Re: [JBoss-dev] RE: Deployment exception on Clustering

[Andreas Schaefer]

Hi David

You hear it. How can be use init() again for Clustering ?

Andy

- Original Message -
From: "Bill Burke" <[EMAIL PROTECTED]>
To: "Andreas Schaefer" <[EMAIL PROTECTED]>
Cc: "Sacha Labourey" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, November 12, 2001 1:10 PM
Subject: [JBoss-dev] RE: Deployment exception on Clustering


> Yes this a very serious problem and it wouldn't show up with your Farm
> stuff.  THis is my fault because I didn't document the code very well, but
> can we please switch this back?
>
> In the init phase, all services register with the cluster (HAPartition)
for
> cluster events that want to listen to and also if they require state
> synchronization.  In the start phase, the ClusterPartition mbean does the
> final Connect to the JavaGroups message Channel.  When the Connect
happens,
> state synchronization starts.  Services will not have their state
> synchronized if everything is done in the start phase.
>
> Bill
>
> > -Original Message-
> > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 12, 2001 3:50 PM
> > To: Bill Burke
> > Cc: Sacha Labourey; [EMAIL PROTECTED]
> > Subject: Re: Deployment exception on Clustering
> >
> >
> > Hi Bill
> >
> > I added all the code from init() into start(). Is this a problem ?
> >
> > At least when I use the Farm it works like a charm.
> >
> > Andy
> >
> > - Original Message -
> > From: "Bill Burke" <[EMAIL PROTECTED]>
> > To: "David Jencks" <[EMAIL PROTECTED]>; "Andreas Schaefer"
> > <[EMAIL PROTECTED]>
> > Cc: "Sacha Labourey" <[EMAIL PROTECTED]>;
> > <[EMAIL PROTECTED]>
> > Sent: Monday, November 12, 2001 12:59 PM
> > Subject: RE: Deployment exception on Clustering
> >
> >
> > > Guys,
> > >
> > > The clustering stuff is dependent on init and start both being
> > there.  Can
> > > we put back the init?  Otherwise you break our stuff.  Why are you
doing
> > > this anyways?
> > >
> > > Bill
> > >
> > > > -Original Message-
> > > > From: David Jencks [mailto:[EMAIL PROTECTED]]
> > > > Sent: Monday, November 12, 2001 2:33 PM
> > > > To: Andreas Schaefer
> > > > Cc: David Jencks; Bill Burke; Sacha Labourey;
> > > > [EMAIL PROTECTED]
> > > > Subject: Re: Deployment exception on Clustering
> > > >
> > > >
> > > > Thanks, must have missed that one.
> > > >
> > > > I generally copied the init[Service] code and put it in
start[Service]
> > at
> > > > the beginning, similarly for destroy.
> > > >
> > > > As far as I could tell, everything covered by the testsuite works as
> > well
> > > > after the changes as before.
> > > >
> > > > Please let me know of other problems.
> > > >
> > > > The Service interface still has init and destroy since these are
used
> > > > heavily in the interceptor chain.  I think they are unnecessary, but
> > won't
> > > > have time to try to change them for a while.  This could probably
> > > > be a part
> > > > if turning the interceptor chains into mbeans.
> > > >
> > > > Thanks!
> > > > david jencks
> > > >
> > > > On 2001.11.12 14:13:41 -0500 Andreas Schaefer wrote:
> > > > > Hi David
> > > > >
> > > > > The ClusterPartition.java class is not started correctly
> > > > > because now init() is not called anymore and therefore
> > > > > the JavaGroups JChannel are not initialized.
> > > > >
> > > > > I will go ahead and fix it but maybe there are other MBeans
> > > > > out there which needs attention, too.
> > > > >
> > > > > Thanx
> > > > >
> > > > > x
> > > > > Andreas Schaefer
> > > > > Senior Consultant
> > > > > JBoss Group, LLC
> > > > > x
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
>
>
>
> ___
> 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

RE: [JBoss-dev] RE: Deployment exception on Clustering

[Bill Burke]

Rickard talked about something called postRegister?

> -Original Message-
> From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 12, 2001 4:50 PM
> To: David Jencks
> Cc: Sacha Labourey; [EMAIL PROTECTED]; Bill Burke
> Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
> 
> 
> Hi David
> 
> You hear it. How can be use init() again for Clustering ?
> 
> Andy
> 
> - Original Message -
> From: "Bill Burke" <[EMAIL PROTECTED]>
> To: "Andreas Schaefer" <[EMAIL PROTECTED]>
> Cc: "Sacha Labourey" <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Monday, November 12, 2001 1:10 PM
> Subject: [JBoss-dev] RE: Deployment exception on Clustering
> 
> 
> > Yes this a very serious problem and it wouldn't show up with your Farm
> > stuff.  THis is my fault because I didn't document the code 
> very well, but
> > can we please switch this back?
> >
> > In the init phase, all services register with the cluster (HAPartition)
> for
> > cluster events that want to listen to and also if they require state
> > synchronization.  In the start phase, the ClusterPartition 
> mbean does the
> > final Connect to the JavaGroups message Channel.  When the Connect
> happens,
> > state synchronization starts.  Services will not have their state
> > synchronized if everything is done in the start phase.
> >
> > Bill
> >
> > > -Original Message-
> > > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, November 12, 2001 3:50 PM
> > > To: Bill Burke
> > > Cc: Sacha Labourey; [EMAIL PROTECTED]
> > > Subject: Re: Deployment exception on Clustering
> > >
> > >
> > > Hi Bill
> > >
> > > I added all the code from init() into start(). Is this a problem ?
> > >
> > > At least when I use the Farm it works like a charm.
> > >
> > > Andy
> > >
> > > - Original Message -
> > > From: "Bill Burke" <[EMAIL PROTECTED]>
> > > To: "David Jencks" <[EMAIL PROTECTED]>; 
> "Andreas Schaefer"
> > > <[EMAIL PROTECTED]>
> > > Cc: "Sacha Labourey" <[EMAIL PROTECTED]>;
> > > <[EMAIL PROTECTED]>
> > > Sent: Monday, November 12, 2001 12:59 PM
> > > Subject: RE: Deployment exception on Clustering
> > >
> > >
> > > > Guys,
> > > >
> > > > The clustering stuff is dependent on init and start both being
> > > there.  Can
> > > > we put back the init?  Otherwise you break our stuff.  Why are you
> doing
> > > > this anyways?
> > > >
> > > > Bill
> > > >
> > > > > -Original Message-
> > > > > From: David Jencks [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Monday, November 12, 2001 2:33 PM
> > > > > To: Andreas Schaefer
> > > > > Cc: David Jencks; Bill Burke; Sacha Labourey;
> > > > > [EMAIL PROTECTED]
> > > > > Subject: Re: Deployment exception on Clustering
> > > > >
> > > > >
> > > > > Thanks, must have missed that one.
> > > > >
> > > > > I generally copied the init[Service] code and put it in
> start[Service]
> > > at
> > > > > the beginning, similarly for destroy.
> > > > >
> > > > > As far as I could tell, everything covered by the 
> testsuite works as
> > > well
> > > > > after the changes as before.
> > > > >
> > > > > Please let me know of other problems.
> > > > >
> > > > > The Service interface still has init and destroy since these are
> used
> > > > > heavily in the interceptor chain.  I think they are 
> unnecessary, but
> > > won't
> > > > > have time to try to change them for a while.  This could probably
> > > > > be a part
> > > > > if turning the interceptor chains into mbeans.
> > > > >
> > > > > Thanks!
> > > > > david jencks
> > > > >
> > > > > On 2001.11.12 14:13:41 -0500 Andreas Schaefer wrote:
> > > > > > Hi David
> > > > > >
> > > > > > The ClusterPartition.java class is not started correctly
> > > > > > because now init() is not called anymore and therefore
> > > > > > the JavaGroups JChannel are not initialized.
> > > > > >
> > > > > > I will go ahead and fix it but maybe there are other MBeans
> > > > > > out there which needs attention, too.
> > > > > >
> > > > > > Thanx
> > > > > >
> > > > > > x
> > > > > > Andreas Schaefer
> > > > > > Senior Consultant
> > > > > > JBoss Group, LLC
> > > > > > x
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
> > ___
> > 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

Re: [JBoss-dev] RE: Deployment exception on Clustering

[Andreas Schaefer]

Hi

postRegister() is a callback method issued by the MBeanServer before the
MBean gets finally registered. You then can save the MBeanServer you are
connected to and change the MBean ObjectName before it is set.

I am still puzzled why you need a 2 stage startup process.
The only reason I can assume is that you subclass the ClusterPartition and
then overwrite initService(). Wouldn't it be better to add a method call in
the startService() method like postInit() which is placed in the middle of
startService() ?

Andy

- Original Message -
From: "Bill Burke" <[EMAIL PROTECTED]>
To: "Andreas Schaefer" <[EMAIL PROTECTED]>; "David Jencks"
<[EMAIL PROTECTED]>
Cc: "Sacha Labourey" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, November 12, 2001 2:04 PM
Subject: RE: [JBoss-dev] RE: Deployment exception on Clustering


> Rickard talked about something called postRegister?
>
> > -Original Message-
> > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 12, 2001 4:50 PM
> > To: David Jencks
> > Cc: Sacha Labourey; [EMAIL PROTECTED]; Bill Burke
> > Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
> >
> >
> > Hi David
> >
> > You hear it. How can be use init() again for Clustering ?
> >
> > Andy
> >
> > - Original Message -
> > From: "Bill Burke" <[EMAIL PROTECTED]>
> > To: "Andreas Schaefer" <[EMAIL PROTECTED]>
> > Cc: "Sacha Labourey" <[EMAIL PROTECTED]>;
> > <[EMAIL PROTECTED]>
> > Sent: Monday, November 12, 2001 1:10 PM
> > Subject: [JBoss-dev] RE: Deployment exception on Clustering
> >
> >
> > > Yes this a very serious problem and it wouldn't show up with your Farm
> > > stuff.  THis is my fault because I didn't document the code
> > very well, but
> > > can we please switch this back?
> > >
> > > In the init phase, all services register with the cluster
(HAPartition)
> > for
> > > cluster events that want to listen to and also if they require state
> > > synchronization.  In the start phase, the ClusterPartition
> > mbean does the
> > > final Connect to the JavaGroups message Channel.  When the Connect
> > happens,
> > > state synchronization starts.  Services will not have their state
> > > synchronized if everything is done in the start phase.
> > >
> > > Bill
> > >
> > > > -Original Message-
> > > > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> > > > Sent: Monday, November 12, 2001 3:50 PM
> > > > To: Bill Burke
> > > > Cc: Sacha Labourey; [EMAIL PROTECTED]
> > > > Subject: Re: Deployment exception on Clustering
> > > >
> > > >
> > > > Hi Bill
> > > >
> > > > I added all the code from init() into start(). Is this a problem ?
> > > >
> > > > At least when I use the Farm it works like a charm.
> > > >
> > > > Andy
> > > >
> > > > - Original Message -
> > > > From: "Bill Burke" <[EMAIL PROTECTED]>
> > > > To: "David Jencks" <[EMAIL PROTECTED]>;
> > "Andreas Schaefer"
> > > > <[EMAIL PROTECTED]>
> > > > Cc: "Sacha Labourey" <[EMAIL PROTECTED]>;
> > > > <[EMAIL PROTECTED]>
> > > > Sent: Monday, November 12, 2001 12:59 PM
> > > > Subject: RE: Deployment exception on Clustering
> > > >
> > > >
> > > > > Guys,
> > > > >
> > > > > The clustering stuff is dependent on init and start both being
> > > > there.  Can
> > > > > we put back the init?  Otherwise you break our stuff.  Why are you
> > doing
> > > > > this anyways?
> > > > >
> > > > > Bill
> > > > >
> > > > > > -Original Message-
> > > > > > From: David Jencks [mailto:[EMAIL PROTECTED]]
> > > > > > Sent: Monday, November 12, 2001 2:33 PM
> > > > > > To: Andreas Schaefer
> > > > > > Cc: David Jencks; Bill Burke; Sacha Labourey;
> > > > > > [EMAIL PROTECTED]
> > > > > > Subject: Re: Deployment exception on Clustering
> > > > > >
> > > > > >
> > > > > > Thanks, must have missed that one.
> > > > > >
> > > > > &

Re: [JBoss-dev] RE: Deployment exception on Clustering

[Scott M Stark]

It is a method of the MBeanRegistration interface that is called after the
MBean has been registered with the server. You could override it to
use it as a hook in place of init:

   public void postRegister(java.lang.Boolean registrationDone)
   {
   if( registrationDone.booleanValue() == true )
  {
 // Do initialization work that depends on no other JBoss
services...
  }
   }

This method is called as each bean is registered.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: "Bill Burke" <[EMAIL PROTECTED]>
To: "Andreas Schaefer" <[EMAIL PROTECTED]>; "David Jencks"
<[EMAIL PROTECTED]>
Cc: "Sacha Labourey" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, November 12, 2001 2:04 PM
Subject: RE: [JBoss-dev] RE: Deployment exception on Clustering


> Rickard talked about something called postRegister?
>
> > -Original Message-
> > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 12, 2001 4:50 PM
> > To: David Jencks
> > Cc: Sacha Labourey; [EMAIL PROTECTED]; Bill Burke
> > Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
> >
> >
> > Hi David
> >
> > You hear it. How can be use init() again for Clustering ?
> >
> > Andy
> >



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] RE: Deployment exception on Clustering

