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
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
