On 6 March 2012 13:59, Bela Ban <bban(a)redhat.com> wrote:
On 3/6/12 2:41 PM, Sanne Grinovero wrote:
> I might need COUNTER as well in the stack for certain configurations.
>
> AFAIR, COUNTER would not affect the stack unless invoked explicitly so
> I'm assuming when I'll finally use it I should be able to enable it on
> all relevant configurations by default without fear of affecting other
> users of the same channel; so being able to insert it dynamically on
> an existing stack would be very useful, however it sounds like an
> unpolished hack: one might add protocols which affect other Channel
> users, or create unintended side-effects.
Yes, say someone might insert SEQUENCER on top of COUNTER after COUNTER
was inserted. This has unintended consequences, now all counter
invocations are globally ordered, which makes no sense as COUNTER uses
locks to provide exclusive access and thus doesn't need global order !
While it is useful to be able to dynamically insert protocols, e.g. for
testing, this can become a nightmare, e.g. when support asks for the
config and it doesn't include either SEQUENCER or COUNTER !
Also, IIRC the channel used by Infinispan is also used by the AS
(copying Paul), so changes to the stack will also affect the AS.
> Could we do better and provide a shared base communication channel on
> top of differently configured logical channels? Conceptually similar
> to the MuxChannel, but moving the split point to a lower point in the stack.
Is this something similar to the shared transport [1] ? I'm not sure but
AFAIK the AS already uses a shared transport. Is what you suggest above
similar to a shared transport ?
Ha yes that looks like perfect!
But looking at the diagram, wouldn't it be useful to have those stacks
share PING, MERGE2 and FD ?
Taking a step further (and getting back to the topic), why not share
the full stack up to SEQUENCER or COUNTER,
so that we have two "virtual" channels but not having the two affect each
other?
-- Sanne
[1]
http://www.jgroups.org/manual-3.x/html/user-advanced.html#SharedTransport
--
Bela Ban
Lead JGroups (
http://www.jgroups.org)
JBoss / Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev