Hi,
> I don't see how we can guarentee that there will not be deadlocks
> by focusing on making the ULR single threaded since that is not
> the point of locking that we do not have control over.
Yes. Making the ULR single threaded is an orthogonal issue (will make the ULR
simpler), but the rea
I don't see how we can guarentee that there will not be deadlocks
by focusing on making the ULR single threaded since that is not
the point of locking that we do not have control over. The issue
is the loadClassInternal class call initiated by the VM and my
concern is illustrated by this stack tra
Hi,
> I think I've found the problems.
>
> Problem 1
> -
> A does a normal loadClass() - no lock on UCL
> it gets past synchronise into the main routine
> B does a loadClassInternal() - locks the UCL
> A reaches unsynchronise, aquires the reentrantLock, releases
> itself as the curre
Really notifyAll only introduces some thread context
switching overhead when there are many threads waiting, but
it generally provides more robust code. See the examples in
Doug Lea's book.
> But
> // This release() must be inside the synchronization block on the
> classloader
> // to avoid
riginal Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|Adrian Brock
|Sent: Wednesday, May 29, 2002 1:57 PM
|To: [EMAIL PROTECTED]
|Subject: RE: [JBoss-Dev] DeployServiceUnitTestCase.testDependsElement
|failure
|
|
|Hi,
|
|Ordering the currentThread and ULR didn't f
ization block on the
classloader
// to avoid that a notifyAll() will arrive before the wait() below, see
unsynchronize()
What problem does the notifyAll before the wait cause? Spinning?
Regards,
Adrian
>From: "Bordet, Simone" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To:
Hi,
Ok, always become the current thread before synchronizing on the ULR
sorts the ordering.
Will this introduce any other problems?
Regards,
Adrian
>From: "Bordet, Simone" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: <[EMAIL PROTECTE
|If that's the case, then I think there is no other choice than
|using the reentrant lock for every method of ULR, so that the code
|is wrapped into a try/finally (acquire/release).
|Adrian, can you try the above to see if it works ?
Woke up this morning, and was thinking that we should make the
Hi,
> The hang is not predictable, but it is mostly on the
> RaTopicUnitTestCase.
> Trying to dump the threads crashes the VM, but below is the start
> of one of the dumps. It appears to be a deadlock in the
> UnifiedLoaderRepository.
>
> Looking at the code, there might be an ordering problem
at sun.rmi.transport.Transport.serviceCall(Transport.java:148)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:465)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:706)
> at java.lang.Thread.
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:706)
at java.lang.Thread.run(Thread.java:484)
Regards,
Adrian
>From: "Scott M Stark" <[EMAIL PROTECTED]>
>Reply-To: "Scott M Stark" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
IL PROTECTED]>
Sent: Tuesday, May 28, 2002 3:38 AM
Subject: Re: [JBoss-Dev] DeployServiceUnitTestCase.testDependsElement
failure
> Hi,
>
> >It is trying to start TestDeployerC, but it is not actually starting.
>
> The test in ServiceMBeanSupport.start() should now be
&g
Hi,
>It is trying to start TestDeployerC, but it is not actually starting.
The test in ServiceMBeanSupport.start() should now be
-if (getState() != STOPPED && getState() != FAILED)
+if (getState() != DESTROYED && getState() != STOPPED && getState() !=
FAILED)
return;
This fixes the test.
Hi Scott,
It is trying to start TestDeployerC, but it is not actually starting.
I don't know whether this is related, but the service context for C
is not being removed anymore.
I'll try to figure out what has changed since Sunday.
Regards,
Adrian
_
Hi Scott,
I made that change.
Cycling a service with dependencies wasn't restarting the dependencies.
I've got a fix for the double destroy that is causing the JBossMQ
errors on shutdown.
I noticed you put a fix in ServiceMBeanSupport, but I think this
should go in the ServiceController - Servic
A change was made to the DeployServiceUnitTestCase to validate the
registered services are in the running state rather than just registered.
The testDependsElement is now failing because the TestDeployerC
service is only being created and not started. Please look into this
on the 3.0 branch.
11:5
16 matches
Mail list logo
