| Author |
Message
|
| prKinch |
 Posted: Sun Jan 31, 2010 5:11 pm Post subject: What are the available ways to GET the msgs from the Queue |
 |
|
Novice
Joined: 31 Jan 2010
Posts: 15
|
 PLease let me know, What are available ways to GET the msgs from the Queue
Like
1) Setting trigger level in the Queue and GET msgs from the Queue
2) Run a Batch job in a particular time and GET the msgs in the Queue
3) Let me know What else....
 |
|
| Back to top |
|
 |
| Vitor |
| Posted: Sun Jan 31, 2010 6:03 pm Post subject: Re: What are the available ways to GET the msgs from the Que |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| prKinch wrote: |
3) Let me know What else....
|
No, that's about it. There are an almost infinate number of variations in the way you can implement them but that's it.
Much like there are only 2 ways you can get down a road:
1) Use your feet
2) Use a vehicle
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Sun Jan 31, 2010 11:16 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I would suggest a long-running application adapter using MQGET with WAIT, is the more modern approach.
Triggering is inefficient for high-volumes as it loads the application each time (although in some cases such as CICS it can be OK).
Batch processing (or polling) has latency.
Depends if you want an immediate response or not and what the volumes are.
Goes without saying that the queue should be emptied each time. For really high volumes, you would have several instances of the adapter listening for messages. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 01, 2010 6:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| I would suggest a long-running application adapter using MQGET with WAIT, is the more modern approach. |
I would suggest this is not the case, or certainly not a general principle.
| zpat wrote: |
| Triggering is inefficient for high-volumes as it loads the application each time (although in some cases such as CICS it can be OK). |
Depends what kind of triggering you're talking about. But consider the case of a high-volume application such as you describe, which only runs for 2-3 hours a couple of times a day. Triggering might be an ideal way of starting such a thing.
| zpat wrote: |
| Batch processing (or polling) has latency. |
Not always.
| zpat wrote: |
| Depends if you want an immediate response or not and what the volumes are. |
Which goes back to my point regarding not a general case.
| zpat wrote: |
| Goes without saying that the queue should be emptied each time. For really high volumes, you would have several instances of the adapter listening for messages. |
You're talking here about an MDB model I believe. There are other scenarios.
And a queue should always be empited. Unless you're using the CICS model you describe further up the post.
Almost had a general case there... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Feb 01, 2010 7:54 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Look at WMB, with a MQINPUT node, how does that work?
It has an outstanding MQGET with WAIT on the queue all the time (or possibly uses the MQ Call Back feature in more recent versions).
Anything waiting or batch scheduled outside MQ will have latency since it won't know instantly when the initial message is available.
Loading the application on message arrival is less efficient for high frequency of arrival than keeping it memory with the queue handle open.
Genuine triggering also means using trigger messages which increases the MQI overhead.
It's not unusual for an adapter to open multiple thread handles to the same queue all of which have MQGET WAIT ready for really high volume and low latency responses.
Nothing to do with MDB as such. Doesn't even need a transaction manager to operate such a listener model.
A good example is WMB itself with message flows (MQInput) and a number of EGs and instances. It's not triggered, nor is it polling or scheduled. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 01, 2010 8:40 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I'm thinking that we've overwhelmed the author of the OP. Given that this is post #1, I'm guessing a basic tutorial on the MQ and the API calls is more in order.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| prKinch |
| Posted: Mon Feb 01, 2010 12:33 pm Post subject: Thanks |
|
|
Novice
Joined: 31 Jan 2010
Posts: 15
|
|
| Back to top |
|
|
|
|
