OK, it seems the situation is much as I thought.
I will try to explain the problem a bit and then propose a solution.
Basically the persistence manager, when it is started, needs to restore from
its persistent store any messages that were left from the last run of the MQ
service. For it to be able to do this effectively it needs to know what
queues there are that are supposed to exist in the system. Hence the queues
that are created at startup need to be registered with the jms server (and
hence the persistence manager) before the persistence manager is started.
This means that the persistence manager needs to be created and initialised
first, then have the various queues and topics initialised before the PM is
started. Clearly this means a two step startup process because of the
dependencies between the mbeans.
In more general terms the only reason I can see for needing a two step
startup process is if such dependencies exist between mbeans. For example
if mbean B requires mbean A to be initialised before it is initialised AND
mbean A requires mbean B to be initialised before it is started then the two
step init start process is required to correctly start these two mbeans. As
in:
init mbean A
init mbean B
start mbean A
start mbean B
If the only dependency that exists is that mbean B needs mbean A to be
started before it is started then a simple one step start process should be
enough.
If this is going to be a general problem then we will need a generic
mechanism for dealing with this dependency (the "Unit deployment" you
mentioned?). If however the only place it exists is between the mbeans of
jbossmq then the answer is that the individual queues, topics, persistent
managers etc should not be mbeans.
If you want to do the first then there should be no problem bundling MQ as a
sar or jsr. If we want to do the second we need to change a bit of code and
do away with all the mbeans (QueueManager, TopicManager, PersistenceManager,
StateManager and ServerILService) that someone (Hiram?) quite recently
created and move the MQ configuration back into a seperate XML file that is
loaded by a single JBossMQService mbean. In this case I would be keen for
the input of whoever made these changes. Why exactly were they made and is
it the end of the world if we undo them.
So my basic question is, do you think this co-dependency between mbeans is
likely to occur elsewhere?
IMHO the dependency only exists because there are too many mbeans in the
jbossMQ setup. An mbean should define an entire service not a part of a
service that is co-dependent with another mbean (in that the both need the
other to work). One mbean using another mbean service (like a DataSource or
JNDI service) is obviously fine, but co-dependent mbeans I'm not so sure
about.
David
> -----Original Message-----
> From: marc fleury [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 05, 2001 12:26 AM
> To: David Maplesden; JBossDev (E-mail)
> Subject: RE: [JBoss-dev] RH startup and JBossMQ
>
>
> |I think we have a problem with RH and jbossmq. With the
> advent of Marc's
> |changes the order in which the mbeans are initialised and
> started seems to
> |have changed. Previously all mbeans listed in the
> jboss.jcml file where
> |initialised before any where started. This meant that when
> the Persistence
> |Manager was started the queues had already been initialised
> and the PM knew
> |which queues it had to try to restore from persistant backup storage.
>
> Yes for that to happen we would have to change the way
> services are started.
>
> Previously there was one xml list and everyone was
> initialized together and
> started together.
>
> To be able to deploy services independently I broke this to individual
> Elements and each is initialized/started as an individual
> unit. It still
> respects the order of the Elements.
>
> If you need an init together and started together I recommend
> coding that as
> part of a "Unit" deployment. That unit can be embodied in a
> jboss-service.xml file with Elements signifying init first
> start then as
> unit. The simplest, in that view would be to come up with a MQ sar.
>
> Then another angle is, is there any way for you to do what
> you do but in one
> step? do you *really* need the init/start steps (as in *2*
> steps) can you
> make it in one step? Init/start is not really used as a
> combo throughout
> the server and there has been talk of removing one.
>
> I am curious to see a case where you really need the two steps.
>
> |Now it seems that each mbean is initialised and then started
> |before the next
> |is initialised. They are still processed in order (now defined by
> |jboss-services.xml) but each one is started before the next
> is initialised.
>
> correct needed if we want independence. The better option is the Unit
> signified by snippets of services that we could initialize as
> one (and then
> keep the URL/set of service association so as to
> init/start/stop/destroy
> together as a unit, but again do you really need the 4 steps?)
>
> |If this is the case (and I'm pretty sure it is) then it will
> break the
> |restoration processes in jbossmq.
>
> Make sure that you need 4 steps and not 2, is that your final answer?
>
> |My question then is could we change the startup process back
> to how it was
> |before or do we change the jbossmq restoration to work with
> the new startup
>
> No I can't change to what it was before for the simple reason
> that before
> stuck the configuration.
>
> what we can do is
> 1- make sure that you need the 2 step init/start. Everyone
> is not down with
> the "init" and jsr77 is modeling only a start on services (no
> 2 steps). I
> tried pushing the 2 steps but it seems no one uses this.
> Maybe it is not
> needed?
> 2- If you *really* need a 2 step init/start over many beans
> then I would
> need to code that support, which might not be too difficult
> but will take me
> some hours.
>
> |process. This change to jbossmq may be quite tricky (its hard to
> |tell until
> |I have a good look at it) and I am not that keen to do it.
> However if RH
>
> Please have that hard look if you determine that a 2 step
> init/start is
> necessary, first double check again, then show me that
> example clearly as I
> would love to take it to JSR77
>
> |startup process is the result of a fundamental change in how
> mbeans are
> |loaded and managed then jbossmq will just have to be fixed.
>
> Nah don't start taking out the big words, not just yet. There is a
> fundamental change in how and where we load the beans, but it
> shouldn't
> affect you that much, it is just the init start steps
>
> |
> |Cheers
> |David
> |
> |PS: I have also had issues with the security mechanisms in RH.
> |The problem
> |is that currently it ignores the server.policy file, which
> usually is fine
> |since no SecurityManager is installed. However we have a
> custom service we
> |are writing that uses RMI and hence requires a SecurityManager.
> |Unfortunately as soon as we install one because the
> server.policy file has
> |not been loaded there are all sorts of access restrictions
> that come into
> |play that effectively stuff the whole server.
>
> The security stuff was hardcoded in the Main. I want this to be a JMX
> configured service. Hence the commented code in Main.
>
> |I tried to fix this by using the SecurityPolicyService mbean
> to implement a
> |security policy but it uses an xml policy file and I can't
> seem to get the
> |right syntax for it. I took an educated guess (based on one
> in the test
> |directory of the security module) but it doesn't seem to
> work. If anyone
> |has any ideas (Scott this is your area, right?) then I would
> appreciate a
> |helping hand. What I am basically asking for is a pointer
> to the correct
> |syntax for the xml file or how to run jboss using a
> convential policy file
> |(like server.policy).
> |
> | (xml file I am using for policy)
> |
> | <?xml version = "1.0" encoding = "UTF-8"?>
> | <policy>
> |
> | <application-policy name = "other">
> | <authorization>
> | <grant>
> | <permission code = "java.security.AllPermission"/>
> | </grant>
> | </authorization>
> | </application-policy>
> |
> | </policy>
> |
>
> I will work with Scott to get the security stuff going in RH.
>
> I need to spend another day on the slides for the London
> training next week
> and will try to code something before next Saturday.
>
> marcf
>
>
> _______________________________________________
> 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
