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
7 months, 2 weeks
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
7 years, 10 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
7 years, 10 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
7 years, 10 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
7 years, 10 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.
7 years, 10 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.
7 years, 10 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
7 years, 10 months
Re: [undertow-dev] Proxying WebSockets
by Hicks, Matt
Stuart, is there anything else you need from me to look into this further?
On Mon, May 23, 2016 at 11:29 AM Hicks, Matt <matt(a)matthicks.com> wrote:
Yes, I do. You can run the example code and it runs against hyperscala.org . If you go to http://hyperscala.org/ example/realtime/chat.html or http://localhost:8080/example/ realtime/chat.html you can test the Chat example that uses WebSockets. If you connect directly it
works fine, if you connect via the Proxy it doesn't.
On Mon, May 23, 2016, 11:17 AM Stuart Douglas < sdouglas(a)redhat.com > wrote:
Do you have a reproduce I can run (complete with JS etc so I can see exactly
what is going on)?
Stuart
On Mon, May 23, 2016 at 3:24 PM, Hicks, Matt < matt(a)matthicks.com > wrote:
Stuart, I created a ticket with all the information I know to provide:
[UNDERTOW-714] Broken WebSocket Proxying Support - JBoss Issue Tracker I have been attempting to write a test proxy server to proxy explicitly to
another server. issues.jboss.org
I'm not positive which side is closing the connection, but looking at the
JavaScript console it's showing the connection is being closed almost
immediately after any message is sent from the browser to the server.
On Mon, May 23, 2016 at 2:48 AM Stuart Douglas < sdouglas(a)redhat.com > wrote:
When you say it does not work exactly what behaviour are you seeing? Does the
connection get established? If it gets established and then fails which side
drops the connection?
We have extensive tests for this in the test suite, as web socket tests are run
through the proxy server, we need more info to see why it is not working for
you.
Stuart
On Fri, May 20, 2016 at 1:18 AM, Hicks, Matt < matt(a)matthicks.com > wrote:
I did some additional testing with 2.0.0.Alpha1 and got the exact same results.
If there is some way to accomplish proper proxying with Undertow I'm not seeing
it.
Should I file a bug report?
______________________________ _________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/ mailman/listinfo/undertow-dev
7 years, 11 months
