August 2015 - mod_cluster-issues - Jboss List Archives

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

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-466?page=com.atlassian.jira.pl... ] Aaron Ogburn updated MODCLUSTER-466: ------------------------------------ Git Pull Request: https://github.com/modcluster/mod_cluster/pull/155, https://github.com/modcluster/mod_cluster/pull/156 (was: https://github.com/modcluster/mod_cluster/pull/155) > 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 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > > 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 (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

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

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-466?page=com.atlassian.jira.pl... ] Aaron Ogburn updated MODCLUSTER-466: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/modcluster/mod_cluster/pull/155 > 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 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > > 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 (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

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

by Aaron Ogburn (JIRA)

Aaron Ogburn created MODCLUSTER-466: --------------------------------------- Summary: 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 Reporter: Aaron Ogburn Assignee: Jean-Frederic Clere 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 (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-376?page=com.atlassian.jira.pl... ] RH Bugzilla Integration updated MODCLUSTER-376: ----------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1255538 > 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 > Attachments: 131122.patch > > > 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 was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-430) CreateBalancers behave the same with option 0 or 2

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-430?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-430: ---------------------------------------------------- Michal Karm Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1157769|https://bugzilla.redhat.com/show_bug.cgi?id=1157769] from NEW to CLOSED > CreateBalancers behave the same with option 0 or 2 > -------------------------------------------------- > > Key: MODCLUSTER-430 > URL: https://issues.jboss.org/browse/MODCLUSTER-430 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.0.Final, 1.2.9.Final > Environment: RHEL 6.4.0 > Apache HTTPD 2.4.10 > JBoss 6.1.1 > Mod_cluster 1.3.0 Final > Reporter: John Jerome > Assignee: Michal Karm Babacek > Fix For: 1.2.11.Final, 1.3.2.Alpha1 > > > The directive CreateBalancers with directive 0 or 2 creates the balancers on all httpd vhosts. > With option 2, the balancers should be created on the main server only, not in the vhosts. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-465) CMake: build expat, apr, apru, zlib, iconv, openssl, httpd, jk and mod_cluster

by Michal Karm Babacek (JIRA)

