| Craig Vermeer 2006-03-07, 5:51 pm |
| That's cool. FWIW, it wouldn't be another queue, but rather just a
different queue that I'd send it to rather than MSMQt.
Regardless, thanks for thoughts. Throttling in a pipeline component is
an interesting idea, too. I may look into that at some point.
Kevin Farley wrote:
> Craig -
>
> Whatever works for you is fine, but I find it architecturally abnormal to
> have a Queue, drain the Queue into another Queue, and then play games to make
> Orchestrations work.
>
> Playing devil's advocate, even with latency on the Rcv Location wouldn't
> this still be better than the current situation of "unlimited" messages.
> Also, you could put a pipeline component in that Receive to delay the
> messages and perhaps even disable the receive location after it processed a
> message.
>
> (I'm just thinking out loud here...)
>
> What if your Pipeline processed 1 message, Disabled the Recv Location and
> then the Orchestration processed the message and Enabled the Rcv Location.
> For latency, the Pipeline might sleep that interval....
>
> I did recently review the fact that you could use the Suspended Message
> feature of BizTalk 2006 in this case:
>
> 1. If you could correlate both on MessageType plus a SequenceID.
>
> 2. All new messages would Suspend in the MsgBox.
>
> 3. You "unsuspend" 1 message at a time in your loop.
>
> In any case, whatever works for you, mainly I'm sharing the point of view
> that you already have a Queue storing the messages, so I wouldn't tend to
> re-queue them, this is purely a throttle condition....but it certainly is an
> interesting balanced work-load issue that requires synchronization.
>
> Another thought is to have the Pipeline check a Global reference to "Clear
> to Send" from the Orchestration before processing the incoming msg. (or this
> could really be an Adapter). The Orchestration could update a Global
> Reference (a row in a table, a semaphore, etc) to "Do not send", then the
> Adapter/Pipeline Sleeps until the "ReadyToSend" is back on.
>
> I think I'm going to have to do an experiment here, but it will be a few
> weeks because I have some other things on my plate first.
|