Java Message Service 1.2? How about NO_ACK mode?

Discussions

Performance and scalability: Java Message Service 1.2? How about NO_ACK mode?

  1. Currently JMS 1.1 provides three session acknowledgment modes: AUTO_ACKNOWLEDGE, CLIENT_ACKNOWLEDGE, DUPS_OK_ACKNOWLEDGE. But, it does not supply a NO_ACKNOWLEGE mode.
    Our applications are very performance critical.  There are many times that we want to publish messages rapidly without concern if the subscriber received that message.  These kinds of messages are periodic updates of common data.  If a subscriber misses one, he'll catch the next one.  Having the additional ack "hop" to the server only serves to clog the network and slow down the publisher. 
       We support standards vehemently and want to be able to plug and play with various JMS providers. We need a no acknowledgement mode. What does the community think of such a mode. Is this a shared need? 
  2. hi,

    "periodic updates of common data" : you need to elaborate on this.

    Does this mean that : they are identical messages or similar messages

    If you meant the data in the a message may not be relevant after some time

    instead he can take the latest data... (which can be handled by expiry mode)

    Bhagvan K
    http://www.architectcorner.com
  3. hi,

    Just to elaborate on

    Client_Acknowledge Mode

    A third approach is client mode in which there is no automatic acknowledgement. Instead, the receiver is responsible for any acknowledgement back to the sender. This approach provides for the ability to adjust the acknowledgement such that it best meets the needs of the application. The trade-off here is that the acknowledgement, if used, must be implemented within the receiving application, rather than using the facilities provided by JMS. The cost is in code complexity and the resources needed for the manual implementation


    Bhagvan K
    http://www.architectcorner.com