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 IndexIBM MQ Java / JMSJMS selector - performance issue on deep queues

Post new topicReply to topic Goto page Previous  1, 2
JMS selector - performance issue on deep queues View previous topic :: View next topic
Author Message
fjb_saper
PostPosted: Fri Aug 07, 2020 4:52 am Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20400
Location: LI,NY

The third format you are talking about, is setting the JMS Correlation ID in the RFH header. It certainly will return you the correct message. And it will cater for a correlation Id that is over 24 bytes.
However any retrieval of a message with this type of correlation ID will not be subjected to the optimized view.

So you need to look how to fit your correlation ID into 24 bytes.
From the looks of it (dumping the '-') your correlation ID is the hex representation for 16 bytes.

What your programmer needs to do is to make that fit (padding with x00") into a String of 48 chars which is a hex representation of 24 bytes then use the "ID: ffffffffffffffffffffff...." representation to set the JMSCorrelID. This will get you the speed you're looking for without loss for precision.
Alternatively you could just turn the - into it's hex representation and use the result with "ID: ...." then read back the JMSCorrelation ID to get the 00 padded value for the selector...

The way you are setting the correlation ID now, it is longer than the byte[] field, and as such is not valid for the accelerated search function... (at least not without loss of precision...)

_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
bef1
PostPosted: Fri Aug 07, 2020 6:26 am Post subject: Reply with quote

Novice

Joined: 29 Aug 2019
Posts: 15

fjb_saper wrote:
The third format you are talking about, is setting the JMS Correlation ID in the RFH header. It certainly will return you the correct message. And it will cater for a correlation Id that is over 24 bytes.
However any retrieval of a message with this type of correlation ID will not be subjected to the optimized view.

So you need to look how to fit your correlation ID into 24 bytes.


That makes sense. We are working with the development team to try this fix in the code.

I will update this thread once the test is completed, either today or Monday.

Thanks for your input, much appreciated!
Back to top
View user's profile Send private message
bef1
PostPosted: Fri Aug 07, 2020 1:39 pm Post subject: Reply with quote

Novice

Joined: 29 Aug 2019
Posts: 15

You were all right.

Using JMSCorrelationID with the "ID:" followed by 48 hex characters switched the behavior of the MQ client.

The MQ client now copies the whole value to the MQMD CorrelID.

And then, the MQ client doesn't set a selector on the OPEN operation. Instead, it sets the selector on the REQUEST_MSGS request, using the MQMH CorrelID in place of the JMSCorrelationID.

Under the same conditions, this results in a 5 ms response time, instead of 15-20s before the fix.

Thanks to all of you who contributed to find that solution!
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum IndexIBM MQ Java / JMSJMS selector - performance issue on deep queues
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.