[Design of OSGi Integration] - Re: JBOSGI-38 and bundle deployment order
by adrian@jboss.org
"thomas.diesler(a)jboss.com" wrote : If I remember correctly, we started of with the requirement that bundles can be deployed in any order.
|
| I now made this configurable
|
|
| | <!--
| | If set to 'true' bundles can be deployed in any order. Deployed bundle will get started when their dependencies can be resolved.
| | If set to 'false' bundles must be deployed in the order that is required to start them.
| | -->
| | <entry><key>org.jboss.osgi.deferred.start</key><value>true</value></entry>
| |
|
| If you set this to 'false' the dependency item is used and deployed bundles are expected to get resolved so that the start/stop deployer can start the bundle.
|
| In case the bundle cannot get resolved you will get an exception (with the deployers in jboss-5.0.1)
|
If you don't want the exception then you need to control the "required state"
of the deployment such that it doesn't move to "Installed" and instead remains
the unresolved state (Described?).
There already is a method to change the "required state" of an existing deployment
DeployerClient.change(deploymentName, DeploymentState);
but there's nothing currently that lets you set it at initial deployment, e.g. something like
DeployerClient.deploy(Deployment, DeploymentState); // DOES NOT EXIST
anonymous wrote :
| I definitely agree with you, if MainDeployerImpl.checkComplete
| would not throw an exception we could always use the DI based approach.
|
|
| | 15:15:08,642 WARN [MainDeployer] Failed to deploy: file:/.../jbosgi38-bundleB.jar
| | org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
| |
| | DEPLOYMENTS MISSING DEPENDENCIES:
| | Deployment "vfszip:/.../jbosgi38-bundleB.jar/" is missing the following dependencies:
| | Dependency "<UNKNOWN jbosgi38-bundleB>" (should be in state "ClassLoader", but is actually in state "** UNRESOLVED Bundle: jbosgi38-bundleB [10] **")
| |
| | DEPLOYMENTS IN ERROR:
| | Deployment "<UNKNOWN jbosgi38-bundleB>" is in error due to the following reason(s): ** UNRESOLVED Bundle: jbosgi38-bundleB [10] **
| |
| | at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
| | at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
| | at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:869)
| | at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:858)
| | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)
| |
|
| Perhaps, we can continue the discussion on the topic of what to do with that exception. Should it be thrown or should there be a warning instead?
|
| In case an exception is no longer thrown it would change the behaviour of
|
|
| | MainDeployer.deploy(URL)
| |
|
| on the client side.
|
| In case the behaviour stays unchanged (i.e. MainDeployerImpl.checkComplete throw an exception) the client is forced to deploy the bundles in the correct order, which contradicts our initial requirement.
|
|
No. MainDeployerMBean.deploy(url) is a convenience methods on the
OLD api that just does:
Deployment deployment = new VFSDeployment(url);
DeployerClient.addDeployment(deployment);
DeployerClient.process();
DeployerClient.checkComplete(deployment);
If you need more control, use the more detailed protocol on the NEW api.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215328#4215328
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215328
17 years, 1 month
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Another DeadLock, something around InVM
by clebert.suconic@jboss.com
I could fix PingStressTest by adding this fix:
| Index: src/main/org/jboss/messaging/core/remoting/impl/RemotingConnectionImpl.java
| ===================================================================
| --- src/main/org/jboss/messaging/core/remoting/impl/RemotingConnectionImpl.java (revision 6007)
| +++ src/main/org/jboss/messaging/core/remoting/impl/RemotingConnectionImpl.java (working copy)
| @@ -417,10 +417,17 @@
|
| log.warn("Connection failed, client " + client + " " + System.identityHashCode(this) + " " + me.getMessage(), me);
|
| - // Then call the listeners
| - callListeners(me);
| + // Using another thread to avoid a hang or dead lock (another thread waiting an executor to finish, while it holds the lock)
| + new Thread()
| + {
| + public void run()
| + {
| + // Then call the listeners
| + callListeners(me);
|
| - internalClose();
| + internalClose();
| + }
| + }.start();
| }
|
| public void destroy()
|
|
Unless you guys find something wrong with it, I will commit it and enable PingStressTest with 20 iterations. (I have also changed the calling timeout on the test, what would make the stress-test to run faster)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215320#4215320
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215320
17 years, 1 month
[Design of OSGi Integration] - Re: JBOSGI-38 and bundle deployment order
by thomas.diesler@jboss.com
If I remember correctly, we started of with the requirement that bundles can be deployed in any order.
I now made this configurable
| <!--
| If set to 'true' bundles can be deployed in any order. Deployed bundle will get started when their dependencies can be resolved.
| If set to 'false' bundles must be deployed in the order that is required to start them.
| -->
| <entry><key>org.jboss.osgi.deferred.start</key><value>true</value></entry>
|
If you set this to 'false' the dependency item is used and deployed bundles are expected to get resolved so that the start/stop deployer can start the bundle.
In case the bundle cannot get resolved you will get an exception (with the deployers in jboss-5.0.1)
I definitely agree with you, if MainDeployerImpl.checkComplete
would not throw an exception we could always use the DI based approach.
| 15:15:08,642 WARN [MainDeployer] Failed to deploy: file:/.../jbosgi38-bundleB.jar
| org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
|
| DEPLOYMENTS MISSING DEPENDENCIES:
| Deployment "vfszip:/.../jbosgi38-bundleB.jar/" is missing the following dependencies:
| Dependency "<UNKNOWN jbosgi38-bundleB>" (should be in state "ClassLoader", but is actually in state "** UNRESOLVED Bundle: jbosgi38-bundleB [10] **")
|
| DEPLOYMENTS IN ERROR:
| Deployment "<UNKNOWN jbosgi38-bundleB>" is in error due to the following reason(s): ** UNRESOLVED Bundle: jbosgi38-bundleB [10] **
|
| at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:869)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:858)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833)
|
Perhaps, we can continue the discussion on the topic of what to do with that exception. Should it be thrown or should there be a warning instead?
In case an exception is no longer thrown it would change the behaviour of
| MainDeployer.deploy(URL)
|
on the client side.
In case the behaviour stays unchanged (i.e. MainDeployerImpl.checkComplete throw an exception) the client is forced to deploy the bundles in the correct order, which contradicts our initial requirement.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215319#4215319
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215319
17 years, 1 month
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Another DeadLock, something around InVM
by ataylor
Ive added some debug to log the packet, as follows
[junit] main 13:57:13,878 INFO [SecurityTest] ####################################################### Start IN-VM test: testLoginInvalidUserInvalidPassword
| [junit] New I/O server worker #6-1 13:57:13,888 ERROR [MessagingServerPacketHandler] Failed to create session
| [junit] MessagingException[errorCode=105 message=Unable to validate user: osama]
| [junit] at org.jboss.messaging.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:119)
| [junit] at org.jboss.messaging.core.server.impl.MessagingServerImpl.doCreateSession(MessagingServerImpl.java:975)
| [junit] MessagingException[errorCode=105 message=Unable to validate user: osama]
| [junit] at org.jboss.messaging.core.server.impl.MessagingServerImpl.createSession(MessagingServerImpl.java:693)
| [junit] at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.doHandleCreateSession(MessagingServerPacketHandler.java:103)
| [junit] at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handleCreateSession(MessagingServerPacketHandler.java:140)
| [junit] at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:71)
| [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1472)
| [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] at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:361)
| [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] packet = PACKET[type=20, channelID=1], exception= MessagingException[errorCode=105 message=Unable to validate user: osama]]
| [junit] lock = java.util.concurrent.locks.ReentrantLock@18177ca[Locked by thread main]
| [junit] at org.jboss.messaging.core.remoting.impl.wireformat.MessagingExceptionMessage.decodeBody(MessagingExceptionMessage.java:81)
| [junit] at org.jboss.messaging.core.remoting.impl.wireformat.PacketImpl.decode(PacketImpl.java:198)
| [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.decode(RemotingConnectionImpl.java:836)
| [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:482)
| [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl$DelegatingBufferHandler.bufferReceived(ConnectionManagerImpl.java:944)
| [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)
|
you see the stacktrace on the server.
The packet exception being received
the lock being obtained unsuccessfully because the main thread has it. The weird thing is how can th emain thread have it if only 1 packet has been received but not processes yet becausse of th elock
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215312#4215312
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215312
17 years, 1 month