kringdahl wrote : Just to loop back on my efforts to integrate JBoss Cache
2.1.1.GA with AS 4.2.2.GA. I have this mostly working. It required upgrading
the AOP deployer in the AS to JBoss AOP 2.0.0 (I used CR8) and also using the
new pluggable-instrumentor.jar as the javaagent.
Great.
Just to loop back on my efforts to integrate JBoss Cache 2.1.1.GA with AS
4.2.2.GA. I have this mostly working. It required upgrading the AOP deployer
in the AS to JBoss AOP 2.0.0 (I used CR8) and also using the new
pluggable-instrumentor.jar as the javaagent. JBoss Cache 2.1.1.GA appears to
I'm pretty sure that upgrading to JBC 2.1.0 GA and JGroups 2.6.2 did resolve
the not in started state errors for us. Unfortunately we ran into other
issues when using sync replication on versions 2.0.0 so we're still running
2.0.0.
View the original post :
What other issues are these? Have you brought these up on the forums or raised
JIRAs?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4157689#4157689
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4157689
Posted here: http://www.jboss.com/index.html?module=bbop=viewtopict=135172
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4157799#4157799
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4157799
No - definitely something to look into. Weird though, since preloading takes
place *before* the cache enters it's STARTED state, i.e., between STARTING and
STARTED.
That said, there were a few obscure lifecycle issues in 2.0.0 which were fixed
in 2.1.X so I'd recommend trying out 2.1.1.GA.
Yeah, the only challenge with moving to 2.1 or 2.2 is that we're running AS
4.2.2 which uses JBoss AOP 1.5. I was trying to avoid having to deal with
custom class loading due to the dependence on AOP 2.0
View the original post :
So I'm guessing you are using POJO Cache?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4156988#4156988
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4156988
___
jboss-user
Yes that's right, we are using Pojo Cache
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4156990#4156990
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4156990
___
jboss-user
OK, so we're actually configured to not pass state at startup. The behavior I
am seeing is that a new JBC instance comes online while a write is happening
and before it has completely joined the cluster, so the write fails. But, it
seems this locks up the entire cluster on a permanent basis
Not sure if I quite understand what you mean when you say locks up the cluster
on a permanent basis. Surely after the node completely joins the cluster,
these exceptions stop?
Is this using invalidation as well?
View the original post :
What I mean is that we use total sync replication and until this node leaves
the cluster, the other cluster nodes time out trying to replicate to it. I'd
be happy to supply you the logs from the cluster nodes that show this. We are
not currently using invalidation.
View the original post :
And you are not fetching in memory state on startup? Odd, there should be no
reason for it to lock the cluster up. A few replication events may fail due to
timing issues, but what is it that prevents it from starting up then? If you
can consistently recreate this, do you have a unit test for
That's right, we are not doing a state txfr. I don't have a unit test, though
I suppose I could write one...it might take a few days to find the cycles. A
thread dump would certainly be easier to get immediately. Should I send those
to you? You want a thread dump from just the new cluster
From the new node that refuses to get out of the STARTED state.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4156772#4156772
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4156772
Sorry, not-STARTED state. It's been a long day. :)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4156773#4156773
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4156773
___
OK, I'll get that thread dump. But, he does get out of the STARTED state.
It's just the other guys can't replicate to him.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4156775#4156775
Reply to the post :
Even after that? Weird. What do the stack traces look like on the sender then?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4156777#4156777
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4156777
So, the cache on the new node does end up in a failed state, but to make
matters worse it stills tries to preload the cache from the CacheLoader. I
would have expected the preloading to not take place if the cache failed to
start. In my case, the preload can take on the order of 10-30 minutes
Our workaround consisted of 'stopping the world', i.e. halt everything in the
system while the new node is connecting and transferring state data. Then start
execution again when we can guarantee that the JBC has stabilized.
Unfortunately we have still not been able to have a jboss cache node
We are using 2.0.0.GA and seeing the same problem. What is the workaround for
this? Is this fixed in a future release? Thanks
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4156101#4156101
Reply to the post :
21 matches
Mail list logo
