jms-spec
  1. jms-spec
  2. JMS_SPEC-149

Asynchronous Send Functionality Should Use Java SE 8 Completeable Future

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Labels:
      None

      Description

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

        Activity

        Hide
        clebertsuconic added a comment -

        good point IMO

        Show
        clebertsuconic added a comment - good point IMO
        Hide
        Nigel Deakin added a comment -

        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).

        Show
        Nigel Deakin added a comment - 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).
        Hide
        Nigel Deakin added a comment - - edited

        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.

        Show
        Nigel Deakin added a comment - - edited 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.
        Hide
        reza_rahman added a comment -

        Honestly I'm not sure about this one myself - we should probably gather more feedback or defer it for now...

        Show
        reza_rahman added a comment - Honestly I'm not sure about this one myself - we should probably gather more feedback or defer it for now...

          People

          • Assignee:
            Unassigned
            Reporter:
            reza_rahman
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: