james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@apache.org
Subject [jira] Closed: (JAMES-104) 100 processor usage if RemoteDelivery uses more then 1 thread
Date Sun, 06 Jun 2004 20:49:54 GMT
Message:

   The following issue has been closed.

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/JAMES-104

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: JAMES-104
    Summary: 100 processor usage if RemoteDelivery uses more then 1 thread
       Type: Bug

     Status: Closed
 Resolution: FIXED

    Project: James
 Components: 
             James Core
   Versions:
             2.1

   Assignee: 
   Reporter: Hontvari Jozsef

    Created: Tue, 29 Apr 2003 7:54 AM
    Updated: Sun, 6 Jun 2004 1:48 PM
Environment: Operating System: All
Platform: All

Description:
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.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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


Mime
View raw message