|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
JMS selector - performance issue on deep queues |
« View previous topic :: View next topic » |
Author |
Message
|
fjb_saper |
Posted: Fri Aug 07, 2020 4:52 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 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 |
|
 |
bef1 |
Posted: Fri Aug 07, 2020 6:26 am Post subject: |
|
|
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 |
|
 |
bef1 |
Posted: Fri Aug 07, 2020 1:39 pm Post subject: |
|
|
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 |
|
 |
|
|
|
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
|
|
|
|