[infinispan-dev] Possible Bug in Distribution Manager

[Dan Berindei]

Hi Pedro,

>From your logs it looks like the CH function has duplicate addresses
in it and that's what's causing some nodes to return the same owner
twice:

12:04:03,505 TRACE [DistributionManagerImpl] New CH is
DefaultConsistentHash{addresses ={73=node09-42492, 848=node02-34421,
1849=node03-61513, 1850=node03-61513, 2093=node10-3814,
2094=node10-3814, 2380=node08-968, 2381=node08-968, 3182=node04-53049,
3183=node04-53049, *5868=node07-42120, 5869=node07-42120,*
5914=node05-23599, 5915=node05-23599, 6410=node01-27066,
6978=node06-24999, 8485=node11-42115, 8486=node11-42115}, hash space
=10240}

How old is your snapshot? Since 5.0.0.ALPHA4 the CH interface uses
Set<Address>, so duplicates should never happen. I think it would be
better to use the latest CR release instead, 5.0.0.CR3, so you (and
us) know exactly what code you're using.

Cheers
Dan


I think my changes for ISPN-110
On Wed, Jun 1, 2011 at 7:49 PM, Pedro Ruivo <pruivo at gsd.inesc-id.pt> wrote:
> Hi,
>
> My name is Pedro and I am working in CloudTM project.
>
> I think that I may have encountered a possible bug in the consistent
> hash function.
>
> I am working on Infinispan 'Pagoa' 5.0.0-SNAPSHOT with JGroups 3.0.0
> Alpha1 and I have a total of 100 000 keys distributed by 11 nodes.
>
> I am using Radargun, that was modified to execute the maximum number of
> transactions in a 5 minutes run. All transactions updates at least one
> key, ie, I didn't have read-only transactions.
>
> At the end of the test,  I am printing all the keys and their location
> (keys' owners), and, as you can see for instance here [1], different
> nodes have different opinions concerning which replicas are in charge of
> storing some keys.
>
> Note that I didn't change anything in the distribution code and my tests
> only update keys, never delete them.
>
> Part of the log can be found in [2] and the config file is in [3]. In
> the log file we have a lot of 'WARN  [DistLockingInterceptor] xxx entry
> commit warmup_key(...) =>  Thread(...)'. Ignore this entries.
>
> Unfortunately, the problem does not always show up, in my tests this
> shows up, say, 5% of the times.
>
> Did this ever happen to you, or am I hitting a known issue?
>
> I hope that the information that I am providing can be sufficient to
> reproduce the bug, let me know if there is anything else that I can do
> to help....
>
> Cheers
> Pedro
>
> [1] - http://pastebin.com/Pp47ctj9
> [2] - http://pastebin.com/tpSXqVmV
> [3] - http://pastebin.com/vjVP48L2
>
> --
> INESC-ID Lisboa, sala 511
> gsd.inesc-id.pt/~pruivo
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>