inline ...
On Thu, Aug 1, 2013 at 9:39 AM, Danny Coward <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!)
>
> 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