The reply to all "feature" is still biting... Thanks!
Will this work? (first conceptually, then how much change would it take) I take it there are several queues for each persistence manager. A queue has a dependency (mbean ref) to a persistence manager. If the queue gets deployed first, it waits till the persistence manager has had start() called on it. The persistence manager does whatever queue- independent startup stuff it needs to do in init() and start() After the persistence manager starts, (or anytime later if a queue happens to get started second), the queue gets init and start called: in one of these it asks the persistence manager to give it back its persistent messages. Since it depends on the mbean-ref to the persistence manager, the persistence manager will be there. The main difference between this and what happens now is that the queues are restored one at a time rather than all at once. Is there some structural reason all the queues need to be restored at once? To my uneducated mind I would think there might be some advantages to being able to restore them one at a time independently. Many thanks for the example david jencks On 2001.10.04 13:43:19 -0400 Hiram Chirino wrote: > > The reason the David M. did that is due to the way that JBossMQ starts up > > it's Queues... The startup sequence is something along the lines of: > > 1. MQ Persistence Manager inits > 2. Queue inits = registers itself with the Persistence Manager > 3. MQ Persistence Manager starts() = restores persitence messages to the > registered queues. > 4. Queues starts() = queues bind to JNDI. > > Maybe this startup sequence should not be used. But the thing we need is > a > signal to the Persistence Manager to restore messages to all the queues > that > have registered. > > >From: David Jencks <[EMAIL PROTECTED]> > >To: jboss-dev <[EMAIL PROTECTED]> > >Subject: [JBoss-dev] Why do init, start, etc have to be done per > deployment > >unit? (rh/3.0) > >Date: Thu, 4 Oct 2001 12:31:53 -0400 > > > >Hi, > > > >When Marc put in the new classloading stuff for 3.0, he had each mbean > >being configured, inited, and started individually (although in the > order > >of the *service.xml file). > > > >David Maplesden added some package depending on mbean dependency control > >and changed the config/init/start to do each step to the entire > deployment > >unit (as it is in 2.4). > > > >I am in the process of making the dependencies operate on an mbean to > mbean > >level by means of mbean references and would like to change this process > >back to config/init/start mbean by mbean. > > > >Given mbean to mbean dependencies, will this cause any problems? Please > >give a specific example. I didn't catch David M's example when he made > the > >first change. > > > > > >Heres an example of the mbean references/ dependencies at work: > > > > > > <mbean code="org.jboss.test.jmx.mbeanconfigure.TestMBeanA" > > name="test:name=TestMBeanA"> > > <mbean-ref > >name="Mbeanb">test:name=TestMBeanB</mbean-ref><!--ObjectName > >valued attribute get/setMbeanb--> > > <mbean-ref-list name="Mbeans"> <!--list valued attribute, elements > are > >ObjectNames--> > > > ><mbean-ref-list-element>test:name=TestMBeanB</mbean-ref-list-element> > > > >><mbean-ref-list-element>JBOSS-SYSTEM:service=TransactionManager</mbean-ref-list-element> > > </mbean-ref-list> > > </mbean> > > > ><!--TestMBeanA will be suspended waiting for TestMBeanB when it is first > >deployed --> > > > > <mbean code="org.jboss.test.jmx.mbeanconfigure.TestMBeanB" > > name="test:name=TestMBeanB"> > > <mbean-ref name="Mbeana">test:name=TestMBeanA</mbean-ref> > > </mbean> > > > ><!-- TestMBeanB will find TestMBeanA, so it can deploy completely. Once > it > >is started, its dependencies are checked, allowing (if the tm is > present!) > >TestMBeanA to finish deploying --> > > > >Suggestions for better element names will be appreciated. > > > >I am planning to use these two new elements in the mbean element because > >they have such different semantics than the existing attribute element. > > > >Thanks! > > > >David Jencks > > > >_______________________________________________ > >Jboss-development mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/jboss-development > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
