james-server-dev mailing list archives

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

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

Markus Wiederkehr commented on MIME4J-72:


dispose() should free any resources that cannot be reclaimed by the garbage collector. This
implies that dispose() essentially destroys the object and it can no longer be used afterwards.
So idempotency cannot be an issue here. It is perfectly okay for an object to behave unpredictably
once disposed. You would not expect an InputStream to work as it did before once you have
closed it, would you?

The intention is to dispose an object and leave it to the garbage collector. If you continue
to use it your are doing something wrong.

As for the pollution of the framework, this is a valid point. But the disposed flag is entirely
optional and can be removed. I will provide a patch for that shortly.

Your third concern was "all files failing deletion are visited (again (and again))". I don't
see where this happens. There is no dispose call inside a finally block (the super.dispose()
in TempFileBinaryBody only sets the parent to null, there is no recursion, loop or anything).

Considering your proposal of a ResourceManager on TempFile*Body.. TempFileTextBody and TempFileBinaryBody
aren't even public classes.. And the use case is to simply dispose a message and free all
temp files held by it or its parts. With my approach you simply call message.dispose() and
be done with it. With your approach you would first have to traverse the message hierarchy
down to the TempFile*Bodys, obtain the ResouceManager and then free the resources - seems
like a lot of work to me.

> 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, mime4j-dispose-no-clutter.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
> 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

View raw message