On 2/1/13 12:29 PM, Danny Coward wrote:
> 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:
>>>>>
>>>>
>>> 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.
Yes, but the application can manage that sync however it wishes
(synchronization or queueing or actors or whatever.)
The problem is that the container doesn't know how the application is
managing the sync to the RemoteEndpoint.
>
> Most of the websocket APIs (pre JSR) support this already, though. Has
> it come up ?
I just noticed it now after thinking through your scenario.
-- Scott
>
> - 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
>