On Wed, 8 Aug 2001, Harmeet wrote:
....
> 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 one is better, I think; once you have the lock server running, it is
applicable on all the spool repositories. All you have to do is to have
the right version of "if (lock(message))" in the spool repositories. It
could become "if (lockServer.lock(message))"; in which lockServer is an
instance of an RMI based Avalon block lock server. I don't know whether
Avalon blocks can be RMI'zed, but if it does, I think it's a nice
solution.
In this configuration, then you'd have a James server (the one which does
the loading of the lock server block, and some other James "clients" which
utilizes the lock server.
> 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
(b) is better.
> If you like the idea, I can do the File Repository part of it over the
> weekend.
I think it's important to be able to switch the kind of spool repositories
without breaking the configuration.
> What do you think ? Does this make sense ?
> Harmeet
(b)? Yes.
Oki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
