[Design of POJO Server] - Re: Integrating platform mbeans into kernel bus?
by scott.stark＠jboss.org
Its taking a combination of 2+3 as I need to be able to invoke methods on the entry and this requires a InvokeDispatchContext. I'm down to this failure now:
| java.lang.reflect.UndeclaredThrowableException
| at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.invoke(KernelBusRuntimeComponentDispatcher.java:123)
| at org.jboss.profileservice.management.ManagementViewImpl$ManagedOperationDelegate.invoke(ManagementViewImpl.java:1358)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
| at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
| at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
| at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
| at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
| Caused by: java.lang.IllegalArgumentException: Cannot execute invoke on non InvokeDispatchContext context: AbstractKernelRegistryEntry@2bc94f{target=ServiceControllerContext@4b934c{name=java.lang:type=Threading target=null state=**ERROR** depends=AbstractDependencyInfo@ada032{idependOn=[]} error=javax.management.InstanceNotFoundException: java.lang:type=Threading is not registered.
| at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
| at org.jboss.mx.server.MBeanServerImpl.getMBeanInfo(MBeanServerImpl.java:675)
| at org.jboss.system.microcontainer.ServiceProxy.getServiceProxy(ServiceProxy.java:112)
| at org.jboss.system.microcontainer.ServiceControllerContext.getServiceProxy(ServiceControllerContext.java:255)
| at org.jboss.system.microcontainer.CreateDestroyLifecycleAction.installAction(CreateDestroyLifecycleAction.java:41)
| at org.jboss.system.microcontainer.CreateDestroyLifecycleAction.installAction(CreateDestroyLifecycleAction.java:37)
| ...
|
I'm going to allow the MBeanServer to be specified at the ServiceControllerContext level so that it can be different from default MBeanServer used by the JMXKernel.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213005#4213005
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213005
16 years, 10 months
[Design of POJO Server] - Re: Bringing the trunk profile service changes to 5_x
by emuckenhuber
Hmm we could do it somehow like this:
| public interface DeploymentTemplate
| {
| // Get the deployment info
| DeploymentTemplateInfo getInfo();
|
| // Get the deployment name
| String getDeploymentName(String baseName);
|
| // Apply template
| VirtualFile applyTemplate(DeploymentTemplateInfo info);
| }
|
Where managementView is more or less doing this:
| // Create a temp deployment
| VirtualFile vf = template.applyTemplate(deploymentInfo);
| // Get the deployment name
| String deploymentName = template.getDeploymentName(baseName);
| // Distribute deployment
| deploymentMgr.distribute(deploymentName, vf.toURL(), true);
| // Start deployment
| deploymentMgr.start(deploymentName);
| // Delete temp deployment
| vf.delete();
|
Although now i really don't know where to put this updateTemplateDeployment(VFSDeployment ctx, DeploymentTemplateInfo values);
IMO a deployment template does not need to know where it gets copied to. Furthermore it won't have access to the DeploymentContext until it's deployed anyway.
Also adding something to the deployments attachment would not make much sense, as it will get lost during the next startup.
I think additional updates to this template should use updateComponent() and be stored as a attachment.
There is also this in the SPI:
| * TODO: this needs to be fleshed out in terms of the various pieces, raw deployment
| * files, ManagedObjects, etc.
|
not sure what you mean by that - so is there still something missing?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4212981#4212981
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4212981
16 years, 10 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messages are lost on Queue?
by jmesnil
"timfox" wrote : 2) and 3) should be handled the same on the server.
|
| In other words, the only case where we immediately remove the ServerSession is when we get an explicit SESSION_CLOSE message.
|
This is not the case today: #2 results in a connectionDestroyed (with no clean-up) and #3 results in a connectionException(with immediate clean-up)
#3 needs to be fixed so that the server session is removed only when the connection TTL is hit.
"timfox" wrote :
| Regarding the LAST request: we already have such a request; it's the SESSION_CLOSE request.
When I receive the SESSION_CLOSE on the server, I flag the remoting connection as "ready to be closed" once the server session has handled the packet.
In the remoting service, when I received a connectionDestroyed event, I check if the remoting connection is ready to be closed.
If true (normal case), I remove the connection from the remoting service and destroy it.
else, I do nothing, the connection and the resources will be cleaned up when the connection TTL is hit.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4212973#4212973
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4212973
16 years, 10 months