[mod_cluster-dev] Enabling mod_cluster by default in AS6

[Brian Stansberry]

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


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat