| Author |
Message
|
| tczielke |
 Posted: Fri Jul 01, 2016 12:00 pm Post subject: JMSXGroupId not "sticky" for MQ |
 |
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
I am working through some samples in a "Java Message Service" book, and I ran across something interesting. I am parallel testing the samples against IBM MQ 8.0.0.4 and ActiveMQ 5.3.12 on Linux SLES 11.
The book has this blurb about JMSXGroupId:
"When the JMSXGroupId property is set, the JMS provider will look for a consumer that has that group ID assigned to it. If there are no consumers assigned to that groupo, the JMS provider will pick one based on its load balancing scheme and assign it the group ID. From that point on, only that consumer will receive the messages associated with that group."
The book has a sample JMSSender and JMSReceiver program to demonstrate sending messages in a group. The JMSSender program will send 5 messages that each have JMSXGroupID property of GROUP1. The JMSReceiver program will process the 5 messages as a group.
When there are two simultaneous JMSReceiver programs with IBM MQ as the JMS service provider and I run the JMSSender program, not all of the 5 messages "stick" to one receiver. Instead most go to one receiver, but the other receiver will receive 1-2 messages.
When there are two simultaneous JMSReceiver programs with ActiveMQ as the JMS service provider and I run the JMSSender program, all of the 5 messages "stick" to one receiver.
This seems like a bug with IBM MQ. However, before I open a PMR, does anyone have any insight into what I am observing?
_________________
Working with MQ since 2010. |
|
| Back to top |
|
 |
