The following comment has been added to this issue:
Author: Noel J. Bergman
Created: Fri, 21 May 2004 10:44 PM
Body:
> mc = null;
Won't help, since the object is in the userInbox collection.
> mc.setMessage(null);
If we were to do that, subsequent calls to mc.getMessageSize(), mc.getMessage(), and
mc.writeMessageTo() would all fail.
The problem you are trying to solve is not the Mail instance or the
MimeMessageWrapper, but the Message content. That is something we are looking to
address, but should not be an issue for either file or dbfile stores.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JAMES-248?page=comments#action_35679
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JAMES-248
Here is an overview of the issue:
---------------------------------------------------------------------
Key: JAMES-248
Summary: memory management - finalize/nullify after successful delivery of
retrieved MailImpl
Type: Improvement
Status: Closed
Priority: Major
Resolution: CANNOT REPRODUCE
Project: James
Versions:
2.1.3
Assignee:
Reporter: Ralf Hauser
Created: Mon, 5 Apr 2004 11:54 AM
Updated: Fri, 21 May 2004 10:44 PM
Environment: Redhat 9
Description:
My application required an adaptation of the MailRepository.retrieve() method.
It creates a temporary object on disk and I provided it with a finalize() method for
cleaning up.
The interesting thing is that this finalize is not executed until I shut-down james.
This leads me to the conclusion that even if there was no ties to a disk operation the
mipl.setMessage(mimeMessage);
remains in memory long after the MUA has disconnected.
Isn't this kind of a memory leak? After all, attachments to such a MIMEMessage can be
13MB large.
Shouldn't those objects be null-ed latest after the POP3Handler.doQUIT of a session?
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
