> What do you mean ? When an app is deployed on one host in the
> cluster do you
> plan to copy it to all instances ?

exactly, imagine the benefit of companies running 10 tomcat instances.

> You can do that by creating an mbean and having it listen - look at
> MapperListener for an example.

will do, sounds like good way to go.

> I'm not very familiar with your impl - I assume each instance in a cluster
> has an "ID". I hope this ID is in sync with the jvm-route and the
> JMX domain

as for now, it doesn't really care about jvmroute and all the other good
stuff since it is an all to all cluster. Since all cluster nodes have the
same state, it doesn't matter where the load balancer redirects it. so you
could have sticky session load balancing, or a per request round robin.

Once we do more efficient clustering ie primary and secondary state holders,
then we need to coordinate a way to load balance around that.

Filip

> -----Original Message-----
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache
> Sent: Thursday, March 20, 2003 4:57 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Cluster wide deployment, question
>
>
> Filip Hanik wrote:
>
> > I'm about to implement cluster wide deployment.
> > Who should initiate the call to deploy cluster wide, should it be the
> > StandardHostDeployer or the manager servlet?
>
> What do you mean ? When an app is deployed on one host in the
> cluster do you
> plan to copy it to all instances ?
>
> In any case - the "right" way to do it is to listen for JMX registration
> events - that will tell you when a new webapp was registered in an
> instance, regardless of the method ( StandardHostDeployer,
> manager servlet,
> admin, other app calling methods directly ).
>
> You can do that by creating an mbean and having it listen - look at
> MapperListener for an example.
>
> I'm not very familiar with your impl - I assume each instance in a cluster
> has an "ID". I hope this ID is in sync with the jvm-route and the
> JMX domain
> :-) ( i.e. it is the Engine name )
>
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to