[JBoss JIRA] (MODCLUSTER-403) UseAlias should use flag, interprets both On/Off/on/off as 0
by Radoslav Husar (JIRA)
Radoslav Husar created MODCLUSTER-403:
-----------------------------------------
Summary: UseAlias should use flag, interprets both On/Off/on/off as 0
Key: MODCLUSTER-403
URL: https://issues.jboss.org/browse/MODCLUSTER-403
Project: mod_cluster
Issue Type: Bug
Affects Versions: 1.2.8.Final, 1.3.0.Final
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Fix For: 1.3.1.Final
Not very pretty. The function is using atoi which is not doing any error handling.
That means, if its integer, it will be checked fine, but if its any string it is always going to be translated as 0!
It should use AP_FLAG so its all done by httpd automatically.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (MODCLUSTER-402) Balancer shutdown, AS:OutOfMemoryError: unable to create new native thread
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-402?page=com.atlassian.jira.pl... ]
Radoslav Husar commented on MODCLUSTER-402:
-------------------------------------------
Looking at the description, are there no sessions being created?
> Balancer shutdown, AS:OutOfMemoryError: unable to create new native thread
> --------------------------------------------------------------------------
>
> Key: MODCLUSTER-402
> URL: https://issues.jboss.org/browse/MODCLUSTER-402
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.8.Final
> Environment: HP-UX ia64, HP JDK 1.7
> Reporter: Michal Babacek
> Assignee: Michal Babacek
> Priority: Critical
> Fix For: 1.2.9.Final
>
> Attachments: OOM-server.logs.zip
>
>
> # start Apache HTTP Server with mod_cluster
> # start EAP 6.3 worker 1, jvmroute: jboss-eap-6.3
> # start EAP 6.3 worker 2, jvmroute: jboss-eap-6.3-2
> # stop 1.
> # let 2. and 3. trying to contact the balancer
> # OOM
> See two detailed logs for both machines: [^OOM-server.logs.zip].
> At the moment, I'm not sure it was really mod_cluster's fault, due to the JGroups messages. I have a hunch it might be linked to the new JBossWeb NIO...
> Assigning to myself for investigation.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (MODCLUSTER-400) Failover with SSL breaks sticky sessions on HP-UX v11.3, hpws22
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-400?page=com.atlassian.jira.pl... ]
Michal Babacek commented on MODCLUSTER-400:
-------------------------------------------
{quote}
With the following configuration on a single box:
{quote}
Yes, load balancer and two cluster nodes are all on HP-UX, HP JDK 1.7. Actually, they are on a *single* box, sharing the same NIC, only ports being shifted.
Regarding clustering, I smell something fishy with MODCLUSTER-402 as well...
> Failover with SSL breaks sticky sessions on HP-UX v11.3, hpws22
> ---------------------------------------------------------------
>
> Key: MODCLUSTER-400
> URL: https://issues.jboss.org/browse/MODCLUSTER-400
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.8.Final
> Environment: HP-UX v11.3, hpuxws22Apache B.2.2.15.15 HP-UX Apache-based Web Server, libaprutil-1.sl.3.9, libapr-1.sl.4.2
> Reporter: Michal Babacek
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Fix For: 1.2.9.Final
>
> Attachments: hp-ux_error_log-ajp-failover.zip, hp-ux_error_log-ssl-failover.zip, rhel_error_log-ssl-failover.zip
>
>
> Failover with SSL breaks sticky sessions on HP-UX v11.3, hpws22
> With the following configuration on a single box:
> {panel:title=mod_cluster.conf| borderStyle=dashed}
> {code}
> 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
> 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/certs/server.crt
> SSLCertificateKeyFile /vault/certs/server.key
> SSLCACertificateFile /vault/certs/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}
> {panel}
> {panel:title=standalone-ha.xml| borderStyle=dashed}
> {code}
> +++
> <subsystem xmlns="urn:jboss:domain:web:2.1" native="false">
> <connector name="https" protocol="HTTP/1.1" socket-binding="https" scheme="https" enabled="true" secure="true">
> <ssl name="https" ca-certificate-file="/vault/certs/ca-cert.jks" certificate-key-file="/vault/certs/client-cert-key.jks" certificate-file="/vault/certs/client-cert-key.jks" password="tomcat" verify-client="false" key-alias="javaclient"
> cipher-suite="SSL_RSA_WITH_DES_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_RSA_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_NULL_MD5,SSL_DHE_RSA_WITH_DES_CBC_SHA,SSL_DH_anon_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_WITH_3DES_EDE_CBC_SHA,SSL_DH_anon_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_MD5,SSL_DHE_DSS_WITH_DES_CBC_SHA,SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA,SSL_DH_anon_WITH_DES_CBC_SHA,SSL_RSA_WITH_NULL_SHA,SSL_RSA_EXPORT_WITH_DES40_CBC_SHA" protocol="TLS"/>
> </connector>
> <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/>
> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> +++
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config connector="https" advertise-socket="modcluster">
> <dynamic-load-provider>
> <load-metric type="busyness"/>
> </dynamic-load-provider>
> <ssl ca-certificate-file="/vault/certs/ca-cert.jks" certificate-key-file="/vault/certs/client-cert-key.jks" password="tomcat" key-alias="javaclient"
> cipher-suite="SSL_RSA_WITH_DES_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_RSA_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_NULL_MD5,SSL_DHE_RSA_WITH_DES_CBC_SHA,SSL_DH_anon_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_WITH_3DES_EDE_CBC_SHA,SSL_DH_anon_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_MD5,SSL_DHE_DSS_WITH_DES_CBC_SHA,SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA,SSL_DH_anon_WITH_DES_CBC_SHA,SSL_RSA_WITH_NULL_SHA,SSL_RSA_EXPORT_WITH_DES40_CBC_SHA" protocol="TLS"/>
> </mod-cluster-config>
> </subsystem>
> +++
> {code}
> {panel}
> One gets the following weird session loss. This log [^hp-ux_error_log-ssl-failover.zip] covers the undermentioned test servlet output:
> {code}
> echo -e "`date` `curl https://10.16.92.191:8745/clusterbench/requestinfo --cert /vault/certs/client.crt --key /vault/certs/client.key --cacert /vault/certs/myca.crt --insecure -c cookiefile.txt -b cookiefile.txt 2> /dev/null`";
> {code}
> {code}
> Wed, Apr 30, 2014 11:50:11 AM Request URI: /clusterbench/requestinfo
> Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=vjZSMs4fZ8j0h+VIQ-GLAz+F.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
> JVM route: jboss-eap-6.3
> Session ID: vjZSMs4fZ8j0h+VIQ-GLAz+F.jboss-eap-6.3
> Session isNew: false
> Wed, Apr 30, 2014 11:50:13 AM Request URI: /clusterbench/requestinfo
> Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=vjZSMs4fZ8j0h+VIQ-GLAz+F.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
> JVM route: jboss-eap-6.3
> Session ID: vjZSMs4fZ8j0h+VIQ-GLAz+F.jboss-eap-6.3
> Session isNew: false
> -- stop jboss-eap-6.3 -- (the same behavior with jvm kill) --
> Wed, Apr 30, 2014 11:50:18 AM Request URI: /clusterbench/requestinfo
> Headers: {host=10.16.92.191:8645, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=vjZSMs4fZ8j0h+VIQ-GLAz+F.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:8645
> JVM route: jboss-eap-6.3-2
> Session ID: tYnoHJhX73UYrr3QCaUikR9h.jboss-eap-6.3-2
> Session isNew: true
> Wed, Apr 30, 2014 11:50:20 AM Request URI: /clusterbench/requestinfo
> Headers: {host=10.16.92.191:8645, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=tYnoHJhX73UYrr3QCaUikR9h.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
> JVM route: jboss-eap-6.3-2
> Session ID: tYnoHJhX73UYrr3QCaUikR9h.jboss-eap-6.3-2
> Session isNew: false
> {code}
> One could note that in the moment of fail-over from worker {{jboss-eap-6.3}} to worker {{jboss-eap-6.3-2}}, the original session {{vjZSMs4fZ8j0h+VIQ-GLAz+F}} had been lost and a new one, {{tYnoHJhX73UYrr3QCaUikR9h}} was created.
> If we comment out all the SSL settings and switch to the AJP connector, the failover seems all right though (see the [^hp-ux_error_log-ajp-failover.zip]):
> {code}
> Wed, Apr 30, 2014 12:04:11 PM Request URI: /clusterbench/requestinfo
> Headers: {user-agent=curl/7.30.0, host=10.16.92.191:8745, accept=*/*, cookie=JSESSIONID=v-hPRQD5FsZUAqZa3ZxRBXIF.jboss-eap-6.3}
> Host header: 10.16.92.191:8745
> JVM route: jboss-eap-6.3
> Session ID: v-hPRQD5FsZUAqZa3ZxRBXIF.jboss-eap-6.3
> Session isNew: false
> -- stop jboss-eap-6.3 -- (the same behavior with jvm kill) --
> Wed, Apr 30, 2014 12:04:14 PM Request URI: /clusterbench/requestinfo
> Headers: {user-agent=curl/7.30.0, host=10.16.92.191:8745, accept=*/*, cookie=JSESSIONID=v-hPRQD5FsZUAqZa3ZxRBXIF.jboss-eap-6.3}
> Host header: 10.16.92.191:8745
> JVM route: jboss-eap-6.3-2
> Session ID: v-hPRQD5FsZUAqZa3ZxRBXIF.jboss-eap-6.3-2
> Session isNew: false
> {code}
> Note that the session {{hPRQD5FsZUAqZa3ZxRBXIF}} remained the same during the failover, only a new jvmRoute were appended.
> The most bewildering thing is that this behavior is specific to {{hpuxws22Apache B.2.2.15.15 HP-UX Apache-based Web Server}},
> i.e., I've carefully followed the same scenario with the same config on RHEL 6 x86_64, Apache/2.2.22 and the session is kept both with AJP and HTTPS connectors (see [^rhel_error_log-ssl-failover.zip]).
> {code}
> Fri May 2 09:47:13 EDT 2014 Request URI: /clusterbench/requestinfo
> Headers: {host=192.168.122.204:8443, user-agent=curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.3.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2, accept=*/*, cookie=JSESSIONID=wdeSdhbahzVweKc5F9mUprJr.jboss-eap-6.3, x-forwarded-for=192.168.122.204, x-forwarded-host=192.168.122.204:8847, x-forwarded-server=192.168.122.204, connection=Keep-Alive}
> Host header: 192.168.122.204:8443
> JVM route: jboss-eap-6.3
> Session ID: wdeSdhbahzVweKc5F9mUprJr.jboss-eap-6.3
> Session isNew: false
> -- stop jboss-eap-6.3 -- (the same behavior with jvm kill) --
> Fri May 2 09:47:16 EDT 2014 Request URI: /clusterbench/requestinfo
> Headers: {host=192.168.122.204:8544, user-agent=curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.3.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2, accept=*/*, cookie=JSESSIONID=wdeSdhbahzVweKc5F9mUprJr.jboss-eap-6.3, x-forwarded-for=192.168.122.204, x-forwarded-host=192.168.122.204:8847, x-forwarded-server=192.168.122.204, connection=Keep-Alive}
> Host header: 192.168.122.204:8544
> JVM route: jboss-eap-6.3-2
> Session ID: wdeSdhbahzVweKc5F9mUprJr.jboss-eap-6.3-2
> Session isNew: false
> {code}
> To date, I don't have any more info to share.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (MODCLUSTER-400) Failover with SSL breaks sticky sessions on HP-UX v11.3, hpws22
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-400?page=com.atlassian.jira.pl... ]
Jean-Frederic Clere commented on MODCLUSTER-400:
------------------------------------------------
that looks like a clustering issue. Are the nodes also on HPUX?
> Failover with SSL breaks sticky sessions on HP-UX v11.3, hpws22
> ---------------------------------------------------------------
>
> Key: MODCLUSTER-400
> URL: https://issues.jboss.org/browse/MODCLUSTER-400
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.8.Final
> Environment: HP-UX v11.3, hpuxws22Apache B.2.2.15.15 HP-UX Apache-based Web Server, libaprutil-1.sl.3.9, libapr-1.sl.4.2
> Reporter: Michal Babacek
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Fix For: 1.2.9.Final
>
> Attachments: hp-ux_error_log-ajp-failover.zip, hp-ux_error_log-ssl-failover.zip, rhel_error_log-ssl-failover.zip
>
>
> Failover with SSL breaks sticky sessions on HP-UX v11.3, hpws22
> With the following configuration on a single box:
> {panel:title=mod_cluster.conf| borderStyle=dashed}
> {code}
> 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
> 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/certs/server.crt
> SSLCertificateKeyFile /vault/certs/server.key
> SSLCACertificateFile /vault/certs/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}
> {panel}
> {panel:title=standalone-ha.xml| borderStyle=dashed}
> {code}
> +++
> <subsystem xmlns="urn:jboss:domain:web:2.1" native="false">
> <connector name="https" protocol="HTTP/1.1" socket-binding="https" scheme="https" enabled="true" secure="true">
> <ssl name="https" ca-certificate-file="/vault/certs/ca-cert.jks" certificate-key-file="/vault/certs/client-cert-key.jks" certificate-file="/vault/certs/client-cert-key.jks" password="tomcat" verify-client="false" key-alias="javaclient"
> cipher-suite="SSL_RSA_WITH_DES_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_RSA_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_NULL_MD5,SSL_DHE_RSA_WITH_DES_CBC_SHA,SSL_DH_anon_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_WITH_3DES_EDE_CBC_SHA,SSL_DH_anon_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_MD5,SSL_DHE_DSS_WITH_DES_CBC_SHA,SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA,SSL_DH_anon_WITH_DES_CBC_SHA,SSL_RSA_WITH_NULL_SHA,SSL_RSA_EXPORT_WITH_DES40_CBC_SHA" protocol="TLS"/>
> </connector>
> <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/>
> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> +++
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config connector="https" advertise-socket="modcluster">
> <dynamic-load-provider>
> <load-metric type="busyness"/>
> </dynamic-load-provider>
> <ssl ca-certificate-file="/vault/certs/ca-cert.jks" certificate-key-file="/vault/certs/client-cert-key.jks" password="tomcat" key-alias="javaclient"
> cipher-suite="SSL_RSA_WITH_DES_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_RSA_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_NULL_MD5,SSL_DHE_RSA_WITH_DES_CBC_SHA,SSL_DH_anon_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_WITH_3DES_EDE_CBC_SHA,SSL_DH_anon_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_MD5,SSL_DHE_DSS_WITH_DES_CBC_SHA,SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA,SSL_DH_anon_WITH_DES_CBC_SHA,SSL_RSA_WITH_NULL_SHA,SSL_RSA_EXPORT_WITH_DES40_CBC_SHA" protocol="TLS"/>
> </mod-cluster-config>
> </subsystem>
> +++
> {code}
> {panel}
> One gets the following weird session loss. This log [^hp-ux_error_log-ssl-failover.zip] covers the undermentioned test servlet output:
> {code}
> echo -e "`date` `curl https://10.16.92.191:8745/clusterbench/requestinfo --cert /vault/certs/client.crt --key /vault/certs/client.key --cacert /vault/certs/myca.crt --insecure -c cookiefile.txt -b cookiefile.txt 2> /dev/null`";
> {code}
> {code}
> Wed, Apr 30, 2014 11:50:11 AM Request URI: /clusterbench/requestinfo
> Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=vjZSMs4fZ8j0h+VIQ-GLAz+F.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
> JVM route: jboss-eap-6.3
> Session ID: vjZSMs4fZ8j0h+VIQ-GLAz+F.jboss-eap-6.3
> Session isNew: false
> Wed, Apr 30, 2014 11:50:13 AM Request URI: /clusterbench/requestinfo
> Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=vjZSMs4fZ8j0h+VIQ-GLAz+F.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
> JVM route: jboss-eap-6.3
> Session ID: vjZSMs4fZ8j0h+VIQ-GLAz+F.jboss-eap-6.3
> Session isNew: false
> -- stop jboss-eap-6.3 -- (the same behavior with jvm kill) --
> Wed, Apr 30, 2014 11:50:18 AM Request URI: /clusterbench/requestinfo
> Headers: {host=10.16.92.191:8645, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=vjZSMs4fZ8j0h+VIQ-GLAz+F.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:8645
> JVM route: jboss-eap-6.3-2
> Session ID: tYnoHJhX73UYrr3QCaUikR9h.jboss-eap-6.3-2
> Session isNew: true
> Wed, Apr 30, 2014 11:50:20 AM Request URI: /clusterbench/requestinfo
> Headers: {host=10.16.92.191:8645, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=tYnoHJhX73UYrr3QCaUikR9h.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
> JVM route: jboss-eap-6.3-2
> Session ID: tYnoHJhX73UYrr3QCaUikR9h.jboss-eap-6.3-2
> Session isNew: false
> {code}
> One could note that in the moment of fail-over from worker {{jboss-eap-6.3}} to worker {{jboss-eap-6.3-2}}, the original session {{vjZSMs4fZ8j0h+VIQ-GLAz+F}} had been lost and a new one, {{tYnoHJhX73UYrr3QCaUikR9h}} was created.
> If we comment out all the SSL settings and switch to the AJP connector, the failover seems all right though (see the [^hp-ux_error_log-ajp-failover.zip]):
> {code}
> Wed, Apr 30, 2014 12:04:11 PM Request URI: /clusterbench/requestinfo
> Headers: {user-agent=curl/7.30.0, host=10.16.92.191:8745, accept=*/*, cookie=JSESSIONID=v-hPRQD5FsZUAqZa3ZxRBXIF.jboss-eap-6.3}
> Host header: 10.16.92.191:8745
> JVM route: jboss-eap-6.3
> Session ID: v-hPRQD5FsZUAqZa3ZxRBXIF.jboss-eap-6.3
> Session isNew: false
> -- stop jboss-eap-6.3 -- (the same behavior with jvm kill) --
> Wed, Apr 30, 2014 12:04:14 PM Request URI: /clusterbench/requestinfo
> Headers: {user-agent=curl/7.30.0, host=10.16.92.191:8745, accept=*/*, cookie=JSESSIONID=v-hPRQD5FsZUAqZa3ZxRBXIF.jboss-eap-6.3}
> Host header: 10.16.92.191:8745
> JVM route: jboss-eap-6.3-2
> Session ID: v-hPRQD5FsZUAqZa3ZxRBXIF.jboss-eap-6.3-2
> Session isNew: false
> {code}
> Note that the session {{hPRQD5FsZUAqZa3ZxRBXIF}} remained the same during the failover, only a new jvmRoute were appended.
> The most bewildering thing is that this behavior is specific to {{hpuxws22Apache B.2.2.15.15 HP-UX Apache-based Web Server}},
> i.e., I've carefully followed the same scenario with the same config on RHEL 6 x86_64, Apache/2.2.22 and the session is kept both with AJP and HTTPS connectors (see [^rhel_error_log-ssl-failover.zip]).
> {code}
> Fri May 2 09:47:13 EDT 2014 Request URI: /clusterbench/requestinfo
> Headers: {host=192.168.122.204:8443, user-agent=curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.3.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2, accept=*/*, cookie=JSESSIONID=wdeSdhbahzVweKc5F9mUprJr.jboss-eap-6.3, x-forwarded-for=192.168.122.204, x-forwarded-host=192.168.122.204:8847, x-forwarded-server=192.168.122.204, connection=Keep-Alive}
> Host header: 192.168.122.204:8443
> JVM route: jboss-eap-6.3
> Session ID: wdeSdhbahzVweKc5F9mUprJr.jboss-eap-6.3
> Session isNew: false
> -- stop jboss-eap-6.3 -- (the same behavior with jvm kill) --
> Fri May 2 09:47:16 EDT 2014 Request URI: /clusterbench/requestinfo
> Headers: {host=192.168.122.204:8544, user-agent=curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.3.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2, accept=*/*, cookie=JSESSIONID=wdeSdhbahzVweKc5F9mUprJr.jboss-eap-6.3, x-forwarded-for=192.168.122.204, x-forwarded-host=192.168.122.204:8847, x-forwarded-server=192.168.122.204, connection=Keep-Alive}
> Host header: 192.168.122.204:8544
> JVM route: jboss-eap-6.3-2
> Session ID: wdeSdhbahzVweKc5F9mUprJr.jboss-eap-6.3-2
> Session isNew: false
> {code}
> To date, I don't have any more info to share.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (MODCLUSTER-402) Balancer shutdown, AS:OutOfMemoryError: unable to create new native thread
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-402?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration updated MODCLUSTER-402:
-----------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1094159
> Balancer shutdown, AS:OutOfMemoryError: unable to create new native thread
> --------------------------------------------------------------------------
>
> Key: MODCLUSTER-402
> URL: https://issues.jboss.org/browse/MODCLUSTER-402
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.8.Final
> Environment: HP-UX ia64, HP JDK 1.7
> Reporter: Michal Babacek
> Assignee: Michal Babacek
> Priority: Critical
> Fix For: 1.2.9.Final
>
> Attachments: OOM-server.logs.zip
>
>
> # start Apache HTTP Server with mod_cluster
> # start EAP 6.3 worker 1, jvmroute: jboss-eap-6.3
> # start EAP 6.3 worker 2, jvmroute: jboss-eap-6.3-2
> # stop 1.
> # let 2. and 3. trying to contact the balancer
> # OOM
> See two detailed logs for both machines: [^OOM-server.logs.zip].
> At the moment, I'm not sure it was really mod_cluster's fault, due to the JGroups messages. I have a hunch it might be linked to the new JBossWeb NIO...
> Assigning to myself for investigation.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (MODCLUSTER-402) Balancer shutdown, AS:OutOfMemoryError: unable to create new native thread
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-402?page=com.atlassian.jira.pl... ]
Michal Babacek updated MODCLUSTER-402:
--------------------------------------
Description:
# start Apache HTTP Server with mod_cluster
# start EAP 6.3 worker 1, jvmroute: jboss-eap-6.3
# start EAP 6.3 worker 2, jvmroute: jboss-eap-6.3-2
# stop 1.
# let 2. and 3. trying to contact the balancer
# OOM
See two detailed logs for both machines: [^OOM-server.logs.zip].
At the moment, I'm not sure it was really mod_cluster's fault, due to the JGroups messages. I have a hunch it might be linked to the new JBossWeb NIO...
Assigning to myself for investigation.
was:
# start Apache HTTP Server with mod_cluster
# start EAP 6.3 worker 1, jvmroute: jboss-eap-6.3
# start EAP 6.3 worker 2, jvmroute: jboss-eap-6.3-2
# stop 1.
# let 2. and 3. trying to contact the balancer
# OOM
See two detailed logs for both machines: [^OOM2-server.log], [^OOM-server.log].
At the moment, I'm not sure it was really mod_cluster's fault, due to the JGroups messages. I have a hunch it might be linked to the new JBossWeb NIO...
Assigning to myself for investigation.
> Balancer shutdown, AS:OutOfMemoryError: unable to create new native thread
> --------------------------------------------------------------------------
>
> Key: MODCLUSTER-402
> URL: https://issues.jboss.org/browse/MODCLUSTER-402
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.8.Final
> Environment: HP-UX ia64, HP JDK 1.7
> Reporter: Michal Babacek
> Assignee: Michal Babacek
> Priority: Critical
> Fix For: 1.2.9.Final
>
> Attachments: OOM-server.logs.zip
>
>
> # start Apache HTTP Server with mod_cluster
> # start EAP 6.3 worker 1, jvmroute: jboss-eap-6.3
> # start EAP 6.3 worker 2, jvmroute: jboss-eap-6.3-2
> # stop 1.
> # let 2. and 3. trying to contact the balancer
> # OOM
> See two detailed logs for both machines: [^OOM-server.logs.zip].
> At the moment, I'm not sure it was really mod_cluster's fault, due to the JGroups messages. I have a hunch it might be linked to the new JBossWeb NIO...
> Assigning to myself for investigation.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (MODCLUSTER-402) Balancer shutdown, AS:OutOfMemoryError: unable to create new native thread
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-402?page=com.atlassian.jira.pl... ]
Michal Babacek updated MODCLUSTER-402:
--------------------------------------
Attachment: OOM-server.logs.zip
> Balancer shutdown, AS:OutOfMemoryError: unable to create new native thread
> --------------------------------------------------------------------------
>
> Key: MODCLUSTER-402
> URL: https://issues.jboss.org/browse/MODCLUSTER-402
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.8.Final
> Environment: HP-UX ia64, HP JDK 1.7
> Reporter: Michal Babacek
> Assignee: Michal Babacek
> Priority: Critical
> Fix For: 1.2.9.Final
>
> Attachments: OOM-server.logs.zip
>
>
> # start Apache HTTP Server with mod_cluster
> # start EAP 6.3 worker 1, jvmroute: jboss-eap-6.3
> # start EAP 6.3 worker 2, jvmroute: jboss-eap-6.3-2
> # stop 1.
> # let 2. and 3. trying to contact the balancer
> # OOM
> See two detailed logs for both machines: [^OOM2-server.log], [^OOM-server.log].
> At the moment, I'm not sure it was really mod_cluster's fault, due to the JGroups messages. I have a hunch it might be linked to the new JBossWeb NIO...
> Assigning to myself for investigation.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (MODCLUSTER-402) Balancer shutdown, AS:OutOfMemoryError: unable to create new native thread
by Michal Babacek (JIRA)
Michal Babacek created MODCLUSTER-402:
-----------------------------------------
Summary: Balancer shutdown, AS:OutOfMemoryError: unable to create new native thread
Key: MODCLUSTER-402
URL: https://issues.jboss.org/browse/MODCLUSTER-402
Project: mod_cluster
Issue Type: Bug
Affects Versions: 1.2.8.Final
Environment: HP-UX ia64, HP JDK 1.7
Reporter: Michal Babacek
Assignee: Michal Babacek
Priority: Critical
Fix For: 1.2.9.Final
# start Apache HTTP Server with mod_cluster
# start EAP 6.3 worker 1, jvmroute: jboss-eap-6.3
# start EAP 6.3 worker 2, jvmroute: jboss-eap-6.3-2
# stop 1.
# let 2. and 3. trying to contact the balancer
# OOM
See two detailed logs for both machines: [^OOM2-server.log], [^OOM-server.log].
At the moment, I'm not sure it was really mod_cluster's fault, due to the JGroups messages. I have a hunch it might be linked to the new JBossWeb NIO...
Assigning to myself for investigation.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (MODCLUSTER-401) EnableOptions and SSL configuration
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-401?page=com.atlassian.jira.pl... ]
Jean-Frederic Clere commented on MODCLUSTER-401:
------------------------------------------------
CreateBalancers default value is 2 so the balancer is created in the main and not in 10.16.92.191:2081 if main doesn't have a SSL configuration the SSL proxy can't work.
> 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 Babacek
> Assignee: Jean-Frederic Clere
> Fix For: 1.2.9.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.2.3#6260)
9 years, 11 months
[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 updated MODCLUSTER-401:
-----------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1093853
> 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 Babacek
> Assignee: Jean-Frederic Clere
> Fix For: 1.2.9.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.2.3#6260)
9 years, 11 months