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

[Design of JBoss/Tomcat Integration] - Re: JBIDE-3394, hot deployment management api

by pete.muir＠jboss.org

https://jira.jboss.org/jira/browse/JBAS-6589 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215909#4215909 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215909

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Another Deadlock

by clebert.suconic＠jboss.com

| [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.callListeners(Remoting | ConnectionImpl.java:547) | | This was introduced on this commit, in an attempt to fix another deadlock. http://fisheye.jboss.org/browse/Messaging/trunk/src/main/org/jboss/messag... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215905#4215905 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215905

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Locking in DeploymentRepository

by alesj

Eh, I should read the code better. :-( As you said, activeScan == Future. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215902#4215902 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215902

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Another Deadlock

by clebert.suconic＠jboss.com

This Thread is holding a Channel.lock: [junit] "Thread-2 (group:JBM-async-session-delivery-threads-17258453)" daemon prio=1 tid=0x63ee2568 nid=0xae2 waiting for monitor entry [0x650b8000..0x650b9030] | [junit] at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.exceptionCaught(MessagingChannelHandler.java:100) | [junit] - waiting to lock <0x74398000> (a org.jboss.messaging.integration.transports.netty.NettyConnector$MessagingClientChannelHandler) | [junit] at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:147) | [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.handler.codec.frame.FrameDecoder.exceptionCaught(FrameDecoder.java:224) | [junit] at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:147) | [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.fireExceptionCaught(Channels.java:605) | [junit] at org.jboss.netty.channel.socket.nio.NioWorker.cleanUpWriteBuffer(NioWorker.java:558) | [junit] - locked <0x74395c80> (a java.lang.Object) | [junit] at org.jboss.netty.channel.socket.nio.NioWorker.write(NioWorker.java:322) | [junit] at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink.eventSunk(NioClientSocketPipelineSink.java:121) | [junit] at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:792) | [junit] at org.jboss.netty.channel.SimpleChannelHandler.writeRequested(SimpleChannelHandler.java:309) | [junit] at org.jboss.netty.channel.SimpleChannelHandler.handleDownstream(SimpleChannelHandler.java:271) | [junit] at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:600) | [junit] at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:797) | [junit] at org.jboss.netty.channel.SimpleChannelHandler.writeRequested(SimpleChannelHandler.java:309) | [junit] at org.jboss.netty.channel.SimpleChannelHandler.handleDownstream(SimpleChannelHandler.java:271) | [junit] at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:600) | [junit] at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:595) | [junit] at org.jboss.netty.channel.Channels.write(Channels.java:876) | [junit] at org.jboss.netty.channel.Channels.write(Channels.java:824) | [junit] at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:236) | [junit] at org.jboss.messaging.integration.transports.netty.NettyConnection.write(NettyConnection.java:128) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.sendBlocking(RemotingConnectionImpl.java:1076) | [junit] - locked <0x74390d18> (a java.lang.Object) | [junit] at org.jboss.messaging.core.client.impl.ClientConsumerImpl.doCleanUp(ClientConsumerImpl.java:620) | [junit] at org.jboss.messaging.core.client.impl.ClientConsumerImpl.close(ClientConsumerImpl.java:263) | [junit] at org.jboss.messaging.core.client.impl.ClientSessionImpl.closeChildren(ClientSessionImpl.java:1339) | [junit] at org.jboss.messaging.core.client.impl.ClientSessionImpl.close(ClientSessionImpl.java:750) | [junit] at org.jboss.messaging.core.server.cluster.impl.BridgeImpl$StopRunnable.run(BridgeImpl.java:322) | [junit] - locked <0x74390b48> (a org.jboss.messaging.core.server.cluster.impl.BridgeImpl) | [junit] at org.jboss.messaging.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105) | [junit] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) | [junit] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) | [junit] at java.lang.Thread.run(Thread.java:595) | If you look at the code, you will see the lock being held: org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.sendBlocking(RemotingConnectionImpl.java:1076) (the lock was acquired at lock.lock(), line 1053). And this thread is trying to the channel lock, while it holds 0x74398000 | [junit] "New I/O client worker #4336-1" daemon prio=1 tid=0x0a1dbb18 nid=0x92c waiting on condition [0x6264f000..0x62650130] | [junit] at sun.misc.Unsafe.park(Native Method) | [junit] at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118) | [junit] at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:716) | [junit] at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:746) | [junit] at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1076) | [junit] at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:184) | [junit] at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:256) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.callListeners(RemotingConnectionImpl.java:547) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:421) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.failConnection(ConnectionManagerImpl.java:876) | [junit] - locked <0x7461ccb8> (a java.lang.Object) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.connectionDestroyed(ConnectionManagerImpl.java:197) | [junit] at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.channelDisconnected(MessagingChannelHandler.java:83) | [junit] - locked <0x7461b3a0> (a org.jboss.messaging.integration.transports.netty.NettyConnector$MessagingClientChannelHandler) | [junit] at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:137) | [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.handler.codec.frame.FrameDecoder.cleanup(FrameDecoder.java:299) | [junit] at org.jboss.netty.handler.codec.frame.FrameDecoder.channelDisconnected(FrameDecoder.java:212) | [junit] at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:137) | [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.fireChannelDisconnected(Channels.java:494) | [junit] at org.jboss.netty.channel.socket.nio.NioWorker.close(NioWorker.java:514) | [junit] at org.jboss.netty.channel.socket.nio.NioWorker.close(NioWorker.java:317) | [junit] at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:306) | [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:650) | [junit] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) | [junit] at java.lang.Thread.run(Thread.java:595) | | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215901#4215901 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215901

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Dependency on XB DefaultSchemaResolver

