I tried a snapshot build from SVN (revision 4982) but the result is still the 
same .

Actually I was not entirely accurate in the sequence description. It should be 
like this:

 1. Cache A starts
 2. Cache A adds 10 nodes to the cache
 3. Cache B starts
 4. Cache B 'gets' 9 nodes thus causing a gravitation 

I'm not sure why I decided to gravitate 9/10 nodes, but there it is. I have 
modified a producer log to include the sequence numbers so you can follow the 
sequences in the log better. You can find a log containing the sequences here: 
http://www.robotsociety.com/cache/br/producer_seq.log

You can see a comparison between running the provided test for 2.0.0 GA and 
2.1.0 CR2 here:
2.0.0 GA producer log : 
http://www.robotsociety.com/cache/br/2.0.0/producer_2.0.0.log
2.1.0 CR2 producer log : 
http://www.robotsociety.com/cache/br/2.1.0%20CR2/producer_2.1.0_cr2.log

To sum the comparison up, the 2.0.0 GA and 2.1.0 CR2 are equal until data has 
gravitated. Then we can see that for 2.0.0 GA the cache in the producer looks 
like:

2.0.0 GA:
  | null  {}
  |   /9  {4=85969gehp9xt}
  |   /_BUDDY_BACKUP_  {}
  |     /192.168.1.135_51890  {}
  |       /3  {4=xapfkubptgx0}
  |       /5  {2=17z0dcpunsivo}
  |       /7  {2=1kr0r0fpucxmy}
  |       /2  {1=1cdp3dootdbu9}
  |       /0  {0=cvwo5pn5r7ou}
  |       /4  {4=1wzvk2sq01r1p}
  |       /8  {0=1vfthyv0lbkvw}
  |       /6  {2=i5az9hje5gxo}
  |       /1  {0=10eaf93uzvsru}

And for 2.1.0 CR2:

2.1.0 CR2:
  | null  {}
  |   /9  {0=13gmz9ol9twc}
  |   /_BUDDY_BACKUP_  {}
  |     /192.168.1.135_51892  {}      
  |       /3  {1=kf0p8vtuad5y}
  |       /5  {4=uvykukzoi2h0}
  |       /7  {1=zaouao7ntsy7}
  |       /2  {0=ib5tifo2tqco}
  |       /0  {4=1d1boyx12sha7}
  |       /4  {2=gyxlbtnjgpc}
  |       /8  {3=1ivb35jlxspf2}
  |       /6  {0=pte5ws2mpe11}
  |       /1  {1=1erqp88pgexrv}
  |     /192.168.1.135_51891  {}     // <--- wtf?

As I stated before in my first slightly confusing post, it is not the fact that 
we get an additional (recursive) buddy node in the cache that is the 
dealbreaker for us. But I strongly believe that this is one of, if not the, 
cause for the lock timeouts we see. Remember that for 2.0.0 GA buddy rep works 
like a charm for us, but with 2.1.0 CR2 it is broken. Given that and the fact 
that the caches are in different states after a gravitation has occurred using 
the simple test code provided, indicates to me that something has changed 
and/or a regression has occurred.

View the original post : 
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117127#4117127

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117127
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to