Sorry Bela,
It is working as U said ... I had a wrong network configuration ...
Thanks
Sebi
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3848424#3848424
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3848424
If you use FD.shun=true and GMS.shun=true, then the following will happen:
- C is disconnected
- C will form a view {C}
- A and B will form a view {A,B}
- When you reconnect, both partitions will shun each other, causing them to leave and
rejoin. There is *never* a merge going on !
When you
Hi Bela,
Thanks for the answer, but i still have some problems :((..
Node C is the coordinator.
If I remove B when I reconnect back B I have the following situation:
- node A and B received a merge view with members A, B
- node C is declared as suspect and does not receive any view ...
I put it
You have to use the exact same config for A, B and C.
I don't understand the rest of your post...
Bela
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3848310#3848310
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3848310
Im using exactlly the same cluster configuration for all the nodes but I still have
the problem:
Consider the following:
- node A is the coordinator of the clustered cache
- there are also node B and C on the cluster
- the node B is disconnected for a while
- I reconnect it back
- I receive
If LOCAL is not what you want, and you want cache partitioning, we don't have this
feature yet. It's on the todo list.
-Ben
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3847748#3847748
Reply to the post :
Since the cache has started on Machine B already, it won't initiate another state
transfer from other members when re-joining the group since it can be expensive
operation. If you stop and start the cache on Machine B (say, from JMX console via
MBean service), then it should sync up.
But I
Hi,
thanks for your answer. It would be nice to have such an option. Because otherwise
we're getting problems with data inconsistency.
To do a workaround with stopping and starting the cache in such cases automatically,
we first should know when a machine has no connection to the cluster
What you essentially want is a state-merge function after e.g. a network partition.
This is actually on the roadmap, but it involves asking you (the application) how to
merge 2 (potentially) different substates back into one. We *cannot* just take the
union of the 2 substates, because an
No, it does not yet. I'm working on the CacheLoader (see org.jboss.cache.loader.*
package), but it is not yet finished.
CacheLoader will be part of the 1.1 release.
Bela
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3829206#3829206
Reply to the post :
Bela,
Thank you for the quick reply. The cache persistence on disk is very important for a
real production application. I'm currently using OScache in my production env with
about 2m hits a day. It would be interesting to see how fast the JBossCache performs
as a distributed cache, but I
frank3wang wrote :
|
| 1) Do u know the rough time frame for the version 1.1 JBossCache with disk
persistence?
|
Depends on my (and Ben's) work load. I would like to release 1.1 before JavaOne (end
of June).
anonymous wrote :
| 2) What about the JSR 107 JCache API? eg. CacheAcess
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3821224#3821224
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3821224
Right,
we need the notion of regions. Do you have cycles to code this?
13 matches
Mail list logo
