jsr356-experts@websocket-spec.java.net

[jsr356-experts] Re: [jsr356-users] Next set of issues

From: Danny Coward <danny.coward_at_oracle.com>
Date: Fri, 01 Feb 2013 11:19:53 -0800

On 1/31/13 5:58 PM, Scott Ferguson wrote:
> On 1/31/13 5:13 PM, Danny Coward wrote:
>> Hi folks,
>>
>> I'm going to try to solve a bunch of issues at once in this email. As
>> usual, please call out if something does not look right to you.
>>
>>
>>
>> * Semantics of send after the session is closed.
>> (http://java.net/jira/browse/WEBSOCKET_SPEC-104)
>>
>> I updated the session methods to throw IllegalStateExceptions if the
>> Session has been closed, and the remoteendpoint.send methods have
>> adequate IOException sigs to cover the case when the developer
>> attempts an API call, but what is the implementation to do in this case
>> @WebSocketMessage
>> public String handle(String message, Session session) {
>> try {
>> session.close();
>> return something;// ???
>> }catch (IOException e) {
>> }
>> return "message";
>> }
>> }
>>
>> The handle method has to complete, but since the session has closed,
>> the message cannot be delivered. I suggest we require the
>> implementation raise an IOException - something like
>> IOException("Cannot deliver message, session closed") and run that
>> into the error handling method so the developer has a chance to deal
>> with this situation it if he elects to.
>
> The message is received in this case, because the server hasn't
> received the client's close yet.
Yes I agree with you the message is received, but the code sample is
trying to illustrate something a bit different: the session.close() call
after the message is received closes the connection, but the question is
what happens to the return value of the handle method ? Can it be
delivered to the remote peer ?

I'm thinking the answer is no, and the developer should get some kind of
exception - as described.


>
> session.close() initiates a graceful close from the server side. It
> cannot send messages, but it can receive messages until it receives
> the @WebSocketClose. That way, messages that are in flight when the
> server initiates the close are delivered properly. (This was the
> purpose of adding an explicit close frame to the spec.)
>
> I'd think calling close() multiple times would be allowed without an
> exception. I don't see any harm.
>
> -- Scott
>


-- 
<http://www.oracle.com> 	*Danny Coward *
Java EE
Oracle Corporation