On 8/1/13 9:53 AM, Joakim Erdfelt wrote:
> inline ...
>
> On Thu, Aug 1, 2013 at 9:39 AM, Danny Coward <danny.coward_at_oracle.com
> <mailto:danny.coward_at_oracle.com>> wrote:
>
> Hi Joakim,
>
>
> On 7/31/13 11:50 AM, Joakim Erdfelt wrote:
>> I have 2 main concerns about the 1.0 API I'd like to see discussed.
>>
>> First, the WebSocketContainer (aka, the Client Container) has no
>> clearly defined lifecycle.
>> When is it to init/start?
>> When is it to finish/stop?
>
> Currently it has to start before the object is handed to the
> developer, and it remains in scope until the developer deferences it.
>
>
> Heh. I think you misunderstood what I meant by lifecycle.
> Seems you think .finalize() is sufficient to clean up the container
> resources.
> Is that really what you expect? (hope not. eesh!)
Hey Joakim,
I'm not saying that that is enough for the container to manage resources
properly, was just trying to describe what happens today in the API. I
agree the responsibility for managing associated resource lands on the
developers' laps and the container can't really do much.
I've filed an issue in the JIRA for .next.
The start/stop idiom would be ok to add, but still you are left with the
problem of bad developers who never call stop. I'm not sure I have a
better idea at this point though.
Thanks for bringing it up,
- Danny
>
>
>>
>> Second, ContainerProvider.getWebSocketContainer() is to return a
>> new instance of a javax.websocket.WebSocketContainer on every
>> call. (per the javadoc)
>>
>> Is this really what is intended?
> Yes. I think the thinking was that some (most) developer may use
> the same instance, but if you want to have a couple instances with
> different default properties, you can.
>
>
> Fair enough.
>
>
>
>> Or, like the server side's
>> javax.websocket.server.ServerContainer, is there to be only 1,
>> and each call to ContainerProvicer.getWebSocketContainer()
>> returns the same instance (with the only nuance being that on a
>> web container, each webapp has its own WebSocketContainer instance)
>>
>> If the implementation has resources that are managed to support
>> the client portions of the WebSocketContainer, when and how do we
>> clean up those resources? As there is no WebSocketContainer
>> lifecycle [such as a .start() and .stop()] then there is no real
>> way to know if the user of the WebSocketContainer is done with it.
>
> Its true. We could look at a defined lifecycle for v2.
>
>>
>> Since API changes are not likely to occur, should we implement
>> some sort of safeguards into the
>> ContainerProvider.getWebSocketContainer() if too many
>> WebSocketContainer references have been requested?
> I think that would be reasonable to do in the meantime. Otherwise,
> perhaps there is a way to use the WebSocketContainer instance as a
> facade a pool of the 'real' container instances or something.
>
>
> A pool of real containers isn't really an option.
> As that would be horribly inefficient use of various pools (thread,
> buffers, connections, etc)
> Seems like, with the current v1 API, the management of shared
> resources would be a provider responsibility, not a container
> responsibility under this assumption.
>
>
> - Danny
>
>
> - Joakim
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation