DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11243>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11243 SMTP server against DB repository doesn't scale with message size Summary: SMTP server against DB repository doesn't scale with message size Product: James Version: 2.0a3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: SMTPServer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I was kind of surprised that this one didn't make it into the bug system yet, so I'm submitting it. Comments lifted off the james-user mailing list. The original submission: > System: > Dedicated machine. > Win2000 Professional SP2 > 500Mhz > 256MB RAM > James 2.0a3 > Connecting to MSSQL 2000 SP2 for message storage and users/lists, with > the latest SQL JDBC driver from Microsoft. > > Config: > No limit on message size > Increased SMTP timeout to 24 minutes > > Problem: > > 10MB messages take about 12 minutes to process through the system with 100% > CPU, with no other activity/messages to process, which is ok. But, I > am having a problem with messages over 15MB. > > At the start of the processing of the message the James goes to 100% > CPU for > 10 secs, 30% for 15 secs then 100% again for 100 secs. Then drops back > to idle. The message then stays in the spool directory and does not > get processed. Restarting James still has no affect. > > I realise that sending messages of this size in general everyday use > is not > one of the best ways to work, but every now and again there is a need > to send a large file by mail. > > What is the largest message that anyone has processed through James? > Has anyone else come across this, and if so is there something I can > to can > do? > > Thank you in advance > > James Gooding and Serge's response: >I've seen similar performance problems, and it seems to be combination of >JDBC and JavaMail. I tried to use some performance analysis tools to spot >what the slow down was, and never got anywhere. I also had weird behavior >running inside Avalon/James (compared to running a stand-alone test) where >inside Avalon was taking 5 times as long. > >Anyway, yes that is unfortunately not surprising, and nobody has been able to >crack this performance nut. The file repository is much faster if you do >need to support large messages like that. > >Serge Knystautas -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
