-
1. Re: Thread separation between client facade and remoting inv
timfox Nov 9, 2005 10:08 AM (in response to ovidiu.feodorov)You're right.
There is the possibility that a message arrives asynch before the synch call has returned and so nothing is waiting. Hence the message would be cancelled.
However, on a related point. It would nice if the asynch call actually returned a message too if one was available (like receive no wait) thus saving the server having to use one if it's threads to delivery. -
2. Re: Thread separation between client facade and remoting inv
ovidiu.feodorov Nov 10, 2005 4:09 PM (in response to ovidiu.feodorov)The latest commit seems to be what we want.
One observation: I noticed that the MessageCallbackHandler sends a deactivation invocation to the server consumer delegate every time it gets a message from its buffer. I belive this is not really necessary, because the consumer delegate "auto-deactivates" by itself after being handled a message - it sets the "ready" flag on false.
The only case I see now in which we really need to explicitely deactivate is when receive(timeout) expires ... -
3. Re: Thread separation between client facade and remoting inv
ovidiu.feodorov Nov 11, 2005 12:12 AM (in response to ovidiu.feodorov)... or when the thread that does receive()/receive(timeout) is forcibly interrupted, and also when the listener is set to null.
-
4. Re: Thread separation between client facade and remoting inv
timfox Nov 11, 2005 5:11 AM (in response to ovidiu.feodorov)"ovidiu.feodorov@jboss.com" wrote:
The latest commit seems to be what we want.
One observation: I noticed that the MessageCallbackHandler sends a deactivation invocation to the server consumer delegate every time it gets a message from its buffer. I belive this is not really necessary, because the consumer delegate "auto-deactivates" by itself after being handled a message - it sets the "ready" flag on false.
You're right.
In other words, if the call to get the message from the buffer returns with a message we never need to deactivate since the server has already done it.
In all other cases (timeout, interrupt) we deactivate.
Cool, one less call :)