james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Serge Knystautas" <ser...@lokitech.com>
Subject Re: POP3Server
Date Thu, 13 Sep 2001 05:26:11 GMT

I think you're headed in the right direction, but I don't think we need all
those changes in the mail repository for this performance gain.

A related issue is that the POP3 server implementation doesn't implement the
spec correctly.  You're only supposed to allow 1 POP3 connection at a time,
and that connection locks the mailbox (including new from delivery).

What I think we should do is as soon as a POP3 connection is created is...
1. keep track in the POP3 handler that this mailbox has been opened (and
don't allow another POP3 handler thread to access it until done), and
2. in that connection, keep a list of what messages are in that mailbox.

The first is important to prevent competing connections from
listing/retrieving/deleting concurrently, and deleting the wrong message.
The second also helps with this.  But also, by keeping a cache of what the
message_names are (and I guess the size since that's frequently needed), you
allow the SMTP handler to deliver messages to that mailbox without having
them appear in the POP3 connection.  LIST, RETR, DELE, etc.. commands would
continue to work against the Vector of messages when they first connected.

I think it might even be better to keep the message wrappers themselves in
memory, and improve that class to cache the message size.  Just a thought
though.  I think the total message size might be useful to add to
repositories, since that would allow us to eventually establish quotas, but
for now I don't how big of a deal that is.

Serge Knystautas
Loki Technologies
----- Original Message -----
From: "Oki DZ" <okidz@pindad.com>
To: <james-dev@jakarta.apache.org>
Sent: Thursday, September 13, 2001 12:29 AM
Subject: POP3Server

> Hi,
> I think the stat() method in the POP3Server.java can be made to work
> faster by storing the message names in the userMailbox Vector instead of
> the MailImpl; you don't have to do a retrieve() from the mail
> repository, which means that there would be lesser number of database
> connections used (of course, this implies that there would be a quite lot
> of modification in the rest of the code).
>     private void stat() {
> userMailbox = new Vector();
> userMailbox.add(DELETED);
> Iterator i = userInbox.list();
> if (i != null) {
>     for (;i.hasNext();) {
> String key = (String) i.next();
> userMailbox.addElement(key);
>     }
> }
> backupUserMailbox = (Vector) userMailbox.clone();
>     }
> Adding some methods in the MailRepository interface would be nicer too. In
> the following, I implemented getMessageSize(Vector) method to get the
> total size of messages in a particular user's mailbox. The SQL statement
> would be: select sum(length(message_body)) from Message where ...
>    private void doSTAT(String command,String argument,String argument1) {
>         if (state == TRANSACTION) {
>             long size = 0;
>             int count = 0;
>     String key;
>     Vector keys = new Vector();
>     for (Iterator i = userMailbox.iterator(); i.hasNext();) {
> if (!(key = (String) i.next()).equals(DELETED)) {
>     keys.add(key);
>     count++;
> }
>     }
>             try {
> size = userInbox.getMessageSize(keys);
>                 out.println(OK_RESPONSE + " " + count + " " + size);
> The following are some of the methods I added in MailRepository interface:
>     // Returns message size; the total size of a particular mailbox
>     int getMessageSize(Vector keys) throws MessagingException;
>     // Return message size; the size of an individual message
>     int getMessageSize(String key) throws MessagingException;
>     // Returns message name and its size pairs; it's implementation
>     // made faster by opening a connection once, and then doing a loop
>     // for getting each size of the message (using length(message_body)).
>     Hashtable getMessageSizeList(Vector keys) throws MessagingException;
> Those are useful to speedup the performance of the POP server by
> implementing specific calls to the database directly. The modified
> interface would mean a lot for other repositories though (eg: the file
> repository); ie: lots of modifications.
> Just some ideas of improvement,
> Oki

To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

View raw message