Hi,
Am 05.05.2006 um 05:34 schrieb Filip Hanik - Dev Lists:
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.
+1
Currently we can copy the old one to TC6 to help people start
testing. The new
cluster module is pretty cool and after it was complete, we deprecate
the good old horse :-)
You change every day a lot. Duplicate those changes are a nightmare
and do much work.
Better we test the new cluster together and after the first
development is finished, we can copy and maintain it.
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
replication,
probably a second attempt at farming, delta versioning and many
other features.
Cool! After my conference week I hope start real testing.
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
+1, to intergrate the build at tc 5.5.
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
embedded,
that container would probably want to share this comm resource,
and they are
able to through JNDI.
I thing JMX is the better option!
4. JMX, yes, hit it on the nail, the
re 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
MalformedObjectNameException
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.
Both are good platforms, but you thing we can use it directly?
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.
Yes! Yes, I think we need a better JMX core that are independent form
implementation. Like a Tomcat JMX API
and people can easier switch implementation and make real dynamic
remote management possible
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.
Let us add it for eaisier testing.
+1
have a great Friday folks!
Thanks and also have nice day...
Peter
Filip
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 <[EMAIL PROTECTED]> wrote:
On 5/4/06, Remy Maucherat <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
