commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holger Hoffstätte (JIRA) <j...@apache.org>
Subject [jira] Commented: (IO-116) Replace static FileCleaner methods
Date Sun, 04 Mar 2007 19:30:50 GMT

    [ 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message