[infinispan-dev] IgnoreExtraResponsesValidityFilter

[Manik Surtani]

A BitSet ought to be thread safe too, right?  Otherwise doing bit masks manually and then a compare-and-set on a long field to hold the final value would make it thread safe. :)

On 14 Jan 2012, at 18:08, Dan Berindei wrote:

> 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
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org