Thread separation between client facade and remoting invocat

[ovidiu.feodorov]

When handling recieve(), the previous MessageCallbackHandler implementation used to send another invocation to the server, on another thread, so client-side receive() would block on the message buffer waiting for an asyncrhonous message arrival.

This has been changed.

I would say that you can't use the same thread to trigger delivery on server and also wait for a message to arrive asynchronously, because of race conditions.

We need to discuss that.

[timfox]

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.

[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 ...

[ovidiu.feodorov]

... or when the thread that does receive()/receive(timeout) is forcibly interrupted, and also when the listener is set to null.

[timfox]

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 :)