[jboss-user] [JBoss Cache: Core Edition] - eviction, clustering without cacheloader
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, that is, it doesn't replicate the node removal. This will cause the replication nodes to not be synchronizing, which is fine since the value will be fetched again when get returns null. This is a problem for us. We don't have a backing CacheLoader, all of the state is in the Cache. We'd like the nodes to be evicted from all machines at the same time (it would be really nice if this were based on the last read time in any server in the cluster). As it is, it's going to be very random behavior - different servers have different times for their most recent read, so different servers are going to evict at different times. Suggestions? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4148384#4148384 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4148384 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache: Core Edition] - Re: eviction, clustering without cacheloader
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 server evicts too soon (due to node having been read on a different server recently), the ClusteredCacheLoader will get it from the other cache. When a node is evicted on all servers in the cluster, then it's when we really wanted to evict. Does that sound like it might work? Question about ClusteredCacheLoader, since I've never used it. If we've got 4 servers in the cluster, and a node has been evicted from 3 of them, are we okay? Does the ClusteredCacheLoader search all other servers in the cluster until it finds the node? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4148397#4148397 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4148397 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: locking CacheSPI
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 : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4135763 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - optionoverrides and DataVersion
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 documentation: E.g., to override the default node versioning used with optimistic locking: | | DataVersion v = new MyCustomDataVersion(); | cache.getInvocationContext().getOptionOverrides().setDataVersion(v); | Node ch = cache.getRoot().addChild(Fqn.fromString(/a/b/c)); | | This seems completely useless except for single-threaded applications. Am I wrong? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4134692#4134692 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4134692 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: optionoverrides and DataVersion
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 : http://www.jboss.com/index.html?module=bbop=viewtopicp=4134693#4134693 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4134693 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: optionoverrides and DataVersion
(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 : http://www.jboss.com/index.html?module=bbop=viewtopicp=4134695#4134695 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4134695 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - locking CacheSPI
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 object in the cache in the same node, or it may decide not to. It's important that a different thread doesn't change the object at that key in that node in between the read and the write. Locking behavior is what we want - the other thread should wait until the first thread is done before writing. Sounds like we want to get a read lock for the read, and then promote it to a write lock for the write. However, if there are other suggestions on how to do this, I'm all ears. So the problems: - the decision on whether to write is application logic. The object stored is an application object. I really don't think that extending the PessimisticLockInterceptor is the right way to do this, because of the application logic that goes on in between the read and the write. - There's no accepted way for the application sitting on top of JbossCache to get a CacheSPI object (and thus be able to acquire its own locks). - If I were to get a CacheSPI object, what do I have to do to ensure that the object that I use to lock the node is the same object that the PessimisticLockInterceptor uses to lock it (so that it can acquire the lock when I actually do the write)? Ideas? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4133007#4133007 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4133007 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: CacheLoaderInterceptor behavior
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 original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4121388#4121388 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4121388 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - CacheLoaderInterceptor behavior
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 get it). What the CacheLoaderInterceptor is doing that we don't want it to do is that when we put an object into a cache and that node doesn't exist in the local cache, it goes to CacheLoader to get that node before proceeding with the put. I understand the thought process behind this - if the CacheLoader is being used as a backing store, then you want to get the node back into memory before adding another key/value pair. However, we're not using it this way. I won't get into the details on why, but what we'd like is to have the CacheLoader get only be invoked on an explicit get, and never on a put. Functionally, this won't make a difference, but there will be a performance difference. Any suggestions on how this can be accomplished? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4120669#4120669 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4120669 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Interception of cache lookup calls
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 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: ClusteredCacheLoader + LOCAL CacheMode
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 nodes, it will replicate the entry straight away into the cache loader(I assume,i havent played with it yet,maybe you can turn this off). I only want to replicate data on demand, i.e if someone asks for data on a node and it aint there, ask the others in the cluster first if they have,if not then got to source. if i add an entry in a node i dont want to push it somewhere else, it just sits on that node until someone else asks for it. | I believe that CacheLoaders can be configured with: | !-- determines whether this cache loader ignores writes - defaults to false. -- | ignoreModificationstrue/ignoreModifications | in order to have the CacheLoader read-only. I haven't actually tried that behavior, so I can't be sure that I'm interpreting it correctly. Maybe one of the jbosscache guys can configrm. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4111005#4111005 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4111005 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: ClusteredCacheLoader + LOCAL CacheMode
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 : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4109427 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: LRU policy for separated object
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 : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4108240 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: FetchInMemoryState + jgroups config
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 : http://www.jboss.com/index.html?module=bbop=viewtopicp=4091207#4091207 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4091207 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: FetchInMemoryState + jgroups config
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 jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - FetchInMemoryState + jgroups config
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 | ip_ttl=64 ip_mcast=true | mcast_send_buf_size=15 mcast_recv_buf_size=8 | ucast_send_buf_size=15 ucast_recv_buf_size=8 | loopback=false/ | PING timeout=1 num_initial_members=3/ | MERGE2 min_interval=1000 max_interval=2000/ | FD shun=true/ | FD_SOCK/ | VERIFY_SUSPECT timeout=1500 | up_thread=false down_thread=false/ | pbcast.NAKACK gc_lag=50 retransmit_timeout=600,1200,2400,4800 | max_xmit_size=8192/ | UNICAST timeout=600,1200,2400/ | pbcast.STABLE desired_avg_gossip=40/ | pbcast.GMS join_timeout=5000 join_retry_timeout=2 | shun=true print_local_addr=true leave_timeout=3000/ | FC max_credits=200 | min_threshold=0.20/ | FRAG2 frag_size=8192/ | pbcast.STREAMING_STATE_TRANSFER/ | /config | /attribute | attribute name=FetchInMemoryStatetrue/attribute | attribute name=StateRetrievalTimeout6/attribute | What I get in the log indicates that JGroups is timing out before it can join the group (related log messages shown. IP of machine joining is 1.1.1.1. IP of machine already up is 9.9.9.9): | 2007-09-12 14:26:51,443 DEBUG [org.jboss.cache.CacheImpl.MyCluster] (main) cache mode is REPL_ASYNC | 2007-09-12 14:26:51,453 INFO [org.jgroups.JChannel] (main) JGroups version: 2.5.0 | 2007-09-12 14:27:01,691 INFO [org.jboss.cache.CacheImpl.MyCluster] (main) viewAccepted(): [1.1.1.1:32774|0] [1.1.1.1:32774] | 2007-09-12 14:27:01,709 INFO [org.jboss.cache.CacheImpl.MyCluster] (main) CacheImpl local address is 1.1.1.1:32774 | 2007-09-12 14:27:01,709 DEBUG [org.jboss.cache.CacheImpl.MyCluster] (main) State could not be retrieved (we are the first member in group) | 2007-09-12 14:27:01,710 INFO [org.jboss.cache.CacheImpl.MyCluster] (main) JBoss Cache version: JBossCache 'Habanero' 2.0.0.GA[ $Id: Version.java,v 1.35 2007/08/01 16:52:13 msurtani Exp $] | 2007-09-12 14:27:03,046 INFO [org.jboss.cache.CacheImpl.MyCluster] (Incoming Thread,MyCluster,1.1.1.1:32774) viewAccepted(): MergeView::[9.9.9.9:32781|19] [9.9.9.9:32781, 1.1.1.1:32774], subgroups=[[9.9.9.9:32781|18] [9.9.9.9:32781], [1.1.1.1:32774|0] [1.1.1.1:32774]] | So I should increease the ping timeout, right? Probably only need a few seconds, since the other server's group was merged with this one only 2 seconds after this JGroups declared that it couldn't find the other one. So I changed the timeout for PING to 20 (200 seconds, much longer). However, this is the result: | 2007-09-12 14:18:41,098 DEBUG [org.jboss.cache.CacheImpl.MyCluster] (main) cache mode is REPL_ASYNC | 2007-09-12 14:18:41,108 INFO [org.jgroups.JChannel] (main) JGroups version: 2.5.0 | 2007-09-12 14:22:01,344 INFO [org.jboss.cache.CacheImpl.MyCluster] (main) viewAccepted(): [1.1.1.1:32773|0] [1.1.1.1:32773] | 2007-09-12 14:22:01,362 INFO [org.jboss.cache.CacheImpl.MyCluster] (main) CacheImpl local address is 1.1.1.1:32773 | 2007-09-12 14:22:01,362 DEBUG [org.jboss.cache.CacheImpl.MyCluster] (main) State could not be retrieved (we are the first member in group) | 2007-09-12 14:22:01,363 INFO [org.jboss.cache.CacheImpl.MyCluster] (main) JBoss Cache version: JBossCache 'Habanero' 2.0.0.GA[ $Id: Version.java,v 1.35 2007/08/01 16:52:13 msurtani Exp $] | 2007-09-12 14:22:04,245 WARN [org.jgroups.protocols.pbcast.NAKACK] (Incoming Thread,MyCluster,1.1.1.1:32773) 1.1.1.1:32773] discarded message from non-member 9.9.9.9:32781, my view is [10.195.70.107:32773|0] [1.1.1.1:32773] | 2007-09-12 14:22:04,246 WARN [org.jgroups.protocols.pbcast.NAKACK] (Incoming Thread,MyCluster,10.195.70.107:32773) 1.1.1.1:32773] discarded message from non-member 9.9.9.9:32781, my view is [1.1.1.1:32773|0] [1.1.1.1:32773] | 2007-09-12 14:22:04,248 INFO [org.jboss.cache.CacheImpl.MyCluster] (Incoming Thread,MyCluster,1.1.1.1:32773) viewAccepted(): MergeView::[9.9.9.9:32781|17] [9.9.9.9:32781, 1.1.1.1:32773], subgroups=[[9.9.9.9:32781|16] [9.9.9.9:32781], [1.1.1.1:32773|0] [1.1.1.1:32773]] | | What happens is that after the 200 seconds expire, JGroups decides that it's alone, no state transfer happens, and then 4 seconds later, JGroups decides that the other server exists. Too late for state transfer. Am I misconfiguring something? Misunderstanding something? View the original post :
[jboss-user] [JBossCache] - Re: Is there a way to view evictions from the cache without
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 : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4083162 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Overflow berfore OutOfMemory
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 policy that evicts when a certain memory threshold is reached, or a MRU eviction policy that evicts when a certain memory threshold is reached, etc - without having to code a completely separate eviction policy for each. Because all of the existing eviction policies assume that maxNodes is how to decide when to evict, it's hard/impossible to put a memory threshold into an eviction policy without also having to code the details of LRU/FIFO/MRU/etc. I'm not really expecting anything to be magically done about this :-) , but I'd like to see if you disagree with me or have any good ideas about an approach for this (that doesn't involve wholesale changes in the org.jboss.cache.eviction package) that's a bit more flexible than subclassing LRUAlgorithm to make a LRUMemoryAwareAlgorithm, subclassing MRUAlgorithm to make MRUMemoryAwareAlgorithm, etc (which wouldn't be hard, but would be less than ideal from a code maintenance standpoint). View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4064763#4064763 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4064763 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - how much memory overhead per node?
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 : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4061460 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Overflow berfore OutOfMemory
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 : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4061469 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: 2.0 and JMX
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 be able to use jconsole to check the state of jbosscache 2.0 in a standalone app Particularly, in the code snippets in the thread, I don't know how to get the mbean server or what the monitor name should be (I've figured out that there's an MBeanServerFactory and I can create or get an mbean server from that, I'm not sure whether I should create one or get one, and how the names relate). Thanks. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4060856#4060856 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4060856 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: 2.0 and JMX
To answer my own question, this seems to work:
_cache = createCache();
| ArrayList mbServers = MBeanServerFactory.findMBeanServer( null
);
| if (mbServers.size() 0)
| {
| MBeanServer mbs = (MBeanServer) mbServers.get( 0 );
| mbs.registerMBean( new
org.jboss.cache.jmx.CacheJmxWrapper( _cache ),
| new ObjectName(
JmxUtil.getDefaultCacheObjectName( _cache ) ) );
| }
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4060894#4060894
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4060894
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - jbosscache MBeans not appearing in jconsole
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 configuring the mbeans to be jmx visible What do I have to do to view them? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4060105#4060105 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4060105 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: jbosscache MBeans not appearing in jconsole
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 jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
