Camel WebSocket does not restart on camelContext

1. camel-example-twitter-websocket.zip – This is a simplified version of the 'camel-twitter-websocket' example from the camel distribution. 2. WebsocketListenerForRedhat.zip – This is the websocket client application which makes a call to the twitter example above. Run the 'camel-example-twitter-websocket.zip ' using 'mvn exec:java'. Observe the stdout text. During the first 60 seconds of that server run, run the client code, 'WebsocketListenerForRedhat.zip' from a different command prompt. At the question from the client hit the 1 key and then the <enter> key - it should then successfully connect to the websocket being served by the server side application. No data flows in this test, but you will see a successful connection message and no exceptions. (It says "<opening websocket>" which is followed by a line of dashes. If that message is followed by nothing else, this is a successful connection). If you hit Control-C (and "Y" to terminate the batch if asked) and re-run the client again, it should once again connect successfully as long as the server code is in the first 60 seconds of its run. After 60 seconds, the server side makes the Camel updates that I've described elsewhere in this problem report - you will see this described in the server side stdout. It then waits another 60 seconds in this state. Re-run the client the same way you did in the previous step during this 60 second period. At this point you should see the exception trail concerning the Handshake error on the client side. Re-run the client and you see the same result for the next 60 seconds. This looks like a problem, You will get the exception stack trace as, Exception in thread "main" java.lang.RuntimeException: javax.websocket.DeploymentException: Handshake error. at testapp.WebsocketClientEndpoint.<init>(WebsocketClientEndpoint.java:34) at testapp.TestApp.main(TestApp.java:42) Caused by: javax.websocket.DeploymentException: Handshake error. at org.glassfish.tyrus.client.ClientManager$3$1.run(ClientManager.java:636) at org.glassfish.tyrus.client.ClientManager$3.run(ClientManager.java:673) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.glassfish.tyrus.client.ClientManager$SameThreadExecutorService.execute(ClientManager.java:826) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:496) at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:366) at testapp.WebsocketClientEndpoint.<init>(WebsocketClientEndpoint.java:30) ... 1 more Caused by: org.glassfish.tyrus.core.HandshakeException: Response code was not 101: 404. at org.glassfish.tyrus.client.TyrusClientEngine.processResponse(TyrusClientEngine.java:419) at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientFilter.handleHandshake(GrizzlyClientFilter.java:343) at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientFilter.handleRead(GrizzlyClientFilter.java:313) at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561) at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545) at java.lang.Thread.run(Thread.java:745) After another 60 seconds the server side will make one more transition - all it does is stop and start the camel context, and once again waits. Re-run the client code the same way you have in the previous two steps and you should see that the websocket now connects. This does not look an acceptable workaround, the reproducer includes it to show that the camel configuration commands executed in the second part of this exercise were good enough to properly describe the websocket to camel.