[infinispan-dev] IgnoreExtraResponsesValidityFilter

[Sanne Grinovero]

JDK's BitSet is not, but there is an implementation in some Apache
licensed project.

On 14 January 2012 20:13, Manik Surtani <manik at jboss.org> wrote:
> 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
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev