Undertow proxy handler + RequestLimit handler issue
by paroczizs
Hi Undertow Dev,
we built a custom integration component based on Wildfly 11 with Undertow
1.4.18. The application contains a couple of custom and built in handlers.
We found the following:
There is a RequestLimit handler right at the beginning and finally the
proxy handler. When the backend getting to be slow and the load is
relatively high the RequestLimit handler does its job queues the request
then throws the request above the queue. When the proxy times out it starts
to consume the queue, in some cases the exception below occurs and we found
that in this case the counter in the RequestLimit handler is not reduced
and the it can stuck the way to the backend.
Are there any possibility to handle the exception in a custom handler?
Thank you in advance, Zsolt
2018-11-28 12:02:19,518 ERROR [io.undertow.proxy] (default I/O-2) UT005028:
Proxy request to /lwi/optinus/getentityanswersservice failed:
java.nio.channels.ClosedChannelException
at
io.undertow.client.http.HttpClientConnection$5.handleEvent(HttpClientConnection.java:194)
at
io.undertow.client.http.HttpClientConnection$5.handleEvent(HttpClientConnection.java:173)
at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at
org.xnio.StreamConnection.invokeCloseListener(StreamConnection.java:80)
at org.xnio.Connection.close(Connection.java:142)
at org.xnio.IoUtils.safeClose(IoUtils.java:152)
at io.undertow.util.ConnectionUtils$3.run(ConnectionUtils.java:102)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
1 month, 2 weeks
Creating a websocket proxy with undertow
by Marc Boorshtein
Using the 1.4 series, I'm trying to handle upgrade and websockets. Looking
at a few examples and the code I think what I need to do is:
1. add the WebSocketServlet to the right path
2. implement WebSocketConnectionCallback that will call my remote ws://
server
Am I on the right track? I haven't found an example of doing this with
undertow but found something similar with jetty (
https://github.com/chipster/chipster-web-server/blob/master/src/main/java...)
but I havne't found the same thing for undertow so any pointers would be
appreciated.
Thanks
Marc Boorshtein
2 months, 2 weeks
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
3 months, 1 week
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, 8 months
Undertow 3.0 Announcement
by Stuart Douglas
The Java network programming world has come a long way since Undertow was
first started. Netty has emerged as the de-facto standard for network
programming in Java, and the Undertow team has decided that the benefits of
utilising Netty outweigh any benefits in keeping our XNIO based transport
layer.
Undertow 3.0 will keep Undertow’s programming model, however the underlying
transport will be changed from XNIO to Netty. We will also use the Netty
HTTP/1, HTTP/2 and Websocket implementations. We believe this change will
have a number of advantages:
-
It will allow other Netty based services (e.g GRPC) to share the same
HTTP port
-
It allows sharing of threads between Undertow and other Netty based
services, resulting in services using less resources
-
The underlying transport implementation are the most complex part of
Undertow, delegating this to Netty will significantly reduce the work
needed to maintain Undertow
As part of this Flavia Rainone will be taking over as project lead from
Stuart Douglas so he can focus on the recently announced Quarkus project,
however Stuart will continue to be heavily involved in Undertow for the
foreseeable future.
Flavia Rainone has been involved in JBoss community since 2002 and has an
extensive background on Remoting and Xnio. In the past years, she acted as
EJB component lead for WildFly, besides contributing to several projects
in WildFly, such as IronJacamar, JBoss MSC and XNIO, and also Byteman. All
this makes her a good fit for taking over Undertow leadership.
What does this mean for me?
What this means for you will depend on which parts of Undertow you are
using:
-
If you are using the Servlet API then you will likely not notice any
change. You will need some different dependencies (Netty instead of XNIO),
however the rest of the experience should be mostly identical
-
If you are using the low level Undertow HttpHandler and
HttpServerExchange and you want to use Undertow 3.0 then you will need to
migrate your application. For the most part this migration should be
straightforward, as most concepts from the old API directly map to the new
API.
Road Map
2.x
The existing Undertow 2.x branch will continue to be maintained for the
foreseeable future. It will receive bug and security fixes, and some
features, however it is unlikely to receive any more low level transport
oriented features (e.g. HTTP/3 support). For now it is a perfectly valid
choice to stay on Undertow 2 while the new Netty based implementation
matures.
3.x
A 3.0 final version should be released in the next few months, however in
the short term the 3.x branch will not provide the same level of API
compatibility that Undertow has traditionally provided. As the Netty
implementation is new this will allow us to potentially fix any issues we
find with our approach without being locked in to supporting an API that is
not ideal.
This is a great time to try out the new API and report and problems or
suggestions. Note that this is explicitly referring to the core
HttpServerExchange based API, no major plans are expected to the Servlet
API (i.e. ServletExtension and DeploymentInfo).
4.x
After a short 3.x cycle we are planning on releasing a 4.x that will
provide API stability, in the same way that Undertow 1.x and 2.x have.
How can I contribute
You can contribute to Undertow in the same way it has always been done.
We have an email list open for discussion here: undertow-dev(a)lists.jboss.org
Jira issues can be accessed here:
https://issues.jboss.org/projects/UNDERTOW/issues
And source code for 3.x is here:
https://github.com/undertow-io/undertow/tree/3.0.x
Also, with the move from HipChat to Zulip in Wildfly team, you can now
access Undertow stream via Zulip at https://wildfly.zulipchat.com/
6 years, 11 months
Discarded Exception in SSL handshake
by Christian Riege
Hi,
we recently noticed the hard way that when the SSL Handshake in io.undertow.protocols.ssl.SslConduit encounters an Exception, that Exception is silently discarded (SslConduit lines 1083ff in Undertow 2.0.21-SNAPSHOT).
try {
doHandshake();
} catch (IOException | RuntimeException | Error e) {
IoUtils.safeClose(connection);
}
This makes it extremely tedious and difficult to analyse any issues in this phase as the Exception that does eventually happen and bubble to the caller looks like this:
8< snip >8
java.nio.channels.ClosedChannelException
at io.undertow.protocols.ssl.SslConduit.write(SslConduit.java:369)
at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
at io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1276)
at io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:592)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:472)
8< /snip >8
There’s no indication in the stack that this is _really_ due to an earlier SSLHandshakeException which looks like this:
8< snip >8
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1521)
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:528)
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:802)
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:766)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:757)
at io.undertow.protocols.ssl.SslConduit.doHandshake(SslConduit.java:648)
at io.undertow.protocols.ssl.SslConduit.access$900(SslConduit.java:63)
at io.undertow.protocols.ssl.SslConduit$5$1.run(SslConduit.java:1084)
... 2 more
(Stack eventually shows this is due to an expired certificate:
Caused by: java.security.cert.CertificateExpiredException: NotAfter: Mon Apr 13 01:59:59 CEST 2015)
8< /snip >8
We have tried the naïve solution of taking the encountered Exception, wrap it into a RuntimeException (because that’s the only way to escalate it from the Runnable#run() method) and this yields limited success:
The Good News is that the RuntimeException is reported on System.err:
ERROR: XNIO000011: Task io.undertow.protocols.ssl.SslConduit$5$1@286a7112 failed with an exception
java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at io.undertow.protocols.ssl.SslConduit$5$1.run(SslConduit.java:1088)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:592)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:472)
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
The Bad News is that the original Exception (see above) is what is propagated to the calling code; i.e. as a user of the library I still get a rather obscure error rather than the SSLHandshakeException which provides me with the root cause.
We have looked through the code in SslConduit but to be frank we don’t really grok what’s happening in there.
I would like to kindly ask if anyone here can provide some guidance or can pick up this issue. I’m more than happy to file this as a proper issue in the Issue Tracker and do a Pull-Request on GitHub; however the current „patch“ of simply throwing a new RuntimeException(e) is too trivial as well as inadequate.
Kind regards,
Christian
--
Riege Software International GmbH
Mollsfeld 10, 40670 Meerbusch, Germany, T: +49 2159 9148 0, F: +49 2159 914811, www.riege.com
Managing Directors: Christian Riege, Gabriele Riege, Dr. Tobias Riege
Commercial Register: Amtsgericht Neuss HRB-NR 4207, VAT Reg No.: DE120585842
YOU CARE FOR FREIGHT, WE CARE FOR YOU
7 years
Undertow with Proxy Protocol enabled doesn't send Certificate Request header (for mutual TLS)
by Ulrich Herberg
Hi,
I noticed that when using the Proxy Protocol (using Undertow 2.0.20.Final
behind an AWS Network Load Balancer), mutual TLS doesn't work: The server
doesn't send the Certificate Request as part of the Server Hello.
I compared it with disabling Proxy Protocol on the load balancer, and then
it works correctly, Undertow includes the Certificate Request, and
therefore the client sends its certs. I am trying to understand what the
cause is; there are some differences in Undertow.java when using the Proxy
Protocol (which in itself shouldn't modify the TCP contents, and therefore
not cause this change of behavior):
if (listener.useProxyProtocol) {
ChannelListener<AcceptingChannel<StreamConnection>> acceptListener =
ChannelListeners.openListenerAdapter(new
ProxyProtocolOpenListener(openListener, xnioSsl, buffers,
socketOptionsWithOverrides));
sslServer = worker.createStreamConnectionServer(new
InetSocketAddress(Inet4Address.getByName(listener.host), listener.port),
(ChannelListener) acceptListener, socketOptionsWithOverrides);
} else {
ChannelListener<AcceptingChannel<StreamConnection>> acceptListener =
ChannelListeners.openListenerAdapter(openListener);
sslServer = xnioSsl.createSslConnectionServer(worker, new
InetSocketAddress(Inet4Address.getByName(listener.host), listener.port),
(ChannelListener) acceptListener, socketOptionsWithOverrides);
}
Not sure if this xnioSSL vs worker has anything to do with it. Thoughts?
Best regards
Ulrich
7 years, 1 month
Undertow supoprts a uncompress option for a request body but lacks documention how to enable that in latest wildlfy
by billy
Hi,
Undertow supports a uncompress option for a request body but lacks
documentation on how to enable that in latest wildlfy standalone.xml
configuration file.
We are currently migrating from Apache / Glassfish to Wildfly and depend
heavily on sending compressed request which Apache handles with no problems
but
so far we find no documentation on how to configure undertow / wildfly to do
the same.
Any help on this desperately needed.
Thanks
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
7 years, 1 month
