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