tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Ralph Feller, afelle1" <afel...@lsu.edu>
Subject Re: Possibility of JSVC daemon with APR reacting strangely to TCP health checks
Date Mon, 14 Jul 2008 20:16:37 GMT
After stepping through the tcpdump, we determined that the health checks are
Layer 4 TCP health checks where the load balancer doesn't provide any HTTP
request information whatsoever and closes the connection as soon as it is
established.  Here is the play-by-play of tcpdump:

       Source              Destination
         DX                  APPL001
Frame 1  ---------SYN---------->
Frame 2  <------SYN,ACK---------
Frame 3  ---------ACK---------->
Frame 4  -------FIN,ACK-------->
Frame 5  <--------ACK-----------
Frame 6  ---------ACK---------->

I am currently checking on how the load balancer's Layer 7 health checks
work, however it seems Tomcat with and without the JSVC daemon is reusing
garbage in the event of empty Layer 4 health checks.  Is this desired
behavior?  Is this necessarily a problem with Tomcat or could this be an
issue with the version of tomcat-native distributed with Tomcat 6?

Thanks!


On 7/14/08 12:08 PM, "Len Popp" <len.popp@gmail.com> wrote:

> The obvious question is, are these TCP health checks well-formed HTTP
requests
> or not?

I guess it's hard to snoop the exact contents of the request
> since
it's sent via SSL, but maybe you could configure it to send the
> exact
same health checks to port 80 via plain HTTP. Then you could
> use
Wireshark to see the exact contents of the requests, and figure out if
the
> problem is in the requests or in Tomcat.
-- 
Len


