| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Delays using Selectors in MQv6 |
« View previous topic :: View next topic » |
| Author |
Message
|
| jan.taralczak |
 Posted: Thu Jul 24, 2008 10:53 pm Post subject: Delays using Selectors in MQv6 |
 |
|
Newbie
Joined: 24 Jul 2008
Posts: 5
|
Since migration from MQv5.3 to MQv6 Solaris10 I observe 5s delays in queueReceiver.receive(timeoutMs) having a queueReceiver with selector, e.g. JMSCorrelationID like ...%. The QCF options setPollingInterval(100); setRescanInterval(100); do not help.
Further findings:
- same behaviour for client and bindings mode
- no 5s delays observed when the reply queue CURDEPTH is less than 2
- replacing MQv6 com.ibm.mqjms.jar by the one from MQv5.3 distribution solves the problem
An interesting workaround: the 5s delay can be reduced when I submit 2 subsequent receive calls on the queue receiver object. The first with fixed timeout 100ms returns nothing, the second returns the reply message within less than 200ms.
It looks to me like some selector initialisation problem in MQv6. Did anybody observe similar performance issues with MQv6? |
|
| Back to top |
|
 |
| jan.taralczak |
| Posted: Sun Jul 27, 2008 10:47 pm Post subject: Enabling MQ-Trace revokes the 5s delay bug |
|
|
Newbie
Joined: 24 Jul 2008
Posts: 5
|
Adding the following MQ-Trace statement eliminates the 5s delays 
| Code: |
| MQEnvironment.enableTracing(1, System.out); |
Here is the proof:
| Quote: |
# time test40getWithMQtrace
real 0m8.205s
user 0m6.844s
sys 0m1.493s
# time test40get
real 3m26.250s
user 0m5.226s
sys 0m1.205s
|
It clearly looks like a bug in JMS MQv6 to me. What is your opinion? |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Jul 27, 2008 11:09 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
You may wish to condiser migrating to MQ v7.0, as MQ selector processing has been moved from the Java / JMS MQ layer into the queue manager, giving a boost to performance. There is no longer any need to the client side jars to poll or rescan the queue, the queue manager now just delivers the matching messages for asynchronous consumption on demand.
_________________
Glenn |
|
| Back to top |
|
|
| jan.taralczak |
| Posted: Mon Jul 28, 2008 10:15 pm Post subject: Tuning socket parameters in MQv6 |
|
|
Newbie
Joined: 24 Jul 2008
Posts: 5
|
This is the stack trace where JMS MQv6 Solaris 10 hangs for up to 5s using selector JMSCorrelationID like ...% if there is at least one message in the queue with an empty CorrelationID.
| Code: |
SocketInputStream.socketRead0(FileDescriptor, byte[], int, int, int) line: not available [native method]
SocketInputStream.read(byte[], int, int) line: 155
BufferedInputStream.fill() line: 229
BufferedInputStream.read1(byte[], int, int) line: 267
BufferedInputStream.read(byte[], int, int) line: 324
DataInputStream.readFully(byte[], int, int) line: 202
DataInputStream.readInt() line: 380
MQv6InternalCommunications(MQInternalCommunications).timedReadInt(int) line: 2748
MQv6InternalCommunications(MQInternalCommunications).receiveBytesFaster(Pint, Pint, Pint) line: 2846
MQv6InternalCommunications(MQInternalCommunications).receive(Pint, Pint, Pint) line: 1179
MQSESSIONClient.lowLevelComms(Pint, Pint, Pint, byte[], byte[], int, byte[]) line: 2841
MQSESSIONClient.MQGET(int, int, MQMsg2, MQGetMessageOptions, int, byte[], Pint, Pint, Pint) line: 1852
MQSPIQueue(MQQueue).getMsg2Int(MQMsg2, MQGetMessageOptions, Pint, Pint, int) line: 1217
MQSPIQueue(MQQueue).getMsg2(MQMsg2, MQGetMessageOptions) line: 1074
MQQueueReceiver(MQMessageConsumer).getMessage(long) line: 3402
MQQueueReceiver(MQMessageConsumer).receiveInternal(long) line: 2817
MQQueueReceiver(MQMessageConsumer).receive(long) line: 2620 |
I suspect an internal JMS library synchronisation hazard related to the MQv6InternalCommunications.receiveBytesFaster() method method and sockets on Solaris 10. Possibly enabling the MQ trace just slows down a bit the processing and thus helps to avoid the hazard that ends up in blocking for 5s.
Unfortunately the migration to MQv7 is not an option for our project. BTW: Can somebody give me a hint how to tune socket parameters in MQv6 using JMS? |
|
| Back to top |
|
|
| JLRowe |
| Posted: Tue Jul 29, 2008 5:19 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
run your code on a 486, that will slow it down
no seriously, you could try using the v7 client jars with a v6 queue manager, i'm pretty sure they are backwards compatible - as long as you do not use v7 features. There has been a major re-write of both the client and server side in v7.
I would look at the scan interval settings again, especially since you said 2 consective gets eliminate the problem. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jul 29, 2008 2:08 pm Post subject: Re: Tuning socket parameters in MQv6 |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jan.taralczak wrote: |
This is the stack trace where JMS MQv6 Solaris 10 hangs for up to 5s using selector JMSCorrelationID like ...% if there is at least one message in the queue with an empty CorrelationID.
|
I would also seriously question the reason why you are using a selector if you don't care about the correlId. Anyways best practice says to always use the provider form of the correlId with IBM.
String id = String.replicate(0,48 );
String mycorrelid = "'ID:+ id + "'";
String selector = "JMSCorrelationID = " + mycorrelid;
and this will match an empty correlation id.
If you don't care about the correlation simply drop the selector!
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jan.taralczak |
| Posted: Tue Jul 29, 2008 10:17 pm Post subject: Re: Tuning socket parameters in MQv6 |
|
|
Newbie
Joined: 24 Jul 2008
Posts: 5
|
| Quote: |
| I would also seriously question the reason why you are using a selector if you don't care about the correlId. |
Of course we do require correlId matching. This is a standard feature from MQ that should also work properly if there are a few non-matching reply messages on the reply queue. This works fine for the JMS library from MQv5 but not using the one from MQv6.
In this test-scenario a single message with a non-matching correlId, i.e. zero correlId created with the AMQSPUT sample from the MQv6 distribution dramatically reduces the receiver performance for matching correlId requests from a few milliseconds to 5s.
Note: this test-scenario just illustrates the malicious behavior of the MQ JMS functionality we relay on. |
|
| Back to top |
|
|
| jan.taralczak |
| Posted: Mon Nov 24, 2008 1:42 am Post subject: Delays using Selectors in MQv6 - Solution/Workaround |
|
|
Newbie
Joined: 24 Jul 2008
Posts: 5
|
Changing to an alternative internal selector algorithm on the reply queue fixes the problem. Since our application does not rely on the message priority, we can live with the following workaround:
Original setting: MSGDLVSQ(PRIORITY)
New setting: MSGDLVSQ(FIFO). |
|
| Back to top |
|
|
|
|
|
| |
|
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
|
|
|
|
