tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Core webapps and clustering
Date Fri, 05 May 2006 03:34:24 GMT
I'd thought I'd chip in my 2 cents,

1. I don't think we should keep maintaining two clustering modules in TC6,
   the old one has too many limitations, I would leave it as a module 
since its stable,
   but I don't have any plans of trying to beat the dead horse and try 
to make it do
   something it wasn't built to do.
   The new "ha" module, which is far from complete is trying to address 
most of these
   limitations, but also extend to features like context attribute 
   probably a second attempt at farming, delta versioning and many other 

2. I would integrate the new "ha" module into the main tree
   as Remy suggested, easier to catch when it breaks,
   and session,context and other data management is something that
   is pretty intimate with Tomcat's code base

3. I was gonna make the "comm" layer, default to tribes
   but be pluggable, if someone prefers to use something else, like 
Appia, Spread, jgroups etc.
   To avoid more server.xml clutter,
   I was simply thinking of binding the comm layer into the
   JNDI tree as a regular resource so that resources simply
   can look it up and take advantage of it. That way, when tomcat is 
   that container would probably want to share this comm resource, and 
they are
   able to through JNDI.

4. JMX, yes, hit it on the nail, there is nothing pluggable about 
tomcat's JMX right now,
   For example, MBeanUtils.createObjectName(String,Connector), if the 
connector does not
   contain the string "CoyoteConnector" it simply throws a 
   So this area would need to be revisited in large before it would be 
something like
   Rickard Oberg created for JBoss that made it so pluggable through JMX 
and MBeans,
   geronimo has something similar through their GBeans/XBeans.
   On a personal note, I think JMX should do monitoring and I think 
injection can be done in
   many more ways. but that is a philosophical point.

I do see the benefit of adding the new cluster module "ha" to the main 
tree, and I would support that effort.
I would keep the old "cluster" module as a module, eventually sunsetting 
it. I would keep "groupcom" as a module
as this is not really a core tomcat feature, but providing the 
context/session management is.

have a great Friday folks!


Yoav Shapira wrote:
> Hola,
> Since you asked for opinions, personally I'm:
> - In favor of having one clustering implementation, but I think
> everyone is, no whoop there
> - Would prefer that clustering, like admin, stay a little module
> that's easily added to the core (and in general would like to keep the
> core as small as possible)
> - Agnostic on JMX versus server.xml (can see equal justification for 
> both)
> A lot of this is just style preference.  As long as we have a working
> clustering module, I'm sure it will be fairly easy to have a distro
> with it and a distro without it.  That's why I haven't chimed in much
> on this, I don't have a strong preference either way.
> Yoav
> On 5/4/06, Costin Manolache <> wrote:
>> On 5/4/06, Remy Maucherat <> wrote:
>> > Costin Manolache wrote:
>> > > It's not about using a mini-jboss architecture, but about a more
>> > > consistent and simpler
>> > > configuration.
>> > >
>> > > IMO JMX should be used for configuration when possible, instead of
>> > > adding more weird
>> > > syntax to server.xml.
>> >
>> > I tried it quite hard at some point (it's the embedded distribution),
>> > and it didn't work out that well. It's actually more complex.
>> >
>> > The first task is to optimize modeler (you'll do it, right ?), and 
>> then
>> > maybe to use modeler exclusively in Tomcat (avoiding all direct JMX
>> > dependencies).
>> I'm actually trying to optimize it and finally implement the 'persist 
>> changes',
>> but it'll take some time, I get less than 1h per day to work on open 
>> source.
>> I would say jboss style config is not _that_ more complex, and even 
>> 3.3 style
>> config was acceptable for many modules ( well, people might not agree
>> with that,
>> bit at least it was simple enough ).
>> > > What is 'core module' and not is a complex issue - obviously what
>> > > ships in the 'default' distro will
>> > > change with each release. But clustering seems like a big enough and
>> > > separate enough component to me, if this is not a good candidate for
>> > > 'separate module' - I don't know what would be. It's clearly not 
>> used
>> > > by all users, it has 2 implementations, etc.
>> >
>> > And it needs to get back to 1 implementation in a hurry :) I am
>> > conceptually ok with it being a module, though, although I would be
>> > happier if it was in the main tree (this way it's harder to ignore 
>> when
>> > the build is broken).
>> :-)
>> Costin
> -- 
> Yoav Shapira
> Nimalex LLC
> 1 Mifflin Place, Suite 310
> Cambridge, MA, USA
> /
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message