I discovered undertow earlier today and its intro page mentions 'Web Sockets' and 'Reverse Proxy' as features.
According to Google and SO there is currently no Java technology that can do Web Socket proxying.
One such post is the following:
Do you think undertow would be up to the task? Has anyone relevant experience?
Many thanks in advance for any pointer.
We are using undertow websocket library for passing back and forth
serialized JSON messages using Websockets.sendText method
On the client side in Chrome we are noticing that that instead of 1 message
we are receiving 2 where the first one is truncated at some 323,821 B and
the second message is of 148,583 but malformed (its text but its garbled)
and therefore not a JSON even if its concatenated with the first message
We are converting protocol buffers to JSON on the server side and can't
point the finger at that code as it had worked for even bigger JSON
To investigate this further I need help ruling out any message size or
frame size limitation on undertow that could cause this. Any pointers here
would be helpful.
I'm creating and testing websockets in my project and I have the following classpath:
This doesn't work:
Caused by: java.lang.ClassCastException: org.glassfish.tyrus.client.ClientManager cannot be cast to io.undertow.websockets.jsr.ServerWebSocketContainer
The code in Bootstrap.java randomly picks an implementation through ServiceLoader and tries to cast it:
Why not load the desired type directly? Should I be able to deploy several websocket implementations? If not, what's the best option for testing?
I have a pretty basic server set up:
ExceptionHandler -> Security Handlers * -> PathTemplateHandler -> my routes
* The security handlers are set up as shown in the examples  and I'm
also using the same `IdentityManager` for my tinkering.
What I'm seeing is that in ExceptionHandler  the request is just passed
directly onto the next handler, which in this case, is the start of the
The request is passed through each handler until it hits
`AuthenticationCallHandler` and is moved off the IO thread . The call
then returns, and all the invocations to the next handler finish back up
the stack until `ExceptionHandler`, where the call completes successfully.
Trouble is, the request was malformed and the route handling it threw an
exception and it wasn't handled as expected.
I guess the correct answer is that I shouldn't have allowed it to get
thrown out of the handler for the route; catch it there and send the
expected error response.
But, I'm curious if there was a way to do this with the handlers, or
perhaps, more generally, what are the expectations along the call chain of
handlers when some may move off the initial IO thread.