Oh yeah forgot about ping being ICMP. :)
I'm going to look into exactly what the 'heartbeat' is. I think it opens
a connection and then doesn't send a request - but that's speculation. I
agree that the more robust method would be to actually do a GET and see
the results (maybe to a specific file and it can look for a keyword or
something).
I'll avoid the 'fork' route if at all possible cause I'm lazy and don't
want to maintain a patch that won't get included in the main distro. :)
Thanks for the thoughts . . .
"Craig R. McClanahan" wrote:
>
> Geoff Lane wrote:
>
> > Reply to myself. :)
> > So after some more digging, I find out that it's caused by a 'heartbeat'
> > monitor that we have on our servers to check the status. It pings port
> > 80 to check if the webserver is alive. Apache does not log this in it's
> > error logs as a Connection reset, but running Tomcat standalone does.
> >
> > Is this a bug? No request is actually being made, just a ping to port 80
> >
>
> If by "ping" you mean "run the Unix 'ping' utility", you would be right. The only
>problem with that theory
> is that you can only ping hosts, not individual ports ...
>
> What is happening is that your monitor program is violating the HTTP protocol,
>because it is establishing a
> network connection to port 80, but never sending a valid request. Therefore, it's
>perfectly within Tomcat's
> rights to complain about it.
>
> It is also perfectly within your rights to modify Tomcat to *not* complain about it,
>since this is specific
> to your site's approach to network monitoring. However, IMHO it is not a bug.
>
> An alternative approach for your particular situation would be to have your monitor
>process actually perform
> an HTTP request, instead of just connecting and disconnecting. Besides avoiding
>these error messages, this
> is also a more robust test to see if Tomcat is actually up and running (consider: if
>all the request
> processing threads were hung for some reason, but the server socket thread was still
>running, your monitor
> process would give you a false sense of security that everything is fine when it
>really was not).
>
> Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
--
-------------------------------------------
Geoff Lane <[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
