The build failure seems to be because of recent changes in the Lock
API/Implemenation. Not sure how to fix this.
I don't really know why the lock API changed. The earlier one seemed be in
use, and a parts of James rely on it. For example see the attached mail.
Also comparing the new Lock implementation from util.concurrent's Mutex, I
realized. that if there is an InterruptedException thrown in the Lock method
the other waiting to acquire threads are not notified. There seems to be one
more problem. the attached comparison could be useful.
<acquire> method of util.concurrent's Mutex.
----------------------------------------------------------
public void acquire() throws InterruptedException {
if (Thread.interrupted()) throw new InterruptedException();
synchronized(this) {
try {
while (inuse_) wait();
inuse_ = true;
}
catch (InterruptedException ex) {
notify();
throw ex;
}
}
}
------------------------------------------
here is the comparable <lock> method from avalon.util's Lock.
-------------------------------------
public final void lock()
throws InterruptedException
{
synchronized (this) {
while (this.isLocked) this.wait();
this.isLocked = true;
}
}
--------------------------------------
I think one should reuse a solid concurrency management library if it is
available. I think one should consider Doug Lea's package as a reasonable
and stable candidate. Anyway not sure how to fix the James build in a safe
manner, hope someone knows how to.
Harmeet
----- Original Message -----
From: "Peter Donald" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, April 07, 2001 2:44 AM
Subject: [GUMP] Build Failure - James
> ----------------------------------------------------
> This email is autogenerated from the output from:
> <http://jakarta.apache.org/builds/gump/2001-04-07/jakarta-james.html>
> ----------------------------------------------------
>
> Buildfile: build.xml
>
> init:
>
> prepare:
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-james/build
>
> prepare-src:
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-james/build/src
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-james/build/classes
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-james/build/lib
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-james/build/conf
> [copy] Copying 1 file to
/home/rubys/jakarta/jakarta-james/build/src/org/apache/james
> [copy] Copying 1 file to /home/rubys/jakarta/jakarta-james/build/conf
>
> compile:
> [javac] Compiling 119 source files to
/home/rubys/jakarta/jakarta-james/build/classes
> [javac]
/home/rubys/jakarta/jakarta-james/src/org/apache/james/mailrepository/Avalon
MailRepository.java:23: Class org.apache.avalon.util.LockException not found
in import.
> [javac] import org.apache.avalon.util.LockException;
> [javac] ^
> [javac]
/home/rubys/jakarta/jakarta-james/src/org/apache/james/mailrepository/TownSp
oolRepository.java:30: Class org.apache.avalon.util.LockException not found
in import.
> [javac] import org.apache.avalon.util.LockException;
> [javac] ^
> [javac]
/home/rubys/jakarta/jakarta-james/src/org/apache/james/mailrepository/Avalon
SpoolRepository.java:41: Wrong number of arguments in method.
> [javac] if (lock.lock(s)) {
> [javac] ^
> [javac]
/home/rubys/jakarta/jakarta-james/src/org/apache/james/mailrepository/Avalon
SpoolRepository.java:61: Wrong number of arguments in method.
> [javac] if (lock.lock(s)) {
> [javac] ^
> [javac]
/home/rubys/jakarta/jakarta-james/src/org/apache/james/smtpserver/SMTPHandle
r.java:135: Note: The method java.lang.String readLine() in class
java.io.DataInputStream has been deprecated.
> [javac] while (parseCommand(in.readLine())) {
> [javac] ^
> [javac]
/home/rubys/jakarta/jakarta-james/src/org/apache/james/smtpserver/SizeLimite
dSMTPHandler.java:148: Note: The method java.lang.String readLine() in class
java.io.DataInputStream has been deprecated.
> [javac] while (parseCommand(in.readLine())) {
> [javac] ^
> [javac] Note: 2 files use or override a deprecated API. Please
consult the documentation for a better alternative in each case.
> [javac] 4 errors, 1 warning
>
> BUILD FAILED
>
> /home/rubys/jakarta/jakarta-james/build.xml:175: Compile failed, messages
should have been provided.
>
> Total time: 36 seconds
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