[Bill Burke]

> -Original Message-
> From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 12, 2001 5:17 PM
> To: Bill Burke
> Cc: Sacha Labourey; [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
>
>
> Hi
>
> postRegister() is a callback method issued by the MBeanServer before the
> MBean gets finally registered. You then can save the MBeanServer you are
> connected to and change the MBean ObjectName before it is set.
>
> I am still puzzled why you need a 2 stage startup process.
> The only reason I can assume is that you subclass the ClusterPartition and
> then overwrite initService(). Wouldn't it be better to add a
> method call in
> the startService() method like postInit() which is placed in the middle of
> startService() ?
>

I need a 2 stage startup because ClusterPartition creates an
HAPartition(This is the actual cluster object) in the init() phase.
MBean-managed HA services like HA-JNDI register themselves with the
HAPartition in the init() phase.  In the start() phase, the ClusterPartition
makes the Connection to the JavaGroups message Channel.  When the connection
is connected, the state-transfer protocol initiates.  In other words, HA
services(HA-JNDI) need to register with the ClusterPartition before the
cluster connections are set up.  Without the 2 phase approach,
initial-state-synchronization will not work.

Bill



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] RE: Deployment exception on Clustering

[David Jencks]

What are the mbean dependencies here? Is it possible to add a service to a
running cluster? How is it synchronized? (what does synchronized mean here,
anyway?).

If it is not possible to add a service to a started cluster, you should
document the contents of the cluster with an mbean-ref-list tag including
all mbean-ref-list-elements participating in the cluster.  The cluster can
then do whatever it wants with them, they will be started before the
cluster is started.

If it is possible to add a service to a started cluster, each service can
depend on the cluster, so it will be started after the cluster, and can get
whatever synchronization it needs set up when it starts.

What are the problems with this approach?  I used the second with jbossmq
startup.

thanks
david jencks

On 2001.11.12 16:10:27 -0500 Bill Burke wrote:
> Yes this a very serious problem and it wouldn't show up with your Farm
> stuff.  THis is my fault because I didn't document the code very well,
> but
> can we please switch this back?
> 
> In the init phase, all services register with the cluster (HAPartition)
> for
> cluster events that want to listen to and also if they require state
> synchronization.  In the start phase, the ClusterPartition mbean does the
> final Connect to the JavaGroups message Channel.  When the Connect
> happens,
> state synchronization starts.  Services will not have their state
> synchronized if everything is done in the start phase.
> 
> Bill
> 
> > -Original Message-
> > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 12, 2001 3:50 PM
> > To: Bill Burke
> > Cc: Sacha Labourey; [EMAIL PROTECTED]
> > Subject: Re: Deployment exception on Clustering
> >
> >
> > Hi Bill
> >
> > I added all the code from init() into start(). Is this a problem ?
> >
> > At least when I use the Farm it works like a charm.
> >
> > Andy
> >
> > - Original Message -
> > From: "Bill Burke" <[EMAIL PROTECTED]>
> > To: "David Jencks" <[EMAIL PROTECTED]>; "Andreas
> Schaefer"
> > <[EMAIL PROTECTED]>
> > Cc: "Sacha Labourey" <[EMAIL PROTECTED]>;
> > <[EMAIL PROTECTED]>
> > Sent: Monday, November 12, 2001 12:59 PM
> > Subject: RE: Deployment exception on Clustering
> >
> >
> > > Guys,
> > >
> > > The clustering stuff is dependent on init and start both being
> > there.  Can
> > > we put back the init?  Otherwise you break our stuff.  Why are you
> doing
> > > this anyways?
> > >
> > > Bill
> > >
> > > > -Original Message-
> > > > From: David Jencks [mailto:[EMAIL PROTECTED]]
> > > > Sent: Monday, November 12, 2001 2:33 PM
> > > > To: Andreas Schaefer
> > > > Cc: David Jencks; Bill Burke; Sacha Labourey;
> > > > [EMAIL PROTECTED]
> > > > Subject: Re: Deployment exception on Clustering
> > > >
> > > >
> > > > Thanks, must have missed that one.
> > > >
> > > > I generally copied the init[Service] code and put it in
> start[Service]
> > at
> > > > the beginning, similarly for destroy.
> > > >
> > > > As far as I could tell, everything covered by the testsuite works
> as
> > well
> > > > after the changes as before.
> > > >
> > > > Please let me know of other problems.
> > > >
> > > > The Service interface still has init and destroy since these are
> used
> > > > heavily in the interceptor chain.  I think they are unnecessary,
> but
> > won't
> > > > have time to try to change them for a while.  This could probably
> > > > be a part
> > > > if turning the interceptor chains into mbeans.
> > > >
> > > > Thanks!
> > > > david jencks
> > > >
> > > > On 2001.11.12 14:13:41 -0500 Andreas Schaefer wrote:
> > > > > Hi David
> > > > >
> > > > > The ClusterPartition.java class is not started correctly
> > > > > because now init() is not called anymore and therefore
> > > > > the JavaGroups JChannel are not initialized.
> > > > >
> > > > > I will go ahead and fix it but maybe there are other MBeans
> > > > > out there which needs attention, too.
> > > > >
> > > > > Thanx
> > > > >
> > > > > x
> > > > > Andreas Schaefer
> > > > > Senior Consultant
> > > > > JBoss Group, LLC
> > > > > x
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
> 
> 
> 
> ___
> 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

