On Wed, 8 Aug 2001 18:01, Harmeet wrote:
> I think what would be best is to have locking not tied to a process. This
> would allow scalability.
Agreed - the locking mechanism should probably be implemented independently
of java thread locking.
>
> This could be done in several ways.
> a) For File System based repositories, it would be a matter of changing the
> extension of message a spool thread is working on and renaming to orig if
> spool processing fails.
>
> for example
> File spoolFile = ....
> boolean reset = false;
> try {
> spoolFile.renameTo(<spooled file with status in-process>)
> catch ( Throwable t) {
> reset = true;
> throw t;
> } finally {
> if ( reset )
> <spooled file with status in-process>.renameTo(spoolFile);
> }
> The same thing could be done in db, by setting a 'in-process' flag for
> spool message.
> The spool threads will pick and process messages that are not being
> processed.
Just thinking...
Would it be possible/useful to separate the SpoolRepository implementation
from the MailRepository; so that a SpoolRepository delegates calls to a
MailRepository contained within? The SpoolRepository implementation would
handle locking/respooling of message ids, but not the physical storage of the
mail.
Possible benefits:
a) keep the MailRepository cleaner, since it wouldn't have to handle locking,
timeouts etc.
b) allow us to mix-and-match Spool implementations with MailRepository
implementations (eg - use a db for spool locking, but a file-based
MailRepository)
c) allow us to use a locking mechanism like the current one (using a Lock
object) for single machine implementations (if this was more performant).
d) later we can switch to a dedicated lock-server component more easily.
>
> Another way could be to
> b) have a lock-server process that controls object locking and lifetime.
> Basically lock facility could be leased out for sometime, and renewed or
> staus success/failed returned. Lock Sever solution is nice and general but
> it may be an overkill. It may however be a good Avalon Block to have. It is
> a nice Server Piece to have when you need it.
>
> This would allow multiple processes to process the spool messages.
> This would not be as fast as the current single process based locking, but
> I think the spool processing does not need to be fast, but it does need to
> be scalable and correct (i.e one email for one message)
> This can be very scalable, one could have multiple instances of James
> behind a load-balancer/virtual address, to service high volume.
>
> Here is a proposal for your vote.
> Let us implement method (a) to allow multiple processes of James to process
> same spoll db.
+1
- I reckon this is the right direction, whether we split the SpoolRepository
and MailRepository implementations or not.
>
> If you like the idea, I can do the File Repository part of it over the
> weekend.
>
> What do you think ? Does this make sense ?
> Harmeet
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
