August 2009 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] Created: (MODCLUSTER-91) Connector bind address of 0.0.0.0 propagated to proxy

by Brian Stansberry (JIRA)

Connector bind address of 0.0.0.0 propagated to proxy ----------------------------------------------------- Key: MODCLUSTER-91 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-91 Project: mod_cluster Issue Type: Bug Affects Versions: 1.0.1.GA Reporter: Brian Stansberry Assignee: Jean-Frederic Clere Marek Goldmann wrote: > I'm encountered a strange error. When I bind JBoss instance to 0.0.0.0 > address instead of a fixed ethernet address, node gets registered in > mod_cluster, shows in mod_cluster-manager, but every request to > registered contexts throws 503 error. > > httpd error log: > > [Fri Aug 07 03:21:05 2009] [error] (111)Connection refused: proxy: > ajp: attempt to connect to 0.0.0.0:8009 (0.0.0.0) failed > [Fri Aug 07 03:21:05 2009] [error] ap_proxy_connect_backend disabling > worker for (0.0.0.0) > [Fri Aug 07 03:21:15 2009] [error] proxy: ajp: disabled connection for > (0.0.0.0) > [Fri Aug 07 03:21:25 2009] [error] proxy: ajp: disabled connection for > (0.0.0.0) > > This looks like a bug for me, because many administrators are binding > JBoss to 0.0.0.0. The java side needs to understand that 0.0.0.0 is useless as a client address and send something useful. Trick is deciding what's useful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

4
12
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-90) Add information in httpd to find easly the mod_cluster version

by Jean-Frederic Clere (JIRA)

Add information in httpd to find easly the mod_cluster version -------------------------------------------------------------- Key: MODCLUSTER-90 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-90 Project: mod_cluster Issue Type: Feature Request Environment: httpd Reporter: Jean-Frederic Clere Assignee: Jean-Frederic Clere Priority: Minor Something like the header: Server: Apache/2.2.12-dev (Unix) mod_ssl/2.2.12-dev OpenSSL/0.9.8k-fips DAV/2 for example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
9
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-84) Add domain versions of enable/disable/stop methods to HAModClusterServiceMBean

by Paul Ferraro (JIRA)

Add domain versions of enable/disable/stop methods to HAModClusterServiceMBean ------------------------------------------------------------------------------ Key: MODCLUSTER-84 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-84 Project: mod_cluster Issue Type: Feature Request Affects Versions: 1.0.0.GA Reporter: Paul Ferraro Assignee: Paul Ferraro enable(String domain) disable(String domain) stop(String domain) HASingleton performs enable/disable/stop operations on behalf of each node with the specified domain. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-72) Management operation to disable then stop node or webapp

by Brian Stansberry (JIRA)

Management operation to disable then stop node or webapp -------------------------------------------------------- Key: MODCLUSTER-72 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-72 Project: mod_cluster Issue Type: Feature Request Reporter: Brian Stansberry A common use case is to try to drain sessions from a server before taking it offline. With mod_cluster you can partially do that by invoking the JMX operation to disable a node, but then you need to manually monitor the # of active sessions so you can know when to stop the node. We should simplify this by adding an operation that tells the node to do the full disable-monitor session count-stop operation itself. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-83) Add stop() methods to ModClusterServiceMBean

by Paul Ferraro (JIRA)

Add stop() methods to ModClusterServiceMBean -------------------------------------------- Key: MODCLUSTER-83 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-83 Project: mod_cluster Issue Type: Feature Request Affects Versions: 1.0.0.GA Reporter: Paul Ferraro Assignee: Paul Ferraro stop() : stop all apps on node stop(String hostName, String contextPath) : stop single app 1. Send disable request to proxy 2. Wait for sessions to drain 3. Send stop request to proxy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-85) HAModClusterService can throw NullPointerExceptions after a partition merge

by Paul Ferraro (JIRA)

HAModClusterService can throw NullPointerExceptions after a partition merge --------------------------------------------------------------------------- Key: MODCLUSTER-85 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-85 Project: mod_cluster Issue Type: Bug Affects Versions: 1.0.0.GA Reporter: Paul Ferraro Assignee: Paul Ferraro Priority: Minor This is caused by updateClusterStatus rpcs returning null if a merged node has master status. Make sure all rpcs get the same treatment. 2009-07-27 14:29:48,134 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] (Incoming-20,10.248.107.114:32770) New cluster view for partition DefaultPartition: 4 ([10.240.62.47:1099, 10.248.107.114:1099, 10.249.195.196:1099] delta: 2) 2009-07-27 14:29:48,137 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] (AsynchViewChangeHandler Thread) Merging partitions... 2009-07-27 14:29:48,137 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] (AsynchViewChangeHandler Thread) Dead members: 0 2009-07-27 14:29:48,137 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] (AsynchViewChangeHandler Thread) Originating groups: [[10.240.62.47:32769|3] [10.240.62.47:32769, 10.249.195.196:32769], [10.248.107.114:32770|0] [10.248.107.114:32770]] 2009-07-27 14:29:50,878 ERROR [org.apache.catalina.core.ContainerBase] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Exception invoking periodic operation: java.lang.NullPointerException at org.jboss.modcluster.ha.HAModClusterService$ClusteredCatalinaEventHandler.updateClusterStatus(HAModClusterService.java:896) at org.jboss.modcluster.ha.HAModClusterService$ClusteredCatalinaEventHandler.status(HAModClusterService.java:836) at org.jboss.modcluster.ha.HAModClusterService$ClusteredCatalinaEventHandler.status(HAModClusterService.java:781) at org.jboss.modcluster.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:157) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1348) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1612) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1601) at java.lang.Thread.run(Thread.java:636) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-86) Interaction with mod_rewrite looks weird for end-users