Re: [JBoss-dev] RE: Deployment exception on Clustering

[Andreas Schaefer]

Hi Bill

postRegister() is NOT an option because it is called after
the MBean is created (Constructor is called) but BEFORE
any attributes are set by the ServiceController.
And I see that you use PartitionProperties and PartitionName
which would not be available except you only use defaults.

Andy

- Original Message -
From: "Bill Burke" <[EMAIL PROTECTED]>
To: "Andreas Schaefer" <[EMAIL PROTECTED]>
Cc: "Sacha Labourey" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, November 12, 2001 2:37 PM
Subject: RE: [JBoss-dev] RE: Deployment exception on Clustering


>
>
> > -Original Message-
> > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 12, 2001 5:17 PM
> > To: Bill Burke
> > Cc: Sacha Labourey; [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
> >
> >
> > Hi
> >
> > postRegister() is a callback method issued by the MBeanServer before the
> > MBean gets finally registered. You then can save the MBeanServer you are
> > connected to and change the MBean ObjectName before it is set.
> >
> > I am still puzzled why you need a 2 stage startup process.
> > The only reason I can assume is that you subclass the ClusterPartition
and
> > then overwrite initService(). Wouldn't it be better to add a
> > method call in
> > the startService() method like postInit() which is placed in the middle
of
> > startService() ?
> >
>
> I need a 2 stage startup because ClusterPartition creates an
> HAPartition(This is the actual cluster object) in the init() phase.
> MBean-managed HA services like HA-JNDI register themselves with the
> HAPartition in the init() phase.  In the start() phase, the
ClusterPartition
> makes the Connection to the JavaGroups message Channel.  When the
connection
> is connected, the state-transfer protocol initiates.  In other words, HA
> services(HA-JNDI) need to register with the ClusterPartition before the
> cluster connections are set up.  Without the 2 phase approach,
> initial-state-synchronization will not work.
>
> Bill
>
>


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] RE: Deployment exception on Clustering

[Andreas Schaefer]

Hi Bill

I see another problem with your approach. With JBoss 3.0
we can deploy services after the application server is started.
Now is it the case that all components registering on a HAPartition
must be started when the JBoss is started ?
Therefore it means that all parts of the cluster must be added to
jboss-service.xml !?

Andy

- Original Message -
From: "David Jencks" <[EMAIL PROTECTED]>
To: "Bill Burke" <[EMAIL PROTECTED]>
Cc: "Andreas Schaefer" <[EMAIL PROTECTED]>; "Sacha Labourey"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, November 12, 2001 2:39 PM
Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering


> What are the mbean dependencies here? Is it possible to add a service to a
> running cluster? How is it synchronized? (what does synchronized mean
here,
> anyway?).
>
> If it is not possible to add a service to a started cluster, you should
> document the contents of the cluster with an mbean-ref-list tag including
> all mbean-ref-list-elements participating in the cluster.  The cluster can
> then do whatever it wants with them, they will be started before the
> cluster is started.
>
> If it is possible to add a service to a started cluster, each service can
> depend on the cluster, so it will be started after the cluster, and can
get
> whatever synchronization it needs set up when it starts.
>
> What are the problems with this approach?  I used the second with jbossmq
> startup.
>
> thanks
> david jencks



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] RE: Deployment exception on Clustering

[David Jencks]

To do this, subclass ServiceMbeanSupport, descend your classes from this
subclass, and override PostRegister to call your init method, after
super.postRegister:


   public void postRegister(Boolean registrationDone)
   {
  super.postRegister(registrationDone);
  if (registrationDone.booleanValue())
  {
 init();
  }
   }
   

you should probably do something similar with preUnregister(?).

IMHO you should not be making any reference to anything outside the mbean
in init. Even Rickard is viewing init as an internal configuration step. 
In this case, I can't see why you can't put the code at the beginning of
start. It might be slower (run more often), but will have the same effect.

I think using explicit mbean references will result in a more satisfactory
and sturdy solution.

david jencks

On 2001.11.12 17:04:34 -0500 Bill Burke wrote:
> Rickard talked about something called postRegister?
> 
> > -Original Message-
> > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 12, 2001 4:50 PM
> > To: David Jencks
> > Cc: Sacha Labourey; [EMAIL PROTECTED]; Bill Burke
> > Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
> > 
> > 
> > Hi David
> > 
> > You hear it. How can be use init() again for Clustering ?
> > 
> > Andy
> > 
> > - Original Message -
> > From: "Bill Burke" <[EMAIL PROTECTED]>
> > To: "Andreas Schaefer" <[EMAIL PROTECTED]>
> > Cc: "Sacha Labourey" <[EMAIL PROTECTED]>;
> > <[EMAIL PROTECTED]>
> > Sent: Monday, November 12, 2001 1:10 PM
> > Subject: [JBoss-dev] RE: Deployment exception on Clustering
> > 
> > 
> > > Yes this a very serious problem and it wouldn't show up with your
> Farm
> > > stuff.  THis is my fault because I didn't document the code 
> > very well, but
> > > can we please switch this back?
> > >
> > > In the init phase, all services register with the cluster
> (HAPartition)
> > for
> > > cluster events that want to listen to and also if they require state
> > > synchronization.  In the start phase, the ClusterPartition 
> > mbean does the
> > > final Connect to the JavaGroups message Channel.  When the Connect
> > happens,
> > > state synchronization starts.  Services will not have their state
> > > synchronized if everything is done in the start phase.
> > >
> > > Bill
> > >
> > > > -Original Message-
> > > > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> > > > Sent: Monday, November 12, 2001 3:50 PM
> > > > To: Bill Burke
> > > > Cc: Sacha Labourey; [EMAIL PROTECTED]
> > > > Subject: Re: Deployment exception on Clustering
> > > >
> > > >
> > > > Hi Bill
> > > >
> > > > I added all the code from init() into start(). Is this a problem ?
> > > >
> > > > At least when I use the Farm it works like a charm.
> > > >
> > > > Andy
> > > >
> > > > - Original Message -
> > > > From: "Bill Burke" <[EMAIL PROTECTED]>
> > > > To: "David Jencks" <[EMAIL PROTECTED]>; 
> > "Andreas Schaefer"
> > > > <[EMAIL PROTECTED]>
> > > > Cc: "Sacha Labourey" <[EMAIL PROTECTED]>;
> > > > <[EMAIL PROTECTED]>
> > > > Sent: Monday, November 12, 2001 12:59 PM
> > > > Subject: RE: Deployment exception on Clustering
> > > >
> > > >
> > > > > Guys,
> > > > >
> > > > > The clustering stuff is dependent on init and start both being
> > > > there.  Can
> > > > > we put back the init?  Otherwise you break our stuff.  Why are
> you
> > doing
> > > > > this anyways?
> > > > >
> > > > > Bill
> > > > >
> > > > > > -Original Message-
> > > > > > From: David Jencks [mailto:[EMAIL PROTECTED]]
> > > > > > Sent: Monday, November 12, 2001 2:33 PM
> > > > > > To: Andreas Schaefer
> > > > > > Cc: David Jencks; Bill Burke; Sacha Labourey;
> > > > > > [EMAIL PROTECTED]
> > > > > > Subject: Re: Deployment exception on Clustering
> > > > > >
> > > > > >
> > > > > > Thanks, must have missed that one.
> > > > > >
> > > > > > I generally co

Re: [JBoss-dev] RE: Deployment exception on Clustering

[Andreas Schaefer]

Hi

Looks like I am asleep here, sorry. Of course, you are
right.

Andy

> Hey,
> 
> > Hi
> > 
> > postRegister() is a callback method issued by the MBeanServer 
> > before the
> > MBean gets finally registered. You then can save the 
> > MBeanServer you are
> > connected to and change the MBean ObjectName before it is set.
> 
> This is done in preRegister, not in postRegister.
> 
> Simon



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] RE: Deployment exception on Clustering

[David Maplesden]

>From what I can follow of this conversation I think what Bill needs is a
bunch of mbeans to be initialised before any of them are started i.e.
mbean1.init();
mbean2.init();
mbean3.init();

mbean1.start();
mbean2.start();
mbean3.start();

as opposed to 
mbean1.init();
mbean1.start();

mbean2.init();
mbean2.start();

mbean3.init();
mbean3.start();

and as long as he has a way to do this (using postRegister to call init or
whatever) he will be happy.

AFAICS then the questions are

1) Can we do this for him?  if yes then great.

2) Is this absolutely neccessary or is there some fancy way he could keep
track of things and work around his problem? if yes then ok (except maybe
for whoever has to implement the fancy bit).  I think however the answer to
this may be no because it sounds like the HAPartition has to exist (i.e. be
initialised) first and then have other mbeans register with it before it is
then started, and the other mbeans can't be started until HAPartition is
started, is this correct?

If no to both of the above then we have a problem with David J's new
deployment stuff...

Cheers
David

> -Original Message-
> From: David Jencks [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 13, 2001 11:48 AM
> To: Bill Burke
> Cc: Andreas Schaefer; David Jencks; Sacha Labourey;
> [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
> 
> 
> To do this, subclass ServiceMbeanSupport, descend your 
> classes from this
> subclass, and override PostRegister to call your init method, after
> super.postRegister:
> 
> 
>public void postRegister(Boolean registrationDone)
>{
>   super.postRegister(registrationDone);
>   if (registrationDone.booleanValue())
>   {
>  init();
>   }
>}
>
> 
> you should probably do something similar with preUnregister(?).
> 
> IMHO you should not be making any reference to anything 
> outside the mbean
> in init. Even Rickard is viewing init as an internal 
> configuration step. 
> In this case, I can't see why you can't put the code at the 
> beginning of
> start. It might be slower (run more often), but will have the 
> same effect.
> 
> I think using explicit mbean references will result in a more 
> satisfactory
> and sturdy solution.
> 
> david jencks
> 
> On 2001.11.12 17:04:34 -0500 Bill Burke wrote:
> > Rickard talked about something called postRegister?
> > 
> > > -Original Message-
> > > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, November 12, 2001 4:50 PM
> > > To: David Jencks
> > > Cc: Sacha Labourey; 
> [EMAIL PROTECTED]; Bill Burke
> > > Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
> > > 
> > > 
> > > Hi David
> > > 
> > > You hear it. How can be use init() again for Clustering ?
> > > 
> > > Andy
> > > 
> > > - Original Message -
> > > From: "Bill Burke" <[EMAIL PROTECTED]>
> > > To: "Andreas Schaefer" <[EMAIL PROTECTED]>
> > > Cc: "Sacha Labourey" <[EMAIL PROTECTED]>;
> > > <[EMAIL PROTECTED]>
> > > Sent: Monday, November 12, 2001 1:10 PM
> > > Subject: [JBoss-dev] RE: Deployment exception on Clustering
> > > 
> > > 
> > > > Yes this a very serious problem and it wouldn't show up 
> with your
> > Farm
> > > > stuff.  THis is my fault because I didn't document the code 
> > > very well, but
> > > > can we please switch this back?
> > > >
> > > > In the init phase, all services register with the cluster
> > (HAPartition)
> > > for
> > > > cluster events that want to listen to and also if they 
> require state
> > > > synchronization.  In the start phase, the ClusterPartition 
> > > mbean does the
> > > > final Connect to the JavaGroups message Channel.  When 
> the Connect
> > > happens,
> > > > state synchronization starts.  Services will not have 
> their state
> > > > synchronized if everything is done in the start phase.
> > > >
> > > > Bill
> > > >
> > > > > -Original Message-
> > > > > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Monday, November 12, 2001 3:50 PM
> > > > > To: Bill Burke
> > > > > Cc: Sacha Labourey; [EMAIL PROTECTED]
> > > > > Subject: Re: Deployment excepti

RE: [JBoss-dev] RE: Deployment exception on Clustering

[Bill Burke]

I answered this in David Jencks' email, but, unfortunately, right now, you
cannot hot-deploy HA services that require state transfer.  You can
hot-deploy clustered SLSBs, and EBs, but I'm not sure about SFSBs. Sacha
will have to answer that.

Also, you do NOT have to add everything to jboss-service.xml.  Have you
since the cool MBean depencies feature added to the XML descriptors?

Bill

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Andreas Schaefer
> Sent: Monday, November 12, 2001 5:42 PM
> To: David Jencks; Bill Burke
> Cc: Sacha Labourey; [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
>
>
> Hi Bill
>
> I see another problem with your approach. With JBoss 3.0
> we can deploy services after the application server is started.
> Now is it the case that all components registering on a HAPartition
> must be started when the JBoss is started ?
> Therefore it means that all parts of the cluster must be added to
> jboss-service.xml !?
>
> Andy
>
> - Original Message -
> From: "David Jencks" <[EMAIL PROTECTED]>
> To: "Bill Burke" <[EMAIL PROTECTED]>
> Cc: "Andreas Schaefer" <[EMAIL PROTECTED]>; "Sacha Labourey"
> <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Monday, November 12, 2001 2:39 PM
> Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
>
>
> > What are the mbean dependencies here? Is it possible to add a
> service to a
> > running cluster? How is it synchronized? (what does synchronized mean
> here,
> > anyway?).
> >
> > If it is not possible to add a service to a started cluster, you should
> > document the contents of the cluster with an mbean-ref-list tag
> including
> > all mbean-ref-list-elements participating in the cluster.  The
> cluster can
> > then do whatever it wants with them, they will be started before the
> > cluster is started.
> >
> > If it is possible to add a service to a started cluster, each
> service can
> > depend on the cluster, so it will be started after the cluster, and can
> get
> > whatever synchronization it needs set up when it starts.
> >
> > What are the problems with this approach?  I used the second
> with jbossmq
> > startup.
> >
> > thanks
> > david jencks
>
>
>
> ___
> 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

Re: [JBoss-dev] RE: Deployment exception on Clustering

[Andreas Schaefer]

Hi Bill

I don't think this works. When you use dependencies feature just wait until
the MBean is available. But when your services is deployed on another thread
then the init() and start() sequence runs out of order and you can fail.
Only when
all the services are deployed by the same thread (DeployerService) you will
succeed.

Andy

> Also, you do NOT have to add everything to jboss-service.xml.  Have you
> since the cool MBean depencies feature added to the XML descriptors?
>
> Bill



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] RE: Deployment exception on Clustering

[Bill Burke]

> -Original Message-
> From: David Jencks [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 12, 2001 5:40 PM
> To: Bill Burke
> Cc: Andreas Schaefer; Sacha Labourey;
> [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
>
>
> What are the mbean dependencies here? Is it possible to add a service to a
> running cluster? How is it synchronized? (what does synchronized
> mean here,
> anyway?).
>

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?

> If it is not possible to add a service to a started cluster, you should
> document the contents of the cluster with an mbean-ref-list tag including
> all mbean-ref-list-elements participating in the cluster.  The cluster can
> then do whatever it wants with them, they will be started before the
> cluster is started.
>
Yes, yes.  I know about dependencies.

> If it is possible to add a service to a started cluster, each service can
> depend on the cluster, so it will be started after the cluster,
> and can get
> whatever synchronization it needs set up when it starts.
>
> What are the problems with this approach?  I used the second with jbossmq
> startup.
>

Services requiring state-transfer like HA-JNDI must register with an object
created by the ClusterPartition.  The ClusterPartition cannot complete
JavaGroups connections until the all these HA services have registered with
the ClusterPartition.  The ClusterPartition should not know about who
depends on it.

Because of quirkiness of JavaGroups, services cannot ask for
state-synchronization once the Group connection has been initiated.

BTW, I originally did nothing in init(), until I discovered that I needed a
2 phase initialization.  Please, trust me,  I need 2 phase initialization in
order for a clean design.

Bill


> thanks
> david jencks
>
> On 2001.11.12 16:10:27 -0500 Bill Burke wrote:
> > Yes this a very serious problem and it wouldn't show up with your Farm
> > stuff.  THis is my fault because I didn't document the code very well,
> > but
> > can we please switch this back?
> >
> > In the init phase, all services register with the cluster (HAPartition)
> > for
> > cluster events that want to listen to and also if they require state
> > synchronization.  In the start phase, the ClusterPartition
> mbean does the
> > final Connect to the JavaGroups message Channel.  When the Connect
> > happens,
> > state synchronization starts.  Services will not have their state
> > synchronized if everything is done in the start phase.
> >
> > Bill
> >
> > > -Original Message-
> > > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, November 12, 2001 3:50 PM
> > > To: Bill Burke
> > > Cc: Sacha Labourey; [EMAIL PROTECTED]
> > > Subject: Re: Deployment exception on Clustering
> > >
> > >
> > > Hi Bill
> > >
> > > I added all the code from init() into start(). Is this a problem ?
> > >
> > > At least when I use the Farm it works like a charm.
> > >
> > > Andy
> > >
> > > - Original Message -
> > > From: "Bill Burke" <[EMAIL PROTECTED]>
> > > To: "David Jencks" <[EMAIL PROTECTED]>; "Andreas
> > Schaefer"
> > > <[EMAIL PROTECTED]>
> > > Cc: "Sacha Labourey" <[EMAIL PROTECTED]>;
> > > <[EMAIL PROTECTED]>
> > > Sent: Monday, November 12, 2001 12:59 PM
> > > Subject: RE: Deployment exception on Clustering
> > >
> > >
> > > > Guys,
> > > >
> > > > The clustering stuff is dependent on init and start both being
> > > there.  Can
> > > > we put back the init?  Otherwise you break our stuff.  Why are you
> > doing
> > > > this anyways?
> > > >
> > > > Bill
> > > >
> > > > > -Original Message-
> > > > > From: David Jencks [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Monday, November 12, 2001 2:33 PM
> > > > > To: Andreas Schaefer
> > > > > Cc: David Jencks; Bill Burke; Sacha Labourey;
> > > > > [EMAIL PROTECTED]
> > > > > Subject: Re: Deployment exception on Clustering
> > > > >
> > > > >
> > > > > Thanks, must have missed that one.
> > > > >
> > > > > I generally c

RE: [JBoss-dev] RE: Deployment exception on Clustering

[Bill Burke]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of David
> Maplesden
> Sent: Monday, November 12, 2001 6:07 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] RE: Deployment exception on Clustering
>
>
> From what I can follow of this conversation I think what Bill needs is a
> bunch of mbeans to be initialised before any of them are started i.e.
>   mbean1.init();
>   mbean2.init();
>   mbean3.init();
>
>   mbean1.start();
>   mbean2.start();
>   mbean3.start();
>

Thank you Mr. Maplesden. Exactly.


> as opposed to
>   mbean1.init();
>   mbean1.start();
>
>   mbean2.init();
>   mbean2.start();
>
>   mbean3.init();
>   mbean3.start();
>
> and as long as he has a way to do this (using postRegister to call init or
> whatever) he will be happy.
>
> AFAICS then the questions are
>
> 1) Can we do this for him?  if yes then great.
>

Please, Please?

> 2) Is this absolutely neccessary or is there some fancy way he could keep
> track of things and work around his problem? if yes then ok (except maybe

Yes its necessary to avoid a corrupted state-synchronization on
initialization.

> for whoever has to implement the fancy bit).  I think however the
> answer to
> this may be no because it sounds like the HAPartition has to
> exist (i.e. be
> initialised) first and then have other mbeans register with it
> before it is
> then started, and the other mbeans can't be started until HAPartition is
> started, is this correct?
>
> If no to both of the above then we have a problem with David J's new
> deployment stuff...
>

Regards,

Bill



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] RE: Deployment exception on Clustering

[Bill Burke]

You're right.  But you don't have to have everything in jboss-service.xml.
Everything has to be in one service.xml file though (i.e.
cluster-service.xml).  Of course, this is only a problem if somebody writes
their own custom HA services that need state-synchronization.

Bill

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Andreas Schaefer
> Sent: Monday, November 12, 2001 6:12 PM
> To: Bill Burke; David Jencks
> Cc: Sacha Labourey; [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
>
>
> Hi Bill
>
> I don't think this works. When you use dependencies feature just
> wait until
> the MBean is available. But when your services is deployed on
> another thread
> then the init() and start() sequence runs out of order and you can fail.
> Only when
> all the services are deployed by the same thread
> (DeployerService) you will
> succeed.
>
> Andy
>
> > Also, you do NOT have to add everything to jboss-service.xml.  Have you
> > since the cool MBean depencies feature added to the XML descriptors?
> >
> > Bill
>
>
>
> ___
> 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

RE: [JBoss-dev] RE: Deployment exception on Clustering

[Hiram Chirino]

>Services requiring state-transfer like HA-JNDI must register with an object
>created by the ClusterPartition.  The ClusterPartition cannot complete
>JavaGroups connections until the all these HA services have registered with
>the ClusterPartition.  The ClusterPartition should not know about who
>depends on it.
>
>Because of quirkiness of JavaGroups, services cannot ask for
>state-synchronization once the Group connection has been initiated.
>
>BTW, I originally did nothing in init(), until I discovered that I needed a
>2 phase initialization.  Please, trust me,  I need 2 phase initialization 
>in
>order for a clean design.
>
>Bill

JbossMQ kinda had similar requirments due to the way we did message 
recovery.  David J. changed it so that we did not have that requirment 
anymore.  It seems to me that what we need is a way to register a post 
server startup JMX invocation.  That way the:

ClusterPartition.start() - setup up the javagroup stuff
StateTransferTypeService1.start() - registers with ClusterPartition.
StateTransferTypeService2.start() - registers with ClusterPartition.
The rest of the JBoss services get started.
ClusterPartion.startJavaGroupsConnection() - the method call that the 
start() method had registered to be called after the method was started.

What do you think??

Regards,
Hiram






_
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

RE: [JBoss-dev] RE: Deployment exception on Clustering

[Bill Burke]

> -Original Message-
> From: Hiram Chirino [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 12, 2001 6:47 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] RE: Deployment exception on Clustering
>
>
> >Services requiring state-transfer like HA-JNDI must register
> with an object
> >created by the ClusterPartition.  The ClusterPartition cannot complete
> >JavaGroups connections until the all these HA services have
> registered with
> >the ClusterPartition.  The ClusterPartition should not know about who
> >depends on it.
> >
> >Because of quirkiness of JavaGroups, services cannot ask for
> >state-synchronization once the Group connection has been initiated.
> >
> >BTW, I originally did nothing in init(), until I discovered that
> I needed a
> >2 phase initialization.  Please, trust me,  I need 2 phase
> initialization
> >in
> >order for a clean design.
> >
> >Bill
>
> JbossMQ kinda had similar requirments due to the way we did message
> recovery.  David J. changed it so that we did not have that requirment
> anymore.  It seems to me that what we need is a way to register a post
> server startup JMX invocation.  That way the:
>
> ClusterPartition.start() - setup up the javagroup stuff
> StateTransferTypeService1.start() - registers with ClusterPartition.
> StateTransferTypeService2.start() - registers with ClusterPartition.
> The rest of the JBoss services get started.
> ClusterPartion.startJavaGroupsConnection() - the method call that the
> start() method had registered to be called after the method was started.
>

When you say "...after the method was started" do you mean after the service
was started?  Meaning we would setup a postRegister callback for
ClusterPartition so that it could call startJavaGroupsConnection?  BTW,
thanks everybody for discussing this.  I'm not up-to-speed on the direction
JMX is taking.

> What do you think??
>

I think it sounds good Hiram.  Thanks.

Bill



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] RE: Deployment exception on Clustering

[David Jencks]

On 2001.11.12 18:08:14 -0500 Bill Burke wrote:
> 
> 
> > -Original Message-
> > From: David Jencks [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 12, 2001 5:40 PM
> > To: Bill Burke
> > Cc: Andreas Schaefer; Sacha Labourey;
> > [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
> >
> >
> > What are the mbean dependencies here? Is it possible to add a service
> to a
> > running cluster? How is it synchronized? (what does synchronized
> > mean here,
> > anyway?).
> >
> 
> 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?
> 
> > If it is not possible to add a service to a started cluster, you should
> > document the contents of the cluster with an mbean-ref-list tag
> including
> > all mbean-ref-list-elements participating in the cluster.  The cluster
> can
> > then do whatever it wants with them, they will be started before the
> > cluster is started.
> >
> Yes, yes.  I know about dependencies.
> 
> > If it is possible to add a service to a started cluster, each service
> can
> > depend on the cluster, so it will be started after the cluster,
> > and can get
> > whatever synchronization it needs set up when it starts.
> >
> > What are the problems with this approach?  I used the second with
> jbossmq
> > startup.
> >
> 
> Services requiring state-transfer like HA-JNDI must register with an
> object
> created by the ClusterPartition.  The ClusterPartition cannot complete
> JavaGroups connections until the all these HA services have registered
> with
> the ClusterPartition.  The ClusterPartition should not know about who
> depends on it.
> 
> Because of quirkiness of JavaGroups, services cannot ask for
> state-synchronization once the Group connection has been initiated.
> 
> BTW, I originally did nothing in init(), until I discovered that I needed
> a
> 2 phase initialization.  Please, trust me,  I need 2 phase initialization
> in
> order for a clean design.
> 
It looks to me as if 
"Because of quirkiness of JavaGroups, services cannot ask for
> state-synchronization once the Group connection has been initiated."
means exactly that the ClusterPartition HAS to know EXACTLY which services
are using it.  If you do this, the mbean-ref-list will give you what you
want.  Otherwise, can you explain how these two statements don't contradict
each other?

Won't having this complete list let you hot deploy a ClusterPartition? How
would this be different than server start-up?
I think explicitly stating the dependencies is a good idea, even if they
are caused by a limitation of JavaGroups.

david

> Bill
> 
> 
> > thanks
> > david jencks
> >
> > On 2001.11.12 16:10:27 -0500 Bill Burke wrote:
> > > Yes this a very serious problem and it wouldn't show up with your
> Farm
> > > stuff.  THis is my fault because I didn't document the code very
> well,
> > > but
> > > can we please switch this back?
> > >
> > > In the init phase, all services register with the cluster
> (HAPartition)
> > > for
> > > cluster events that want to listen to and also if they require state
> > > synchronization.  In the start phase, the ClusterPartition
> > mbean does the
> > > final Connect to the JavaGroups message Channel.  When the Connect
> > > happens,
> > > state synchronization starts.  Services will not have their state
> > > synchronized if everything is done in the start phase.
> > >
> > > Bill
> > >
> > > > -Original Message-
> > > > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> > > > Sent: Monday, November 12, 2001 3:50 PM
> > > > To: Bill Burke
> > > > Cc: Sacha Labourey; [EMAIL PROTECTED]
> > > > Subject: Re: Deployment exception on Clustering
> > > >
> > > >
> > > > Hi Bill
> > > >
> > > > I added all the code from init() into start(). Is this a problem ?
> > > >
> > > > At least when I use the Farm it works like a charm.
> > > >
> > > > Andy
> > > >
> > > > - Original Message -
> > > > From: "Bill Burke" <[EMAIL PROTECTED]>
> > > > To: "David Jencks" <[EMAIL PROTECTED]>; "Andreas
> > > Schaefer"
> > > > <[EMAIL

Re: [JBoss-dev] RE: Deployment exception on Clustering

[Hiram Chirino]

>It looks to me as if
>"Because of quirkiness of JavaGroups, services cannot ask for
> > state-synchronization once the Group connection has been initiated."
>means exactly that the ClusterPartition HAS to know EXACTLY which services
>are using it.  If you do this, the mbean-ref-list will give you what you
>want.  Otherwise, can you explain how these two statements don't contradict
>each other?
>
>Won't having this complete list let you hot deploy a ClusterPartition? How
>would this be different than server start-up?
>I think explicitly stating the dependencies is a good idea, even if they
>are caused by a limitation of JavaGroups.
>
>david
>

This seem like a good idea.  What would the XML syntax be for specifying a 
mbean reference list?

Regards,
Hiram

_
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

Re: [JBoss-dev] RE: Deployment exception on Clustering

[Andreas Schaefer]

Hi Geeks

To keep Davids changes and to make Clustering working I remember a
suggestion long ago to add a method-call to the arguments of a MBean.

I would suggest the following:
- a  can contain a  attribute
-  attribute supports the call of a non-argument method and
   the time can be specified (after creation, before start(), after start())
- ServiceDeployer call the method at the appropriate time

This would look like this:
gugus
connect


As long as we reduce the method to non-args methods we should not
have much to deal with.

Andy

- Original Message -
From: "Hiram Chirino" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, November 12, 2001 5:37 PM
Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering


> >It looks to me as if
> >"Because of quirkiness of JavaGroups, services cannot ask for
> > > state-synchronization once the Group connection has been initiated."
> >means exactly that the ClusterPartition HAS to know EXACTLY which
services
> >are using it.  If you do this, the mbean-ref-list will give you what you
> >want.  Otherwise, can you explain how these two statements don't
contradict
> >each other?
> >
> >Won't having this complete list let you hot deploy a ClusterPartition?
How
> >would this be different than server start-up?
> >I think explicitly stating the dependencies is a good idea, even if they
> >are caused by a limitation of JavaGroups.
> >
> >david
> >
>
> This seem like a good idea.  What would the XML syntax be for specifying a
> mbean reference list?
>
> Regards,
> Hiram
>
> _
> 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

Re: [JBoss-dev] RE: Deployment exception on Clustering

[Hiram Chirino]

>Hi Geeks
>
>To keep Davids changes and to make Clustering working I remember a
>suggestion long ago to add a method-call to the arguments of a MBean.
>
>I would suggest the following:
>- a  can contain a  attribute
>-  attribute supports the call of a non-argument method and
>the time can be specified (after creation, before start(), after 
>start())


It would also be cool to have a "after the entire server is started"

>- ServiceDeployer call the method at the appropriate time
>
>This would look like this:
>gugus
> connect
>
>


regards,
Hiram

_
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

Re: [JBoss-dev] RE: Deployment exception on Clustering

[David Jencks]

On 2001.11.12 20:37:24 -0500 Hiram Chirino wrote:
> >It looks to me as if
> >"Because of quirkiness of JavaGroups, services cannot ask for
> > > state-synchronization once the Group connection has been initiated."
> >means exactly that the ClusterPartition HAS to know EXACTLY which
> services
> >are using it.  If you do this, the mbean-ref-list will give you what you
> >want.  Otherwise, can you explain how these two statements don't
> contradict
> >each other?
> >
> >Won't having this complete list let you hot deploy a ClusterPartition?
> How
> >would this be different than server start-up?
> >I think explicitly stating the dependencies is a good idea, even if they
> >are caused by a limitation of JavaGroups.
> >
> >david
> >
> 
> This seem like a good idea.  What would the XML syntax be for specifying
> a 
> mbean reference list?


  
JBossCluster:service=HAJNDI,name=dave
  JBossCluster:service=HATM,name=dave
  
JBossCluster:service=HARARDeployer,name=dave



then 

...

etc 
can be in any service file, the mbean with the mbean-ref-list won't start
until all the mbeans in the list are started, and will stop if any are
stopped.

david


> 
> Regards,
> Hiram
> 
> _
> 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
> 
> 

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] RE: Deployment exception on Clustering

[David Jencks]

This won't do any good.  If all required beans are present, the order will
be 

create
configure
call before start
start
call after start

with no opportunity for anything else to happen.  Might as well put
everything in start. 

Unfortunately Hirams suggestion of "after server is started" doesn't make
sense- you never know when the server is completely started, someone is
always about to add one more mbean.

 The only way the cluster stuff ever worked was there was a more or less
hidden concept of a deployment unit, with a more or less explicit order,
which could be used to hide dependencies.  This only works if the explicit
dependencies are between mbeans needed for a deployment unit (the depends
tag from David Maplesden) or between deployment units themselves (my
original recursive sar deployment scheme).  For everything I've tried so
far, the mbean-ref method is simpler, clearer, and reduces the need for
fake and implicit dependencies than either of the other two methods, or the
"ordering in deployment unit" method. For instance, in the
ConnectionFactoryLoader, there was a really fake dependency on the
RARDeployer, the only use of which was to help the RARDeployer notify the
ConnectionFactoryLoaders when it deployed a rar.  By making the
RARDeployment mbean, and having the ConnectionFactoryLoader refer to it,
the extraneous reference is no longer needed, and the actual dependence is
clearly exposed.


I think there must be a hidden ordering dependency in the cluster file. 
The Cluster has to apperar before any of the services it manages, right?,
so it can be called from the init.

Why not make this dependency explicit?

thanks

david jencks


On 2001.11.12 20:44:39 -0500 Andreas Schaefer wrote:
> Hi Geeks
> 
> To keep Davids changes and to make Clustering working I remember a
> suggestion long ago to add a method-call to the arguments of a MBean.
> 
> I would suggest the following:
> - a  can contain a  attribute
> -  attribute supports the call of a non-argument method and
>the time can be specified (after creation, before start(), after
> start())
> - ServiceDeployer call the method at the appropriate time
> 
> This would look like this:
> gugus
> connect
> 
> 
> As long as we reduce the method to non-args methods we should not
> have much to deal with.
> 
> Andy
> 
> - Original Message -
> From: "Hiram Chirino" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Monday, November 12, 2001 5:37 PM
> Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
> 
> 
> > >It looks to me as if
> > >"Because of quirkiness of JavaGroups, services cannot ask for
> > > > state-synchronization once the Group connection has been
> initiated."
> > >means exactly that the ClusterPartition HAS to know EXACTLY which
> services
> > >are using it.  If you do this, the mbean-ref-list will give you what
> you
> > >want.  Otherwise, can you explain how these two statements don't
> contradict
> > >each other?
> > >
> > >Won't having this complete list let you hot deploy a ClusterPartition?
> How
> > >would this be different than server start-up?
> > >I think explicitly stating the dependencies is a good idea, even if
> they
> > >are caused by a limitation of JavaGroups.
> > >
> > >david
> > >
> >
> > This seem like a good idea.  What would the XML syntax be for
> specifying a
> > mbean reference list?
> >
> > Regards,
> > Hiram
> >
> > _
> > 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

Re: [JBoss-dev] RE: Deployment exception on Clustering

[Andreas Schaefer]

> This won't do any good.  If all required beans are present, the order will
> be
>
> create
> configure
> call before start
> start
> call after start
>
> with no opportunity for anything else to happen.  Might as well put
> everything in start.

I don't understand. The problem we have here is that we have to call
a method on the ClusterPartition MBean after all other MBeans are started.
As far as I understand the ClusterPartition's JChannel must be initialized
before the other "clustering" services can be started. Therefore to wait
with
this will do no good. What we need is:
- create all MBeans
- "initialize ClusterPartition before all other clustering services
- start other clustering services
- connect within the ClusterPartition to fire it up

As long as all the clustering services are deployed as a unit it would work
fine.

Whenever a clustering services is deployed outsite we are f*cked and then
we must be able to add new services at runtime. THAT is the catch in
JavaGroups -> Clustering.

> Unfortunately Hirams suggestion of "after server is started" doesn't make
> sense- you never know when the server is completely started, someone is
> always about to add one more mbean.

Let us say after UNIT DEPLOYMENT and we are there.

>  The only way the cluster stuff ever worked was there was a more or less
> hidden concept of a deployment unit, with a more or less explicit order,
> which could be used to hide dependencies.  This only works if the explicit
> dependencies are between mbeans needed for a deployment unit (the depends
> tag from David Maplesden) or between deployment units themselves (my
> original recursive sar deployment scheme).  For everything I've tried so
> far, the mbean-ref method is simpler, clearer, and reduces the need for
> fake and implicit dependencies than either of the other two methods, or
the
> "ordering in deployment unit" method. For instance, in the
> ConnectionFactoryLoader, there was a really fake dependency on the
> RARDeployer, the only use of which was to help the RARDeployer notify the
> ConnectionFactoryLoaders when it deployed a rar.  By making the
> RARDeployment mbean, and having the ConnectionFactoryLoader refer to it,
> the extraneous reference is no longer needed, and the actual dependence is
> clearly exposed.

The best way is to resolve the dependencies to make it dynamic like the
other services but these seems to be a problem with JavaGroups and you
know how long it can take to fix such a bug.

> I think there must be a hidden ordering dependency in the cluster file.
> The Cluster has to apperar before any of the services it manages, right?,
> so it can be called from the init.
>
> Why not make this dependency explicit?

I don't think it is a "single" depencies. First the JChannel must be
initialized,
then all the clustering services must be started and finally
ClusterPartition must
connect.

See ya - Andy


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] RE: Deployment exception on Clustering

[David Jencks]

I'm happy to try to fix this problem along these lines, especially if
someone will tell me which mbeans need to be synchronized(?right word?)

1. in ClusterPartition, include


  JBossCluster:service=HANaming
...


2. A new mbean interface, ClusterRegistration having the method
registerCluster(ClusterPartition cluster);

3. The mbeans needing synchronization(?) implement this ClusterRegistration
interface, and the current contents (mostly) of their startService method
is moved to registerCluster.

4. ClusterPartition's start method looks like this:

start()
{
--current contents of init
--iterate through synchronizedMBeans collection, calling
mbean.registerCluster(this) (or maybe the HAPartition?)
--current contents of start 
}

Aside from working with the mbean-ref framework, this makes all the
dependencies explicit, and indicates by means of the ClusterRegistration
interface which mbeans need to be present at startup and which can be added
later (if any).

OK?

Thanks
david jencks

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] RE: Deployment exception on Clustering

[Sacha Labourey]

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

Re: [JBoss-dev] RE: Deployment exception on Clustering

[David Jencks]

Does this mean that the dependencies can go like this?


  
  

   
  JBOSS-SYSTEM:service=DefaultPartition
  


  
  JBOSS-SYSTEM:service=DefaultPartition
  


rather than like this:


  

  
JBOSS-SYSTEM:service=HASessionState
  JBOSS-SYSTEM:service=HAJNDI

  

   
  


  
  

?

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?

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

RE: [JBoss-dev] RE: Deployment exception on Clustering

[Bill Burke]

> -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?
>
>
>name="JBOSS-SYSTEM:service=DefaultPartition">
>   
>
> name="JBOSS-SYSTEM:service=HASessionState">
>   JBOSS-SYSTEM:service=DefaultPartition
>   
>
>
>name="JBOSS-SYSTEM:service=HAJNDI">
>   JBOSS-SYSTEM:service=DefaultPartition
>   
>
>
> rather than like this:
>
>
>name="JBOSS-SYSTEM:service=DefaultPartition">
> 
>
> JBOSS-SYSTEM:service=HASessionState -ref-list-element>
>
> JBOSS-SYSTEM:service=HAJNDI t-element>
> 
>   
>
> name="JBOSS-SYSTEM:service=HASessionState">
>   
>
>
>name="JBOSS-SYSTEM:service=HAJNDI">
>   
>
> ?
>
> 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.  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.  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?


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?



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

Re: [JBoss-dev] RE: Deployment exception on Clustering

[David Jencks]

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)
> >
> >> name="JBOSS-SYSTEM:service=DefaultPartition">
> >   
> >
> > > name="JBOSS-SYSTEM:service=HASessionState">
> >   name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition
> >   
> >
> >
> >> name="JBOSS-SYSTEM:service=HAJNDI">
> >   name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition
> >   
> >
> >
> > rather than like this:
> >
> >
> >> name="JBOSS-SYSTEM:service=DefaultPartition">
> > 
> >
> > JBOSS-SYSTEM:service=HASessionState > -ref-list-element>
> >
> > JBOSS-SYSTEM:service=HAJNDI > t-element>
> > 
> >   
> >
> > > name="JBOSS-SYSTEM:service=HASessionState">
> >   
> >
> >
> >> name="JBOSS-SYSTEM:service=HAJNDI">
> >   
> >
> > ?
> >
> > 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.

