All,
Personally I find this a really troubling bug. Seems like database repository behavior should be more, not less, scalable than file repository behavior. I'd like to collect info from anyone who's seen it. I've noticed at least a couple of places in the code base that may be contributing to this behavior, most notably the writeTo(OutputStream os) method in MimeMessageWrapper.java and the similar code in getMessageSize() in MimeMessageJDBCSource. I'm going to devote some effort starting early next week to try and nail this one. Any thoughts or suggestions would be appreciated. --Peter > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Sunday, July 28, 2002 2:04 PM > To: [EMAIL PROTECTED] > Subject: DO NOT REPLY [Bug 11243] New: - SMTP server against DB repository > doesn't scale with message size > > 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]>
