May 2010 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] Created: (MODCLUSTER-135) update zlib to 1.2.4

by Jean-Frederic Clere (JIRA)

update zlib to 1.2.4 --------------------- Key: MODCLUSTER-135 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-135 Project: mod_cluster Issue Type: Feature Request Reporter: Jean-Frederic Clere Assignee: Jean-Frederic Clere -- 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

14 years, 6 months

1
5
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-156) Parsing of IPv6 loopback address fails

by Bela Ban (JIRA)

Parsing of IPv6 loopback address fails -------------------------------------- Key: MODCLUSTER-156 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-156 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.0.CR1 Reporter: Bela Ban Assignee: Jean-Frederic Clere Fix For: 1.1.0.CR2 The IPv6 loopback addresss ::1 cannot be parsed. I suspect this also fails for regular IPv6 addresses. The stack trace is: 04:18:33,829 ERROR [STDERR] Exception in thread "pool-5-thread-1" java.lang.NumberFormatException: For input stri ng: ":1:8000" 04:18:33,829 ERROR [STDERR] at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 04:18:33,830 ERROR [STDERR] at java.lang.Integer.parseInt(Integer.java:481) 04:18:33,830 ERROR [STDERR] at java.lang.Integer.parseInt(Integer.java:514) 04:18:33,830 ERROR [STDERR] at org.jboss.modcluster.Utils.parseSocketAddress(Utils.java:115) 04:18:33,830 ERROR [STDERR] at org.jboss.modcluster.Utils.parseSocketAddress(Utils.java:76) 04:18:33,830 ERROR [STDERR] at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl$AdvertiseListenerWor ker.run(AdvertiseListenerImpl.java:505) 04:18:33,830 ERROR [STDERR] 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

14 years, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-159) Clean shutdown logic can still inadvertently kill requests for non-distributed contexts.

by Paul Ferraro (JIRA)

Clean shutdown logic can still inadvertently kill requests for non-distributed contexts. ---------------------------------------------------------------------------------------- Key: MODCLUSTER-159 URL: https://jira.jboss.org/browse/MODCLUSTER-159 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.0.CR2 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 1.1.0.CR3 After sessions are drained from a context, we still need to drain pending requests. It is not enough to send a single STOP-APP. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-158) Avoid unnecessary open sockets for non-master nodes

by Paul Ferraro (JIRA)

Avoid unnecessary open sockets for non-master nodes --------------------------------------------------- Key: MODCLUSTER-158 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-158 Project: mod_cluster Issue Type: Feature Request Affects Versions: 1.1.0.CR2, 1.0.3.GA Reporter: Paul Ferraro Assignee: Jean-Frederic Clere Fix For: 1.0.4.GA, 1.1.0.CR3 When a node is being reset, or when it first comes online, an INFO request is sent to the proxy. If this node is not the HASingleton master, this socket connection will typically remain open, unused, until it times out. We ought to proactively close this connection. -- 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

14 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-157) SystemMemoryUsageLoadMetric returns wrong load metric

by Masafumi Miura (JIRA)

SystemMemoryUsageLoadMetric returns wrong load metric ----------------------------------------------------- Key: MODCLUSTER-157 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-157 Project: mod_cluster Issue Type: Bug Affects Versions: 1.0.3.GA, 1.0.2.GA Reporter: Masafumi Miura Assignee: Jean-Frederic Clere Fix For: 1.0.4.GA When using SystemMemoryUsageLoadMetric, mod_cluster prioritizes dispatching requests to a machine which are using system memory higher than other machines. This loadbalancing behaviour is odd. SystemMemoryUsageLoadMetric[1] returns wrong load metric. The SystemMemoryUsageLoadMetric#getLoad() should not return "free / total". It should return "(total - free) / total" (= usage / total ) like HeapMemoryUsageLoadMetric[2]. [1] http://anonsvn.jboss.org/repos/mod_cluster/tags/1.0.3.GA/src/main/java/or... [2] http://anonsvn.jboss.org/repos/mod_cluster/tags/1.0.3.GA/src/main/java/or... -- 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

14 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-128) INFO and mod_cluster_manager/ displays milliseconds and DUMP second

by Jean-Frederic Clere (JIRA)

INFO and mod_cluster_manager/ displays milliseconds and DUMP second ------------------------------------------------------------------- Key: MODCLUSTER-128 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-128 Project: mod_cluster Issue Type: Bug Environment: any Reporter: Jean-Frederic Clere Assignee: Jean-Frederic Clere Priority: Optional It is just a problem of display or documentation. -- 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

14 years, 7 months

1
5
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-137) Add a solaris10 64 bits sparc in the bundles.

by Jean-Frederic Clere (JIRA)

Add a solaris10 64 bits sparc in the bundles. --------------------------------------------- Key: MODCLUSTER-137 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-137 Project: mod_cluster Issue Type: Feature Request Reporter: Jean-Frederic Clere Assignee: Jean-Frederic Clere Fix For: 1.1.0.CR2 Add a solaris10 64 bits sparc in the bundles. Note it needs some cflags like -m64 -xmemalign=8s -- 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

14 years, 7 months

1
7
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-150) improve packaging so that the bundle can run in ~ too

by Jean-Frederic Clere (JIRA)

improve packaging so that the bundle can run in ~ too ----------------------------------------------------- Key: MODCLUSTER-150 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-150 Project: mod_cluster Issue Type: Feature Request Environment: any Reporter: Jean-Frederic Clere Assignee: Jean-Frederic Clere Fix For: 1.1.0.CR2 the bundles actually are excepted to be started in /opt/jboss/httpd/ in fact it would be nice that they also run in ~/httpd Additionally the quick start parameter should be in the httpd.conf (commented out may be) to ease testing. -- 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

14 years, 7 months

1
3
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-149) proxy_cluster_isup: Can't find worker for 2 (just after CONFIG).

by Jean-Frederic Clere (JIRA)

proxy_cluster_isup: Can't find worker for 2 (just after CONFIG). ---------------------------------------------------------------- Key: MODCLUSTER-149 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-149 Project: mod_cluster Issue Type: Bug Affects Versions: 1.1.0.CR1, 1.0.3.GA 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 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

14 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (MODCLUSTER-155) jboss.mod_cluster.proxyList: invalid hosts cause mod-cluster startup to be delayed

by Bela Ban (JIRA)

jboss.mod_cluster.proxyList: invalid hosts cause mod-cluster startup to be delayed ---------------------------------------------------------------------------------- Key: MODCLUSTER-155 URL: https://jira.jboss.org/jira/browse/MODCLUSTER-155 Project: mod_cluster Issue Type: Bug Reporter: Bela Ban Assignee: Jean-Frederic Clere Attachments: tmp.txt When I set jbss.mod_cluster.proxyList (e.g.) to "http1.dyndns.org:8000,1.2.3.4:8000", mod-cluster does connect to http1.dyndns.org:8000 (assuming it's running), but blocks for 10 minutes trying to connect to 1.2.3.4:8000. It eventually times out connecting to 1.2.3.4, and then seems to default to 127.0.0.1 ! A better mechanism would be to connect via a timeout (see code below), and to simply skip unreachable httpd instances. The reconnect mechanism can always add httpds (which become reachable) later. The code to connect to a socket with a timeout would be: Socket sock=new Socket(new InetSocketAddress("1.2.3.4", 8000), 1000); This call blocks until it has connected to 1.2.3.4:8000, or until 1 sec has elapsed, whichever occurs first. In any case, it doesn't block until the OS defined socket connect timeout kicks in; this might be up to 10 mins ! -- 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

14 years, 7 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues May 2010