November 2013 - mod_cluster-issues

[JBoss JIRA] (MODCLUSTER-376) multiple workers with the same id following a tomcat crash/kill

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-376?page=com.atlassian.jira.pl... ] Aaron Ogburn commented on MODCLUSTER-376: ----------------------------------------- Build from attached patch file: https://brewweb.devel.redhat.com//buildinfo?buildID=314749 > multiple workers with the same id following a tomcat crash/kill > --------------------------------------------------------------- > > Key: MODCLUSTER-376 > URL: https://issues.jboss.org/browse/MODCLUSTER-376 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.0.10 > Environment: -JBoss Enterprise Web Server 1.0.2 > -mod_cluster 1.0.10.GA_CP04 > -Red Hat Enterprise Linux 5 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > > Following a kill or crash of tomcat, multiple workers are seen for a single id when a new tomcat node reconnects and reuses the id from the previously crashed worker. > The STATUS's ping check sees the old crashed worker first for the id and so pings the wrong destination. Thus the ping fails, and load factor is not applied. The persistent -1 load state leads to 503s. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-376) multiple workers with the same id following a tomcat crash/kill

by Aaron Ogburn (JIRA)

Aaron Ogburn created MODCLUSTER-376: --------------------------------------- Summary: multiple workers with the same id following a tomcat crash/kill Key: MODCLUSTER-376 URL: https://issues.jboss.org/browse/MODCLUSTER-376 Project: mod_cluster Issue Type: Bug Affects Versions: 1.0.10 Environment: -JBoss Enterprise Web Server 1.0.2 -mod_cluster 1.0.10.GA_CP04 -Red Hat Enterprise Linux 5 Reporter: Aaron Ogburn Assignee: Jean-Frederic Clere Following a kill or crash of tomcat, multiple workers are seen for a single id when a new tomcat node reconnects and reuses the id from the previously crashed worker. The STATUS's ping check sees the old crashed worker first for the id and so pings the wrong destination. Thus the ping fails, and load factor is not applied. The persistent -1 load state leads to 503s. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-339) "proxy: DNS lookup failure" with IPv6 on Solaris

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-339?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-339: ---------------------------------------------------- Scott Mumford <smumford(a)redhat.com> made a comment on [bug 963720|https://bugzilla.redhat.com/show_bug.cgi?id=963720] Thanks for that Michal. I still can't see where that's stated in the link. I guess I need to get better at reading pull requests. Have added Doc Text and marked for inclusion in EAP 6.2 Release Notes. > "proxy: DNS lookup failure" with IPv6 on Solaris > ------------------------------------------------ > > Key: MODCLUSTER-339 > URL: https://issues.jboss.org/browse/MODCLUSTER-339 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.3.Final, 1.2.4.Final > Environment: Solaris 10 x86, Solaris 11 x86, Solaris 11 SPARC > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > Priority: Critical > Labels: ipv6 > Fix For: 1.2.5.Final > > Attachments: access_log-mod_cluster, error_log-mod_cluster, error_log-mod_cluster-RHEL, error_log-proxypass, error_log_pull20, http.conf, mod_manager.so, sockaddr.lo_fedora18_x86_64, sockaddr.lo_solaris11_sparc64 > > > h2. Failure with mod_cluster > Having the following setting: > {code:title=mod_cluster.conf|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > LoadModule slotmem_module modules/mod_slotmem.so > LoadModule manager_module modules/mod_manager.so > LoadModule proxy_cluster_module modules/mod_proxy_cluster.so > LoadModule advertise_module modules/mod_advertise.so > MemManagerFile "/tmp/mod_cluster-eap6/jboss-ews-2.0/var/cache/mod_cluster" > ServerName [2620:52:0:105f::ffff:50]:2080 > <IfModule manager_module> > Listen [2620:52:0:105f::ffff:50]:6666 > LogLevel debug > <VirtualHost [2620:52:0:105f::ffff:50]:6666> > ServerName [2620:52:0:105f::ffff:50]:6666 > <Directory /> > Order deny,allow > Deny from all > Allow from all > </Directory> > KeepAliveTimeout 60 > MaxKeepAliveRequests 0 > ServerAdvertise on > AdvertiseFrequency 5 > ManagerBalancerName qacluster > AdvertiseGroup [ff01::7]:23964 > EnableMCPMReceive > <Location /mcm> > SetHandler mod_cluster-manager > Order deny,allow > Deny from all > Allow from all > </Location> > </VirtualHost> > </IfModule> > {code} > I get a weird {{proxy: DNS lookup failure}} as soon as worker sends {{CONFIGURE}}}: > {code:title=access_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "INFO / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "CONFIG / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "STATUS / HTTP/1.1" 200 64 "-" "ClusterListener/1.0" > ... > {code} > {code:title=error_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > ... > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans INFO (/) > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler INFO (/) processing: "" > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2647): manager_handler INFO OK > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans CONFIG (/) > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler CONFIG (/) processing: "JVMRoute=jboss-eap-6.1&Host=%5B2620%3A52%3A0%3A105f%3A0%3A0%3Affff%3A50%252%5D&Maxattempts=1&Port=8009&StickySessionForce=No&Type=ajp&ping=10" > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2647): manager_handler CONFIG OK > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans STATUS (/) > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler STATUS (/) processing: "JVMRoute=jboss-eap-6.1&Load=100" > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1638): Processing STATUS > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(655): add_balancer_node: Create balancer balancer://qacluster > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(426): Created: worker for ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009 > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(532): proxy: initialized worker 1 in child 16847 for (2620:52:0:105f:0:0:ffff:50%2) min=0 max=25 smax=25 > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(601): Created: worker for ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009 1 (status): 1 > [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (2620:52:0:105f:0:0:ffff:50%2) > [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009/ to 2620:52:0:105f:0:0:ffff:50%2:8009 > [Thu May 16 08:37:24 2013] [error] [client 2620:52:0:105f::ffff:50] proxy: DNS lookup failure for: 2620:52:0:105f:0:0:ffff:50%2 returned by / > [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (2620:52:0:105f:0:0:ffff:50%2) > ... > {code} > An attempt to access the mod_cluster manager console yields an unpleasant {{NOTOK}} (obviously, we have All workers are in error state...): > {code} > curl -g [2620:52:0:105f::ffff:50]:6666/mcm > ... > <h1> Node jboss-eap-6.1 (ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009): </h1> > <a href="/mcm?nonce=1bddeeea-f9d5-eeea-ee5b-e3a5e3c0a965&Cmd=ENABLE-APP&Range=NODE&JVMRoute=jboss-eap-6.1">Enable Contexts</a> <a href="/mcm?nonce=1bddeeea-f9d5-eeea-ee5b-e3a5e3c0a965&Cmd=DISABLE-APP&Range=NODE&JVMRoute=jboss-eap-6.1">Disable Contexts</a><br/> > Balancer: qacluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 26,Ttl: 60000000,Status: NOTOK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: -1 > {code} > You might take a look at the logs: [^error_log-mod_cluster], [^access_log-mod_cluster]. > h2. ProxyPass itself works just fine > On the other hand, when I had tried this: > {code:title=proxypass.conf|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > LoadModule proxy_ajp_module modules/mod_proxy_ajp.so > ServerName [2620:52:0:105f::ffff:50]:2080 > Listen [2620:52:0:105f::ffff:50]:6666 > LogLevel debug > <VirtualHost [2620:52:0:105f::ffff:50]:6666> > ServerName [2620:52:0:105f::ffff:50]:6666 > ProxyPass / ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > ProxyPassReverse / ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > <Directory /> > Order deny,allow > Deny from all > Allow from all > </Directory> > </VirtualHost> > {code} > I received: > {code:title=error_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > ... > [Thu May 16 08:29:00 2013] [debug] mod_proxy_ajp.c(45): proxy: AJP: canonicalising URL //[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(1506): [client 2620:52:0:105f::ffff:50] proxy: ajp: found worker ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ for ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] mod_proxy.c(1020): Running scheme ajp handler (attempt 0) > [Thu May 16 08:29:00 2013] [debug] mod_proxy_http.c(1963): proxy: HTTP: declining URL ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] mod_proxy_ajp.c(681): proxy: AJP: serving URL ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2011): proxy: AJP: has acquired connection for (2620:52:0:105f:0:0:ffff:50) > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ to 2620:52:0:105f:0:0:ffff:50:8009 > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2193): proxy: connected / to 2620:52:0:105f:0:0:ffff:50:8009 > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2444): proxy: AJP: fam 26 socket created to connect to 2620:52:0:105f:0:0:ffff:50 > ... > {code} > And from the client's side, it worked: > {{curl -g [2620:52:0:105f::ffff:50]:6666/}} brought me the worker's home page (EAP's welcome in this case). > Take a look at the whole log [^error_log-proxypass]. > *Note:* The [^http.conf] was the same both for mod_cluster and for proxypass test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-339) "proxy: DNS lookup failure" with IPv6 on Solaris

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-339?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-339: ---------------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> made a comment on [bug 963720|https://bugzilla.redhat.com/show_bug.cgi?id=963720] Resolution was this: https://github.com/modcluster/mod_cluster/pull/20/ In my own words: An unnecessary zone string is removed from the received message. > "proxy: DNS lookup failure" with IPv6 on Solaris > ------------------------------------------------ > > Key: MODCLUSTER-339 > URL: https://issues.jboss.org/browse/MODCLUSTER-339 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.3.Final, 1.2.4.Final > Environment: Solaris 10 x86, Solaris 11 x86, Solaris 11 SPARC > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > Priority: Critical > Labels: ipv6 > Fix For: 1.2.5.Final > > Attachments: access_log-mod_cluster, error_log-mod_cluster, error_log-mod_cluster-RHEL, error_log-proxypass, error_log_pull20, http.conf, mod_manager.so, sockaddr.lo_fedora18_x86_64, sockaddr.lo_solaris11_sparc64 > > > h2. Failure with mod_cluster > Having the following setting: > {code:title=mod_cluster.conf|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > LoadModule slotmem_module modules/mod_slotmem.so > LoadModule manager_module modules/mod_manager.so > LoadModule proxy_cluster_module modules/mod_proxy_cluster.so > LoadModule advertise_module modules/mod_advertise.so > MemManagerFile "/tmp/mod_cluster-eap6/jboss-ews-2.0/var/cache/mod_cluster" > ServerName [2620:52:0:105f::ffff:50]:2080 > <IfModule manager_module> > Listen [2620:52:0:105f::ffff:50]:6666 > LogLevel debug > <VirtualHost [2620:52:0:105f::ffff:50]:6666> > ServerName [2620:52:0:105f::ffff:50]:6666 > <Directory /> > Order deny,allow > Deny from all > Allow from all > </Directory> > KeepAliveTimeout 60 > MaxKeepAliveRequests 0 > ServerAdvertise on > AdvertiseFrequency 5 > ManagerBalancerName qacluster > AdvertiseGroup [ff01::7]:23964 > EnableMCPMReceive > <Location /mcm> > SetHandler mod_cluster-manager > Order deny,allow > Deny from all > Allow from all > </Location> > </VirtualHost> > </IfModule> > {code} > I get a weird {{proxy: DNS lookup failure}} as soon as worker sends {{CONFIGURE}}}: > {code:title=access_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "INFO / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "CONFIG / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "STATUS / HTTP/1.1" 200 64 "-" "ClusterListener/1.0" > ... > {code} > {code:title=error_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > ... > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans INFO (/) > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler INFO (/) processing: "" > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2647): manager_handler INFO OK > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans CONFIG (/) > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler CONFIG (/) processing: "JVMRoute=jboss-eap-6.1&Host=%5B2620%3A52%3A0%3A105f%3A0%3A0%3Affff%3A50%252%5D&Maxattempts=1&Port=8009&StickySessionForce=No&Type=ajp&ping=10" > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2647): manager_handler CONFIG OK > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans STATUS (/) > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler STATUS (/) processing: "JVMRoute=jboss-eap-6.1&Load=100" > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1638): Processing STATUS > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(655): add_balancer_node: Create balancer balancer://qacluster > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(426): Created: worker for ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009 > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(532): proxy: initialized worker 1 in child 16847 for (2620:52:0:105f:0:0:ffff:50%2) min=0 max=25 smax=25 > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(601): Created: worker for ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009 1 (status): 1 > [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (2620:52:0:105f:0:0:ffff:50%2) > [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009/ to 2620:52:0:105f:0:0:ffff:50%2:8009 > [Thu May 16 08:37:24 2013] [error] [client 2620:52:0:105f::ffff:50] proxy: DNS lookup failure for: 2620:52:0:105f:0:0:ffff:50%2 returned by / > [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (2620:52:0:105f:0:0:ffff:50%2) > ... > {code} > An attempt to access the mod_cluster manager console yields an unpleasant {{NOTOK}} (obviously, we have All workers are in error state...): > {code} > curl -g [2620:52:0:105f::ffff:50]:6666/mcm > ... > <h1> Node jboss-eap-6.1 (ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009): </h1> > <a href="/mcm?nonce=1bddeeea-f9d5-eeea-ee5b-e3a5e3c0a965&Cmd=ENABLE-APP&Range=NODE&JVMRoute=jboss-eap-6.1">Enable Contexts</a> <a href="/mcm?nonce=1bddeeea-f9d5-eeea-ee5b-e3a5e3c0a965&Cmd=DISABLE-APP&Range=NODE&JVMRoute=jboss-eap-6.1">Disable Contexts</a><br/> > Balancer: qacluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 26,Ttl: 60000000,Status: NOTOK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: -1 > {code} > You might take a look at the logs: [^error_log-mod_cluster], [^access_log-mod_cluster]. > h2. ProxyPass itself works just fine > On the other hand, when I had tried this: > {code:title=proxypass.conf|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > LoadModule proxy_ajp_module modules/mod_proxy_ajp.so > ServerName [2620:52:0:105f::ffff:50]:2080 > Listen [2620:52:0:105f::ffff:50]:6666 > LogLevel debug > <VirtualHost [2620:52:0:105f::ffff:50]:6666> > ServerName [2620:52:0:105f::ffff:50]:6666 > ProxyPass / ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > ProxyPassReverse / ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > <Directory /> > Order deny,allow > Deny from all > Allow from all > </Directory> > </VirtualHost> > {code} > I received: > {code:title=error_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > ... > [Thu May 16 08:29:00 2013] [debug] mod_proxy_ajp.c(45): proxy: AJP: canonicalising URL //[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(1506): [client 2620:52:0:105f::ffff:50] proxy: ajp: found worker ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ for ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] mod_proxy.c(1020): Running scheme ajp handler (attempt 0) > [Thu May 16 08:29:00 2013] [debug] mod_proxy_http.c(1963): proxy: HTTP: declining URL ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] mod_proxy_ajp.c(681): proxy: AJP: serving URL ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2011): proxy: AJP: has acquired connection for (2620:52:0:105f:0:0:ffff:50) > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ to 2620:52:0:105f:0:0:ffff:50:8009 > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2193): proxy: connected / to 2620:52:0:105f:0:0:ffff:50:8009 > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2444): proxy: AJP: fam 26 socket created to connect to 2620:52:0:105f:0:0:ffff:50 > ... > {code} > And from the client's side, it worked: > {{curl -g [2620:52:0:105f::ffff:50]:6666/}} brought me the worker's home page (EAP's welcome in this case). > Take a look at the whole log [^error_log-proxypass]. > *Note:* The [^http.conf] was the same both for mod_cluster and for proxypass test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-339) "proxy: DNS lookup failure" with IPv6 on Solaris

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-339?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-339: ---------------------------------------------------- Scott Mumford <smumford(a)redhat.com> made a comment on [bug 963720|https://bugzilla.redhat.com/show_bug.cgi?id=963720] So what did we wind up doing to resolve this? None of the linked tickets explicitly state what the fix was (that I could see, anyway). Did we remove the problematic zone? Or find a way to make Solaris play nice with it? Need to know how we fixed this for the Release Note. > "proxy: DNS lookup failure" with IPv6 on Solaris > ------------------------------------------------ > > Key: MODCLUSTER-339 > URL: https://issues.jboss.org/browse/MODCLUSTER-339 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.3.Final, 1.2.4.Final > Environment: Solaris 10 x86, Solaris 11 x86, Solaris 11 SPARC > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > Priority: Critical > Labels: ipv6 > Fix For: 1.2.5.Final > > Attachments: access_log-mod_cluster, error_log-mod_cluster, error_log-mod_cluster-RHEL, error_log-proxypass, error_log_pull20, http.conf, mod_manager.so, sockaddr.lo_fedora18_x86_64, sockaddr.lo_solaris11_sparc64 > > > h2. Failure with mod_cluster > Having the following setting: > {code:title=mod_cluster.conf|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > LoadModule slotmem_module modules/mod_slotmem.so > LoadModule manager_module modules/mod_manager.so > LoadModule proxy_cluster_module modules/mod_proxy_cluster.so > LoadModule advertise_module modules/mod_advertise.so > MemManagerFile "/tmp/mod_cluster-eap6/jboss-ews-2.0/var/cache/mod_cluster" > ServerName [2620:52:0:105f::ffff:50]:2080 > <IfModule manager_module> > Listen [2620:52:0:105f::ffff:50]:6666 > LogLevel debug > <VirtualHost [2620:52:0:105f::ffff:50]:6666> > ServerName [2620:52:0:105f::ffff:50]:6666 > <Directory /> > Order deny,allow > Deny from all > Allow from all > </Directory> > KeepAliveTimeout 60 > MaxKeepAliveRequests 0 > ServerAdvertise on > AdvertiseFrequency 5 > ManagerBalancerName qacluster > AdvertiseGroup [ff01::7]:23964 > EnableMCPMReceive > <Location /mcm> > SetHandler mod_cluster-manager > Order deny,allow > Deny from all > Allow from all > </Location> > </VirtualHost> > </IfModule> > {code} > I get a weird {{proxy: DNS lookup failure}} as soon as worker sends {{CONFIGURE}}}: > {code:title=access_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "INFO / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "CONFIG / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "STATUS / HTTP/1.1" 200 64 "-" "ClusterListener/1.0" > ... > {code} > {code:title=error_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > ... > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans INFO (/) > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler INFO (/) processing: "" > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2647): manager_handler INFO OK > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans CONFIG (/) > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler CONFIG (/) processing: "JVMRoute=jboss-eap-6.1&Host=%5B2620%3A52%3A0%3A105f%3A0%3A0%3Affff%3A50%252%5D&Maxattempts=1&Port=8009&StickySessionForce=No&Type=ajp&ping=10" > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2647): manager_handler CONFIG OK > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans STATUS (/) > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler STATUS (/) processing: "JVMRoute=jboss-eap-6.1&Load=100" > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1638): Processing STATUS > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(655): add_balancer_node: Create balancer balancer://qacluster > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(426): Created: worker for ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009 > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(532): proxy: initialized worker 1 in child 16847 for (2620:52:0:105f:0:0:ffff:50%2) min=0 max=25 smax=25 > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(601): Created: worker for ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009 1 (status): 1 > [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (2620:52:0:105f:0:0:ffff:50%2) > [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009/ to 2620:52:0:105f:0:0:ffff:50%2:8009 > [Thu May 16 08:37:24 2013] [error] [client 2620:52:0:105f::ffff:50] proxy: DNS lookup failure for: 2620:52:0:105f:0:0:ffff:50%2 returned by / > [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (2620:52:0:105f:0:0:ffff:50%2) > ... > {code} > An attempt to access the mod_cluster manager console yields an unpleasant {{NOTOK}} (obviously, we have All workers are in error state...): > {code} > curl -g [2620:52:0:105f::ffff:50]:6666/mcm > ... > <h1> Node jboss-eap-6.1 (ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009): </h1> > <a href="/mcm?nonce=1bddeeea-f9d5-eeea-ee5b-e3a5e3c0a965&Cmd=ENABLE-APP&Range=NODE&JVMRoute=jboss-eap-6.1">Enable Contexts</a> <a href="/mcm?nonce=1bddeeea-f9d5-eeea-ee5b-e3a5e3c0a965&Cmd=DISABLE-APP&Range=NODE&JVMRoute=jboss-eap-6.1">Disable Contexts</a><br/> > Balancer: qacluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 26,Ttl: 60000000,Status: NOTOK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: -1 > {code} > You might take a look at the logs: [^error_log-mod_cluster], [^access_log-mod_cluster]. > h2. ProxyPass itself works just fine > On the other hand, when I had tried this: > {code:title=proxypass.conf|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > LoadModule proxy_ajp_module modules/mod_proxy_ajp.so > ServerName [2620:52:0:105f::ffff:50]:2080 > Listen [2620:52:0:105f::ffff:50]:6666 > LogLevel debug > <VirtualHost [2620:52:0:105f::ffff:50]:6666> > ServerName [2620:52:0:105f::ffff:50]:6666 > ProxyPass / ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > ProxyPassReverse / ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > <Directory /> > Order deny,allow > Deny from all > Allow from all > </Directory> > </VirtualHost> > {code} > I received: > {code:title=error_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > ... > [Thu May 16 08:29:00 2013] [debug] mod_proxy_ajp.c(45): proxy: AJP: canonicalising URL //[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(1506): [client 2620:52:0:105f::ffff:50] proxy: ajp: found worker ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ for ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] mod_proxy.c(1020): Running scheme ajp handler (attempt 0) > [Thu May 16 08:29:00 2013] [debug] mod_proxy_http.c(1963): proxy: HTTP: declining URL ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] mod_proxy_ajp.c(681): proxy: AJP: serving URL ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2011): proxy: AJP: has acquired connection for (2620:52:0:105f:0:0:ffff:50) > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ to 2620:52:0:105f:0:0:ffff:50:8009 > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2193): proxy: connected / to 2620:52:0:105f:0:0:ffff:50:8009 > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2444): proxy: AJP: fam 26 socket created to connect to 2620:52:0:105f:0:0:ffff:50 > ... > {code} > And from the client's side, it worked: > {{curl -g [2620:52:0:105f::ffff:50]:6666/}} brought me the worker's home page (EAP's welcome in this case). > Take a look at the whole log [^error_log-proxypass]. > *Note:* The [^http.conf] was the same both for mod_cluster and for proxypass test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-335) Regression in ProxyPass integration

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-335?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-335: ---------------------------------------------------- Scott Mumford <smumford(a)redhat.com> made a comment on [bug 960243|https://bugzilla.redhat.com/show_bug.cgi?id=960243] Added draft Doc Text (albeit a little light on the 'how' of the fix). Marking for inclusion in 6.2 Release Notes document. > Regression in ProxyPass integration > ----------------------------------- > > Key: MODCLUSTER-335 > URL: https://issues.jboss.org/browse/MODCLUSTER-335 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.2.4.Final > Environment: RHEL6 x86_64, the rest is to be confirmed... > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > Fix For: 1.2.5.Final > > Attachments: logs-and-configs-m_c-1.2.3.zip, logs-and-configs-m_c-1.2.4.zip, test-run-modProxyOnlyPartOfUrlSpaceTest-mod_cluster-1.2.3.log, test-run-modProxyOnlyPartOfUrlSpaceTest-mod_cluster-1.2.4.log > > > This configuration & test worked just fine with 1.2.3.Final and it is broken in 1.2.4.Final, so we have a *regression* here, I guess. > {code} > ProxyPassMatch ^/app/static/ ! > ProxyPass /app balancer://qacluster stickysession=JSESSIONID|jsessionid nofailover=on > ProxyPass / ! > ProxyPassReverse /app balancer://qacluster > ProxyPassReverseCookieDomain / /app/ > ProxyPassReverseCookiePath / /app/ > ProxyPreserveHost on > {code} > Accessing e.g. {{/app/clusterbench/requestinfo/}} returns HTTP 503. *requestinfo* comes from the famous [CommonRequestInfoServlet.java|https://github.com/Karm/clusterbench/blob/s...]. > h3. mod_cluster 1.2.3 ProxyPass test: > *Failed tests* > * modProxyOnlyPartOfUrlSpaceTest: Known fail: [JBQA-7899] Assert #10 Session ID must always be the same. > * modProxyWithoutSessionId: Assert #1, fail, known as [MODCLUSTER-334], http://10.16.45.160:2080/clusterbench/requestinfo/ should have been available... > h3. mod_cluster 1.2.4 ProxyPass test: > *Failed tests* > * modProxyOnlyPartOfUrlSpaceTest: Assert #1, fail, http://10.16.45.160:2080/app/clusterbench/requestinfo/ should have been available... > * modProxyWithoutSessionId: Assert #1, fail, known as [MODCLUSTER-334], http://10.16.45.160:2080/clusterbench/requestinfo/ should have been available... > What the test does is it accesses various URLs, getting either static content from httpd or a dynamic one from application server. > Browse the attached files for complete configs, debug logs and test results. Ping me, if the zipped file structure does not make sense to you... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-334) mod_cluster core when use ProxyPass / balancer://bal and CreateBalancers 1

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-334?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-334: ---------------------------------------------------- Scott Mumford <smumford(a)redhat.com> made a comment on [bug 958991|https://bugzilla.redhat.com/show_bug.cgi?id=958991] Added Doc Text draft based on the 'Known Issue' text in bug 958990. The above draft assumes that the workaround was adopted in this release as a default. Please comment with information if this is incorrect. > mod_cluster core when use ProxyPass / balancer://bal and CreateBalancers 1 > -------------------------------------------------------------------------- > > Key: MODCLUSTER-334 > URL: https://issues.jboss.org/browse/MODCLUSTER-334 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.2.4.Final > Environment: Any > Reporter: Jean-Frederic Clere > Assignee: Jean-Frederic Clere > Fix For: 1.2.5.Final > > > Use something like: > ProxyPass / balancer://neo5 > CreateBalancers 1 > When the first STATUS is received from a node using the balancer (neo5) httpd will dump a core. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-374) "httpd version 2.4.6 doesn't match version 2.4.6" logging

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-374?page=com.atlassian.jira.pl... ] Michal Babacek edited comment on MODCLUSTER-374 at 11/20/13 10:21 AM: ---------------------------------------------------------------------- Kudos for this bughunt goes to [~marcodanti]. BTW: The bug hadn't been ignored, it was well noted and shall be resolved. It's been confirmed by yet another guy now, ruling out the possibility of some weird glitch. was (Author: mbabacek): Kudos for this bughunt goes to [~marcodanti]. BTW: The bug hadn't been ignored, it was well noted and shall be resolved. Now it's been confirmed by yet another guy now, ruling out the possibility of some weird glitch. > "httpd version 2.4.6 doesn't match version 2.4.6" logging > --------------------------------------------------------- > > Key: MODCLUSTER-374 > URL: https://issues.jboss.org/browse/MODCLUSTER-374 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.3.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > Priority: Minor > Fix For: 1.3.0.Alpha2 > > > {noformat} > [Mon Nov 18 14:03:11.797623 2013] [:warn] [pid 29424] httpd version 2.4.6 doesn't match version 2.4.6 used by mod_proxy_cluster.c > {noformat} > Seems like there is still problem with this logging. I have compiled against 2.4.6 all from F19 repo and get this message. What is wrong, magic number maybe? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-374) "httpd version 2.4.6 doesn't match version 2.4.6" logging

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-374?page=com.atlassian.jira.pl... ] Michal Babacek commented on MODCLUSTER-374: ------------------------------------------- Kudos for this bughunt goes to [~marcodanti]. BTW: The bug hadn't been ignored, it was well noted and shall be resolved. Now it's been confirmed by yet another guy now, ruling out the possibility of some weird glitch. > "httpd version 2.4.6 doesn't match version 2.4.6" logging > --------------------------------------------------------- > > Key: MODCLUSTER-374 > URL: https://issues.jboss.org/browse/MODCLUSTER-374 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.3.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > Priority: Minor > Fix For: 1.3.0.Alpha2 > > > {noformat} > [Mon Nov 18 14:03:11.797623 2013] [:warn] [pid 29424] httpd version 2.4.6 doesn't match version 2.4.6 used by mod_proxy_cluster.c > {noformat} > Seems like there is still problem with this logging. I have compiled against 2.4.6 all from F19 repo and get this message. What is wrong, magic number maybe? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-374) "httpd version 2.4.6 doesn't match version 2.4.6" logging

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-374?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-374: -------------------------------------- Forum Reference: https://community.jboss.org/message/835722#835722 > "httpd version 2.4.6 doesn't match version 2.4.6" logging > --------------------------------------------------------- > > Key: MODCLUSTER-374 > URL: https://issues.jboss.org/browse/MODCLUSTER-374 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.3.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > Priority: Minor > Fix For: 1.3.0.Alpha2 > > > {noformat} > [Mon Nov 18 14:03:11.797623 2013] [:warn] [pid 29424] httpd version 2.4.6 doesn't match version 2.4.6 used by mod_proxy_cluster.c > {noformat} > Seems like there is still problem with this logging. I have compiled against 2.4.6 all from F19 repo and get this message. What is wrong, magic number maybe? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues November 2013