Hi Filip,
Filip Hanik - Dev Lists schrieb:
Rainer Jung wrote:
<snip>
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)
ClusterJMXHelper.java in tomcat/trunk, feel free to add more
- Java 5 dispatcher: it doesn't use a queue at the moment,
instead it uses a thread pool.
huh? Yes, the thread pool uses a queue to queue its jobs. set threads=1,
and you have a queued async sender, just like 5.5
- we need to find out, if threads are to exensive for caching messages
in case replication gets slow or stuck
not sure what this means
- 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.
use dispatcher with a single thread, it becomes automatically ordered,
just like 5.5
TC session replication has never really relied on ordering, even in 5.5
you can get unordered messages since they are received using a thread
pool. an ordering interceptor is really the only way you could guarantee
it.
- documentation: the huge flexibility of HA/Tribes needs for better
documentation
agreed
sounds little bit like there is a disconnect on the knowledge of what
5.5 provides vs 6.0
That's very likely. But as I wrote, my main concern is of a much more
general nature and contained in what you abbreviated with "<snip>".
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
- taking over the whole queue by the remover instead of
removing item by item (again less lock contention paired with
less context switching)
- 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
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 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.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
