james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann (JIRA)" <server-...@james.apache.org>
Subject [jira] Commented: (MIME4J-72) Provide a means to dispose a Message
Date Wed, 08 Oct 2008 06:27:44 GMT

    [ https://issues.apache.org/jira/browse/MIME4J-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637792#action_12637792
] 

Bernd Fondermann commented on MIME4J-72:
----------------------------------------

I reviewed both patches and I think this kind of resource managment is not a good thing.

Disadvantages:
+ It pollutes the whole framework, by introducing dispose() and if(disposed) checks everywhere
and although only TempFile*Body is concerned. 
+ dispose state removes indempotency. two method calls yield different results, if dispose()
was called in between. but there is no way to check if a part has been disposed
+ delete candidate files are held in a static final container. if one file is to be deleted,
all files failing deletion are visited (again (and again)) in a synchonized block. this is
bad. it introduces a severe bottleneck for the whole framework.

Prososal:
+ Introduce 
public interface ManagedResource {
    ResourceManager getResourceManager();
}
only on TempFile*Body.
The ResourceManager should then be responsible for managing the tempory files. tracking, copying,
deleting, whatever.

Advantages:
+ ResourceManager can do all the complicated things we now try to objects which should not
be concerned with resource management and without polluting our existing framework interfaces.
+ We make this concern separately testable, and exchangable.
+ ResourceManager can grow without affecting other parts of the framework and changing interfaces
+ ResourceManager must not rely on calls to dispose() to efffectively collect disposed resources
(removing temp files), this can be done by a scheduler or a method call etc.
+ no keeping track of the disposed flag in every method call





> Provide a means to dispose a Message
> ------------------------------------
>
>                 Key: MIME4J-72
>                 URL: https://issues.apache.org/jira/browse/MIME4J-72
>             Project: JAMES Mime4j
>          Issue Type: Improvement
>    Affects Versions: 0.5
>            Reporter: Markus Wiederkehr
>            Assignee: Robert Burrell Donkin
>         Attachments: mime4j-disposable.patch, mime4j-dispose-finalize.patch
>
>
> Currently an org.apache.james.mime4j.message.Message uses temporary files to store text
and binary attachments of the message. Unfortunately a Message cannot be disposed of explicitly.
Even when it eventually gets garbage collected the temp files continue to exist until the
VM exits.
> If the VM runs for a long time and a lot of e-mails get processed this can become a major
problem.
> For this reason I think that class Entity and interface Body should both have a method
to dispose of the object. Multipart should dispatch a dispose-call to its list of body parts.
A BodyPart should dispose of its body and concrete Body implementation such as TempFileTextBody
should ultimately invoke delete() on the backing TempFile.
> Last but not least SimpleTempStorage$SimpleTempFile should not silently ignore delete-calls.

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


Mime
View raw message