> Using 100 delivery threads, each delivering 100 1k mails
> to James with new connections every time Java bugs out at
> about mail 1200, out of memory, ps shows a gazillion James
> threads. Re-using a single connection for each thread lets
> 10,000 11k mails be delivered in 690 seconds on my hardware,
> however James does freak out at this too, it stops accepting
> connections and I don't yet know why.
FWIW, I seem to recall that there is an error where you if increase the
threads in one place, but not in another, there isn't a good configuration
check; it just dies. So if you tried 100 receiving threads, that might be
the problem.
Assuming that you just had your regular receiving threads, then in your
first case you had 100 threads competing to attach to each server thread,
each one delivering a single e-mail and disconnecting. So you'd have
created 1200 or so connections (and handlers and other objects, plus around
6000 scheduler entries). In the second case, you have 100 delivery threads,
but each one keeps its connection live until it is finished sending 100
e-mails.
All of the current handlers have basically the same loop:
final PeriodicTimeTrigger trigger = new PeriodicTimeTrigger(
timeout, -1 );
scheduler.addTrigger( triggerId, trigger, this );
while (parseCommand(reader.readLine())) {
scheduler.resetTrigger(triggerId);
}
scheduler.removeTrigger(triggerId);
Just so you know, unless you specify a connection timeout for the handler,
the default is 30 minutes (1800000 ms). The defaults in james-config are:
RemoteManager: 1 minute ( 60000 ms)
POP3: 2 minutes (120000 ms)
SMTP: 6 minutes (360000 ms)
NNTP: 2 minutes (120000 ms)
If I am counting properly, SMTP generates 5 scheduler entries per e-mail
(initial, HELO, MAIL FROM, RCPT TO, DATA), plus additional entries per
20,000 bytes of content. 10K e-mails would have put 60K scheduler entries
into the queue, and it wouldn't even start to remove them until after the
first 36K entries. In contrast, there would be exactly one watchdog object.
Plus there are other objects that might lend themselves to object pooling,
if we find that to be an issue.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
