[infinispan-dev] IgnoreExtraResponsesValidityFilter

[Dan Berindei]

Good catch Manik! I just copied the approach from
ClusteredGetResponseFilter and I didn't think too much about
performance issues.

Bela, the BitSet approach sounds a little better than a simple counter
from a debugging perspective. But I think we're also missing some
synchronization at the moment, and with the counter approach could be
made thread-safe with minimal overhead by using an AtomicInteger. I
assume using a counter only is safe (i.e. RspFilter.isAcceptable()
will never be called twice for the same target).

ClusteredGetResponseFilter could probably use the same treatment,
except the targets list is quite small so we can search in the list
directly instead of creating a HashSet with the same contents.

Cheers
Dan


On Sat, Jan 14, 2012 at 4:06 PM, Bela Ban <bban at redhat.com> wrote:
> Another implementation could take the current view, and create a BitSet
> with the size being the length of the view, and every bit corresponds to
> the position of a member in the view, e.g.:
> V1={A,B,C,D,E,F}, bitset={0,0,1,0,1,1} means that responses have been
> received from C, E and F.
>
> On 1/13/12 8:20 PM, Manik Surtani wrote:
>> Looking at IgnoreExtraResponsesValidityFilter - this seems to be a scalability issue!  It seems to copy a set of every address in the cluster and gradually remove entries as responses come in.  Isn't this a scalability issue?  Since - assuming a large cluster - for every prepare command, we create a collection, copy into it the entire list of addresses (think hundreds of nodes x hundreds of concurrent threads) only to "count down" on the responses.  I'm almost certain there is a better way to do this!  :)  Maybe even maintain a shared list of members (updated whenever there is a view change) to test for responses from non-members, a counter, and assume that members don't respond to the same request more than once?
>>
>> Cheers
>> Manik
>> --
>> Manik Surtani
>> manik at jboss.org
>> twitter.com/maniksurtani
>>
>> Lead, Infinispan
>> http://www.infinispan.org
>
> --
> Bela Ban
> Lead JGroups (http://www.jgroups.org)
> JBoss / Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev