June 2019 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-466) mod_cluster undersizes the connection pool on httpd 2.2

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-466?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-466: ---------------------------------------------------- Jean-frederic Clere <jclere(a)redhat.com> changed the Status of [bug 1338642|https://bugzilla.redhat.com/show_bug.cgi?id=1338642] from VERIFIED to CLOSED > mod_cluster undersizes the connection pool on httpd 2.2 > ------------------------------------------------------- > > Key: MODCLUSTER-466 > URL: https://issues.jboss.org/browse/MODCLUSTER-466 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Priority: Major > Fix For: 1.3.2.Final, 1.2.13.Final > > > If all threads in a httpd child worker process are saturated with long requests, then all connections in the pool are exhausted, likely leaving none available for additional pings, which then fail with errors like: > [error] (70007)The timeout specified has expired: proxy: ajp: failed to acquire connection for ... > Documentation suggests the connection pool will be sized to ThreadsPerChild+1 to avoid that, but it looks like it is really just ThreadsPerChild on httpd 2.2. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-521) Old MSVC doesn't compile current 1.2.x codebase: mod_proxy_cluster

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-521?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-521: ---------------------------------------------------- Jean-frederic Clere <jclere(a)redhat.com> changed the Status of [bug 1346877|https://bugzilla.redhat.com/show_bug.cgi?id=1346877] from VERIFIED to CLOSED > Old MSVC doesn't compile current 1.2.x codebase: mod_proxy_cluster > ------------------------------------------------------------------ > > Key: MODCLUSTER-521 > URL: https://issues.jboss.org/browse/MODCLUSTER-521 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.13.Final > Environment: Windows > Reporter: Michal Karm > Assignee: Jean-Frederic Clere > Priority: Critical > Fix For: 1.2.14.Final > > > {code} > mod_proxy_cluster.c > .\mod_proxy_cluster.c(1515) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data > .\mod_proxy_cluster.c(2062) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data > .\mod_proxy_cluster.c(2336) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data > .\mod_proxy_cluster.c(2337) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data > .\mod_proxy_cluster.c(3035) : warning C4244: 'return' : conversion from '__int64' to 'int', possible loss of data > .\mod_proxy_cluster.c(3174) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data > .\mod_proxy_cluster.c(3196) : error C2275: 'proxy_context_table' : illegal use of this type as an expression > .\mod_proxy_cluster.c(108) : see declaration of 'proxy_context_table' > .\mod_proxy_cluster.c(3196) : error C2065: 'context_table' : undeclared identifier > .\mod_proxy_cluster.c(3197) : error C2065: 'context_table' : undeclared identifier > .\mod_proxy_cluster.c(3198) : error C2065: 'context_table' : undeclared identifier > .\mod_proxy_cluster.c(3198) : warning C4047: '=' : 'int' differs in levels of indirection from 'proxy_context_table *' > .\mod_proxy_cluster.c(3200) : error C2275: 'proxy_balancer_table' : illegal use of this type as an expression > .\mod_proxy_cluster.c(127) : see declaration of 'proxy_balancer_table' > .\mod_proxy_cluster.c(3200) : error C2065: 'balancer_table' : undeclared identifier > .\mod_proxy_cluster.c(3201) : error C2065: 'balancer_table' : undeclared identifier > .\mod_proxy_cluster.c(3202) : error C2065: 'balancer_table' : undeclared identifier > .\mod_proxy_cluster.c(3202) : warning C4047: '=' : 'int' differs in levels of indirection from 'proxy_balancer_table *' > .\mod_proxy_cluster.c(3204) : error C2275: 'proxy_node_table' : illegal use of this type as an expression > .\mod_proxy_cluster.c(136) : see declaration of 'proxy_node_table' > .\mod_proxy_cluster.c(3204) : error C2065: 'node_table' : undeclared identifier > .\mod_proxy_cluster.c(3205) : error C2065: 'node_table' : undeclared identifier > .\mod_proxy_cluster.c(3206) : error C2065: 'node_table' : undeclared identifier > .\mod_proxy_cluster.c(3206) : warning C4047: '=' : 'int' differs in levels of indirection from 'proxy_node_table *' > .\mod_proxy_cluster.c(3208) : error C2065: 'context_table' : undeclared identifier > .\mod_proxy_cluster.c(3208) : warning C4047: 'function' : 'proxy_context_table *' differs in levels of indirection from 'int' > .\mod_proxy_cluster.c(3208) : warning C4024: 'get_route_balancer' : different types for formal and actual parameter 4 > .\mod_proxy_cluster.c(3208) : error C2065: 'balancer_table' : undeclared identifier > .\mod_proxy_cluster.c(3208) : warning C4047: 'function' : 'proxy_balancer_table *' differs in levels of indirection from 'int' > .\mod_proxy_cluster.c(3208) : warning C4024: 'get_route_balancer' : different types for formal and actual parameter 5 > .\mod_proxy_cluster.c(3208) : error C2065: 'node_table' : undeclared identifier > .\mod_proxy_cluster.c(3208) : warning C4047: 'function' : 'proxy_node_table *' differs in levels of indirection from 'int' > .\mod_proxy_cluster.c(3208) : warning C4024: 'get_route_balancer' : different types for formal and actual parameter 6 > NMAKE : fatal error U1077: 'C:\cmsc\msvc\bin\amd64\cl.EXE' : return code '0x2' > Stop. > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-458) Add JVMRoute or node identifier to httpd/mod_cluster errors

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-458?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-458: ---------------------------------------------------- Jean-frederic Clere <jclere(a)redhat.com> changed the Status of [bug 1338644|https://bugzilla.redhat.com/show_bug.cgi?id=1338644] from VERIFIED to CLOSED > Add JVMRoute or node identifier to httpd/mod_cluster errors > ----------------------------------------------------------- > > Key: MODCLUSTER-458 > URL: https://issues.jboss.org/browse/MODCLUSTER-458 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Reporter: Coty Sutherland > Assignee: Michal Karm > Priority: Major > Fix For: 1.3.2.Final, 1.2.12.Final > > > Messages such as: > [Tue Apr 14 10:38:56 2015] [warn] manager_handler STATUS error: MEM: Can't read node > are very difficult to troubleshoot given the limited context provided. It would be great if we could add some sort of node identifier or the JVMRoute of the node to the message above. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-463) UpperCase Alias never matches any context

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-463?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-463: ---------------------------------------------------- Jean-frederic Clere <jclere(a)redhat.com> changed the Status of [bug 1340958|https://bugzilla.redhat.com/show_bug.cgi?id=1340958] from VERIFIED to CLOSED > UpperCase Alias never matches any context > ----------------------------------------- > > Key: MODCLUSTER-463 > URL: https://issues.jboss.org/browse/MODCLUSTER-463 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.11.Final, 1.3.1.Final > Reporter: Michal Karm > Assignee: Michal Karm > Priority: Major > Fix For: 1.3.3.Final, 1.2.13.Final, 2.0.0.Alpha1 > > Attachments: simplecontext-examples.zip > > > h3. Problem > h4. JBossWeb > Regardless the upper/lower case of an Alias one configured in _JBossWeb (EAP 6.4.3, mod_cluster subsystem 1.2.11.Final)_, it has always been reported to Apache HTTP Server in lower case. For example, the following configuration:{code:xml} > <subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" instance-id="workerXXX" native="false"> > <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/> > <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/> > <virtual-server name="default-host" enable-welcome-root="true"> > <alias name="localhost"/> > <alias name="example.com"/> > </virtual-server> > <virtual-server name="web1" default-web-module="simplecontext-web1"> > <alias name="web1.rhel7GAx86-64"/> > </virtual-server> > <virtual-server name="web2" default-web-module="simplecontext-web2"> > <alias name="web2.rhel7GAx86-64"/> > </virtual-server> > </subsystem> > {code}sends this message with aliases actually being reported in lower case: {{JVMRoute=workerXXX&Alias=web2%2Cweb2.rhel7gax86-64&Context=%2F}}. Having {{aliases}} stored in lower case on the Apache HTTP Server side enables both these URLs to work perfectly:{noformat}curl http://web2.rhel7GAx86-64:6666/ > curl http://web2.rhel7gax86-64:6666/{noformat}. The balancer configuration is just a simple [UseAlias 1|http://fpaste.org/251417/86985831/]. > h4. Undertow > _Undertow (JBossWeb's successor in EAP 7.0.0.DR7, mod_cluster subsystem 1.3.1.Final)_ behaves differently; it reports verbatim what one sets as an alias, so with the following configuration:{code:xml}<subsystem xmlns="urn:jboss:domain:undertow:3.0" instance-id="workerXXX"> > <buffer-cache name="default"/> > <server name="default-server"> > <ajp-listener name="ajp" socket-binding="ajp"/> > <http-listener name="default" redirect-socket="https" socket-binding="http"/> > <host name="default-host" alias="localhost"> > <location name="/" handler="welcome-content"/> > <filter-ref name="server-header"/> > <filter-ref name="x-powered-by-header"/> > </host> > <host name="web1" alias="web1.rhel7GAx86-64"> > <location name="/" handler="web1-content"/> > <filter-ref name="server-header"/> > <filter-ref name="x-powered-by-header"/> > </host> > <host name="web2" alias="web2.rhel7GAx86-64"> > <location name="/" handler="web2-content"/> > <filter-ref name="server-header"/> > <filter-ref name="x-powered-by-header"/> > </host> > </server> > <servlet-container name="default"> > <jsp-config/> > <websockets/> > </servlet-container> > <handlers> > <file name="web1-content" path="${jboss.home.dir}/simplecontext-web1"/> > <file name="web2-content" path="${jboss.home.dir}/simplecontext-web2"/> > <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/> > </handlers> > <filters> > <response-header name="server-header" header-value="WildFly/10" header-name="Server"/> > <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/> > </filters> > </subsystem>{code}, the message reported to Apache HTTP Server actually is:{{JVMRoute=workerXXX&Alias=web2%2Cweb2.rhel7GAx86-64&Context=%2F}}. Due to the fact that aliases are being compared byte-by-byte for equality (because pumping of slash characters takes place) and the accessed domain is always in lower case and alias is stored as it was received, there is never match between these. > The result is that while these work:{{http://web2:6666/}}, {{http://web1:6666/}}, one of the upper case containing ones work at all: {{http://web1.rhel7GAx86-64:6666}} and {{http://web2.rhel7gax86-64:6666/}} neither. By not working I actually mean they return the root of Apache HTTP Server Welcome page instead of correctly forwarding to one of the Application server's virtual host contexts. > Last but not least, while EAP 6.4.3 with JBossWeb itself treats aliases as case-insensitive, EAP 7.0.0.DR7 with Undertow does not; i.e. {{web1.rhel7GAx86-64:8080/}} returns correctly web application content whereas {{web1.rhel7gax86-64:8080/}} returns EAP7 Welcome page. > While the aforementioned is clearly a bug (or a weird feature :)) in Undertow, we must make the Apache HTTP Server code resilient to such behaviour. > h3. Solution > I suggest converting aliases to lower case in mod_manager on ENABLE-APP arrival. According to my preliminary tests, this approach works for both JBossWeb and Undertow equipped workers. I think it's cool to do that: [RFC 1035|https://tools.ietf.org/html/rfc1035#section-2.3.3]. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-397) StickySessions don't work for ProxyPass from unenabled context

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-397?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-397: ---------------------------------------------------- Jean-frederic Clere <jclere(a)redhat.com> changed the Status of [bug 1338641|https://bugzilla.redhat.com/show_bug.cgi?id=1338641] from VERIFIED to CLOSED > StickySessions don't work for ProxyPass from unenabled context > -------------------------------------------------------------- > > Key: MODCLUSTER-397 > URL: https://issues.jboss.org/browse/MODCLUSTER-397 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.8.Final > Reporter: Aaron Ogburn > Assignee: Michal Karm > Priority: Major > Fix For: 1.3.3.Final, 1.2.13.Final, 2.0.0.Alpha1 > > > Sticky sessions are not maintained if you try to ProxyPass from an unenabled context to an enabled one. For example, consider JBoss with just /foo deployed and enabled via MCMP. Then try to ProxyPass / to /foo/ on httpd: > CreateBalancers 1 > ... > ProxyPass / balancer://mycluster/foo/ stickysession=JSESSIONID|jsessionid nofailover=On -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 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: ---------------------------------------------------- Jean-frederic Clere <jclere(a)redhat.com> changed the Status of [bug 960246|https://bugzilla.redhat.com/show_bug.cgi?id=960246] from VERIFIED to CLOSED > 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 Karm > Assignee: Jean-Frederic Clere > Priority: Major > 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 was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 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: ---------------------------------------------------- Jean-frederic Clere <jclere(a)redhat.com> changed the Status of [bug 963723|https://bugzilla.redhat.com/show_bug.cgi?id=963723] from VERIFIED to CLOSED > "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 Karm > 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 was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-505) ProxyErrorOverride=On causes workers in error state after 500 errors

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-505?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-505: ---------------------------------------------------- Jean-frederic Clere <jclere(a)redhat.com> changed the Status of [bug 1309598|https://bugzilla.redhat.com/show_bug.cgi?id=1309598] from VERIFIED to CLOSED > ProxyErrorOverride=On causes workers in error state after 500 errors > --------------------------------------------------------------------- > > Key: MODCLUSTER-505 > URL: https://issues.jboss.org/browse/MODCLUSTER-505 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.2.Final, 1.2.12.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Priority: Major > Fix For: 1.2.14.Final, 1.3.5.Final > > > When a VirtualHost uses ProxyPass to proxy traffic to the backend and uses ProxyErrorOverride to host custom error pages on Apache httpd side, when the backend replies with a 50x error code mod_proxy/mod_cluster marks that worker as down, breaking session stickiness. This behaviour is quite similar to have failonstatus=500 for example. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-412) java.lang.NoSuchMethodError: org.apache.catalina.Context.isStarted()Z, Tomcat6, Windows

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-412?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-412: ---------------------------------------------------- Mladen Turk <mturk(a)redhat.com> changed the Status of [bug 1102012|https://bugzilla.redhat.com/show_bug.cgi?id=1102012] from VERIFIED to CLOSED > java.lang.NoSuchMethodError: org.apache.catalina.Context.isStarted()Z, Tomcat6, Windows > --------------------------------------------------------------------------------------- > > Key: MODCLUSTER-412 > URL: https://issues.jboss.org/browse/MODCLUSTER-412 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.8.Final > Environment: Oracle JDK 1.7, Windows, Tomcat6, Apache Tomcat Native library 1.1.30 using APR version 1.4.8. > Reporter: Michal Karm > Assignee: Jean-Frederic Clere > Priority: Major > Fix For: 1.2.9.Final > > > mod_cluster with Tomcat 6 on Windows fails on initialization in this weird fashion: > {code} > INFO: Loaded APR based Apache Tomcat Native library 1.1.30 using APR version 1.4.8. > May 28, 2014 12:12:40 PM org.apache.catalina.core.AprLifecycleListener init > INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. > May 28, 2014 12:12:41 PM org.apache.catalina.core.AprLifecycleListener initializeSSL > INFO: OpenSSL successfully initialized with version OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 > May 28, 2014 12:12:41 PM org.jboss.modcluster.ModClusterService init > INFO: MODCLUSTER000001: Initializing mod_cluster version ${project.version} > May 28, 2014 12:12:41 PM org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl start > INFO: MODCLUSTER000032: Listening to proxy advertisements on /224.0.7.222:43294 > May 28, 2014 12:12:41 PM org.apache.coyote.http11.Http11AprProtocol init > INFO: Initializing Coyote HTTP/1.1 on http-192.168.122.24-8080 > May 28, 2014 12:12:41 PM org.apache.coyote.ajp.AjpAprProtocol init > INFO: Initializing Coyote AJP/1.3 on ajp-192.168.122.24-8009 > May 28, 2014 12:12:41 PM org.apache.catalina.startup.Catalina load > INFO: Initialization processed in 1928 ms > May 28, 2014 12:12:41 PM org.apache.catalina.core.StandardService start > INFO: Starting service Catalina > May 28, 2014 12:12:41 PM org.apache.catalina.core.StandardEngine start > INFO: Starting Servlet Engine: Apache Tomcat/6.0.39 > May 28, 2014 12:12:41 PM org.apache.catalina.startup.HostConfig deployWAR > INFO: Deploying web application archive clusterbench.war > May 28, 2014 12:12:42 PM org.apache.catalina.startup.HostConfig deployDirectory > INFO: Deploying web application directory docs > May 28, 2014 12:12:43 PM org.apache.catalina.startup.HostConfig deployDirectory > INFO: Deploying web application directory examples > May 28, 2014 12:12:43 PM org.apache.catalina.startup.HostConfig deployDirectory > INFO: Deploying web application directory host-manager > May 28, 2014 12:12:43 PM org.apache.catalina.startup.HostConfig deployDirectory > INFO: Deploying web application directory manager > May 28, 2014 12:12:43 PM org.apache.catalina.startup.HostConfig deployDirectory > INFO: Deploying web application directory ROOT > May 28, 2014 12:12:43 PM org.apache.coyote.http11.Http11AprProtocol start > INFO: Starting Coyote HTTP/1.1 on http-192.168.122.24-8080 > May 28, 2014 12:12:44 PM org.apache.coyote.ajp.AjpAprProtocol start > INFO: Starting Coyote AJP/1.3 on ajp-192.168.122.24-8009 > May 28, 2014 12:12:44 PM org.apache.catalina.startup.Catalina start > INFO: Server startup in 2395 ms > May 28, 2014 12:12:54 PM org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren > SEVERE: Exception invoking periodic operation: > java.lang.NoSuchMethodError: org.apache.catalina.Context.isStarted()Z > at org.jboss.modcluster.container.jbossweb.JBossWebContext.isStarted(JBossWebContext.java:60) > at org.jboss.modcluster.mcmp.impl.ResetRequestSourceImpl.getResetRequests(ResetRequestSourceImpl.java:135) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:384) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350) > at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:458) > at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249) > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) > at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1389) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1653) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1642) > at java.lang.Thread.run(Thread.java:745) > May 28, 2014 12:13:04 PM org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler sendRequest > ERROR: MODCLUSTER000042: Error MEM sending STATUS command to WIN-NKI15SIE9RC/192.168.122.24:8847, configuration will be reset: MEM: Can't read node > May 28, 2014 12:13:14 PM org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren > SEVERE: Exception invoking periodic operation: > java.lang.NoSuchMethodError: org.apache.catalina.Context.isStarted()Z > at org.jboss.modcluster.container.jbossweb.JBossWebContext.isStarted(JBossWebContext.java:60) > at org.jboss.modcluster.mcmp.impl.ResetRequestSourceImpl.getResetRequests(ResetRequestSourceImpl.java:135) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:384) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350) > at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:458) > at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249) > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) > at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1389) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1653) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1642) > at java.lang.Thread.run(Thread.java:745) > {code} > with the configuration being: > {code} > <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric" > loadMetricCapacity="1" loadHistory="9" loadDecayFactor="2" stickySession="true" stickySessionForce="false" > stickySessionRemove="true" advertise="true" > advertiseGroupAddress="224.0.7.222" advertisePort="43294" /> > {code} > According to Apache HTTP Server log, the Tomcat is trying to register itself, but it does not offer any contexts: > {code} > [notice] Apache/2.2.26 (Win64) DAV/2 mod_cluster/1.2.8.Final configured -- resuming normal operations > [notice] Server built: May 13 2014 08:51:33 > [notice] Parent: Created child process 2140 > [debug] mpm_winnt.c(477): Parent: Sent the scoreboard to the child > [debug] util_ldap.c(1990): LDAP merging Shared Cache conf: shm=0x6733e0 rmm=0x673438 for VHOST: WIN-NKI15SIE9RC > [info] APR LDAP: Built with Microsoft Corporation. LDAP SDK > [info] LDAP: SSL support unavailable: LDAP: CA certificates cannot be set using this method, as they are stored in the registry instead. > [notice] Digest: generating secret for digest authentication ... > [notice] Digest: done > [debug] mod_advertise.c(589): [2140 - 3024] in child post config hook > [notice] Child 2140: Child process is running > [debug] mpm_winnt.c(398): Child 2140: Retrieved our scoreboard from the parent. > [info] Parent: Duplicating socket 268 and sending it to child process 2140 > [info] Parent: Duplicating socket 260 and sending it to child process 2140 > [debug] mpm_winnt.c(595): Parent: Sent 2 listeners to child 2140 > [debug] mpm_winnt.c(554): Child 2140: retrieved 2 listeners from parent > [debug] proxy_util.c(1825): proxy: grabbed scoreboard slot 0 in child 2140 for worker proxy:reverse > [debug] proxy_util.c(1921): proxy: initialized worker 0 in child 2140 for (*) min=0 max=150 smax=150 > [notice] Child 2140: Acquired the start mutex. > [notice] Child 2140: Starting 150 worker threads. > [notice] Child 2140: Starting thread to listen on port 8847. > [notice] Child 2140: Starting thread to listen on port 2181. > [debug] mod_manager.c(1901): manager_trans INFO (/) > [debug] mod_manager.c(2617): manager_handler INFO (C:/) processing: "" > [debug] mod_manager.c(2666): manager_handler INFO OK > [debug] mod_manager.c(1901): manager_trans INFO (/) > [debug] mod_manager.c(2617): manager_handler INFO (C:/) processing: "" > [debug] mod_manager.c(2666): manager_handler INFO OK > [debug] mod_manager.c(1901): manager_trans STATUS (/) > [debug] mod_manager.c(2617): manager_handler STATUS (C:/) processing: "JVMRoute=tomcat-6-1&Load=100" > [debug] mod_manager.c(1616): Processing STATUS > [warn] manager_handler STATUS error: MEM: Can't read node > [debug] mod_manager.c(1901): manager_trans STATUS (/) > [debug] mod_manager.c(2617): manager_handler STATUS (C:/) processing: "JVMRoute=tomcat-6-2&Load=100" > [debug] mod_manager.c(1616): Processing STATUS > [warn] manager_handler STATUS error: MEM: Can't read node > [debug] mod_manager.c(1901): manager_trans INFO (/) > [debug] mod_manager.c(2617): manager_handler INFO (C:/) processing: "" > [debug] mod_manager.c(2666): manager_handler INFO OK > [debug] mod_manager.c(1901): manager_trans INFO (/) > [debug] mod_manager.c(2617): manager_handler INFO (C:/) processing: "" > [debug] mod_manager.c(2666): manager_handler INFO OK > [debug] mod_manager.c(1901): manager_trans STATUS (/) > [debug] mod_manager.c(2617): manager_handler STATUS (C:/) processing: "JVMRoute=tomcat-6-1&Load=100" > [debug] mod_manager.c(1616): Processing STATUS > [warn] manager_handler STATUS error: MEM: Can't read node > --repeats-- > {code} > I can't hit this on RHEL. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-411) java.lang.NoSuchFieldError: SESSION_COOKIE_NAME, Tomcat7

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-411?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-411: ---------------------------------------------------- Mladen Turk <mturk(a)redhat.com> changed the Status of [bug 1101977|https://bugzilla.redhat.com/show_bug.cgi?id=1101977] from VERIFIED to CLOSED > java.lang.NoSuchFieldError: SESSION_COOKIE_NAME, Tomcat7 > -------------------------------------------------------- > > Key: MODCLUSTER-411 > URL: https://issues.jboss.org/browse/MODCLUSTER-411 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.8.Final > Environment: oracle JDK 1.7, Tomcat 7, Windows, Apache Tomcat Native library 1.1.30 using APR version 1.4.8 > Reporter: Michal Karm > Assignee: Jean-Frederic Clere > Priority: Major > Fix For: 1.2.9.Final > > > mod_cluster in Tomcat 7 on Windows fails to register with Apache HTTP Server: > {code} > May 28, 2014 10:52:03 AM org.apache.catalina.core.AprLifecycleListener init > INFO: Loaded APR based Apache Tomcat Native library 1.1.30 using APR version 1.4.8. > May 28, 2014 10:52:03 AM org.apache.catalina.core.AprLifecycleListener init > INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. > May 28, 2014 10:52:03 AM org.apache.catalina.core.AprLifecycleListener initializeSSL > INFO: OpenSSL successfully initialized (OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008) > May 28, 2014 10:52:04 AM org.apache.coyote.AbstractProtocol init > INFO: Initializing ProtocolHandler ["http-apr-192.168.122.24-8080"] > May 28, 2014 10:52:04 AM org.apache.coyote.AbstractProtocol init > INFO: Initializing ProtocolHandler ["ajp-apr-192.168.122.24-8009"] > May 28, 2014 10:52:04 AM org.apache.catalina.startup.Catalina load > INFO: Initialization processed in 1892 ms > May 28, 2014 10:52:04 AM org.jboss.modcluster.ModClusterService init > INFO: MODCLUSTER000001: Initializing mod_cluster version ${project.version} > May 28, 2014 10:52:04 AM org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl start > INFO: MODCLUSTER000032: Listening to proxy advertisements on /224.0.7.222:43294 > May 28, 2014 10:52:04 AM org.apache.catalina.core.StandardService startInternal > INFO: Starting service Catalina > May 28, 2014 10:52:04 AM org.apache.catalina.core.StandardEngine startInternal > INFO: Starting Servlet Engine: Apache Tomcat/7.0.52 > May 28, 2014 10:52:04 AM org.apache.catalina.startup.HostConfig deployWAR > INFO: Deploying web application archive C:\Program Files\jboss-ews-2.1\share\tomcat7\webapps\clusterbench.war > May 28, 2014 10:52:06 AM org.apache.catalina.startup.HostConfig deployDirectory > INFO: Deploying web application directory C:\Program Files\jboss-ews-2.1\share\tomcat7\webapps\docs > May 28, 2014 10:52:06 AM org.apache.catalina.startup.HostConfig deployDirectory > INFO: Deploying web application directory C:\Program Files\jboss-ews-2.1\share\tomcat7\webapps\examples > May 28, 2014 10:52:06 AM org.apache.catalina.startup.HostConfig deployDirectory > INFO: Deploying web application directory C:\Program Files\jboss-ews-2.1\share\tomcat7\webapps\host-manager > May 28, 2014 10:52:07 AM org.apache.catalina.startup.HostConfig deployDirectory > INFO: Deploying web application directory C:\Program Files\jboss-ews-2.1\share\tomcat7\webapps\manager > May 28, 2014 10:52:07 AM org.apache.catalina.startup.HostConfig deployDirectory > INFO: Deploying web application directory C:\Program Files\jboss-ews-2.1\share\tomcat7\webapps\ROOT > May 28, 2014 10:52:07 AM org.apache.coyote.AbstractProtocol start > INFO: Starting ProtocolHandler ["http-apr-192.168.122.24-8080"] > May 28, 2014 10:52:08 AM org.apache.coyote.AbstractProtocol start > INFO: Starting ProtocolHandler ["ajp-apr-192.168.122.24-8009"] > May 28, 2014 10:52:08 AM org.apache.catalina.startup.Catalina start > INFO: Server startup in 3876 ms > May 28, 2014 10:52:18 AM org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren > SEVERE: Exception invoking periodic operation: > java.lang.NoSuchFieldError: SESSION_COOKIE_NAME > at org.jboss.modcluster.container.jbossweb.JBossWebEngine.getSessionCookieName(JBossWebEngine.java:43) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPRequestFactory.createConfigRequest(DefaultMCMPRequestFactory.java:127) > at org.jboss.modcluster.mcmp.impl.ResetRequestSourceImpl.getResetRequests(ResetRequestSourceImpl.java:89) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:384) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350) > at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:458) > at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249) > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) > at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) > at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519) > at java.lang.Thread.run(Thread.java:745) > May 28, 2014 10:52:28 AM org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren > SEVERE: Exception invoking periodic operation: > java.lang.NoSuchMethodError: org.apache.catalina.connector.Connector.isAvailable()Z > at org.jboss.modcluster.container.jbossweb.JBossWebConnector.isAvailable(JBossWebConnector.java:39) > at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:464) > at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249) > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) > at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) > at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519) > at java.lang.Thread.run(Thread.java:745) > +++ > repeats... > {code} > On the Apache HTTP Server side, it looks very weird, because there is an INFO message from Tomcat 7, but no CONFIG... > {code} > [notice] Apache/2.2.26 (Win64) DAV/2 mod_cluster/1.2.8.Final configured -- resuming normal operations > [notice] Server built: May 13 2014 08:51:33 > [notice] Parent: Created child process 3432 > [debug] mpm_winnt.c(477): Parent: Sent the scoreboard to the child > [debug] util_ldap.c(1990): LDAP merging Shared Cache conf: shm=0x6833e0 rmm=0x683438 for VHOST: WIN-NKI15SIE9RC > [info] APR LDAP: Built with Microsoft Corporation. LDAP SDK > [info] LDAP: SSL support unavailable: LDAP: CA certificates cannot be set using this method, as they are stored in the registry instead. > [notice] Digest: generating secret for digest authentication ... > [notice] Digest: done > [debug] mod_advertise.c(589): [3432 - 3460] in child post config hook > [notice] Child 3432: Child process is running > [debug] mpm_winnt.c(398): Child 3432: Retrieved our scoreboard from the parent. > [info] Parent: Duplicating socket 268 and sending it to child process 3432 > [info] Parent: Duplicating socket 260 and sending it to child process 3432 > [debug] mpm_winnt.c(595): Parent: Sent 2 listeners to child 3432 > [debug] mpm_winnt.c(554): Child 3432: retrieved 2 listeners from parent > [debug] proxy_util.c(1825): proxy: grabbed scoreboard slot 0 in child 3432 for worker proxy:reverse > [debug] proxy_util.c(1921): proxy: initialized worker 0 in child 3432 for (*) min=0 max=150 smax=150 > [notice] Child 3432: Acquired the start mutex. > [notice] Child 3432: Starting 150 worker threads. > [notice] Child 3432: Starting thread to listen on port 2181. > [notice] Child 3432: Starting thread to listen on port 8847. > [debug] mod_manager.c(1901): manager_trans INFO (/) > [debug] mod_manager.c(2617): manager_handler INFO (C:/) processing: "" > [debug] mod_manager.c(2666): manager_handler INFO OK > [debug] mod_manager.c(1901): manager_trans INFO (/) > [debug] mod_manager.c(2617): manager_handler INFO (C:/) processing: "" > [debug] mod_manager.c(2666): manager_handler INFO OK > --end of the log, no more relevant messages-- > {code} > Tomcat 7 configuration: > {code} > <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" > loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric" > loadMetricCapacity="1" > loadHistory="9" > loadDecayFactor="2" > stickySession="true" > stickySessionForce="false" > stickySessionRemove="true" > advertise="true" > advertiseGroupAddress="224.0.7.222" > advertisePort="43294" /> > {code} > Nothing suspicious in the Apache HTTP Server mod_cluster config: > {code} > MemManagerFile "C:\Program Files\jboss-ews-2.1\var\cache\mod_cluster" > ServerName WIN-NKI15SIE9RC:2181 > <IfModule manager_module> > Listen 192.168.122.24:8847 > LogLevel debug > <VirtualHost 192.168.122.24:8847> > ServerName WIN-NKI15SIE9RC:8847 > <Directory /> > Order deny,allow > Deny from all > Allow from all > </Directory> > KeepAliveTimeout 60 > MaxKeepAliveRequests 0 > ServerAdvertise on > AdvertiseFrequency 5 > ManagerBalancerName qacluster > AdvertiseGroup 224.0.7.222:43294 > EnableMCPMReceive > <Location /mcm> > SetHandler mod_cluster-manager > Order deny,allow > Deny from all > Allow from all > </Location> > </VirtualHost> > </IfModule> > {code} > I'm unable to hit it on RHEL. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues June 2019