You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Peter M. Goldstein" <pe...@yahoo.com> on 2002/07/28 23:43:53 UTC

RE: [Bug 11243] New: - SMTP server against DB repository doesn't scale with message size

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: bugzilla@apache.org [mailto:bugzilla@apache.org]
> Sent: Sunday, July 28, 2002 2:04 PM
> To: farsight@alum.mit.edu
> 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: james-dev@jakarta.apache.org
>         ReportedBy: farsight@alum.mit.edu
> 
> 
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>