Klaus Wagner schrieb:
> Here my impressions of the situation from an serveradmin perspective.
> 
> On Wed, 2006-08-23 at 17:08 +0200, Rainer Jung wrote:
>> I still don't have a consistent idea what happened around the firewall:
>>
>> - silently dropping is not expected apart from a deny rule, but deny
>> will not be the rule that had been applied to the apache-tomcat connection.
> 
> state keeping firewalls have timeouts. If the firewalltimeouts are lower
> that keepalive timeouts there is a possibility that the firewall
> invalidates the connection - afterwards it will drop any related packet.
> Another possibility would be a firewall that is forgetting states which
> would be clearly a bug.

OK, then the read side on tomcat will not detect the problem, because
there is no connection shutdown. Tomcat threads will still stay in read
and only the connectionTimeout will help. Stopping reuse sacrifices
performance and ressources (e.g. firewall ressources...), using correct
keepalive values for the TCP stack seems to be worth an investigation.

> 
>> - only shutting down one side of an established (!) connection seems broken
> 
> I don't think this is going to happen, but here is the reason why tomcat
> is in the worse situation:
> 
> client ---request---> apache
> apache tries to use the stale connection and realizes that this is
> broken de facto immediately (socket error)
> 
> tomcat on the other hand is not really notified (execpt when the kernel
> marks the connection as stale (timeout) AND tomcat tries to read from or
> poll/select the connections state)
> 
>> - no answers yet about using TCP keep-alive
> 
> should help in most cases imho

That's my expectation to. I assume noone tried it in the case in question.

> 
> regards Klaus
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to