On 2001.11.13 11:34:39 -0500 Bill Burke wrote: > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > David > > Jencks > > Sent: Tuesday, November 13, 2001 9:03 AM > > To: Sacha Labourey > > Cc: Bill Burke; David Jencks; Andreas Schaefer; > > [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering > > > > > > Does this mean that the dependencies can go like this? > >
(I added missing name attributes to the mbean-ref's) > > > > <mbean code="org.jboss.ha.framework.server.ClusterPartition" > > name="JBOSS-SYSTEM:service=DefaultPartition"> > > </mbean> > > > > <mbean code="org.jboss.ha.hasessionstate.server.HASessionStateService" > > name="JBOSS-SYSTEM:service=HASessionState"> > > <mbean-ref >name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition</mbean-ref> > > </mbean> > > > > > > <mbean code="org.jboss.ha.jndi.HANamingService" > > name="JBOSS-SYSTEM:service=HAJNDI"> > > <mbean-ref >name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition</mbean-ref> > > </mbean> > > > > > > rather than like this: > > > > > > <mbean code="org.jboss.ha.framework.server.ClusterPartition" > > name="JBOSS-SYSTEM:service=DefaultPartition"> > > <mbean-ref-list name="SynchronizedMBeans"> > > > > <mbean-ref-list-element>JBOSS-SYSTEM:service=HASessionState</mbean > > -ref-list-element> > > > > <mbean-ref-list-element>JBOSS-SYSTEM:service=HAJNDI</mbean-ref-lis > > t-element> > > </mbean-ref-list> > > </mbean> > > > > <mbean code="org.jboss.ha.hasessionstate.server.HASessionStateService" > > name="JBOSS-SYSTEM:service=HASessionState"> > > </mbean> > > > > > > <mbean code="org.jboss.ha.jndi.HANamingService" > > name="JBOSS-SYSTEM:service=HAJNDI"> > > </mbean> > > > > ? > > > > How soon? Would you like a fix for the current situation based on the > > second example which is more or less how the system works now (I think > I > > have such a fix nearly working, but it's always hard to know what > "nearly" > > means) or is it ok to wait for the first method based on possible > > JavaGroups changes? > > > > No, we cannot wait for JavaGroups changes. Was Sacha hining that the changes toward hot-deploy (option 1) might be possible with the latest released JavaGroups? This needs to work. Please > do > not modify the code yourself. I'll do the work, just point me to an > example > of how I can access the mbean-ref-list. I'll send you what I have so far. You can also look at ConnectionFactoryLoader and in jbossmq for other examples of this stuff at work. BTW, with the mbean-ref-list > example can you please describe to me how calls are ordered? What MBeans > get created first? What order does start() get called? The mbeans are created and configured in what ever order they happen to be encountered by the autodeployer/ServiceDeployer/code directly calling ServiceDeployer etc. ServiceConfigurator returns a list of objectnames referenced in mbean-ref and mbean-ref-list/mbean-ref-list-element elements. The ServiceController finds out if all of these have been started: if so it registers (with itself) and starts the mbean. If not, it waits, and every time an mbean is started checks to see if all dependencies are satisfied for waiting beans. Once all the dependencies are satisfied for a waiting mbean, it is started. The reverse happens when you stop or undeploy an mbean. To look at the examples, in the first format the ClusterPartition can be started immediately, since it has no mbean-refs. No matter when the HASessionState and HAJNDI mbeans are encountered (i.e. before the ClusterPartition mbean), they will not be started until after the ClusterPartition mbean is started. In the second format, the ClusterPartition mbean will be created and configured, but not started until after the HASessionState and HAJNDI mbeans are started. > > <flame> > BTW, nobody has explained to me yet WHY YOU ARE REMOVING INIT. All your > suggestions are just hacks and will muddy the design and complicate it. > Honestly, I'm extremely annoyed that I have to go back to code that had > worked before just because somebody doesn't like init(). Could somebody > please explain why removing init() is so important and how it is such a > critical thing for the JMX framework? > </flame> > <counter-flame ;-)> Well, I thought I did explain it several times repeatedly over the last 2 months, I'll try again. 1. Proper use of init is to set up stuff that DOES NOT depend or reference anything outside of the current mbean. (see Rickard's posts) yesterday 2. Use of init in violation of (1) makes sense only if there is a deployment unit larger than 1 mbean, so you can have m1.init() m2.init() m1.start() m2.start() for a deployment unit consisting of m1, m2. 3. If you have a deployment unit larger than one mbean, as in 2, and ignore (1), and have an n-step startup process start1, start2, start3,...startn, I can easily create some mbeans that rely on this process and the ordering of the mbeans in the deployment unit. Obviously this does not mean that the n-step startup process is architecturally reasonable or privileged in some way. What it does show is that it is possible to rely on more or less accidental dependency relationships in the deplyment mechanism to conceal the actual dependencies. </counter-flame> (I hope its the end;-))) Hmm, lets try again. In the hot-deploy environment of jboss 3, we need some way of indicating dependencies between mbeans so we don't try to start things before the services they need to start are present and started. We do have a concept of a deployment unit, the *service.xml file, although it is equally possible to deploy a single mbean through code. There are 4 possible dependency relationships: package requires package. I tried this first with recursive sar deployment. It sucks. There is essentially no way to keep track of what is happening. package requires mbean. This is David Maplesden's depends tag. It works, but requires manual maintenance of the depends tag contents, and these contents cannot be checked in any way by the system. It conceals actual mbean-mbean dependencies. mbean requires package. I can't see any reason to try this one, it seems to combine the worst features of all the others. mbean requires mbean. (mbean-ref, mbean-ref-list elements). Here, if an mbean A requires another mbean B to work, this is made explicit: mbean A has a mbean-ref to mbean B, so it doesn't have to have mbean B's hardcoded name or rely on jndi, it gets an actual reference to mbean B and is guaranteed that mbean B is started before it is started. In my experience this results in much cleaner more comprehensible code with fewer hardcoded magic strings and complicated workaround mechanisms. However, it makes it nearly impossible to rely on the order of mbeans in a deployment unit for anything: the only way this could work is if the deployer computed a deployment order based on the dependencies in a deployment unit, ignoring the physical order in the deployment descriptor, and made n passes through this list (for an n-step startup process). However, once you express the dependencies through mbean-refs, you know what order the beans will be started in (as far as it matters), and can use inter-bean method calls to transfer information in the appropriate order, without relying on accidental features of the deployment architecture. Look, I apologize for this breaking the cluster code, I will do whatever I can to help fix it. I would like to know if you have any suggestions on how I could have provided more warning about the effects or found out that the code was breaking. I've been talking about this change for more than a month, mostly in regards to the jbossmq code, which I could identify as breaking, and (I think) fixed before checking in the changes. thanks David Jencks > > Bill > > > > Thanks > > david jencks > > > > > > On 2001.11.13 03:23:23 -0500 Sacha Labourey wrote: > > > Hello, > > > > > > > Unfortunately at this moment in time it is not possible to > > hot-deploy a > > > > clustered service that depends on state-transfer. You can > hot-deploy > > > > clustered EJBs though, well at least for SLSB and EBs. Sacha, what > > > about > > > > SFSBs? > > > > > > Yes, it is possible. > > > > > > Next step on my todo list is to speak with Bela about how to > implement > > > clean > > > "local" state transfer and merge protocols. Once done, this should > solve > > > our > > > problems. > > > > > > BTW Bill, have you seen that JG 1.0 is out with some bug fixes and > new > > > features (such as merge2 protocol layer) > > > > > > cheers, > > > > > > > > > > > > Sacha > > > > > > > > > > > > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
