inline ...Hey Joakim,
On Thu, Aug 1, 2013 at 9:39 AM, Danny Coward < <mailto: >> wrote:
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!)
Yes. I think the thinking was that some (most) developer may use
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?
the same instance, but if you want to have a couple instances with
different default properties, you can.
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.
I think that would be reasonable to do in the meantime. Otherwise,
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?
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.
[jsr356-users] [jsr356-experts] Re: WebSocketContainer lifecycle concerns