March 2009 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: InterruptedException not being cleared?

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : This type of test is tricky because it takes two threads with one handling the load of a one class and the other handling the load of superclass or field related classes. I'd just make it a todo for now. | You'd probably need: 1) to use a dummy ClassLoaderPolicy so you can cause classloading requests to wait with the classloading locks held by different threads 2) get locks on the classloaders before making the classloading requests to simulate what loadClassInternal() does. The basic rule should be that a) if the thread is interrupted before you make the classloading request then the request should work. b) But you should be able to interrupt a thread if it is stuck in a classloading task wait. Neither should lead to a live/deadlock in the classloading. One issue that occurs to me though with (b) is that it will end up throwing a ClassNotFoundException which will likely end up causing the class to be blacklisted. We should really work around this by throwing some sort of TemporaryClassNotFoundException to show the request maybe retried later? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215213#4215213 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215213

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBossWS Test Approach

by richard.opalka＠jboss.com

"richard.opalka(a)jboss.com" wrote : we don't test against AS distributions but against local maven repository This is fundamental problem for me. There are two types of AS we're testing against to consider here: released AS GAs - current testing approach works properly for it moving AS branches/trunks - current testing approach is highly error prone for it And because our testing approach is identical for released AS GAs and moving AS branches/trunks we should use AS distributions jars only to prevent this problem. In that case you'd be always up2date with jars in the distribution and there'd be no overhead to exclude dependencies on regular basis, upload maven artifacts, ... etc. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215211#4215211 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215211

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Another DeadLock, something around InVM

by timfox

Ok, that's a separate issue. The one you pasted if for Netty, the one I fixed is invm transport. That's why I said this thread confusing - it's two separate issues. Ok... onto fixing the second one. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215209#4215209 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215209

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Another DeadLock, something around InVM

by ataylor

