Uploaded image for project: 'Undertow'
  1. Undertow
  2. UNDERTOW-284

Application exceptions make Undertow force-close client

    Details

    • Steps to Reproduce:
      Show
      Clone: https://github.com/MartinanderssonDotcom/websocket-exception-handling
    • Workaround Description:
      Hide

      The application may move the @OnMessage annotation to another method which decorate the real message handler with a try-catch statement. If RuntimException is caught, that exception can be forwarded to @OnError programmatically. I don't know what implications this might have for the runtime performance and stability of the server.

      Show
      The application may move the @OnMessage annotation to another method which decorate the real message handler with a try-catch statement. If RuntimException is caught, that exception can be forwarded to @OnError programmatically. I don't know what implications this might have for the runtime performance and stability of the server.
    • Estimated Difficulty:
      Low

      Description

      The version affected, as far as I know, is 1.0.15 that WildFly 8.1.0 use. But I could not select that version in the list.

      If @OnMessage throw a RuntimeException, Undertow will force-close the endpoint/websocket without even calling the @OnClose annotated method. Thereafter, the @OnError method is property invoked. However, at this point in time, it is too late for the application to respond appropriately to the client as the websocket has been closed.

      Tyrus, used by GlassFish, does not close the WebSocket. The exception is caught and delivered to @OnError, making it possible for the application to handle the exception as he see fit. Maybe the application has reason to close the client, maybe not.

      I wrote a complete test to illustrate this problem here:
      https://github.com/MartinanderssonDotcom/websocket-exception-handling

      The test project uses Arquillian with two Maven build profiles for GlassFish and WildFly so it's a no-brainer to have the test application running within a few minutes. GlassFish pass the test, WildFly don't.

      The Java API for WebSocket specification (JSR-356) says on page 7 (section 2.1.5 "Closing Connections"):

      "If an open connection to a websocket endpoint is to be closed for any reason, [..] the websocket implementation must invoke the onClose() method of the websocket endpoint."

      In my test case, Undertow brake this principle as @OnClose is not called.

      JSR-356 says on page 24 (section 5.2.2 "Errors Originating in Websocket Application Code"):

      "If the developer has not provided an error handling method on an endpoint that is generating errors, this indicates to the implementation that the developer does not wish to handle such errors."

      Meaning that if the @OnError method is present, the developer wish to handle such errors. This section does not say that the container/implementation may close the endpoint. This is true only for errors that originate from the container itself (see section 5.2.3 "Errors Originating in the Container and/or Underlying Connection").

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                swd847 Stuart Douglas
                Reporter:
                martin.andersson Martin Andersson
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 1 week
                  1w
                  Remaining:
                  Remaining Estimate - 1 week
                  1w
                  Logged:
                  Time Spent - Not Specified
                  Not Specified