[IO-220] FileCleaningTracker Vector performs badly under load

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.0, 1.1, 1.2, 1.3, 1.3.1, 1.3.2, 1.4, 2.0, 3.x
• Fix Version/s: 2.0

Environment

Using commons-io-1.4 via commons-fileupload-1.1.1 in Apache Tomcat/5.5.0 on Java 1.6.

• Assignee: Niall Pemberton
• Reporter: Michael Haverkamp
• Created: 23/Oct/09 20:32
• Updated: 10/Nov/11 18:09
• Resolved: 04/Aug/10 00:37

Description

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.