[JBoss JIRA] (MODCLUSTER-149) proxy_cluster_isup: Can't find worker for 2 (just after CONFIG).
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-149?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-149.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> proxy_cluster_isup: Can't find worker for 2 (just after CONFIG).
> ----------------------------------------------------------------
>
> Key: MODCLUSTER-149
> URL: https://issues.jboss.org/browse/MODCLUSTER-149
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.3.GA, 1.1.0.CR1
> Environment: That was a with 2.2.3 (Which is not supported).
> Reporter: Jean-Frederic Clere
> Assignee: Jean-Frederic Clere
> Fix For: 1.0.4.GA, 1.1.0.CR2
>
>
> The STATUS message arrives immediately after the CONFIG:
> +++
> 10.138.5.11 - - [03/May/2010:11:07:34 +0200] "INFO / HTTP/1.0" 200 220 "-" "ClusterListener/1.0"
> 10.138.5.11 - - [03/May/2010:11:07:34 +0200] "CONFIG / HTTP/1.0" 200 - "-" "ClusterListener/1.0"
> 10.138.5.11 - - [03/May/2010:11:07:34 +0200] "CONFIG / HTTP/1.0" 200 - "-" "ClusterListener/1.0"
> 10.138.5.11 - - [03/May/2010:11:07:34 +0200] "STATUS / HTTP/1.0" 200 60 "-" "ClusterListener/1.0"
> +++
> According to the error_log:
> +++
> Mon May 03 11:07:34 2010] [debug] mod_manager.c(1416): manager_trans INFO (/)
> [Mon May 03 11:07:34 2010] [debug] mod_manager.c(1929): manager_handler INFO (/) processing: ""
> [Mon May 03 11:07:34 2010] [debug] mod_manager.c(1970): manager_handler INFO OK
> [Mon May 03 11:07:34 2010] [debug] mod_manager.c(1416): manager_trans CONFIG (/)
> [Mon May 03 11:07:34 2010] [debug] mod_manager.c(1929): manager_handler CONFIG (/) processing: "JVMRoute=Nodo_02&Port=8009&Balancer=TestCluster&Host=10.138.5.11&Type=ajp&StickySessionForce=No"
> [Mon May 03 11:07:34 2010] [debug] mod_manager.c(1970): manager_handler CONFIG OK
> [Mon May 03 11:07:34 2010] [debug] mod_manager.c(1416): manager_trans CONFIG (/)
> [Mon May 03 11:07:34 2010] [debug] mod_manager.c(1929): manager_handler CONFIG (/) processing: "JVMRoute=Nodo_02&Port=8009&Balancer=TestCluster&Host=10.138.5.11&Type=ajp&StickySessionForce=No"
> [Mon May 03 11:07:34 2010] [debug] mod_manager.c(1970): manager_handler CONFIG OK
> [Mon May 03 11:07:34 2010] [debug] mod_manager.c(1416): manager_trans STATUS (/)
> [Mon May 03 11:07:34 2010] [debug] mod_manager.c(1929): manager_handler STATUS (/) processing: "JVMRoute=Nodo_02&Load=100"
> [Mon May 03 11:07:34 2010] [debug] mod_proxy_cluster.c(228): Created: worker for ajp://10.138.5.11:8009
> [Mon May 03 11:07:34 2010] [debug] mod_proxy_cluster.c(323): proxy: initialized single connection worker 2 in child 28541 for (10.138.5.11)
> [Mon May 03 11:07:34 2010] [debug] mod_proxy_cluster.c(364): Created: worker for ajp://10.138.5.11:8009 2 (status): 1
> [Mon May 03 11:07:34 2010] [debug] mod_proxy_cluster.c(1318): proxy_cluster_isup: Can't find worker for 2
> [Mon May 03 11:07:34 2010] [debug] mod_manager.c(1970): manager_handler STATUS OK
> +++
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-175) Wrong configuration could cause a core
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-175?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-175.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> Wrong configuration could cause a core
> --------------------------------------
>
> Key: MODCLUSTER-175
> URL: https://issues.jboss.org/browse/MODCLUSTER-175
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.3.GA, 1.1.0.Beta1
> Reporter: Jean-Frederic Clere
> Assignee: Jean-Frederic Clere
> Fix For: 1.0.4.GA, 1.1.0.Final
>
>
> # That creates a core...
> <Proxy balancer://mycluster>
> BalancerMember ajp://10.33.144.3:8009 loadfactor=1
> </Proxy>
> ProxyPass / balancer://mycluster/
> Of course having entries describing the node is not what mod_cluster is done for....
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-219) AS7 integration
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-219?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-219.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> AS7 integration
> ---------------
>
> Key: MODCLUSTER-219
> URL: https://issues.jboss.org/browse/MODCLUSTER-219
> Project: mod_cluster
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.1.Final
> Reporter: Jean-Frederic Clere
> Assignee: Paul Ferraro
> Fix For: 1.2.0.Beta1
>
>
> In the xsd we have:
> +++
> <xs:complexType name="common-load-metricType" abstract="true">
> <xs:sequence>
> <xs:element name="property" type="tns:propertyType" minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> <xs:attribute name="weight" type="xs:int"/>
> <xs:attribute name="capacity" type="xs:double"/>
> </xs:complexType>
> +++
> So a getProperties() and a setProperties() should be added AbstractLoadMetric for example?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-251) CatalinaEventHandlerAdapter requires a reference to the mbean server
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-251?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-251.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> CatalinaEventHandlerAdapter requires a reference to the mbean server
> --------------------------------------------------------------------
>
> Key: MODCLUSTER-251
> URL: https://issues.jboss.org/browse/MODCLUSTER-251
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.3.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
>
> A new CatalinaEventHandlerAdapter constructor was added during AS7 integration, however, it does not supply an mbean server, which is critical for any of the existing load metrics to work.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-41) Advertise doesn't work on windows
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-41?page=com.atlassian.jira.plu... ]
Michal Babacek closed MODCLUSTER-41.
------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> Advertise doesn't work on windows
> ---------------------------------
>
> Key: MODCLUSTER-41
> URL: https://issues.jboss.org/browse/MODCLUSTER-41
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.0.Beta1, 1.0.0.Beta2
> Environment: win32/win64
> Reporter: Jean-Frederic Clere
> Assignee: Mladen Turk
> Fix For: 1.0.0.GA
>
>
> Advertise doesn't work on windows, the following error message is in the error_log file:
> (9)Bad file descriptor: mod_advertise: multicast join failed for 232.0.0.2:23364.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-68) Add ability to disable/enable individual webapp via JMX
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-68?page=com.atlassian.jira.plu... ]
Michal Babacek closed MODCLUSTER-68.
------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> Add ability to disable/enable individual webapp via JMX
> -------------------------------------------------------
>
> Key: MODCLUSTER-68
> URL: https://issues.jboss.org/browse/MODCLUSTER-68
> Project: mod_cluster
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 1.0.0.CR2
>
>
> Currently, JMX interface allows enabling/disabling *all* webapps on an AS node, but not individual webapps.
> Allowing webapp granularity allows session draining prior to undeploy of an individual webapp.
> e.g.
> enable(String host, String contextPath)
> disable(String host, String contextPath)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-240) mod_cluster does not work with Tomcat 7 due to API Change in Connector
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-240?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-240.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> mod_cluster does not work with Tomcat 7 due to API Change in Connector
> ----------------------------------------------------------------------
>
> Key: MODCLUSTER-240
> URL: https://issues.jboss.org/browse/MODCLUSTER-240
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.2.Final
> Environment: Tomcat 7.0.14
> Reporter: C Giess
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Fix For: 1.1.3.Final
>
>
> The method *isAvailable* is no longer available in Tomcats Connector-Class.
> Error message from catalina.out:
> {code}
> Jun 6, 2011 4:14:16 PM org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren
> SEVERE: Exception invoking periodic operation:
> java.lang.NoSuchMethodError: org.apache.catalina.connector.Connector.isAvailable()Z
> at org.jboss.modcluster.catalina.CatalinaConnector.isAvailable(CatalinaConnector.java:154)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:488)
> at org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:323)
> at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
> at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:89)
> at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1233)
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1391)
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1380)
> at java.lang.Thread.run(Thread.java:662)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-203) CLONE - Quotes in jsessionId causing sticky sessions to fail
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-203?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-203.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> CLONE - Quotes in jsessionId causing sticky sessions to fail
> ------------------------------------------------------------
>
> Key: MODCLUSTER-203
> URL: https://issues.jboss.org/browse/MODCLUSTER-203
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.5
> Environment: JBoss 6 M2, mod_cluster's httpd
> Reporter: Wim Vandenhaute
> Assignee: Jean-Frederic Clere
> Fix For: 1.0.6
>
>
> I am having an issue trying to setup sticky sessions for following configuration:
> 1 httpd front end
> 2 backend jboss instances
> What I am noticing is when running in a cluster, the JSESSIONID contains quotes like:
> Set-Cookie: JSESSIONID="DE0F7EEA2A5E90497D729DB27DDB4B25.192.168.7.11:8009:jboss.web"; Version=1; Path=/f00
> Whilst not in a cluster:
> Set-Cookie: JSESSIONID=355F9E370912DC10187A15E8B02260CD; Path=/foo
> Now when I am looking in the httpd logging I see:
> mod_proxy_cluster.c(1681): cluster: Found value "54F0CFC4961C9ED14A64335B40645392.192.168.7.11:8009:jboss.web" for stickysession JSESSIONID
> In my opinion the quotes around the jsessionid is causing mod_proxy_cluster to fail in finding the jboss node to which to "stick" to.
> I recompiled mod_proxy_cluster with "HAVE_CLUSTER_EX_DEBUG" set for more debugging info and this confirmed my suspicion:
> mod_proxy_cluster.c(1739): find_nodedomain: finding node for 192.168.7.11:8009:jboss.web": mycluster
> mod_proxy_cluster.c(1752): find_nodedomain: finding domain for 192.168.7.11:8009:jboss.web": mycluster
> Looking in the code this shows that it was unable to find the node, due to the ending quote in the route.
> As for my JBoss Setup:
> * Uncommented ModClusterListener in jbossweb.sar/META-INF/jboss-beans.xml
> * mod_cluster.sar/META-INF/mod_cluster-jboss-beans.xml
> - changed ModClusterService to HAModClusterService
> - changed ${jboss.mod_cluster.advertise.enabled:false} to true
> As for my httpd setup:
> LoadModule proxy_module /opt/jboss/httpd/lib/httpd/modules/mod_proxy.so
> LoadModule proxy_ajp_module /opt/jboss/httpd/lib/httpd/modules/mod_proxy_ajp.so
> LoadModule slotmem_module /opt/jboss/httpd/lib/httpd/modules/mod_slotmem.so
> LoadModule manager_module /opt/jboss/httpd/lib/httpd/modules/mod_manager.so
> LoadModule proxy_cluster_module /opt/jboss/httpd/lib/httpd/modules/mod_proxy_cluster.so
> LoadModule advertise_module /opt/jboss/httpd/lib/httpd/modules/mod_advertise.so
> LogLevel debug
> CreateBalancers 0
> <VirtualHost *:80>
> <Location /mod_cluster-manager>
> SetHandler mod_cluster-manager
> Order deny,allow
> Deny from all
> Allow from all
> # Allow from 192.168.7.
> </Location>
> <Directory />
> Order deny,allow
> Deny from all
> Allow from all
> </Directory>
> ProxyPass /foo balancer://mycluster/foo stickysession=JSESSIONID scolonpathdelim=On nofailover=On
> KeepAliveTimeout 60
> MaxKeepAliveRequests 0
> ManagerBalancerName mycluster
> AdvertiseFrequency 5
>
> </VirtualHost>
> Listen sebeco-dev-11:443
> <VirtualHost *:443>
> ServerName sebeco-dev-11:443
> SSLEngine on
> SSLProxyEngine on
> SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
> SSLCertificateFile "/opt/jboss/httpd/httpd/server.crt"
> SSLCertificateKeyFile "/opt/jboss/httpd/httpd/server.key"
> SSLCertificateChainFile "/opt/jboss/httpd/httpd/server-ca.crt"
> <FilesMatch "\.(cgi|shtml|phtml|php)$">
> SSLOptions +StdEnvVars
> </FilesMatch>
> <Location />
> Order allow,deny
> Allow from all
> </Location>
> ProxyPass /foo balancer://mycluster/foo stickysession=JSESSIONID scolonpathdelim=On nofailover=On
> </VirtualHost>
> As my setup is not really complex at this point my gut says I am doing something wrong in the setup, but digging in the code shows the opposite.
> Any thougts?
> Best regards,
> Wim.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-151) Modify jbossweb metrics to use service provider spi, instead of jmx
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-151?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-151.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> Modify jbossweb metrics to use service provider spi, instead of jmx
> -------------------------------------------------------------------
>
> Key: MODCLUSTER-151
> URL: https://issues.jboss.org/browse/MODCLUSTER-151
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.0.CR1, 1.1.3.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 1.2.0.Beta1
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Currently, the jbossweb load metrics (i.e. ActiveSessionsLoadMetric, BusyConnectorsLoadMetric, RequestCountLoadMetric, ReceiveTrafficLoadMetric, SendTrafficLoadMetric) use jmx to generate their load values.
> This is potentially fragile.
> Instead, these load metrics should use org.jboss.mod_cluster.Engine as a load context.
> This raises the issue of load value scope. Currently, load is scoped to a server. Really, this should be scoped to an engine. While server:engine is usually a 1:1 relationship, this is technically a 1:N relationship.
> Suggested API change:
> {code}
> class LoadMetricSource<C extends LoadContext>
> {
> C createContext(Engine engine);
> }
> {code}
> Where there exists:
> {code}
> class EngineLoadMetricSource<EngineLoadContext>
> {
> public EngineLoadContext createContext(Engine engine)
> {
> return new EngineLoadContext(engine);
> }
> }
> class EngineLoadContext implements LoadContext
> {
> private final Engine engine;
> public EngineLoadContext(Engine engine)
> {
> this.engine = engine;
> }
> public Engine getEngine()
> {
> return this.engine;
> }
> public void close()
> {
> // Nothing to close
> }
> }
> {code}
> The various jbossweb load metrics would use this source.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months