tags:

views:

603

answers:

5

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.

+1  A: 

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!

David Hall
A: 

I have to say I find this very strange, I would find it very hard to believe that 5 years into BizTalk (counting from 2004 :-)), the FILE adapter and the standard disassemblers have threading issues.,

Are the files coming into the pick up location over the network? what file masks are you using? is there a chance that one of the receive location is picking up the files before their transfer is complete?

Yossi Dahan
+1  A: 

This only occurs on our test box (a VMWare vm)

If you do not succeed in reproducing this on another machine with the same configuration, I'd mark this off as a non-issue, or external. Agree with the aforementioned that concurrency problems are highly unlikely

Yuval A
A: 

You said the receive location network is a network share - perhaps it's a network problem? Can you reproduce this on local drive?

Booji Boy
A: 

A few more thoughts... is the share a DFS share? Can you put the receive locations on different hosts and see what happens then?

ChrisLoris