| Author |
Message
|
| shalabh1976 |
 Posted: Thu Aug 21, 2008 11:27 pm Post subject: Memory Issue with message retry in MB6.1 |
 |
|
Partisan
Joined: 18 Jul 2002
Posts: 381
Location: Gurgaon, India
|
We have a requirement to have sequencing and assured delivery for our client. The end system(target) is connected through SOAP Node(webservice). Flow is like : MQInput-->Process-->SOAP Request
Now we have the following scenarios -->
1. Target is down in which case we must retry.
2. Target is up and sends us a response asking us to retry.
3. Target is up and sends us a happy response and we process the next message.
To retry we simply reconnect the out/failure terminal to the SOAP Request.
To simulate a delay we use a dummy loop.( Using Timer nodes causes a problem that the next message is picked up from the queue for processing while this message is waiting. )
However this causes a serious STACK Issue and after a few retries the message gets corrupted and the Broker dequeues the message with the error something like "Dequeued failed message". By increasing the MQSI_THREAD_STACK_SIZE we were able to increase the time to failure but the Problem remains.
What is the way out?
Can the broker somehow not support assured delivery and sequencing over SOAP?
_________________
Shalabh
IBM Cert. WMB V6.0
IBM Cert. MQ V5.3 App. Prog.
IBM Cert. DB2 9 DB Associate |
|
| Back to top |
|
 |
| Maximreality |
| Posted: Fri Aug 22, 2008 4:26 am Post subject: Re: Memory Issue with message retry in MB6.1 |
|
|
Acolyte
Joined: 04 Jun 2004
Posts: 65
Location: Copenhagen
|
| shalabh1976 wrote: |
We have a requirement to have sequencing and assured delivery for our client. The end system(target) is connected through SOAP Node(webservice). Flow is like : MQInput-->Process-->SOAP Request
Now we have the following scenarios -->
1. Target is down in which case we must retry.
2. Target is up and sends us a response asking us to retry.
3. Target is up and sends us a happy response and we process the next message.
To retry we simply reconnect the out/failure terminal to the SOAP Request.
To simulate a delay we use a dummy loop.( Using Timer nodes causes a problem that the next message is picked up from the queue for processing while this message is waiting. )
However this causes a serious STACK Issue and after a few retries the message gets corrupted and the Broker dequeues the message with the error something like "Dequeued failed message". By increasing the MQSI_THREAD_STACK_SIZE we were able to increase the time to failure but the Problem remains.
What is the way out?
Can the broker somehow not support assured delivery and sequencing over SOAP? |
Remove busy waits and potential endless loops, you might end up crashing your executiongroup...
I would consider using SOAP async request/reply nodes to a solution like yours |
|
| Back to top |
|
|
| JLRowe |
| Posted: Fri Aug 22, 2008 4:47 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
Web services (SOAP over HTTP) on the broker does not support the WS-ReliableMessaging and WS-Transaction specs, if you want reliable soap then use WAS or some other app server.
You may want to reexamine your design and have another flow that gets kicked off at regular intervals to see if the service provider is up. You can batch up all your retries and kick them off every 5 mins or so. |
|
| Back to top |
|
|
| shalabh1976 |
| Posted: Sat Aug 23, 2008 11:01 pm Post subject: |
|
|
Partisan
Joined: 18 Jul 2002
Posts: 381
Location: Gurgaon, India
|
Maximreality,
With Async Nodes can we maintain sequencing, ie Message 2 must not be sent till Message 1 is successfully processed.
JLRowe,
We can batch all our retries and use a temp MQ Queue to save the messages. Retry after a certain time interval can be done by Timer Nodes but I have a problem of sequencing. As long as there is a message in the retry queue no message from the main queue must be processed. To do this we built a sequencing engine that used a database table to maintain the sequence. However this had a lot of performance issues and an added dependency on a DB.
Use of another App Server has cost implications for the client and they might not agree.
_________________
Shalabh
IBM Cert. WMB V6.0
IBM Cert. MQ V5.3 App. Prog.
IBM Cert. DB2 9 DB Associate |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Aug 24, 2008 3:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
What you have is message affinity and this is always a bad proposition as it prevents scalability.
Correctly you are using a DB to alleviate some of the message affinity problems.
Keep your design in such a way that the processing of messages is scalable and not affected by message affinity. As you did not specify what the message affinity was about or why you need to heed it there is not much more we can point you towards here.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