On Mon, Jul 14, 2008 at
> 09:57, Andrew Feller <andrew.feller@gmail.com> wrote:
> Is there any reason
> why Tomcat running under the JSVC daemon using the
> Apache Portable Runtime
> for SSL would act erratically to TCP health checks?
>
> We are using a Juniper
> DX for load balancing that uses TCP health checks to
> port 443 of a Tomcat
> instance in order to keep the machine in the forwarding
> cluster.  However,
> whenever the health check comes in, the logs generated by
> Tomcat's
> AccessLogValve show them to be malformed HTTP requests.  My
> networking
> colleagues and the Juniper engineer confirm that it is sending
> plain TCP
> health checks; nothing fancy.  As you can see in the logs below,
> Tomcat
> states the TCP health check is malformed HTTP request.  Any thoughts?
>
>
> Sincerely grateful for any assistance,
> Andrew
>
> Environment:
>
>    OS:
> RHEL 5 32-bit
>    Tomcat: 6.0.14
>    Connectors: Apache Portable Runtime
> distributed with Tomcat binaries
>    Connector configuration:
>
>
> <Connector port="443"
> protocol="org.apache.coyote.http11.Http11AprProtocol"
> maxThreads="150"
>        SSLEnabled="true" scheme="https" secure="true"
> clientAuth="false"
> sslProtocol="TLS"
>
> SSLCertificateFile="/etc/pki/tls/certs/server.crt"
>
> SSLCertificateKeyFile="/etc/pki/tls/private/server.key"
>        />
>
>
> Excerpt from AccessLogValve output (with health check occurring every 9
>
> seconds):
>
> 192.168.1.2 [07/Jul/2008:13:32:40 -0500] GET /serviceValidate
> 200 240 -
> serviceA.example.com 9 ?&someparam=1-f5dUkJr3KDo0VewDxeF7-
>
> serviceA.example.com&service=https%3A%2F%2serviceB.example.com%2Flogin
>
>
> 192.168.1.2 [07/Jul/2008:13:32:40 -0500]
>
> H8f7UQt2SP-IeCHR0myAbQ0PyeXhTISx6ldp5RBOkd6GNkwfakOE6VGgFDyUr1wWWcVksPYbJSfD8B
> qxjFHze8M0jGWn5dqfb3o0-VOovBOlsANm_lvjg7ZUEfz9ZFfo3RPxtt-qqP2hZNlynme7Dr62iBCq
> 5K4DuryO4Dy3ne6uGizIIXkGIAf5OHU-sAMYnDnhi2IgB_IKIPwCqAA_DMwYfFRAuVwZ1X7GwcZZgP
> MB8DnyhAUyFtyyK1cIqkH7b2HIhqFquoQJP2IhZbq-IfztVAQ4xzfDfXiDimop2AGuGK8aKhYWNhRM
> uACscC7dKEKyUsJj9pFAzdZy8Rkl4MqqVbYyh-tsKhjgL2xEEofVw7WyADz5dwZvxX6CpewNhXxdks
> NH39Rg7BvcokYFt5baJ_1hZeAH0ynn7lPTL4VYID4KKFZAf1IlUFd6jNJSMtD7GzidasfIlLO4Ds4b
> 7Bg_leB4rX8biJBYPBB0_Fp8gBQLXyBpaIHHI47wgu-onISD6hGD-sbWumqSUvdikJUsrBCzuFuSWh
> li4JceBwCdZqR3dRy3dxPNnQy1RsVtdkM1If8D5cdFIhgU4F2c1yVUZkOTYXklQ3NZ53BSnLMYnMKx
> oRJ7P-1KYBjCZkMz8MynKcEMtUTFtq2AaMOsQ3qOnHjMvmxCiKv0N6tQRyHjrwgP8bfWE8Lk3z8x_q
> gXc_UsD4-MeBayyhqbwl-m23xXw2IGVJ7B4Ul4JVHIhuP_9fv4AHsgw4noAAAM5UwMR1lWT_Dupw22
> 8eFXpuelprJzB4ilwXt3ey8IweBaiD84uB_zwhS3TAgG_ZKQVuOC6YJFbsXIWi59UdBBXncbhoxbXh
> Rfn1DidZjHKvSyWXsuzaYsgaYSmDoWBKfn2Nyzq5dEi2ZwRwwQLyBQoJg8uj-9Q2ksayhmGbK8zWMc
> FrPwMi3PwgNeru8GMu1EWw3IdNiM4CFEswnmNi_VSK1lr2oZXHKO6zOt58wW5eoFeXyifW42n3qq4x
> pnOtAdx0NLYIcaVOfhcN8WRAxX_PGDwXrhqLM7HqaNyxl_V_SZ2U-DIsXTK9ds5dRzGD1NzFs6jTXH
> kmFv5041Aq3OzGjpKjoE-IcjOutD7bNfHXV9DiwGdFuS6ONBZHO-m5GtwjOFpoVDXVZNiQIvKnxaUd
> Fgeqgp1Yww15kHWrV7Z80jrPedydl6htlcSagGblsyzfJVVhBMrYx-3BQtC-JqKdkyQmahClMNlrOr
> slNGqs3PQ4Ye8AIivjw21RP8qqMJksPx96hyqiy1szTa3eZRMkCANzvj1NWODhfzRZ9by50pLFnYRt
> OM9XS0IdTB52NIdG4LRttvBnxE3GSGqNTTzkhXIDydZ5PuDF0rgzuhVAhHeKbuc3FgvPcaoBcKDJ4r
> jFfmtJ79--vKvbn_tVzJVthjuf3mM19HEt5eCwzzYQB0m_j0hltGjx5pu4P985QUvYdbTIFQFxLsHT
> 3174IqeVxNkMcjKZOYFVBT5ToLPx_4cWVv08mgygQ1zbbBm0Peuepm_0ZhpmPG3IJ4y_RAVBZXTWhV
> SZL4s-EwlpZAknGdL1UVyYUm8SnLgwvQRg5l61WeecYaJPLn_zfJDH8G9valeooxNU9BOnPBtJ3737
> xcfzLzv7S5wnjbKUhRMWROs_Sf4FCZNVYqe_GjnC-dbT232tioZ9h6WPv7Wt-6ePNH_dFOz90EBDd4
> Qx7OWxmW-MEtWMC9zmLFLlpgky1UTc3gQZCZjbMvx
>
> 192.168.1.2
> [07/Jul/2008:13:32:49 -0500] GET /serviceValidate 200 240 -
>
> serviceA.example.com 6 ?&someparam=-1-f5dUkJr3KDo0VewDxeF7-
>
> serviceA.example.com&service=https%3A%2F%2FserviceB.example.com%2Flogin
>
>
> 192.168.1.2 [07/Jul/2008:13:32:49 -0500]
>
> H8f7UQt2SP-IeCHR0myAbQ0PyeXhTISx6ldp5RBOkd6GNkwfakOE6VGgFDyUr1wWWcVksPYbJSfD8B
> qxjFHze8M0jGWn5dqfb3o0-VOovBOlsANm_lvjg7ZUEfz9ZFfo3RPxtt-qqP2hZNlynme7Dr62iBCq
> 5K4DuryO4Dy3ne6uGizIIXkGIAf5OHU-sAMYnDnhi2IgB_IKIPwCqAA_DMwYfFRAuVwZ1X7GwcZZgP
> MB8DnyhAUyFtyyK1cIqkH7b2HIhqFquoQJP2IhZbq-IfztVAQ4xzfDfXiDimop2AGuGK8aKhYWNhRM
> uACscC7dKEKyUsJj9pFAzdZy8Rkl4MqqVbYyh-tsKhjgL2xEEofVw7WyADz5dwZvxX6CpewNhXxdks
> NH39Rg7BvcokYFt5baJ_1hZeAH0ynn7lPTL4VYID4KKFZAf1IlUFd6jNJSMtD7GzidasfIlLO4Ds4b
> 7Bg_leB4rX8biJBYPBB0_Fp8gBQLXyBpaIHHI47wgu-onISD6hGD-sbWumqSUvdikJUsrBCzuFuSWh
> li4JceBwCdZqR3dRy3dxPNnQy1RsVtdkM1If8D5cdFIhgU4F2c1yVUZkOTYXklQ3NZ53BSnLMYnMKx
> oRJ7P-1KYBjCZkMz8MynKcEMtUTFtq2AaMOsQ3qOnHjMvmxCiKv0N6tQRyHjrwgP8bfWE8Lk3z8x_q
> gXc_UsD4-MeBayyhqbwl-m23xXw2IGVJ7B4Ul4JVHIhuP_9fv4AHsgw4noAAAM5UwMR1lWT_Dupw22
> 8eFXpuelprJzB4ilwXt3ey8IweBaiD84uB_zwhS3TAgG_ZKQVuOC6YJFbsXIWi59UdBBXncbhoxbXh
> Rfn1DidZjHKvSyWXsuzaYsgaYSmDoWBKfn2Nyzq5dEi2ZwRwwQLyBQoJg8uj-9Q2ksayhmGbK8zWMc
> FrPwMi3PwgNeru8GMu1EWw3IdNiM4CFEswnmNi_VSK1lr2oZXHKO6zOt58wW5eoFeXyifW42n3qq4x
> pnOtAdx0NLYIcaVOfhcN8WRAxX_PGDwXrhqLM7HqaNyxl_V_SZ2U-DIsXTK9ds5dRzGD1NzFs6jTXH
> kmFv5041Aq3OzGjpKjoE-IcjOutD7bNfHXV9DiwGdFuS6ONBZHO-m5GtwjOFpoVDXVZNiQIvKnxaUd
> Fgeqgp1Yww15kHWrV7Z80jrPedydl6htlcSagGblsyzfJVVhBMrYx-3BQtC-JqKdkyQmahClMNlrOr
> slNGqs3PQ4Ye8AIivjw21RP8qqMJksPx96hyqiy1szTa3eZRMkCANzvj1NWODhfzRZ9by50pLFnYRt
> OM9XS0IdTB52NIdG4LRttvBnxE3GSGqNTTzkhXIDydZ5PuDF0rgzuhVAhHeKbuc3FgvPcaoBcKDJ4r
> jFfmtJ79--vKvbn_tVzJVthjuf3mM19HEt5eCwzzYQB0m_j0hltGjx5pu4P985QUvYdbTIFQFxLsHT
> 3174IqeVxNkMcjKZOYFVBT5ToLPx_4cWVv08mgygQ1zbbBm0Peuepm_0ZhpmPG3IJ4y_RAVBZXTWhV
> SZL4s-EwlpZAknGdL1UVyYUm8SnLgwvQRg5l61WeecYaJPLn_zfJDH8G9valeooxNU9BOnPBtJ3737
> xcfzLzv7S5wnjbKUhRMWROs_Sf4FCZNVYqe_GjnC-dbT232tioZ9h6WPv7Wt-6ePNH_dFOz90EBDd4
> Qx7OWxmW-MEtWMC9zmLFLlpgky1UTc3gQZCZjbMvx
>


-- 
Andrew R. Feller, Analyst
Information Technology Services
200 Fred Frey Building
Louisiana State University
Baton Rouge, LA 70803
(225) 578-3737 (Office)
(225) 578-6400 (Fax)


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message