[jboss-user] [JBossCache] - Re: Buddyrep issue

FredrikJ do-not-reply at jboss.com
Fri Jan 4 11:39:50 EST 2008


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



More information about the jboss-user mailing list