>Then simple cluster setup currently not working.
that's ok, I haven't voted "+1 stable" yet :) I will get to it.
Filip
Peter Rossbach wrote:
Am 23.02.2006 um 15:05 schrieb Filip Hanik - Dev Lists:
>Peter Rossbach wrote:
as you might understand, it will take me longer time to explain the
Am 23.02.2006 um 15:05 schrieb Filip Hanik - Dev Lists:
>Peter Rossbach wrote:
as you might understand, it will take me longer time to explain the
design to you than to just do it, and you can learn it from the
code itself. you'll catch on it it eventually.
That is a way, but I thing like
>Peter Rossbach wrote:
as you might understand, it will take me longer time to explain the
design to you than to just do it, and you can learn it from the code
itself. you'll catch on it it eventually.
>Q: Break your ReplicationListener/ClusterReceiverBase change the
cluster default mode ?
Hey Filip
can you tell us more about the your change plans, and how I can help?
I thing the current cluster changes are a high risk and it was better
to start those changes for TC 6. When next cluster generation is
stable, then we make a backport to TC 5.5
One of me ideas is, that we build
couple more changes coming up.
today in the NIO setting waitForAck="false" means essentially async, and
waitForAck="true" means sync, meaning that the session will get updated
across the entire cluster before returning to the request.
in the next release waitForAck="true" means that the recei
new features and new development has historically always been done
against the head revision.
If you want to put something into maintenance, then that becomes a branch
for example
VERSION
| ---> HEAD REV ---> NEW DEVELOPMENT
|
| ---> BRANCH ---> MAINTENANCE MODULE
in our case
5.5.15
Hey Filip,
what I see is you want make an innovative step. Great, I m very
motivated to
help that we implement a next generation.
But, why do we this implementation not inside a sandbox, branch or
separate module?
Last year I learned that big changes are great, but it is easy to
make fa
Peter Rossbach wrote:
>I have add the compress flag inside the protocol.
>It is usefull to send message with an without compression.
>For short messages it is not usefull to compress, it is an overhead.
There is no question whether compression is useful or not.
The compression flag should have n
Hey Filip
Why do you think we must move the cluster JMX MBean code?
OK, then we can use the cluster components without JMX, but is this
really usefull?
A lot of my customers have add there own monitoring to the current
cluster MBeans.
This is really important to see trends and analyse bad sze