yes after your fix was applied. The second thread has the Channel.lock. [junit] "New I/O client worker #318-1" daemon prio=10 tid=0x080be400 nid=0x640d waiting on condition [0x6ea5c000..0x6ea5cf40] | [junit] java.lang.Thread.State: WAITING (parking) | [junit] at sun.misc.Unsafe.park(Native Method) | [junit] - parking to wait for <0xadf7e648> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) | [junit] at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) | [junit] at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) | [junit] at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778) | [junit] at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114) | [junit] at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186) | [junit] at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1459) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:845) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:492) | [junit] - locked <0xadf7e400> (a java.lang.Object) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl$DelegatingBufferHandler.bufferReceived(ConnectionManagerImpl.java:943) | [junit] at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:62) | [junit] at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105) | [junit] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:577) | [junit] at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:804) | [junit] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:385) | [junit] at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:279) | [junit] at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:202) | [junit] at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105) | [junit] at org.jboss.netty.handler.codec.frame.FrameDecoder.handleUpstream(FrameDecoder.java:162) | [junit] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:577) | [junit] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:572) | [junit] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:342) | [junit] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:329) | [junit] at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:302) | [junit] at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:254) | [junit] at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:171) | [junit] at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72) | [junit] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) | [junit] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) | [junit] at java.lang.Thread.run(Thread.java:619) | [junit] "main" prio=10 tid=0x0805cc00 nid=0x606e waiting on condition [0xb7d5d000..0xb7d5e208] | [junit] java.lang.Thread.State: TIMED_WAITING (parking) | [junit] at sun.misc.Unsafe.park(Native Method) | [junit] - parking to wait for <0xadf7bed0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) | [junit] at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198) | [junit] at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1963) | [junit] at java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1245) | [junit] at org.jboss.messaging.integration.transports.netty.NettyConnector.close(NettyConnector.java:363) | [junit] - locked <0xadf7b6c8> (a org.jboss.messaging.integration.transports.netty.NettyConnector) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.checkCloseConnections(ConnectionManagerImpl.java:761) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.returnConnection(ConnectionManagerImpl.java:852) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.createSession(ConnectionManagerImpl.java:333) | [junit] - locked <0xadf7afd8> (a java.lang.Object) | [junit] at org.jboss.messaging.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:862) | [junit] - locked <0xadf7a8d8> (a org.jboss.messaging.core.client.impl.ClientSessionFactoryImpl) | [junit] at org.jboss.messaging.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:574) | [junit] at org.jboss.messaging.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:572) | [junit] - locked <0xadf742b8> (a org.jboss.messaging.jms.client.JBossConnectionFactory) | [junit] at org.jboss.messaging.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:408) | [junit] at org.jboss.test.messaging.jms.SecurityTest.testLoginValidUserInvalidPassword(SecurityTest.java:136) | [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | [junit] at java.lang.reflect.Method.invoke(Method.java:597) | [junit] at junit.framework.TestCase.runTest(TestCase.java:164) | [junit] at junit.framework.TestCase.runBare(TestCase.java:130) | [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) | [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) | [junit] at junit.framework.TestResult.run(TestResult.java:109) | [junit] at junit.framework.TestCase.run(TestCase.java:120) | [junit] at junit.framework.TestSuite.runTest(TestSuite.java:230) | [junit] at junit.framework.TestSuite.run(TestSuite.java:225) | [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421) | [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:912) | [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215206#4215206 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215206

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractVFSParsingDeployer doesn't kick in upon server r

by heiko.braun＠jboss.com

anonymous wrote : | You can also see which deployers processed a deployment on the JMX console. | Find your (sub-)deployment/component in the jboss.deployment namespace. | thanks, that's good to know View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215200#4215200 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215200

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBossWS Test Approach

by richard.opalka＠jboss.com

"richard.opalka(a)jboss.com" wrote : it's error prone approach We're using maven surefire plugin to invoke our junit integration tests. The problem is our tests are not just java component tests but they test whole JBossWS integration to JBossAS. The concrete problem is we're using maven dependencies mechanism to configure our tests classpath. Unfortunately this introduces many defects to our tests: We're not testing AS using AS provided libraries in distribution We're using libraries from local maven repository where many of these libraries has wrong version (because of outdated dependency exclusions) we don't have control over which version of particular component jar will be used for testing when there are two libraries of the same component with different version. The only way to achieve it is to use maven dependency exclusions (a lot of work without any evident added value). These exclusions should be updated on daily basis when testing AS moving branches/trunks. we're using out of date libraries for moving AS versions - many updates of the required dependencies are not released to the maven repository To solve this AS maven artifacts (SNAPSHOTS) should be uploaded to maven repo on daily basis. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215196#4215196 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215196

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractVFSParsingDeployer doesn't kick in upon server r

by adrian＠jboss.org

"jaikiran" wrote : | anonymous wrote : 2009-03-04 17:11:55,399 TRACE [org.jboss.deployers.plugins.deployers.DeployersImpl] Deployer org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer@1406eb6 not relevant for vfsfile:/home/jpai/business/jboss/wc/jbossas/projects/ejb3/trunk/nointerface/src/test/resources/deployers/ | | | | | | which shows me whether the deployer was considered relevant for the deployment | You can also see which deployers processed a deployment on the JMX console. Find your (sub-)deployment/component in the jboss.deployment namespace. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215195#4215195 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215195

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Another DeadLock, something around InVM

by timfox

"ataylor" wrote : I'm seeing similar hangs with the same thread dump. Whats weird is that the following line hangs: | Is this after the fix I applied this morning? If so, please post thread dump. This thread is confusing since two completely different thread dumps were posted, which are possibly different issues. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215193#4215193 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215193

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Another DeadLock, something around InVM

by ataylor

actually its not hanging, I didn't notice it was in a loop View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215188#4215188 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215188

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Another DeadLock, something around InVM

by ataylor

I'm seeing similar hangs with the same thread dump. Whats weird is that the following line hangs: if (workerExecutor.awaitTermination(1, TimeUnit.SECONDS)) I'm not sure why this line would hang! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215184#4215184 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215184

17 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2009