> 
> 
> 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?
> 
> 

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 

Re: [JBoss-dev] RE: Deployment exception on Clustering

[Andreas Schaefer]

Hi Geeks

I don't think the mbean-ref list will WORK. As you said the ClusterPartition
will be created, attributes are set BUT it won't be started.

AFAIK ClusterPartition needs to initialize JChannel before the other HA-
service can start, doesn't it? Yeah, but then this initialization is NOT
STARTED
with the "mbean-ref-list"! So, how to you want to initialize the JChannel on
ClusterPartition before the other HA-services are started ? REMEBER that
there are attributes which could be set after the creation of the MBean.

Andy

> > >> > name="JBOSS-SYSTEM:service=DefaultPartition">
> > >   
> > >
> > > > > name="JBOSS-SYSTEM:service=HASessionState">
> > >   JBOSS-SYSTEM:service=DefaultPartition
> > >   
> > >
> > >
> > >> > name="JBOSS-SYSTEM:service=HAJNDI">
> > >   JBOSS-SYSTEM:service=DefaultPartition
> > >   
> > >
> > >
> > > rather than like this:
> > >
> > >
> > >> > name="JBOSS-SYSTEM:service=DefaultPartition">
> > > 
> > >
> > > JBOSS-SYSTEM:service=HASessionState > > -ref-list-element>
> > >
> > > JBOSS-SYSTEM:service=HAJNDI > > t-element>
> > > 
> > >   
> > >
> > > > > name="JBOSS-SYSTEM:service=HASessionState">
> > >   
> > >
> > >
> > >> > name="JBOSS-SYSTEM:service=HAJNDI">
> > >   

