| Author |
Message
|
| krishna1228 |
 Posted: Wed May 29, 2013 4:41 am Post subject: Is there any way to calculate the queue depth of remoteQueue |
 |
|
Novice
Joined: 28 May 2013
Posts: 18
|
| Using java program Im trying to connect a remote Queue manager so how can i calculate the Queue depth of remote queue? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed May 29, 2013 4:45 am Post subject: Re: Is there any way to calculate the queue depth of remoteQ |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| krishna1228 wrote: |
| Using java program Im trying to connect a remote Queue manager so how can i calculate the Queue depth of remote queue? |
You don't ever ever calculate the queue depth.
You don't ever ever calculate the queue depth of remote queues. |
|
| Back to top |
|
|
| krishna1228 |
| Posted: Wed May 29, 2013 4:48 am Post subject: |
|
|
Novice
Joined: 28 May 2013
Posts: 18
|
But my requirement is to persist the messages to Hadoop after i read from MQ for that i need to know the depth of the queue to loop that may times..
Thanks in advance..... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed May 29, 2013 4:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| krishna1228 wrote: |
| But my requirement is to persist the messages to Hadoop after i read from MQ for that i need to know the depth of the queue to loop that may times.. |
No.
Your requirement is to persist all messages on the queue into Hadoop.
This does not ever require that you know anything about how many messages are on the queue.
Imagine this basic scenario. - I put one message on the queue
- You calculate the depth of the queue
- I put another message on the queue
- You start your loop
What happens?
Also, there's no way that MQ will ever let you read any messages from a QREMOTE. It simply doesn't work that way.
Talk to an MQ architect or senior developer at your local site. Read, think, try, repeat. Hire a consultant. Take training. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed May 29, 2013 4:52 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| krishna1228 wrote: |
| But my requirement is to persist the messages to Hadoop after i read from MQ for that i need to know the depth of the queue to loop that may times... |
No, you don't - just keep reading off the messages until MQRC 2033.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 29, 2013 4:53 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The depth of the queue is not a 100% indicator of how many messages are available for your program to get.
Loop until your app receives an MQ reason code that says there are no more messages available that meet your selection criteria.
DO NOT attempt to get the current q depth and loop that many times. Seriously, don't. Its a common error for people new to MQ. Its been discussed many times here.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| krishna1228 |
| Posted: Wed May 29, 2013 5:06 am Post subject: |
|
|
Novice
Joined: 28 May 2013
Posts: 18
|
| Thanks all for your valuable suggestions...... :D |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 29, 2013 5:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| krishna1228 wrote: |
| But my requirement is to persist the messages to Hadoop after i read from MQ for that i need to know the depth of the queue to loop that may times.. |
That's a very stupid requirement. You're persisting messages in Hadoop after you read them from the persistent message store (MQ) that you're paying IBM a lot of money for. Why would you want to do that? What does that get you?
And I agree with my associate; you don't need to know the depth of the queue and you need to be aware that even if you find and use one of the administrative methods to programatically obtain depth, it may not always return the result you expect.
Note also that "remote" in WMQ terms means "a queue manager your application is not connected to", which is not quite I think how you're using it. You're not wrong, but you may give WMQ-centric people here the wrong view of your topology.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
