I agree. I think the current spool repository implementations are overloaded as they provide queueing and indexed store/retrieve functionality. This leads to some interesting quirks in the code for dequeueing functionality messages, namely that the accept(long delay) retrieves the key of the next message, reads the message from the repository (so that it can check whether the message is a retry and if it's retry is due), then it returns the key to the caller so that the caller can reread the message from the store.
I'd like to propose that the error/retry mechanism is separated from the main spool queue mechanism and that the spool queue becomes a pure queue as you suggest. Unfortunately this is a non-trivial change and I haven't fully investigated what it entails. Cheers Steve > -----Original Message----- > From: Jerry Crone [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 30, 2002 9:26 AM > To: [EMAIL PROTECTED] > Subject: Processing messages from spool > > > I have been looking at the code that takes messages from the > spool and processes them. Assume that I am running a > production server with more than 300k messages per day, and > that there are 2,000 messages on the spool. It seems that > AvalonMailRepository.list() is called for every message that > is processed, creating a new HashSet. This would mean: > 1) a lot of objects are created and GCed soon thereafter > 2) if the spool always has messages, how could you be > optimistic that the last message in the HashSet would be processed? > > What is the problem of using a queue for the keys; e.g., a > single instance of Vector? The keys for messages being > processed would have been removed from the Vector; however, > their corresponding members would still be in the > ObjectRepository and StreamRepository until their processing > is done. If James is shutdown and restarted, the keys would > be included in the new queue. > > I want to emphasize that I am not being critical; I am > ignorant of the discussions that occurred while James was > being designed. You all have done a lot of excellent work. > > P.S. I incorporated Shilpa's new classes and code mods. It > increased throughput by more than 30% (using files for both > spool and inboxes). > > Have a good day, Jerry Crone > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
