Just an update
Other option Im looking at is the JGroups getState and setState as a way to
transfer a branch.
Im as far as trying to stream a node, but "Node" is not serializable, so have
started to look at the org.jboss.cache.statetransfer.StateTransferManager and
how that does it.
View the
The STM uses a NodeData object, which is Externalizable.
What you may want to do is to use Regions for each feed, so that each region
can be activated/deactivated independent of one another. Each region
activation will cause a state transfer for that region.
View the original post :
http://ww
Ok i have got it to work through getState and setState, however I would nearly
call it a hack version but it works. I have tried to re-use what is already in
JBoss Cache to do the state transfer, now whether it is a good idea or not to
reuse im not sure. How often does this area change?? Would I
Thanks for pointing this out. I am waiting for 2.6.7 before I cut JBC 3.0.0.GA.
Cheers
Manik
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189113#4189113
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189113
You say this is still a problem with higher timeout values? I'm guessing you
have edited the sources to set this to the same value as LockAcquisitionTimeout
?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153949#4153949
Reply to the post :
http://www.jbos
Indeed.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153963#4153963
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153963
___
jboss-user mailing list
jboss-user@lists.jboss.
And what probs do you see when you use sync commit and rollback?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153969#4153969
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153969
__
Oh, and: This was with JBoss Cache 2.1.1.GA on an Intel dual core/Linux 2.6.22.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4149683#4149683
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4149683
___
Will have a look and report back
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4149701#4149701
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4149701
___
jboss-user mailing lis
BTW, I really appreciate the tests that you send to try and reproduce these
issues, but in future could I ask you to check out the JBC srcs, and write your
test as a TestNG unit test so I could just drop it in to the src tree and run
it/analyse it rather than rewriting it first?
I know this i
Well That could... possibly work. After all, I doubt setting up TestNG
will take a significant amount of time for us comparing to write the damn stuff
in the first place :-)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4149741#4149741
Reply to the p
There's not much setup involved - just chk out the JBC sources and you should
be able to run the existing tests in your IDE (IntelliJ supports TestNG out of
the box; Eclipse may need a separate plugin).
If you can run existing tests from your IDE, all you'll need thereafter is to
create a new
Sorry, no - I've been tied down with 2.2.0.CR1 release work. This should be
released today.
Do you see the problem with 2.2.0.Beta1 or a snapshot from SVN, by the way?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151745#4151745
Reply to the post :
http:
Did you ever find something out regarding this?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151744#4151744
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151744
___
jboss-u
I've testng'd this now.
Here: http://www.cubeia.com/misc/statetransfer/src2.zip
This uses the available buddy replication config in the test resources, so it
tests REPL_SYNC with buddy replication with and without user transactions.
I can also confirm that it fails on all JBC versions I have av
Sorry for being so slow with this.
I don't see a problem here. Yes, your test fails, but that is due to a few
minor issues.
1. Make sure you have the following enabled in your buddy replication config:
| true
|
2. After starting cache2, the BR organisation code takes a short whil
Hum... You'll pardon me for thinking that that listener/latch solution feels a
bit like black magic eh? :-)
But if it works I won't beat it.
However, it doesn't seem to work for me. Without transactions we're still
failing 15-20% of all runs (I increased repetitions to 5 or 10 to check this)
w
No black magic at all - just a simple callback to tell you once a buddy has
fully joined a buddy group. :-)
Regarding your exceptions, they look like standard lock acquisition timeouts.
Your access pattern is very write-heavy. Write-heavy patterns will always have
a lot of contention on writ
Mmm. A few questions.
1) The lock contention occurs on data gravitation only, correct? As we're only
updating attributes on nodes, the only time we need to content on lock (the "/"
lock, or the buddy backup lock) is when adding something on a cache, ie. on
data gravitation?
2) If #1, is there
No, in different places, not just gravitation.
the first stack trace shows contention during a state transfer for the new
buddy. There is stuff being written to cache1 while cache1 is trying to get
state to send to cache2. And there is contention here. Perhaps increasing
your lock acquisitio
The first timeout is not configurable (at least not in JBC 2.2.0.BETA1). It is
hard coded to a sequence of 400, 800, and 1600 milliseconds in
BuddyManager.java:859 (again in JBC 2.2.0.BETA1).
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152681#4152681
Rep
Wow, that's not nice.
JBCACHE-1353. Thx for spotting this.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152690#4152690
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152690
Setting higher timeout values in the sequence does not help. Also synchronous
commit and rollbacks only brought other exceptions.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152736#4152736
Reply to the post :
http://www.jboss.com/index.html?module=bb&o
What I fail to understand is where the lock contention comes from. Given that
each thread access separate nodes and mutate only attributes, why is there a
contention on state transfer?
Ie. given thread T1 accessing node N1, state transfer for N1 should not
commence unless T1 accesses the data o
24 matches
Mail list logo
