What happened to JSR356 Client Container LifeCycle stop?

[mpsrig]

https://bugs.eclipse.org/bugs/show_bug.cgi?id=423646#c0

I can reproduce this bug in 9.4.11.v20180605

The supposed fix was 44a7d23

This can be easily reproduced with https://github.com/jetty-project/embedded-jetty-websocket-examples/tree/master/javax.websocket-example ; simply commenting the call to stop() at https://github.com/jetty-project/embedded-jetty-websocket-examples/blob/master/javax.websocket-example/src/main/java/org/eclipse/jetty/demo/EventClient.java#L38 causes the client to never exit.

@joakime

[joakime]

JSR356 Client Container has no LifeCycle.

See: jakartaee/websocket#212

Our past addition of it breaks our spec compliance.

The layers present in JSR356 makes this even more difficult ...

JSR356 Client Container -> WebSocket Client -> Http Client

You'd have to unwrap down to the HttpClient to initiate the stop any more.
The upcoming support for the new WebSocket over HTTP/2 drafts also complicates this even further.

[joakime]

The design of the JSR356 Client Container is that it exists for the life of the JVM.
You have limited control over the JSR356 Client Container, its part of the design of the JSR356 container.
There are many limitations in the JSR356 Client Container.
Eg:

• You can't set/configure Proxy support.
• You can't set/configure SSL/TLS support.

It's best if you think of the JSR356 Client Container as a Web Browser, you start it, then use it to perform many connections to different resources / endpoints, without closing the Web Browser.
The Web Browser is heavy weight, and so is the JSR356 Client Container (by design).

[mpsrig]

@joakime I'm not sure if those comments were addressed to me? The issue I am trying to report is that this down-casting hack is necessary, when it should not be.

[mpsrig]

Perhaps this is naive, but it seems that the implementation could (easily) automatically clean up after itself when the number of active connections drops to 0.

[joakime]

I sense you are finding that the Jetty JSR356 Client Container uses too many resources.
That's probably true, especially in light of (the recent) Issue #2655 (being worked on).

[mpsrig]

That's not so much my concern; my goal is to not be writing unnecessary platform-specific (Jetty-specific) code; after all that's the whole reason for using JSR356.

[joakime]

There's nothing to do here, as JSR356 (javax.websocket) has no lifecycle, no stop, no close, no shutdown. Once you create the Client container it's live for the entirety of the JVM's runtime.
In the future, should a new API arise in javax.websocket, we'll create a new issue to add that feature/functionality.