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
6 months, 3 weeks
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
3 years
Server-Sent Event: support of retry reconnection time
by Cédric Tran-Xuan
Hello,
We are using the Undertow SSE support.
In the SSE spec, it is possible to send a "retry: <time in milliseconds>"
that tells the client to try a reconnection after a certain amount of time (
https://html.spec.whatwg.org/multipage/comms.html#concept-event-stream-re...
).
Right now, we haven't found the ability to send the "retry" via the
Undertow API.
If we look at the ServerSentEventConnection class, you can only send an
event, an id and a data.
So, is it a missing feature or is there a way, we may have missed, to send
the "retry"?
Thanks in advance for the answer!
Best regards,
Cédric.
9 years, 11 months
JSESSIONIDSSO cookie not set in response on Wildfly 9
by Matt Smith
Hi,
I am working on several JEE web apps that are deployed on a Wildfly 9.0.2
application server. We have SSO enabled and working, but are having an
issue where the SSO cookie is not always returned. Specifically, if we
restart the Wildfly instance, two of the several applications deployed on
the server stop returning the JSESSIONIDSSO cookie in their responses. If
we disable and then re-enable those apps then they work perfectly until the
next time Wildfly is restarted.
The issue described occurs in both UAT and Production environments. Both
environments are set up in clustered mode, with the only real difference
being that UAT has more applications deployed on it. The Wildfly instances
also sit behind an Apache HTTPd reverse proxy using mod_proxy. If the
servers are accessed directly - bypassing the Apache server - the problem
does not occur. After much poking around I can only assume that the issue
is triggered by the different headers present on the proxied requests.
That's a guess though and I would really appreciate any input from people
who know Undertow much better.
All of our applications are configured the same way with regards to
security and the technology stack used. Authentication is provided by the
server via a security domain that delegates to a security realm, and is
backed by Active Directory. I have attached the relevant configuration
files and examples of the requests and responses. In terms of versions, I
have reproduced the issue in Wildfly 8.0.2, 9.0.1, 9.0.2, and 10.0.1 (not
sure what Undertow versions they correspond to).
The Wildfly forum had no answers and directed me here, so I hope someone
here can help!
(PS I've changed the actual IP addresses, server names, etc in the attached
files so I don't expose the real systems - I know the IPs aren't valid, but
they are on the real system!)
Thanks,
Matt
9 years, 11 months
exchange.dispatch() deprecation - safe to ignore?
by Michael Hixson
Hello,
I'm using the no-argument version of HttpServerExchange.dispatch(),
and I just noticed that it's deprecated.
I'm using dispatch() to suspend the exchange, to make sure the
exchange isn't completed when the call stack returns. Basically I'm
telling it, "Go to sleep. I'll be back later to finish things."
Is that an inappropriate use of dispatch()?
It's not clear that the suggested alternative of
dispatch(Executor,Runnable) is better in this case. What arguments
would I provide? dispatch(null, () -> {}) ?
-Michael
9 years, 12 months
UT000005: getRequestChannel() has already been called
by paroczizs .
Hi,
we are implementing a proxy solution based on Wildfly/Undertow.
There are a couple of custom handler configured in a row. Two of the
handlers are deal with the incoming request – message validator and message
log.
The message validator use the solution form this class to read the incoming
request:
core/src/main/java/io/undertow/server/handlers/RequestBufferingHandler.java
The message log based on conduits and logs on the exchange complete event.
It works almost perfectly however the first request fails with this when
the log handler registers the conduit:
2016-09-21 10:05:02,034 INFO [hu.telekom.lwi.plugin.log.LwiLogHandler]
(default task-1) [lwiId-lpx1474445101966] LwiLogHandler > start
request/response log handling (FULL)...
2016-09-21 10:05:02,039 ERROR [io.undertow.request] (default task-1)
UT005071: Undertow request failed HttpServerExchange{ POST
/lwi/cnr/getMsisdn request {X-MT-UserId=[pzs], SOAPAction=[""],
X-MT-CorrelationId=[123], Accept-Encoding=[gzip,deflate],
X-Lwi-RequestId=[lwiId-lpx1474445101966],
User-Agent=[Apache-HttpClient/4.1.1 (java 1.5)],
X-SSL-Client-CN=[lwitester1], X-MT-RequestId=[12345],
Content-Type=[text/xml;charset=UTF-8], Content-Length=[798],
Host=[localhost:444]} response {}}: java.lang.IllegalStateException:
UT000005: getRequestChannel() has already been called
at
io.undertow.server.HttpServerExchange.addRequestWrapper(HttpServerExchange.java:1406)
at
hu.telekom.lwi.plugin.log.LwiConduitWrapper.applyConduits(LwiConduitWrapper.java:50)
at
hu.telekom.lwi.plugin.log.LwiLogHandler.handleRequest(LwiLogHandler.java:38)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
hu.telekom.lwi.plugin.validation.ValidationHandler.handleRequest(ValidationHandler.java:78)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
After the first call everything work perfectly there is no error, however
it is true that the exchange.getRequestChannel() was called in the message
validation handler.
Is it any work around for this?
Regards, Zsolt
9 years, 12 months
ProxyHandler timeout handling
by paroczizs .
Hi,
I am using a ProxyHandler with a ProxyClient from a custom handler.
...
ProxyClient lbpc = getProxyClient();
ProxyHandler proxyhandler = new ProxyHandler(lbpc, requestTimeout,
ResponseCodeHandler.HANDLE_404);
...
It handles the timeout correctly however I can see some error after my
handler, the timeout logged properly.
16:43:28,566 INFO [stdout] (default I/O-4) LWI COMPLETED 200 status 200
16:43:28,597 ERROR [io.undertow.proxy] (default I/O-4) UT005027: Timing out
request to /lwi/cnr/getMsisdn
16:43:28,658 ERROR [org.xnio.listener] (default I/O-4) XNIO001007: A
channel event listener threw an exception: java.lang.IllegalStateException:
UT000139: Exchange already complete
at
io.undertow.server.HttpServerExchange.addExchangeCompleteListener(HttpServerExchange.java:916)
at
io.undertow.server.handlers.proxy.ProxyConnectionPool.connectionReady(ProxyConnectionPool.java:315)
at
io.undertow.server.handlers.proxy.ProxyConnectionPool.access$900(ProxyConnectionPool.java:58)
at
io.undertow.server.handlers.proxy.ProxyConnectionPool$1.completed(ProxyConnectionPool.java:278)
at
io.undertow.server.handlers.proxy.ProxyConnectionPool$1.completed(ProxyConnectionPool.java:265)
at
io.undertow.client.http.HttpClientProvider.handleConnected(HttpClientProvider.java:156)
at
io.undertow.client.http.HttpClientProvider.access$000(HttpClientProvider.java:51)
at
io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:127)
at
io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:124)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at
org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:326)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
Is it the normal behavior and nothing to do with it?
Is there a way to catch the timeout error and give some custom response?
Regards, Zsolt
10 years
let's encrypt
by Edgar Espina
Hi,
I'm playing with https://github.com/shred/acme4j, let's encrypt and
undertow. I made some progress but it is hard to test if the certificate
works without and real domain. I'm using ngrok but think there is a problem
there with HTTPS... not sure.
Anyway, I want to know if there is a way to dynamically renew the
certificate at runtime (no downtime).
Don't think is possible with existing API, is it?
Thanks
10 years
Debugging HttpServerExchange cannot have both async IO resumed and dispatch
by Oliver Dain
I'm getting the following exception when I run an integration test, but
only sometimes:
HttpServerExchange cannot have both async IO resumed and dispatch() called
in the same cycle
So clearly I've got some kind of race condition where sometimes I'm doing
things in an odd order, but I can't figure out where. Part of the issue is
that the above error doesn't include a stack trace so it's hard for me to
tell where it is in the code when this happens. Is there a way to get a
stack trace?
Also, I'm calling "exchange.setResponseCookie" after having called dispatch
but before ending the exchange. That should be safe, right? It's the only
thing I can think of. As far as I can tell, what happens is the request
comes in, a few handlers examine the request, but those are read-only
operations for logging and such, then then dispatch to a wrapped handler.
Finally get to our inner-most handler which calls dispatch. That then does
some async work (a lookup in a database) and, when it's complete it sets a
few cookies. After that the response is put on the exchange via
"exchange.getResponseSender().send". Finally a few things listen for the
exchange to complete so they can log some things but these are again
calling read-only properties like "exchange.getStatusCode()",
"exchange.getResponseBytesSent()", and
"exchange.getResponseCookies().keySet())".
Any ideas what might be causing this error?
thanks,
Oliver
--
CTO, Analytic Spot
44 West Broadway #222
Eugene, OR 97401
analyticspot.com • 425-296-6556
www.linkedin.com/in/oliverdain
10 years
Undertow with contextpath
by Sven Kubiak
?Hello,
is there an option to set a contextpath? Or what is the best practice on this?
For e.g., I want to have all request behind a context like "/foo".
Cheers,
Sven
10 years
