[JBoss JIRA] (WFLY-7647) Configure Artemis thread pool size without reload
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-7647?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-7647:
-----------------------------------
The thread-pool-max-size is handled by Artemis in its configuration.
Changing this value on the fly will have no consequence until Artemis is restarted.
In order to do that, you will have to open an upstream issue in ARTEMIS to ask them to be able to change thread pool size at runtime.
> Configure Artemis thread pool size without reload
> -------------------------------------------------
>
> Key: WFLY-7647
> URL: https://issues.jboss.org/browse/WFLY-7647
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Martin Styk
> Assignee: Jeff Mesnil
>
> Currently, thread pool size can not be adjusted without server reload. If server runs into performance problem caused by thread pool size, there is no way to adjust thread pool size without termination of all running tasks. Making this configurable "on fly" would prevent this scenario.
> Attribute {{thread-pool-max-size}} in {{/subsystem=messaging-activemq/server=default}} requires server reload.
> Size of global client thread pools can be set only before this thread pool is created. Adjusting values of system properties which configure client thread pool size has no effect on running server (with pool already created).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 5 months
[JBoss JIRA] (DROOLS-1744) Inclusion of kbases containing rule templates results in duplicate rule names and kbase build failure.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1744?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1744:
--------------------------------
Sprint: 2017 Week 38-39
> Inclusion of kbases containing rule templates results in duplicate rule names and kbase build failure.
> ------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1744
> URL: https://issues.jboss.org/browse/DROOLS-1744
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 7.3.0.Final
> Reporter: Alistair Black
> Assignee: Mario Fusco
> Fix For: 7.4.0.Final
>
>
> I am working on a multi-module BRMS project, with each module encapsulating a set of rules forming a single knowledge base. There is an empty "packaging" module which inherits each of these modules in order to generate a single KJAR for deployment purposes. The application then utilises this KJAR via the KieScanner/ReleaseId approach to facilitate dynamic rule loading at runtime and decoupling of application/rules.
> Having taken the above approach I have encountered an issue when including knowledge bases that contain rule templates. Drools is unable to build these knowledge bases, reporting duplicate rule names; it appears to believe that the rules exist in both the inheriting and inherited knowledge bases. This behaviour is not seen when including knowledge bases containing standard rules or decision tables - just rule templates.
> An example of the error reported is:
> {{4528 [main] INFO org.drools.compiler.kie.builder.impl.KieRepositoryImpl - KieModule was added: ZipKieModule[releaseId=my.drools.templates:ruleModuleOne:1.0-SNAPSHOT,file=C:\Users\black\.m2\repository\my\drools\templates\ruleModuleOne\1.0-SNAPSHOT\ruleModuleOne-1.0-SNAPSHOT.jar]
> 5145 [main] ERROR org.drools.compiler.kie.builder.impl.KieProject - Unable to build KieBaseModel:ruleModule_1_kbase
> [7,4]: Duplicate rule name: Rule One :: CCC_4
> [15,4]: Duplicate rule name: Rule One :: BBB_3
> [23,4]: Duplicate rule name: Rule One :: AAA_2
> [7,4]: Duplicate rule name: Rule Two :: EEE_3
> [16,4]: Duplicate rule name: Rule Two :: DDD_2
> 5329 [main] ERROR org.drools.compiler.kie.builder.impl.KieProject - Unable to build KieBaseModel:inheritedTemplateModules-ruleModule_1_kbase
> [7,4]: Duplicate rule name: Rule One :: CCC_4
> [15,4]: Duplicate rule name: Rule One :: BBB_3
> [23,4]: Duplicate rule name: Rule One :: AAA_2
> [7,4]: Duplicate rule name: Rule Two :: EEE_3
> [16,4]: Duplicate rule name: Rule Two :: DDD_2
> }}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 5 months
[JBoss JIRA] (WFLY-9399) EJB remote and local methods are not calling through Threads
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9399?page=com.atlassian.jira.plugin.... ]
David Lloyd closed WFLY-9399.
-----------------------------
Resolution: Rejected
This is not a help forum, this is a bug tracker. If you are looking for help, try this link: [http://wildfly.org/gethelp/]
> EJB remote and local methods are not calling through Threads
> ------------------------------------------------------------
>
> Key: WFLY-9399
> URL: https://issues.jboss.org/browse/WFLY-9399
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 9.0.2.Final
> Reporter: Karthika Udayasankar
> Priority: Blocker
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Hi,
> We are migrated from JBoss 5.1 to WildFly 9.0.2. After migrating I'm facing exception while calling EJB methods when it is coming through *Thread* concept otherwise it is working fine.
> 2017-09-28 16:03:38,981 ERROR [SIRAHULOG] (Thread-149) Thread ID:398:EjbUtils:getEJBInstance:Exception raised for name:java:app/app-model-1.0-SNAPSHOT/FirmBaseEJB!com.sirahu.apptivo.model.ejb.common.session.FirmBaseEJBRemote: javax.naming.NameNotFoundException: java:app/app-model-1.0-SNAPSHOT/FirmBaseEJB!com.sirahu.apptivo.model.ejb.common.session.FirmBaseEJBRemote
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:189)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:233)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at javax.naming.InitialContext.lookup(InitialContext.java:411)
> at javax.naming.InitialContext.lookup(InitialContext.java:411)
> at com.sirahu.apptivo.view.framework.util.EjbUtils.getEJBInstance(EjbUtils.java:563)
> at com.sirahu.apptivo.view.framework.util.EjbUtils.getEjb(EjbUtils.java:498)
> at com.sirahu.apptivo.view.framework.util.EjbUtils.getRemoteEjb(EjbUtils.java:527)
> at com.sirahu.apptivo.view.framework.util.EjbUtils.getFirmOrCFRemoteEjb(EjbUtils.java:535)
> at com.sirahu.apptivo.view.framework.util.AppClusterEJBFactory.getFirmBaseEJBRemote(AppClusterEJBFactory.java:1105)
> at com.sirahu.apptivo.view.dao.service.BusinessAttributeService.getBusinessAtrributeMap(BusinessAttributeService.java:52)
> at com.sirahu.apptivo.view.action.common.MessageTemplateCommonService.getObjectMessageTemplateMap(MessageTemplateCommonService.java:124)
> at com.sirahu.apptivo.view.dao.service.MessageTemplateService.processMessageTemplate(MessageTemplateService.java:3033)
> at com.sirahu.apptivo.view.dao.service.MessageTemplateService.replaceMessageTemplate(MessageTemplateService.java:340)
> at com.sirahu.apptivo.view.dao.service.MessageTemplateService.replaceMessageTemplate(MessageTemplateService.java:167)
> at com.sirahu.apptivo.view.dao.servlet.v6.UpdateEmployeeSignatureThread.run(EmployeesServlet.java:7012)
> at java.lang.Thread.run(Thread.java:745)
> Is there anything need to config for Thread concepts.? Can anybody help me to fix this issue?
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 5 months
[JBoss JIRA] (WFLY-9399) EJB remote and local methods are not calling through Threads
by Karthika Udayasankar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9399?page=com.atlassian.jira.plugin.... ]
Karthika Udayasankar updated WFLY-9399:
---------------------------------------
Description:
Hi,
We are migrated from JBoss 5.1 to WildFly 9.0.2. After migrating I'm facing exception while calling EJB methods when it is coming through *Thread* concept otherwise it is working fine.
2017-09-28 16:03:38,981 ERROR [SIRAHULOG] (Thread-149) Thread ID:398:EjbUtils:getEJBInstance:Exception raised for name:java:app/app-model-1.0-SNAPSHOT/FirmBaseEJB!com.sirahu.apptivo.model.ejb.common.session.FirmBaseEJBRemote: javax.naming.NameNotFoundException: java:app/app-model-1.0-SNAPSHOT/FirmBaseEJB!com.sirahu.apptivo.model.ejb.common.session.FirmBaseEJBRemote
at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:189)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:233)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sirahu.apptivo.view.framework.util.EjbUtils.getEJBInstance(EjbUtils.java:563)
at com.sirahu.apptivo.view.framework.util.EjbUtils.getEjb(EjbUtils.java:498)
at com.sirahu.apptivo.view.framework.util.EjbUtils.getRemoteEjb(EjbUtils.java:527)
at com.sirahu.apptivo.view.framework.util.EjbUtils.getFirmOrCFRemoteEjb(EjbUtils.java:535)
at com.sirahu.apptivo.view.framework.util.AppClusterEJBFactory.getFirmBaseEJBRemote(AppClusterEJBFactory.java:1105)
at com.sirahu.apptivo.view.dao.service.BusinessAttributeService.getBusinessAtrributeMap(BusinessAttributeService.java:52)
at com.sirahu.apptivo.view.action.common.MessageTemplateCommonService.getObjectMessageTemplateMap(MessageTemplateCommonService.java:124)
at com.sirahu.apptivo.view.dao.service.MessageTemplateService.processMessageTemplate(MessageTemplateService.java:3033)
at com.sirahu.apptivo.view.dao.service.MessageTemplateService.replaceMessageTemplate(MessageTemplateService.java:340)
at com.sirahu.apptivo.view.dao.service.MessageTemplateService.replaceMessageTemplate(MessageTemplateService.java:167)
at com.sirahu.apptivo.view.dao.servlet.v6.UpdateEmployeeSignatureThread.run(EmployeesServlet.java:7012)
at java.lang.Thread.run(Thread.java:745)
Is there anything need to config for Thread concepts.? Can anybody help me to fix this issue?
was:
Hi,
We are migrated from JBoss 5.1 to WildFly 9.0.2. After migrating I'm facing this exception when it is coming through from *Thread* concept otherwise it is working fine.
2017-09-28 16:03:38,981 ERROR [SIRAHULOG] (Thread-149) Thread ID:398:EjbUtils:getEJBInstance:Exception raised for name:java:app/app-model-1.0-SNAPSHOT/FirmBaseEJB!com.sirahu.apptivo.model.ejb.common.session.FirmBaseEJBRemote: javax.naming.NameNotFoundException: java:app/app-model-1.0-SNAPSHOT/FirmBaseEJB!com.sirahu.apptivo.model.ejb.common.session.FirmBaseEJBRemote
at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:189)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:233)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sirahu.apptivo.view.framework.util.EjbUtils.getEJBInstance(EjbUtils.java:563)
at com.sirahu.apptivo.view.framework.util.EjbUtils.getEjb(EjbUtils.java:498)
at com.sirahu.apptivo.view.framework.util.EjbUtils.getRemoteEjb(EjbUtils.java:527)
at com.sirahu.apptivo.view.framework.util.EjbUtils.getFirmOrCFRemoteEjb(EjbUtils.java:535)
at com.sirahu.apptivo.view.framework.util.AppClusterEJBFactory.getFirmBaseEJBRemote(AppClusterEJBFactory.java:1105)
at com.sirahu.apptivo.view.dao.service.BusinessAttributeService.getBusinessAtrributeMap(BusinessAttributeService.java:52)
at com.sirahu.apptivo.view.action.common.MessageTemplateCommonService.getObjectMessageTemplateMap(MessageTemplateCommonService.java:124)
at com.sirahu.apptivo.view.dao.service.MessageTemplateService.processMessageTemplate(MessageTemplateService.java:3033)
at com.sirahu.apptivo.view.dao.service.MessageTemplateService.replaceMessageTemplate(MessageTemplateService.java:340)
at com.sirahu.apptivo.view.dao.service.MessageTemplateService.replaceMessageTemplate(MessageTemplateService.java:167)
at com.sirahu.apptivo.view.dao.servlet.v6.UpdateEmployeeSignatureThread.run(EmployeesServlet.java:7012)
at java.lang.Thread.run(Thread.java:745)
Is there anything need to config for Thread concepts.? Can anybody help me to fix this issue?
> EJB remote and local methods are not calling through Threads
> ------------------------------------------------------------
>
> Key: WFLY-9399
> URL: https://issues.jboss.org/browse/WFLY-9399
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 9.0.2.Final
> Reporter: Karthika Udayasankar
> Priority: Blocker
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Hi,
> We are migrated from JBoss 5.1 to WildFly 9.0.2. After migrating I'm facing exception while calling EJB methods when it is coming through *Thread* concept otherwise it is working fine.
> 2017-09-28 16:03:38,981 ERROR [SIRAHULOG] (Thread-149) Thread ID:398:EjbUtils:getEJBInstance:Exception raised for name:java:app/app-model-1.0-SNAPSHOT/FirmBaseEJB!com.sirahu.apptivo.model.ejb.common.session.FirmBaseEJBRemote: javax.naming.NameNotFoundException: java:app/app-model-1.0-SNAPSHOT/FirmBaseEJB!com.sirahu.apptivo.model.ejb.common.session.FirmBaseEJBRemote
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:189)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:233)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at javax.naming.InitialContext.lookup(InitialContext.java:411)
> at javax.naming.InitialContext.lookup(InitialContext.java:411)
> at com.sirahu.apptivo.view.framework.util.EjbUtils.getEJBInstance(EjbUtils.java:563)
> at com.sirahu.apptivo.view.framework.util.EjbUtils.getEjb(EjbUtils.java:498)
> at com.sirahu.apptivo.view.framework.util.EjbUtils.getRemoteEjb(EjbUtils.java:527)
> at com.sirahu.apptivo.view.framework.util.EjbUtils.getFirmOrCFRemoteEjb(EjbUtils.java:535)
> at com.sirahu.apptivo.view.framework.util.AppClusterEJBFactory.getFirmBaseEJBRemote(AppClusterEJBFactory.java:1105)
> at com.sirahu.apptivo.view.dao.service.BusinessAttributeService.getBusinessAtrributeMap(BusinessAttributeService.java:52)
> at com.sirahu.apptivo.view.action.common.MessageTemplateCommonService.getObjectMessageTemplateMap(MessageTemplateCommonService.java:124)
> at com.sirahu.apptivo.view.dao.service.MessageTemplateService.processMessageTemplate(MessageTemplateService.java:3033)
> at com.sirahu.apptivo.view.dao.service.MessageTemplateService.replaceMessageTemplate(MessageTemplateService.java:340)
> at com.sirahu.apptivo.view.dao.service.MessageTemplateService.replaceMessageTemplate(MessageTemplateService.java:167)
> at com.sirahu.apptivo.view.dao.servlet.v6.UpdateEmployeeSignatureThread.run(EmployeesServlet.java:7012)
> at java.lang.Thread.run(Thread.java:745)
> Is there anything need to config for Thread concepts.? Can anybody help me to fix this issue?
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 5 months
[JBoss JIRA] (WFLY-9399) EJB remote and local methods are not calling through Threads
by Karthika Udayasankar (JIRA)
Karthika Udayasankar created WFLY-9399:
------------------------------------------
Summary: EJB remote and local methods are not calling through Threads
Key: WFLY-9399
URL: https://issues.jboss.org/browse/WFLY-9399
Project: WildFly
Issue Type: Feature Request
Components: EJB
Affects Versions: 9.0.2.Final
Reporter: Karthika Udayasankar
Priority: Blocker
Hi,
We are migrated from JBoss 5.1 to WildFly 9.0.2. After migrating I'm facing this exception when it is coming through from *Thread* concept otherwise it is working fine.
2017-09-28 16:03:38,981 ERROR [SIRAHULOG] (Thread-149) Thread ID:398:EjbUtils:getEJBInstance:Exception raised for name:java:app/app-model-1.0-SNAPSHOT/FirmBaseEJB!com.sirahu.apptivo.model.ejb.common.session.FirmBaseEJBRemote: javax.naming.NameNotFoundException: java:app/app-model-1.0-SNAPSHOT/FirmBaseEJB!com.sirahu.apptivo.model.ejb.common.session.FirmBaseEJBRemote
at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:189)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:233)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sirahu.apptivo.view.framework.util.EjbUtils.getEJBInstance(EjbUtils.java:563)
at com.sirahu.apptivo.view.framework.util.EjbUtils.getEjb(EjbUtils.java:498)
at com.sirahu.apptivo.view.framework.util.EjbUtils.getRemoteEjb(EjbUtils.java:527)
at com.sirahu.apptivo.view.framework.util.EjbUtils.getFirmOrCFRemoteEjb(EjbUtils.java:535)
at com.sirahu.apptivo.view.framework.util.AppClusterEJBFactory.getFirmBaseEJBRemote(AppClusterEJBFactory.java:1105)
at com.sirahu.apptivo.view.dao.service.BusinessAttributeService.getBusinessAtrributeMap(BusinessAttributeService.java:52)
at com.sirahu.apptivo.view.action.common.MessageTemplateCommonService.getObjectMessageTemplateMap(MessageTemplateCommonService.java:124)
at com.sirahu.apptivo.view.dao.service.MessageTemplateService.processMessageTemplate(MessageTemplateService.java:3033)
at com.sirahu.apptivo.view.dao.service.MessageTemplateService.replaceMessageTemplate(MessageTemplateService.java:340)
at com.sirahu.apptivo.view.dao.service.MessageTemplateService.replaceMessageTemplate(MessageTemplateService.java:167)
at com.sirahu.apptivo.view.dao.servlet.v6.UpdateEmployeeSignatureThread.run(EmployeesServlet.java:7012)
at java.lang.Thread.run(Thread.java:745)
Is there anything need to config for Thread concepts.? Can anybody help me to fix this issue?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 5 months
[JBoss JIRA] (WFLY-9398) Hi Team,
by Karthika Udayasankar (JIRA)
Karthika Udayasankar created WFLY-9398:
------------------------------------------
Summary: Hi Team,
Key: WFLY-9398
URL: https://issues.jboss.org/browse/WFLY-9398
Project: WildFly
Issue Type: Feature Request
Reporter: Karthika Udayasankar
Assignee: Jason Greene
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 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:
---------------------------------
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)
8 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:
---------------------------------
Steps to Reproduce:
# Set {{max-connections}} attribute in listener and Start WildFly:
{code}
<http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true" max-connections="10"/>
{code}
# Sent concurrent requests which can overflow the max-connections limit:
{code}
ab -c 100 -n 100 http://localhost:8080/
{code}
You will see most requests will be failed with "The timeout specified has expired". Once the above command hit the max-connections limit, WildFly does not accept new connection any more even after all request processing are completed.
- Try {{curl}} command to confirm you can not connect:
{code}
curl -v http://localhost:8080/
{code}
- Check an output of {{netstat}}. {{CLOSE_WAIT}} will be increased one by one when you execute curl command and cancel it:
{code}
netstat -tunapl | grep 8080
{code}
was:
# Set {{max-connections}} attribute in listener and Start JBoss:
{code}
<http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true" max-connections="10"/>
{code}
# Sent concurrent requests which can overflow the max-connections limit:
{code}
ab -c 100 -n 100 http://localhost:8080/
{code}
You will see most requests will be failed with "The timeout specified has expired". Once the above command hit the max-connections limit, JBoss does not accept new connection any more even after all request processing are completed.
- Try {{curl}} command to confirm you can not connect:
{code}
curl -v http://localhost:8080/
{code}
- Check an output of {{netstat}}. {{CLOSE_WAIT}} will be increased one by one when you execute curl command and cancel it:
{code}
netstat -tunapl | grep 8080
{code}
> 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, 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.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 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 moved JBEAP-13284 to WFLY-9397:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9397 (was: JBEAP-13284)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Affects Version/s: 11.0.0.CR1
(was: 7.1.0.CR1)
(was: 7.1.0.CR2)
> 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, 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.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 5 months