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
permessage-deflate extension is not supported, getInstalledExtensions() returns empty set in ServerWebSocketContainer.java
by PingShan Li
--- Problem:
client's request for compression is ignored.
The client sends the request for compression:
Sec-WebSocket-Extensions: permessage-deflate; client_no_context_takeover; client_max_window_bits\r\n
Webserver receives the client request,
org.springframework.web.socket.server.support.AbstractHandshakeHandler.java:
doHandshake function: try to see if requested extension is supported
String subProtocol = selectProtocol(headers.getSecWebSocketProtocol(), wsHandler);
List<WebSocketExtension> requested = headers.getSecWebSocketExtensions();
List<WebSocketExtension> supported = this.requestUpgradeStrategy.getSupportedExtensions(request);
List<WebSocketExtension> extensions = filterRequestedExtensions(request, requested, supported);
getSupportedExtensions calls into the following function, which always returns empty set for installed extensions.
io.undertow.websockets.jsr.ServerWebSocketContainer.java:
public Set<Extension> getInstalledExtensions() {
return Collections.emptySet();
}
My question is:
how to tell spring framework that the permessage-deflate extension is supported by undertow?
Environement:
Undertow 1.3.22 Final is used by springframework:
+- org.springframework.boot:spring-boot-starter-undertow:jar:1.3.5.RELEASE:compile
[INFO] | | +- io.undertow:undertow-core:jar:1.3.22.Final:compile
[INFO] | | +- io.undertow:undertow-servlet:jar:1.3.22.Final:compile
[INFO] | | +- io.undertow:undertow-websockets-jsr:jar:1.3.22.Final:compile
Thanks
9 years, 8 months
Websocket proxy: monitor (in)activity
by Frederick Michielssen
Hi,
Our application uses Undertow to serve a Spring-boot application, as well as proxy websocket connections to a backend server.
Now we would like to monitor activity on the websocket, so that specific resources can be freed when the websocket has been inactive for a long time.
Is there an appropriate way we can detect this in Undertow? Maybe some timeout setting that can be used for this purpose?
-Frederick
9 years, 8 months
Issue with SOAP application deployment with https
by Thomas Walas
Hi all,
this is my first to post undertow-dev, so I hope I'm at the right location.
My problem is deploying a SOAP application on a ssl secured Wildfly 10.
The webservice subsystem complains about a non-present wsdl port it can run HTTP/1.1 on. It used to get this information from the web subsystem, but with Undertow this functionality seems to have been removed.
The result is a failing SOAP deployment, a work-around would be to set <wsdl-secure-port/> in the webservice subsystem.
Can you provide a fix to reenable the forwarding of the secured http port to the webservice subsystem?
Thanks in advance!
Thomas Walas
9 years, 8 months
Websocket connections and IO thread affinity
by peter royal
(I believe the following is true... please correct me if not!)
I have an application which heavily utilizes web sockets. It is an
internal application which uses a small number of connections with
reasonable load on each.
When a new connection is received by Undertow, there is an
at-connection-time assignment of an XNIO IO Thread to the connection.
This is causing uneven load on my IO threads, due to chance.
I'm increasing the number of IO threads as a temporary fix, but it might
be useful to be able to either migrate a long-lived connection to
another IO thread (harder) or do better load balancing amongst IO
threads. For the latter, if Undertow was able to provide a strategy for
picking a thread in NioXnioWorker.getIoThread(hashCode), it could try
and pick a thread that had fewer connections assigned to it.
Has anyone else run into this problem? Would a fix be accepted?
-pete
--
(peter.royal|osi)(a)pobox.com - http://fotap.org/~osi
9 years, 8 months
Fwd: File descriptor in bad state
by Toby Crawley
This came in from an Immutant user on Solaris - are there any known
undertow issues on Solaris? Is it a platform you even test on?
This is using Undertow 1.3.0.Beta9 - we're using 1.3.23.Final in
Immutant HEAD, so can have the user try that if you think it might
help.
- Toby
---------- Forwarded message ----------
From: Dusan Miloradovic <dusan.miloradovic(a)gmail.com>
Date: Sun, Jun 19, 2016 at 2:33 AM
Subject: File descriptor in bad state
To: Immutant <immutant(a)googlegroups.com>
Hi
I hope someone can give me some directions about this issue I have .
I recently upgraded the production server from HTTP Kit to Immutant,
because effectively the server was becoming unresponsive every week
or so. I was hoping that the issue was with the HTTP Kit itself, and
the move to Immutant would solve the issue. With the HTTP Kit I
didn't get any error logs when it was hanging, but with Immutant,
this is what I got:
Exception in thread "XNIO-1 I/O-4" java.lang.InternalError: File
descriptor in bad state
at sun.nio.ch.EventPortWrapper.release(EventPortWrapper.java:235)
at sun.nio.ch.EventPortSelectorImpl.implDereg(EventPortSelectorImpl.java:144)
at sun.nio.ch.SelectorImpl.processDeregisterQueue(SelectorImpl.java:150)
at sun.nio.ch.EventPortSelectorImpl.doSelect(EventPortSelectorImpl.java:75)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:510)
Caused by: java.io.IOException: File descriptor in bad state
at sun.nio.ch.SolarisEventPort.port_dissociate(Native Method)
at sun.nio.ch.EventPortWrapper.release(EventPortWrapper.java:233)
... 6 more
I am running Immutant version 2.1.4 on Sun Solaris version SunOS 5.11
with Oracle JDK 1.7 and clojure 1.8.0
Are there any Immutant/Undertow parameters I should be aware of with
regards to the problem?
Thanks
--
You received this message because you are subscribed to the Google
Groups "Immutant" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to immutant+unsubscribe(a)googlegroups.com.
To post to this group, send email to immutant(a)googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/immutant/13c058c9-b079-4b82-8a01-4f3ed0....
For more options, visit https://groups.google.com/d/optout.
9 years, 8 months
How to handle exceptions thrown from worker threads
by Wolinsky, Jared
Good morning,
We're using Undertow in a new web service at MLB, and I haven't been able to find a solution for handling errors that occur in requests that have been dispatched to worker threads. Here is a link to my SO question: http://stackoverflow.com/questions/37753726/how-to-handle-exceptions-thro.... Ignoring worker threads, my model for error handling is to have an outer handler that maintains a map of exception type -> {log level, http status code}. Then I allow exceptions to propagate out from the actual API handlers, hitting the error handler which logs the error and responds to the client with the correct status code based on the exception type. When exceptions are thrown from worker threads, however, they break out of the normal handler chain and never hit the error handler, resulting in a 500 response every time. Here are options I've considered for handling this problem:
1. Inside my error handler, set a DefaultResponseListener (https://http2.undertow.io/documentation/core/error-handling.html) on the exchange that contains my error handling logic. I hit a wall here after realizing the listener only has access to the Exchange, not to the exception that will be thrown.
2. Set an UncaughtExceptionHandler on each handler that's on a worker thread. This code would be added to my base handler class, do a !exchange.isInIoThread() check, set the error handler, then call the handleRequest method. The caveat here is that I can only do this for handlers that I have control over, not built-in handlers that dispatch to worker threads such as the AuthenticationCallHandler.
3. Use an AspectJ-based approach where I create an @Around advice that executes for all of my handlers that will wrap the execution in a try-catch, and take care of the error handling.
Are there best practices for handling this?
Thanks,
Jared Wolinsky
Senior Software Engineer, MLB Advanced Media
**********************************************************
MLB.com <http://mlb.com> - Where Baseball is Always On.
9 years, 8 months
Undertow 1.4 release and HTTP/2
by Stuart Douglas
Hi everyone,
Undertow 1.4 Final should be released very soon and will be part of
Wildfly 10. The main feature that we have added in this release is
direct support for ALPN on JDK8 without requiring modification of the
boot class path.
If anyone who is using HTTP/2 would like to try this out and provide
feedback that would be great. The current ALPN solution will continue
to be supported, however you will need to set
-Dio.undertow.disable-jdk8-alpn=true to disable the new
implementation.
JDK9 has ALPN support out of the box so this only applies to JDK8.
Stuart
9 years, 9 months
