Re: Sequential Convoy Orchestration and High Instance State Messag
Web Server forum
Back To The Forum Home!Search!Private Messaging System

Web Server Talk Web Server Talk > Web Servers reviews > BizTalk Server > BizTalk Server Orchestration > Re: Sequential Convoy Orchestration and High Instance State Messag




  Last Thread   Next Thread Next
  Show Printable Version Email this Page Subscribe to this Thread      Post New Thread    Post A Reply      

    Re: Sequential Convoy Orchestration and High Instance State Messag  
Craig Vermeer


View Ip Address Report This Message To A Moderator Edit/Delete Message


 
03-07-06 10: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 m
ake
> 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 th
is
> 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.





[ Post a follow-up to this message ]



    Sponsored Links  




 





   All times are GMT. The time now is 02:36 AM.      Post New Thread    Post A Reply      
  Last Thread   Next Thread Next


Most Popular forums 

Forum Jump:
Rate This Thread:

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are ON
[IMG] code is OFF
 
Medical and Health forum | Computer Games Reviews | Graphics design forum

Back To The Top
Home | Usercp | Faq | Register