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 ji...@apache.org on 2004/04/22 03:45:53 UTC
[jira] Created: (JAMES-269) AvalonMailRepository emits spurious "so we're deleting it... good riddance" messages due to synchronization
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
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: Unassigned
Priority: Trivial
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:44 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Closed: (JAMES-269) AvalonMailRepository emits spurious "so we're deleting it... good riddance" messages due to synchronization
Posted by ji...@apache.org.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Closed: (JAMES-269) AvalonMailRepository emits spurious "so we're deleting it... good riddance" messages due to synchronization
Posted by ji...@apache.org.
Message:
The following issue has been closed.
---------------------------------------------------------------------
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.0RC2
Versions:
2.2.0RC1
2.1.3
2.0a3
Assignee:
Reporter: Noel J. Bergman
Created: Wed, 21 Apr 2004 6:44 PM
Updated: Wed, 21 Apr 2004 7:13 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Reopened: (JAMES-269) AvalonMailRepository emits spurious "so we're deleting it... good riddance" messages due to synchronization
Posted by ji...@apache.org.
Message:
The following issue has been reopened.
---------------------------------------------------------------------
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: Reopened
Priority: Trivial
Project: James
Components:
MailStore & MailRepository
Fix Fors:
2.2.0RC2
Versions:
2.2.0RC1
2.1.3
2.0a3
Assignee:
Reporter: Noel J. Bergman
Created: Wed, 21 Apr 2004 6:44 PM
Updated: Wed, 21 Apr 2004 7:13 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org