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