by Jean-Frederic Clere (JIRA)

Interaction with mod_rewrite looks weird for end-users ------------------------------------------------------ Key: MODCLUSTER-86 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-86 Project: mod_cluster Issue Type: Bug Affects Versions: 1.0.1.GA Environment: Use mod_rewrite and mod_cluster Reporter: Jean-Frederic Clere Assignee: Jean-Frederic Clere Use mod_cluster with a JBoss with the application myapp (myapp.war) and use the following in httpd.conf: RewriteEngine On RewriteCond %{HTTP_HOST} ^cluster\.domain\.com [NC] RewriteRule ^/$ /myapp/MyCount [PT] As /myapp is mapped to JBoss you would except / on cluster.domain.com to go to /myapp/MyCount in JBoss unfortunately it goes to /. You would except it goes to /myapp/MyCount as it does when to you a ProxyPass directive: ProxyPass /myapp http://localhost:8080/myapp Internals: [debug] mod_proxy_cluster.c(1703): proxy_cluster_trans for 0 passthrough:/myapp/MyCount (null) uri: /myapp/MyCount args: (null) unparsed_uri: / in get_balancer_by_node() we use r->uri (/myapp/MyCount in the case) to map to the application. in proxy_cluster_trans we do: r->filename = apr_pstrcat(r->pool, "proxy:balancer://", balancer, r->unparsed_uri, NULL); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
5
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-97) httpd should remove workers who crashed

by Bela Ban (JIRA)

httpd should remove workers who crashed --------------------------------------- Key: MODCLUSTER-97 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-97 Project: mod_cluster Issue Type: Feature Request Affects Versions: 1.0.1.GA Reporter: Bela Ban Assignee: Jean-Frederic Clere Fix For: 1.1.0.CR1 When worker W crashes, httpd will not remove it from its worker tables and still try to send requests to W. We should implement something like ping_mode=I (interval), ping_timeout and connection_ping_interval in mod_jk [1]. It should work as follows: - W crashes - httpd waits for connection_ping_interval of idle time, then starts checking the connection to W every ping_timeout seconds (or ms) - When the connection to W is broken, httpd should remove W from its worker table and stop the connection checker - When (if !) W is started again, mod-cluster will register it again with httpd The configuration above should be done entirely on the AS side, e.g. in HAModClusterConfig. maybe we can find just 1 attribute rather than 3. [1] http://tomcat.apache.org/connectors-doc/reference/workers.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-92) add status from the proxy_worker_stat structure to the node information in mod_cluster-manage

by Jean-Frederic Clere (JIRA)

add status from the proxy_worker_stat structure to the node information in mod_cluster-manage --------------------------------------------------------------------------------------------- Key: MODCLUSTER-92 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-92 Project: mod_cluster Issue Type: Feature Request Affects Versions: 1.0.2.GA Environment: any Reporter: Jean-Frederic Clere Assignee: Jean-Frederic Clere Priority: Minor We are already displaying proxystat->elected, proxystat->read, proxystat->transferred, proxystat->busy, proxystat->lbfactor, would be nice to have the proxystat->status. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
6
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-101) Redeployment of session doesn't acquire session state

by Bela Ban (JIRA)

Redeployment of session doesn't acquire session state ----------------------------------------------------- Key: MODCLUSTER-101 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-101 Project: mod_cluster Issue Type: Bug Affects Versions: 1.0.2.GA Reporter: Bela Ban Assignee: Jean-Frederic Clere Here's the scenario: - Start instances A and B in a cluster, the webapp is session.war (*exploded* WAR) - Create a session, say its session-id is sessionId.A - Go to A and remove the WAR, e.g. cd ./deploy ; mv session.war session.war.bak - Refresh the session. It fails over to B: sessionId.B - Go back to A (/deploy dir) and mv session.war.bak session.war - Go to B and remove the session ==> The session will fail back to A, but the session's data is gone ! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 4 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues August 2009