> 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.



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] RE: Deployment exception on Clustering

[Bill Burke]

> 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.
>

I have not been viewing the dev list posts lately because I've been really
busy.  I apologize.  I'm just being grumpy.

Bill



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] RE: Deployment exception on Clustering

[Bill Burke]

Can't we just deprecate the use of init() right now?  It would make all of
our lives much easier and the RabbitHole alpha can go forward with a working
clustering engine.  In the meantime, Sacha and I can work with the
JavaGroups guys to eliminate the need for 2 phase initialization.

Bill

> -Original Message-
> From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 13, 2001 12:47 PM
> To: David Jencks; Bill Burke
> Cc: Sacha Labourey; [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
>
>
> Hi Geeks
>
> I don't think the mbean-ref list will WORK. As you said the
> ClusterPartition
> will be created, attributes are set BUT it won't be started.
>
> AFAIK ClusterPartition needs to initialize JChannel before the other HA-
> service can start, doesn't it? Yeah, but then this initialization is NOT
> STARTED
> with the "mbean-ref-list"! So, how to you want to initialize the
> JChannel on
> ClusterPartition before the other HA-services are started ? REMEBER that
> there are attributes which could be set after the creation of the MBean.
>
> Andy
>
> > > >> > > name="JBOSS-SYSTEM:service=DefaultPartition">
> > > >   
> > > >
> > > > code="org.jboss.ha.hasessionstate.server.HASessionStateService"
> > > > name="JBOSS-SYSTEM:service=HASessionState">
> > > >name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition
> > > >   
> > > >
> > > >
> > > >> > > name="JBOSS-SYSTEM:service=HAJNDI">
> > > >name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition
> > > >   
> > > >
> > > >
> > > > rather than like this:
> > > >
> > > >
> > > >> > > name="JBOSS-SYSTEM:service=DefaultPartition">
> > > > 
> > > >
> > > > JBOSS-SYSTEM:service=HASessionState > > > -ref-list-element>
> > > >
> > > > JBOSS-SYSTEM:service=HAJNDI > > > t-element>
> > > > 
> > > >   
> > > >
> > > > code="org.jboss.ha.hasessionstate.server.HASessionStateService"
> > > > name="JBOSS-SYSTEM:service=HASessionState">
> > > >   
> > > >
> > > >
> > > >> > > name="JBOSS-SYSTEM:service=HAJNDI">
> > > >   
>
> > 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.
>
>



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] RE: Deployment exception on Clustering

