On 12/5/12 1:23 PM, Sanne Grinovero wrote: > On 5 December 2012 11:02, Galder Zamarreño <[email protected]> wrote: >> On Dec 4, 2012, at 10:22 AM, Sanne Grinovero <[email protected]> wrote: >> >>> On 4 December 2012 09:14, Galder Zamarreño <[email protected]> wrote: >>>> Hey Dan/Adrian, >>>> >>>> Re: https://issues.jboss.org/browse/ISPN-2541 >>>> >>>> I'm looking at this intermittent failure, and it seems to be caused by the >>>> fact that the test does not wait for the cluster to be formed when the new >>>> node is started, which can lead a replication timeout failure from the new >>>> joining node. >>>> >>>> The test can easily be fixed by waiting for cluster to form, and then do >>>> the call. >>>> >>> [...] >>> >>> I don't think the cache should ever be in an illegal state to be used >>> after being started. So Infinispan should not require tests to wait >>> for a "cluster to be formed", I'd rather guarantee that after a cache >>> is started it's usable. >> Precisely, which is why I raised the flag instead of going down the easy >> path. >> >>> If this is not possible, then any application would also need to wait >>> for that "cluster formed" event, and we should expose an API for that. >> The problem is considering when a cluster is formed. How many nodes should >> you wait for? >> > Why can't we rely on JGroups Discovery to know that, as a user I > already specified the expected initial group size with > num_initial_members > Don't want to repeat that configuration ;-)
I don't understand this discussion: when a new node join, it'll return from JChannel.connect() when it received a JOIN response from the coordinator, with the current view... or are you guys talking about Infinispan's 'service views' ? -- Bela Ban, JGroups lead (http://www.jgroups.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
