| Author |
Message
|
| Harman |
 Posted: Wed Apr 22, 2020 4:19 am Post subject: Query regarding pause and resume a message processing |
 |
|
Newbie
Joined: 22 Apr 2020
Posts: 9
|
Hi Experts
I am working on a project which has couple of message flows all of which are MQ input initialized . After one is completed , the other starts. I have requirement wherein I want to pause the processing of a particular message in next to current queue and resume it later. I know it is feasible to inhibit and allow the queue itself using java apis and esql , but how to do it for a particular message and not all the messages.
Regards
Harman |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Apr 22, 2020 6:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
This is a bad requirement as it smacks of message affinity.
You could browse the message in question to put a lock on it and then sleep the thread until you're ready but that both grossly inefficient & offers all sorts of problems in recovery situations.
If you absolutely have to do this then I would suggest reading the message off the queue, storing it someplace (db, file, etc,) and then reading it back out when you're ready to process it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 22, 2020 6:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Or better still, get whoever's putting the messages to do it with all the messages in an MQ group and have the flow only read them off when the group is complete.
I have some doubts that's going to work for you with 2 flows, but would be feasible if you had one MQ enabled flow with 2 sub flows.
The path of least reengineering is probably reading all the messages off and sticking them someplace until you're ready for them.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Apr 22, 2020 3:38 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
One solution is to move the 'paused' message to a separate queue, that is picked up when needed.
What is the criteria for 'resuming it later' ? Is it time based or event based? Could there be multiple messages in a paused state, with different resumption criteria for each?
MQ is built around the concept of processing everything as quickly as possible. If you need time or event based marshalling, the data should be stored in a DB, and processed when needed.
_________________
Glenn |
|
| Back to top |
|
|
| Harman |
| Posted: Sun May 17, 2020 4:29 am Post subject: |
|
|
Newbie
Joined: 22 Apr 2020
Posts: 9
|
| @Vitor: Thank you for your reply. I got your point . Let me try these approaches suggested by you . |
|
| Back to top |
|
|
| Harman |
| Posted: Sun May 17, 2020 4:32 am Post subject: |
|
|
Newbie
Joined: 22 Apr 2020
Posts: 9
|
| @gbaddeley : Thank you for your reply. To answer your questions, it a UI event based. So I have a button of pause and play . On Pause , it will stop the message from being processed in the consecutive queue and when play is clicked , we need to resume the message processing from that state only. Also yes there can be multiple messages in the paused state and can resume from the state where they were paused |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun May 17, 2020 3:03 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Harman wrote: |
| @gbaddeley : Thank you for your reply. To answer your questions, it a UI event based. So I have a button of pause and play . On Pause , it will stop the message from being processed in the consecutive queue and when play is clicked , we need to resume the message processing from that state only. Also yes there can be multiple messages in the paused state and can resume from the state where they were paused |
MQ is not designed to have "stateful" messages that can be updated to turn on / off a "processing flag". A possible design is to consume all the messages and store in a DB. Other messages from UI events (pause, play) could turn on and off the processing flag in the DB row, to control the processing.
_________________
Glenn |
|
| Back to top |
|
|
|
|
