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

[timfox <nu...@jb...>]

Hi guys, here's my 2c FWIW, apologies if you've already gone over this ground :)

In Ovidiu's case 2) above it seems to me that the positive acknowledgement may not  be known until some (very long and unknown) time in the future - this might be the case for a transacted JMS Session, where the acknowledgement is done at commit time, not at message receipt time.

In that case, blocking the server thread that delivers the message to the client until the ack/nack occurs isn't really an option.

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.

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.

-Tim





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

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