[jsr356-experts] Re: [jsr356-users] Re: Concurrency questions

From: Scott Ferguson <ferg_at_caucho.com>
Date: Thu, 31 Jan 2013 17:45:47 -0800

On 1/31/13 5:13 PM, Danny Coward wrote:
> Hi Mark,
> Thanks for bringing these up, I don't think you've missed anything in
> the spec.
> On 1/29/13 1:42 AM, Mark Thomas wrote:
>> All,
>> 2) How is 1) affected when batching is enabled?
>> My current thinking is that the send is completed (via the Future or
>> SendHandler) once the message has been batched but before it has been
>> flushed. Otherwise it would be impossible to batch multiple messages.
> Is this the case where you are in batching mode and you call a send
> while the container is in the middle
> of sending the last batch. Can't the container start a new batch ?
> Scott what do you think on this one ?

I agree with Mark. (Although I think he's focusing on a slightly
different part of the scenario than what you're describing.)

As long as the send method can complete without blocking, I think the
future/SendHandler would complete even though the data is just buffered,
not sent.

The future/SendHandler should be about avoiding blocking, not
necessarily related to any underlying buffering.

For example the following sequence:

1) RemoteEndpoint.sendStringByCompletion("hello", cb);

cb completes immediately because the message fits into the container's
buffer. The buffer is not necessarily flushed (depending on the
container, of course.)

2) RemoteEndpoint.sendStringByCompletion("world", cb);

cb can completed immediately if both messages fit in the container's
internal buffer.

(1+2 is Mark's scenario, I think. It's a bit different from your
description because the container isn't sending anything yet.)

3) RemoteEndpoint.sendStringByCompletion("really big string that
overflows the buffer", cb);

The cb is not completed until the container has enough room after
flushing its current buffer.

(I think #3 is your scenario. I don't think the cb can be called until
the container has flushed enough data to make room for a new sendString

-- Scott