On 13/01/2015 18:14, Joakim Erdfelt wrote:
> Some information from the Jetty camp ...
>>
>>
>> Your sample can be reduced to:
>>
>> session.getAsyncRemote().sendText(message);
>> session.getBasicRemote().sendText(message);
>>
>>
>> and I don't think this should end up in an exception. There must be
>> some kind of queue implemented in the container and second call will
>> wait for first message to be sent, but that's all. Consider Session
>> class javadoc:
>
>
> Jetty does not throw an exception in this case.
> The 2 messages are queued, and notified in the "has been sent" case.
>
> "has been sent" having different meanings depending on
> RemoteEndpoint.Basic vs RemoteEndpoint.Async and batching behavior.
>
> If batching is not enabled, then "has been sent" means the message (or
> partial message) has left the java network stack.
> If batching *is* enabled, then "has been sent" for RemoteEndpoint.Basic
> means it entered the batch, and RemoteEndpoint.Async has no change and
> still notifies the Future<Void> or ResultHandler when the message has
> left the java network stack.
How do you handle write backpressure in this case? What stops a client
doing multiple sendText(message) calls for Async and/or Basic?
Mark