August 2014 - mod_cluster-issues - Jboss List Archives

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

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-156?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-156. ------------------------------------- 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 > Parsing of IPv6 loopback address fails > -------------------------------------- > > Key: MODCLUSTER-156 > URL: https://issues.jboss.org/browse/MODCLUSTER-156 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.1.0.CR1 > Reporter: Bela Ban > Assignee: Paul Ferraro > Fix For: 1.1.0.CR3 > > > 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 was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-145) mod_proxy timeout setting is not set correctly from nodeTimeout (JBoss) or ProxyTimeout (httpd) configuration in mod_cluster

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-145?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-145. ------------------------------------- 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_proxy timeout setting is not set correctly from nodeTimeout (JBoss) or ProxyTimeout (httpd) configuration in mod_cluster > ---------------------------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-145 > URL: https://issues.jboss.org/browse/MODCLUSTER-145 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.1.0.CR1 > Environment: CentOS5.4 Xen host > JBossAS 5.1.0.GA running on jdk6 backend, on 2 hosts. mod_cluster configured in clustered mode. > httpd-2.2.3-31.el5.centos.4 with manual mod_cluster configuration on frontend server host > multicast disabled at a network layer > jgroups configured with TCP transport and PING/gossip discovery > Reporter: Brett Cave > Assignee: Jean-Frederic Clere > Labels: failover, mod_cluster, nodeTimeout > > If 1 backend AS process is killed, the frontend proxy still connects clients to the dead node. The node is removed from mod_proxy after 5 minutes. All requests are directed to the dead node. > mod-cluster manager status shows the node as status=NOTOK. > client connections to this node result in 503 errors. > After backend is removed from configuration after 5 minutes, requests to httpd still result in 503 errors as request is routed to the unavailable node. Even new sessions from different hosts try to get routed to the dead node, resulting in 503 errors. > The note on www.jboss.org/mod_cluster/java/properties.html: > When nodeTimeout is not defined, the ProxyTimeout directive Proxy is used. If ProxyTimeout is not defined the server timeout (Timeout) is used (default 300 seconds). nodeTimeout, ProxyTimeout or Timeout is set at the socket level. > As per the configuration below, nodeTimeout is set in the Listener configuration. In addition to that, ProxyTimeout has been enabled and disabled on the httpd server. Timeout is configured with default of 120. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

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

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-135?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-135. ------------------------------------- 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 > update zlib to 1.2.4 > --------------------- > > Key: MODCLUSTER-135 > URL: https://issues.jboss.org/browse/MODCLUSTER-135 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.1.0.Beta1 > Reporter: Jean-Frederic Clere > Assignee: Jean-Frederic Clere > Fix For: 1.1.0.CR3 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-22) Mechanism for excluding specific webapps from mod_cluster httpd registration

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-22?page=com.atlassian.jira.plu... ] Michal Babacek closed MODCLUSTER-22. ------------------------------------ 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 > Mechanism for excluding specific webapps from mod_cluster httpd registration > ---------------------------------------------------------------------------- > > Key: MODCLUSTER-22 > URL: https://issues.jboss.org/browse/MODCLUSTER-22 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Jean-Frederic Clere > Assignee: Paul Ferraro > Fix For: 1.0.0.Beta3 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

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

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-157?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-157. ------------------------------------- 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 > SystemMemoryUsageLoadMetric returns wrong load metric > ----------------------------------------------------- > > Key: MODCLUSTER-157 > URL: https://issues.jboss.org/browse/MODCLUSTER-157 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.3.GA, 1.1.0.CR2 > Reporter: Masafumi Miura > Assignee: Paul Ferraro > Fix For: 1.0.4.GA, 1.1.0.CR3 > > > 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 was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-226) Worker in error state after a request timeout

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-226?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-226. ------------------------------------- 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 > Worker in error state after a request timeout > --------------------------------------------- > > Key: MODCLUSTER-226 > URL: https://issues.jboss.org/browse/MODCLUSTER-226 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.9, 1.1.1.Final > Reporter: Jean-Frederic Clere > Assignee: Jean-Frederic Clere > Attachments: patch.txt > > > An application timeout mark a worker in ERROR, it might be nice to have a better control on that. > In fact the modification would be mostly in Apache httpd mod_proxy code. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

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

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-86?page=com.atlassian.jira.plu... ] Michal Babacek closed MODCLUSTER-86. ------------------------------------ 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 > Interaction with mod_rewrite looks weird for end-users > ------------------------------------------------------ > > Key: MODCLUSTER-86 > URL: https://issues.jboss.org/browse/MODCLUSTER-86 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.1.GA > Environment: Use mod_rewrite and mod_cluster > Reporter: Jean-Frederic Clere > Assignee: Jean-Frederic Clere > Fix For: 1.1.0.Beta1 > > > 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 was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-127) Disable "cnone" request parameter to ease remote invocation on mod_cluster-manager

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-127?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-127. ------------------------------------- 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 > Disable "cnone" request parameter to ease remote invocation on mod_cluster-manager > ---------------------------------------------------------------------------------- > > Key: MODCLUSTER-127 > URL: https://issues.jboss.org/browse/MODCLUSTER-127 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.0.3.GA > Reporter: Noel Rocher > Assignee: Jean-Frederic Clere > Fix For: 1.1.0.CR1 > > > Disable "cnone" request parameter to ease remote invocation on mod_cluster-manager in particular when you think about large set of servers -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-221) Only 100 webapps are detected : Maxcontext doesn't seem to be read

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-221?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-221. ------------------------------------- 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 > Only 100 webapps are detected : Maxcontext doesn't seem to be read > ------------------------------------------------------------------ > > Key: MODCLUSTER-221 > URL: https://issues.jboss.org/browse/MODCLUSTER-221 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.9, 1.1.1.Final > Environment: RHEL5, > JBOSS EAP 5.1.0.GA, > JDK Sun 1.6.0_22, > [root@LB ~/provisionning-from-scratch]$ httpd -V > Server version: Apache/2.2.3 > Server built: Mar 4 2010 09:57:54 > Server's Module Magic Number: 20051115:3 > Server loaded: APR 1.2.7, APR-Util 1.2.7 > Compiled using: APR 1.2.7, APR-Util 1.2.7 > Architecture: 64-bit > Server MPM: Prefork > threaded: no > forked: yes (variable process count) > Server compiled with.... > -D APACHE_MPM_DIR="server/mpm/prefork" > -D APR_HAS_SENDFILE > -D APR_HAS_MMAP > -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) > -D APR_USE_SYSVSEM_SERIALIZE > -D APR_USE_PTHREAD_SERIALIZE > -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT > -D APR_HAS_OTHER_CHILD > -D AP_HAVE_RELIABLE_PIPED_LOGS > -D DYNAMIC_MODULE_LIMIT=128 > -D HTTPD_ROOT="/etc/httpd" > -D SUEXEC_BIN="/usr/sbin/suexec" > -D DEFAULT_PIDLOG="run/httpd.pid" > -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" > -D DEFAULT_LOCKFILE="logs/accept.lock" > -D DEFAULT_ERRORLOG="logs/error_log" > -D AP_TYPES_CONFIG_FILE="conf/mime.types" > -D SERVER_CONFIG_FILE="conf/httpd.conf" > [17:25:43][root@LB ~/provisionning-from-scratch]$ httpd -v > Server version: Apache/2.2.3 > Server built: Mar 4 2010 09:57:54 > Reporter: Baptiste MATHUS > Assignee: Jean-Frederic Clere > Labels: httpd, jboss-as > Fix For: 1.0.10 > > Attachments: httpd.conf > > > We're currently testing an architecture where we deploy 70 webapps in a 3-nodes cluster. > After some times wondering why only some of the webapps were visible in the /mod_cluster-manager URL, we discovered that a Maxcontext parameter existed and was defaulting to 100. > Then we set the Maxcontext parameter to 400, but it doesn't seem to change anything. Still only 100 webapp contexts are detected. > I tried having a look at the C source code, but I don't see anything obvious. > Maybe this parameter is just not read? > Thanks a lot for your help. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-8) Extract AS to mod_cluster communication code from JBossWeb

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-8?page=com.atlassian.jira.plug... ] Michal Babacek closed MODCLUSTER-8. ----------------------------------- 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 > Extract AS to mod_cluster communication code from JBossWeb > ---------------------------------------------------------- > > Key: MODCLUSTER-8 > URL: https://issues.jboss.org/browse/MODCLUSTER-8 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Assignee: Paul Ferraro > Fix For: 1.0.0.Beta1 > > > The ClusterListener class in JBossWeb includes generally useful functionality for communicating from the JBossWeb side to the httpd side. We should re-use that code in the JBoss AS impl as well; no reason to duplicate it. > Task here is to extract the code from ClusterListener into a separate subcomponent. Package it in a separate jar so both JBossWeb and JBoss AS can both consume it without getting into dependency issues vis-a-vis each other. The JBossNative project seems like a logical place to host this code. (We can move it if not). > This should be done with an interface and extensible base implementation approach. JBoss AS will likely want to extend/alter the behavior used by standalone JBossWeb, but the ClusterListener class should be unaware of this. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues August 2014