December 2014 - mod_cluster-issues

[JBoss JIRA] (MODCLUSTER-444) MODCLUSTER000043: Failed to send - Connection refused exception using JBoss EAP 6.3.2

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-444?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-444: -------------------------------------- Summary: MODCLUSTER000043: Failed to send - Connection refused exception using JBoss EAP 6.3.2 (was: MODCLUSTER000043: Failed to send - Connection refused exception using JBOSS 6.3.2) > MODCLUSTER000043: Failed to send - Connection refused exception using JBoss EAP 6.3.2 > ------------------------------------------------------------------------------------- > > Key: MODCLUSTER-444 > URL: https://issues.jboss.org/browse/MODCLUSTER-444 > Project: mod_cluster > Issue Type: Feature Request > Reporter: Siddharth GARG > Assignee: Jean-Frederic Clere > > We are using JBOSS version 6.3.2 and getting below exception while trying to access the application deployed on it - > MODCLUSTER000043: Failed to send STATUS to server1: java.net.ConnectException: Connection refused > at java.net.PlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_71] > at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_71] > at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_71] > at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_71] > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) [rt.jar:1.7.0_71] > at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_71] > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:835) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:858) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:499) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:600) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:414) > at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:468) > at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249) > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.4.9.Final-redhat-1.jar:7.4.9.Final-redhat-1] > at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1323) [jbossweb-7.4.9.Final-redhat-1.jar:7.4.9.Final-redhat-1] > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1588) [jbossweb-7.4.9.Final-redhat-1.jar:7.4.9.Final-redhat-1] > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1574) [jbossweb-7.4.9.Final-redhat-1.jar:7.4.9.Final-redhat-1] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71] > Could you please let me know if this is known issue/bug with JBOSS 6.3.2 and if there is any fix pack available for this > Thanks, -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-444) MODCLUSTER000043: Failed to send - Connection refused exception using JBOSS 6.3.2

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-444?page=com.atlassian.jira.pl... ] Radoslav Husar edited comment on MODCLUSTER-444 at 12/11/14 8:58 AM: --------------------------------------------------------------------- That isn't a bug but probably a misconfiguration or a network issue. Please use the user forum to get help. was (Author: jfclere): That isn't a bug but probably a miscinfiguration or a network issue. Please use the user forum to get help. > MODCLUSTER000043: Failed to send - Connection refused exception using JBOSS 6.3.2 > --------------------------------------------------------------------------------- > > Key: MODCLUSTER-444 > URL: https://issues.jboss.org/browse/MODCLUSTER-444 > Project: mod_cluster > Issue Type: Feature Request > Reporter: Siddharth GARG > Assignee: Jean-Frederic Clere > > We are using JBOSS version 6.3.2 and getting below exception while trying to access the application deployed on it - > MODCLUSTER000043: Failed to send STATUS to server1: java.net.ConnectException: Connection refused > at java.net.PlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_71] > at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_71] > at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_71] > at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_71] > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) [rt.jar:1.7.0_71] > at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_71] > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:835) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:858) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:499) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:600) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:414) > at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:468) > at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249) > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.4.9.Final-redhat-1.jar:7.4.9.Final-redhat-1] > at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1323) [jbossweb-7.4.9.Final-redhat-1.jar:7.4.9.Final-redhat-1] > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1588) [jbossweb-7.4.9.Final-redhat-1.jar:7.4.9.Final-redhat-1] > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1574) [jbossweb-7.4.9.Final-redhat-1.jar:7.4.9.Final-redhat-1] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71] > Could you please let me know if this is known issue/bug with JBOSS 6.3.2 and if there is any fix pack available for this > Thanks, -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-443) mod_cluster doesn't recognize ; as a proper context delimiter causing 404s on requests with URL jsessionids

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-443?page=com.atlassian.jira.pl... ] Michal Babacek updated MODCLUSTER-443: -------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Aaron's pull requests have been merged moth to 1.2.x and master streams. Resolving. > mod_cluster doesn't recognize ; as a proper context delimiter causing 404s on requests with URL jsessionids > ----------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-443 > URL: https://issues.jboss.org/browse/MODCLUSTER-443 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.9.Final, 1.3.1.Alpha2 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > > This is similar to MODCLUSTER-328, but in regards to ; instead of ?. > mod_cluster does not recognize ; as a delimiter when checking the request context. Thus with no trailing slash on index page requests, it treats ;jsessionid as part of the request context and tries to check the balancer for a deployed context of /helloworld;jsessionid=..., which doesn't exist and 404s. Adding the trailing slash, mod_cluster can properly delimit this and then sees the context (so /helloworld/;jsessionid=... works just fine). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-443) mod_cluster doesn't recognize ; as a proper context delimiter causing 404s on requests with URL jsessionids

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-443?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-443: ---------------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1164916|https://bugzilla.redhat.com/show_bug.cgi?id=1164916] from NEW to MODIFIED > mod_cluster doesn't recognize ; as a proper context delimiter causing 404s on requests with URL jsessionids > ----------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-443 > URL: https://issues.jboss.org/browse/MODCLUSTER-443 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.9.Final, 1.3.1.Alpha2 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > > This is similar to MODCLUSTER-328, but in regards to ; instead of ?. > mod_cluster does not recognize ; as a delimiter when checking the request context. Thus with no trailing slash on index page requests, it treats ;jsessionid as part of the request context and tries to check the balancer for a deployed context of /helloworld;jsessionid=..., which doesn't exist and 404s. Adding the trailing slash, mod_cluster can properly delimit this and then sees the context (so /helloworld/;jsessionid=... works just fine). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-427) mod_cluster can break stickiness for the first request on new child processes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-427?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-427: ---------------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1136976|https://bugzilla.redhat.com/show_bug.cgi?id=1136976] from ON_QA to VERIFIED > mod_cluster can break stickiness for the first request on new child processes > ----------------------------------------------------------------------------- > > Key: MODCLUSTER-427 > URL: https://issues.jboss.org/browse/MODCLUSTER-427 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.9.Final, 1.3.1.Alpha1 > Environment: JBoss EAP 6.3.0 > Reporter: Aaron Ogburn > Assignee: Aaron Ogburn > Fix For: 1.2.10.Final, 1.3.1.Alpha3 > > > mod_cluster can break stickiness for the first request on new child processes. It looks like this occurs specifically when "CreateBalancers 1" is used. Prefork typically makes this much worse as well. > My debugging showed that the proxy_balancer would exist, but it would essentially be empty in the new child process. find_session_route/find_route_worker would be called as expected, but the for loop in find_route_worker wasn't even doing anything because balancer->workers->nelts was 0. The balancer would then finally be populated in the new child when the first request hits internal_find_best_byrequests and calls update_workers_node. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-435) If "Balancer name includes" uppercase letter in name then mod_cluster will not maintain sticky sessions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-435?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-435: ---------------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1044879|https://bugzilla.redhat.com/show_bug.cgi?id=1044879] from ON_QA to VERIFIED > If "Balancer name includes" uppercase letter in name then mod_cluster will not maintain sticky sessions > ------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-435 > URL: https://issues.jboss.org/browse/MODCLUSTER-435 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.9.Final, 1.3.1.Alpha2 > Reporter: Michal Babacek > Assignee: Michal Babacek > Fix For: 1.2.10.Final, 1.3.1.Alpha3 > > > If one sets {{ManagerBalancerName}} (or balancer attribute in m_c subsystem) to something containing an upper case letter, e.g. _thisIsBalancerName_, sticky sessions behaviour gets broken. > Jean-Frederic suggests looking into usages of {{strcasecmp()}} in mod_proxy_balancer, rendering {{strncmp()}} in mod_cluster erroneous. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-427) mod_cluster can break stickiness for the first request on new child processes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-427?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-427: ---------------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1136976|https://bugzilla.redhat.com/show_bug.cgi?id=1136976] from ASSIGNED to ON_QA > mod_cluster can break stickiness for the first request on new child processes > ----------------------------------------------------------------------------- > > Key: MODCLUSTER-427 > URL: https://issues.jboss.org/browse/MODCLUSTER-427 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.9.Final, 1.3.1.Alpha1 > Environment: JBoss EAP 6.3.0 > Reporter: Aaron Ogburn > Assignee: Aaron Ogburn > Fix For: 1.2.10.Final, 1.3.1.Alpha3 > > > mod_cluster can break stickiness for the first request on new child processes. It looks like this occurs specifically when "CreateBalancers 1" is used. Prefork typically makes this much worse as well. > My debugging showed that the proxy_balancer would exist, but it would essentially be empty in the new child process. find_session_route/find_route_worker would be called as expected, but the for loop in find_route_worker wasn't even doing anything because balancer->workers->nelts was 0. The balancer would then finally be populated in the new child when the first request hits internal_find_best_byrequests and calls update_workers_node. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-435) If "Balancer name includes" uppercase letter in name then mod_cluster will not maintain sticky sessions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-435?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-435: ---------------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1044879|https://bugzilla.redhat.com/show_bug.cgi?id=1044879] from NEW to ON_QA > If "Balancer name includes" uppercase letter in name then mod_cluster will not maintain sticky sessions > ------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-435 > URL: https://issues.jboss.org/browse/MODCLUSTER-435 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.9.Final, 1.3.1.Alpha2 > Reporter: Michal Babacek > Assignee: Michal Babacek > Fix For: 1.2.10.Final, 1.3.1.Alpha3 > > > If one sets {{ManagerBalancerName}} (or balancer attribute in m_c subsystem) to something containing an upper case letter, e.g. _thisIsBalancerName_, sticky sessions behaviour gets broken. > Jean-Frederic suggests looking into usages of {{strcasecmp()}} in mod_proxy_balancer, rendering {{strncmp()}} in mod_cluster erroneous. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-445) [Doc]update docs SetHandler mod_cluster-manager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-445?page=com.atlassian.jira.pl... ] RH Bugzilla Integration updated MODCLUSTER-445: ----------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1168792 > [Doc]update docs SetHandler mod_cluster-manager > ----------------------------------------------- > > Key: MODCLUSTER-445 > URL: https://issues.jboss.org/browse/MODCLUSTER-445 > Project: mod_cluster > Issue Type: Bug > Reporter: Xiaohui Wu > Assignee: Jean-Frederic Clere > > In the upstream doc: > http://docs.jboss.org/mod_cluster/1.2.0/html/native.config.html > see the chapter > 3.5.14. SetHandler mod_cluster-manager > <Location /mod_cluster-manager> > SetHandler mod_cluster-manager > So I think we need to change the <Location /mod_cluster-manager> to <Location /mod_cluster_manager> to keep consistency? And do not know which one is the correct name ? And looks like the screenshot also shows the mod_cluster-manager. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-445) [Doc]update docs SetHandler mod_cluster-manager

