Performance and scalability: Java Message Service 1.2? How about NO_ACK mode?
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.
- Posted by: Lillian Andres
- Posted on: May 14 2004 14:10 EDT
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?
"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)
Just to elaborate on
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