Filip Hanik - Dev Lists schrieb:
hi Rainer,
so to tell the true tale, isn't the story...
- You got customers on 5.5 using session replication
Of course, and that helped in making the 5.5 cluster better.
- Your customers want to move to Tomcat 6
I do hope so! I thought that's something we want all our users to do?
But: I didn't do OACC because *anyone* asked me to. I reflected the
actual situation and I still think it is a good idea.
- You're not confident about the maturity of Tomcat 6's clustering
codebase, mainly cause you haven't used it, even though it was
originally developed in 2006. I would argue that the this doubt is
mainly a lack of both usage and understanding
Yes, as I said I'm not confident in its maturity. No, it mainly comes
from the fact that it is pretty young. Yes, it was developped in 2006
but it first got delivered as default with TC 6. And TC 6 is getting
wide adoption now - but not clustering! As I said, I'm talking about
experience coming from users and I expect this to need another 6 to 12
months to grow.
- So, to mitigate this, you'd like to use the ASF as the delivery
vehicle for your custom code base to allow your customers to switch to
Tomcat 6
So how should I interprete this statement? The terms "vehicle", "your
codebase" and "your customers" make it a very insulting statement. At
least I do feel insulted.
But what are we talking about:
- "your codebase": its our codebase. If we had to find a single person
for this cluster codebase, then it would be your codebase. As everyone
can see from yesterdays commit, the codebase is nearly identical from
the TC 5.5 codebase. I don't want to have "my" codebase. I want us to
cooperate for a strong shared Tomcat codebase.
- "your customers": I get a lot of ideas from my customers, and yes they
belomg to our community as well as yours. I try to be very cautious not
to bring in very customer specific things into the Tomcat project. I was
thinking about cluster users of TC 5.5 and how they could move forward
and this is why I did port the TC 5.5 cluster. And yes, I know users who
would profit from that. But the motivation for OACC is much more
general. Migration concepts in the world of high availability need to be
very solid. The Tomcat project (we) cancelled support for its existing
cluster module from one major version to the next, without any early
warning. That's not good practise in the HA world. So yes, I want to
mitigate. I want to mitigate the fact, that we didn't do the right
decisions with respect to cluster users when we dropped the existing
cluster in TC 6. And I am very happy, that under the hood we didn't
change the inhterfaces too much so that it is very simple to mitigate
this. OACC was done in less than a day.
- "vehicle": The official Tomcat project is the right place to offer
OACC and to care about migration issues. We only started lately to act
more properly with respect to deprecations and end of live
announcements. This shows the necessary awareness for the needs of our
users since Tomcat is now the leading servlet container and is
ubiquitous. And I'm very open here about my motivation and plans. Most
of us need to combine business work with our community work. And the ASF
model allows this. The questions w.r.t. doing the work inside an ASF
project are more like: does it lead to the right result for the
community? Do we work together in good collaboration? Is our decision
process open? And yes: w.r.t. meritocracy you are much in front of me.
All in all I feel accused by the above formulation.
I'm ok with you doing this for those folks in sandbox, I'd probably
would recommend that we not put this as an official release to Tomcat,
as I believe our small group would do much better focusing the effort
against the current implementation. Putting into a release means we
would spend resources in the bugs that arise from the port itself.
The effort point is a valid point. For this reason I'm OK with clearly
stating that OACC is a dead end. I already put some (probably not that
harsh) statement in the release plan file I committed yesterday before
our discussion even started.
Concerning official module releases I have a differing opinion:
- I will not suggest to bundle OACC additionally inside any other
Tomcat release file
but
- I think it will be a strong statement from a responsibility point
of view (a project asset), to provide OACC as an official
separate release download. But at least for me it's to early
to propose this, because I first want to get a clearer picture,
of what will be included in OACC. At the moment it builds and works,
but something we deliver needs to contain other parts. Not far away,
but not finished yet.
I do have some comments inline too
Rainer Jung wrote:
Although I think that a detailed technical discussion is not the right
way to determine the usefulness of OACC, some comments:
- monitoring: your reference to trunk strengthens my argument about
maturity of code. Taking trunk code instead of TC 5.5 code is the
maximum opposite approach.
- Java 5 dispatcher: I mostly agree. I got lost in the code. The code
I thought was responsible was transport/PooledSender.java which uses a
fixed pool of threads without queueing. I overlooked somehow the
Executor with queue in the Java 5 dispatcher. Nevertheless there's
still some discrepancy, because we added some aspects to the queue in
5.5 which are gone now:
- lock fairness biased to the remover in order to reduce the
likelyness of lock starvation
the LinkedBlockingQueue implements a two-lock algorith to avoid lock
contention around simultaneous puts and takes.
Sounds very good, though Executor uses queue.offer() and offer() does
need both of them. Neverteless I'm confident, that the j.u.concurrent
queues and Executor are very efficient and stable. Using them may need
some tuning, if my reasoning about primary and secondary functionality
is right (bounding queue size, maybe more).
- taking over the whole queue by the remover instead of
removing item by item (again less lock contention paired with
less context switching)
yes, that's a neat idea, question is how it compares against the
two-lock algorithm
since TC 5.5 uses a single lock, my guess would be there is a larger
risk of contention there than a two lock algorithm
That's quite possible. The queue actually supports exactly this "take
all of it" idea, but I didn't check the Executor implementation for it.
It would increase thread to memory locality. But this is more
performance optimization. As long as we are far away from lock
contention, I'm fine.
- limited size: Favor prevention of OutOfMemoryError over replication
correctness in case we run into replication communication problems.
Priority is always on the primary function, i.e. a working webapp,
clustering is always a secondary function which should be as
transparent as possible during normal operations
this is also implemented, and very accurate. default queue size is set
to 64MB, and you can control what behavior to use when you reach that
limit.
OK, thanks. Although the term queue size is a little misleading I agree.
Why is the default to send synchronous (alwaysSend=true), when the
amount of outstanding messages reaches the limit? I have the impression,
that for session replication once we reach the limit it's likely that
replication has a problem and switching to synchronous then makes the
replication problem a problem for normal response delivery.
We could go into detail here, but I would prefer to do this in a
separate discussion thread. I don't think that those examples are big
problems, and maybe they are not problems at all.
I do agree that JMX support is a major uha, but the other points seem to
be based on not understanding or misunderstanding the current
implementations, and I'd like to address those for you
The technical points: quite possible. The structural motivation for
OACC: no, see above.
I want to stress once again my own experience, that a huge code base
implementing a complex apparatus needs time to mature. Thus I think
it's fair to not simply lock up happy TC 5.5 cluster users inside 5.5
and offer OACC as an intermediate step on the way to migrate to
HA/Tribes.
knock yourself out :)
Quite seriously: here I've got a language problem, I don't know how to
interprete this. Sorry about that.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
