On Fri, Sep 18, 2009 at 8:42 PM, Robert Nicholson <robert.nichol...@gmail.com> wrote: > I've been looking at DMLC lately. > > Acknowledge semantics are a little different when using it though?
There are four types of acknowledgement in the message listener container as listed in the AbstractMessageListenerContainer. I'd copy/paste the acknowledgement modes here but the Javadoc is kinda big but it's comprehensive. Take a look here: http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/jms/listener/AbstractMessageListenerContainer.html > Isn't there the notion that you acknowledge before dispatch and therefore > there > lies an opportunity to acknowledge something from the queue and not actually > process it > because of an outage. Acknowledgement semantics depend on the mode you choose. Here are some items that tend to confuse: 1) "sessionAcknowledgeMode" set to "AUTO_ACKNOWLEDGE" (default): Automatic message acknowledgment before listener execution; no redelivery in case of exception thrown. 2) "sessionAcknowledgeMode" set to "CLIENT_ACKNOWLEDGE": Automatic message acknowledgment after successful listener execution; no redelivery in case of exception thrown. 3) "sessionAcknowledgeMode" set to "DUPS_OK_ACKNOWLEDGE": Lazy message acknowledgment during or after listener execution; potential redelivery in case of exception thrown. 4) "sessionTransacted" set to "true": Transactional acknowledgment after successful listener execution; guaranteed redelivery in case of exception thrown. > JMS doesn't let you commit the session in any other thread than the thread > of control > of the session so you aren't going to have a guarantee that you actually > processed > what was acknowledged/committed in the Session. Again, that depends on the ack mode. See above. > Also, DMLC doesn't do anything for you regarding order of processing so how > does > Spring address that problem? Am I expected to have N's DMLC's and dispatch > based > on my own rules rather than something that can share from a common thread > pool but > still guarantee some order of processing? Controlling the order in which messages are processed on the client-side is not a goal of the Spring message listener container architecture. In a scenario where the order of processing is important, you would only want to have a single consumer. Either that or you'd need to wholly separate the consumption/ack stage from the processing stage. Still, you'd need some additional strategy for such a restriction. Please explain the use case you have in mind for controlling the order in which messages are processed. Bruce -- perl -e 'print unpack("u30","D0G)u8...@4vyy9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' ActiveMQ in Action: http://bit.ly/2je6cQ Blog: http://bruceblog.org/ Twitter: http://twitter.com/brucesnyder
