Hi. I am currently using cache 2.1.0 GA and jgroups 2.6.1 with buddy replication. Buddy rep is configured to use one buddy only.
The setup is four nodes with ip addresses like: 172.16.0.5 | 172.16.0.6 | 172.16.0.7 | 172.16.0.8 | | They are all started in the stated order so that .5 is the coordinator. The first node up (.5) will insert data to the cache and then data will gravitate to the other nodes when needed. This will occur mostly initially when applying load to the system. Data affinity is handled by a layer above the cache. | | Using this scenario with 2.0.0 GA presented no problems except adding new nodes during load, so we are now investigating 2.1.0. | | The issue I'm facing is that the coordinator seems to get two buddy backups, one being itself. | | This is the contents on 172.16.0.5 (coordinator): | | | | null {} | | /91 [EMAIL PROTECTED] [EMAIL PROTECTED] | | /63 [EMAIL PROTECTED] [EMAIL PROTECTED] | | /92 [EMAIL PROTECTED] [EMAIL PROTECTED] | | ... | | | | /_BUDDY_BACKUP_ {} | | /172.16.0.8_8786 {} | | /15 [EMAIL PROTECTED] null} | | /16 [EMAIL PROTECTED] null} | | /172.16.0.5_8786 {} | | /31 {} | | Notice that there are two members listed under_BUDDY_BACKUP, one is .8 and the other one is .5, which is itself. | | Now, on 172.16.8 we get a lot of lock timeouts like the one below: | | Caused by: org.jboss.cache.lock.TimeoutException: read lock for /_BUDDY_BACKUP_/172.16.0.5_8786 could not be acquired by GlobalTransaction:<172.16.0.6:8786>:41 after 5000 ms. Locks: Read lock owners: [] | | Write lock owner: GlobalTransaction:<172.16.0.6:8786>:1 | | , lock info: write owner=GlobalTransaction:<172.16.0.6:8786>:1 (activeReaders=0, activeWriter=Thread[Incoming,TableSpace,172.16.0.8:8786,5,Thread Pools], waitingReaders=25, waitingWriters=0, waitingUpgrader=0) | | | | 172.16.0.8 also shows two members under the buddy backup: | | null {} | | /28 {} | | /29 {} | | /92 {} | | ... | | /_BUDDY_BACKUP_ {} | | /172.16.0.7_8786 {} | | /91 [EMAIL PROTECTED] null} | | /41 [EMAIL PROTECTED] null} | | /115 [EMAIL PROTECTED] null} | | ... | | /172.16.0.5_8786 {} | | /31 {} | | | | It seems like .8's buddy to backup is in fact .7. But we still hold some buddy ref to the .5 member as well. In fact, all the lock timeouts on .8 is related to to .5 buddy back fqn: | | failure acquiring lock: fqn=/_BUDDY_BACKUP_/172.16.0.5_8786 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115924#4115924 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115924 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user