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

2008-01-07 Thread FredrikJ
Wow, that was fast =) The issue is indeed fixed for the standalone test case. We will probably wait for the CR3 release before we test with our real application. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4117525#4117525 Reply to the post :

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

2008-01-04 Thread FredrikJ
We do apply session affinity. Look at this way: 1. Cache A starts 2. Cache A adds 10 nodes to the cache 3. Cache B starts 4. Cache B 'gets' the 10 nodes thus causing a gravitation After #4 in the sequence we end up with the weird buddy rep settings as discussed above. This is exactly what

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

2008-01-04 Thread [EMAIL PROTECTED]
Sorry, I didn't quite understand your use case in the beginning. If you are adding data to .5 while at the same time reading the same data from the other nodes (causing data gravitation), this will naturally cause some timeouts since there is contention on a buddy backup subtree. In general

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

2008-01-04 Thread [EMAIL PROTECTED]
FredrikJ wrote : | But we also see the master having a buddy backup for itself (with no data): | | MASTER: | | null {} | | /_BUDDY_BACKUP_ {} | | /192.168.1.135_51469 {} | | /192.168.1.135_51470 {} | | /1 {1=c6m0p888dfvz} | | The backup

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

2008-01-04 Thread FredrikJ
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

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

2008-01-04 Thread [EMAIL PROTECTED]
This is a regression. Thanks for this - JBCACHE-1256 View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4117150#4117150 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4117150 ___

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

2008-01-04 Thread [EMAIL PROTECTED]
Hi - I have a fix in svn trunk if you feel like trying it out. Note that trunk is unstable and Hudson still hasn't finished thoroughly checking my fix for further regressions. Details are in JIRA. View the original post :

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

2008-01-03 Thread FredrikJ
I have now tried to reproduce the issue in a standalone unit test and have succeeded to at least some extent =) I am now running two caches locally where one is producing data and the other one is inspecting the cache - causing data to gravitate to the second cache. The issue is replicated in

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

2008-01-02 Thread [EMAIL PROTECTED]
FredrikJ wrote : I am currently using cache 2.1.0 GA I presume you mean 2.1.0.CR2. No such behaviour should have changed between 2.0.0 and 2.1.0. Some of the internal code has changed, but that is more along the lines of refactoring and performance enhancements, not logical behaviour in any

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

2008-01-02 Thread FredrikJ
2.1.0 CR2 is correct. We are not using anything extra apart from turning on buddy replication and using data gravitation. I tried to recreate it today as well in a separate unit-test but with no success so far. I will give it another shot tomorrow since I think the underlying use case scenario

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

2007-12-28 Thread FredrikJ
(Cont.) Further, we see that all locks that fail because a timeout is from .6, which do have .5 as its buddy backup. So, my question is if buddy replication has changed between 2.0.0 and 2.1.0? In any case the behavior is changed since this worked with 2.0.0 and not anymore. Why does the .5