[JBoss JIRA] (MODCLUSTER-44) Sessions not removed from /mod_cluster-manager app on failover
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-44?page=com.atlassian.jira.plu... ]
Michal Babacek closed MODCLUSTER-44.
------------------------------------
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
> Sessions not removed from /mod_cluster-manager app on failover
> --------------------------------------------------------------
>
> Key: MODCLUSTER-44
> URL: https://issues.jboss.org/browse/MODCLUSTER-44
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.0.Beta3
> Reporter: Bela Ban
> Assignee: Jean-Frederic Clere
> Fix For: 1.0.0.Beta4
>
>
> When I start node1 and create 2 sessions, I see (localhost:8000/mod_cluster-manager):
> SessionIDs:
> id: DrP58P0i889C9crgfGfHQQ__.node1 route: node1
> id: PC4ET-Eeb0KJqsnuvcg0tA__.node1 route: node1
> Then I start node2 and kill node1. Sessions now fail over to node2, but http://localhost:8000/mod_cluster-manager still shows
> SessionIDs:
> id: DrP58P0i889C9crgfGfHQQ__.node1 route: node1
> id: PC4ET-Eeb0KJqsnuvcg0tA__.node1 route: node1
> id: DrP58P0i889C9crgfGfHQQ__.node2 route: node2
> id: PC4ET-Eeb0KJqsnuvcg0tA__.node2 route: node2
> I think the node1-related sessions should be removed because node1 is down !
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (MODCLUSTER-58) windows broken
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-58?page=com.atlassian.jira.plu... ]
Michal Babacek closed MODCLUSTER-58.
------------------------------------
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
> windows broken
> --------------
>
> Key: MODCLUSTER-58
> URL: https://issues.jboss.org/browse/MODCLUSTER-58
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.0.Beta3
> Environment: windoze
> Reporter: Jean-Frederic Clere
> Assignee: Jean-Frederic Clere
> Fix For: 1.0.0.CR1
>
>
> It can't remove nodes:
> +++
> [Mon Mar 09 11:51:47 2009] [debug] mod_manager.c(1368): manager_trans CONFIG (/*)
> [Mon Mar 09 11:51:47 2009] [error] [client 127.0.0.1] (20025)The given path contained wildcard characters: access to /* failed
> +++
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (MODCLUSTER-85) HAModClusterService can throw NullPointerExceptions after a partition merge
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-85?page=com.atlassian.jira.plu... ]
Michal Babacek closed MODCLUSTER-85.
------------------------------------
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
> HAModClusterService can throw NullPointerExceptions after a partition merge
> ---------------------------------------------------------------------------
>
> Key: MODCLUSTER-85
> URL: https://issues.jboss.org/browse/MODCLUSTER-85
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.0.GA
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 1.0.3.GA, 1.1.0.Beta1
>
>
> 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 was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (MODCLUSTER-165) Better no servers connected message
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-165?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-165.
-------------------------------------
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
> Better no servers connected message
> -----------------------------------
>
> Key: MODCLUSTER-165
> URL: https://issues.jboss.org/browse/MODCLUSTER-165
> Project: mod_cluster
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.3.GA
> Environment: All
> Reporter: Jim Tyrrell
> Assignee: Jean-Frederic Clere
> Fix For: 1.1.0.Final
>
> Attachments: Screenshot-Mod_cluster Status - Mozilla Firefox-1.png, Screenshot-Mod_cluster Status - Mozilla Firefox-2.png
>
>
> The default landing screen before any jboss servers have connected is very thin. It would be nice to see a splash screen to have the ability to see that everything is installed correctly, but it is not yet listening or farming any content to the JBoss server instances.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (MODCLUSTER-286) Not well specifed installation instruction
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-286?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-286.
-------------------------------------
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
> Not well specifed installation instruction
> ------------------------------------------
>
> Key: MODCLUSTER-286
> URL: https://issues.jboss.org/browse/MODCLUSTER-286
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.3.Final, 1.2.0.Final
> Reporter: Stefano Nichele
> Assignee: Jean-Frederic Clere
> Fix For: 1.2.1.Beta1
>
>
> Reading Mod_cluster-UserGuide.pdf, section 2.2.2. (Install only the modules), it's not clear that using a httpd version newer than 2.2.13, only mod-cluster modules (mod_manager, mod_proxy_cluster, mod_slotmem, mod_advertise) must be copied (as per README file in mod_proxy source code directory).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (MODCLUSTER-185) Make logging on Tomcat use JDK14LoggerPlugin by default
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-185?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-185.
-------------------------------------
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
> Make logging on Tomcat use JDK14LoggerPlugin by default
> -------------------------------------------------------
>
> Key: MODCLUSTER-185
> URL: https://issues.jboss.org/browse/MODCLUSTER-185
> Project: mod_cluster
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.0.Final
> Environment: Windows 7 x64, Java 1.6.0_18-b07 32bit, Tomcat 6.0.29 + APR 1.1.20 + load-demo webapp
> jboss-logging-jdk.jar Implementation-Version: 2.1.1.GA
> jboss-logging-spi.jar Implementation-Version: 2.0.5.GA
> Reporter: Ruslan Gainutdinov
> Assignee: Paul Ferraro
> Priority: Minor
> Labels: logging, mod_cluster, tomcat
> Fix For: 1.1.1.Final
>
> Attachments: mod-cluster-listener-jdk-logging.patch
>
>
> I`ve added
> jboss-logging-jdk.jar
> jboss-logging-spi.jar
> mod_cluster.jar
> to Tomcat lib/ directory.
> However, when I start Tomcat, no messages from mod_cluster is displayed.
> By debugging I was able to understand what NullLoggerPlugin is used.
> Where is a code to initialize logging in Tomcat - org.jboss.modcluster.catalina.ModClusterListener.java:65
> however, it is not working because org.jboss.logging.Logger.init() called before it.
> By default, system tries to load log4j plugin, which is not available in this environment.
> After that, it sets NullLoggerPlugin.
> To workaround this, I have added -Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.jdk.JDK14LoggerPlugin
> to java options used when Tomcat is started.
> I propose fixing org.jboss.modcluster.catalina.ModClusterListener.java with patch (attaching in next comment).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (MODCLUSTER-198) Can only rewrite from the root context in httpd if there is a root context deployed in JBoss
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-198?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-198.
-------------------------------------
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
> Can only rewrite from the root context in httpd if there is a root context deployed in JBoss
> --------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-198
> URL: https://issues.jboss.org/browse/MODCLUSTER-198
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.4.GA, 1.1.0.Final
> Reporter: Samuel Mendenhall
> Assignee: Jean-Frederic Clere
> Priority: Minor
> Fix For: 1.0.8, 1.1.1.Final
>
>
> See: http://community.jboss.org/thread/159462
> ====
> I have a working mod_cluster 1.0.4 in front of EAP 5.1 (.com). I have been advised to use mod_rewrite and it works well. But i'm curious about the following scenario:
> mod_cluster set to expose ROOT. ROOT.war removed from JBoss. /sample deployed to jboss. mod_cluster INFO looks like:
> Node: [1],Name: redcloud:8009:jboss.web,Balancer: uat,Domain: ,Host: 192.168.235.128,Port: 8009,Type: ajp,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 88
> Vhost: [1:1:1], Alias: localhost
> Context: [1:1:1], Context: /sample, Status: ENABLED
> When i do:
> RewriteRule ^/sample/(.*)$ balancer://uat/sample/$1 [P,L]
> and ask for my.url/sample/ it works perfectly.
> If i do:
> RewriteRule ^/(.*)$ balancer://uat/sample/$1 [P,L]
> and go to my.url/ i get a 503 from apache and see
> [Wed Dec 01 07:37:20 2010] [debug] mod_proxy_cluster.c(962): get_balancer_by_node balancer NOT found
> [Wed Dec 01 07:37:20 2010] [debug] mod_proxy_cluster.c(962): get_balancer_by_node balancer NOT found
> [Wed Dec 01 07:37:20 2010] [debug] mod_proxy_cluster.c(1137): proxy: byrequests balancer FAILED
> [Wed Dec 01 07:37:20 2010] [error] proxy: CLUSTER: (balancer://uat). All workers are in error state
> in the apache logs.
> If i put ROOT.war back in, mod_cluster-manager INFO shows:
> Node: [1],Name: redcloud:8009:jboss.web,Balancer: uat,Domain: ,Host: 192.168.235.128,Port: 8009,Type: ajp,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 92
> Vhost: [1:1:1], Alias: localhost
> Context: [1:1:1], Context: /sample, Status: ENABLED
> Context: [1:1:2], Context: /, Status: ENABLED
> and my.url/ works (and serves the sameple app under root context).
> So, my question is has anyone seen this behavior with mod_cluster and mod_rewrite? I don't mind having a "dummy" app in to make ROOT visible but i don't necessarily want to have to.
> ====
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (MODCLUSTER-347) mod_cluster-manager may break up aliases from a single VirtualHost, causing a messy page
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-347?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-347.
-------------------------------------
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-manager may break up aliases from a single VirtualHost, causing a messy page
> ----------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-347
> URL: https://issues.jboss.org/browse/MODCLUSTER-347
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.2.4.Final
> Environment: -JBoss Enterprise Application Platform (EAP 6.1.0)
> -mod_cluster 1.2.4.Final
> Reporter: Aaron Ogburn
> Assignee: Jean-Frederic Clere
> Fix For: 1.2.5.Final
>
> Attachments: mod_cluster-manager.html
>
>
> Now that we properly show all the individual virtual hosts for a node, mod_cluster-manager may display a messy page with the aliases from a single Virtual Host broken up with multiple instances of the Virtual Host and its contexts. This can occur with our concurrent start ups now when JBoss has multiple applications bound to virtual servers that are deploying and enabling at once. The dump output demonstrates the cause:
> balancer: [1] Name: mycluster Sticky: 1 [JSESSIONID]/[jsessionid] remove: 0 force: 0 Timeout: 0 maxAttempts: 1
> node: [1:1],Balancer: mycluster,JVMRoute: 4e6189af-0502-3305-8ff3-fad7fee8b516,LBGroup: [],Host: 127.0.0.1,Port: 8009,Type: ajp,flushpackets: 0,flushwait: 10,ping: 10,smax: 1,ttl: 60,timeout: 0
> host: 1 [example3.com] vhost: 3 node: 1
> host: 2 [example2.com] vhost: 3 node: 1
> host: 3 [example.com] vhost: 3 node: 1
> host: 4 [localhost] vhost: 3 node: 1
> host: 5 [example6.com] vhost: 1 node: 1
> host: 6 [example5.com] vhost: 1 node: 1
> host: 7 [example4.com] vhost: 1 node: 1
> host: 8 [testhost2] vhost: 1 node: 1
> host: 9 [default-host] vhost: 3 node: 1
> host: 10 [example9.com] vhost: 2 node: 1
> host: 11 [example8.com] vhost: 2 node: 1
> host: 12 [example7.com] vhost: 2 node: 1
> host: 13 [testhost3] vhost: 2 node: 1
> context: 1 [/helloworld2] vhost: 3 node: 1 status: 1
> context: 2 [/helloworld3] vhost: 1 node: 1 status: 1
> context: 3 [/] vhost: 2 node: 1 status: 1
> The messy html representative of this bad output is attached. Note host entry 9 is for vhost 3, but separated in the html from the other vhost 3 entries.
> The problem is in manager_info_hosts. It assumes all of those entries will be in order, printing out the Virtual Host/Context lines whenever a different vhost entry is seen. It'd be much cleaner if we ensured each VirtualHost was only ever printed once on the page.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months