10:27 a.m.
When discussing the initial integration of mod_cluster into the AS, it
was decided that we would keep it disabled by default - but make it as
simple as possible to enable, i.e. by uncommenting the
<!--depends>ModClusterListener</depends--> withing jbossweb's mc
configuration.
The reasoning for this was that mod_cluster added unwanted overhead in
the case where it wasn't being used. As of version 1.1.0.CR1
(specifically, the completion of MODCLUSTER-103), mod_cluster's
container event handling and load balance factor calculation is
effectively bypassed if it has no proxies with which to communicate.
Consequently, I want to revisit this discussion.
I can think of a couple issues that would need to be addressed if the AS
shipped mod_cluster enabled by default:
1. If a user deletes mod_cluster.sar from their profile, jbossweb will
refuse to start since it has a dependency on the ModClusterListener bean
- the configuration of which was just deleted. This is rather annoying.
a. A potential workaround for this: move the mod_cluster jar and
configuration xml within the jbossweb service itself, rather than a
separate deploy/mod_cluster.sar. Those profiles that include jbossweb,
but do not want to include mod_cluster could include a "dummy"
ModClusterListener bean configuration - so the dependency is satisfied.
This dummy bean config should reside within jbossweb.sar. I think this
is preferable to maintaining 2 copies of the jbossweb mc configuration,
one with and one without the mod_cluster dependency.
b. Hmm - now that I think of it we may actually be able to drop the
jbossweb dependency altogether... The reason this dependency exists in
the first place is to ensure that mod_cluster sends the necessary
DISABLE-APP/STOP-APP/REMOVE-APP mcmp messages prior to shutdown of
jbossweb. In my fix for MODCLUSTER-131, mod_cluster's shutdown handling
was enhanced to react to the "jboss.tomcat.connectors.stopped" JMX
event, emitted prior to stopping the Connectors, which is the first
thing jbossweb does during shutdown. If I'm not mistaken, this may
ultimately mean that we can finally let mod_cluster depend on jbossweb,
and not the other way around. We still need mod_cluster to start before
the WebServer, but a simple dummy bean configuration should do the
trick:
<bean name="ModClusterLoader" class="java.lang.Object">
<demand targetState="Installed">ModClusterListener</demand>
<demand targetState="Instantiated">WebServer</demand>
</bean>
I could not use this previously because this said nothing about the
shutdown order of the two beans. But now, I think it should work.
Thoughts?
5:36 p.m.
On 04/30/2010 10:27 AM, Paul Ferraro wrote:
We still need mod_cluster to start before
the WebServer, but a simple dummy bean configuration should do the
trick:
<bean name="ModClusterLoader" class="java.lang.Object">
<demand targetState="Installed">ModClusterListener</demand>
<demand targetState="Instantiated">WebServer</demand>
</bean>
I could not use this previously because this said nothing about the
shutdown order of the two beans. But now, I think it should work.
Ales: does <demand targetState="Instantiated">WebServer</demand>
mean
"install me once WebServer is instantiated but before it reaches the
next state"? Or is it "install me once WebServer is at least
instantiated (although WebServer could be at a later state)"
The former could only be reliable if the MC knew about ModClusterLoader
before it started handling WebServer.
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
8:55 a.m.
Paul Ferraro wrote:
1. If a user deletes mod_cluster.sar from their profile, jbossweb
will
refuse to start since it has a dependency on the ModClusterListener bean
- the configuration of which was just deleted. This is rather annoying.
Maybe this is a general MC question for smart Ales :-) If we have a
dependency on a non-existing bean, can't we just ignore that dependency
? For example, if we read in all the beans at MC startup time, construct
a dependency graph and see that the ModClusterListener bean doesn't
exist, can't we ignore that dependency ?
The other question I have for Paul, is why does jbossweb have a
dependency on ModClusterListener ? Can't ModClisterListener simply query
JBossWeb (if available) for deployed contexts (if that's why it
registered as a listener) and then register if needed ?
If we could remove this dependency, we'd have one less thing to worry
about (and configure)...
a. A potential workaround for this: move the mod_cluster jar and
configuration xml within the jbossweb service itself, rather than a
separate deploy/mod_cluster.sar. Those profiles that include jbossweb,
but do not want to include mod_cluster could include a "dummy"
ModClusterListener bean configuration - so the dependency is satisfied.
Hmm, not really nice though...
b. Hmm - now that I think of it we may actually be able to drop the
jbossweb dependency altogether...
YEEEAAAHHH !
The reason this dependency exists in
the first place is to ensure that mod_cluster sends the necessary
DISABLE-APP/STOP-APP/REMOVE-APP mcmp messages prior to shutdown of
jbossweb. In my fix for MODCLUSTER-131, mod_cluster's shutdown handling
was enhanced to react to the "jboss.tomcat.connectors.stopped" JMX
event, emitted prior to stopping the Connectors, which is the first
thing jbossweb does during shutdown. If I'm not mistaken, this may
ultimately mean that we can finally let mod_cluster depend on jbossweb,
and not the other way around.
That's how it should be (see my comment above) !
We still need mod_cluster to start before the WebServer
Why ? Can't we simply grab the deployed contexts from JBossWeb ? If
mod-cluster is started before jbossweb, we'll get the deployed contexts
later, once jbossweb has been started. Do we get notifications about
when beans have been started ? If so we could listen for
jbossweb-started, and *then* grab all contexts...
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
11:25 a.m.
On Sat, 2010-05-01 at 15:55 +0200, Bela Ban wrote:
Paul Ferraro wrote:
> 1. If a user deletes mod_cluster.sar from their profile, jbossweb will
> refuse to start since it has a dependency on the ModClusterListener bean
> - the configuration of which was just deleted. This is rather annoying.
Maybe this is a general MC question for smart Ales :-) If we have a
dependency on a non-existing bean, can't we just ignore that dependency
? For example, if we read in all the beans at MC startup time, construct
a dependency graph and see that the ModClusterListener bean doesn't
exist, can't we ignore that dependency ?
I think I've found a better solution. See below.
The other question I have for Paul, is why does jbossweb have a
dependency on ModClusterListener ? Can't ModClisterListener simply query
JBossWeb (if available) for deployed contexts (if that's why it
registered as a listener) and then register if needed ?
The only reason it is there is to control startup order (and used to be
needed to control shutdown order, though not anymore). The current
jbossweb integration (via a server lifecycle listener) requires that
mod_cluster's listener (CatalinaEventHandlerAdapter) exists before the
WebServer starts.
If we could remove this dependency, we'd have one less thing to
worry
about (and configure)...
Agreed.
> a. A potential workaround for this: move the mod_cluster jar
and
> configuration xml within the jbossweb service itself, rather than a
> separate deploy/mod_cluster.sar. Those profiles that include jbossweb,
> but do not want to include mod_cluster could include a "dummy"
> ModClusterListener bean configuration - so the dependency is satisfied.
Hmm, not really nice though...
Admittedly not ideal...
> b. Hmm - now that I think of it we may actually be able to drop
the
> jbossweb dependency altogether...
YEEEAAAHHH !
> The reason this dependency exists in
> the first place is to ensure that mod_cluster sends the necessary
> DISABLE-APP/STOP-APP/REMOVE-APP mcmp messages prior to shutdown of
> jbossweb. In my fix for MODCLUSTER-131, mod_cluster's shutdown handling
> was enhanced to react to the "jboss.tomcat.connectors.stopped" JMX
> event, emitted prior to stopping the Connectors, which is the first
> thing jbossweb does during shutdown. If I'm not mistaken, this may
> ultimately mean that we can finally let mod_cluster depend on jbossweb,
> and not the other way around.
That's how it should be (see my comment above) !
> We still need mod_cluster to start before the WebServer
Why ? Can't we simply grab the deployed contexts from JBossWeb ? If
mod-cluster is started before jbossweb, we'll get the deployed contexts
later, once jbossweb has been started. Do we get notifications about
when beans have been started ? If so we could listen for
jbossweb-started, and *then* grab all contexts...
Right. Scrap that old idea. Here's what I think we should do (I spent
this morning validating that this works):
Edit mod_cluster MC config such that it depends on the WebServer bean
and is no longer "On Demand". e.g.
<bean name="ModClusterListener"
class="org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter">
<constructor>
<!-- To use the HA singleton version of mod_cluster, change this injection to
HAModClusterService -->
<parameter><inject bean="ModClusterService"/></parameter>
<parameter><inject bean="JMXKernel"
property="mbeanServer"/></parameter>
</constructor>
<depends>WebServer</depends>
</bean>
Add a start() MC lifecycle method to CatalinaEventHandlerAdapter that
looks like:
public void start() throws JMException
{
try
{
// If the catalina server is already registered, init/start mod_cluster
Service[] services = (Service[]) this.mbeanServer.invoke(this.serverObjectName,
"findServices", null, null);
if (services.length > 0)
{
Server server = (Server) services[0].getServer();
if (server instanceof Lifecycle)
{
Lifecycle lifecycle = (Lifecycle) server;
for (LifecycleListener listener: lifecycle.findLifecycleListeners())
{
// Test if listener is already registered
if (listener.equals(this)) return;
}
lifecycle.addLifecycleListener(this);
if (this.init.compareAndSet(false, true))
{
this.init(server);
if (this.start.compareAndSet(false, true))
{
this.eventHandler.start(new CatalinaServer(server, this.mbeanServer));
}
}
}
}
}
catch (InstanceNotFoundException e)
{
// Ignore
}
}
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 !!!).
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.
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.
4. It is still compatible with the mod_cluster configuration bundled
with AS 6.0.0.M1-M3.
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.
Thoughts?
2:57 a.m.
Paul Ferraro wrote:
>
> Why ? Can't we simply grab the deployed contexts from JBossWeb ? If
> mod-cluster is started before jbossweb, we'll get the deployed contexts
> later, once jbossweb has been started. Do we get notifications about
> when beans have been started ? If so we could listen for
> jbossweb-started, and *then* grab all contexts...
Right. Scrap that old idea. Here's what I think we should do (I spent
this morning validating that this works):
Edit mod_cluster MC config such that it depends on the WebServer bean
and is no longer "On Demand". e.g.
<bean name="ModClusterListener"
class="org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter">
<constructor>
<!-- To use the HA singleton version of mod_cluster, change this injection to
HAModClusterService -->
<parameter><inject
bean="ModClusterService"/></parameter>
<parameter><inject bean="JMXKernel"
property="mbeanServer"/></parameter>
</constructor>
<depends>WebServer</depends>
</bean>
Add a start() MC lifecycle method to CatalinaEventHandlerAdapter that
looks like:
public void start() throws JMException
{
try
{
// If the catalina server is already registered, init/start mod_cluster
Service[] services = (Service[]) this.mbeanServer.invoke(this.serverObjectName,
"findServices", null, null);
if (services.length > 0)
{
Server server = (Server) services[0].getServer();
if (server instanceof Lifecycle)
{
Lifecycle lifecycle = (Lifecycle) server;
for (LifecycleListener listener: lifecycle.findLifecycleListeners())
{
// Test if listener is already registered
if (listener.equals(this)) return;
}
lifecycle.addLifecycleListener(this);
if (this.init.compareAndSet(false, true))
{
this.init(server);
if (this.start.compareAndSet(false, true))
{
this.eventHandler.start(new CatalinaServer(server, this.mbeanServer));
}
}
}
}
}
catch (InstanceNotFoundException e)
{
// Ignore
}
}
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.
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 ?
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 !
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 !
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]
2. mod-cluster.sar:
1. Set the proxy list (jboss.mod_cluster.proxyList) [optional
if IP multicasting works, as advertise is enabled by default]
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 ?
WDYT ?
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
10:16 a.m.
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.
10:52 a.m.
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
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
9:45 a.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/mod_cluster-dev
10:11 a.m.
On 05/05/2010 04:45 PM, Paul Ferraro wrote:
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?
I need to fix (finish) or rollback MODCLUSTER-150 and would like to fix
MODCLUSTER-149 too. But that is only a day or 2.
But this Friday should be possible.
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?
Yep, I like the concept release often release early ;-)
Cheers
Jean-Frederic
2:57 a.m.
No hurry with respect to releasing mod-cluster CR2; I'm all set with my
demo, just need to create the images for GoGrid, EC2 and Rackspace.
However, once you released the changes we discussed (no dependency from
JBossWeb to mod-cluster); I'll probably have to update my slides for JBW...
Paul Ferraro wrote:
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?
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
3:18 p.m.
Paul Ferraro wrote:
> 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).
OK, got it
> 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
I assume you're referring to the *factory*, so would the property be
something like -Djboss.mod_cluster.jvmRoute.factory=CLASSNAME ?
> 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=....
OK. In order to create virtual images for GoGrid, EC2 and Rackspace, I
want to avoid using system properties as much as possible. So jvmRoutes
need to be either hard coded, or my startup script (/etc/init.d/jboss)
will have to provide unique values for them, e.g. via uuidgen.
> 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.
OK
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
9:40 a.m.
On Tue, 2010-05-04 at 22:18 +0200, Bela Ban wrote:
<snip>
>> 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
I assume you're referring to the *factory*, so would the property be
something like -Djboss.mod_cluster.jvmRoute.factory=CLASSNAME ?
No - the jvm route itself.
e.g. -Djboss.mod_cluster.jvmRoute=node1
Implementation-wise, the default JvmRouteFactory is:
new SystemPropertyJvmRouteFactory(new UUIDJvmRouteFactory(),
"jboss.mod_cluster.jvmRoute");
So, it returns the given system property, if defined; or if not, a UUID.
If you want to override the factory itself, you would modify the
jvmRouteFactory property of the ModClusterConfig bean within
mod_cluster-jboss-beans.xml.
e.g.
<bean name="ModClusterConfig" class="...">
...
<property name="jvmRouteFactory">
<!-- Generates jvm route as: bind-address:port:engine-name -->
<bean class="org.jboss.mod_cluster.SimpleJvmRouteFactory"/>
</property>
...
</bean>
>> 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=....
OK. In order to create virtual images for GoGrid, EC2 and Rackspace, I
want to avoid using system properties as much as possible. So jvmRoutes
need to be either hard coded, or my startup script (/etc/init.d/jboss)
will have to provide unique values for them, e.g. via uuidgen.
You don't need to use a system property to get unique auto-generated jvm
routes by default. See above.
In general, system properties are only used for convenience, i.e. to
allow the user to override commonly used configuration properties via
command line.
2:47 a.m.
Paul Ferraro wrote:
> I assume you're referring to the *factory*, so would the
property be
> something like -Djboss.mod_cluster.jvmRoute.factory=CLASSNAME ?
No - the jvm route itself.
e.g. -Djboss.mod_cluster.jvmRoute=node1
Implementation-wise, the default JvmRouteFactory is:
new SystemPropertyJvmRouteFactory(new UUIDJvmRouteFactory(),
"jboss.mod_cluster.jvmRoute");
So, it returns the given system property, if defined; or if not, a UUID.
Ah, OK. Is the factory pluggable, can I replace it with my own impl ?
If you want to override the factory itself, you would modify the
jvmRouteFactory property of the ModClusterConfig bean within
mod_cluster-jboss-beans.xml.
e.g.
<bean name="ModClusterConfig" class="...">
...
<property name="jvmRouteFactory">
<!-- Generates jvm route as: bind-address:port:engine-name -->
<bean class="org.jboss.mod_cluster.SimpleJvmRouteFactory"/>
</property>
...
</bean>
Got it, answers my question above
>>> 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=....
> OK. In order to create virtual images for GoGrid, EC2 and Rackspace, I
> want to avoid using system properties as much as possible. So jvmRoutes
> need to be either hard coded, or my startup script (/etc/init.d/jboss)
> will have to provide unique values for them, e.g. via uuidgen.
You don't need to use a system property to get unique auto-generated jvm
routes by default. See above.
OK, good.
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
5301
days inactive
5307
days old
mod_cluster-dev@lists.jboss.org
12 comments
4 participants
participants (4)
-
Bela Ban -
Brian Stansberry -
jean-frederic clere -
Paul Ferraro