[
https://issues.apache.org/jira/browse/IO-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved IO-220.
--------------------------------
Assignee: Niall Pemberton
Fix Version/s: 2.0
Resolution: Fixed
Fixed thanks
http://svn.apache.org/viewvc?view=revision&revision=982093
> FileCleaningTracker Vector performs badly under load
> ----------------------------------------------------
>
> Key: IO-220
> URL: https://issues.apache.org/jira/browse/IO-220
> Project: Commons IO
> Issue Type: Bug
> Affects Versions: 1.0, 1.1, 1.2, 1.3, 1.3.1, 1.3.2, 1.4, 2.0, 2.x
> Environment: Using commons-io-1.4 via commons-fileupload-1.1.1 in
> Apache Tomcat/5.5.0 on Java 1.6.
> Reporter: Michael Haverkamp
> Assignee: Niall Pemberton
> Fix For: 2.0
>
>
> When subjected to heavy load, the performance of
> org.apache.commons.io.FileCleaningTracker degrades and becomes a bottleneck
> to the system. In our case, we had over 2 millions entries on the "trackers"
> Vector. Under these conditions, the call to trackers.remove(tracker) on line
> 214 becomes very inefficient as it causes the Vector to shift and reindex the
> remaining data. In addition, calls to trackers.add are forced to wait on the
> inefficient remove operation. With the application idle, it took several
> hours for the File Reaper thread to finish processing the entries on the
> trackers Vector.
> The solution for use was to implement trackers as a HashSet instead of a
> Vector. Thus line 52 was changed from:
> final Collection /* Tracker */ trackers = new Vector(); // synchronized
> to
> final Collection /* Tracker */ trackers = Collections.synchronizedSet(new
> HashSet()); // synchronized
> Imports were also change appropriately.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
