Bug 42925 - Sendfile thread uses 100% cpu for long periods
Summary: Sendfile thread uses 100% cpu for long periods
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 major (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
: 44938 (view as bug list)
Depends on:
Reported: 2007-07-18 01:53 UTC by Chris Lear
Modified: 2012-02-17 12:05 UTC (History)
3 users (show)

Proposed patch (2.32 KB, patch)
2007-10-05 14:01 UTC, Remy Maucherat
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Lear 2007-07-18 01:53:44 UTC
Tomcat 6.13 using APR, running under jsvc on linux (debian, but tomcat isn't
installed via apt-get) 2.6.21 SMP. Sun Java 1.6.0.

After tomcat was running for a short while (<15mins), cpu usage on one cpu would
go to 100%, as shown by top. Using ps xU tomcat -fL showed that one tomcat
thread was using far more cpu than all the others. Cross-referencing the thread
id to a thread dump (from kill -3) showed that it was the sendfile thread that
was consuming all the cpu time.

Tomcat was still responding to requests while this was going on, but obviously
the high cpu load was not necessary or helpful. Watching cpu usage via top
showed that at times it would return to normal, but never for long.

Workaround: I added 'useSendfile="false"' to the http connector, restarted
tomcat, and it has now run with normal cpu usage for over 12 hours.
Comment 1 Chris Elving 2007-09-25 19:44:40 UTC
This is a result of AprEndpoint.Sendfile.init calling Poll.create with a timeout
parameter but never calling Poll.maintain to deal with the resulting poll
descriptor timeouts. My work around was to pass a timeout of -1 to Poll.create.
Comment 2 Remy Maucherat 2007-10-05 14:01:58 UTC
Created attachment 20930 [details]
Proposed patch

This patch replaces the TODO with code that calls maintain. I was not aware
calling maintain was more or less mandatory.
Comment 3 Mark Thomas 2007-11-29 15:12:25 UTC
This was fixed in rev 583650.
Comment 4 Mark Thomas 2008-05-07 00:16:47 UTC
*** Bug 44938 has been marked as a duplicate of this bug. ***