[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Synchronous vs. asynchronous NACK when client refuses de

[<ad...@jb...>]

"timfox" wrote : 
  | I can see two options here:
  | 
  | 1) Let something on the client side implement a reliable store and take over responsibility for message delivery. It can then respond with an ack immediately. I think this violates any idea of having a thin client though, plus it's just passing the same problem to the next thing in the chain IMO.
  | 

Rule 1 in Middleware design: NEVER TRUST A CLIENT TO BE RELIABLE
That is a decision for the end user that requires work on their side.

anonymous wrote : 
  | 2) Have some way (callback) for the client to inform the server queue object asynchronously that a message is acked/nacked.  This would be called by the client side code when the JMS session (or whatever) commits or rolls back. It's my understanding the core classes currently don't support such functionality - I may well be wrong here.
  | 

Correct, you need this anyway for CLIENT_ACKNOWLEDGEMENT/session.close()/etc.
You can also "piggy-back" the acks on top of other client->server requests in the case of
DUPS_OK, which is a trick that JBossMQ does NOT do.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876609#3876609

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876609