<< Back to previous view

[JMS_SPEC-103] A JMS 2.0 resource adapter needs to be able to include cluster name in a generated subscription name Created: 29/Oct/12  Updated: 14/Nov/12  Resolved: 14/Nov/12

Status: Closed
Project: jms-spec
Component/s: None
Affects Version/s: 2.0PD
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Duplicate Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-73 Define how messages from a topic are ... Open
blocks MQ-230 Enhance JMSRA to include cluster name... Closed
Tags: pd20-forreview-minor
Participants: Nigel Deakin

 Description   

The draft JMS 2.0 specification, chapter 12.1. "ActivationSpec properties" states that:

If a durable subscription is specified but subscriptionName is not specified then the resource adapter will set the name of the durable subscription to be a name which is unique to the deployed MDB.

The intention of this feature is to allow the resource adapter to automatically generate a subscription name automatically which will be different for each deployed MDB but the same for each instance in the cluster. This instances of the same deployed MDB across the whole cluster to share the work of processing messages from the same subscription.

However if the same JMS provider is being used by two different application server clusters, and the two clusters are using the same MDB name, then this would cause the two clusters to share the same subscription which is undesirable.

To avoid this, the subscription name generated by the resource adapter should be composed of (1) a name which uniquely identifies the deployed MDB within thin the cluster as well as (2) a name which uniquely identifies the application server cluster.

The JMS specification needs to be extended to cover (2)



 Comments   
Comment by Nigel Deakin [ 29/Oct/12 04:26 PM ]

This will also require a change to the EJB 3.2 specification which contains a similar definition of what the container does it the subscriptionName property is not set.

Implementing this will require a change to the Java EE specification to make the name of the cluster available.

Comment by Nigel Deakin [ 29/Oct/12 04:34 PM ]

This is an extension of issue JMS_SPEC-73

Comment by Nigel Deakin [ 14/Nov/12 12:56 PM ]

I'm closing this issue as a duplicate of JMS_SPEC-73 because that issue is still open and it is best to keep this as a single open issue.





[JMS_SPEC-91] New "relaxed message order" option Created: 28/Mar/12  Updated: 28/Mar/12

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: pd20-forreview-minor
Participants: Nigel Deakin

 Description   

Not all JMS applications depend on the message ordering guarantees required by JMS 1.1. Some would work perfectly well if the existing guarantees were occasionally broken.

The need to satisfy the message ordering requirements of JMS 1.1 imposes a significant burden on the JMS provider. For example, the requirement to preserve the order of messages sent by a message producer during the lifetime of the client-side object places constraints on the way in which a clustered JMS provider may handle producer failover or on its ability to balance the message load across the cluster.

Whilst JMS providers will always need to be able to satisfy JMS 1.1 message ordering requirements, if JMS also defined a less onerous message order requirement then those applications which could use it may be able to benefit from better performance or increased scalability.

It is therefore proposed that a new "relaxed" message ordering option be available. In such a mode, JMS does not guarantee that messages will always be received by a consumer in the same order that they were sent by a given producer. Although JMS providers could not be permitted to ignore message order altogether, the strict requirement to deliver messages in order would be relaxed.

It is expected that this option would be of particular value in very large clusters and similar web-scale architectures. However it would be up to providers to decide whether, and how, to take advantage of this option. Although vendors would be required to allow "relaxed message order" as an option, it would be completely valid for this to be identical to normal message ordering.

The exact API to specify "relaxed ordering" is not yet proposed. It might be a property of the producer connection or of the destination itself.






[JMS_SPEC-79] New factory methods to create BytesMessage and MapMessage and set the payload Created: 20/Feb/12  Updated: 28/Mar/12

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: pd20-forreview-minor
Participants: Nigel Deakin

 Description   

In JMS 1.1 the following methods on Session can be used to create a ObjectMessage or TextMessage and set the payload at the same time:

createObjectMessage(Serializable object)
createTextMessage(String text)

However there are no equivalent methods for BytesMessage and MapMessage. It is therefore proposed that the following new methods be added to Session (and MessagingContext):

createBytesMessage(byte[] bytes)
createMapMessage(Map map)





[JMS_SPEC-71] Change XAConnectionFactory to extend ConnectionFactory Created: 15/Feb/12  Updated: 01/Jul/13

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GENERICJMSRA-55 genericjmsra gets ClassCastException ... Open
Tags: pd20-forreview-minor
Participants: Nigel Deakin

 Description   

JMS 1.1, includes the following three interface definitions:

public interface XATopicConnectionFactory extends XAConnectionFactory, TopicConnectionFactory

public interface XAQueueConnectionFactory extends XAConnectionFactory, QueueConnectionFactory 

