Author |
Message
|
SAFraser |
Posted: Mon Apr 04, 2011 9:57 am Post subject: More GETs than PUTs |
|
|
 Shaman
Joined: 22 Oct 2003 Posts: 742 Location: Austin, Texas, USA
|
I searched a bit and didn't see anything that helps. I feel like I ought to be able to explain this, but I cannot.
We have an application that uses a WAS 7.0 MDB with listener port to consume messages. The number of GETs slightly exceeds the number of PUTs. Example:
Code: |
PUTs GETs
7:00 AM 23 23
8:00 AM 52 53
9:00 AM 83 85
10:00 AM 72 76
11:00 AM 86 95
12:00 PM 34 35
|
My only theory: The MDB is rolling the message back to the input queue for some reason, then processing the message properly on the second try. If it were a poison message, the listener port would shut down (as message retry is set to 0).
Does that theory make sense? Please, what else might it be? |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Apr 04, 2011 9:59 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9472 Location: US: west coast, almost. Otherwise, enroute.
|
Any messages discarded? _________________ 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 |
|
 |
SAFraser |
Posted: Mon Apr 04, 2011 10:10 am Post subject: |
|
|
 Shaman
Joined: 22 Oct 2003 Posts: 742 Location: Austin, Texas, USA
|
Not sure what you mean by discarded....? If you mean, do any of the messages expire? Supposedly not. And if they did, the disparity would be the other way round, right? More PUTs than GETs?
I bet I am not understanding your question.  |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Apr 04, 2011 10:29 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9472 Location: US: west coast, almost. Otherwise, enroute.
|
Discarded by the app as not meeting business process requirements. _________________ 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 |
|
 |
SAFraser |
Posted: Mon Apr 04, 2011 11:01 am Post subject: |
|
|
 Shaman
Joined: 22 Oct 2003 Posts: 742 Location: Austin, Texas, USA
|
My understanding is that the application either processes the data or writes an exception to a database for further processing. According to the development team, all messages are handled.
There is a controversy at the moment about "lost data" in this application (which I didn't mention in my first post as it did not occur to me it might be related). The application producing the data claims it is sending certain updates that the receiving application never posts to its database. I am actually about it implement a temporary build that will duplicate the input messages so they can be inspected to see if the transactions have gone missing at the producer end or the consumer end.
If it did discard a message (and I presume we are talking about the GET), how might that impact the PUT and GET counts?
Thanks, Bruce, for thinking about this. |
|
Back to top |
|
 |
exerk |
Posted: Mon Apr 04, 2011 12:35 pm Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
If you're at WMQ V7.0 you might want to think about temporarily duplicating the messages (good old pub/sub!) to 'trap' the so-called missing messages  _________________ 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 |
|
 |
SAFraser |
Posted: Mon Apr 04, 2011 12:41 pm Post subject: |
|
|
 Shaman
Joined: 22 Oct 2003 Posts: 742 Location: Austin, Texas, USA
|
Even easier for me.... since we already have WMB, I made a message flow with two output nodes wired to a single input node. All I have to do is create a couple of extra queues and change the base queue name in the jndi definition of the queue on which the receiving app is listening.
It worked a treat in our MQ unit test environment. The development teams are now arguing about where and when I can deploy it. <sigh>
It didn't occur to me to use pub/sub. If all you know how to use is a hammer, every problem is a nail, blah blah. |
|
Back to top |
|
 |
exerk |
Posted: Mon Apr 04, 2011 12:45 pm Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
SAFraser wrote: |
...It didn't occur to me to use pub/sub. If all you know how to use is a hammer, every problem is a nail, blah blah. |
You'd have made a wonderful heavy engineer.....sigh. _________________ 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: Mon Apr 04, 2011 12:48 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Someone else browsing the queue could drive the MQGET counts higher. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Apr 04, 2011 12:50 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
SAFraser wrote: |
If it did discard a message (and I presume we are talking about the GET), how might that impact the PUT and GET counts? |
The app does the MQGET, the count goes up as it should, and the app chucks the data instead of sticking it in the DB, or doing whatever else it was supposed to do with it. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Apr 04, 2011 12:59 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9472 Location: US: west coast, almost. Otherwise, enroute.
|
Quote: |
If it did discard a message (and I presume we are talking about the GET), how might that impact the PUT and GET counts? |
I'm presuming that the message get is the first event, followed by the db update, followed by the confirming put.
Thus, if the app discards the message after the mqget, there would be no msg put. In your stats, gets are always higher than puts. _________________ 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 |
|
 |
SAFraser |
Posted: Mon Apr 04, 2011 1:19 pm Post subject: |
|
|
 Shaman
Joined: 22 Oct 2003 Posts: 742 Location: Austin, Texas, USA
|
Browsing a queue does not increase the dequeue count as far as I can tell. I just tested it to be sure. I stand ready to be corrected. (Which is how I always stand whenever I post to this forum.)
Please see my original post! I posted stats from a single queue.
First the PUT, then the GET.
I am not asking about two different queues. I am asking about the enqueue count and the dequeue count on a single queue. "What situation would cause the dequeue count to be greater than the enqueue count?"
We have seen these types of counts where input messages are backed out. Backing a message out to the original input queue does not appear to increase the enqueue count. But when the application does a new GET, it does (of course) increase the dequeue count.
Any other way this could happen? is what we are wondering..... |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Apr 04, 2011 1:34 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
MO71 does the puts and browses.
QPASA shows the enque and deque counts
Linux QM is MQ 6.0.2.8
z/OS QM is MQ 7
On Linux, the browse does not drive up the deque count.
On z/OS, it does!  _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mvic |
Posted: Mon Apr 04, 2011 2:01 pm Post subject: |
|
|
 Jedi
Joined: 09 Mar 2004 Posts: 2080
|
SAFraser wrote: |
I am not asking about two different queues. I am asking about the enqueue count and the dequeue count on a single queue. "What situation would cause the dequeue count to be greater than the enqueue count?" |
Hi, Your OP said PUTs and GETs, not enqueues and dequeues.
If any of the GETs returned MQCC_FAILED, then it did not dequeue a message.
Please can you clarify whether every GET returned either MQCC_OK or MQCC_WARNING? |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Apr 04, 2011 5:06 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
PeterPotkay wrote: |
SAFraser wrote: |
If it did discard a message (and I presume we are talking about the GET), how might that impact the PUT and GET counts? |
The app does the MQGET, the count goes up as it should, and the app chucks the data instead of sticking it in the DB, or doing whatever else it was supposed to do with it. |
JMS is a little bit tricky. If you read the message (i.e. you get a dequeue) but roll back the unit of work the number of enqueues stays put but you still have a dequeue for that message. When you then reprocess the message you have another dequeue and a commit. So for one enqueue you end up having 2 dequeues... That's AFAIK. You'd have to check through experimentation.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
|