David Doucette wrote:
> How many msgs/sec have you seen with James for a given size message?
I think you should ask the original poster; I haven't done any
benchmark.
> Have you found a good number to set this at? 300? 1000? I'm sure it
> depends on the type of system, etc.
Sure, it would depend on the hardware used. But in my case, I'm limited
by the max. connection number that can be handled by MySQL. Somewhere on
the Net, I read that the number was 50. Recently I changed James config
so that it has 60 connections; let's see what happens.
> Could you clarify this a bit more? I'm not sure I understand about the
> removal of messages in the spool and the log files issue.
Once I had a problem on the log files after I removed some of the
messages; James kept writing the exceptions on the log files, trying to
find the missing messages. James just kept trying and trying until the
filesystem was filled up. Then I switched to using the database, and
when I removed the messages (from the spool or mailboxes), the
exceptions printed were not so massive.
> When you say it couldn't deliver more than 1MB, what do you mean?
It just meant that my email was rejected (pressing the "Send" button on
the mail client, and then an error message received by the email
client).
> Do you mean you couldn't store more than 1MB in a single column in the
> database?
It's the limitation imposed by the MySQL JDBC driver that I use
(mm.mysql201.jar), and not by MySQL (I guess).
>Does this mean that James doesn't store the attachments in
> the file system when storing messages in the database?
If you use a database for the repositories, then everyting would be
stored in the database; viewed from James' perspective. On the database,
that's implementation dependent.
On MySQL, that's the way it is.
On Postgres, blobs are stored on separate tables. Problem is, Town
doesn't support Postgres; or maybe it's just that the JDBC driver
supplied by Postgres is not quite compatible with the JDBC
specification. Once I tried to use Postgres as the backend,
unfortunately, Town had problems in dealing with attachments; Postgres
uses "object ID" as a pointer to the real blob and Town apparently
didn't handle that properly.
BTW, I'd like to eat my own words; PostgresSpoolRepository.class,
somebody please...?
But it might not be a cure for the attachment problem. I think the POP
implementation in James is the one that needs some fix up. You can try
to have about 1400 messages on your database, and have some of them to
be large enough (300KB). Get them via James POP, and you'd see that your
email client would just time-out (manually removing the messages in the
database table would be needed, and then restarting James).
Well, having big attachments on email is not quite wise; but sometimes,
it could be needed, say, your customers insist.
Oki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