| hughson |
| Posted: Fri Jul 01, 2016 12:28 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1948
Location: Bay of Plenty, New Zealand
|
Sounds like the JMSReceiver program is not using first in group. Don't know whether that is a coding issue in the sample or the JMS layer. If you look at the API trace can you see what MQI options are in use as a result of the JMS program doing the MQGETs?
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| tczielke |
| Posted: Sat Jul 02, 2016 7:40 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
I changed the JMSSender sample to send 12 messages to have a little better use case. The MQ run resulted in messages going to both JMSReceiver processes. The ActiveMQ run resulted in all 12 messages going to one of the JMSReceiver processes.
Here are the open and get options that were found in the strmqtrc API trace of the two JMSReceiver processes:
Options=MQOO_BROWSE
Options=MQOO_FAIL_IF_QUIESCING
Options=MQOO_INPUT_AS_Q_DEF
Options=MQOO_INQUIRE
Options=MQGMO_FAIL_IF_QUIESCING
Options=MQGMO_PROPERTIES_FORCE_MQRFH2
Options=MQGMO_SYNCPOINT
So I don't see any group options being set in the JMSReceiver processes.
I looked at what the JMS 2.0 specification doc says about JMSXGroupId and it is extremely terse. I definitely did not get anything as specific as what this JMS book listed below for the JMSXGroupId:
"When the JMSXGroupId property is set, the JMS provider will look for a consumer that has that group ID assigned to it. If there are no consumers assigned to that group, the JMS provider will pick one based on its load balancing scheme and assign it the group ID. From that point on, only that consumer will receive the messages associated with that group."
To me, what IBM is doing does not match the spirit of the JMSXGroupId specification, but the specification is so vague that there is plenty of wiggle room to support what IBM is doing.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| hughson |
| Posted: Sat Jul 02, 2016 6:26 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1948
Location: Bay of Plenty, New Zealand
|
Agreed, looks like no attempt is made to used grouped messages correctly in the JMS layer. Suggest you raise it with IBM for defect support.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Jul 21, 2016 6:34 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
To close the loop on this thread, here was the response from IBM for the PMR question I raised about JMSXGroupId:
| Quote: |
. . . on your question about the JMS message property:
JMSXGroupId
As you have observed Tim, the WebSphere MQ classes for JMS does not use
this property in the 'sticky' consumer mechanism as described in your book.
The reason for this is that the WebSphere MQ classes for JMS has not
implemented the intended function for this "JMSXGroupId" message
property. If you examine table 3.3 of the JMS 2.0a specification you
will note that this is an optional part of the JMS specification, which
to date IBM has not chosen to implement.
If you feel that this function would be useful to your application,
then I would encourage the raising of an RFE for consideration in a
future release of WebSphere MQ."
|
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jul 21, 2016 12:47 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1948
Location: Bay of Plenty, New Zealand
|
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Jul 21, 2016 1:56 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jul 21, 2016 4:57 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1948
Location: Bay of Plenty, New Zealand
|
Maybe it's supported by XMS but not JMS? (Since that's in an XMS section of KC)
Might be worth asking in the PMRS.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 22, 2016 4:36 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20729
Location: LI,NY
|
| hughson wrote: |
Maybe it's supported by XMS but not JMS? (Since that's in an XMS section of KC)
Might be worth asking in the PMRS.
Cheers
Morag |
I read that to mean that the fields are supported, not that the automatic selection on them is being done. As stated that is an optional part of the JMS Spec that has not yet been implemented.
What does that mean? Well if you deal in message grouping, you need to set a selector on your consumer and select on last in group to then have an other consumer that you set up with the proper selector for the group to pick up messages from first to before last and set up the content...
In other words you need to program it yourself.
Remember if using a transacted session to correctly set the transaction borders.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| tczielke |
| Posted: Tue Mar 28, 2017 3:16 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
So I happened to be reading the JMS 2.0 specification, and I came across the part where it talks about the JMSXGroupId. It does indeed specify this field as optional in the table of JMSX fields. However, if you read a little further it explicitly says this:
| Quote: |
| JMSXGroupID and JMSXGroupSeq are standard properties clients should use if they want to group messages. All providers must support them. |
"All providers must support them" seems pretty explicit that IBM does need to support this. This is also consistent with what I read in my JMS book. I think the optional part in the table is just a typo.
I don't really care about this (until one of our JMS developers needs it), but it seems to me that the JMSXGroupId is a required property to support for a JMS provider.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 29, 2017 4:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
What the PMR says is that the MQ JMS client libraries don't support the sticky part, not that the MQ JMS provider doesn't...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| tczielke |
| Posted: Wed Mar 29, 2017 4:51 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
That's not the response I got back from IBM in the PMR. My understanding is that they are saying that the IBM MQ JMS provider does not support JMSXGroupId, because it is optional.
| Quote: |
As you have observed Tim, the WebSphere MQ classes for JMS does not use
this property in the 'sticky' consumer mechanism as described in your
book.
The reason for this is that the WebSphere MQ classes for JMS has not
implemented the intended function for this "JMSXGroupId" message
property. If you examine table 3.3 of the JMS 2.0a specification you
will note that this is an optional part of the JMS specification, which
to date IBM has not chosen to implement.
If you feel that this function would be useful to your application,
then I would encourage the raising of an RFE for consideration in a
future release of WebSphere MQ. |
IBM refers to the table that does clearly call the JMSXGroupId as optional. However, that same section more explicitly contradicts the optional statement, and calls the JMSXGroupId out as mandatory. Not sure if you can do this, but I am going to see if I can follow up with the people that support the JMS specifications to see if they can correct the contradiction in their specification. When I read the specification, it seems pretty obvious to me that they meant for the JMSXGroupId to be mandartory, and they have a misprint in their table.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 29, 2017 5:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| tczielke wrote: |
That's not the response I got back from IBM in the PMR. My understanding is that they are saying that the IBM MQ JMS provider does not support JMSXGroupId, because it is optional.
| Quote: |
As you have observed Tim, the WebSphere MQ classes for JMS does not use
this property in the 'sticky' consumer mechanism as described in your
book. |
|
Unless I'm remembering wrong, the WebSphere MQ classes for JMS are the client classes, and have nothing to do with what the MQ pub/sub or queue mechanism does.
So, again... MQ server - pub/sub or plain queue - probably does support groupId - certainly it does for straight queue, and probably does for pub/sub. It is required by the standard that the JMS provider - the queue manager in this case - supports these properties. THe JMSProvider class is not, I believe, the actual JMS provider.
But the JMS classes don't expose this, because it is optional for JMS clients.
But this is something that should be confirmed through your PMR - what counts as a JMSProvider here, and whether the MQ JMS infrastructure supports the required features.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Mar 30, 2017 4:25 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
In my mind, the IBM MQ Classes for JMS working in conjunction with the queue manager are the JMS provider for IBM MQ. But maybe some of this comes down to semantics.
I did follow up with the JMS specification group, and got back a clarification to the contradiction I was seeing in the specification for JMSXGroupId.
https://java.net/jira/browse/JMS_SPEC-179
It's actually the table that says that JMSXGroupId is optional for the JMS provider to support that is correct, and the more explict statement "JMSXGroupID and JMSXGroupSeq are standard properties clients should use if they want to group messages. All providers must support them." is incorrect or a bug in the documentation. It sounds like this documentation error will be fixed at some later release of the JMS specification.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Dec 22, 2017 5:04 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
I recently was looking at the supported JMSX properties that the IBM MQ JMS service provider returns when you use a method like ConnectionMetaData metadata.getJMSXPropertyNames(), and I was surprised to find that they do return the JMSXGroupID and JMSXGroupSeq properties as supported by their JMS service provider.
Since this contradicted the information I got from IBM in my previous PMR that IBM does not support them, I followed up with another PMR. The information I got back this time from IBM is that the JMSXGroupID and JMSXGroupSeq properties are supported by IBM, but implemented in a way where the values are just passed along to the consumer. So there is no other functionality like sending multiple messages with the same JMSXGroupId to a unique consumer.
Personally, I find this implementation functionally useless, but I did want to update this thread with the new information I received from IBM in regards to IBM's support of these two JMSX group properties.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
|
|
