3

我有一个接收端口，其中两个 FILE 接收位置轮询同一个网络共享。接收位置之间的唯一区别是它们使用不同的文件掩码。它们都使用带有单个平面文件反汇编器组件的自定义管道。我有一个订阅接收端口的发送端口。（这只是我可以重现问题的最小设置）。

在处理一组文件（最大 1mb 大小）时，管道偶尔会抛出错误。仅当一次将多个文件复制到接收位置文件共享并且不定期发生时，才会发生这种情况。该错误通常为：

解析传入文档时出现错误：“查找时发现意外数据：'\r\n'当前正在解析的定义是GIRMFile。发生错误的流偏移量是491540。发生错误的行号是2446 . 发生错误的列是199。”。

检查所示行号处的挂起消息，始终有 512 字节的数据与传入消息不同。这 512 字节的数据始终与同时使用的其他输入文件之一的数据相匹配！或者在极少数情况下，不正确的 512 字节数据是来自同时使用但在管道处理之后的文件的数据（即暂停的平面文件具有 512 字节的 xml 块！）。这 512 个字节在挂起的消息中从未处于一致的位置。

认为 BizTalk 数据库以某种方式损坏，我将其删除并重新配置。成功处理了几百个文件后，问题又回来了。

这只发生在我们的测试盒（VMWare vm）上，所以我怀疑机器在某种程度上是问题所在。但是机器没有在其他进程中报告其他错误似乎很奇怪。

4

6 回答 6

1

有趣 - 我记得在 BizTalk 2004 中看到过类似的东西，但在 BT2006 中没有看到类似的东西。

听起来管道可能会遇到线程问题 - 可能是由于从同一文件位置接收文件。

您是否尝试过任何高级文件接收位置属性？

我特别在想“阅读时重命名文件”复选框。也许如果问题出在非线程安全的流读取上，那么创建重命名文件的过程（我认为它只使用标准 IO 库）将允许 BizTalk 获得干净的流。

只是猜测 - 如果您找到解决方案，请报告！

于 2008-11-26T21:14:01.743 回答
1

这仅发生在我们的测试盒（VMWare vm）上

如果您无法在另一台具有相同配置的机器上成功复制它，我会将其标记为非问题或外部问题。同意前面提到的并发问题的可能性很小

于 2009-01-03T00:34:50.137 回答
0

我不得不说我觉得这很奇怪，我很难相信进入 BizTalk 的 5 年（从 2004 年算起 :-)），文件适配器和标准反汇编程序有线程问题。，

文件是否通过网络进入提取位置？你使用什么文件掩码？接收位置之一是否有可能在文件传输完成之前拾取文件？

于 2008-12-06T13:38:42.300 回答
0

您说接收位置网络是网络共享-也许是网络问题？你能在本地驱动器上重现这个吗？

于 2009-01-06T02:38:48.683 回答
0

在访问共享的 VMWare VM 上运行的程序也存在类似问题。由于某种原因，文件似乎已损坏。

这与 BizTalk 无关，它发生在内部开发的应用程序中。

重新启动 VM 可以暂时解决我们的问题。在我们的案例中，我们能够重新配置我们的流程以不使用共享。我们从来没有努力找到真正问题的解决方案。

于 2011-02-17T15:27:29.717 回答
0

还有一些想法……共享是 DFS 共享吗？你能把接收位置放在不同的主机上，看看会发生什么吗？

于 2009-01-20T16:11:25.320 回答