Yossi Dahan [BizTalk]

Google
 

Thursday, March 29, 2007

Exceptions.Types.InterceptorException

We've had this error today:

Exceptions.Types.InterceptorException
GetTempFileName Failed.

Exception type: StreamingException
Source: Microsoft.BizTalk.Streaming
Target Site: System.IO.Stream CreatePersistentStream()

Stephen W. Thomas blogged on this here

Our case was similiar, but not identical - it had nothing to do with correlation.
We had a loop on take parts of a message using xpath and creating a new message out of every part.

Then, we had a decision shape and in each branch we would start some orchestration passing in that message, together with a port through which we would expect a response - a classic scatter gather pattern.

However, in the else branch of the decide, we do not call any orchestration; the problem was that we also did not advance the loop counter, so the process went around the loop endlessly, creatting a new message each time in the process.

After almost two days BizTalk has had enough and we started getting these errors.

Once we've spotted the endless loop we've created by mistake and sorted it out, we stopped getting the errors obviously.

Saravana Kumar's BizTalk247.com

I know I'm a bit behind others on this, but if you have missed any of the other bloggers recommendations so far, go an have a look at Saravana Kumar's BizTalk247.com.

I have intentionally waited before bloggin about it as I wanted to see how it developes, but it seems that in a very short time it has become what I think is a great information hub for BizTalkers.

Adding to that great contents by Saravana himself and a very pleasant web design and you get a great portal to come back to on a regular basis.

Well done Saravana!

Friday, March 23, 2007

Query HAT based on an interchange Id

This one got me wondering for while, but as ever - once you know the answer - it is quite simple really.

Initially I was struck by the fact that there's no apparent way to find anything in HAT based on the interchange id.

I've got to look at it because we're doing quite a lot of tracking in our solution and as you can imagine, the interchange id was quite an appealing thing to use to id our processes and link various tracking and tracing information to them.

However, we quickly found out that when we do have a problem, although we can quickly get from our tracking the interchange id, there's no query in HAT that would find you the orchestration instance(s) that relates to that interchange id. the interchange id seems to be in the message's context and thats it. or so we thought.

Since we track a lot of information, over time, we could take an overview of what we have again, and so we spotted that the interchange id is always the id of the first message in the interchange (at least in our case, we did not do an extensive research into this)

This mean that we could now easily write a HAT query that would find this messgage. then - looking at that message's flow we can see which pipeliens and, more importantly for us, which orchestrations processed it and even get a neat little link to open them in replay mode.

The more difficult bit is to locate instances of orchestrations that are part of that interchange but we're spawned as a result of other direct bound ports from the orchestration ( as opposed to call or start orchestration shapes), but with careful digging through HAT I do belive that is possible as well.

So - to conclude - it is possible, and actually quite easy, to find an orchestration in HAT using an interchange id.

Labels:

Thursday, March 22, 2007

a few observations around threads and finalization in BizTalk

I’ve been exploring a little bit with threads, appDomains and host shutdown in process yesterday.

Out of that came out a few observations to think about (some make perfect sense I guess, but I just didn't think about them until we tried, others less). Sorry for the lack of structure in this post.

BizTalk seems to re-use threads to run orchestrations (so orchestration A runs on thread 1 and finishes. another orchestration will run on thread 1 again) - this is probably due to the fact that the thread had finished and another NEW thread was started with the same id - I don't know if I can prove this reliably though.

When I dropped 100 files in our receive location only 3-4 threads were started to process them; not 100.

If I started a thread from an orchestration (through a helper class, of course) - that thread will continue to run even after the orchestration finishes.

If we stop the host while a thread is running, even if we implement a destructor (or finalize) - we only get a limited time to do so. after 40-50 seconds the thread will die , whether the destructor completed or not.

If you had multiple instances of a class in the host that implement finalize, the finalizers will be called sequentially (so that finalizer for instance B of the class will only be called after finalizer of instance A had finished), according to the previous point, after 40-50 seconds the host will stop, regardless of how many finalizers were actually called. So an instance may be terminated without the finalizer being called.