我有一个接收端口，其中有两个FILE接收位置轮询相同的网络共享。接收位置之间的唯一区别是它们使用不同的文件掩码。它们都使用带有单个Flat文件反汇编程序组件的自定义管道。我有一个订阅接收端口的发送端口。 （这只是我可以重现问题的最小设置。）
当处理一组文件（最大大小为1mb）时，管道偶尔会抛出错误。仅当多个文件一次复制到接收位置文件共享并且不规则地发生时，才会发生这种情况。错误通常如下：
解析传入文档时发生错误：“意外数据 找到时找到：'\ r \ n'正在解析的当前定义是 GIRMFile。发生错误的流偏移量为491540 发生错误的行号是2446.列所在的位置 发生错误的是199。“。
检查显示的行号处的暂停消息，始终512字节的数据与传入消息不同。这512字节的数据总是匹配同时消耗的其他输入文件之一的数据！或者在少数情况下，不正确的512字节数据是来自同时消耗但在管道处理完文件之后的文件中的数据（即，挂起的平面文件具有512字节的xml块！）。 512个字节永远不会在挂起的消息中处于一致的位置。
认为BizTalk数据库在某种程度上已损坏，我将其删除并重新配置。成功处理几百个文件后返回问题。
这只发生在我们的测试盒（VMWare vm）上，所以我怀疑机器在某种程度上是个问题。但似乎很奇怪机器没有报告其他过程中的其他错误。
答案 0 :(得分：1)
有趣 - 我记得在BizTalk 2004中看到过类似的东西，但BT2006却没有看到类似的内容。
听起来管道可能会遇到线程问题 - 可能是因为从同一文件位置接收文件。
您是否尝试过任何高级文件接收位置属性？
我正在考虑“在阅读时重命名文件”复选框。也许如果问题是非线程安全流读取，那么创建重命名文件（我认为只使用标准IO库）的过程将允许BizTalk获得干净的流。
只是猜测 - 如果找到解决方案，请报告回来！
答案 1 :(得分：1)
这只发生在我们的测试盒（VMWare vm）
上
如果你没有成功地在具有相同配置的另一台机器上复制它，我会将其标记为非问题或外部。同意前面提到的并发问题非常不可能
答案 2 :(得分：0)
我不得不说我觉得这很奇怪，我觉得很难相信BizTalk的5年（从2004年开始计算:-)），FILE适配器和标准反汇编程序都有线程问题。，
文件是否通过网络进入接收位置？你用的是什么文件掩码？在转移完成之前，其中一个接收位置是否有机会提取文件？
答案 3 :(得分：0)
你说接收位置网络是一个网络共享 - 也许这是一个网络问题？你能在本地驱动器上重现这个吗？
答案 4 :(得分：0)
还有一些想法...... DFS分享的份额是多少？您可以将接收位置放在不同的主机上，然后看看会发生什么？
答案 5 :(得分：0)
我们在访问共享的VMWare VM上运行的程序遇到类似问题。由于某种原因，文件似乎已损坏。
这与BizTalk无关，它是在内部开发的应用程序中发生的。
重新启动虚拟机会解决我们的问题一段时间。在我们的案例中，我们能够将我们的流程重新配置为不使用共享。我们从来没有找到解决真正问题的方法。