Skip to main content

[jsr356-users] [jsr356-experts] Re: WebSocketContainer lifecycle concerns

  • From: Danny Coward < >
  • To: Joakim Erdfelt < >
  • Cc: ,
  • Subject: [jsr356-users] [jsr356-experts] Re: WebSocketContainer lifecycle concerns
  • Date: Fri, 02 Aug 2013 09:41:48 -0700
  • List-id: <>

On 8/1/13 9:53 AM, Joakim Erdfelt wrote:
inline ...

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

<>   *Danny Coward *
Java EE
Oracle Corporation

[jsr356-users] [jsr356-experts] Re: WebSocketContainer lifecycle concerns

Danny Coward 08/01/2013

[jsr356-users] [jsr356-experts] Re: WebSocketContainer lifecycle concerns

Joakim Erdfelt 08/01/2013

[jsr356-users] [jsr356-experts] Re: WebSocketContainer lifecycle concerns

Danny Coward 08/02/2013
Please Confirm