Message:

   The following issue has been closed.

   Resolver: Noel J. Bergman
       Date: Wed, 21 Apr 2004 6:49 PM

Changed log level to debug.
---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/JAMES-269

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: JAMES-269
    Summary: AvalonMailRepository emits spurious "so we're deleting it... good 
riddance" messages due to synchronization
       Type: Bug

     Status: Closed
   Priority: Trivial
 Resolution: FIXED

    Project: James
 Components: 
             MailStore & MailRepository
   Fix Fors:
             2.2.0RC1
   Versions:
             2.0a3
             2.1.3
             2.2.0RC1

   Assignee: 
   Reporter: Noel J. Bergman

    Created: Wed, 21 Apr 2004 6:44 PM
    Updated: Wed, 21 Apr 2004 6:49 PM

Description:
If you use AvalonMailRepository, especially if you use AvalonSpoolRepository, and you 
have a lot of active threads, you are likely to see quite a few:

ERROR mailstore: Exception retrieving mail: java.lang.RuntimeException: Exception 
caught while retrieving an object, cause: java.io.FileNotFoundException: 
/path/xxx.Repository.FileObjectStore (No such file or directory), so we're deleting 
it... good riddance!

People have seen, and asked, about this in the past, so I am going to document why 
this happens:

AvalonSpoolRepository.accept() clones the key set and iterates over it.  That method 
is synchronized, but remove(String key) is not.  So one thread starts running in 
accept, clones the key set, and starts iterating over it.  Meanwhile, another thread 
finishes processing that message and decides to remove it.  Since remove is not 
synchronized, the file is removed from the repository and the live key set, but the 
key is still present in the cloned key set, and if the accept() method tries to 
retrieve(String) that message, it will find that it is removed.

We could synchronize remove(String), but it does not appear that there is any point to 
doing so, and why would we want to hold up removing a message while waiting for 
another thread to find a message to process?

The same situation occurs in the JDBC repository, and is logged at debug level rather 
than error level.  AvalonMailRepository should also have the logging level changed.


---------------------------------------------------------------------
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to