Michal Karm Babacek created MODCLUSTER-465: ---------------------------------------------- Summary: CMake: build expat, apr, apru, zlib, iconv, openssl, httpd, jk and mod_cluster Key: MODCLUSTER-465 URL: https://issues.jboss.org/browse/MODCLUSTER-465 Project: mod_cluster Issue Type: Enhancement Components: Native (httpd modules) Reporter: Michal Karm Babacek Assignee: Michal Karm Babacek This is a long-term pet project dedicated to translating Autotools to CMake. The first two target platforms are Windows and Fedora, x86_64. Various flavours of Solaris, HP-UX, FreeBSD and Mac will follow. I'll use this JIRA for tracking notes and progress. It is noteworthy that the current upstream expat, apr and httpd use CMake to generate MSVC projects, so translating those to generating Linux make files shouldn't be that nightmareish. One Autotools directive at a time... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-434) Enable workers to tell the balancer they are overloaded at a certain threshold

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-434?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-434: -------------------------------------- Component/s: Core & Container Integration (Java) > Enable workers to tell the balancer they are overloaded at a certain threshold > ------------------------------------------------------------------------------ > > Key: MODCLUSTER-434 > URL: https://issues.jboss.org/browse/MODCLUSTER-434 > Project: mod_cluster > Issue Type: Enhancement > Components: Core & Container Integration (Java) > Affects Versions: 1.2.10.Final, 1.3.1.Final > Reporter: Michal Karm Babacek > Assignee: Radoslav Husar > Priority: Minor > > The discussion on [Server load threshold|https://developer.jboss.org/message/907660], initiated by [~leaqui] and [~godiedelrio], revealed that there might be a need for having a way how one could enable workers to trigger failover at a certain load threshold. For instance, one might want to consider nodes in the cluster desperately overloaded at Load 40 and have failover triggered. > Formerly, similar behavior could have been achieved with a custom load metric returning Load 0, thus marking the node as "stand by" one. This is no longer possible though: [MODCLUSTER-279 mod_cluster returns 503s after STATUS|https://github.com/modcluster/mod_cluster/commit/1fbff789481f48409...] > I see some viable ways for adding the described logic into the current code base: > h3. 1. Leveraging Load: -1 Worker in Error or Load: 0 Stand-by worker > We could simply modify [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...] so as it doesn't apply ceiling|floor normalization {{if load == -1}}. The question is what shall happen when we want the node back? Would returning Load > 0 make the balancer to change the node's status from *NOTOK* to *OK* again even after removal period? I think yes, because the node would keep responding to cping/cpong. This way seems legit, IMHO. > > h3. 2. {{STOP-APP}} message > Well, hey, don't we actually have a message for this? :-) What if we allow custom load metric to access mod_cluster subsystem API so as it could send {{STOP-APP}} message with {{Range=NODE}}? One could send {{ENABLE-APP}} as soon as the load settles below the threshold. > h3. 3. An additional _threshold_ attribute > I don't favor this one, but it's still an option. We might add a configuration attribute {{threshold}} to both mod_cluster subsystem and native mod_proxy_cluster code, hence allowing us to set a certain threshold on per-worker basis. Then, in function [internal_find_best_byrequests|https://github.com/modcluster/mod_cluster/b...] we might access this threshold and decide whether the lbfactor is below it. > WDYT? -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-434) Enable workers to tell the balancer they are overloaded at a certain threshold

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-434?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-434: -------------------------------------- Affects Version/s: 1.3.1.Final 1.2.10.Final > Enable workers to tell the balancer they are overloaded at a certain threshold > ------------------------------------------------------------------------------ > > Key: MODCLUSTER-434 > URL: https://issues.jboss.org/browse/MODCLUSTER-434 > Project: mod_cluster > Issue Type: Enhancement > Affects Versions: 1.2.10.Final, 1.3.1.Final > Reporter: Michal Karm Babacek > Assignee: Radoslav Husar > Priority: Minor > > The discussion on [Server load threshold|https://developer.jboss.org/message/907660], initiated by [~leaqui] and [~godiedelrio], revealed that there might be a need for having a way how one could enable workers to trigger failover at a certain load threshold. For instance, one might want to consider nodes in the cluster desperately overloaded at Load 40 and have failover triggered. > Formerly, similar behavior could have been achieved with a custom load metric returning Load 0, thus marking the node as "stand by" one. This is no longer possible though: [MODCLUSTER-279 mod_cluster returns 503s after STATUS|https://github.com/modcluster/mod_cluster/commit/1fbff789481f48409...] > I see some viable ways for adding the described logic into the current code base: > h3. 1. Leveraging Load: -1 Worker in Error or Load: 0 Stand-by worker > We could simply modify [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...] so as it doesn't apply ceiling|floor normalization {{if load == -1}}. The question is what shall happen when we want the node back? Would returning Load > 0 make the balancer to change the node's status from *NOTOK* to *OK* again even after removal period? I think yes, because the node would keep responding to cping/cpong. This way seems legit, IMHO. > > h3. 2. {{STOP-APP}} message > Well, hey, don't we actually have a message for this? :-) What if we allow custom load metric to access mod_cluster subsystem API so as it could send {{STOP-APP}} message with {{Range=NODE}}? One could send {{ENABLE-APP}} as soon as the load settles below the threshold. > h3. 3. An additional _threshold_ attribute > I don't favor this one, but it's still an option. We might add a configuration attribute {{threshold}} to both mod_cluster subsystem and native mod_proxy_cluster code, hence allowing us to set a certain threshold on per-worker basis. Then, in function [internal_find_best_byrequests|https://github.com/modcluster/mod_cluster/b...] we might access this threshold and decide whether the lbfactor is below it. > WDYT? -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-434) Enable workers to tell the balancer they are overloaded at a certain threshold

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-434?page=com.atlassian.jira.pl... ] Radoslav Husar reassigned MODCLUSTER-434: ----------------------------------------- Assignee: Radoslav Husar (was: Michal Karm Babacek) > Enable workers to tell the balancer they are overloaded at a certain threshold > ------------------------------------------------------------------------------ > > Key: MODCLUSTER-434 > URL: https://issues.jboss.org/browse/MODCLUSTER-434 > Project: mod_cluster > Issue Type: Enhancement > Affects Versions: 1.2.10.Final, 1.3.1.Final > Reporter: Michal Karm Babacek > Assignee: Radoslav Husar > Priority: Minor > > The discussion on [Server load threshold|https://developer.jboss.org/message/907660], initiated by [~leaqui] and [~godiedelrio], revealed that there might be a need for having a way how one could enable workers to trigger failover at a certain load threshold. For instance, one might want to consider nodes in the cluster desperately overloaded at Load 40 and have failover triggered. > Formerly, similar behavior could have been achieved with a custom load metric returning Load 0, thus marking the node as "stand by" one. This is no longer possible though: [MODCLUSTER-279 mod_cluster returns 503s after STATUS|https://github.com/modcluster/mod_cluster/commit/1fbff789481f48409...] > I see some viable ways for adding the described logic into the current code base: > h3. 1. Leveraging Load: -1 Worker in Error or Load: 0 Stand-by worker > We could simply modify [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...] so as it doesn't apply ceiling|floor normalization {{if load == -1}}. The question is what shall happen when we want the node back? Would returning Load > 0 make the balancer to change the node's status from *NOTOK* to *OK* again even after removal period? I think yes, because the node would keep responding to cping/cpong. This way seems legit, IMHO. > > h3. 2. {{STOP-APP}} message > Well, hey, don't we actually have a message for this? :-) What if we allow custom load metric to access mod_cluster subsystem API so as it could send {{STOP-APP}} message with {{Range=NODE}}? One could send {{ENABLE-APP}} as soon as the load settles below the threshold. > h3. 3. An additional _threshold_ attribute > I don't favor this one, but it's still an option. We might add a configuration attribute {{threshold}} to both mod_cluster subsystem and native mod_proxy_cluster code, hence allowing us to set a certain threshold on per-worker basis. Then, in function [internal_find_best_byrequests|https://github.com/modcluster/mod_cluster/b...] we might access this threshold and decide whether the lbfactor is below it. > WDYT? -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-401) EnableOptions and SSL configuration

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-401?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-401: ---------------------------------------------------- Nidhi <nchaudha(a)redhat.com> changed the Status of [bug 1093853|https://bugzilla.redhat.com/show_bug.cgi?id=1093853] from NEW to ASSIGNED > EnableOptions and SSL configuration > ----------------------------------- > > Key: MODCLUSTER-401 > URL: https://issues.jboss.org/browse/MODCLUSTER-401 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.8.Final > Environment: HP-UX Apache HTTP Server 2.2.15, RHEL Apache HTTP Server 2.2.22, perhaps platform independent... > Reporter: Michal Karm Babacek > Assignee: Jean-Frederic Clere > Fix For: 1.2.11.Final > > > As a follow up on MODCLUSTER-400 and a documentation effort for *EnableOptions* logic, I tried to add {{EnableOptions}} to the configuration so as to allow for a "cping/cpong" emulation of the famous AJP feature. > With the following {{mod_cluster.conf / httpd.conf}} (standalone-ha.xml being the same as in MODCLUSTER-400's description): > {code} > +++ > Listen 10.16.92.191:2081 > +++ > MemManagerFile "/hell/workspace/hpws22/apache/cache/mod_cluster" > ServerName 10.16.92.191:2081 > <IfModule manager_module> > Listen 10.16.92.191:8745 > LogLevel debug > <VirtualHost 10.16.92.191:8745> > ServerName 10.16.92.191:8745 > <Directory /> > Order deny,allow > Deny from all > Allow from all > </Directory> > KeepAliveTimeout 60 > MaxKeepAliveRequests 0 > ServerAdvertise on > AdvertiseFrequency 5 > ManagerBalancerName qacluster > AdvertiseGroup 224.0.3.47:23364 > EnableOptions > EnableMCPMReceive > SSLEngine on > SSLProtocol all -SSLv2 -SSLv3 > SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS" > SSLHonorCipherOrder on > SSLCertificateFile /vault/server.crt > SSLCertificateKeyFile /vault/server.key > SSLCACertificateFile /vault/myca.crt > SSLProxyEngine On > SSLVerifyDepth 10 > <Location /mcm> > SetHandler mod_cluster-manager > Order deny,allow > Deny from all > Allow from all > </Location> > </VirtualHost> > </IfModule> > {code} > one gets this [^hp-ux_error_log-EnableOptions.zip] log: > {code} > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received HTTP/1.1 200 OK > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Server: Apache-Coyote/1.1 > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Content-Length: 0 > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Date: Fri, 02 May 2014 17:22:46 GMT > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Connection: close > [debug] mod_proxy_cluster.c(1239): http_cping_cpong: Done > [debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191) > [debug] mod_manager.c(2666): manager_handler STATUS OK > [debug] proxy_util.c(2029): proxy: https: has acquired connection for (10.16.92.191) > [debug] proxy_util.c(2085): proxy: connecting https://10.16.92.191:8645/ to 10.16.92.191:8645 > [debug] proxy_util.c(2211): proxy: connected / to 10.16.92.191:8645 > [debug] proxy_util.c(2462): proxy: https: fam 2 socket created to connect to 10.16.92.191 > [debug] mod_proxy_cluster.c(1384): proxy_cluster_try_pingpong: connected to backend > [error] [client 10.16.92.191] SSL Proxy requested for 10.16.92.191:2081 but not enabled [Hint: SSLProxyEngine] > [error] proxy: https: failed to enable ssl support for 10.16.92.191:8645 (10.16.92.191) > [debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191) > {code} > Why is the JBoss EAP residing on {{10.16.92.191:8645}} trying to request SSL Proxy on the virtual host {{10.16.92.191:2081}}? The result is {{Status: NOTOK}} on mod_cluser manager console. > I tried to remove that {{10.16.92.191:2081}}, so as the {{10.16.92.191:8745}} is the only one ([^hp-ux_error_log-EnableOptions-single-vhost.zip]): > {code} > - Listen 10.16.92.191:2081 > - ServerName 10.16.92.191:2081 > {code} > The result is a funny trial to request a proxy for the boxe's actual hostname and port 80 *no one* (netstat) is even listening on: > {code} > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received HTTP/1.1 200 OK > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Server: Apache-Coyote/1.1 > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Content-Length: 0 > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Date: Fri, 02 May 2014 17:39:33 GMT > [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Connection: close > [debug] mod_proxy_cluster.c(1239): http_cping_cpong: Done > [debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191) > [debug] mod_manager.c(2666): manager_handler STATUS OK > [debug] proxy_util.c(2029): proxy: https: has acquired connection for (10.16.92.191) > [debug] proxy_util.c(2085): proxy: connecting https://10.16.92.191:8645/ to 10.16.92.191:8645 > [debug] proxy_util.c(2211): proxy: connected / to 10.16.92.191:8645 > [debug] proxy_util.c(2462): proxy: https: fam 2 socket created to connect to 10.16.92.191 > [debug] mod_proxy_cluster.c(1384): proxy_cluster_try_pingpong: connected to backend > [error] [client 10.16.92.191] SSL Proxy requested for eap-perf-hpux-03.mw.lab.eng.bos.redhat.com:80 but not enabled [Hint: SSLProxyEngine] > [error] proxy: https: failed to enable ssl support for 10.16.92.191:8645 (10.16.92.191) > [debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191) > {code} > I tried to add: {{RequestHeader set Front-End-Https "On"}} to the configuration without any luck. > Finally, I replicated the SSL configuration *outside* the VirtualHost: > {code} > MemManagerFile "/hell/workspace/hpws22/apache/cache/mod_cluster" > Listen 10.16.92.191:2081 > ServerName 10.16.92.191:2081 > SSLEngine on > SSLProtocol all -SSLv2 -SSLv3 > SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !S RP !DSS" > SSLHonorCipherOrder on > SSLCertificateFile /vault/server.crt > SSLCertificateKeyFile /vault/server.key > SSLCACertificateFile /vault/myca.crt > SSLProxyEngine On > SSLVerifyDepth 10 > <IfModule manager_module> > +++ the same as above +++ > </IfModule> > {code} > This configuration fixed the aforementioned {{failed to enable ssl support}} *and* actually helped to workaround the MODCLUSTER-400: (log: [^hp-ux_error_log-EnableOptions-SSL_everywhere.zip]) > {code} > Fri, May 2, 2014 02:23:44 PM Request URI: /clusterbench/requestinfo > Headers: {host=10.16.92.191:8645, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive} > Host header: 10.16.92.191:8645 > Character encoding: null > JVM route: jboss-eap-6.3-2 > Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2 > Session isNew: false > Fri, May 2, 2014 02:23:47 PM Request URI: /clusterbench/requestinfo > Headers: {host=10.16.92.191:8645, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive} > Host header: 10.16.92.191:8645 > Character encoding: null > JVM route: jboss-eap-6.3-2 > Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2 > Session isNew: false > -- stop jboss-eap-6.3-2 -- (the same behavior with jvm kill) -- > Fri, May 2, 2014 02:23:50 PM Request URI: /clusterbench/requestinfo > Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive} > Host header: 10.16.92.191:8544 > Character encoding: null > JVM route: jboss-eap-6.3 > Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3 > Session isNew: false > Fri, May 2, 2014 02:23:53 PM Request URI: /clusterbench/requestinfo > Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive} > Host header: 10.16.92.191:8544 > Character encoding: null > JVM route: jboss-eap-6.3 > Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3 > Session isNew: false > Fri, May 2, 2014 02:23:56 PM Request URI: /clusterbench/requestinfo > Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive} > Host header: 10.16.92.191:8544 > Character encoding: null > JVM route: jboss-eap-6.3 > Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3 > Session isNew: false > {code} > Why isn't the {{10.16.92.191:8745}} enough? Is it a configuration error or a ProxyPass/SSL integration bug? -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 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 2015