Regarding onClose() semantics.
Be very clear that WebSocket close is a protocol frame and does not result
in an immediate disconnect of the underlying connection.
A call to Session.close() will result in a request to close the WebSocket
connection.
This will happen after any pending outgoing messages (think
RemoteEndpoint.Async or batch mode).
It is not possible in 100% of cases to say that when onClose() is called
the Remote Endpoint has responded to the close.
Examples: the mobile Client can request Session.close(), but due to network
conditions that close hasn't been sent before a timeout occurs.
This will result in the local Endpoint onClose() with a non-sendable status
code 1006 (CLOSED_ABNORMALLY)
It should be noted that the onClose() should definitely be called, only
once, in all situations to indicate that the connection is being terminated.
It might be prudent to use the words "close" for WebSocket protocol close,
and "disconnect" for referring to the connection itself being terminated.
--
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 Mon, Feb 25, 2013 at 5:42 PM, Danny Coward <danny.coward_at_oracle.com>wrote:
> Hi folks,
>
> 1) Discrepancy on onClose() vs @OnClose semantics - how closed is the
> session ?
>
> @OnClose: "This method level annotation can be used to decorate a Java
> method that wishes to be called when a web socket session has closed."
> onClose(Session s): "This method is called immediately prior to the
> session with the remote peer being closed."
>
> First of all, these two definitions should match. But how closed is the
> session ? The reality is that as far as developers sending more messages is
> concerned, the session is closed. But (and this is the reason for the
> onClose() definition) it would still be useful for developers to be able to
> query the attributes of the session (URI, user properties stored in there,
> id and so on).
>
> So I'd propose changing the definition on onClose() to agree with @OnClose
> i.e. the session object passed in has closed. The getXRemote() calls throw
> IllegalStateExceptions, as do any write operations on the session. But the
> developer may still read the other attributes from the session up until the
> end of the onClose()/_at_OnClose call.
>
> Does that sound reasonable ?
>
> 2) Check on batching semantics on RemoteEndpoint (mostly for you Scott !)
>
> Wanted to check on the blocking and async semantics when batching is
> enabled. The following are true:
>
> 1) a blocking write to the batch-buffer that does not cause the
> batch-buffer to be sent returns as soon as the message is put in the
> batch-buffer.
> 2) a blocking write to the batch-buffer that causes the batch-buffer to be
> sent returns as soon as the whole batch-buffer is sent on the wire.
> 3) an async write to the batch-buffer that does not cause the batch-buffer
> to be sent is gets the completed callback as soon as the write to the
> batch-buffer completes.
> 4) an async write to the batch-buffer that causes the batch-buffer to be
> sent is gets the completed callback as soon as whole batch-buffer is sent
> on the wire.
>
> 4/4 ?
>
> Thanks,
>
> - Danny
> --
> <http://www.oracle.com> * Danny Coward *
> Java EE
> Oracle Corporation
>