>From [EMAIL PROTECTED]
From: David Doucette <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
X-Sender: [EMAIL PROTECTED]
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> As for the reason James slows down as the spool grows... it's because each
> time the spooler thread goes to grab a message from the db, it gets the
> message_id and last_updated (and maybe another field or two) of ALL messages
> in the spool to determine what message is not locked, to determine which it
> should grab. This isn't really avoidable as the DB query won't tell you
> which messages are locked, so you have to get a list, and try one by one to
> acquire an in-memory lock on that message. With more control over the
> result set, you could set it up to read only 20 records, and only read the
> remaining 4980 if all those 20 records were locked. That would obviously
> boost performance significantly, but again, we would need probably raw JDBC
> access, not Town (or Turbine or other OR mapping software).
Could you explain this a bit more. How does the locking work in James?
Is a flag set in the database or is it based on locking the record
through some other method? I'm not sure what you mean by in-memory lock
and would like to learn. :)
Also, doesn't the SpoolManager just do one read and then manage delivery
threads until the records it has read are all sent? Or am I confusing
SpoolManager with RemoteDelivery?
> There are some quick thoughts. I usually set my delivery threads between 5
> and 15 depending on how many messages I'm sending out. The only real
> benefit I've found with increasing threads is to overcome the latency of
> remote servers. If you're delivering messages to a local machine, having 2
> or 15 threads really makes little effect on throughput.
Yeah, I was thinking as I read your reply that James must do a lot of
thrashing when it is doing local delivery. Having a different disk for
the Spool and the Mailboxes (if possible) might help?
Thanks,
David
>
> Serge Knystautas
> Loki Technologies
> http://www.lokitech.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