public interface XAConnectionFactory 

why does XAConnectionFactory not extend ConnectionFactory? This is inconsistent.

Please consider changing XAConnectionFactory to extend ConnectionFactory.



 Comments   
Comment by Nigel Deakin [ 09/Mar/12 02:24 PM ]

We would need to consider whether changing an object's superclass is a permitted change in conformance with the Backwards Compatibility Requirements for Java EE Specifications . This interface is not intended for use by normal applications so there may be more scope to change it.

This will be evaluated by the expert group for possible inclusion in the JMS 2.0 public draft. Tagging accordingly.





[JMS_SPEC-68] Add new method Session.acknowledge() Created: 16/Jan/12  Updated: 28/Mar/12

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: pd20-forreview-minor
Participants: crowne and Nigel Deakin

 Description   

When a session is created with an acknowledgement mode of Session.CLIENT_ACKNOWLEDGE, messages are acknowledged by calling the acknowledge() method on the Message object.

However this method is potentially misleading because calling it causes all messages delivered to the Session to be acknowledged,. It doesn't just acknowledge the Message on which the acknowledge method is called. JMS 1.1 recognised this issue and clarified the spec and javadocs to make this clear.

However the fact that the acknowledge method is on the Message is still potentially confusing. Although we can never remove this method because of the need to maintain compatibility, adding an acknowledge method to the Session would allow application code to reflect the true behaviour.

It is therefore proposed that a new method acknowledge() be added to the Session interface which causes all messages delivered to the Session to be acknowledged (i.e. identical behaviour to the existing method).



 Comments   
Comment by Nigel Deakin [ 16/Jan/12 03:38 PM ]

The proposed simplified API {JMS_SPEC-64) provides an acknowledge method on MessagingContext. Adding a similar method on Session would be consistent with this.

Comment by Nigel Deakin [ 16/Jan/12 03:41 PM ]

eg

Comment by crowne [ 17/Jan/12 07:08 AM ]

Why not be specific about the intention of the method on Session and name it acknowledgeAll();

Comment by Nigel Deakin [ 05/Mar/12 04:54 PM ]

This will be reviewed by the JSR 343 expert group. Adding appropriate tag.





[JMS_SPEC-67] Relaxing the requirement to throw an exception if a message is sent to a deleted temp destination Created: 10/Jan/12  Updated: 28/Mar/12

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: pd20-forreview-minor
Participants: Nigel Deakin

 Description   

This was raised by Hiram Chirino:

As an implementor of the JMS 1.1 spec one of the things that bother me about that version of the spec is the need to throw an exception when a client attempts to send a message to a temporary destination which has been deleted.

This isn't explicitly required in the JMS spec, but it appears to be required by the TCK tests. Hiram added:

If I recall correctly, I first encountered the requirement was when I was testing Geronimo against the JMS TCK. The TCK has a test case which checked the requirement I described. I guess the TCK implementors justify the test assertion due to the API documentation on send method that states throws 'InvalidDestinationException - if a client uses this method with a QueueSender with an invalid queue.'

Hiram gave the following as his justification:

You either have do an RPC against the server for each send to verify the temp destination is still around (which is slow since your working with non-persistent messages anyways) or the client has to monitor all temp destinations on the server which increases complexity of the client and the amount of memory it uses.

It also provides very little value to the end user application since NOT getting an exception does not guarantee the message will get processed. You could have a scenario where the producer sends a message to a temp destination and then the temp destination gets deleted which means the sent message gets dropped.

Hopefully the next version of the spec will be changed so that sending to a deleted temp destination does not throw a JMSException but instead the message gets dropped by the server.



 Comments   
Comment by Nigel Deakin [ 09/Mar/12 02:28 PM ]

This will be reviewed by the expert group for possible inclusion in the JMS 2.0 public draft. Tagging accordingly.





[JMS_SPEC-66] Define how MessageConsumer.receive should handle a thread interrupt Created: 03/Jan/12  Updated: 08/Jan/13

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: pd20-forreview-minor
Participants: axel_podehl, brecht_yperman and Nigel Deakin

 Description   

The Java SE API allows an application to interrupt a running thread by calling the interrupt method on the Thread object.

I'm logging this issue to raise the question of whether JMS should define how a JMS provider should handle a thread interrupt during a call to MessageConsumer.receive() or MessageConsumer.receive(timeout), which will both block whilst waiting for a message to arrive.

There's a useful article by Brian Goetz here:
http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html

Possibilities are:

1. Leave this up to the JMS provider (which is the current situation in JMS 1.1)
2. Define that a thread interrupt should cause the receive method to throw a JMSException
3. Define that a thread interrupt should cause the receive method to throw a InterruptedException
4. Define that a thread interrupt should be ignored

