| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| When would you use a Custom Service? |
« View previous topic :: View next topic » |
| Author |
Message
|
| shaund |
 Posted: Tue Jan 29, 2002 4:24 am Post subject: |
 |
|
Newbie
Joined: 26 Jan 2002
Posts: 5
Location: Shaun Davey
|
We've devloped a piece of software that polls a queue continuously to see if a message is present and then processes it.
As this needs to be running all of the time that the queue manager is up, could this be installed as a NT custom service?
Are there any issues surrounding using these?
Is this really an appropriate use of a service?
Thanks in advance
Shaun |
|
| Back to top |
|
 |
| kolban |
| Posted: Tue Jan 29, 2002 8:52 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
| Sounds like an excellent use of the custom service mechanism. Are there any alternative designs to polling? That doesn't sound like its too efficient? |
|
| Back to top |
|
|
| shaund |
| Posted: Wed Jan 30, 2002 3:02 am Post subject: |
|
|
Newbie
Joined: 26 Jan 2002
Posts: 5
Location: Shaun Davey
|
As the message stream to the queue is going to be fairly consistent throughout the day, we weren't sure that using a triggered process would be any more efficient, primarily as we're only interested on starting on the first message and from then on letting it process whatever's thrown at it.
Basically the design is a straight forward request/reply model with the OS/390 clients putting to an NT Cluster which gets/process/sends back.
If we had gone for triggering, given that we can only really trigger on 1st, could we have ended up with lots of these processes hanging about - or is it just a case of writing the code so that it gets until a 2033 and then terminates?
Shaun |
|
| Back to top |
|
|
| kolban |
| Posted: Wed Jan 30, 2002 7:21 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
| Ah ... in that case use triggering. It is what it was designed for. Have the application perform a blocking MQGET and, when it gets the 2033 (no more messages), have it end. Make sure the wait time on the get is sufficiently large that your triggering app isn't continually starting/stopping. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jan 30, 2002 9:33 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Polling is not always the right design for MQSeries.
I prefer a long-running task (or tasks) which have outstanding MQGETs with WAIT specified. That way they wait until a message arrives and then immediately deal with it. You might have a wait interval of 60 seconds so that you can check for "application closedown" requests now and then (before re-issuing the MQGET with wait).
If you poll - then you introduce latency since if a message arrives it won't get picked up until the next MQGET is performed. Whereas an outstanding MQGET will get it without any delay as MQSeries will terminate the wait immediately there is a message for availabe for you.
Also MQSeries QM code is now optimised to actually bypass the queue entirely if an outstanding MQGET can be satisfied when a suitable MQPUT is being executed. So the message goes directly from the MQPUT app to the MQGET app for speed.
Event driven (not polling) is the way to go - also works on remote queue managers using MQClients, whereas polling would saturate the network with client MQI messages. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
