Hi Alan,  thanks for your reply. We discussed it a couple days ago in
another thread.

I am (vaguely) aware of how and when an orchestration should be dehydrated,
but his orchestration is processing like 1000 messages from the same
MQseries queue in about 10 minutes, and within that timeframe it dehydrates
and rehydrates for EVERY single message.
The hardware consists of two BizTalk servers on top of an SQL cluster (with
two nodes). Both BizTalk servers have 4 GB ram and a single 3 Ghz CPU.

Doesnt that sound a little over the top?  It drives me a little nuts ... 

I am actually  using your Sequential Convoy Aggregator pattern as a basis
for my own orchestration as you have implemented the timeout timer in a nice
way, and it is my first venture into orchestration. Thanks for posting it
btw!!  

regards
Lars


"Alan Smith" <AlanSmith@discussions.microsoft.com> wrote in message
news:2632BB46-A39D-4318-8A23-99B327CA4F99@microsoft.com...
> Hi Lars,
>
> The dehydration shuld not be a problem. The orchestration will dehydrate
> orchestrations when it thinks hey will not be active for a while, and when
it
> needs to free memory resources. One option is to test the orchestration on
a
> system with more ram, this shuld reduce the dehydration occurances.
>
> I don't think there is a way to prevent it from hppening, and if you
could,[vbcol=seagreen]
> it may cause other performance problems.
>
> Regards,
>
> Alan
>
>
> "Lars W. Andersen" wrote:
> 
for[vbcol=seagreen] 
prevent it[vbcol=seagreen] 
two[vbcol=seagreen] 
None.[vbcol=seagreen] 

[ Post a follow-up to this message ]