|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Multithreading with TimeoutControl/TimeoutNotification Retry |
« View previous topic :: View next topic » |
Author |
Message
|
howardl |
Posted: Fri Aug 19, 2011 8:09 am Post subject: Multithreading with TimeoutControl/TimeoutNotification Retry |
|
|
Novice
Joined: 13 Jul 2010 Posts: 11
|
I am using a TimeoutControl node and TimeoutNotification node as a retry mechanism for a SOAP Request. The time for the synchronous response from the web service combined with TimeoutNotifications only having one instance is not allowing the throughput I am looking for. I am looking to be able to increase the capacity of the web service delivery flow with multiple threads while still taking advantage of the Timeout nodes.
I have found having a separate flow to only put the timeout event to a queue and then let the web service delivery flow take input from the queue allows the multiple threads for delivery I want. While solving the multithreading on delivery issue, it introduces the risk of duplicate messages if the queue gets backed up to the point where the delay is greater than the retry interval.
I have a few options to stop this duplicate messages problem, but my questions are what are the pros/cons/risks associated with each option, are there any other options for the duplicate messages problem or any other multithreading options in general, and is this a possible risk/bad idea in general to try to introduce multithreading while using timeout control?
Option 1: When the message is put to the queue set an expiry slightly less than the retry interval. If the message sits on the queue for too long the message will expire before the duplicate message gets put on the queue. However, it is possible for this to repeat until the retry count runs out, and then the last message expires and the message never delivers when it may of been possible too.
Option 2: Before putting the message to the delivery queue perform a mqget to determine if the message already exists. This would require a second queue in the middle though, as a mqget directly in the TimeoutNotification flow once again introduces the delay with a single thread problem. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Fri Aug 19, 2011 9:06 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
Hi Howard,
WebSphere Message Broker is designed to be stateless. You are attempting to imply state on a stateless design. You are creating a lot of I/O to do this.
Its not clear if you are hosting a Web Service which calls a downstream Web Service? If so, whats the point of retrying after the caller goes away?
Web Services are designed also to be stateless. It is the caller's responsibility to check the result of the Web Service call to determine if a re-call is needed.
Seems to me you are doing alot of work to fit a square peg into a round hole. If I were your client, I would want you to tell me that I need to re-think my design and change it so the design is stateless.
Lance _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|