-
1. Re: Singleton persistence archive, datasource?
huberth Nov 10, 2006 9:45 AM (in response to huberth)Forgot to mention...
I'm using 4.0.4.GA, with EJB3. -
2. Re: Singleton persistence archive, datasource?
brian.stansberry Nov 10, 2006 2:24 PM (in response to huberth)What did the "depends" element you added to the persistence archjve look like?
Also, does packaging the persistence archive and the -ds.xml together in a sar help?
I'm thinking this is due with the fact that the deploy-hasingleton folder is deployed as a deployment itself, all of the items contained within deploy-hasingleton are then deployed as sub-deployments of the parent deployment. A side effect of this is normal deployment ordering rules do not apply.
Another thing to look at for a workaround is using the BarrierController discussed on http://wiki.jboss.org/wiki/Wiki.jsp?page=HASingletonDeployer. -
3. Re: Singleton persistence archive, datasource?
huberth Nov 10, 2006 3:08 PM (in response to huberth)I copied the object name from the log output :
I just tried packaging in a sar but I get the same result.
I have actually been playing with a barrier mbean as well to find a work-around for this issue. What I did is move all of my par's, dependent ear's, and the datasource definition into a different (i.e. made up by me) deploy directory. Then when my mbean is 'started' I call on the main deployer to deploy that directory, and vice-versa when 'stopped'. This all seems to go cleanly. Do you see any issues with such an approach?
Honestly, I thought this approach would have led to the same problems, but I tried it as a first step... the next step would have been to stage the deploy and undeploy in separate directories, in dependency order. -
4. Re: Singleton persistence archive, datasource?
huberth Nov 10, 2006 3:12 PM (in response to huberth)I don't know what happeend to my property definition in that post. I checked the 'Disable HTML in this post' box... did I misunderstand the meaning of that?
Anyway, here it is, minus the angle-brackets just to be safe:
property name="jboss.depends.1" value="jboss.jca:name=tpapps-ds,service=ManagedConnectionFactory" -
5. Re: Singleton persistence archive, datasource?
huberth Nov 10, 2006 4:17 PM (in response to huberth)While we're on barriers, the documentation seems to suggest that a singleton barrier mbean will have it's 'create' method called at system startup, deferring the 'start' method call until the node becomes the master.
I'm not seeing my create method get called until the node becomes master either.
Which way is it supposed to work? -
6. Re: Singleton persistence archive, datasource?
brian.stansberry Nov 10, 2006 4:55 PM (in response to huberth)Responding to various points...
1) I don't know what "Disable HTML" does. But I do know you have to use the Code button above the input box to get XML to appear correctly :)
2) What does the descriptor for your service that deploys from another directory look like? Sounds very much like the deployer for deploy-hasingleton (which is the first mbean in the deploy/deploy-hasingleton-service.xml file). So I agree - it's odd it worked differently
3) For a dependency, try jboss.jca:name=tpapps-ds,service=DataSourceBinding
That's the service that actually binds your datasource in JNDI.
4) My reading of the docs and of the org.jboss.system.BarrierController code leads me to expect your create() should be called after deploy, with start() deferred until the node becomes master. Not sure why you're not seeing that. -
7. Re: Singleton persistence archive, datasource?
huberth Nov 13, 2006 10:01 AM (in response to huberth)First of all, thanks alot for the prompt replies!
And in response to:
1) Thanks, I'll make sure I do that.
2) The jboss-service.xml is just a stub (empty server tag), as we rely exclusively on annotations. Here are the annotations, though:@Management(DatabaseManager.class) @Service(objectName = "my.domain:service=DatabaseManager") @RemoteBinding(jndiBinding = DatabaseManager.JNDI_NAME) @Depends("jboss.ha:service=HASingletonDeployer,type=Barrier")
The create method, for now, just logs that it is being called.
The start method finds the MainDeployer (MBeanServerLocator.locateJBoss, MBeanServerInvocationHandler.newProxyInstance, objectName="jboss.system:service=MainDeployer", etc), and calls deploy on it, passing the directory's url (file:/..../server/default/deploy-db/).
The stop method is the same as start, except, of course, it calls undeploy.
3) Changing the dependency works. Everything seems to come up without incident. Given your comment in 2) about it being odd that it worked differently, I presume that even if I go the barrier-controller route, it'd be wise to keep this dependency, yes?
I'd like to go with the barrier-controller as it gives me more precise control over the timing of the replication management tasks relative to shutting down or starting up the db services.
4) It definitely does not call create until the subsequent switch-over. Here's the stack trace at the point at which my create method is called:Thread "AsynchKeyChangeHandler Thread"@4,007 in group "jboss" status: RUNNING create():49, my.domain.databasemanager.DatabaseManagerMBean invoke0():-1, sun.reflect.NativeMethodAccessorImpl invoke():39, sun.reflect.NativeMethodAccessorImpl invoke():25, sun.reflect.DelegatingMethodAccessorImpl invoke():585, java.lang.reflect.Method invokeNext():109, org.jboss.aop.joinpoint.MethodInvocation invoke():54, org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation invoke():47, org.jboss.ejb3.AllowedOperationsInterceptor invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation invokeInOurTx():79, org.jboss.aspects.tx.TxPolicy invoke():192, org.jboss.aspects.tx.TxInterceptor$Required invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation invoke():76, org.jboss.aspects.tx.TxPropagationInterceptor invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation invoke():78, org.jboss.aspects.security.AuthenticationInterceptor invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation invoke():47, org.jboss.ejb3.ENCPropagationInterceptor invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation invoke():106, org.jboss.ejb3.asynchronous.AsynchronousInterceptor invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation localInvoke():181, org.jboss.ejb3.service.ServiceContainer localInvoke():142, org.jboss.ejb3.service.ServiceContainer invoke():168, org.jboss.ejb3.service.ServiceMBeanDelegate invoke():164, org.jboss.mx.server.RawDynamicInvoker invoke():659, org.jboss.mx.server.MBeanServerImpl invoke():995, org.jboss.system.ServiceController$ServiceProxy create():-1, $Proxy0 create():330, org.jboss.system.ServiceController invoke0():-1, sun.reflect.NativeMethodAccessorImpl invoke():39, sun.reflect.NativeMethodAccessorImpl invoke():25, sun.reflect.DelegatingMethodAccessorImpl invoke():585, java.lang.reflect.Method invoke():155, org.jboss.mx.interceptor.ReflectedDispatcher dispatch():94, org.jboss.mx.server.Invocation invoke():86, org.jboss.mx.server.Invocation invoke():264, org.jboss.mx.server.AbstractMBeanInvoker invoke():659, org.jboss.mx.server.MBeanServerImpl invoke():210, org.jboss.mx.util.MBeanProxyExt create():-1, $Proxy128 installMBean():109, org.jboss.ejb3.JmxKernelAbstraction registerManagementInterface():352, org.jboss.ejb3.service.ServiceContainer start():92, org.jboss.ejb3.service.ServiceContainer invoke0():-1, sun.reflect.NativeMethodAccessorImpl invoke():39, sun.reflect.NativeMethodAccessorImpl invoke():25, sun.reflect.DelegatingMethodAccessorImpl invoke():585, java.lang.reflect.Method startService():99, org.jboss.ejb3.ServiceDelegateWrapper jbossInternalStart():289, org.jboss.system.ServiceMBeanSupport jbossInternalLifecycle():245, org.jboss.system.ServiceMBeanSupport invoke():-1, sun.reflect.GeneratedMethodAccessor2 invoke():25, sun.reflect.DelegatingMethodAccessorImpl invoke():585, java.lang.reflect.Method invoke():155, org.jboss.mx.interceptor.ReflectedDispatcher dispatch():94, org.jboss.mx.server.Invocation invoke():86, org.jboss.mx.server.Invocation invoke():264, org.jboss.mx.server.AbstractMBeanInvoker invoke():659, org.jboss.mx.server.MBeanServerImpl invoke():978, org.jboss.system.ServiceController$ServiceProxy start():-1, $Proxy0 start():417, org.jboss.system.ServiceController start():435, org.jboss.system.ServiceController invoke():-1, sun.reflect.GeneratedMethodAccessor9 invoke():25, sun.reflect.DelegatingMethodAccessorImpl invoke():585, java.lang.reflect.Method invoke():155, org.jboss.mx.interceptor.ReflectedDispatcher dispatch():94, org.jboss.mx.server.Invocation invoke():86, org.jboss.mx.server.Invocation invoke():264, org.jboss.mx.server.AbstractMBeanInvoker invoke():659, org.jboss.mx.server.MBeanServerImpl start():194, org.jboss.system.ServiceMBeanSupport startBarrier():334, org.jboss.system.BarrierController handleNotification2():313, org.jboss.system.BarrierController handleNotification():403, org.jboss.system.ListenerServiceMBeanSupport invoke():-1, sun.reflect.GeneratedMethodAccessor3 invoke():25, sun.reflect.DelegatingMethodAccessorImpl invoke():585, java.lang.reflect.Method invoke():153, org.jboss.mx.notification.NotificationListenerProxy handleNotification():-1, $Proxy101 handleNotification():127, org.jboss.mx.util.JBossNotificationBroadcasterSupport sendNotification():110, org.jboss.mx.util.JBossNotificationBroadcasterSupport sendNotificationToLocalListeners():354, org.jboss.ha.jmx.HAServiceMBeanSupport sendLocalNotification():213, org.jboss.ha.singleton.HASingletonSupport makeThisNodeMaster():200, org.jboss.ha.singleton.HASingletonSupport partitionTopologyChanged():133, org.jboss.ha.singleton.HASingletonSupport replicantsChanged():243, org.jboss.ha.jmx.HAServiceMBeanSupport$1 notifyKeyListeners():844, org.jboss.ha.framework.server.DistributedReplicantManagerImpl processEvent():386, org.jboss.ha.framework.server.DistributedReplicantManagerImpl run():107, org.jboss.ha.framework.server.AsynchEventHandler run():595, java.lang.Thread
Getting the create method called at system startup would be nice so I don't have to create yet another MBean just to know that the system started up.