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

[bu...@apache.org]

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>