Community
Participate
Working Groups
Build Identifier: jetty-distribution-8.0.4.v20111024 The idle timeout is triggered in SelectChannelEndPoint.blockWritable which is called by AbstractGenerator.flush only if the buffer couldn't be flushed completely. This happens only with larger outputs. So if you write a small amount of data and flush the idle timeout is never triggered or reseted. For instance a heartbeat of 1 byte every 5s never closes the connection from idling even if the heartbeat writing stops. The problem is also noticeable the other way around. If at one point enough data was written to trigger the idle timeout and after that only the heartbeat (1byte/5s) is written the idle timeout closes the connection after the specified time. The idle timeout should be maintained in SelectChannelEndPoint.flush not in SelectChannelEndPoint.blockWritable to solve this issue. Reproducible: Always
Sebastian, I think there is an issue here, but not exactly how you describe. Note that if you have a servlet that does doGet(){sleep(forever);}, then the connection should not timeout. The idle timeout should only apply when the connection is not dispatched in a request, or it that request is blocked on the IO. Will review and clean up this code.
The idle timeout is poorly implemented as it mixes up the state of when to check for idle with working out if the endpoint is idle or not. Changing so that it is the SelectChannelEndPoint fill and flush methods that will reset the idle timestamp and there is a new setCheckForIdle(boolean) method that controls if we care about idle connections or not.
fixed pushed to jetty-7.6 branch @ ddce35a 7.6.0.RC0 due in the next few days.
hmmm looks like some of the changes were rolled back??? Specifically there is no check for idle boolean, but should work much the same... if not as accurately. However there is a problem for HTTP, as idle is not checked for closed connections. Fixed this for now by putting setCheckForIdle(true) into shutdownOutput
