On 25/02/2013 16:42, Danny Coward 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 ?
Yes. Can we add something that makes it explicitly clear that the close
frame has been sent (or at least tried to have been sent) to the client
before this method is called. Not sure if we want to add that if the
close was server initiated then the client will continue to send
messages until it receives the close and reference section 5.5.1 of RFC6455.
> 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.
+1
> 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.
I think it returns:
- after the buffer has been written to the wire
- and after the write has been written to the (now empty buffer|wire)
(the message be be written directly to the wire if it is too big for the
buffer)
> 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.
+1
> 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.
Same as 2.
> 4/4 ?
Yes, with the clarifications above about the message that triggered the
flush.
Mark