[JBoss JIRA] (WFLY-9397) Once hitting the max-connections limit, new connections are not accepted any more and CLOSE_WAIT connections increase gradually
by Masafumi Miura (JIRA)
[ https://issues.jboss.org/browse/WFLY-9397?page=com.atlassian.jira.plugin.... ]
Masafumi Miura commented on WFLY-9397:
--------------------------------------
[~dmlloyd] Yes, I think this JIRA can be closed. WildFly 12 comes with XNIO 3.6.2.Final which already incorporates the missing commits for this JIRA.
> 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
> Fix For: 12.0.0.Final
>
>
> 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.5.0#75005)
7 years, 5 months
[JBoss JIRA] (WFLY-9397) Once hitting the max-connections limit, new connections are not accepted any more and CLOSE_WAIT connections increase gradually
by Masafumi Miura (JIRA)
[ https://issues.jboss.org/browse/WFLY-9397?page=com.atlassian.jira.plugin.... ]
Masafumi Miura updated WFLY-9397:
---------------------------------
Fix Version/s: 12.0.0.Final
> 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
> Fix For: 12.0.0.Final
>
>
> 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.5.0#75005)
7 years, 5 months
[JBoss JIRA] (WFLY-9397) Once hitting the max-connections limit, new connections are not accepted any more and CLOSE_WAIT connections increase gradually
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9397?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-9397:
-----------------------------------
This seems to have been fixed a while ago; can this be closed?
> 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.5.0#75005)
7 years, 5 months
[JBoss JIRA] (WFLY-9397) Once hitting the max-connections limit, new connections are not accepted any more and CLOSE_WAIT connections increase gradually
by Masafumi Miura (JIRA)
[ https://issues.jboss.org/browse/WFLY-9397?page=com.atlassian.jira.plugin.... ]
Masafumi Miura edited comment on WFLY-9397 at 4/27/18 8:06 AM:
---------------------------------------------------------------
[~jorgevillaverde] At first glance, I guess it's different from this. It sounds to me that you are just hitting the maximum number of task worker thread pool which handles application processing (like Servlet or EJB, etc). You can configure it with the"task-max-threads" attribute of <worker> in io subsystem. When "task-max-threads" is not specified, it defaults to "16 * CPU cores".
Please understand that JIRA is not a support forum but a bug tracker. Please use WildFly's user forums: http://wildfly.org/gethelp/
was (Author: mmiura):
[~jorgevillaverde] At first glance, I guess it's different from this. It sounds to me that you are just hitting the maximum number of task worker thread pool which handles application processing (like Servlet or EJB, etc). You can configure it with the"task-max-threads" attribute of <worker> in io subsystem. When "task-max-threads" is not specified, it defaults to "16 * CPU cores".
Please understand that JIRA is not a support forum but a bug tracker. Please use WildFly's user forums.
> 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.5.0#75005)
7 years, 5 months
[JBoss JIRA] (WFLY-9397) Once hitting the max-connections limit, new connections are not accepted any more and CLOSE_WAIT connections increase gradually
by Masafumi Miura (JIRA)
[ https://issues.jboss.org/browse/WFLY-9397?page=com.atlassian.jira.plugin.... ]
Masafumi Miura commented on WFLY-9397:
--------------------------------------
[~jorgevillaverde] At first glance, I guess it's different from this. It sounds to me that you are just hitting the maximum number of task worker thread pool which handles application processing (like Servlet or EJB, etc). You can configure it with the"task-max-threads" attribute of <worker> in io subsystem. When "task-max-threads" is not specified, it defaults to "16 * CPU cores".
Please understand that JIRA is not a support forum but a bug tracker. Please use WildFly's user forums.
> 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.5.0#75005)
7 years, 5 months
[JBoss JIRA] (WFLY-9397) Once hitting the max-connections limit, new connections are not accepted any more and CLOSE_WAIT connections increase gradually
by Jorge Villaverde (JIRA)
[ https://issues.jboss.org/browse/WFLY-9397?page=com.atlassian.jira.plugin.... ]
Jorge Villaverde commented on WFLY-9397:
----------------------------------------
We are experiencing a similar problem, but without max-connection. It seems to happen when we reach (16 * num processors) of simultaneous connections.
Does anyone knows what the problem is?
> 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.5.0#75005)
7 years, 5 months
[JBoss JIRA] (WFCORE-1917) Deprecate "reload", "suspend" and "resume" ops on the server-config resource
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1917?page=com.atlassian.jira.plugi... ]
Yeray Borges reassigned WFCORE-1917:
------------------------------------
Assignee: Yeray Borges
> Deprecate "reload", "suspend" and "resume" ops on the server-config resource
> ----------------------------------------------------------------------------
>
> Key: WFCORE-1917
> URL: https://issues.jboss.org/browse/WFCORE-1917
> Project: WildFly Core
> Issue Type: Task
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Yeray Borges
> Labels: domain-mode
>
> The /host=x/server-config=y resource is a configuration chunk meant to describe how the HC should set up a server, not an actual runtime resource that represents the server. The runtime resource is /host=x/server=y. But in the early days of AS7 we hadn't worked out how to have a resource for /host=x/server=y when y wasn't actually started, so as a workaround we stuck 'runtime' ops like start/stop/restart on server-config. But that was never conceptually right; it was just a workaround.
> But then we mistakenly expanded on that by sticking ops like 'reload', 'resume' and 'suspend' on the server-config resource as well. We should deprecate these so we can get rid of them in a future release (EAP 8).
> Right now they don't work very well; e.g. you can reload, suspend or resume a 'server-config' that isn't even started and the op will succeed. But that's not something this JIRA is meant to address; I'm just pointing it out as evidence of why having these ops on this resource type is conceptually a mess.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (DROOLS-2502) Declare role event erase exists class
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2502?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-2502:
-------------------------------------
[~aarevkov] Are you sure the drl you pasted is correct? I see some naming mismatches in class names (e.g. Fact 2 vs. MyFact2). Please double check it before I investigate this issue.
> Declare role event erase exists class
> -------------------------------------
>
> Key: DROOLS-2502
> URL: https://issues.jboss.org/browse/DROOLS-2502
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.5.0.Final, 7.0.0.Final, 7.1.0.Final, 7.2.0.Final, 7.3.0.Final, 7.4.1.Final, 7.5.0.Final, 7.6.0.Final, 7.7.0.Final
> Environment: Kie workbench + one kie execution server. Java 8. Statefull session. Stream mode.
> Reporter: Alexander Revkov
> Assignee: Mario Fusco
>
> Declare @role(event) rewrite exists class in drools workbench and kie execution server.
> All methods are losts.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (DROOLS-2502) Declare role event erase exists class
by Alexander Revkov (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2502?page=com.atlassian.jira.plugi... ]
Alexander Revkov updated DROOLS-2502:
-------------------------------------
Affects Version/s: 7.7.0.Final
7.6.0.Final
7.5.0.Final
7.4.1.Final
7.3.0.Final
7.2.0.Final
7.1.0.Final
7.0.0.Final
> Declare role event erase exists class
> -------------------------------------
>
> Key: DROOLS-2502
> URL: https://issues.jboss.org/browse/DROOLS-2502
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.5.0.Final, 7.0.0.Final, 7.1.0.Final, 7.2.0.Final, 7.3.0.Final, 7.4.1.Final, 7.5.0.Final, 7.6.0.Final, 7.7.0.Final
> Environment: Kie workbench + one kie execution server. Java 8. Statefull session. Stream mode.
> Reporter: Alexander Revkov
> Assignee: Mario Fusco
>
> Declare @role(event) rewrite exists class in drools workbench and kie execution server.
> All methods are losts.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months