Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Closing a jaxa.websocket.WebSocketContainer in Jetty 9.1

Thanks.
I'm trying to make a library that both can be used standalone and in a jsr 356 container.
Guess there is no away around 2 different versions.

But again, sorry if I am repeating myself.
Why can't jetty start the threads as daemon threads?

I do have users that might not remember to close the library in a finally block.
Which is needed, for example, if some exception is thrown.

- Kasper









On Mon, Jan 6, 2014 at 6:33 PM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
That is an open bug with no good solution (yet)


There are 2 current workarounds on standalone client use at the moment.

1) use System.exit() on your standalone when you want to shutdown cleanly.

package jetty.jsr356;

import java.net.URI;
import java.util.concurrent.CountDownLatch;

import javax.websocket.ClientEndpoint;
import javax.websocket.CloseReason;
import javax.websocket.ContainerProvider;
import javax.websocket.OnClose;
import javax.websocket.WebSocketContainer;

@ClientEndpoint
public class TestClientA
{
    private CountDownLatch closeLatch = new CountDownLatch(1);

    @OnClose
    public void onClose(CloseReason close)
    {
        closeLatch.countDown();
    }

    public void waitForClose() throws InterruptedException
    {
        closeLatch.await();
    }

    public static void main(String[] args)
    {
        try
        {
            WebSocketContainer ws = ContainerProvider.getWebSocketContainer();

            TestClientA socket = new TestClientA();
            ws.connectToServer(socket,new URI("ws://wuhu.wuhu"));
            socket.waitForClose();
        }
        catch (Throwable t)
        {
            t.printStackTrace();
        }
        finally
        {
            System.exit(0);
        }
    }
}


2) or use the Jetty specific lifecycle to shutdown the container.


package jetty.jsr356;

import java.net.URI;
import java.util.concurrent.CountDownLatch;

import javax.websocket.ClientEndpoint;
import javax.websocket.CloseReason;
import javax.websocket.ContainerProvider;
import javax.websocket.OnClose;
import javax.websocket.WebSocketContainer;

import org.eclipse.jetty.util.component.LifeCycle;

@ClientEndpoint
public class TestClientB
{
    private CountDownLatch closeLatch = new CountDownLatch(1);

    @OnClose
    public void onClose(CloseReason close)
    {
        closeLatch.countDown();
    }

    public void waitForClose() throws InterruptedException
    {
        closeLatch.await();
    }

    public static void main(String[] args)
    {
        try
        {
            WebSocketContainer ws = ContainerProvider.getWebSocketContainer();

            try
            {
                TestClientB socket = new TestClientB();
                ws.connectToServer(socket,new URI("ws://wuhu.wuhu"));
                socket.waitForClose();
            }
            finally
            {
                if (ws instanceof LifeCycle)
                {
                    ((LifeCycle)ws).stop();
                }
            }
        }
        catch (Throwable t)
        {
            t.printStackTrace();
        }
    }
}



--
Joakim Erdfelt <joakim@xxxxxxxxxxx>
Expert advice, services and support from from the Jetty & CometD experts


On Mon, Jan 6, 2014 at 9:37 AM, Kasper Nielsen <kasperni@xxxxxxxxx> wrote:
just following up on an old thread.

Would it be possible to at least mark all jetty threads as daemon threads?


A simple test like this is stuck forever. Because all the jetty threads are non daemon threads

@ClientEndpoint

public class Test {

    public static void main(String[] args) throws Exception {

        WebSocketContainer ws = ContainerProvider.getWebSocketContainer();

        ws.connectToServer(new Test(), new URI("ws://wuhu.wuhu"));

    }

}


Cheers
  Kasper






On Mon, Sep 9, 2013 at 6:25 PM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
The JSR-356 websocket containers do not have a lifecycle.
It is expected that you request only 1 WebSocketContainer and use it for the life of your JVM.

Avoid using ContainerProvider.getWebSocketContainer() multiple times.

Note, if all you are wanting is a container suitable for instantiating outgoing connections from a web application, then you can access the ServerContainer from
ServerContainer container = (ServerContainer) HttpServletRequest.getAttribute("javax.websocket.server.ServerContainer");

There is only ever 1 of those (per web application)
From there you can use the container.connectToServer() calls like before.


--
Joakim Erdfelt <joakim@xxxxxxxxxxx>
Expert advice, services and support from from the Jetty & CometD experts


On Mon, Sep 9, 2013 at 7:18 AM, Kasper Nielsen <kasperni@xxxxxxxxx> wrote:
Hi,

I'm trying to port an existing Jetty 9.0 websocket implementation to javax.websocket.

I'm creating a WebSocketContainer using 
  WebSocketContainer container = ContainerProvider.getWebSocketContainer();
which will pick up an instance of ClientContainer/ServerContainer.

What is the preferred way to shut down the container again seeing that WebSocketContainer does not have lifecycle methods?

((org.eclipse.jetty.util.component.ContainerLifeCycle) container).stop();
works but depends on the Jetty implementation.

Cheers
  Kasper

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users



_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users



_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users



_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users


Back to the top