ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Java / JMS » JMS application and channel message count

Post new topic  Reply to topic
 JMS application and channel message count « View previous topic :: View next topic » 
Author Message
zpat
PostPosted: Tue Aug 03, 2021 4:59 am    Post subject: JMS application and channel message count Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Wed Aug 04, 2021 12:56 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Wed Aug 04, 2021 5:20 am    Post subject: Re: JMS application and channel message count Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

zpat wrote:
I would run an AAT but such things do not exist on z/OS MQ.
z/OS’s GTF (generalized trace facility) is the tool.

https://www.ibm.com/docs/en/ibm-mq/9.2?topic=trace-using-problem-determination-zos
_________________
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
View user's profile Send private message
markt
PostPosted: Wed Aug 04, 2021 7:50 am    Post subject: Reply with quote

Knight

Joined: 14 May 2002
Posts: 502

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
View user's profile Send private message
zpat
PostPosted: Wed Aug 04, 2021 10:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
zpat
PostPosted: Thu Aug 12, 2021 5:24 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Java / JMS » JMS application and channel message count
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.