The following comment has been added to this issue:
Author: Noel J. Bergman
Created: Fri, 21 May 2004 10:51 PM
Body:
> james at the end of doPASS does a stat() that brings all
> messages in their entirety (not just referenced by their
> key)
doPASS()
-> stat()
-> userInbox.retrieve(key);
The file and dbfile stores, do not load the entire message into memory. The db store
currently does.
> Why not wait with the retrieve (from file or JDBC) until
> the MUA's doRETR arrives?
As explained in JAMES-248 and again now, that is what does happen. Have you tried
using a dbfile store?
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JAMES-288?page=comments#action_35680
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JAMES-288
Here is an overview of the issue:
---------------------------------------------------------------------
Key: JAMES-288
Summary: memory efficient retrieval
Type: Improvement
Status: Unassigned
Priority: Major
Project: James
Components:
POP3Server
Versions:
2.1.3
Assignee:
Reporter: Ralf Hauser
Created: Tue, 18 May 2004 9:38 AM
Updated: Fri, 21 May 2004 10:51 PM
Environment: redhat 9
Description:
After analyzing what happens when I retrieve mail, I noticed that james at the end of
doPASS does a stat() that brings all messages in their entirety (not just referenced
by their key) into the JVM irrespective whether they are already read or not.
later the MUA then will doRETR() selected messages.
It appears to me that this may lead to problems if either messages are large or with
many simultaneous user sessions.
Why not wait with the retrieve (from file or JDBC) until the MUA's doRETR arrives?
If the MUA first only gets a few hundred header characters and then comes back again,
one might accomodate this by on-demand-insertion or rather upgrade in doRETR. This
previously happened in stat() with
userMailbox.addElement(mc);
What do you think?
---------------------------------------------------------------------
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]
