It’s late on a Friday. I am still at the client site. I just canceled my flight home. It is my anniversary weekend (yep it is on 9/11, sure sucks). We are hours from going live… But, what does Exceptions.Types.InterceptorException GetTempFileName Failed mean?
I ran into this problem while testing some recently updated Orchestrations that use Convoys to process messages received from multiple source systems in order. A small change was made that removed a Send Shape and replaced it with a custom .net component call to a java web service. Seems simple enough.
When the process encounters an exception, it uses the file adapter to write the file to disk and stops message process. That all tested perfectly.
When the process completes successfully but no other messages have arrived in the convoy. That all tested perfectly.
When the process completes successfully but new messages have arrived in the convoy the follow error occurs:
Exception type: StreamingException
Target Site: System.IO.Stream CreatePersistentStream()
Additional error information:
Not only do I get an exception, but the process continues forever in an endless loop with a 100% CPU spike.
So, what could be the problem and more importantly how can it be fixed?
The answer lies with the change that was made by replacing the Send Shape with a .net component call. This removed a persistence point in the Orchestation. In fact, it removed the only persistence point for the happy path (i.e. no errors) inside the Orchestration. So, when this message is processing, a 2nd message arrives in the convoy, and the next Receive Shape is hit the whole process goes down hill.
Solution: I added an Atomic Scope (persistence point) right after the Receive Shape. Problem solved.
A better solution: Isolate the units of work inside the Orchestration into logical units and use Atomic scopes to track progress through the Orchestation. In the event of a Server Crash, the Orchestrations would restart in more desirable state.
Even better solutions? I’m sure.