jsr356-experts@websocket-spec.java.net

[jsr356-experts] Re: Next set of issues (message object lifetimes)

From: Scott Ferguson <ferg_at_caucho.com>
Date: Fri, 01 Feb 2013 12:54:18 -0800

On 2/1/13 12:12 PM, Danny Coward wrote:
> On 1/31/13 6:11 PM, Scott Ferguson wrote:
>> On 1/31/13 5:13 PM, Danny Coward wrote:
>>> Hi folks,
>>>
>>>
>>>
>>> * Validity of message objects
>>> (http://java.net/jira/browse/WEBSOCKET_SPEC-122)
>>>
>>> Mark and I have exchanged comments over on the JIRA issue for this:
>>> for the message objects that can be passed into the various
>>> MessageHandlers, should they remain valid after the completion of
>>> the onMessage call ? for example if the implementation passes in a
>>> ByteBuffer to represent a binary message, can the developer be sure
>>> that it won't be recycled after the onMessage call has completed.
>>>
>>> I'd say it would be easier for developers if they could uses these
>>> message objects outside the scope of the onMessage call, any other
>>> opinions ?
>>>
>>
>> It's pretty important that these objects be owned by the container
>> and lose scope after the message handler.
>>
>> The need is most clear in the case of InputStream and Reader (because
>> their data is no longer live outside the call). But also ByteBuffer,
>> since that's designed to avoid buffer copies. The underlying data for
>> the ByteBuffer could conceivably be non-heap memory.
> OK. I guess it could get ugly if the developer held on to an
> InputStream and decided to try to read it a month later (!), and I
> think Mark thinks mutable objects should go out of scope too.
>
> Looking through the list of possible message objects in both the
> annotated/programmatic message handlers, we have
>
> String
> Reader
> byte
> ByteBuffer
> InputStream
> Java primitives / class equivalents
> developer objects derived from decoders wholly consuming the incoming
> message.
>
> would you think it reasonable to say that
> Reader/InputStream/ByteBuffer messages should not be references
> outside the scope of the message handler callback, but its ok for
> developers to reference the other types outside that scope ?

+1

That sounds like a good definition.

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