David Doucette wrote:
> I'm new to James, so I didn't realize each delivery thread reads from
> the database. I assumed the message was passed to the thread. What is
> passed to the thread so it knows which message to get out of the
> database? Or does it just grab the next one that hasn't already been
> sent?
I'm not so clear what would happen if the messages are already in the
spool (the messages that are ready to be sent out)... but on SMTP and
POP connections, basically James provides (or tries to provide) one
thread for one message. A message needs to be retrieved from or stored
to some storage, and it would need a database connection each.
> My first impression is that this performance bottleneck could be avoided
> by having one thread (or even more than one thread to improve
> performance against the database) reading messages from the database and
> putting them in a queue in memory.
It wouldn't be acceptable to have the queue on memory, I think; 2 MB
attachment on each email, and you have your clients send 100 messages.
You'd run out your swapspace pretty fast I believe.
>The delivery threads could access
> this same shared queue and pull the data from there instead of reading
> it from the database. The advantage of this would be not requiring a
> connection to the database for every delivery thread, so you could have
> more delivery threads running.
I think if James provides a way of assigning priorities to the running
threads, that would be great. The max. database connection number is not
quite the issue, the apparent (ie: based on gut feeling benchmark) James
performance is. So I think, if the threads that handle SMTP connections
from _mail_clients_ (ie: from inside network) and the POP handlers could
be given higer priorities than the other threads, James would
(apparently) run faster; ie: when you need the services (SMTP or POP),
they are there.
> In general, however, connection pooling is a good thing! I've been
> immersed in coding such things for a week straight now, so it is all
> very fresh in my mind. :)
Connection pooling wouldn't increase the max. database connection that
can be handled by a particular server, right? Sure, it would make the
server run faster by not always opening and closing the database
connection for each connection request.
> Did you remove messages that had already been sent?
No. Definitely not. (I believe that such an effort would be quite
improbable. :-)
>If so, I'm curious
> why James is looking for messages that have already been sent.
The messages were not yet sent; they were in the error state, or already
in the users' mailboxes.
> I'm initially interested in James for SMTP more than POP3, but since I'm
> planning on using it for POP3 down the road, this kind of troubles me.
If you need _only_ SMTP and POP, then use sendmail and pop3d; they are
more robust (already in version 8.x) and tons faster (implemented in C).
Once I tried to send an email with a 26MB attachment (jdk1.3.jar),
sendmail could do it without choking, and retrieving was painless.
The interesting thing on James is the mailet feature; you could _do_
something with the messages before they reach the spool or repositories;
you could do more than just applying address filter.
> Is it merely the size of some of the messages that is the problem, or
> does the number of messages in a mailbox/in the database matter??
Both.
Once I tried to have a 7MB attachment (got split into 300KB-each
messages by Outlook Express); retrieving was like forever. Then I had
1400 messages sitting on my mailbox; the POP handler timed out.
> To the rest of the group, is this a known problem??
You didn't believe me, did you?
> Even if you can control whether you put attachments on your outgoing
> emails, you can't control whether someone sends you a large one. That's
> what makes the POP3 problem worse than not being able to send large
> attachments (when using the database, not the file system).
Since the JDBC driver rejects large attachments, it means that my mail
server couldn't receive large email. It seems that for James, size does
matter.
Oki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
