[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)
6 years
[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)
6 years
[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)
6 years
[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)
6 years
[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)
6 years
[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)
6 years
[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2253:
--------------------------------
Sorry for the delay!
Well, first of all, external_addr for FD_SOCK seems not necessary since you're only using internal IP addresses.
Secondly, terminating an EC2 instance apparently doesn't (always) close the sockets of the killed process, so it is not the same as {{kill -3/-9}}. In that case, FD_ALL (or FD) acts as second line of defense.
IIRC, AWS allows you to add a hook (script) to the termination process, in that hook, you could kill the process. But I haven't used AWS for months, so maybe this has changed...
The best way would be to shut down the cluster node *gracefully*, ie. via {{JChannel.close()}}; this would install a new view in the remaining members quickly.
> FD_SOCK is not working in AWS environment
> -----------------------------------------
>
> Key: JGRP-2253
> URL: https://issues.jboss.org/browse/JGRP-2253
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Environment: AWS - EC2
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
> Fix For: 4.0.12
>
>
> We have our failure detection defined like below.
> <FD_SOCK external_port="7804" />
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="3000" />
> Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
> In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK.
> We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
> Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
> Thanks,
> Sibin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (WFCORE-3382) Further Enhance Elytron Permission Configuration
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3382?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-3382:
--------------------------------
Fix Version/s: 5.0.0.Alpha5
(was: 5.0.0.Alpha4)
> Further Enhance Elytron Permission Configuration
> ------------------------------------------------
>
> Key: WFCORE-3382
> URL: https://issues.jboss.org/browse/WFCORE-3382
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Darran Lofthouse
> Priority: Blocker
> Fix For: 5.0.0.Alpha5
>
>
> This has currently been simplified to a single resource for the out of the box configuration, however this brings issues as now permissions are duplicated so modifications need to be replicated instead of to a single location.
> Finding a way for the default required permissions to be defined in one location could help eliminate the duplication.
> We could also consider going one step further and subsystems register the default permissions that should be granted.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years