[
https://issues.jboss.org/browse/WFLY-9397?page=com.atlassian.jira.plugin....
]
Masafumi Miura updated WFLY-9397:
---------------------------------
Description:
Once hitting the {{max-connections}} limit of listener, WildFly does not accept new
connections any more. Even after all request processing are completed, WildFly does not
accept. So, any client can not connect to the server.
In addition, when a client send a new request and close the connection from client-side
due to timeout or cancellation in such situation, CLOSE_WAIT connections remain until
WildFly Java process is stopped.
I think this issue is related to XNIO-276 and XNIO-279, which both fixes are merged in
XNIO 3.4 branch but it's not merged (or partially merged) in XNIO 3.5 branch:
- XNIO-276 - If QueuedNioTcpServer hits the max connection limit it gets stuck in an
infinite loop
This issue is fixed by the two commits
[
6a5d04e|https://github.com/xnio/xnio/commit/6a5d04e3be98ee68a9fb1f9f98eb4...] and
[
8c0af87|https://github.com/xnio/xnio/commit/8c0af87f5dfdee96af2e3000e47e6...]
which were merged in 3.4 branch. However, 8c0af87 is not included in 3.5 branch.
- XNIO-279 - QueuedNioTcpServer can go into an infinite loop if accept fails
This issue is fixed by the commit
[
86d0f6c|https://github.com/xnio/xnio/commit/86d0f6cc4bc41443b7e9442989e56...] in
3.4 branch. However, this is not included in 3.5 branch.
was:
Once hitting the {{max-connections}} limit of listener, JBoss EAP does not accept new
connections any more. Even after all request processing are completed, JBoss does not
accept. So, any client can not connect to JBoss EAP.
In addition, when a client send a new request and close the connection from client-side
due to timeout or cancellation in such situation, CLOSE_WAIT connections remain until
JBoss Java process is stopped.
I think this issue is related to XNIO-276 and XNIO-279, which both fixes are merged in
XNIO 3.4 branch but it's not merged (or partially merged) in XNIO 3.5 branch:
- XNIO-276 - If QueuedNioTcpServer hits the max connection limit it gets stuck in an
infinite loop
This issue is fixed by the two commits
[
6a5d04e|https://github.com/xnio/xnio/commit/6a5d04e3be98ee68a9fb1f9f98eb4...] and
[
8c0af87|https://github.com/xnio/xnio/commit/8c0af87f5dfdee96af2e3000e47e6...]
which were merged in 3.4 branch. However, 8c0af87 is not included in 3.5 branch.
- XNIO-279 - QueuedNioTcpServer can go into an infinite loop if accept fails
This issue is fixed by the commit
[
86d0f6c|https://github.com/xnio/xnio/commit/86d0f6cc4bc41443b7e9442989e56...] in
3.4 branch. However, this is not included in 3.5 branch.
Note: JBEAP-6397 and JBEAP-8080 were raised to track the issues for 7.1.0. I think both
are marked as resolved because 7.1.0 DR came with XNIO 3.4.x at that time. However, the
latest 7.1.0 CR now comes with XNIO 3.5.x, so it regresses in the latest release.
Once hitting the max-connections limit, new connections are not
accepted any more and CLOSE_WAIT connections increase gradually
-------------------------------------------------------------------------------------------------------------------------------
Key: WFLY-9397
URL:
https://issues.jboss.org/browse/WFLY-9397
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 11.0.0.CR1
Reporter: Masafumi Miura
Assignee: David Lloyd
Once hitting the {{max-connections}} limit of listener, WildFly does not accept new
connections any more. Even after all request processing are completed, WildFly does not
accept. So, any client can not connect to the server.
In addition, when a client send a new request and close the connection from client-side
due to timeout or cancellation in such situation, CLOSE_WAIT connections remain until
WildFly Java process is stopped.
I think this issue is related to XNIO-276 and XNIO-279, which both fixes are merged in
XNIO 3.4 branch but it's not merged (or partially merged) in XNIO 3.5 branch:
- XNIO-276 - If QueuedNioTcpServer hits the max connection limit it gets stuck in an
infinite loop
This issue is fixed by the two commits
[
6a5d04e|https://github.com/xnio/xnio/commit/6a5d04e3be98ee68a9fb1f9f98eb4...] and
[
8c0af87|https://github.com/xnio/xnio/commit/8c0af87f5dfdee96af2e3000e47e6...]
which were merged in 3.4 branch. However, 8c0af87 is not included in 3.5 branch.
- XNIO-279 - QueuedNioTcpServer can go into an infinite loop if accept fails
This issue is fixed by the commit
[
86d0f6c|https://github.com/xnio/xnio/commit/86d0f6cc4bc41443b7e9442989e56...] in
3.4 branch. However, this is not included in 3.5 branch.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)