Re: [mod_cluster-dev] Enabling mod_cluster by default in AS6

Good stuff. :) When can this appear in a release (i.e. a CR2) so Bela can plug it into his M3 and play?

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

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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/mod_cluster-dev