[David Jencks]

On 2001.11.13 13:07:22 -0500 Bill Burke wrote:
> Can't we just deprecate the use of init() right now?  It would make all
> of
> our lives much easier and the RabbitHole alpha can go forward with a
> working
> clustering engine.  In the meantime, Sacha and I can work with the
> JavaGroups guys to eliminate the need for 2 phase initialization.
> 
> Bill

Unfortunately, we would have to back out all the mbean-ref stuff and
configuration changes to jbossmq and jbosscx.  It would be way less work
for me to modify the cluster code to work with mbean refs.

david jencks
> 
> > -Original Message-
> > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, November 13, 2001 12:47 PM
> > To: David Jencks; Bill Burke
> > Cc: Sacha Labourey; [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
> >
> >
> > Hi Geeks
> >
> > I don't think the mbean-ref list will WORK. As you said the
> > ClusterPartition
> > will be created, attributes are set BUT it won't be started.
> >
> > AFAIK ClusterPartition needs to initialize JChannel before the other
> HA-
> > service can start, doesn't it? Yeah, but then this initialization is
> NOT
> > STARTED
> > with the "mbean-ref-list"! So, how to you want to initialize the
> > JChannel on
> > ClusterPartition before the other HA-services are started ? REMEBER
> that
> > there are attributes which could be set after the creation of the
> MBean.
> >
> > Andy
> >
> > > > >> > > > name="JBOSS-SYSTEM:service=DefaultPartition">
> > > > >   
> > > > >
> > > > > > code="org.jboss.ha.hasessionstate.server.HASessionStateService"
> > > > > name="JBOSS-SYSTEM:service=HASessionState">
> > > > >> name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition
> > > > >   
> > > > >
> > > > >
> > > > >> > > > name="JBOSS-SYSTEM:service=HAJNDI">
> > > > >> name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition
> > > > >   
> > > > >
> > > > >
> > > > > rather than like this:
> > > > >
> > > > >
> > > > >> > > > name="JBOSS-SYSTEM:service=DefaultPartition">
> > > > > 
> > > > >
> > > > > JBOSS-SYSTEM:service=HASessionState > > > > -ref-list-element>
> > > > >
> > > > > JBOSS-SYSTEM:service=HAJNDI > > > > t-element>
> > > > > 
> > > > >   
> > > > >
> > > > > > code="org.jboss.ha.hasessionstate.server.HASessionStateService"
> > > > > name="JBOSS-SYSTEM:service=HASessionState">
> > > > >   
> > > > >
> > > > >
> > > > >> > > > name="JBOSS-SYSTEM:service=HAJNDI">
> > > > >   
> >
> > > 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.
> >
> >
> 
> 
> 
> 

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] RE: Deployment exception on Clustering

