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
Robin Anil | Software Engineer
I believe these two questions are very basic based on the posts I've read
so far on the mailing list. I appreciate your insights into how to handle
these correctly using undertow handlers (was thinking custom handlers).
First topic: a portion of the URI for my app is "dynamic" and changes as my
For example, with this URI:
the "cohort1" portion "appears" after my program starts.
Each cohort may have distinct processing - so this URI:
needs to be handled by code that may be entirely different from the first
In a first approach, a single custom handler for the path /sd/* was
rh0 = new RoutingHandler().post("/xd/*", new
Undertow server = Undertow.builder().addHttpListener(ipPort,
That examined the URI, validated the "cohort" piece, and then called a
separate helper class directly (no dispatch, or async) to process the
Is this the best approach or is there a better way to handle this with
(The out-of-the-box Path Template handler, for example, did not seem
dynamic enough to handle this sort of URI.)
Second topic: the application can receive "GETS" and "POSTS" to the same
A "GET" to /xd/cohort1/healthevents/examdata would return data where a
POST to /xd/cohort1/healthevents/examdata would expect the body of the
message to have JSON to be stored.
How to best handle both GET and POST messages coming to the same URI with
Undertow? I started to add an extra layer of abstraction - a generic
handler that looked at the request method
HttpString hString = exchange.getRequestMethod();
but was not sure where to go from there...do I then call the specialized
POST and GET handlers with .dispatch (deprecated except if I provide an
Executor?) or is there a way to register two handlers for the same
path...just different request methods?
I agree that it's a load-balancing issue but we can't do much about it at
I still see issues after using the latest XNIO (3.7.7) with Undertow. what
I have observed it that when there is a spike in request
and CONNECTION_HIGH_WATER is reached, the server stops accepting new
connection as expected and the client starts to close the connection
because of delay (we have strict low latency requirement < 100ms) and try
to create new connection again (which will also not be accepted) but server
has not closed those connections (NO_REQUEST_TIMEOUT = 6000) and there will
be high number of CLOSE_WAIT connections at this moment. The server is
considering CLOSE_WAIT + ESTABLISHED for CONNECTION_HIGH_WATER (my
Is there a way that I can close all CLOSE_WAIT connection at this moment
so that connection counts drop under CONNECTION_HIGH_WATER and we start
responding to newly established connections? or any other suggestions? I
have tried removing CONNECTION_HIGH_WATER and relying on the FD limit but
that didn't work.
On Sun, Mar 1, 2020 at 7:47 AM Stan Rosenberg <stan.rosenberg(a)gmail.com>
> On Sat, Feb 29, 2020 at 8:18 PM Nishant Kumar <nishantkumar35(a)gmail.com>
>> Thanks for the reply. I am running it under supervisord and i have
>> updated open file limit in supervisord config. The problem seems to be same
>> as what @Carter has mentioned. It happens mostly during sudden traffic
>> spike and then sudden increase (~30k-300k) of TIME_WAIT socket.
> The changes in
> https://github.com/xnio/xnio/pull/206/files#diff-23a6a7997705ea72e4016c11... are
> likely to improve the exceptional case of exceeding the file descriptor
> limit. However, if you're already setting the limit too high (e.g., in our
> case it was 795588), then exceeding it is a symptom of not properly
> load-balancing your traffic; with that many connections, you'd better have
> a ton of free RAM available.
Mob: +91 80088 42030
Hi devs and followers we have a problem and maybe someone on this list have some input.
We use undertow as an API gateway in front of JBoss application servers.
One API we have is responding with a chunked response, and the receiving side is expecting that each chunk is a valid JSon object.
When we analyze the TCP dumps it looks like some chunks are not the full JSon response we are expecting.
So the question is could this be a problem in the gateway?
I found a flag called PRE_CHUNKED_RESPONSE could this be the answer.
If so, how do we apply it in a proxy handler?
Under load, when the worker threads are saturated, new requests will be queued.
Is there a way to timeout these requests, so that it doesn't waste time serving them later when the client has already given up?
I saw a reference to RequestLimitingHandler having a configurable timeout, but that doesn't appear to be true.
I also don't want any limit to how many request that can be waiting, only how long they can wait.
This doesn't seem to be a feature offered by any of the standard Java ExecutorService implementations,
but perhaps Undertow has added this (or an appropriate extension point for this) somewhere?