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 » JMSXGroupId not "sticky" for MQ

Post new topic  Reply to topic
 JMSXGroupId not "sticky" for MQ « View previous topic :: View next topic » 
Author Message
tczielke
PostPosted: Fri Jul 01, 2016 12:00 pm    Post subject: JMSXGroupId not "sticky" for MQ Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
View user's profile Send private message
hughson
PostPosted: Fri Jul 01, 2016 12:28 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
tczielke
PostPosted: Sat Jul 02, 2016 7:40 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
View user's profile Send private message
hughson
PostPosted: Sat Jul 02, 2016 6:26 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
tczielke
PostPosted: Thu Jul 21, 2016 6:34 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
View user's profile Send private message
hughson
PostPosted: Thu Jul 21, 2016 12:47 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

Well, that explains that then!
_________________
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
tczielke
PostPosted: Thu Jul 21, 2016 1:56 pm    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

The only caveat I have to the PMR reply is that this doc in the IBM MQ (formerly WebSphere MQ (formerly MQSeries)) KC seems to imply that JMSXGroupId is supported by IBM MQ.

https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.msc.doc/xms_rmes_prp_jms.htm

I have opened a feedback item (I think) to clarify that documentation, because that does not seem to be consistent with the information in the PMR.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
hughson
PostPosted: Thu Jul 21, 2016 4:57 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Fri Jul 22, 2016 4:36 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20695
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
View user's profile Send private message Send e-mail
tczielke
PostPosted: Tue Mar 28, 2017 3:16 pm    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
View user's profile Send private message
mqjeff
PostPosted: Wed Mar 29, 2017 4:32 am    Post subject: Reply with quote

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
View user's profile Send private message
tczielke
PostPosted: Wed Mar 29, 2017 4:51 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
View user's profile Send private message
mqjeff
PostPosted: Wed Mar 29, 2017 5:14 am    Post subject: Reply with quote

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
View user's profile Send private message
tczielke
PostPosted: Thu Mar 30, 2017 4:25 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
View user's profile Send private message
tczielke
PostPosted: Fri Dec 22, 2017 5:04 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
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 » JMSXGroupId not "sticky" for MQ
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.