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, 3 months
no error logged when running out of files.
by Christoph Sturm
Hello Undertow developers!
Lately my undertow server sometimes just stopped listening on its http port. I found out that the reason was that it ran out of files. The really strange thing about it is that it just stopped listening on the http port without logging any error.
I have now reproduced it locally by setting the file limit to a low value (ulimit -H -n 400) before starting the server, and then sending it some traffic with wrk.
I totally understand that running out of file handles is a big deal and that the server can act strange in that case. but its really suprising to see not a single log entry about that (also not to stdout)
thanks, regards
chris
8 years
Using the RequestBufferingHandler properly
by paroczizs .
Hi Undertow dev,
I would like to use the RequestBufferingHandler in our proxy application. I
found the following in a privious post:
"RequestBufferingHandler is a performance enhancing handler that is
designed to be used for blocking requests, basically
it allows you to fully read the request before the request gets dispatched
to a (potentially limited) thread pool."
I have to do the following:
- read the full request body or first limit size of the body e.g max 1MB if
larger there is no need for the whole body.
- do some check on the body content
- forward the whole request towards the business backend using a proxy
handler if the check was successful
I use the Undertow with Wildfly, the RequestBufferingHandler cannot be
configured in the standalone.xml the error refer an unimplemented
constructor.
I can clone the RequestBufferingHandler into an own class and I suppose it
works but I am not able to access the bufferd bytes due to the attachment
key belongs HttpServerExchange and the attachment key is package private so
I cannot use it.
Some more detail:
- I also would like to log the full in/out contents with conduits. With
this I got an error if the RequestBufferingHandler registered and fired
before the handler that wants to add the conduits. The problem here that I
need some info from the request in the log (request id / correlation id /
etc.). I can create callbacks towards the own conduit but it is not clear
for me how the conduits and the RequestBufferingHandler work together.
Any help is appreciated.
Regards, Zsolt
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_camp...>
Mentes
a vírusoktól. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_camp...>
<#m_6878925675556719771_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
8 years, 1 month
WildFly 8.2.1 EJB Security and Custom Auth Mechanism.
by Nick Stuart
Hello all, having an issue with a
custom io.undertow.security.api.AuthenticationMechanism implementation and
EJB security on WildFly 8.2 and hoping someone can think of a work around.
Basic problem, user is authenticated via the AuthenticationMechanism, and
the web context sees the user just fine and their roles, but when we get to
the EJB calls the user is seen as 'anonymous'. The mechanism calls:
sc.authenticationComplete(ac, mechanismName, true);
and returns:
AuthenticationMechanismOutcome.AUTHENTICATED;
The resources I'm calling are configured as being protected through the
web.xml and all of that is working as expected.
Another note, I am able to get this to work in WildFly 10.1, but only with
(what I think is) a bit of hack. The following code is required for EJB
Security to work:
sc.authenticationComplete(ac, mechanismName, true);
sc.login(ac.getUsername(), "");
sc.authenticate();
This same code in 8.2 causes an infinite recursion issue. Even working
around that (with another hack) this still doesn't work.
Any ideas would be greatly appreciated. Upgrading is going to be considered
a worst case scenario right now, and would like avoid it right now if at
all possible.
Thanks for the help!
-Nick
8 years, 1 month