by Xiaohui Wu (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-445?page=com.atlassian.jira.pl... ] Xiaohui Wu updated MODCLUSTER-445: ---------------------------------- Description: In the upstream doc: http://docs.jboss.org/mod_cluster/1.2.0/html/native.config.html see the chapter 3.5.14. SetHandler mod_cluster-manager <Location /mod_cluster-manager> SetHandler mod_cluster-manager So I think we need to change the <Location /mod_cluster-manager> to <Location /mod_cluster_manager> to keep consistency? And do not know which one is the correct name ? And looks like the screenshot also shows the mod_cluster-manager. was: In the upstream doc: http://docs.jboss.org/mod_cluster/1.2.0/html/native.config.html see the chapter 3.5.14. SetHandler mod_cluster-manager <Location /mod_cluster-manager> SetHandler mod_cluster-manager So I think we need to change the <Location /mod_cluster-manager> to <Location /mod_cluster_manager> to keep consistency? And do not know what is the correct name ? > [Doc]update docs SetHandler mod_cluster-manager > ----------------------------------------------- > > Key: MODCLUSTER-445 > URL: https://issues.jboss.org/browse/MODCLUSTER-445 > Project: mod_cluster > Issue Type: Bug > Reporter: Xiaohui Wu > Assignee: Jean-Frederic Clere > > In the upstream doc: > http://docs.jboss.org/mod_cluster/1.2.0/html/native.config.html > see the chapter > 3.5.14. SetHandler mod_cluster-manager > <Location /mod_cluster-manager> > SetHandler mod_cluster-manager > So I think we need to change the <Location /mod_cluster-manager> to <Location /mod_cluster_manager> to keep consistency? And do not know which one is the correct name ? And looks like the screenshot also shows the mod_cluster-manager. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues December 2014