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.
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