A bit more on this. The interesting issue is that the BizTalk MsgBox does no
t
expect to have Messages received that have no Subscribers, and with your
Orchestration intending to act as a Throttle, the result is non-optimal unde
r
load.

So, the solution is to throttle prior to the Orchestration. I would not
advocate creating another Accumulator, since you have a MSMQT already.

I see two reasonable approaches:

1. Disable/Enable the Receive location programmatically in your
Orchestration. In your Loop you could Disable the ReceiveLocation after the
Correlated Receive and then Re-enable the ReceiveLocation prior to the Liste
n
Shape.

The following URL provides guidance on programmatically Enabling Receive
locations:
http://msdn.microsoft.com/library/d...e_core_odws.asp

You could conceivably throttle in a pipeline to slow down the rate of
Interchanges to balance but you probably don't need to do this here.

2. You could make an Intermediary component to not "drain" the MSMQT at a
rate higher than your solution could process, this has the effect of letting
the MSMQT be the true Accumulator and adding more business rules, controls
and events to a process that can monitor Queue size, processing rate, Notify
parties if certain conditions occur.

Both solutions address the issue of not taking in more Messages from your
MSMQT at a rate higher than you want to process them which is your issue.

It would be interesting to write solution 1 for you and as a general
solution for re-use to demonstrate Throttling. I'll put it on my list but I
have some other things I have to work on ahead of that.

Hopefully this will work for you.

Kevin

"Kevin Farley" wrote:
[vbcol=seagreen]
> Craig -
>
> Aha. Ok, at least we clarified that your not explicitly accumulating in th
e
> Orchestration. Here is what I think is going on relative to the subscripti
on
> on the correlated receive port.
>
> The Subscription is currently such that the Orchestration is subscribing t
o
> all messages from the Q's receive port. So the Rcv Location processes all 
of
> the Q items an publishes them to the MsgBox. The Orchestration is subscrib
ed
> to all of the Msgs from this Rcv Location so the Orch gets all of the Msgs
> even tho it can only process 1 at a time.
>
> So, I now see that it is an interesting subscription problem. I haven't ha
d
> this exact problem before, but my approach would be to try to throttle
> receives in the Rcv Location. So I think I might try to turn on and off th
e
> receive process so the orchestration can allow the Q to maintain the
> Accumulation.
>
> I will think about this more to find the precise answer, but my approach
> would be to keep the Orch as is, and throttle in the Rcv side.
>
> More to come.
>
> Kevin
> --
> Kevin Farley - Technical Principal
> Internosis, Inc. www.internosis.com
>
>
> "Craig Vermeer" wrote:
> 

[ Post a follow-up to this message ]