|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
![Reply to topic](templates/DAJ_Glass/images/lang_english/reply.gif) |
|
JMS application and channel message count |
« View previous topic :: View next topic » |
Author |
Message
|
zpat |
Posted: Tue Aug 03, 2021 4:59 am Post subject: JMS application and channel message count |
|
|
![](images/avatars/200698233754e3c3649f6d0.jpg) Jedi Council
Joined: 19 May 2001 Posts: 5849 Location: UK
|
We have a JMS application and it needs to read a queue. It has no need to filter or select messages. I do not have access to the source code.
Observing the channel status I can see it making two svrconn connections and the message count on one of those, after reading 80k messages, is 80k. The other connection has a message count of slightly more than 80k.
Seems to me it is performing two MQI calls for each message.
Is this likely to be caused by using a JMS selector? Presumably if they stop doing that it would be more efficient?
It's written by a third-party who (as usual these days) has little knowledge of MQ (or even JMS).
MQ client v914 on Linux. QM is z/OS v9.0.0
I would run an AAT but such things do not exist on z/OS MQ. _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
hughson |
Posted: Wed Aug 04, 2021 12:56 am Post subject: |
|
|
![](images/avatars/810794940518bb946528b3.jpg) Padawan
Joined: 09 May 2013 Posts: 1916 Location: Bay of Plenty, New Zealand
|
There are other things you can look at to try and figure out what this application is doing on each connection. I would start with a DISPLAY CONN(*) TYPE(ALL) ALL WHERE(CHANNEL EQ channel-name) and pluck out the two connections.
Look at the object handles on each connection and see what OPENOPTS are in use - one hopes you'll see MQOO_INPUT_* on one of them. It might have another queue open which would account for the rest of the API calls.
Look also at the CHSTATUS, and check out the BYTSSENT and BYTSRCVD fields on both connections - is one bigger than the other? i.e. is more data going in one direction than the other - for both connections?
To answer your explicit questions, a JMS Selector should map exactly to an MQ selector (these days) so I would not expect that to add an extra API call.
Generally speaking with a JMS application you have one MQ connection to the queue manager for the JMSConnection, and one MQ connection for the JMSSession. The JMSSession will be the one with the 80k messages got off the queue. Generally speaking I thought that not much went on, on the JMSConnection.
Feel free to post the output from the above commands for us all to pore over.
Is there anything you know about this application apart from that it is JMS and that it reads from a queue?
Cheers,
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Wed Aug 04, 2021 5:20 am Post subject: Re: JMS application and channel message count |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9405 Location: US: west coast, almost. Otherwise, enroute.
|
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
markt |
Posted: Wed Aug 04, 2021 7:50 am Post subject: |
|
|
![](images/avatars/519b992c426bb0c8eac47.jpg) Knight
Joined: 14 May 2002 Posts: 504
|
Number of "messages" on a SVRCONN CHSTATUS is actually the number of MQI calls. Not the number of got or put messages.
So my initial thought was that you were seeing the results of an MQGET+MQCMIT. Though I'd expect those to all be against the same hConn, assuming(!) there's not something like a pooling model with two equivalent consumers where either could be getting the message.
Another thought was that you're using one of the dispatching listener approaches. Was it ActivationSpecs in some AppServer environments? Those would typically do a BROWSE in one Connection and hand off the destructive GET to another Connection.
There are some heuristics where an early JMS "GET" might result in several MQI GETs as buffer sizes adjust but those should very rapidly stabilise.
In any case, the GTF would give one way of seeing what the app is doing. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
zpat |
Posted: Wed Aug 04, 2021 10:33 pm Post subject: |
|
|
![](images/avatars/200698233754e3c3649f6d0.jpg) Jedi Council
Joined: 19 May 2001 Posts: 5849 Location: UK
|
Thanks for ideas, I will look into it further.
Other than it uses JMS to receive messages from a queue (which are then destined for Kafka), I know nothing about the app.
I can see from the queue status that it has the queue open for shared input and browse on both handles. _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
zpat |
Posted: Thu Aug 12, 2021 5:24 am Post subject: |
|
|
![](images/avatars/200698233754e3c3649f6d0.jpg) Jedi Council
Joined: 19 May 2001 Posts: 5849 Location: UK
|
They are using Spring JMS.
They forgot to remove the "default" listener in whatever code they based it on. Now they have only one connection with two conversations on it.
The message count is still double the messages read. They seem to be using transacted sessions, so may well be MQGET and MQCMIT for each one.
How inefficient is that (for NP messages)? Is it worth the hassle of trying to get them to commit every "n" messages?
Can't see an obvious way to make Spring JMS do that.
I have questioned whether they actually benefit from a transacted session given that it seems to commit immediately after getting the message (before processing it) - in fact they don't seem to have any commit logic in their code - appears that Spring is doing it for them. _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
|
|
![Reply to topic](templates/DAJ_Glass/images/lang_english/reply.gif) |
|
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
|
|
|
|