April 2018 - jboss-jira - Jboss List Archives

[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, 8 months

1
0
0 / 0

[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, 8 months

1
0
0 / 0

[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, 8 months

1
0
0 / 0

[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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3724) stop-servers following by a reload operation could end up in a long period with an unmanageable domain

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3724?page=com.atlassian.jira.plugi... ] Yeray Borges updated WFCORE-3724: --------------------------------- Issue Type: Feature Request (was: Bug) > stop-servers following by a reload operation could end up in a long period with an unmanageable domain > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-3724 > URL: https://issues.jboss.org/browse/WFCORE-3724 > Project: WildFly Core > Issue Type: Feature Request > Components: Management > Affects Versions: 5.0.0.Alpha2 > Reporter: Yeray Borges > Assignee: Yeray Borges > > When {{:stop-servers}} operation is used with a timeout different than 0, a graceful stop is performed on each server. > If the user executes {{/host=master:reload}} in a DC, the reload operation waits for the servers until they are completely stopped. This could be an issue for a DC since the user is unable to execute any operation meanwhile the reload op is waiting for the previous stop. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[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, 8 months

1
0
0 / 0

[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, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2503) Do not use origin-repository.jboss.org, use repository.jboss.org instead in kie-parent pom

by Piotr Szubiakowski (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2503?page=com.atlassian.jira.plugi... ] Piotr Szubiakowski commented on DROOLS-2503: -------------------------------------------- [~ge0ffrey] Thanks for good explanation of the issue. I'll try to do local build that is using correct proxy. If build is fine I'll raise PRs. > Do not use origin-repository.jboss.org, use repository.jboss.org instead in kie-parent pom > ------------------------------------------------------------------------------------------ > > Key: DROOLS-2503 > URL: https://issues.jboss.org/browse/DROOLS-2503 > Project: Drools > Issue Type: Task > Components: build > Reporter: Geoffrey De Smet > Assignee: Piotr Szubiakowski > Priority: Blocker > > - repository.jboss.org is a load-balancing proxy for the jboss nexus. Nowadays it should offer much faster reads than the master one and barely slower writes (and we read far more than we write). > - origin-repository.jboss.org is the actual nexus master instance, which we must not contact directly as a good citizen. > Over 2 years ago, someone added a hack to workaround temporary stability issues with repository.jboss.org that made us go directly to origin-repository.jboss.org > https://github.com/kiegroup/droolsjbpm-build-bootstrap/blob/master/pom.xm... > That was never rolled back. Replace those 2 lines to use repository.jboss.org instead and remove the comment. > Suggested actions:: > - Replace those 2 lines to use repository.jboss.org instead and remove the comment > - Look for the use of origin-repository.jboss.org in all repo's and change that too. > -- the errai/uberfire/appformer parent pom might use it too > - Delete your local .m2/repository and do a full downstream build. > - Adjust any jenkins jobs (both blessed jobs and PR jobs) that have hard coded origin-repository.jboss.org somewhere -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[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, 8 months

1
0
0 / 0

[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, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2018