[JBoss JIRA] (MODCLUSTER-469) Tomcat8 standalone : jvmRoute not added to jessionid cookie when generated as UUID by JvmRouteFactory
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-469?page=com.atlassian.jira.pl... ]
Jean-Frederic Clere reassigned MODCLUSTER-469:
----------------------------------------------
Assignee: Radoslav Husar (was: Jean-Frederic Clere)
> Tomcat8 standalone : jvmRoute not added to jessionid cookie when generated as UUID by JvmRouteFactory
> -----------------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-469
> URL: https://issues.jboss.org/browse/MODCLUSTER-469
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 1.3.1.Final
> Environment: Apache 2.4, ModCluster 1.3.1, Tomcat 8.0 standalone
> Reporter: Eric Vernier
> Assignee: Radoslav Husar
>
> If jvmRoute attribute is not set in server.xml on engine element, ModClusterService generates a jvmRoute (UUID).
> This UUID is not added in the value of the cookie "jsessionid", so the sticky session doesn't work.
> When the jvmRoute is defined in the server.xml all works fine.
> I known no much about lifecyle in Catalina, but my feeling is that ModClusterService generates the jvmRoute (with JvmRouteFactory)
> after the creation of SessionIdGenerator by the org.apache.catalina.Manager. When ModClusterService injects the generated jvmRoute it's too late,
> the SessionIdGenerator is already created.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (MODCLUSTER-469) Tomcat8 standalone : jvmRoute not added to jessionid cookie when generated as UUID by JvmRouteFactory
by Eric Vernier (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-469?page=com.atlassian.jira.pl... ]
Eric Vernier updated MODCLUSTER-469:
------------------------------------
Git Pull Request: https://github.com/modcluster/mod_cluster/pull/160
> Tomcat8 standalone : jvmRoute not added to jessionid cookie when generated as UUID by JvmRouteFactory
> -----------------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-469
> URL: https://issues.jboss.org/browse/MODCLUSTER-469
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 1.3.1.Final
> Environment: Apache 2.4, ModCluster 1.3.1, Tomcat 8.0 standalone
> Reporter: Eric Vernier
> Assignee: Jean-Frederic Clere
>
> If jvmRoute attribute is not set in server.xml on engine element, ModClusterService generates a jvmRoute (UUID).
> This UUID is not added in the value of the cookie "jsessionid", so the sticky session doesn't work.
> When the jvmRoute is defined in the server.xml all works fine.
> I known no much about lifecyle in Catalina, but my feeling is that ModClusterService generates the jvmRoute (with JvmRouteFactory)
> after the creation of SessionIdGenerator by the org.apache.catalina.Manager. When ModClusterService injects the generated jvmRoute it's too late,
> the SessionIdGenerator is already created.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (MODCLUSTER-469) Tomcat8 standalone : jvmRoute not added to jessionid cookie when generated as UUID by JvmRouteFactory
by Eric Vernier (JIRA)
Eric Vernier created MODCLUSTER-469:
---------------------------------------
Summary: Tomcat8 standalone : jvmRoute not added to jessionid cookie when generated as UUID by JvmRouteFactory
Key: MODCLUSTER-469
URL: https://issues.jboss.org/browse/MODCLUSTER-469
Project: mod_cluster
Issue Type: Bug
Components: Core & Container Integration (Java)
Affects Versions: 1.3.1.Final
Environment: Apache 2.4, ModCluster 1.3.1, Tomcat 8.0 standalone
Reporter: Eric Vernier
Assignee: Jean-Frederic Clere
If jvmRoute attribute is not set in server.xml on engine element, ModClusterService generates a jvmRoute (UUID).
This UUID is not added in the value of the cookie "jsessionid", so the sticky session doesn't work.
When the jvmRoute is defined in the server.xml all works fine.
I known no much about lifecyle in Catalina, but my feeling is that ModClusterService generates the jvmRoute (with JvmRouteFactory)
after the creation of SessionIdGenerator by the org.apache.catalina.Manager. When ModClusterService injects the generated jvmRoute it's too late,
the SessionIdGenerator is already created.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (MODCLUSTER-401) EnableOptions and SSL configuration
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-401?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-401:
--------------------------------------
Fix Version/s: 1.2.12.Final
(was: 1.2.11.Final)
> 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.12.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.4.11#64026)
9 years, 2 months
[JBoss JIRA] (MODCLUSTER-391) mod_cluster and mod_proxy integration
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-391?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-391:
--------------------------------------
Fix Version/s: 1.2.12.Final
(was: 1.2.11.Final)
> mod_cluster and mod_proxy integration
> -------------------------------------
>
> Key: MODCLUSTER-391
> URL: https://issues.jboss.org/browse/MODCLUSTER-391
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.6.Final
> Environment: All platforms we build mod_cluster for.
> Reporter: Michal Karm Babacek
> Assignee: Jean-Frederic Clere
> Labels: native_libraries
> Fix For: 1.3.2.Alpha1, 1.2.12.Final
>
> Attachments: error_log, mod_cluster.conf, mod_proxy.conf, standalone-ha.xml
>
>
> This Jira encapsulates all concerns regarding mod_cluster - mod_proxy integration. For instance, while basic {{ProxyPass}} settings work just fine, e.g. serving some files on {{/static}} from the Apache HTTP itself:
> {code}
> ProxyPassMatch ^/static/ !
> ProxyPass / balancer://qacluster stickysession=JSESSIONID|jsessionid nofailover=on
> ProxyPassReverse / balancer://qacluster
> ProxyPreserveHost on
> {code}
> there are more complex setups, involving {{BalancerMember}} configurations, that do not work as expected. In the following example, one wanted to have {{/clusterbench}} application managed by mod_cluster, dynamically, while at the same time, in a different VirtualHost, having {{/tses}} application handled by manually created mod_proxy balancer settings.
> Attached [^mod_cluster.conf], [^mod_proxy.conf], [^standalone-ha.xml](modcluster subsystem element only) and [^error_log].
> The aforementioned setup resulted in:
> |HTTP 200|(From worker)|http://10.16.88.19:8847/clusterbench/requestinfo/|OK|(/)|
> |HTTP 404|(From httpd)|http://10.16.88.19:8847/tses/session.jsp|Expected fail|(/)|
> |HTTP 503|(From httpd)|http://10.16.88.19:2182/tses/session.jsp|Unexpected fail|(x)|
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (MODCLUSTER-168) mod_cluster should use hostname provided in address instead a IP address
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-168?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-168:
--------------------------------------
Fix Version/s: 1.2.12.Final
(was: 1.2.11.Final)
> mod_cluster should use hostname provided in address instead a IP address
> ------------------------------------------------------------------------
>
> Key: MODCLUSTER-168
> URL: https://issues.jboss.org/browse/MODCLUSTER-168
> Project: mod_cluster
> Issue Type: Feature Request
> Affects Versions: 1.1.0.CR3
> Environment: any
> Reporter: Jean-Frederic Clere
> Assignee: Radoslav Husar
> Fix For: 1.3.2.Alpha1, 1.2.12.Final
>
>
> The CONFIG message contains something like:
> JVMRoute=51ec121e-2976-3d75-bfd9-9e662bbb4bcd&Host=10.33.144.3&Port=8009&Type=ajp
> Even if the Connector is defined like:
> <Connector port="8009" address= "jfcpc" protocol="AJP/1.3" redirectPort="8443" />
> There are 2 ways to fix:
> - Use the String (Change the Connector.java in mod_cluster).
> - Use parameters.put("Host", connector.getAddress().getHostName()); when building the CONFIG message.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (MODCLUSTER-430) CreateBalancers behave the same with option 0 or 2
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-430?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-430:
--------------------------------------
Fix Version/s: 1.2.12.Final
(was: 1.2.11.Final)
> 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.3.2.Alpha1, 1.2.12.Final
>
>
> 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.4.11#64026)
9 years, 2 months