web stats
How does Destination Queue affect response - Mirth Community

Go Back   Mirth Community > Mirth Connect > Support

Reply
 
Thread Tools Display Modes
  #1  
Old 05-09-2019, 04:57 PM
khobbs khobbs is offline
Mirth Newb
 
Join Date: May 2016
Posts: 11
khobbs is on a distinguished road
Default How does Destination Queue affect response

If we turn the destination queue on, does that mean the channel sends a response immediately like it does for the source queue?

Is it possible to have multithreading, in-order processing, and synchronous (block until response from dest api call, because upstream channel needs to "wait for previous destination"), or does using a destination queue return a response immediately?

If we leave the source queue off and max processing threads to 1, and enable the destination queue to Always with more than 1 queue thread and use an MRN based thread assignment variable....does this give us a multithreaded, in-order processing, synchronous ("wait for previous destination" on upstream channel) pipeline?

In the documentation it is explicitly clear that a source queue causes an immediate response, but it's not so clear in the docs with a destination queue.

Does this involve the Response: field in the Source panel. Setting the response to be "destination completed". That popup says the response is from the destination, and it mentions QUEUED status, so that might be my answer right there. Does this mean if I queue in the dest I get an immediate response of QUEUED, if so then I think we can't get what we want.

Thank you for your time!

-kevin
Reply With Quote
  #2  
Old 05-10-2019, 05:18 AM
bhesler bhesler is offline
Mirth Newb
 
Join Date: Jul 2015
Posts: 11
bhesler is on a distinguished road
Default

I am not on expert on this but below are my answers to your questions to add to the discussion.

If we turn the destination queue on, does that mean the channel sends a response immediately like it does for the source queue?

Answer: The response would not be sent to the sending channel until it is processed by the receiving object. If it is sending to another channel with Source Queue on then the sending channel would get an immediate response. However if it is sending to an application that takes 30 seconds to process the message then the response would be received in 30 seconds.


Is it possible to have multithreading, in-order processing, and synchronous (block until response from dest api call, because upstream channel needs to "wait for previous destination"), or does using a destination queue return a response immediately?

Answer: You could have multithreading in multiple ways. If you have Max Processing Threads > 1 on the source then you are multithreading there. Or if you have Advanced Queue settings on the destination and increase the thread count there it is multi-threaded. I do know that once queuing turns on you lose the ability to process in order.



If we leave the source queue off and max processing threads to 1, and enable the destination queue to Always with more than 1 queue thread and use an MRN based thread assignment variable....does this give us a multithreaded, in-order processing, synchronous ("wait for previous destination" on upstream channel) pipeline?

Answer: I donít know if the order will be preserved. Letís say the queue thread is set to 2. And the receiving application processes gets too messages at once. If it processes the 1st one before the 2nd, and then receives the 3rd before it is done processing the 2nd it is then out of order.


In the documentation it is explicitly clear that a source queue causes an immediate response, but it's not so clear in the docs with a destination queue.

Does this involve the Response: field in the Source panel. Setting the response to be "destination completed". That popup says the response is from the destination, and it mentions QUEUED status, so that might be my answer right there. Does this mean if I queue in the dest I get an immediate response of QUEUED, if so then I think we can't get what we want.

Answer: You do get an immediate response of queued once a message is queuing.
Reply With Quote
  #3  
Old 05-10-2019, 06:30 AM
agermano agermano is offline
Mirth Guru
 
Join Date: Apr 2017
Location: Indiana, USA
Posts: 894
agermano is on a distinguished road
Default

The destination queue is processed asynchronously. If you need to return the response from a destination you can't let it queue.

When the source queue is off, a source connector response is sent when the channel is finished processing, which is after the post-processor runs, which is after every destination has returned an initial response (which includes QUEUED status.)

Destination queue tries/retries will not trigger a source response or the post-processor script to fire again.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 07:24 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Mirth Corporation