JMSXGroupId/GroupSeq Optional or Mandatory?

[glassfishrobot]

Hello,

I was looking for clarification on if the JMSXGroupId and JMSXGroupSeq fields are optional or mandatory for a JMS provider to support. The 3-3 table in the JMS 2.0 specification says they are optional. However, a little later in the 3.5.9 section they are explicitly called out as mandatory:

"JMSXGroupID and JMSXGroupSeq are standard properties clients should use if they want to group messages. All providers must support them."

This seems to me like a contradiction, so just following up on if this is a bug (i.e. contradiction) and also for clarification on if these two fields are optional or mandatory for a JMS provider to support.

Environment

All

Affected Versions

[2.0]

[glassfishrobot]

@glassfishrobot Commented
Reported by TimZielke

[glassfishrobot]

@glassfishrobot Commented
@nigeldeakin said:
In JMS 2.0, table 3.3 states that JMSXGroupId and JMSXGroupSeq are set by the client (rather than by the JMS provider). This means that the word "Optional" in the third column means that it is optional whether the client sets them.

When section 3.5.9 states that "All providers must support" these properties, I think this means that if the sending application sets these properties on a message that is sent, the JMS provider MUST set the same values when the message is delivered to the receiving application (i.e. it mustn't simply ignore them). The JMS provider doesn't have to do anything with these properties other than transmit them faithfully to the consumer.

[glassfishrobot]

@glassfishrobot Commented
timzielke said:
Thanks, Nigel. To further clarify, let's say we had the situation where there is one JMS client putting 5 messages with the same JMSXGroupId to a queue. There are two consumers reading from this queue. If the JMS client puts 5 messages to the queue with the same JMSXGroupId, the JMS Provider would be required to pick one of the consumers and then send all 5 messages to that same consumer, correct?

[glassfishrobot]

@glassfishrobot Commented
@nigeldeakin said:
Tim. You're right to follow up. Reading the spec again, I think I need to correct my previous comment that in table 3.3 the word "optional" means that it is optional whether the client sets them. The note above the table says that it means "whether support for the property is mandatory or optional". The word "support" clearly refers to the capabilities of the JMS provider. So for these two properties (which are the only two which are set by the client rather than by the provider) I think it means that it is optional whether the JMS provider "honours" these properties and changes its behaviour as a consequence of their being set.

You also mentioned section 3.5.9. On reflection, I think this is simply incorrect (an error in the spec) since it contradicts table 3.3 - as you pointed out. I really don't know what the writers had in mind when they wrote this section. I suggested above that it means that the provider should transmit these properties to the client. Whilst I think it should certainly do that, this section seems to be saying something else, but I'm not sure what.

One thing to keep in mind here is that the description of these properties in table 3.3 is pretty vague. JMSXGroupID is defined as "the identify of the message group this message is part of" and JMSXGroupSeq is defined as "the sequence number of this message within the group". But nowhere does the spec actually define what a "message group" is. For example there is no mention anywhere of a requirement that that all the messages in a "message group" must be delivered to the same consumer. I think the lack of any definition of "message group" confirms that the JMS provider doesn't have to "honour" these properties since the spec doesn't actually define what it needs to do. Some JMS providers do interpret it in the way suggested, but the reference implementation simply ignores it.

The spec should be clarified. I'll leave this issue open: it will be considered for a possible future maintenance release.

I suspect this feature was added in the early days of JMS to expose a feature of some particular existing messaging system. as an optional feature, which is why no-one ever bothered to define it clearly in the spec.

As an aside, note that JMS 2.0 section 4.1.2 "queue semantics" states "Apart from the requirements of any message selectors, JMS does not define how messages are distributed between multiple consumers on the same queue." (JMS 1.1 says the same thing). No mention of message groups here.

Thanks for raising this. Feel free to follow-up.

[glassfishrobot]

@glassfishrobot Commented
timzielke said:
Thank you for the information, Nigel! That does answer all my questions. Feel free to close this from my end.

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA JMS_SPEC-179

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/jms-spec/issues/179
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @nigeldeakin