You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Michael Haverkamp (JIRA)" <ji...@apache.org> on 2009/10/23 22:33:59 UTC
[jira] Created: (IO-220) FileCleaningTracker Vector performs badly
under load
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.4, 1.3.2, 1.3.1, 1.3, 1.2, 1.1, 1.0, 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
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.
[jira] Resolved: (IO-220) FileCleaningTracker Vector performs badly
under load
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ 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.