[JBoss JIRA] (MODCLUSTER-38) empty string variable for proxyList should be handled
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-38?page=com.atlassian.jira.plu... ]
Michal Babacek closed MODCLUSTER-38.
------------------------------------
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
> empty string variable for proxyList should be handled
> -----------------------------------------------------
>
> Key: MODCLUSTER-38
> URL: https://issues.jboss.org/browse/MODCLUSTER-38
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.0.Beta2
> Reporter: Marek Goldmann
> Assignee: Paul Ferraro
> Fix For: 1.0.0.Beta3
>
> Attachments: empty_string_handling.patch
>
>
> Property proxyList without specified value should be handled as follows: there are no proxies.
> <property name="proxyList"></property>
> This could be done by replacing line 389 of MCMPUtils.java:
> if (proxyList == null) return Collections.emptyList();
> to
> if (proxyList == null || proxyList.length() == 0) return Collections.emptyList();
> This bug is related to MODCLUSTER-36. If we give an empty default value JBoss fails with exception:
> 2009-01-09 18:13:11,505 ERROR [org.apache.tomcat.util.modeler.BaseModelMBean] (main) Exception invoking method start
> java.lang.IllegalArgumentException: [address] is null
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (MODCLUSTER-267) String index out of range: -1 with a lot of nodes/deployments
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-267?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-267.
-------------------------------------
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
> String index out of range: -1 with a lot of nodes/deployments
> -------------------------------------------------------------
>
> Key: MODCLUSTER-267
> URL: https://issues.jboss.org/browse/MODCLUSTER-267
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.1.Final, 1.1.2.Final , 1.1.3.Final
> Environment: Centos Linux 5.4 32 Bit x86
> JBoss 5.1 & JBoss 7
> mod_cluster-1.1.3.Final-bin
> mod_cluster-1.1.3.Final-linux2-x86-ssl
> Reporter: Yves Peter
> Assignee: Jean-Frederic Clere
> Fix For: 1.2.0.Beta4
>
>
> With mod_cluster Version 1.1.1 an up when there are already lot of application servers registered and a new server trys to register on mod_cluster the following error gets thrown on the server:
> 2011-09-20 09:10:34,759 INFO [org.jboss.modcluster.ModClusterService] (main) Initializing mod_cluster 1.1.3.Final
> 2011-09-20 09:10:34,855 DEBUG [org.jboss.modcluster.ModClusterService] (main) Received server start event
> 2011-09-20 09:10:45,107 DEBUG [org.jboss.modcluster.ModClusterService] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Check status for engine [jboss.web]
> 2011-09-20 09:10:45,108 TRACE [org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Sending command [org.jboss.modcluster.mcmp.impl.DefaultMCMPRequest{requestType=INFO,wildcard=false,jvmRoute=null,parameters={}}] to proxy [jsplb01x.umobi.mobicorp.test/10.32.34.139:80]
> 2011-09-20 09:10:45,111 TRACE [org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Parsing responseStatus:HTTP/1.1 200 OK
> 2011-09-20 09:10:45,133 TRACE [org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) [org.jboss.modcluster.mcmp.impl.DefaultMCMPRequest{requestType=CONFIG,wildcard=false,jvmRoute=defaultmetro_u_01,parameters={Balancer=defaultmetro, Host=10.32.34.70, Maxattempts=1, Port=8009, Type=ajp}}, org.jboss.modcluster.mcmp.impl.DefaultMCMPRequest{requestType=ENABLE-APP,wildcard=false,jvmRoute=defaultmetro_u_01,parameters={Alias=localhost, Context=/blublu/sampleApp}}]
> 2011-09-20 09:10:45,134 TRACE [org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Sending command [org.jboss.modcluster.mcmp.impl.DefaultMCMPRequest{requestType=CONFIG,wildcard=false,jvmRoute=defaultmetro_u_01,parameters={Balancer=defaultmetro, Host=10.32.34.70, Maxattempts=1, Port=8009, Type=ajp}}] to proxy [jsplb01x.umobi.mobicorp.test/10.32.34.139:80]
> 2011-09-20 09:10:45,134 TRACE [org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Parsing responseStatus:1f53
> 2011-09-20 09:10:45,134 INFO [org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Error parsing response header for command CONFIG
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1937)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:667)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequests(DefaultMCMPHandler.java:476)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:417)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:377)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:480)
> at org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:323)
> 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:619)
> 2011-09-20 09:10:45,135 ERROR [org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Error [null: null: {4}] sending command CONFIG to proxy jsplb01x.umobi.mobicorp.test/10.32.34.139:80, configuration will be reset
> 2011-09-20 09:10:55,523 DEBUG [org.jboss.modcluster.ModClusterService] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Check status for engine [jboss.web]
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (MODCLUSTER-146) Quotes in jsessionId causing sticky sessions to fail
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-146?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-146.
-------------------------------------
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
> Quotes in jsessionId causing sticky sessions to fail
> ----------------------------------------------------
>
> Key: MODCLUSTER-146
> URL: https://issues.jboss.org/browse/MODCLUSTER-146
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: JBoss 6 M2, mod_cluster's httpd
> Reporter: Wim Vandenhaute
> Assignee: Jean-Frederic Clere
> Fix For: 1.1.0.CR3
>
>
> 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, 8 months
[JBoss JIRA] (MODCLUSTER-246) :read-attribute and :write-attribute Error in AS7
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-246?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-246.
-------------------------------------
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
> :read-attribute and :write-attribute Error in AS7
> -------------------------------------------------
>
> Key: MODCLUSTER-246
> URL: https://issues.jboss.org/browse/MODCLUSTER-246
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.3.Final
> Reporter: Stefan Negrea
> Assignee: Jean-Frederic Clere
> Fix For: 1.2.0.Beta4
>
>
> :read-attribute(name=xyz) and :write-attribute(name=xyz,value=zyx) do not work in console with JBoss AS7.1 nightly builds.
> The expectation is that :read-attribute will return the current value of the property or the default value if the property has not been set. For :write-attribute the expectation is that all the properties listed in :read-resource-description can be set.
> The JBoss was started with the following command:
> bin/standalone.sh --server-config=standalone-ha.xml
> Here is the current output for invoking the two operations use the advertise attribute as an example. The outcome of both operations is failed.
> [standalone@localhost:9999 subsystem=modcluster] :read-attribute(name=advertise)
> {
> "outcome" => "failed",
> "failure-description" => "No known attribute advertise",
> "rolled-back" => true
> }
> [standalone@localhost:9999 subsystem=modcluster] :write-attribute(name=advertise,value=true)
> {
> "outcome" => "failed",
> "failure-description" => "No known attribute called advertise",
> "rolled-back" => true
> }
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (MODCLUSTER-84) Add domain versions of enable/disable/stop methods to HAModClusterServiceMBean
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-84?page=com.atlassian.jira.plu... ]
Michal Babacek closed MODCLUSTER-84.
------------------------------------
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 domain versions of enable/disable/stop methods to HAModClusterServiceMBean
> ------------------------------------------------------------------------------
>
> Key: MODCLUSTER-84
> URL: https://issues.jboss.org/browse/MODCLUSTER-84
> Project: mod_cluster
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.0.GA
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 1.1.0.Beta1
>
>
> 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 was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (MODCLUSTER-104) Advertise security key verification does not work
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-104?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-104.
-------------------------------------
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 security key verification does not work
> -------------------------------------------------
>
> Key: MODCLUSTER-104
> URL: https://issues.jboss.org/browse/MODCLUSTER-104
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.2.GA
> Reporter: Paul Ferraro
> Assignee: Jean-Frederic Clere
> Fix For: 1.0.3.GA, 1.1.0.Beta1
>
>
> Currently, AdvertiseListenerImpl.verifyDigest(...) always returns true, regardless of the value provided to MCMPConfiguration.advertiseSecurityKey
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (MODCLUSTER-52) in TC6 jk connection does work with mod_cluster
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-52?page=com.atlassian.jira.plu... ]
Michal Babacek closed MODCLUSTER-52.
------------------------------------
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
> in TC6 jk connection does work with mod_cluster
> -----------------------------------------------
>
> Key: MODCLUSTER-52
> URL: https://issues.jboss.org/browse/MODCLUSTER-52
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.0.Beta3
> Environment: When using TC6 and org.jboss.modcluster.ModClusterListener ajp connector are handle as http.
> Reporter: Jean-Frederic Clere
> Assignee: Jean-Frederic Clere
> Fix For: 1.0.0.Beta4
>
>
> Just use tc6 and add JVMRoute in the engine and the listener. Look to the mod_cluster status page.... The AJP connector is display as HTTP and handled like HTTP so it doesn't work. Note that using protocol="org.apache.coyote.ajp.AjpProtocol" doesn't help the connector is ignored but mod_cluster.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (MODCLUSTER-140) Rpc failure can lead to failure to deploy a webapp
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-140?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-140.
-------------------------------------
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
> Rpc failure can lead to failure to deploy a webapp
> --------------------------------------------------
>
> Key: MODCLUSTER-140
> URL: https://issues.jboss.org/browse/MODCLUSTER-140
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.3.GA, 1.1.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 1.1.0.CR3, MOD_CLUSTER_1_0_10_GA_CP04
>
>
> An exception thrown during an rpc call should never propagate to the web container. See stack trace in forum thread.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months