3

同じネットワーク共有をポーリングする 2 つの FILE 受信場所を持つ受信ポートがあります。受信場所の唯一の違いは、異なるファイル マスクを使用することです。どちらも、単一のフラット ファイル逆アセンブラー コンポーネントを含むカスタム パイプラインを使用します。受信ポートをサブスクライブする送信ポートがあります。(これは、問題を再現できる最小限のセットアップです)。

ファイルのグループ (サイズが 1 MB まで) を処理するときに、パイプラインがエラーをスローすることがあります。これは、一度に複数のファイルが受信場所のファイル共有にコピーされた場合にのみ発生し、不規則に発生します。エラーは通常次のように表示されます。

着信ドキュメントの解析中にエラーが発生しました:「検索中に予期しないデータが見つかりました: '\r\n' 解析中の現在の定義は GIRMFile です。エラーが発生したストリーム オフセットは 491540 です。エラーが発生した行番号は 2446 です。エラーが発生した列は 199 です。

示された行番号で中断されたメッセージを調べると、一貫して 512 バイトのデータが着信メッセージと異なっています。この 512 バイトのデータは、同時に消費される他の入力ファイルの 1 つからのデータと常に一致します。または、まれに、誤った 512 バイトのデータが、パイプラインによって処理された後に同時に消費されたファイルからのデータである場合があります (つまり、中断されたフラット ファイルには 512 バイトの xml チャンクがあります!)。中断されたメッセージ内で、512 バイトが一貫した場所にあることはありません。

BizTalk データベースが何らかの形で破損していると考えて、それらを削除して再構成しました。数百のファイルが正常に処理された後、問題が再発しました。

これはテスト ボックス (VMWare vm) でのみ発生するため、マシンに何らかの問題があると思われます。しかし、マシンが他のプロセスで他のエラーを報告していないのは奇妙に思えます。

4

6 に答える 6

1

興味深い-BizTalk2004で同様のことを見たことを思い出しますが、BT2006ではそのようなことは見たことがありません。

パイプラインでスレッドの問題が発生している可能性があります。おそらく、同じファイルの場所からファイルを受信したことが原因です。

高度なファイル受信場所のプロパティのいずれかを試しましたか?

特に「読みながらファイルの名前を変更する」チェックボックスを考えています。おそらく、問題がスレッドセーフでないストリーム読み取りにある場合、名前が変更されたファイル(標準のIOライブラリを使用していると思います)を作成するこのプロセスにより、BizTalkはクリーンなストリームを取得できます。

ただし、推測するだけです。解決策が見つかった場合は、報告してください。

于 2008-11-26T21:14:01.743 に答える
1

これは、テスト ボックス (VMWare vm) でのみ発生します。

同じ構成の別のマシンでこれを再現できない場合は、これを問題ではない、または外部としてマークします。同時実行性の問題が発生する可能性は非常に低いという前述の内容に同意する

于 2009-01-03T00:34:50.137 に答える
0

受信ロケーションネットワークはネットワーク共有であるとおっしゃいましたが、おそらくネットワークの問題ですか?これをローカルドライブで再現できますか?

于 2009-01-06T02:38:48.683 に答える
0

さらにいくつかの考え...共有はDFS共有ですか?受信場所を別のホストに配置して、何が起こるかを確認できますか?

于 2009-01-20T16:11:25.320 に答える
0

これは非常に奇妙だと言わざるを得ません。BizTalk に 5 年 (2004 年から数えて :-))、FILE アダプターと標準の逆アセンブラーにスレッドの問題があるとは信じがたいでしょう。

ファイルはネットワーク経由で受け取り場所に送られますか? どのファイルマスクを使用していますか? 転送が完了する前に、受信場所の 1 つがファイルを取得している可能性はありますか?

于 2008-12-06T13:38:42.300 に答える