It seems to me that you've got a bug with the way that you treat evictions -
data integrity is only maintained if there's a CacheLoader backing the cache.
I say this, because the javadoc on CacheImpl.evict(Fqn) method (2.0.0, at any
rate) includes: Note that eviction is done only in local mode,
Hmmm. Probably won't quite work for us - we need the timeToLiveSeconds
behavior in LRU policy. To mimic that, we'd need to set a new ExpirationPolicy
time on every get, which would kill performance (due to replication).
One thing that I'm thinking is adding a ClusteredCacheLoader. So if one
Right, that's what I would like to do. But how do I do that from application
code without having my app code operate in an Interceptor? Am I missing
something easy?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4135763#4135763
Reply to the post :
It's possible that optimistic locking and using OptionOverrides to tweak
optimistic locking to do some things that we want to do. However, it seems
like the fact that the way that the DataVersion is set for an attribute (using
global OptionOverrides) is not thread safe at all. From the
Hmmm. Maybe I am wrong. Let me rephrase it:
Does getInvocationContext() return a different object per thread? Is that what
makes it so that two different threads doing this at the same time don't step
on each others' toes?
View the original post :
(slaps self on head). I looked at the code, and see that InvocationContext is
ThreadLocal. So anybody, can I just have confirmation that using
OptionOverrides to set data version for optimistic locking is thread-safe? :-P
View the original post :
We have a need (we think - unless somebody has a better suggestion) to try to
do lock nodes in some situations.
When our application decides to write to the cache, it needs to check what's
already at the node that's there, and then depending on what it finds, it may
choose to put the new
Hmmm. Interesting. I see the general idea of what you're doing. We'll take a
look at adding that functionality for synchronous gets. We also may end up
declaring that the performance penalty for our expected use case is small
enough that we'll live with it as it is. Thanks.
View the
We're using a custom CacheLoader in a somewhat non-standard way. Our
CacheLoader is read-only, and it's designed to get a node from a different
server if not on the current server (the difference between it and the
TcpDelegatingCacheLoader is that this cacheloader figures out where to go and
JbossCache contains this functionality - look at CacheLoaders (specifically,
JDBCCacheLoader).
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4116545#4116545
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4116545
lovelyliatroim wrote :
| anonymous wrote :
| | From your description, it sounds like you might want to use LOCAL cache
mode and a TCPCacheLoader. Have you looked into that?
| |
|
| I have read about it but the thing that i dont want is that when you add an
entry into one of the
From your description, it sounds like you might want to use LOCAL cache mode
and a TCPCacheLoader. Have you looked into that?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4109427#4109427
Reply to the post :
It sounds like you're putting both a and b under different keys in the same
node. Have you tried putting a and b in different nodes?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4108240#4108240
Reply to the post :
They do. It does, however, seem to be a multicast-related problem with one of
our boxes. When the other server comes up first, things work fine, and when we
use a TCP configuration, everything's fine.
So probably not a problem with JGroups or JBossCache. Thanks.
View the original post :
64-bit Ubuntu linux.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4084096#4084096
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4084096
___
jboss-user mailing list
I'm having trouble getting things configured properly to get the state
transferred to a new server joining a cluster (jbosscache 2.0.0GA). Relevant
config:
| attribute name=ClusterConfig
| config
| UDP mcast_addr=228.1.2.3 mcast_port=48866
|
You could use JMX. The jbosscache documentation tells you how enable JMX.
Depending on what your needs are, you could then use jconsole to view evictions.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4083162#4083162
Reply to the post :
What would be really nice to be able to do is to be able to separate the
questions of: Do I need to evict? and What should I evict? into different
responsibilities So that you could have an LRU eviction policy that evicts
when a certain memory threshold is reached, or a FIFO eviction
Has anybody done some analysis or profiling to determine what the memory
overhead for TreeCache is per node?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4061460#4061460
Reply to the post :
Has anybody done this (eviction policy based on consumed memory) yet (now 7
months after the initial conversation)?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4061469#4061469
Reply to the post :
A couple of things:
It would be a good idea if this were documented. The 2.0 documentation still
implies that no registration is necessary for JMX.
Second, anybody have quick hints (or links) for a JMX newbie? I'm not really
interested in learning so much about it right now - I just want to
To answer my own question, this seems to work:
_cache = createCache();
| ArrayList mbServers = MBeanServerFactory.findMBeanServer( null
);
| if (mbServers.size() 0)
| {
| MBeanServer mbs = (MBeanServer)
We're using jbosscache in a standalone application. Starting the application
with jmxremote turned on, I can connect to the application. The list of
MBeans, however, doesn't include jboss.cache, so the JBossCache mbeans aren't
visible.
I really don't see much in the documentation about
Sorry - 2.0 release candidate.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4060125#4060125
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4060125
___
jboss-user mailing list
24 matches
Mail list logo
