james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harmeet Bedi" <hb...@yahoo.com>
Subject Re: Potential problem in RemoteDelivery.
Date Sun, 18 Mar 2001 01:41:21 GMT
I take this back. Seems fine.  :-)

The SpoolRepository's <accept> method seems to lock the object up for
processing only by the thread that called <accept>.
If another thread attempts to grab the same object it fails, because there
is a prexisting lock. In affect the locking provides a sort of
'some-operation-in-progress-so-unavaliable' state.

The lock is released on invocation of MailRepository's <remove> method.

The RemoteRepository seems to works beautifully, but a repository that does
not follow the specific locking semantics could break. The locking semantics
seem to have been very well thought out, but I wish there was weeker
coupling between Repository and RemoteDelivery, and/or better documentation
of locking contract.

Harmeet
----- Original Message -----
From: "Harmeet Bedi" <hbedi@yahoo.com>
To: <james-dev@jakarta.apache.org>
Sent: Saturday, March 17, 2001 2:29 PM
Subject: Potential problem in RemoteDelivery.


> It looks like there could be some multithreading issues with remote
> delivery.
>
> The initialization of remote delivery can take "deliverThreads" paramter.
> The default value is 1. As long as the value is 1, there does not seem to
be
> a problem.
>  If multiple threads are spawned, then they all operate on the same remote
> delivery object. The variables shared and available to different threads
may
> not be locked in a safe manner.
>
> As an example if there are 2 threads spawned to do Remote Delivery, they
> operate on the same outgoing SpoolRepository.
> The run method has this code from line 299.
> -------------
>                 String key = outgoing.accept(delayTime);
>                 log(Thread.currentThread().getName() + " will process mail
"
> + key);
>                 MailImpl mail = outgoing.retrieve(key);
>                 deliver(mail, session);
>                 outgoing.remove(key);
>
> There seems to be a potential that a message can be sent by 2 threads
> separately. Does that seem possible to you or am I delusional.
>
> If there is a problem, some ideas to fix it are
> - spool repository have an in progress state, so that multiple threads
don't
> process an entry that is being processed.
> - Another way could be to arrange the repository such that each worker
> thread gets a separate part of repository to process. One way it worked
for
> me in the past was to do a modulus on the id of a to-process entity with
the
> number of processing threads. Depending on the value of the mod, hand the
> processing to appropriate worker thread. This makes for a fast and simple
> system, unfortunatly not as beautiful.
> There must be other ways, I could be raising a false alarm, etc.
>
> Please let me know if this is a false alarm.
> Harmeet
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org


Mime
View raw message