You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by ji...@apache.org on 2004/04/05 20:54:43 UTC
[jira] Created: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
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: Unassigned
Priority: Major
Project: James
Versions:
2.1.3
Assignee:
Reporter: Ralf Hauser
Created: Mon, 5 Apr 2004 11:54 AM
Updated: Mon, 5 Apr 2004 11:54 AM
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
[jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Ralf Hauser
Created: Wed, 14 Apr 2004 3:07 AM
Body:
Noel, thx for the insight.
But wouldn't the finalizer immediately be called if the MailImpl object the MailRepository.java's retrieve() mehtod returns would be actively set to null once it has been transported to the MUA?
Perhaps addint the line
mc = null;
at the end of the POP3Handler.java's doRETR() method's try-catch block would aready do it?
perhaps do it again in a finally part to this try-catch block?
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JAMES-248?page=comments#action_35016
---------------------------------------------------------------------
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: Unassigned
Priority: Major
Project: James
Versions:
2.1.3
Assignee:
Reporter: Ralf Hauser
Created: Mon, 5 Apr 2004 11:54 AM
Updated: Wed, 14 Apr 2004 3:07 AM
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
[jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Noel J. Bergman
Created: Wed, 14 Apr 2004 6:46 AM
Body:
The Mail object is held in the userInbox for the duration of the session. When streaming is possible (there is an issue to be fixed with db protocol, but not file or dbfile), the message is streamed directly from store to wire. When resetHandler is called in the finally {} clause of handleConnection, the objects are released.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JAMES-248?page=comments#action_35018
---------------------------------------------------------------------
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: Unassigned
Priority: Major
Project: James
Versions:
2.1.3
Assignee:
Reporter: Ralf Hauser
Created: Mon, 5 Apr 2004 11:54 AM
Updated: Wed, 14 Apr 2004 6:46 AM
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
RE: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > Java does not guarantee that finalizers run, and it certainly
> > does not guarantee that they will run before Java decides to
> > garbage collect that object.
> Are you sure?
Yes, but you misunderstood, and my phrasing wasn't clear.
"The Java programming language does not specify how soon a finalizer
will be invoked, except to say that it will happen before the storage
for the object is reused."
In other words, you cannot count on Java to call the finalize method if it
has not yet decided to garbage collect the object. One of the aspects of
garbage collection is determining that an object is no longer reachable, and
the earliest that a finalizer would be called is when that determination has
been made.
The use of a PhantomReference is considered a more reliable approach. That
mechanism is keyed by the determination that an object is no longer
reachable except via a PhantomReference.
See
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/PhantomReference.html
for more details.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify
after successful delivery of retrieved MailImpl
Posted by Kerr Rainey <ke...@rokera.com>.
> Author: Noel J. Bergman
> Java does not guarantee that finalizers run, and it certainly does not guarantee that they will run before Java decides to garbage collect that object.
Are you sure?
Java Language Specification, 12.6 Finalization of Class Instances
"Before the storage for an object is reclaimed by the garbage collector,
the Java virtual machine will invoke the finalizer of that object."
"Before the storage for an object is reclaimed by the garbage collector,
the Java virtual machine will invoke the finalizer of that object."
"The Java programming language does not specify how soon a finalizer
will be invoked, except to say that it will happen before the storage
for the object is reused."
http://java.sun.com/docs/books/jls/second_edition/html/execution.doc.html#44748
Interestingly the first quote says the finalizer method is invoked
before the storage of the object is reclaimed and the second says that
it is sometime before the storage is reused. I'd guess that this is
getting into the nitty gritty of what the garbage collector is actually
doing.
Certainly I'd always assumed that the finalizer of an object would run
eventually, even if it was sometime long after the object was eligible
for garbage collection.
Any comments/docs to the contrary are welcome. I've not used finalizers
heavily so I've not had any problem with them and your comment was at
odds with what I thought to be the case. If I'm simplifying something
and there is something I'm missing, please let me know.
Cheers
Kerr
--
Kerr Rainey - kerr_rainey@rokera.com - http://www.rokera.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl
Posted by "Noel J. Bergman" <no...@devtech.com>.
> When I see variables set to null after their use,
> I think that this programmer does not know Java.
There are good reasons for doing this, but not if the variables are
transient.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify
after successful delivery of retrieved MailImpl
Posted by "Richard O. Hammer" <RO...@EarthLink.net>.
The original issue <http://issues.apache.org/jira/browse/JAMES-248> says:
"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?"
Commenting upon this, Noel wisely asks "Do you have any reason to
believe that there is currently a problem in James?"
I guess that this IS NOT a kind of memory leak. The people who
specified the JVM seem to believe that they have the JVM's memory
managment under control, and they seem to want us Java developers to
leave that problem to them. Generally, I trust the JVM to do garbage
collection using parameters which are known to the JVM.
Generally, all you need to do with a variable name when you are done
with it is to forget it. Just let it fall out of scope, while making
sure of course that your scope is not larger than needed.
When I see variables set to null after their use, I think that this
programmer does not know Java.
Rich Hammer
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify
after successful delivery of retrieved MailImpl
Posted by Kerr Rainey <ke...@rokera.com>.
> One correction... you are not guaranteed that a finalizer will get called.
>
> http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html
Thanks for that, interesting stuff. If I read it correctly though they
seem to be saying that objects aren't guaranteed to be garbage
collected. I'm still assuming that if an object is GC'd it would have
it's finalize method called. The performance issues are interesting also.
Cheers
Kerr
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify
after successful delivery of retrieved MailImpl
Posted by Serge Knystautas <se...@lokitech.com>.
Serge Knystautas wrote:
> Everything would /eventually/ get GC'd... but eventually is a long and
> non-guaranteed time. If you're dealing with something expensive, such
> as file-handles on a server, you'd want to handle this explicitly.
One correction... you are not guaranteed that a finalizer will get called.
http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify
after successful delivery of retrieved MailImpl
Posted by Serge Knystautas <se...@lokitech.com>.
Kerr Rainey wrote:
> OK, yes I understand that you cannot guarantee when an object will be
> garbage collected, but does java not guarantee that everything will be
> garbage collected eventually? Even if that is not until program exit? To
> be honest, I'm not sure about this. I'd certainly hope any reasonable
> implementation would do this. Too expectant?
>
> Obviously if you have expensive resources tied up you probably want to
> guarantee that they get released in a much more timely fashion ;)
Honestly I've lost context of what the resource is you were trying to
release, so I'm just making general comments at this point.
Everything would /eventually/ get GC'd... but eventually is a long and
non-guaranteed time. If you're dealing with something expensive, such
as file-handles on a server, you'd want to handle this explicitly.
I think finalize() is perceived as a "less than ideal" design pattern at
this point. It might be ok if you're dealing with a client app, where
an extra file handle or socket connection could get cleaned up
"eventually." But in a mailet, it's probably something to avoid.
Also, I just find this part very, very interesting... finalize() can
really hurt performance with respect to your garbage collector. Objects
that have a finalize call survive through multiple generations where
they otherwise would get immediately destroyed.
http://www-106.ibm.com/developerworks/java/library/j-jtp01274.html
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify
after successful delivery of retrieved MailImpl
Posted by Kerr Rainey <ke...@rokera.com>.
Noel J. Bergman wrote:
> See: Runtime.runFinalizersOnExit(). There is no guarantee that finalizers
> will be called, unless you use that deprecated and unreliable method.
Thanks for that, not noticed that before, or have since forgotten ;) It
certainly seems like there is a bit of a gap in the spec around this area.
Cheers
Kerr
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl
Posted by "Noel J. Bergman" <no...@devtech.com>.
> does java not guarantee that everything will be garbage collected
> eventually? Even if that is not until program exit?
See: Runtime.runFinalizersOnExit(). There is no guarantee that finalizers
will be called, unless you use that deprecated and unreliable method.
I don't know if there is a guarantee that PhantomReference handling will
occur at JVM shutdown, either. See Runtime.exit(int) for a description of
the exit sequence. But there is also
Runtime.getRuntime().addShutdownHook(), and that could be used.
Martin Cooper raised the same concern, related to code that we are using in
Jakarta Commons. I am looking at the code that I gave to Martin that uses
PhantomReferences, and see where a shutdown hook (JDK 1.3+) could apply. It
should be able to process any remaining PhantomReference instances.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify
after successful delivery of retrieved MailImpl
Posted by Kerr Rainey <ke...@rokera.com>.
>> You mis-understood. Rephrasing, you cannot count on Java to call the
>> finalize method if it has not has not yet decided to garbage collect the
>> object.
>
>
> I would explain it that you cannot guarantee when Java will decide to
> garbage collect /this/ object. Even an explicit call to System.gc() does:
OK, yes I understand that you cannot guarantee when an object will be
garbage collected, but does java not guarantee that everything will be
garbage collected eventually? Even if that is not until program exit? To
be honest, I'm not sure about this. I'd certainly hope any reasonable
implementation would do this. Too expectant?
Obviously if you have expensive resources tied up you probably want to
guarantee that they get released in a much more timely fashion ;)
Cheers
Kerr
--
Kerr Rainey - kerr_rainey@rokera.com - http://www.rokera.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl
Posted by "Noel J. Bergman" <no...@devtech.com>.
> You could try to call System.runFinalization(). However I would
> suggest switching to an active way of cleaning up resources rather
> than relying on finalize().
Yes. Explicit closure or PhantomReference use.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify
after successful delivery of retrieved MailImpl
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>>and [Java] certainly does not guarantee that they will run
>>>before Java decides to garbage collect that object.
>
>>I believe there is a guarantee that the finalize() method will be
>>called on an object before it is garbage collected
>
> You mis-understood. Rephrasing, you cannot count on Java to call the
> finalize method if it has not has not yet decided to garbage collect the
> object.
I would explain it that you cannot guarantee when Java will decide to
garbage collect /this/ object. Even an explicit call to System.gc() does:
"Calling the gc method suggests that the Java Virtual Machine expend
effort toward recycling unused objects in order to make the memory they
currently occupy available for quick reuse. When control returns from
the method call, the Java Virtual Machine has made a best effort to
reclaim space from all discarded objects."
So just because you no longer reference it in your code will System.gc()
get called. You could try to call System.runFinalization(). However I
would suggest switching to an active way of cleaning up resources rather
than relying on finalize().
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > and [Java] certainly does not guarantee that they will run
> > before Java decides to garbage collect that object.
> I believe there is a guarantee that the finalize() method will be
> called on an object before it is garbage collected
You mis-understood. Rephrasing, you cannot count on Java to call the
finalize method if it has not has not yet decided to garbage collect the
object.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify
after successful delivery of retrieved MailImpl
Posted by "Richard O. Hammer" <RO...@EarthLink.net>.
jira@apache.org wrote:
> Java does not guarantee that finalizers run,
I believe this is correct. There is no guarantee that garbage
collection will run, or will run on a given object. But I believe the
following is mistaken
> and it certainly does not guarantee that they will run before Java decides to garbage collect that object.
I believe there is a guarantee that the finalize() method will be
called on an object before it is garbage collected (IF it is garbage
collected).
Rich Hammer
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Noel J. Bergman
Created: Thu, 8 Apr 2004 8:53 AM
Body:
Java does not guarantee that finalizers run, and it certainly does not guarantee that they will run before Java decides to garbage collect that object.
Another approach to cleanup is the use of PhantomReference objects. We may adopt that approach into James, but temporary files in James, created by MimeMessageInputSource, are cleaned up during normal operation as you could see by watching the temp/ directory. I cannot speak for whatever is done in your code.
Do you have any reason to believe that there is currently a problem in James?
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JAMES-248?page=comments#action_28040
---------------------------------------------------------------------
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: Unassigned
Priority: Major
Project: James
Versions:
2.1.3
Assignee:
Reporter: Ralf Hauser
Created: Mon, 5 Apr 2004 11:54 AM
Updated: Thu, 8 Apr 2004 8:53 AM
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
[jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl
Posted by ji...@apache.org.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Serge Knystautas
Created: Fri, 21 May 2004 10:18 PM
Body:
Explicit nulling objects can do exact opposite you intend, i.e., it can make the JVM less efficient at garbage collection.
http://www-106.ibm.com/developerworks/java/library/j-jtp01274.html
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JAMES-248?page=comments#action_35678
---------------------------------------------------------------------
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:18 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
[jira] Closed: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl
Posted by ji...@apache.org.
Message:
The following issue has been closed.
Resolver: Noel J. Bergman
Date: Fri, 16 Apr 2004 8:37 AM
As far as I can see, this is not a defect present in James.
---------------------------------------------------------------------
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, 16 Apr 2004 8:37 AM
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
[jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl
Posted by 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