[infinispan-dev] Including CENTRAL_LOCK in our stacks, COUNTER

[Sanne Grinovero]

On 17 October 2012 12:40, Bela Ban <bban at 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 :)