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 Fri, 10 Oct 2008 02:18:46 GMT

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

Markus Wiederkehr commented on MIME4J-72:

Oleg, here are a few more thoughts, please bear with me..

dispose method: unless you decide to keep the entire message in memory you will _always_ have
the need to free the backing resources when the message is no longer needed. Regardless of
what backing mechanism you want to use. Therefore the typical use case looks like this:

Message message = acquireMessage();
try {
finally {

Clearly message.dispose() is more convenient than message.accept(new DisposingEntityVisitor()).

So this is not something exotic. You dispose of a message for the same reasons you close an
I/O stream. It has to be an inherent part of the API.

Regarding the visitor, Oleg's vs Markus'.. Please consider a message like this one:

      multipart #1
            text part #1
            multipart #2
                  binary part #1
                  binary part #2
            binary part #3

I believe that your visitor cannot be used to copy the structure of this message. It gets
notified of the entities and bodies in the order they appear. Therefore it is impossible to
determine if binary part #3 belongs to multipart #1 or multipart #2.

Besides, what good is a visitor if I have to do all the instance-of checks by myself. If I
wanted to do instance-of I would not need a visitor in the first place.

After all a visitor is only a crutch for languages that don't have a multiple dispatch mechanism.
So the visitor should inform you on the concrete leaf classes as good as possible.

> 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: entityvisitor.patch, mime4j-disposable.patch, mime4j-dispose-finalize.patch,
mime4j-dispose-no-clutter.patch, mime4j-dispose-visitor.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