Note that it would not be possible to change the signature of the existing receive methods (as in (3)) since this would break backwards compatibility.

In cases 1,2 and 4 (the ones that don't throw a InterruptedException) Brian Goetz's article recommends that the method should re-enable the interrupted status of the thread (even if the interrupt was swallowed or converted a JMSException) to allow the calling code to detect whether an interrupt had occurred.

In logging this issue I'm not proposing any change, but the topic is worth recording and I'd welcome comments.



 Comments   
Comment by brecht_yperman [ 03/Jan/12 03:27 PM ]

Having encountered this issue with JMS 1.1 and OpenMQ, I'd personally prefer option 2.

MessageConsumer.receive() is an operation very similar to a blocking read, described in the API

"If this thread is blocked in an I/O operation upon an interruptible channel then the channel will be closed, the thread's interrupt status will be set, and the thread will receive a ClosedByInterruptException."
http://docs.oracle.com/javase/6/docs/api/java/lang/Thread.html#interrupt()

I also think, but this is of course guessing, that most JMS clients do a blocking socket read anyway, so they can easily handle the InterruptedException thrown by that read.

Just my two cents.

Comment by Nigel Deakin [ 08/Mar/12 12:28 PM ]

This issue will be considered by the expert group for possible inclusion in the JMS 2.0 public draft. Tagging appropriately.

Comment by axel_podehl [ 08/Jan/13 12:56 PM ]

I would prefer 3 (throw InterruptedException)- if it wouldn't break the API.
So choice 2 (throw JMSException) is the second best alternative

Probably the JMS Provider should set JMSException.setLinkedException() to be the InterruptedException





[JMS_SPEC-24] Clarify classloader used in ObjectMessage.getObject() and/or provide new method getObject(ClassLoader classLoader) Created: 04/Jul/11  Updated: 28/Mar/12

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: F.Degenaar Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: pd20-forreview-minor
Participants: F.Degenaar and Nigel Deakin

 Description   

It is specified neither in the spec nor in the API JavaDoc which ClassLoader is to be used, when the object gets deserialized in ObjectMessage.getObject().
This omission lead to different implementations (and bugs) among JMS providers, as can be seen here:
http://www-01.ibm.com/support/docview.wss?uid=swg1IC72855
http://www.coderanch.com/t/313402/EJB-JEE/java/Exception-receiving-ObjectMessage-JMS
http://forums.oracle.com/forums/thread.jspa?threadID=738545
http://community.jboss.org/message/437144#437144

Alternatively, if it isn't possible to specify the class loader, add a method "Serializable getObject(ClassLoader classLoader) to ObjectMessage.



 Comments   
Comment by Nigel Deakin [ 08/Mar/12 12:25 PM ]

Would the person who raised this issue like to propose what kind of clarification they would want to see?

Standard Java deserialization uses the java.io.ObjectInputStream.readObject() method.

The default behaviour of ObjectInputStream.readObject() is described in the javadoc for ObjectInputStream.resolveClass() here. This states that the class loader loader is determined as follows:

if there is a method on the current thread's stack whose declaring class was defined by a user-defined class loader (and was not a generated [class] to implement reflective invocations), then loader is [the] class loader corresponding to the closest such method to the currently executing frame; otherwise, loader is null

However some JMS providers appear to override this behaviour, perhaps to use the context class loader if using the class loader provided by default cannot load the class.

Trying the context class loader is more flexible, though it still relies on the context class loader being configured appropriately, which is not under direct application control in a MDB or message listener where the thread is created by the JMS provider or application server. In addition, the first of the four examples given above suggest that even when messages are consumed synchronously using a application thread, the deserialization may still be performed in a separate JMS provider thread. So requiring the deserialization to try the context class loader may not always solve the problem.

The submitted proposes a new method getObject(ClassLoader classLoader) on java.jms.ObjectMessage. This would be simple to implement and not impact on existing JMS providers or applications, so seems a good candidate for consideration.

I'll raise this topic with the expert group. Tagging appropriately.

Comment by Nigel Deakin [ 12/Mar/12 04:21 PM ]

Description changed from:
Clarify, which ClassLoader to use when invoking ObjectMessage.getObject()
to:
Clarify classloader used in ObjectMessage.getObject() or provide new method getObject(ClassLoader classLoader)

Comment by F.Degenaar [ 13/Mar/12 05:41 PM ]

My take on the first example was a different one: the problem was, that the object was deserialized internally before getObject() was called. So, using the context class loader should have helped avoiding the issue.
Still, neither spec nor javadoc mention the default behaviour from ObjectInputStream.resolveClass(). Defining it as default will not resolve all problems, but most of them. I still see this as an improvement, especially when an alternative classloader can be chosen with the overloaded version.

Comment by Nigel Deakin [ 13/Mar/12 05:55 PM ]

@F.Degenaar: In the first example, the object was deserialized in an internal JMS thread. How would it help to mandate that it should use the context class loader, since the application has no way to configure the context class loader of an internal JMS thread?

Comment by F.Degenaar [ 13/Mar/12 11:44 PM ]

@Nigel Deakin: A new method getObject(ClassLoader classLoader) alone cannot solve the problem described in the first example. The ClassNotFoundException will be thrown either which way, because the the deserialization happens independently in an internal thread.
At present it is impossible to predict, if ObjectMessage can be used to transport non-JDK classes even with a certified JMS provider.
If the context class loader (or the one specified as an parameter) is mandated as the only one to use, the control will be in the hands of the application or the application server.
Anything else would than be a vendor extension, which can be used at will.

Comment by Nigel Deakin [ 14/Mar/12 10:11 AM ]

F.Degenaar writes:

A new method getObject(ClassLoader classLoader) alone cannot solve the problem described in the first example. The ClassNotFoundException will be thrown either which way, because the the deserialization happens independently in an internal thread.

We would define getObject(ClassLoader classLoader) as meaning that the object must be deserialised using the specified class loader. So if a suitable class loader is specified it will not fail.

If the provider also deserialises the object eagerly in a separate thread created by the JMS provider (to improve the performance of a subsequent call to the existing getObject()) then how are you suggesting we specify which class loader it uses? Specifying that it uses the context class loader isn't a help, since the application doesn't have any way to configure the context class loader if a provider-created thread.

I'm not sure exactly what you are asking for here. Please do suggest some text!

Comment by F.Degenaar [ 14/Mar/12 06:40 PM ]

Please keep in mind, that English is not my native language. That said:
As an addition to the Returns:-JavaDoc of ObjectMessage.getObject():
"Any deserialization necessary must only happen using the context class loader of the thread, in which this method was invoked."
For the proposed method getObject(ClassLoader classLoader) the JavaDoc for the parameter classLoader would read:
"The class loader to be exclusively used for any deserialization necessary."

What I am trying to achieve here?

  • If no deserialization is necessary, the class loader obviously doesn't matter (think in-memory provider).
  • If a deserialization happens, the developer or an application server have control over which class loader is used by setting the context class loader beforehand.
  • Every spec-compliant optimization is transparent to the application.
  • Any optimization violating the spec will be explicit by a cast to a vendor-specific class or interface, in the configuration of the provider or the initialization of factory objects etc.
Comment by Nigel Deakin [ 15/Mar/12 11:04 AM ]

Thanks for clarifying what you are asking for. My goal at this stage is simply to ensure that this issue is clearly described. Now it is, we can now leave it for later review by the expert group.





[JMS_SPEC-22] Add JMS defined property JMSXGroupLast Created: 04/Jul/11  Updated: 28/Mar/12

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: F.Degenaar Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: pd20-forreview-minor
Participants: F.Degenaar and Nigel Deakin

 Description   

When grouping messages, there is no specified way to flag a message as the last one in a group.
To determine the last message in a group, one has to fall back to a vendor-specific property.
A good example can be found here: http://www.ibm.com/developerworks/websphere/library/techarticles/0602_currie/0602_currie.html

Adding a boolean JMS defined property with a name like JMSXGroupLast or similar would enable receiving group messages to be portable among different JMS providers.



 Comments   
Comment by Nigel Deakin [ 09/Mar/12 07:02 PM ]

So JMSXGroupLast would be another JMS-defined property to add to JMSXGroupID (The identity of the message group this message is part of) and JMSXGroupSeq (The sequence number of this message within the group).

As with the two existing properties, all that JMS will do is define the name of this new property. It will not require JMS providers to provide any functionality related to them.

This proposal will be reviewed by the expert group for inclusion in the JMS 2.0 public draft. Tagging accordingly.

Comment by F.Degenaar [ 13/Mar/12 06:17 PM ]

For the current message group properties the spec states "JMSXGroupID and JMSXGroupSeq are standard properties clients should use if they want to group messages. All providers must support them.". JMSXGroupLast should be included in the first sentence, so getting and setting this property is guaranteed behaviour.

Comment by Nigel Deakin [ 14/Mar/12 09:58 AM ]

Agreed. That was what I intended. However I think it would be worth clarifying that a JMS provider is not required to do anything more than allow this property to be set and got.





Generated at Thu Apr 17 18:35:41 UTC 2014 using JIRA 4.0.2#472.