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 b...@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
ma...@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
