Asynchronous Send Functionality Should Use Java SE 8 Completeable Future

[glassfishrobot]

Much better fit for the intent of the asynchronous send functionality than the current callback interface.

Affected Versions

[2.0]

[glassfishrobot]

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

[glassfishrobot]

@glassfishrobot Commented Reported by reza_rahman

[glassfishrobot]

@glassfishrobot Commented clebertsuconic said: good point IMO

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: Here is an analysis of what new API this would entail:

The standard API currently defines four existing methods on MessageProducer which perform an async send:

void sendAsync(Destination destination, Message message) throws JMSException void sendAsync(Destination destination, Message message) throws JMSException void sendAsync(Destination destination, Message message, int deliveryMode, int priority, long timeToLive) throws JMSException void sendAsync(Message message) throws JMSException

If we were to add equivalent methods which perform an async send and return a CompleteableListener then we would need:

CompletableFuture sendAsync(Destination destination, Message message) throws JMSException CompletableFuture sendAsync(Destination destination, Message message) throws JMSException CompletableFuture sendAsync(Destination destination, Message message, int deliveryMode, int priority, long timeToLive) throws JMSException CompletableFuture sendAsync(Message message) throws JMSException

In the simplified API, an async send is current specified on a JMSProducer by calling the existing method setAsync(CompletionListener completionListener) followed by a call to one of five existing send methods. These send methods return the JMSProducer to allow message chaining:

JMSProducer send(Destination destination, byte[] body) JMSProducer send(Destination destination, Map<String,Object> body) JMSProducer send(Destination destination, Message message) {{JMSProducer send(Destination destination, Serializable body) JMSProducer send(Destination destination, String body)

We would need to define five new methods which perform an async send and which return a CompleteableFuture. Since these methods don't return the JMSProducer they can't be used in message chaining:

CompletableFuture sendAsync(Destination destination, byte[] body) CompletableFuture sendAsync(Destination destination, Map<String,Object> body) CompletableFuture sendAsync(Destination destination, Message message) {{CompletableFuture sendAsync(Destination destination, Serializable body) CompletableFuture sendAsync(Destination destination, String body)

In all cases, the CompletableFuture allows the caller to use methods such as accept, apply or {[exceptionally}} to register callback functions which are executed in the event of successful or unsuccessful completion of the send (many other options are possible in addition to this).

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: As can be seen, quite a lot of new API would be required. The most important issue, I think, is whether providing this new API would be of genuine benefit to users. I think we current have insufficient information to determine this currently. It would be very helpful to have feedback from developers who are using the new JMS 2.0 async send feature.

Implementing these new methods would be fairly simple - indeed applications could probably write their own implementations on top of the JMS 2.0 API.

One issue to bear in mind is that JMS 2.0 specifies that completion callbacks must take place one at a time and in the correct order. This restriction would apply even if CompletableFuture were used instead, unless the spec defined otherwise.

[glassfishrobot]

@glassfishrobot Commented reza_rahman said: Honestly I'm not sure about this one myself - we should probably gather more feedback or defer it for now...

[glassfishrobot]

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