I disagree with this statement ...
RemoteEndpoint.sendStringByCompletion("hello", cb);
cb completes immediately because the message fits into the container's
buffer.
The CB (aka SendHandler) should not be triggered on entering a internal
container buffer.
It should only be triggered when all of the frames that make up that
message have been written out the network connection only.
Even the javadoc says "Called once the message has been transmitted".
With various extensions in the mix, a single call to
RemoteEndpoint.sendStringByCompletion(message, callback) can result in
multiple frames (or queuing in the case of mux) before it has even been
written out the network layer.
As a container implementer, we have to track this breakdown of the message
to fragments and have the user callback trigger on the last frame written.
(Incidentally, this is not that hard to implement, I've already done this)
If we change the semantic to be on entering the containers buffer, then
this SendHandler is going to prove useless for end users as there between
the send -> container buffer -> flush to network layer an error can occur
that should be communicated back via the SendHandler.sendResult(new
SendResult(new IOException("Unable to write"))).
--
Joakim Erdfelt <joakim_at_intalio.com>
webtide.com <http://www.webtide.com/>
Developer advice, services and support
from the Jetty & CometD experts
eclipse.org/jetty - cometd.org
On Thu, Jan 31, 2013 at 6:45 PM, Scott Ferguson <ferg_at_caucho.com> wrote:
> 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 call.)
>
> -- Scott
>
>