| Author |
Message
|
| mgerben |
 Posted: Tue Oct 10, 2006 6:13 am Post subject: Looking for a 'wait for all' function (C++) |
 |
|
Newbie
Joined: 10 Oct 2006
Posts: 3
|
Sorry for this rtfm question, but I don't have the M yet (it's on order) and I need to make an estimate on how to design an MQ program.
Language is C++ and the program will have to wait for messages on multiple queues.
I want to know if I have to build this multithreaded, with one thread per queue, and all queues executing a 'wait for message' function,
or
whether I can have one mainthread, with one eventloop, waiting for all queues simultaneously (sort of a 'wait for event' function). |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Oct 10, 2006 6:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Frankly you can do both - which is best is one of "those" questions!
What you can't do is set one call to listen on multiple queues and return when each queue has a message on it. Each MQGET call (or equivalent) referes to a specific queue and returns under the conditions you set for that queue. There's no reason why a single thread can't issue multiple MQGET calls against one or more queues if it so desires.
AFAIK the connection to a queue manager is not thread safe, so a multiple thread solution would require multiple connections.
And while you're waiting for the M, have a peek here:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp
or here:
http://www-306.ibm.com/software/integration/wmq/library/library6x.html
Happy Reading! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Oct 10, 2006 12:37 pm Post subject: Re: Looking for a 'wait for all' function (C++) |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mgerben wrote: |
| I want to know if I have to build this multithreaded, with one thread per queue, and all queues executing a 'wait for message' function |
A "correct" answer will depend on your concurrency requirements. Do the n queues have to be processed in some application-defined order. Or are they all independent streams of work? If the former, then multiple threads makes little sense. If the latter, then multiple threads makes a lot of sense.
| Quote: |
or
whether I can have one mainthread, with one eventloop, waiting for all queues simultaneously (sort of a 'wait for event' function). |
Yes, but. The "Yes" only applies if you're using the IBM XMS C++ libraries. The "but" is because internally the XMS client libraries will get from your n queues in a round-robin fashion, with yielding logic to ensure none is starved of processing time.
So, there's a bit more detail to assist in what appears to be a non-trivial application design issue. If you want to post more, I'm sure you'd find several willing to volunteer opinions. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Oct 10, 2006 12:39 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Vitor wrote: |
| AFAIK the connection to a queue manager is not thread safe, so a multiple thread solution would require multiple connections. |
Just a quick reply on this point. Rather than the phrase "not thread safe", I would prefer a more detailed point: a connection to a queue manager cannot be used concurrently on more than one thread at the same time. MQ library code will not crash if you try, but you will get reasonable and documented return codes to show you've tried something that's disallowed. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 10, 2006 11:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
mvic
Thanks for the clarification. Not solid on multi-threading.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mgerben |
| Posted: Wed Oct 11, 2006 6:06 am Post subject: |
|
|
Newbie
Joined: 10 Oct 2006
Posts: 3
|
Thanks all for the answers and not flaming one who hasn't read the manual.
| Vitor wrote: |
What you can't do is set one call to listen on multiple queues and return when each queue has a message on it.
|
No need. I'd like the program to respond to any message, not wait untill all queues have a message on them. We're still talking about the same thing?
| Quote: |
Each MQGET call (or equivalent) referes to a specific queue and returns under the conditions you set for that queue. There's no reason why a single thread can't issue multiple MQGET calls against one or more queues if it so desires.
|
That sounds more like it.
But - this is where my lack of MQ knowledge shows - does the MQGET call not block itself untill a message is received?
Or do you suggest we poll each queue in turn to see which might have a message on it?
I am looking for something like a callback-function: To register a callback function for each queue, which would be called the moment a message arrives. Is that how MQGET works?
Yep, found those links already, thanks.
Anyone knows what is included in the MQ developer's license? More documentation? Keyring perhaps? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 11, 2006 6:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mgerben wrote: |
| Thanks all for the answers and not flaming one who hasn't read the manual. |
That's in 3 -5 dumb question's time. We're a tolerant crowd.... 
| mgerben wrote: |
No need. I'd like the program to respond to any message, not wait untill all queues have a message on them. We're still talking about the same thing? |
Nope - the function you're describing implies that a single call is waiting for any message to arrive on 1-n queues. Each call can wait on a single queue only.
| mgerben wrote: |
does the MQGET call not block itself untill a message is received?
Or do you suggest we poll each queue in turn to see which might have a message on it? |
Each call is blocking, but there's a programmable wait period. I'm suggesting (but not proposing) the latter.
| mgerben wrote: |
| I am looking for something like a callback-function: To register a callback function for each queue, which would be called the moment a message arrives. Is that how MQGET works? |
No.
But you could write some kind of multi-threaded app which spawns as many children as it needs and waits for one of them to return asyncronously. Again, this is not a design proposition but an alternative to the looping outlined above.
The closest you can get to the "callback" function you describe is to get MQ to call your program once a message arrives. Look up "Triggering" in the documentation.
| mgerben wrote: |
Yep, found those links already, thanks.
Anyone knows what is included in the MQ developer's license? More documentation? Keyring perhaps? |
If there's a keyring going I want one! Those links contain the sum total of the documentation, though there are various other sample code / redbook resources at points on ibm.com & other the likely places.
Licensing questions are best directed at your IBM rep.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mgerben |
| Posted: Wed Oct 11, 2006 6:33 am Post subject: |
|
|
Newbie
Joined: 10 Oct 2006
Posts: 3
|
| Quote: |
Nope - the function you're describing implies that a single call is waiting for any message to arrive on 1-n queues. Each call can wait on a single queue only.
Each call is blocking, but there's a programmable wait period. I'm suggesting (but not proposing) the latter.
| mgerben wrote: |
| callback-function: which would be called the moment a message arrives. Is that how MQGET works? |
No.
|
Ai.
Are you familiar with the ACE library?
I was looking for a similar approach where you register all the events you want to handle at a central reactor, and then the main-loop goes on to call the reactor - indefinitely.
The reactor then fires off callback calls to the appropriate registered object when a new event arrives.
So in ACE, each socket you open is represented by one object of a class 'Socket', and that object is called when anything happens on that socket.
Very nice, when your program can handle one socket, it can handle n sockets - just create more socket-objects.
So, nothing like that, eh?
What is the MQ paradigm then? Is one program supposed to have only one input-queue?
Last edited by mgerben on Wed Oct 11, 2006 6:58 am; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 11, 2006 6:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| mgerben wrote: |
| What is the MQ paradigm then? Is one program supposed to have only one input-queue? |
Why would it need more?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 11, 2006 6:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I have no knowledge of this ACE product of which you speak.
One program tends to have one input queue, though that input queue is not necessarially fixed at design time and may not be exclusive to that program. This program processes the input queue until all messages are consumed, doing what needs doing (which may be putting 1-n messages on other queues) then ending in whatever manner is best for the design.
IMHO MQ provides significant benefits over socket based communication (detailed in many IBM documents!  ) and as such can be forgiven any minor functionality oversights. I've not found myself thinking "I wish MQ could .... " on any occassion that springs to mind.
Maybe I've been fortunate to have simple requirements...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Oct 11, 2006 6:49 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mgerben wrote: |
| But - this is where my lack of MQ knowledge shows - does the MQGET call not block itself untill a message is received? |
Time to read the manual, in particular the early chapters of the Application Programming Guide and the section on MQGET in the Application Programming Reference.
MQGET blocks for as long as you ask it to.
| Quote: |
| Or do you suggest we poll each queue in turn to see which might have a message on it? |
Totally your decision. The callback behaviour you desire is provided in the IBM's XMS C/C++ libraries. These are available for free download, and are fully supported for production use. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 11, 2006 6:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mvic wrote: |
| Totally your decision. The callback behaviour you desire is provided in the IBM's XMS C/C++ libraries. These are available for free download, and are fully supported for production use. |
And to forestall the next likely question:
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0509_phillips/0509_phillips.html
You'll notice the article describes itself as "intermediate". If you're at an early stage of familiarity with MQ I'd recommend you get your feet wet with the base product before using it. Unless you're good with JMS in which case dive right in!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