by alesj

This is now done under JBXB-191. Is there anything else to VFSInputSource than this: | public class VFSInputSource extends InputSource | { | private VirtualFile file; | | public VFSInputSource(VirtualFile file) | { | if (file == null) | throw new IllegalArgumentException("Null file"); | | this.file = file; | } | | @Override | public String getSystemId() | { | try | { | return file.toURI().toString(); | } | catch (Exception e) | { | throw new RuntimeException(e); | } | } | | @Override | public InputStream getByteStream() | { | try | { | return file.openStream(); | } | catch (IOException e) | { | throw new RuntimeException(e); | } | } | | @Override | public Reader getCharacterStream() | { | return new InputStreamReader(getByteStream()); | } | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215899#4215899 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215899

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Extending jboss-beans.xml schema?

by scott.stark＠jboss.org

Every usage that is working has included a SchemaResolverDeployer with the registerWithJBossXB=true which is updating the jbossxb schema mappings. I don't need a parsing deployer, but I'm not sure why just trying to register the namespace mapping directly is not working. Could just be I'm not doing it correctly. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215898#4215898 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215898

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Locking in DeploymentRepository

by scott.stark＠jboss.org

The ScheduledFuture is the activeScan variable. It could be exposed as a read-only property that would be null if scanning is not enabled. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215897#4215897 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215897

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Locking in DeploymentRepository

by alesj

The question is more "can I get a hold of that Future instance", then, like Jason says, it would be just a matter of calling Future::get to know when we're done with cancel. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215895#4215895 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215895

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Extending jboss-beans.xml schema?

by david.lloyd＠jboss.com

This is how I do it with all the deployers I've done, like Threads and XNIO and so forth: | <deployment xmlns="urn:jboss:bean-deployer:2.0"> | <bean name="XnioMetaDataDeployer" class="org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryDeployer"> | <constructor> | <parameter>org.jboss.xnio.metadata.XnioMetaData</parameter> | </constructor> | </bean> | | <bean name="XnioParserDeployer" class="org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer"> | <constructor> | <parameter>org.jboss.xnio.metadata.XnioMetaData</parameter> | </constructor> | <property name="name">jboss-xnio.xml</property> | <property name="registerWithJBossXB">true</property> | </bean> | | </deployment> | | Then XnioMetaData implements BeanMetaDataFactory, which allows "xnio" elements to exist directly under "deployment" elements. I'm not sure if this is what you're looking for though... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215893#4215893 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215893

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Locking in DeploymentRepository

by scott.stark＠jboss.org

"alesj" wrote : I think the future is an impl detail there. | Scott? | Its part of the HDScanner api in that it uses a ScheduledExecutorService via injection. If one is not provided it creates one. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215892#4215892 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215892

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