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").