The following is a summary of the problem.
1) It occurs ONLY when using JDBCSpoolRepository for RemoteDelivery
2) If there are more items in the spool than fit in the cache, it is
possible to delay delivery for messages that ought to be delivered.
3) If iterating through the cache takes more than one second, it is
possible to spinloop.
There are a variety of approaches. One is to fix it. So far neither
Stefano nor I (not that I've had much time to look, but he spent all day on
it), have come up with a trivial fix. The types of fixes for this code
would push back release for weeks. At that point I might as well implement
the right long-term change, planned for the next release, rather than a
one-off bandaid to resolve v2.3.
Alternatively, we could add a configuration parameter for the hardcoded
timeout value (there is already one for the cache size), document the
potential problem, and release JAMES v2.3.
I do not want to just remove the cache, which is one of Stefano's
suggestions. The cache prevents JAMES from crashing when the message
arrival rate is higher than it can process. Throwing OOMs and possibly
discarding messages in the process is not acceptable.
Recognize that part of the problem is the conflating of the RemoteDelivery
spool and the main pipeline spool, which have different requirements, since
the former applies scheduling on top of the spool. Again, that's on the
roadmap to change, but wasn't planned for v2.3.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
