[infinispan-dev] State transfer testing

Galder Zamarreño galder at redhat.com
Tue Jul 19 09:54:04 EDT 2011


On Jul 19, 2011, at 3:19 PM, Vladimir Blagojevic wrote:

> On 11-07-19 4:38 AM, Galder Zamarreño wrote:
>> Btw, you might be wondering how on earth a merge would happen with our new TEST_PING? I have that question too and seems like sometimes Discovery.sendGetMembersRequest does not get called and my TEST_PING implementation assumes that will definitely get called. I've sent an email to Bela and I'm gonna try to add some more debugging to find out how on earth this happens.
> 
> 
> I saw your emails. Keep us posted please. It might be a bug during channel startup?

Ever since I fixed the StateTransferFunctionalTest as mentioned earlier, I haven't been able to replicate it. So, I'm heading down to master to try there with the added log messages in Discovery.

Judging by the fact that the wait happens, I reckon that this condition returns false in Discovery:

if(senderFuture == null || senderFuture.isDone())

The only way I can see this happening is if two channels are sharing the same Discovery/TEST_PING instance.

I'll keep running the test to see if I can get it to show this behaviour, but it's quite hard.

> 
>> Now, what I'm wondering here is whether this is something the end users would be interested as well cos they might be running their own testing to check whether state transfer works as expected.
>> 
>> It's at this point that I miss tuples in java cos I think it'd be handy to have a getMembers() call that returns not only a List<Address>  but also an enum value indicating whether the last view change was a merge or view change, or more simply a boolean indicating whether the last view change was a merge or not:
>> 
>> (boolean, List<Members>) getMembers();
>> 
>> Unfortunately Java does not make it easy to return things like this. Having a separate method to find out if the last view change was a merge or not would be clunky cos you'd want a single method that can provide the guarantees with regards to the member list returned.
>> 
>> Any thoughts on this API enhancement? Would it be useful? In the Java world, it would require creating a new type which is a bit of a deterrent for me.
> 
> This could be added into a View I suppose, but that does not help you :-)

Yeah, doesn't help cos we can already figure that out as seen in JGroupsTransport.viewAccepted class.

> 
> Regards,
> Vladimir

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache




More information about the infinispan-dev mailing list