It's my understanding that NACKs (cancels) can always be sent asynchronously from the client to server, since it won't affect the reliability guarantee if they are lost for some reason.
However, with ACKs then, if the ACK fails, the client needs to know this, in the case of CLIENT_ACKNOWLEDGE, or transactional (where the commit does an implicit ack of the messages), therefore the call to acknowledge needs to be synchronous.
However with DUPS_OK, duplicates may happen anyway, therefore we can get away with asynchronous acks, since if one is lost this may result in redelivery which we are ok with anyway.
What about AUTO_ACK? Does the ack need to be synchronous in this case?
With auto_ack without a message listener, the message is acked before it is processed. So messages could be lost anyway, if the client fails. So the once and only once does not apply anywhere. Since the reliability guarantee is lower is it acceptable to use asynchronous acks with AUTO_ACK as well?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990444#3990444
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990444
The filestore stuff is *very* interesting on a number of fronts. Most fascinating of all (in my mind) is an idea I've been thinking about lately to store JBMS back-end data onto Amazon's S3 service (www.amazon.com/aws) via a filesystem interface like JungleDisk or something similar. It would be a cool way to host a JBMS service on a large scale without having to worry about huge amounts of back-end storage.
The catch is that AWS is not POSIX compliant (aws can't guarantee certain things that a normal filesystem would). I'd be curious to do some testing on this, though....also to hear thoughts about whether such a setup could even work or not.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990332#3990332
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990332