You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Harmeet Bedi <hb...@yahoo.com> on 2001/04/08 00:35:26 UTC
[GUMP] Build Failure - James and Lock related changes
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" <do...@apache.org>
To: <ja...@jakarta.apache.org>
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: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: [GUMP] Build Failure - James and Lock related changes
Posted by Berin Loritsch <bl...@apache.org>.
Harmeet Bedi wrote:
>
> Added previous version of org.apache.avalon.util.Lock to package
> org.apache.avalon.james.util
>
> The build shoud go ok now. Hopefully the duplication in Lock.java files will
> get removed and exist only under Avalon. For now it gets the build going and
> removes block on other work.
OK, but keep in mind the old version doesn't work under severe load--even on
single processor machines. If JAMES can quickly be reworked to handle this
new class, then it should be done.
In a Servlet environment, on an Athlon 750 with 256 MB RAM, Sun JDK 1.3.0_01
HotSpot "Server", Windows 2000, I got the Lock failure (exhibited as race
conditions that should have clearly been handled by the lock) with as few
as 6 concurrent threads bombarding the server every 500 ms.
To me this is unnecceptible. I want Cocoon 2 to be able to handle the type of
load that Apache.org will see, or Slashdot, and have performance degrade
gracefully instead of intermittently sending broken links due to concurrency
issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [GUMP] Build Failure - James and Lock related changes
Posted by Harmeet Bedi <hb...@yahoo.com>.
Added previous version of org.apache.avalon.util.Lock to package
org.apache.avalon.james.util
The build shoud go ok now. Hopefully the duplication in Lock.java files will
get removed and exist only under Avalon. For now it gets the build going and
removes block on other work.
Harmeet
----- Original Message -----
From: "Harmeet Bedi" <hb...@yahoo.com>
To: <ja...@jakarta.apache.org>; <av...@jakarta.apache.org>
Sent: Saturday, April 07, 2001 3:35 PM
Subject: [GUMP] Build Failure - James and Lock related changes
> 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" <do...@apache.org>
> To: <ja...@jakarta.apache.org>
> 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: james-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
----------------------------------------------------------------------------
----
> ---------------------------------------------------------------------
> 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
Re: [GUMP] Build Failure - James and Lock related changes
Posted by Harmeet Bedi <hb...@yahoo.com>.
Added previous version of org.apache.avalon.util.Lock to package
org.apache.avalon.james.util
The build shoud go ok now. Hopefully the duplication in Lock.java files will
get removed and exist only under Avalon. For now it gets the build going and
removes block on other work.
Harmeet
----- Original Message -----
From: "Harmeet Bedi" <hb...@yahoo.com>
To: <ja...@jakarta.apache.org>; <av...@jakarta.apache.org>
Sent: Saturday, April 07, 2001 3:35 PM
Subject: [GUMP] Build Failure - James and Lock related changes
> 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" <do...@apache.org>
> To: <ja...@jakarta.apache.org>
> 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: james-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
----------------------------------------------------------------------------
----
> ---------------------------------------------------------------------
> 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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [GUMP] Build Failure - James and Lock related changes
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
I think we should keep James using Avalon's utilities, ie Lock. If there
is a problem with them, the change should happen at the Avalon level.
So, someone needs to sit down and hack through James updating the locks.
No promises!
By the way, I would prefer to get Gump build errors than have duplicated
lock code.
Charles
Harmeet Bedi wrote:
>
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> > The Lock implementation DID NOT WORK in its previous form. For some
> reason,
> > when we had one Lock object handle the locks for multiple objects, the
> Lock
> > would not prevent access. This caused some concurrency issues in the Pool
> > implementations. The API was changed to lock() and unlock() with no
> parameters.
> > canLock() and isLocked() were not implemented, as I didn't think they were
> > truly useful. They can be added back in, but without ANY params. I was
> > focusing on getting something that really worked.
> >
> > I did post an email about this to the Avalon Dev list when I committed it,
> > but it looks like noone read it.
>
> I did read it, but did had no cycles to follow up or think about the impact.
> I have for now added the old Avalon Lock Classes to James. This is a stopgap
> measure otherwise James would suffer from the same problems you found in
> Cocoon. James does seem to rely on the previous Lock API. Maybe the same API
> can be built in some other object using the new Lock implementation.
>
> >
> > If we want to adopt the aquire()/release() names, it's nothing but a name
> > thing. The contents change with the InterruptedException is excellent,
> > and can help prevent some deadlocks. I will incorporate that.
> >
> > But lets vote on the "Class : Method" names:
> >
> > 1) Mutex : aquire()/release()
> > 2) Lock : lock()/unlock()
> >
> > I have no qualms or preferences about either--I just want this thing to
> > work properly.
>
> Names don't matter that much however if Avalon can use or reuse a standard
> package, than the same names should be mentained. Well my vote is not
> important and in any case it is 0.
>
> >
> > > 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.
> >
> > OK. I was working on what was already in Avalon. If there is a solid
> > concurrency management library available with a compatible license, then
> > go for it. Note, we did have someone express interest in donating or
> > developing a number of classes that would fill this need.
>
> I make lots of multithreading mistakes. Would prefer to rely on a well
> tested, widely reviewed and fast library. But that is sometimes a chicken
> and egg problem. Not sure if there is a need for a new implementation, but
> if there is, good to get it done and available as part of Avalon. :-)
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [GUMP] Build Failure - James and Lock related changes
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
I think we should keep James using Avalon's utilities, ie Lock. If there
is a problem with them, the change should happen at the Avalon level.
So, someone needs to sit down and hack through James updating the locks.
No promises!
By the way, I would prefer to get Gump build errors than have duplicated
lock code.
Charles
Harmeet Bedi wrote:
>
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> > The Lock implementation DID NOT WORK in its previous form. For some
> reason,
> > when we had one Lock object handle the locks for multiple objects, the
> Lock
> > would not prevent access. This caused some concurrency issues in the Pool
> > implementations. The API was changed to lock() and unlock() with no
> parameters.
> > canLock() and isLocked() were not implemented, as I didn't think they were
> > truly useful. They can be added back in, but without ANY params. I was
> > focusing on getting something that really worked.
> >
> > I did post an email about this to the Avalon Dev list when I committed it,
> > but it looks like noone read it.
>
> I did read it, but did had no cycles to follow up or think about the impact.
> I have for now added the old Avalon Lock Classes to James. This is a stopgap
> measure otherwise James would suffer from the same problems you found in
> Cocoon. James does seem to rely on the previous Lock API. Maybe the same API
> can be built in some other object using the new Lock implementation.
>
> >
> > If we want to adopt the aquire()/release() names, it's nothing but a name
> > thing. The contents change with the InterruptedException is excellent,
> > and can help prevent some deadlocks. I will incorporate that.
> >
> > But lets vote on the "Class : Method" names:
> >
> > 1) Mutex : aquire()/release()
> > 2) Lock : lock()/unlock()
> >
> > I have no qualms or preferences about either--I just want this thing to
> > work properly.
>
> Names don't matter that much however if Avalon can use or reuse a standard
> package, than the same names should be mentained. Well my vote is not
> important and in any case it is 0.
>
> >
> > > 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.
> >
> > OK. I was working on what was already in Avalon. If there is a solid
> > concurrency management library available with a compatible license, then
> > go for it. Note, we did have someone express interest in donating or
> > developing a number of classes that would fill this need.
>
> I make lots of multithreading mistakes. Would prefer to rely on a well
> tested, widely reviewed and fast library. But that is sometimes a chicken
> and egg problem. Not sure if there is a need for a new implementation, but
> if there is, good to get it done and available as part of Avalon. :-)
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: [GUMP] Build Failure - James and Lock related changes
Posted by Harmeet Bedi <hb...@yahoo.com>.
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
> The Lock implementation DID NOT WORK in its previous form. For some
reason,
> when we had one Lock object handle the locks for multiple objects, the
Lock
> would not prevent access. This caused some concurrency issues in the Pool
> implementations. The API was changed to lock() and unlock() with no
parameters.
> canLock() and isLocked() were not implemented, as I didn't think they were
> truly useful. They can be added back in, but without ANY params. I was
> focusing on getting something that really worked.
>
> I did post an email about this to the Avalon Dev list when I committed it,
> but it looks like noone read it.
I did read it, but did had no cycles to follow up or think about the impact.
I have for now added the old Avalon Lock Classes to James. This is a stopgap
measure otherwise James would suffer from the same problems you found in
Cocoon. James does seem to rely on the previous Lock API. Maybe the same API
can be built in some other object using the new Lock implementation.
>
> If we want to adopt the aquire()/release() names, it's nothing but a name
> thing. The contents change with the InterruptedException is excellent,
> and can help prevent some deadlocks. I will incorporate that.
>
> But lets vote on the "Class : Method" names:
>
> 1) Mutex : aquire()/release()
> 2) Lock : lock()/unlock()
>
> I have no qualms or preferences about either--I just want this thing to
> work properly.
Names don't matter that much however if Avalon can use or reuse a standard
package, than the same names should be mentained. Well my vote is not
important and in any case it is 0.
>
> > 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.
>
> OK. I was working on what was already in Avalon. If there is a solid
> concurrency management library available with a compatible license, then
> go for it. Note, we did have someone express interest in donating or
> developing a number of classes that would fill this need.
I make lots of multithreading mistakes. Would prefer to rely on a well
tested, widely reviewed and fast library. But that is sometimes a chicken
and egg problem. Not sure if there is a need for a new implementation, but
if there is, good to get it done and available as part of Avalon. :-)
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
Re: [GUMP] Build Failure - James and Lock related changes
Posted by Harmeet Bedi <hb...@yahoo.com>.
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
> The Lock implementation DID NOT WORK in its previous form. For some
reason,
> when we had one Lock object handle the locks for multiple objects, the
Lock
> would not prevent access. This caused some concurrency issues in the Pool
> implementations. The API was changed to lock() and unlock() with no
parameters.
> canLock() and isLocked() were not implemented, as I didn't think they were
> truly useful. They can be added back in, but without ANY params. I was
> focusing on getting something that really worked.
>
> I did post an email about this to the Avalon Dev list when I committed it,
> but it looks like noone read it.
I did read it, but did had no cycles to follow up or think about the impact.
I have for now added the old Avalon Lock Classes to James. This is a stopgap
measure otherwise James would suffer from the same problems you found in
Cocoon. James does seem to rely on the previous Lock API. Maybe the same API
can be built in some other object using the new Lock implementation.
>
> If we want to adopt the aquire()/release() names, it's nothing but a name
> thing. The contents change with the InterruptedException is excellent,
> and can help prevent some deadlocks. I will incorporate that.
>
> But lets vote on the "Class : Method" names:
>
> 1) Mutex : aquire()/release()
> 2) Lock : lock()/unlock()
>
> I have no qualms or preferences about either--I just want this thing to
> work properly.
Names don't matter that much however if Avalon can use or reuse a standard
package, than the same names should be mentained. Well my vote is not
important and in any case it is 0.
>
> > 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.
>
> OK. I was working on what was already in Avalon. If there is a solid
> concurrency management library available with a compatible license, then
> go for it. Note, we did have someone express interest in donating or
> developing a number of classes that would fill this need.
I make lots of multithreading mistakes. Would prefer to rely on a well
tested, widely reviewed and fast library. But that is sometimes a chicken
and egg problem. Not sure if there is a need for a new implementation, but
if there is, good to get it done and available as part of Avalon. :-)
Harmeet
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [GUMP] Build Failure - James and Lock related changes
Posted by Berin Loritsch <bl...@apache.org>.
Harmeet Bedi wrote:
>
> 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.
The Lock implementation DID NOT WORK in its previous form. For some reason,
when we had one Lock object handle the locks for multiple objects, the Lock
would not prevent access. This caused some concurrency issues in the Pool
implementations. The API was changed to lock() and unlock() with no parameters.
canLock() and isLocked() were not implemented, as I didn't think they were
truly useful. They can be added back in, but without ANY params. I was
focusing on getting something that really worked.
I did post an email about this to the Avalon Dev list when I committed it,
but it looks like noone read it.
> 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;
> }
> }
> }
> ------------------------------------------
If we want to adopt the aquire()/release() names, it's nothing but a name
thing. The contents change with the InterruptedException is excellent,
and can help prevent some deadlocks. I will incorporate that.
But lets vote on the "Class : Method" names:
1) Mutex : aquire()/release()
2) Lock : lock()/unlock()
I have no qualms or preferences about either--I just want this thing to
work properly.
> 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.
OK. I was working on what was already in Avalon. If there is a solid
concurrency management library available with a compatible license, then
go for it. Note, we did have someone express interest in donating or
developing a number of classes that would fill this need.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [GUMP] Build Failure - James and Lock related changes
Posted by Peter Donald <do...@apache.org>.
At 03:35 7/04/01 -0700, Harmeet Bedi wrote:
>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.
I love his code so that sounds kewl. Whether we can directly use it or have
to imitate it I am not sure - will check out license real soon now. IIRC he
also included heaps of other stuff with the package so we should consider
reducing the package to just concurrency management stuff.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [GUMP] Build Failure - James and Lock related changes
Posted by Peter Donald <do...@apache.org>.
At 03:35 7/04/01 -0700, Harmeet Bedi wrote:
>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.
I love his code so that sounds kewl. Whether we can directly use it or have
to imitate it I am not sure - will check out license real soon now. IIRC he
also included heaps of other stuff with the package so we should consider
reducing the package to just concurrency management stuff.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org