Issue with Undertow Client and SSL
by Thomas Segismont
Hi,
Openshift Origin uses Hawkular Metrics to store node and container data. In
this scenario, Hawkular Metrics calls the Kubernetes master server over
HTTPS to validate the client identity. This is implemented with Undertow
Client, as part of a ServletExtension (inside Wildfly 10) [1]. Works fine
in development and testing.
Now the Openshit team sees errors in the logs [2][3]. I couldn't reproduce
yet. Errors come in pair, first the "UT005001: An exception occurred
processing the request: java.lang.IllegalStateException: XNIO000017: Buffer
was already freed", and just after "XNIO001007: A channel event listener
threw an exception: java.lang.NullPointerException".
Does that ring a bell? I haven't been able to find a starting point by
looking into the source the code.
Thanks
--
Thomas Segismont
JBoss ON Engineering Team
[1] https://git.io/vrNyP
[2] https://issues.jboss.org/browse/HWKMETRICS-408
[3] https://issues.jboss.org/secure/attachment/12405779/hawkular.log
1 week, 4 days
Correctly shutting down a websocket handler
by Robin Anil
When a client disconnects, I see that onClose is not being fired. The only
way this seems to be firing if client sents a close frame.
Is there any way to detect disconnection and immediately close all the
opened resources.
Robin
Robin Anil | Software Engineer
2 years, 5 months
WebRTC Support?
by Hicks, Matt
Is there any support or third-party integrations to support WebRTC in
Undertow?
6 years, 5 months
Undertow load test with single vs multiple clients
by Ravitej Akula
Hi,
I am trying to tune Undertow for our high traffic application and as part
of that I am running a load test from a client host (different from the
host where undertow is running) that calls endpoints that involve writing
multiple 1-1.5 MB files to disk.
These are two scenarios that I run the load test:
1) Single client with 100 concurrent threads , each thread uploads files
of size > 1 MB and repeats the process for 2 minutes
2) Two clients each with 50 concurrent threads, each thread uploads files
of size > 1 MB and repeats the process for 2 minutes
Observations:
In the first scenario, I am seeing a latency of about 5 secs per upload.
In the second scenario, I am only seeing a latency of 2.5 secs per upload.
I am calculating the latency at the client.
I've checked the number of connections open to the server in both cases and
they are around 100 at the server.
Is there any setting on the server side that would explain this behavior?
Since the number of connections are same shouldn't the latency be same more
or less in both scenarios?
I have 32 IO Threads and 160 Worker threads with a Backlog of 1000
configured at the server.
Thank you for all the help.
-Ravi
6 years, 5 months
java.io.IOException: Connection reset by peer
by Jocke Eriksson
Hi we are using jboss EAP in production as an API gateway and we have a problem with the communication to some of our servers.
We can see this in our logs.
2019-09-13 08:57:31,337 +0200 DEBUG [io.undertow.client] (default-undertow I/O-21) Connection closed with IOException: java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method) [rt.jar:1.8.0_222]
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) [rt.jar:1.8.0_222]
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) [rt.jar:1.8.0_222]
at sun.nio.ch.IOUtil.read(IOUtil.java:192) [rt.jar:1.8.0_222]
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) [rt.jar:1.8.0_222]
at org.xnio.nio.NioSocketConduit.read(NioSocketConduit.java:289) [xnio-nio.jar:3.4.3.Final-redhat-1]
at org.xnio.conduits.PushBackStreamSourceConduit.read(PushBackStreamSourceConduit.java:52) [xnio-api.jar:3.4.3.Final-redhat-1]
at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) [xnio-api.jar:3.4.3.Final-redhat-1]
at io.undertow.client.http.HttpClientConnection$ClientReadListener.handleEvent(HttpClientConnection.java:510)
at io.undertow.client.http.HttpClientConnection$ClientReadListener.handleEvent(HttpClientConnection.java:473)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api.jar:3.4.3.Final-redhat-1]
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api.jar:3.4.3.Final-redhat-1]
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio.jar:3.4.3.Final-redhat-1]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio.jar:3.4.3.Final-redhat-1]
2019-09-13 08:57:31,339 +0200 ERROR [io.undertow.proxy] (default-undertow I/O-21) UT005028: Proxy request to /*****/******* failed: java.io.IOException: UT001000: Connection closed
at io.undertow.client.http.HttpClientConnection$ClientReadListener.handleEvent(HttpClientConnection.java:516)
at io.undertow.client.http.HttpClientConnection$ClientReadListener.handleEvent(HttpClientConnection.java:473)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api.jar:3.4.3.Final-redhat-1]
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api.jar:3.4.3.Final-redhat-1]
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio.jar:3.4.3.Final-redhat-1]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio.jar:3.4.3.Final-redhat-1]
The client receives a HTTP 503 response,
any advice on how we can solve this is very welcome.
Also it looks like we are setting up a lot of new connections, I was thinking it would be kept alive a bit longer.
2019-09-13 08:57:46,696 +0200 DEBUG [io.undertow.client] (default-undertow I/O-11) Connection to ********************:8080 was closed by the target server
2019-09-13 08:57:47,019 +0200 DEBUG [io.undertow.client] (default-undertow I/O-17) Connection to ********************:8080 was closed by the target server
2019-09-13 08:57:47,117 +0200 DEBUG [io.undertow.client] (default-undertow I/O-7) Connection to ********************:8080 was closed by the target server
2019-09-13 08:57:47,427 +0200 DEBUG [io.undertow.client] (default-undertow I/O-9) Connection to ********************:8080 was closed by the target server
2019-09-13 08:57:47,552 +0200 DEBUG [io.undertow.client] (default-undertow I/O-9) Connection to ********************:8080 was closed by the target server
2019-09-13 08:57:47,552 +0200 DEBUG [io.undertow.client] (default-undertow I/O-6) Connection to ********************:8080 was closed by the target server
2019-09-13 08:57:47,634 +0200 DEBUG [io.undertow.client] (default-undertow I/O-28) Connection to ********************:8080 was closed by the target server
2019-09-13 08:57:48,200 +0200 DEBUG [io.undertow.client] (default-undertow I/O-9) Connection to ********************:8080 was closed by the target server
2019-09-13 08:57:48,205 +0200 DEBUG [io.undertow.client] (default-undertow I/O-15) Connection to ********************8080 was closed by the target server
6 years, 5 months
