-
1. Re: Behavior with AbstractKernelController
starksm64 Aug 22, 2006 1:12 AM (in response to anil.saldhana)The problem is that the start exception thrown by the DynamicLoginConfig.startService method is transititioning the ServiceControllerContext to an error state, but no exception is thrown from the ServiceController.start(ObjectName) method.
ServiceControllerContext@256bf3{name=jboss:service=TestDynamicLoginConfig target=null state=**ERROR** mode=Manual requiredState=Installed depends=AbstractDependencyInfo@e2e2bf{idependOn=[]} error=java.lang.IllegalStateException: AuthConfig is defaulting to conf/login-config.xml. Please check your archive. at org.jboss.security.auth.login.DynamicLoginConfig.validateAuthConfigURL(DynamicLoginConfig.java:271) at org.jboss.security.auth.login.DynamicLoginConfig.startService(DynamicLoginConfig.java:219) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:167) at $Proxy0.start()V(Unknown Source) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42) at org.jboss.system.microcontainer.ServiceControllerContextAction.install(ServiceControllerContextAction.java:46) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:226) at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:198) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:429) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:538) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:472) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:320) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190) at org.jboss.system.ServiceController.doChange(ServiceController.java:632) at org.jboss.system.ServiceController.start(ServiceController.java:407) }
The test fails at this point because it was expecting an exception to be thrown from the start attempt. -
2. Re: Behavior with AbstractKernelController
anil.saldhana Aug 22, 2006 8:56 AM (in response to anil.saldhana)Additionally, the ServiceController, once reaches the "Error" state is shut off for a stop or undeploy or redeploy attempts, for the service in question.
-
3. Re: Behavior with AbstractKernelController
starksm64 Aug 22, 2006 4:40 PM (in response to anil.saldhana)Right. I'll go through the jmx tests in the MC_VDF_WORK branch and create one that represents what needs to happen for this usage to be able to talk about what needs to be changed.
-
4. Re: Behavior with AbstractKernelController
anil.saldhana Aug 23, 2006 10:51 AM (in response to anil.saldhana)Adran says:
The behaviour is not "inconsistent". In fact, it is more consistent now. In the past, invoking "start" never actually guaranteed the service started. It would only actually do the start() if all the dependencies were satisfied. Later you might actually get the start when the correct dependency is added. In fact, the code you show didn't even work properly until less than 2 years ago when I made it redirect through the service controller (under the hood in ServiceMBeanSupport). Now with the introduction of the MC, everything is done consistently. Your code should be (and always should have been if you want things to work properly) ServiceController.start(ObjectName); followed by ServiceController.getServiceContext(ObjectName) to check what state it is actually in, i.e. dependencies satisfied, the error/problem, etc. See the deployment tests, that I wrote when I was fixing all this a while ago, if you want to see the correct pattern in more detail.
-
5. Re: Behavior with AbstractKernelController
starksm64 Aug 23, 2006 11:57 AM (in response to anil.saldhana)Ok, but the issue is what usage constructs that work today should continue to work? All of the usages that are now failing need to be documented in terms of tests and either resolved as invalid or support added to the JMX/MC integration layer.
-
6. Re: Behavior with AbstractKernelController
anil.saldhana Aug 23, 2006 3:08 PM (in response to anil.saldhana)I have updated the testcase to use the ServiceController to create/start/stop/destroy a service (and look into its ServiceContext to give me the state of the service at any time).
The test in question is:ant -Dtest=org.jboss.test.security.test.DynamicLoginConfigServiceUnitTestCase one-test
Currently I see three issues:
a) I am unable to set an attribute on a service that has been created but failed to start (in FAILED state).
b) I cannot destroy a service that is in FAILED state but has been created.
b) Against a running JBoss instance, if you run the same test a second time, you will see issues because the previous run did not destroy the service. -
7. Re: Behavior with AbstractKernelController
starksm64 Aug 23, 2006 10:27 PM (in response to anil.saldhana)The lack of an exception from the start attempt is a red-herring as this is not working anyway. The lack of an exception is masked by the catch(Throwable t) which is catching the junit fail call. If this is changed to:
try { server.invoke(serviceOName,"create", new Object[0], new String[0]); server.invoke(serviceOName,"start", new Object[0], new String[0]); fail("Service should not have started"); } catch(Exception t) { log.debug("Service has rightly disagreed to start",t); }
the test fails. The state of the service needs to be queried to ensure that is started rather than relying on getting an exception back. -
8. Re: Behavior with AbstractKernelController
anil.saldhana Aug 24, 2006 8:22 AM (in response to anil.saldhana)Scott, my last post was after I had totally revamped the testcase to use the ServiceControllerMBean to do the deployment and query for the state of the service.
-
9. Re: Behavior with AbstractKernelController
starksm64 Aug 24, 2006 10:54 AM (in response to anil.saldhana)I was talking about the 4.0 branch version.
-
10. Re: Behavior with AbstractKernelController
anil.saldhana Aug 24, 2006 10:57 AM (in response to anil.saldhana)I synched up the 4.0 testcase also to use the ServiceController. Now the tests pass and I can run the test multiple times and it passes fine.
While the testcase in HEAD clearly shows that once the service has "failed" to start, I cannot "set an attribute" and I cannot "destroy" the service. -
11. Re: Behavior with AbstractKernelController
starksm64 Aug 25, 2006 3:22 PM (in response to anil.saldhana)The test runs multiple times now in head, but fails at each point because of:
junit.framework.ComparisonFailure: state is Destroyed expected:<DESTROY...> but was:<FAIL...> at junit.framework.Assert.assertEquals(Assert.java:81) at org.jboss.test.security.test.DynamicLoginConfigServiceUnitTestCase.testAuthConf(DynamicLoginConfigServiceUnitTestCase.java:165)
There is a change in the ServiceController to ignore requests to destroy a service that is in a FAILED state. Previouly only requests for services in ServiceContext.DESTROYED or ServiceContext.NOTYETINSTALLED were ignored.2006-08-25 12:01:26,641 DEBUG [org.jboss.system.ServiceController] destroying se rvice: jboss:service=TestDynamicLoginConfig 2006-08-25 12:01:26,641 DEBUG [org.jboss.system.ServiceController] Ignoring dest roy request for service: jboss:service=TestDynamicLoginConfig at state FAILED
If we want backward compatibility we need to define the service state machine diagram with all transitions and require the same under the mc. I'm doubtful that this would be useful as we really should not allow a service to go from an error state liked FAILED to DESTROYED. At this point the service state diagram needs to be defined along with the expected semantics and code updated to conform to it in my view. -
12. Re: Behavior with AbstractKernelController
anil.saldhana Aug 25, 2006 4:16 PM (in response to anil.saldhana)What about deregistering the service from the MBeanServer if it has reached FAILED state?
In my testcase, the destroy is done to cleanup. I can change it to explicity deregister an mbean, because in my preparexxxx method, I do a register on a mbean with the server. -
13. Re: Behavior with AbstractKernelController
anil.saldhana Aug 25, 2006 4:55 PM (in response to anil.saldhana)Thanks Scott for the testcase cleanup.