Author |
Message
|
Vin |
Posted: Wed Mar 27, 2002 4:47 pm Post subject: |
|
|
Master
Joined: 25 Mar 2002 Posts: 212 Location: India
|
Is it possible for setting up a listener using MQ Java similar to what JMS can do with the MessageListener Interface? If so could anyone point me to a code sample? Thanks for the help |
|
Back to top |
|
 |
mqonnet |
Posted: Wed Mar 27, 2002 5:51 pm Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
|
Back to top |
|
 |
mqonnet |
Posted: Wed Mar 27, 2002 5:52 pm Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Is it possible for setting up a listener using MQ Java similar to what JMS can do with the MessageListener Interface? If so could anyone point me to a code sample? Thanks for the help
---If you mean writing a listener program, you sure can. Check out some of the sample programs in this forum. Listener is nothing but an app waiting on an MQGET. You can write your own program using an MQGET call with a specified wait interval.
Cheers.
Kumar
_________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
Vin |
Posted: Wed Mar 27, 2002 8:43 pm Post subject: |
|
|
Master
Joined: 25 Mar 2002 Posts: 212 Location: India
|
Thanks for the input. If I put a listener with a timeout on a MQGET call won't the listener die after the specified time interval? I mean the purpose to serve is simply to get the messages as soon as they arrive on the queue. Is this something which can be done with MQGET with a timeout? Can you explain me more about this? Thanks. |
|
Back to top |
|
 |
mqonnet |
Posted: Thu Mar 28, 2002 5:22 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
You could always use polling method. Which means you would be setting a very short timeout interval for the get and MQGET call is repeatedly called. Whenever there is a message, it will pick up, process and then again wait for the next message. The only way to end this program would be to Physically terminate or add options such as qmgr_shutdown and likes.
Cheers.
Kumar
_________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
Vin |
Posted: Thu Mar 28, 2002 7:01 pm Post subject: |
|
|
Master
Joined: 25 Mar 2002 Posts: 212 Location: India
|
Thanks for the tip! would polling not eat away the CPU time. I mean what about the performance for this application, do you think it's going to be okay? appreciate your time. |
|
Back to top |
|
 |
mqonnet |
Posted: Fri Mar 29, 2002 5:04 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Since you know the theory behind polling you would think that it would consume lot of cpu time. But did you ever give a thought as to what is a listener(runmqlsr). Sure is nothing but near to polling mechanism only.
As for cpu usage is concerned, since it is only one process doing gets all the time and NOT processing any message until arrived, i think it should be just fine.
Cheers.
Kumar
_________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
StefanSievert |
Posted: Fri Mar 29, 2002 10:43 pm Post subject: |
|
|
 Partisan
Joined: 28 Oct 2001 Posts: 333 Location: San Francisco
|
The mechanism you select will probably need to be based on some criteria that you have to define for yourself, like:
1/ what is your expected message arrival rate?
2/ are you waiting for a reply to a request you sent? (dialog style appl.)
3/ what environment are you running in?
and so forth.
If you have 10 messages/day you might not want to have your message consumer process (listener has a different meaning in MQ) hanging around eating resources all day long. And you might want to think of memory more than just CPU time. Each process that is connected to MQ not only uses process memory all by itself, it also causes MQ server resources to be allocated. In this scenario, triggering the message consumer upon arrival is probably the way to go. The application then should process the queue in a loop until there are no more messages coming in for a while, then MQCLOSE and MQDISC and bye bye until the next message comes in.
On the other hand, if you expect 10 messages/second, the cost of terminating and restarting your consumer process for every message is fairly obviously to be avoided.
If you have a request-reply scenario, you might have no choice but doing an MQGET on the requesting end with a certain wait interval because your applcation probably needs the reply for further processing. In this case, you would need to decide what to do, if the reply doesn't show up after the wait interval has expired. Wait a little longer? Tell the user to try again later? What to do with the reply message once it shows up (an hour?) later? Again, it all depends on YOUR business scenario, there is no hard and fast rule to this.
On the receiving end you will probably have a long running server program, because response time in request-reply applications is typically critical and you want to have messages processed as quickly as possible.
And again, recommended reading: Part 1 of the Application Programming Guide about "Designing applications that use MQSeries", available at http://www-3.ibm.com/software/ts/mqseries/library/manualsa/csqzal05/csqzal05tfrm.htm
Stefan
_________________ Stefan Sievert
IBM Certified * WebSphere MQ |
|
Back to top |
|
 |
Vin |
Posted: Sun Mar 31, 2002 10:51 pm Post subject: |
|
|
Master
Joined: 25 Mar 2002 Posts: 212 Location: India
|
Stefan,
Lets take a scenario where in there a group of messages comming in and have to processed all at once. I set up a listener on the recieving end and after I get all the messages, invoke an API which will process the messages and put a reply on some other queue. After this group of messages are processed there is an other group of messages comming in probably in a short/long interval of time. The problem is If I put a listener am I not waiting for messages until the next group arrives probably after a long time? Is this the right design, I mean how do you think this can be programmed in a more effective way? Let me know your thoughts.Thanks. |
|
Back to top |
|
 |
|