Re: [infinispan-dev] Including CENTRAL_LOCK in our stacks, COUNTER
On 17 October 2012 12:40, Bela Ban <bban(a)redhat.com> wrote:
On 10/17/12 1:11 PM, Sanne Grinovero wrote:
>
> Having my app introduce this on the stack leads to other kinds of
> problems, I think it would be way simpler if the protocols where
> always available on each participating node.
OK. So how about a separate stack that's available for OGM/HS etc including
CENTRAL_LOCK and COUNTER ? These 2 protocols incur almost no overhead in
passing messages down (as they pass every message down) and a small overhead
in the up-direction (as they check for presence of a protocol-specific
header).
Well to simplify things, as you say there is no significant overhead,
and I guess no trouble if you don't need them.. so why don't add them
in the default stack?
Might be useful for many other reasons / applications.
> The Coordination election isn't good enough as
> - that node might not have Search running
> - I'd like to distribute the load of different indexes on different
> nodes, basically hashing on the index name to suggest a favourite
> node.
OK
> So if I have to add the stack at runtime.. the nodes not having my
> services deployed yet won't have the protocol, I assume CENTRAL_LOCK
> won't work properly if some nodes - especially the coordinator - don't
> have it installed?
Correct. But if all of the nodes running HibernateSearch create the same
stack dynamically, and they're the only ones using it, then the view will be
including only those nodes, so their coordinator is correct (although it may
not be the same as the one of the main channel).
> I already have the option to create a new Channel and bypass any
> trouble, the point is I'd like to reuse the single channel, both for
> efficiency reasons but also to guarantee consistent views, consistency
> with mod_cluster, etc..
OK
--
Bela Ban, JGroups lead (http://www.jgroups.org)
OK :)