[mod_cluster-dev] Enabling mod_cluster by default in AS6

[Paul Ferraro]

On Tue, 2010-05-04 at 10:52 -0500, Brian Stansberry wrote:
> Good stuff. :)
> 
> When can this appear in a release (i.e. a CR2) so Bela can plug it into 
> his M3 and play? 

The changes discussed in this thread are already checked-in to trunk.

JFC, can we do a CR2 release this week?  Admittedly, this would not
really be a proper release candidate - as we have a few more issues to
fix prior to GA...
Let's create a CR3 release in jira and reassign less urgent fixes
accordingly, so we can get CR2 out asap.  Thoughts?

> He's your best tester. It would be nice to get this 
> into AS trunk ASAP as well.

As soon as CR2 is out, I'll update the AS.

> On 05/04/2010 10:16 AM, Paul Ferraro wrote:
> > On Tue, 2010-05-04 at 09:57 +0200, Bela Ban wrote:
> >> Paul Ferraro wrote:
> >
> > <snip>
> >
> >> TBH, I'm not a 100% sure what the code above does... is it adding a
> >> lifecycle listener dynamically if mod_cluster is started after JBossWeb
> >> ? Actually, I guess this will always be the case as you have a
> >> dependency from mod-cluster to JBossWeb.
> >
> > In summary, if the jbossweb server exists that means the WebServer
> > service was already started.  If this is the case, then dynamically add
> > the mod_cluster lifecycle listener, and trigger the init and start
> > events manually (since those events were missed).
> >
> >>> This requires a small modification to the
> >>> MicrocontainerIntegrationLifecycleListener, which will need to delegate
> >>> equals(Object) to its non-null delegate listener if the argument is a
> >>> LifecycleListener, but not an instanceof MCILL.
> >>>
> >>> So, this essentially does what you described. There are couple other
> >>> advantages:
> >>> 1. We no longer need to define a<Listener/>  in server.xml (closes
> >>> MODCLUSTER-20 !!!).
> >>
> >> Because you're adding the listener dynamically, a la MODCLUSTER-20, right ?
> >
> > Right.
> >
> >> Wow, that would be great !
> >>
> >>> 2. We no longer rely on the finicky
> >>> MicrocontainerIntegrationLifecycleListener, which requires (so to avoid
> >>> a call to JBossWebMicrocontainerBeanLocator.getInstalledBean(...) on
> >>> every lifecycle event) that the delegate listener is deployed prior to
> >>> the start() of the WebServer service.
> >>
> >> OK
> >>
> >>> 3. There is no longer any manual step to enable mod_cluster (e.g.
> >>> uncommenting<depends>ModClusterListener</depends>) - the existence of
> >>> mod_cluster.sar is enough.
> >>
> >> Cool ! So the mod-cluster SAR has a dependency on WebServer, and when
> >> you dynamically deploy mod-cluster.sar, JBossWeb will already be
> >> running, good !
> >
> > Yup.
> >
> >>> 4. It is still compatible with the mod_cluster configuration bundled
> >>> with AS 6.0.0.M1-M3.
> >>
> >> OK
> >>
> >>> 5. mod_cluster is now hot-deployable, independently of jbossweb. The
> >>> addition of a corresponding stop() that removes the lifecycle listener
> >>> will allow mod_cluster to be hot-undeployable.
> >>
> >> Great !
> >
> > Yes - now mod_cluster can finally behave like a normal jboss service...
> >
> >>> Thoughts?
> >>
> >> Excellent ! I like this a lot, because it simplifies things a lot and
> >> reduces the amount of configuration to be done.
> >>
> >> So when this is done, what will the configuration steps be (on the JBoss
> >> AS side) ?
> >>
> >>     1. Add a jvmRoute to server.xml [optional, as jvmRoute is generated
> >>        if absent]
> >
> > The default JvmRouteFactory allows system property override as well, via
> > -Djboss.mod_cluster.jvmRoute
> >
> >>     2. mod-cluster.sar:
> >>           1. Set the proxy list (jboss.mod_cluster.proxyList) [optional
> >>              if IP multicasting works, as advertise is enabled by default]
> >
> > Advertise is not enabled by default - in order to minimize jboss's
> > default port footprint.  Advertise can be enabled via a system property.
> >
> > So, in summary, the servers just need to be started with either:
> > -Djboss.mod_cluster.advertise=true
> > or
> > -Djboss.mod_cluster.proxyList=....
> >
> >>           2. Set the domain [optional if we use a system prop, or the
> >>              default domain]
> >>           3. Use HAModClusterService instead of ModClusterService: for
> >>              the mod-cluster.sar located in 'all', can we make this the
> >>              default ?
> >
> > I alluded to this earlier when I mentioned splitting the
> > ModClusterListener bean into a separate conf file and creating 2
> > versions of it.  One using HAModClusterService for use in the all
> > profile, the other using ModClusterService for use in the default
> > profile.
> >
> > _______________________________________________
> > mod_cluster-dev mailing list
> > mod_cluster-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/mod_cluster-dev
> 
>