| Author |
Message
|
| new_to_wmb8 |
 Posted: Wed Feb 11, 2015 3:54 am Post subject: Put the Message back to the queue |
 |
|
Centurion
Joined: 28 May 2013
Posts: 127
Location: Hyderabad, India
|
Hi All,
I am using the http server and my requirement is something like that whenever server is down we want to put the message back to the top of the queue.
Whenever server down exception occur, message will remain in the queue on the top and it will start retrying to send again after 2 minutes.
Any suggestions or way to do? |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Feb 11, 2015 5:12 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Using synchronous protocols is actually a nightmare. MQ is so much better.
All the questions of how long to wait, what to do if no response is received, when to retry, what to do with other pending messages and so on are all consequences of using HTTP instead of MQ to connect to back-ends.
Do you retry indefinitely (at 2 min intervals)? At what point do you give up?
Should all other requests wait behind the failing request or not?
You can't put a message to the top of a queue so the correct model is to rollback the message (back it out).
Making the best of a bad protocol - I would say that you use the HTTP/SOAP request node - set the 2 min timeout on that node. If it fails then backout the message (rollback the transaction).
You can also set a backout requeue threshold and backout requeue queue to decide to eventually give up retrying if you want to.
There should not be a need to sleep inside the flow - but the ESQL sleep function is there should you want to pause before rolling back the message.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 11, 2015 6:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| You can't put a message to the top of a queue |
You can put a message with a higher priority than not-previously-processed messages so they go to the top. Clearly all of those messages will then stack so the newest to-be-reprocessed message is at the bottom of that block.
Aside from that quibble, I agree with and echo all your comments.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| new_to_wmb8 |
| Posted: Wed Feb 11, 2015 6:29 am Post subject: |
|
|
Centurion
Joined: 28 May 2013
Posts: 127
Location: Hyderabad, India
|
Yes i have to wait for 2 min then retry indefinitely.
I am planning to use the sleep function in the esql that will put the delay and using the back out threshold to very high value so that message will retry again and again for server down exception. but can any one suggest me how i can restrict this scenario only in case of server down, rest in all cases flow should behave normal.
I have set the transaction to yes but in this case every exception message start retying.
Please suggest |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Feb 11, 2015 8:39 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Vitor wrote: |
| zpat wrote: |
| You can't put a message to the top of a queue |
You can put a message with a higher priority than not-previously-processed messages so they go to the top. Clearly all of those messages will then stack so the newest to-be-reprocessed message is at the bottom of that block.
Aside from that quibble, I agree with and echo all your comments. |
Yes, I was ignoring that for simplicity and because it also seems to be the wrong approach in a transactional sense.
I have seen flows send messages to holding queues for later processing - it never works out to be a good design though unless you can do something else useful in that flow in the meantime.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Feb 11, 2015 8:43 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| new_to_wmb8 wrote: |
Yes i have to wait for 2 min then retry indefinitely.
I am planning to use the sleep function in the esql that will put the delay and using the back out threshold to very high value so that message will retry again and again for server down exception. but can any one suggest me how i can restrict this scenario only in case of server down, rest in all cases flow should behave normal.
I have set the transaction to yes but in this case every exception message start retying.
Please suggest |
I don't see why you need a sleep at all. Set the 2 min timeout as the response timeout value in the HTTP or SOAP request node.
Clearly you would not want to sleep if the http request was successful -that should be easy enough to detect and use conditional logic in the ESQL compute node afterwards.
But - always try the simple approach first. Use standard node properties.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
