[
https://issues.apache.org/jira/browse/IO-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477848
]
Holger Hoffstätte commented on IO-116:
--------------------------------------
Hi,
ich fürchte wir reden total aneinander vorbei :)
Ich weiß schon wie der FileTracker funktioniert, und auch daß er als
"Dienst" eine etwas andere Rolle spielen darf als z.B. die üblichen
statischen Helfer-Methoden. Gerade aber weil er nur ab und zu laufen muß,
ist es ein guter Kandidat für einen Timer - weil z.B. eine Webapp ja auch
garantiert noch andere Dinge zu tun hat, und es wäre sicherlich einfacher,
nur einen Timer pro Webapp für alle periodischen Dinge zu benutzen/zu
kontrollieren als x verschiedene Mechanismen.
Worauf ich hinauswollte: Bibliotheken (im Gegensatz zu Frameworks) "an
sich" sollten eben überhaupt gar keine Threads starten - weil das sonst
eben genau darauf hinausläuft, daß jede Klasse ihr Thread-Handling selbst
neu stricken muß, mit ClassLoader-leaks und dem ganzen Klimbim.
Es gibt unzählige Verwendungen für asynchrone Objekte in Collections, IO,
Lang, Pool, DBCP usw. und obwohl eigentlich nur 1-2 gebraucht würden um
die Arbeit zu erledigen hätte man am Ende mehrere hundert Threads laufen,
nur weil wieder keiner über APIs und Komposition/Zusammenspiel im größeren
Rahmen nachgedacht hat. Wenn ich in meiner App z.B. 100 kleine Pools habe,
die sich alle 5 Minuten periodisch selbst säubern können, brauche ich
dafür wirklich keine 100 Threads, die 99.99% der Zeit einfach nichts tun.
Mein Kommentar war lediglich als kleiner Denkanstoß für commons allgemein
gedacht.
ciao
Holger
> Replace static FileCleaner methods
> ----------------------------------
>
> Key: IO-116
> URL: https://issues.apache.org/jira/browse/IO-116
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
> Affects Versions: 1.3.1
> Reporter: Jochen Wiedmann
> Priority: Critical
> Fix For: 1.4
>
> Attachments: commons-io-filecleaningtracker.patch
>
>
> The attached patch aims to finally resolve the problems, which are named in
> IO-99, FILEUPLOAD-120, and FILEUPLOAD-125.
> I choosed a conservative strategy: Basically I copied the FileCleaner class
> to an instantiable class FileCleaningTracker with instance methods. The
> static FileCleaner methods are now implemented by a static instance of
> FileCleaningTracker. (The name FileCleaningTracker is, of course,
> questionable.
> The FileCleaningTestCase was also created by simply copying FileCleaner to
> FileCleaningTestCase. FileCleanerTestCase is now similarly implemented as a
> subclass of FileCleanerTestCase which uses the static instance of FileCleaner
> rather than a dynamically created instance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
