Unexpected data found error during BizTalk Simultaneous Receive

Question

I have a receive port with two FILE receive locations polling the same network share. The only difference between the receive locations is that they use a different file mask. They both use a custom pipeline with single Flat file disassembler component. I have a send port subscribing to the receive port. (this is just the minimal setup where I can reproduce the problem).

When processing a group of files (up to 1mb in size) occasionally the pipeline throws an error. This only occurs when more than one file is copied to the receive location file share at once and occurs irregularly. The error generally reads:

An error occurred when parsing the incoming document: "Unexpected data found while looking for: '\r\n' The current definition being parsed is GIRMFile. The stream offset where the error occured is 491540. The line number where the error occured is 2446. The column where the error occured is 199.".

Examining the suspended message at the line number shown, consistently 512 bytes of data is different from the incoming message. This 512 bytes of data always matches data from one of the other input files consumed at the same time! Or in a few rare cases the incorrect 512 bytes of data is data from a file consumed at the same time but after it had been processed by the pipeline (i.e. the suspended flat file has a 512 byte chunk of xml!). The 512 bytes is never in a consistent location within the suspended messages.

Thinking the BizTalk databases were corrupted in some way, I deleted them and re-configured. The problem returned after a few hundred files were processed successfully.

This only occurs on our test box (a VMWare vm) so I suspect the machine is the problem in some way. But it seems odd that the machine isn't reporting other errors in other processes.

Answer 1

Interesting - I recall seeing similar things in BizTalk 2004 but haven't seen anything like that with BT2006.

It sounds like the pipeline may be running into threading issues - perhaps due to receiving the files from the same file location.

Have you tried any of the advanced file receive location properties?

I'm thinking in particular the 'Rename files while reading' checkbox. Perhaps if the issue is with non-threadsafe stream reads, this process of creating a renamed file (which I think just uses standard IO libraries) will allow BizTalk to get a clean stream.

Only guessing though - please report back if you find a solution!