Hi Filip,
sorry, that this mail will be lengthy, but I prefer to explain my
reasons for OACC in more detail.
Filip Hanik - Dev Lists schrieb:
------
The sandbox provides a port of TC 5.5 cluster for
Tomcat 6 in order to ease Tomcat 6 migration for webapps
using Tomcat 5.5 cluster. Using OACC users can first
switch to TC 6 with the same cluster configuration and
later migrate to the very different HA/Tribes cluster.
------
In my experience, cluster users which really have a critical app
running, hesitate to switch to a completely different cluster
implementation. On the other hand they might want to move on to Tomcat 6.
I've not run into this scenario, customer's were actually happy to
switch, as it provided them with much more flexibility.
There might be cultural differences between the states and europe. I
often work with people from the operating units who prefer using proven
technology. My experience differs from yours. I'm *not* walking about
new cluster users.
OACC provides an easy way of doing a two step migration. Go to Tomcat
6 (which in its core parts is not too different from 5.5) and then
test the new HA/Tribes cluster.
At the moment OACC is only a sandbox. If it looks good (functionality
and stability) - which my first tests seem to indicate - then I would
propose an optional extra download for TC 6 containing OACC. Filip's
cluster has the bigger potential and should stay the default
automatically contained in each download of TC 6, s.t. cluster newbies
directly start with that one. But for users having a running TC 5.5
cluster I think it's nice - and necessary - to provide the OACC
alternative.
if this is for migration, why not provide a migration document instead.
the only difference between 5.5 and 6.0 is the messaging and membership
mechanism, which are fairly broken in 5.5. The actual session
replication code is the same, but more bug fixes, in 6.0.
if there is something lacking in 6.0 that you have in 5.5, then I would
add that to 6 instead of doing this effort you're doing now.
Filip
First: this *is* for migration. I have no interest in putting more time
into features for OACC. As you will have noticed, after adding the
fastasyncmode to OACC we efficiently went into maintenance mode and only
fixed problems detected in real life. No major new features were added.
The RELEASE-PLAN file I added to OACC clearly states, that there is no
plan to add new features to OACC.
Why not simply improving HA/Tribes? Because the time frames do not fit.
I expect about 6 to 12 more months, until we can be very confident in
the runtime behaviour of HA/Tribes. But I want to provide people a way
of moving forward with their critical applications during 2008. TC 6 in
general is ready for prime time and I want to help with that.
Why am I so pessimistic about reliability of HA/Tribes? The bigger part
is not specific to the existing HA/Tribes code. The argument is more
general: the code base is large and allows a lot of different
configuration combinations. So the amount of real usage needed to find
glitches is not small. On the other hand people only start using the TC
6 cluster. So I expect it'll take another 6 to 12 months for users to
provide us with enough experience. HA stability doesn't mean it runs
usually, it means it behaves well under unexpected conditions.
But I do not only have these very abstract concerns. There is room for
improvement and I'll happily help as I did in 2004 for the TC 5.0/5.5
cluster. Examples for improvements:
- monitoring (the old MBeans are gone and there's no good alternative)
- Java 5 dispatcher: it doesn't use a queue at the moment,
instead it uses a thread pool.
- we need to find out, if threads are to exensive for caching messages
in case replication gets slow or stuck
- We can easily run into ordering problems if we use a separate thread
for each message. I know there's an ordering interceptor, but
there's a big diference between you can optionally use it or you
have to use it to make replication correct.
- documentation: the huge flexibility of HA/Tribes needs for better
documentation
Important: I'm not blaming you! There's nothing to complain about at
all. You have put very much time into the old and into the new cluster,
and you contributed the two most attractive frontpage features for TC
(HA/Tribes and Comet). Without your work, there would be no cluster at
all. And I'm also offering to help. It's quite normal, that such a big
and young code base has room for improvement.
Also important: those examples are the ones that come to my mind from
having a recent look at HA/Tribes. More important for me those items is
the general fact above. The volume of the code and the configuration
complexity will require enough operating hours to find out those
problems, that we know are not able to think of.
In my opinion the biggest dilemma we face is:
Can we provide the OACC alternative, because at least one committer
thinks it is safer than HA/Tribes and at the same time convince new
cluster users to go the HA/Tribes way.
If you take a look at the text documnts I put into the trunk directory
of OACC I always stress the fact, that OACC is a migration step for
existing customer users. I definitely support the claim, that HA/Tribes
is much more powerful and flexible, and that the project as a whole will
put all development efforts into HA/Tribes and not into OACC. HA/Tribes
should stay the default and be bundled with each TC 6 download.
OACC could be an optional download for those who want or need to migrate
to TC 6 but prefer to stick to a cluster implmentation they got used to.
The nice thing is, that it will not hinder TC development. I carefully
committed the changes need to make TC 5.5 cluster TC 6 compatible in a
sequence of very simple commits. As one can see, the relationship
between OACC and Tomcat 6 is very straightforward. There's only one TC 6
class, which needed a single method addition. And we will get rid of
this too.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