[David Jencks]

Well, see the code I sent under separate cover, but here's how i think you
can get exactly the same code execution sequence:

[ClusterPartition created, configured, but not started]

HAJNDI created, start does nothing 
(other needed mbeans also created and started similarly)

Now the dependencies for ClusterPartition are satisfied, it is started.
It does:
old init code
calls registerCluster(haPartition) on each of the mbeans it depends on
(HAJNDI).  This method includes the former init code.
old start code
calls startFromCluster(haPartition) on each of the mbeans it depends on
(HAJNDI).  This method includes the former start code.

Isn't this the same code in the same order as executed previously?

I think you can get away with only the calls to registerCluster, no
startFromCluster, although this might be why the code I sent doesn't
actually work at the moment;-)

david jencks

On 2001.11.13 12:47:08 -0500 Andreas Schaefer wrote:
> Hi Geeks
> 
> I don't think the mbean-ref list will WORK. As you said the
> ClusterPartition
> will be created, attributes are set BUT it won't be started.
> 
> AFAIK ClusterPartition needs to initialize JChannel before the other HA-
> service can start, doesn't it? Yeah, but then this initialization is NOT
> STARTED
> with the "mbean-ref-list"! So, how to you want to initialize the JChannel
> on
> ClusterPartition before the other HA-services are started ? REMEBER that
> there are attributes which could be set after the creation of the MBean.
> 
> Andy
> 
> > > >> > > name="JBOSS-SYSTEM:service=DefaultPartition">
> > > >   
> > > >
> > > > code="org.jboss.ha.hasessionstate.server.HASessionStateService"
> > > > name="JBOSS-SYSTEM:service=HASessionState">
> > > >name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition
> > > >   
> > > >
> > > >
> > > >> > > name="JBOSS-SYSTEM:service=HAJNDI">
> > > >name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition
> > > >   
> > > >
> > > >
> > > > rather than like this:
> > > >
> > > >
> > > >> > > name="JBOSS-SYSTEM:service=DefaultPartition">
> > > > 
> > > >
> > > > JBOSS-SYSTEM:service=HASessionState > > > -ref-list-element>
> > > >
> > > > JBOSS-SYSTEM:service=HAJNDI > > > t-element>
> > > > 
> > > >   
> > > >
> > > > code="org.jboss.ha.hasessionstate.server.HASessionStateService"
> > > > name="JBOSS-SYSTEM:service=HASessionState">
> > > >   
> > > >
> > > >
> > > >> > > name="JBOSS-SYSTEM:service=HAJNDI">
> > > >   
> 
> > 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.
> 
> 
> 
> 

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] RE: Deployment exception on Clustering

[Bill Burke]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of David
> Jencks
> Sent: Monday, November 12, 2001 10:22 PM
> To: Andreas Schaefer
> Cc: [EMAIL PROTECTED]; Bill Burke; David Jencks
> Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
>
>
> This won't do any good.  If all required beans are present, the order will
> be
>
> create
> configure
> call before start
> start
> call after start
>
> with no opportunity for anything else to happen.  Might as well put
> everything in start.
>
> Unfortunately Hirams suggestion of "after server is started" doesn't make
> sense- you never know when the server is completely started, someone is
> always about to add one more mbean.
>
>  The only way the cluster stuff ever worked was there was a more or less
> hidden concept of a deployment unit, with a more or less explicit order,
> which could be used to hide dependencies.  This only works if the explicit
> dependencies are between mbeans needed for a deployment unit (the depends
> tag from David Maplesden) or between deployment units themselves (my
> original recursive sar deployment scheme).  For everything I've tried so
> far, the mbean-ref method is simpler, clearer, and reduces the need for
> fake and implicit dependencies than either of the other two
> methods, or the
> "ordering in deployment unit" method. For instance, in the
> ConnectionFactoryLoader, there was a really fake dependency on the
> RARDeployer, the only use of which was to help the RARDeployer notify the
> ConnectionFactoryLoaders when it deployed a rar.  By making the
> RARDeployment mbean, and having the ConnectionFactoryLoader refer to it,
> the extraneous reference is no longer needed, and the actual dependence is
> clearly exposed.
>
>
> I think there must be a hidden ordering dependency in the cluster file.

Again, I have 2 phase initialization.  It's kind of my fault that it's not
clear what exactly this 2 phase initialization is.  ClusterPartition should
be delegating init(), start() and stop() to HAPartitionImpl instead of the
initialization logic being divided between the 2 classes.

> The Cluster has to apperar before any of the services it manages, right?,
> so it can be called from the init.
>
> Why not make this dependency explicit?
>

The more important question is, How can I get 2 phase initialization with
the current MBean code base now that you've removed init().  Does your patch
you gave me show how to do this?

Bill




___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] RE: Deployment exception on Clustering

[David Jencks]

On 2001.11.16 17:33:17 -0500 Bill Burke wrote:
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> David
> > Jencks
> > Sent: Monday, November 12, 2001 10:22 PM
> > To: Andreas Schaefer
> > Cc: [EMAIL PROTECTED]; Bill Burke; David Jencks
> > Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
> >

> 
> The more important question is, How can I get 2 phase initialization with
> the current MBean code base now that you've removed init().  Does your
> patch
> you gave me show how to do this?

I think so, I think the same code is executing in the same order as it used
to be, for the HAJNDI.

Used to be:

ClusterPartition init
HAJNDI init
ClusterPartition start
HAJNDI start

Now, ClusterPartition has a reference to HAJNDI, so start wont be called on
it until HAJNDI is started.

What I did is like this (and may have a problem-- see below)

HAJNDI start (empty method)
ClusterPartition Start (does this, in terms of old methods:
   CP init
   (calls registerCluster on HAJNDI) which contains
  HAJNDI init
  HAJNDI start (!!!this might be a problem!!!)
   CP start


If it is necessary to put the HAJNDI start last, you can make another
method call from ClusterPartition to HAJNDI.

Hope this is getting a little clearer;-)

Please ask more if there is anything else I can do.

david jencks

> 
> Bill
> 
> 
> 
> 
> 

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development