[jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[ji...@apache.org]

The following comment has been added to this issue:

     Author: Ralf Hauser
    Created: Fri, 21 May 2004 9:25 PM
       Body:
Noel, I never said that the current implementation is a defect. I only think it is not very memory efficient. One more degree of sophistication what I am proposing comes next:

As per http://nagoya.apache.org/jira/browse/JAMES-288 , doLIST could occur multiple times, thus, it is better to do 
            	mc.setMessage(null); //instead of mc = null;
this way, only one full message body remains in RAM at a time.
This is only a disadvantage if the doRETR is executed multiple times on the same message.

When a doTOP arrives, the message might remain in memory since it is highly likely that a doRETR will follow.

---------------------------------------------------------------------
View this comment:
  http://issues.apache.org/jira/browse/JAMES-248?page=comments#action_35677

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