On 2/1/13 11:19 AM, Danny Coward wrote:
> 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.
>
Oh. I see. Hmm.
(To be honest, I'm not a fan of the RPC-style use of @WebSocketMessage.)
The message can't be sent, of course.
You know, there might be a significant concurrency problem with the RPC
mode, because the application normally manages the concurrency of the
RemoteEndpoint, but in the RPC mode the container is sending a message,
which would likely introduce a threading problem between the container
and the application.
That concurrency problem is basically what this issue is running into.
The application knows the RemoteEndpoint is shutdown, but the RPC-mode
isn't synchronized with the application.
-- Scott
>
>>
>> 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
>