Uploaded image for project: 'Red Hat Fuse'
  1. Red Hat Fuse
  2. ENTESB-3995

Camel WebSocket does not restart on camelContext

XMLWordPrintable

    • % %
    • Hide

      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.

      Show
      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.
    • 6.3 Sprint 4 (Mar 28 - Apr 29)

      Here's the query reference, http://camel.465427.n5.nabble.com/A-restarted-websocket-endpoint-no-longer-accepts-client-connections-td5760156.html

      The websocket never really gets registered in the camelContext when the context is restarted. This prevents any new client connections to fail with the HandShake exception.
      Attached you will find reproducers for this,

      camel-example-twitter-websocket.zip \src\main\java\org\apache\camel\example\websocket\CamelTwitterWebSocketMain.java and TwitterWebSocketRoute.java. The code is completely linear, excepting for a small modification to the camel route in that second file. There are large blocks of text that are put to stdout between the steps describing exactly what is being done.

      For the client side - WebsocketListenerForRedhat.zip, the complete source was in \source\testapp\TestApp.java and WebsocketClientEndpoint.java. When run, all that this program does is connect to the websocket and reflect anything that is received to stdout. It will exit by exception or Control-C. It may also time-out, but you only need to run it for a few seconds to prove the condition.

        1. camel-example-twitter-websocket.ExampleWithRouteBuilderActivity.tar.gz
          65 kB
        2. camel-example-twitter-websocket.zip
          70 kB
        3. websocket_test.zip
          7 kB
        4. websocket-client-maven.zip
          4 kB

              mbasovni Martin Basovnik (Inactive)
              rhn-support-vgohel Viral Gohel (Inactive)
              Martin Basovnik Martin Basovnik (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: