[prev in list] [next in list] [prev in thread] [next in thread] 

List:       james-dev
Subject:    DO NOT REPLY [Bug 19418] New:  -
From:       bugzilla () apache ! org
Date:       2003-04-29 7:54:35
[Download RAW message or body]

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=19418>.
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=19418

100 processor usage if RemoteDelivery uses more then 1 thread

           Summary: 100 processor usage if RemoteDelivery uses more then 1
                    thread
           Product: James
           Version: 2.1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: James Core
        AssignedTo: james-dev@jakarta.apache.org
        ReportedBy: hontvari2@solware.com


If the RemoteDelivery mailet was configured to use more then one delivery 
threads, then James causes 100% processor usage. The 100% processor usage 
appears a few minutes after James started.
A detailed analysis from Cameron Braid on 2003-04-14, James User's list:

I found the same problem, and after much painful debugging, tracked it to
the avalon AvalonMailRepository / AvalonSpoolRepository classes... Sorry but
my memory is a bit vague since it was a few weeks ago, and since then, we
have aborted the James approach, in favour of a EZML or some other lmailing
list manager.  We were sending a weekly mailing list of 160,000+ emails

The problem was when there were more than 1 remote delivery threads.

It was to do with the threads waking each other up, while waiting the
accept(long delay) block.

The internal code caused the first thread to iterate through the messages in
the spool to determine the minimum time to wait, then it executed
wait(timeToWait).

The second (or any other thread) comes along, and goes through the same
process, however, it awakens the other threads, due to the lock(s) call.
Thereby causing a continual state of insomnia.

I havn't found a soloution, though my thoughts are to change the way the
waiting and wakening happens.  I would stop each and every remote delivery
thread from going through this process, and instead, have a singe thread
who's job it is to keep track of the wait time, and waken the threads then
it knows there is work to do.

I hope this can help.  I can look into my memory a little bit more, if some
more clarification is required.

Cameron.

---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]