[Design the new POJO MicroContainer] - jboss fails to boot with current snapshot
by scott.stark@jboss.org
If I try to boot with the current mc snapshot, it fails due to the AOPConstructorJoinpoint missing from the jboss-aop-mc-int-boot.jar:
| Caused by: java.lang.NoClassDefFoundError: org/jboss/aop/microcontainer/integration/AOPConstructorJoinpoint
| at org.jboss.aop.microcontainer.integration.AOPJoinpointFactory.getConstructorJoinpoint(AOPJoinpointFactory.java:53)
| at org.jboss.kernel.plugins.config.Configurator.findConstructor(Configurator.java:212)
| at org.jboss.kernel.plugins.config.Configurator.getConstructorJoinPoint(Configurator.java:195)
| at org.jboss.kernel.plugins.config.Configurator.instantiate(Configurator.java:93)
| at org.jboss.kernel.plugins.config.Configurator.instantiateAndConfigure(Configurator.java:69)
| at org.jboss.kernel.plugins.config.property.PropertyKernelConfig.getImplementation(PropertyKernelConfig.java:159)
| at org.jboss.kernel.plugins.config.property.PropertyKernelConfig.createKernelInitializer(PropertyKernelConfig.java:118)
| at org.jboss.kernel.KernelFactory.createKernelInitializer(KernelFactory.java:150)
| ... 10 more
|
What is the basis for including content in the jboss-aop-mc-int-boot.jar, and why would this class not already be included?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994832#3994832
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994832
19 years, 3 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Valve on HAAspect
by clebert.suconic@jboss.com
I have locally changed ValveAspect to use readWriteLocks... But I think using org.jboss.messaging.util.Valve would be a better mechanism.
a parenthesis before starting (Valve is the same as creating a property failoverRunning on the Aspect, and if failoverRunning is true we will wait on notify until failover is finished. I just encapsulated such logic in a class instead of spread Objects and notifies on ValveAspect, so please do not compare it with java.util.concurrent or any other package like that)
Using readWriteLock will add synchronization into ValveAspect::invoke. Even readWriteLock requires synchronization while the use of Valve would minimize it.
As a comparisson I have written ValidateValveLogicValveTest and ValidateValveLogicReadWriteTest which are going to play with counters and doing the exact same locking mechanism needed on ValveAspect.
ValidateValveLogicValveTest could perform more or less 4 times the number of loops performed by ValidateValveLogicReadWriteTest. This is because the object.wait() added readLock().acquire().
on a thread dump, I could see this from readLock().acquire():
| "Thread-999" prio=1 tid=0x087bacd8 nid=0x37a0 waiting for monitor entry [0x4e456000..0x4e456228]
| at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(WriterPreferenceReadWriteLock.java:159)
| - waiting to lock <0x746d4428> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
| at org.jboss.test.messaging.util.ValidateValveLogicReadWriteTest$ThreadRead.run(ValidateValveLogicReadWriteTest.java:198)
|
| "Thread-998" prio=1 tid=0x087b9fd0 nid=0x379f waiting for monitor entry [0x4e4d7000..0x4e4d7228]
| at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(WriterPreferenceReadWriteLock.java:159)
| - waiting to lock <0x746d4428> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
| at org.jboss.test.messaging.util.ValidateValveLogicReadWriteTest$ThreadRead.run(ValidateValveLogicReadWriteTest.java:198)
|
| "Thread-997" prio=1 tid=0x087b92c8 nid=0x379e waiting for monitor entry [0x4e558000..0x4e558228]
| at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(WriterPreferenceReadWriteLock.java:159)
| - waiting to lock <0x746d4428> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
| at org.jboss.test.messaging.util.ValidateValveLogicReadWriteTest$ThreadRead.run(ValidateValveLogicReadWriteTest.java:198)
|
Of course I'm not trying to reinvent the wheel here, but I just think we have an useCase where we don't want to synchronize readLocks on the invocation, as we want to avoid new calls to be performed while client failover is being executed, not to add synchronization on such basic feature.
I'm assuming here it is a common practice to have multiple sessions associated with a single connection. The synchronization here will be per Connection. If customers or public benchmarks are using muliple connections, then this shouldn't be a problem.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994828#3994828
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994828
19 years, 3 months