jms-spec
  1. jms-spec
  2. JMS_SPEC-12

Message producer confirms aka async message production.

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 1.1
    • Fix Version/s: 2.0
    • Labels:
      None

      Description

      The synchronous 1.1 JMS API has an impact on how a single thread can produce messages with a session. There is too much waiting around for a reply from the server.

      As a JMS client I would like to send a message on a non-transacted session with persistent delivery and receive asynchronous confirmation that it is stable via a callback. The session can then interact with the server in a more efficient manner.

      RabbitMQ has a good write up of the functionality http://www.rabbitmq.com/blog/2011/02/10/introducing-publisher-confirms.
      29West and Tervela have similar capability.
      No doubt some JMS implementations have similar capabilities using non-JMS APIs.

        Issue Links

          Activity

          Hide
          timlfox added a comment -

          +1 on this feature.

          HornetQ was a pioneer with this - it's definitely a must for high throughput reliable message sending.

          http://docs.jboss.org/hornetq/2.2.2.Final/user-manual/en/html/send-guarantees.html#asynchronous-send-acknowledgements

          Show
          timlfox added a comment - +1 on this feature. HornetQ was a pioneer with this - it's definitely a must for high throughput reliable message sending. http://docs.jboss.org/hornetq/2.2.2.Final/user-manual/en/html/send-guarantees.html#asynchronous-send-acknowledgements
          Hide
          bsnyder added a comment -

          Agreed, this is one area where there is a hole in the JMS 1.x spec.

          Show
          bsnyder added a comment - Agreed, this is one area where there is a hole in the JMS 1.x spec.
          Hide
          rdohna added a comment -

          I can see that there are some very-high-throughput use cases for this feature, but you'd need to implement your own two-phase commit, wouldn't you? It's a lot of code every client would have to re-implement... and it's easy to get it wrong and extremely difficult to test. It's quite a chimaera between transactional and non-transactional, isn't it?

          I think we should either find a solution that's easier to work with, or choose to leave it out of the standard; it may have to be optimised for every JMS implementation anyway.

          Show
          rdohna added a comment - I can see that there are some very-high-throughput use cases for this feature, but you'd need to implement your own two-phase commit, wouldn't you? It's a lot of code every client would have to re-implement... and it's easy to get it wrong and extremely difficult to test. It's quite a chimaera between transactional and non-transactional, isn't it? I think we should either find a solution that's easier to work with, or choose to leave it out of the standard; it may have to be optimised for every JMS implementation anyway.
          Hide
          colincrist added a comment -

          Persistent messaging does not imply container managed transactions. In the classic J2EE world the way to do persistent messaging and database co-ordination is via XA. This is fine for many use cases but I have found JMS used a great deal without a J2EE container and XA is not the only way to avoid data loss although it does require a bit of coding to co-ordinate

          If say on some thread(s) messages are sent whilst on another the stability confirms are received sometime later then the application can update its store that the message (say an order) has indeed been sent successfully and can also do this in batch, keeping the disk I/O under control. This approach leads to a flurry of application generated duplicate messages on recovery as the application has to send messages it has not seen stability confirms for but this is the price you pay for scalability. On the plus side there is far less waiting around to co-ordinate disk writes via XA so you get a hugh increase in throughput, 10s-100s of times faster is not uncommon.

          The implementation of this part of the API is up to the provider and its performance would be another differentiator between products.

          Show
          colincrist added a comment - Persistent messaging does not imply container managed transactions. In the classic J2EE world the way to do persistent messaging and database co-ordination is via XA. This is fine for many use cases but I have found JMS used a great deal without a J2EE container and XA is not the only way to avoid data loss although it does require a bit of coding to co-ordinate If say on some thread(s) messages are sent whilst on another the stability confirms are received sometime later then the application can update its store that the message (say an order) has indeed been sent successfully and can also do this in batch, keeping the disk I/O under control. This approach leads to a flurry of application generated duplicate messages on recovery as the application has to send messages it has not seen stability confirms for but this is the price you pay for scalability. On the plus side there is far less waiting around to co-ordinate disk writes via XA so you get a hugh increase in throughput, 10s-100s of times faster is not uncommon. The implementation of this part of the API is up to the provider and its performance would be another differentiator between products.
          Hide
          rdohna added a comment -

          NON_PERSISTENT means at-most-once message delivery. PERSISTENT currently (as of JMS 1.1) means once-and-only-once message delivery. I understand that this issue requests something else, as it doesn't want to pay the price for the transaction overhead, but still wants guaranteed delivery.

          This means that you'd have to mark the reason for the message as "in progress" before you send the message. When you receive an ack, you'd mark that status as "done". This as a manual two-phase commit, isn't it?

          Now whenever the sender or the receiver fails, there are two options: If the receiver is idempotent, you can resend all "in progress" messages... that's a new at-least-once message delivery and not yet supported by JMS... there may be use cases for this.

          But if you still require full once-and-only-once guarantee, there has to be some resolution mechanism to re-sync the status of the sender and the receiver. Distributed transactions have such mechanisms, but that's expensive... and I can see no way around that.

          If JMS 2.0 defines a at-least-once delivery guarantee, I'd prefer not to have every client to repeat that code, but to hide it somehow at a lower layer. But I don't have any good ideas, yet.

          Show
          rdohna added a comment - NON_PERSISTENT means at-most-once message delivery. PERSISTENT currently (as of JMS 1.1) means once-and-only-once message delivery. I understand that this issue requests something else, as it doesn't want to pay the price for the transaction overhead, but still wants guaranteed delivery. This means that you'd have to mark the reason for the message as "in progress" before you send the message. When you receive an ack, you'd mark that status as "done". This as a manual two-phase commit, isn't it? Now whenever the sender or the receiver fails, there are two options: If the receiver is idempotent, you can resend all "in progress" messages... that's a new at-least-once message delivery and not yet supported by JMS... there may be use cases for this. But if you still require full once-and-only-once guarantee, there has to be some resolution mechanism to re-sync the status of the sender and the receiver. Distributed transactions have such mechanisms, but that's expensive... and I can see no way around that. If JMS 2.0 defines a at-least-once delivery guarantee, I'd prefer not to have every client to repeat that code, but to hide it somehow at a lower layer. But I don't have any good ideas, yet.
          Hide
          abien added a comment -

          +1 for callback. But why just with persistent messages? Could be also interesting for transient messages.

          Show
          abien added a comment - +1 for callback. But why just with persistent messages? Could be also interesting for transient messages.
          Hide
          Nigel Deakin added a comment -

          This requirement appears to have been satisfied by JMS_SPEC-43, which was included in the JMS 2.0 Early Draft. Please review that draft and provide any comments.

          That other issue appears to be a duplicate of this one. Given that the other issue contains details of the proposed changes I will close this issue as being a duplicate. Feel free to make comments on the other issue, or directly to users@jms-spec.java.net.

          Show
          Nigel Deakin added a comment - This requirement appears to have been satisfied by JMS_SPEC-43 , which was included in the JMS 2.0 Early Draft. Please review that draft and provide any comments. That other issue appears to be a duplicate of this one. Given that the other issue contains details of the proposed changes I will close this issue as being a duplicate. Feel free to make comments on the other issue, or directly to users@jms-spec.java.net.

            People

            • Assignee:
              Nigel Deakin
              Reporter:
              colincrist
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: