| Author |
Message
|
| NeXgeN |
 Posted: Wed Oct 23, 2013 7:21 pm Post subject: MQ Callback function call wait till some job is done |
 |
|
Newbie
Joined: 23 Oct 2013
Posts: 6
|
Hi i am using MQCB to register a callback function on my queue for reading new data. I have used MQGMO option of MQGMO_SYNCPOINT. So call MQCMIT at the end of the callback function too. Immediately i call MQCTL and start consumption of messages in the queue, by which my callback function gets called.
My situation here is, i am doing a specific set of tasks in the call back function and i dont want the callback function to be called on next new message which is put in the queue. I want my set of tasks to be finished first.
I am sure there must be a way to do this, but not able to figure out from google or this forum
Can anyone help me out in this. My code base is C and C++. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Oct 24, 2013 5:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you really want messages to be processed one at a time, it's not as clear why you're using callback to do it.
That said, there are two patterns for using callbacks - one of which has the callback invoked in a separate thread from the main program flow, and the other of which has it invoked in the same thread. The second pattern means that there's only one thread doing any work, so you don't have the problem.
More generally, any time you have a section of code that should be reentrant, you shoudl wrap that section of code in a mutex lock. This is standard C/C++ programming methodology, and you should find a lot of exmaples out in places that provide in depth c/C++ assistance. StackOverflow, for example, probably has *tons* of questions and responses. |
|
| Back to top |
|
|
| NeXgeN |
| Posted: Thu Oct 24, 2013 5:58 am Post subject: |
|
|
Newbie
Joined: 23 Oct 2013
Posts: 6
|
We have a requirement to receive the message from MQ in a different thread that the main program thread, So had to use callback.
In the second pattern, will it create one thread and wait for callback function to return, before calling it again? if that is the case, it would be perfect for our scenario.
Cant use mutex locks in the code. We need to sync with MQ only. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 24, 2013 8:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| NeXgeN wrote: |
| We have a requirement to receive the message from MQ in a different thread that the main program thread |
Why? What exactly leads to this requirement?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| NeXgeN |
| Posted: Thu Oct 24, 2013 8:47 am Post subject: |
|
|
Newbie
Joined: 23 Oct 2013
Posts: 6
|
| previously we used to poll MQ at timely intervals for any new data using MQGET, now our main program is running continously, MQ callback function has to retrieve data and do some actions using the data. Dont want to use polling now. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 24, 2013 8:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| NeXgeN wrote: |
| previously we used to poll MQ at timely intervals for any new data using MQGET, now our main program is running continously, MQ callback function has to retrieve data and do some actions using the data. Dont want to use polling now. |
I asked why you're processing the messages in a separate thread to the one which receives the messages, not why you're using callback. 
For the record and slightly off topic, you don't have to poll with MQGet & really shouldn't; it's much better to set a wait interval on the MQGet than poll round.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| NeXgeN |
| Posted: Thu Oct 24, 2013 8:29 pm Post subject: |
|
|
Newbie
Joined: 23 Oct 2013
Posts: 6
|
I am not processing the messages in a separate thread, messages are processed in the callback thread only, but the main thread does some other operations , which is different from message processing.
If i use wait in get, wont it block the main thread, i mean the main thread does some other operations too. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Thu Oct 24, 2013 11:38 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
When using Async consume you are guaranteed that your callback won't called multiple times at the same time for the same HOBJ. So, until you have returned from your callback you won't be given the 'next' message. So, you could do as much processing as you like in the call back thread. Of course it's not good practice to just sit in a GET(wait) for hours in the callback but it's not unreasonable to spend a second or two (and this is a huge amount of time in processing terms, unless you're running java of course  ) if you really must. If you are going to do something which is more long lived than that then I would suggest you suspend the consumer before you return from the call back, do whatever it is that takes so long, and then resume the consumer. However, suspending and resuming consumers is a fairly expensive operation so you'd like to avoid that if you can.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| NeXgeN |
| Posted: Fri Oct 25, 2013 1:22 am Post subject: |
|
|
Newbie
Joined: 23 Oct 2013
Posts: 6
|
| Quote: |
| When using Async consume you are guaranteed that your callback won't called multiple times at the same time for the same HOBJ. So, until you have returned from your callback you won't be given the 'next' message. |
Are you sure about the above, i thought it creates a new thread for calling callback function everytime a new message is put on MQ.
I plan to use Suspend and Resume. but i read this on IBM site
| Quote: |
MQOP_SUSPEND
Pause the consuming of messages. This operation releases the connection handle.
This does not have any effect on the reading ahead of messages for the application. If you intend to stop consuming messages for a long time, consider closing the queue and reopening it when consumption continues. |
Fail to understand the line in bold. Can anyone explain. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Fri Oct 25, 2013 1:41 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Hi,
Yes I am certain. Consider the HCONNs. If you only have one HCONN then you can only have one 'effective' MQI call at one time (and let's not start the debate about the subtle nuances of this). There is a thread associated with the callback function it is only one or zero threads. There is no concept of creating a thread for every message put. For one thing this would be very inefficient but for another it would be chaotic. You can't have 10 messages being put to a queue and all of them being processed at the same time by default, ordering would be completely out of the windows. So, ordering is maintained, messages are delivered to the consumer function one after the other just as if the application was issuing a sequence of MQGET calls. Now, if the application really did want to process messages in parallel then it could make two connections and start two consumers.
The read-ahead case is different. If you have read-ahead set for your client connections then the client will pre-fetch any non-persistent messages it can and keep them in a holding buffer on the client. Stopping your consumer on the client will not stop this pre-fetch process. If these messages could be given to some other process then you probably don't want to use read ahead but if your application is the only possible consumer then there is little downside to allowing read ahead to get them before you need them. Read ahead can give a significant performance benefit.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| NeXgeN |
| Posted: Fri Oct 25, 2013 1:48 am Post subject: |
|
|
Newbie
Joined: 23 Oct 2013
Posts: 6
|
Cool. Thanks Paul 
Suspend and Resume serves my purpose. |
|
| Back to top |
|
|
|
|
