On 2/1/13 12:21 PM, Scott Ferguson wrote:
> 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.
Well, its not really just an issue of that style of @WebSocketMessage:
if there is a threading issue, it would also come up whenever any kind
of websocket endpoint tried to send a message from within an onMessage
callback.
Most of the websocket APIs (pre JSR) support this already, though. Has
it come up ?
- Danny
>
> 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
>>
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation