Re: Clustering w/ distributed cache
On Mon, Feb 16, 2009 at 9:02 PM, defeng defeng...@gmail.com wrote: I am using Jackrabbit 1.4.4 clustering. DB for persistent manager, and NFS for datastore. Everything works well, but since the Jackrabbit uses a Cluster-wide lock, many times, other JCR clients need to wait for a long time to acquire the Global lock. To solve this issue, I want to use a distributed cache(memcached) in SharedISM. To disable cache in SessionISM and LocalISM (I did not use XA ). So there is no necessary to sync any data in cache. In addition, I donot need to register Namespace or Nodetype at runtime. The only thing is to sync local search index in the Looping of ClusterNode. (I did not use AccessManager in Jackrabbit) When updating an item, a distributed lock is acquired. It is used to ensure the data consistence between persisten manager and distributed cache (2-phase commit). Is the proposal feasible? Any comment is highly appreciated! i don't think that this would work without a major redesign of jackrabbit's core architecture. SharedISM caches ItemState instances read from the PM. this memory-sensitive cache, apart from helping to reduce PM calls, guarantees that there's only *one* ItemState instance for any given id on this layer. similarly, 'caches' in SessionISM and LocalISM are crucial for jackrabbit's support of isolation levels. changing the semantics/behavior of those 'caches' would easily lead to data corruption/lost updates etc. cheers stefan -- View this message in context: http://www.nabble.com/Clustering-w--distributed-cache-tp22044598p22044598.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Clustering w/ distributed cache
Hi, You are right, we have to serialize/deserialize objects. But that's the price we have to pay for the clustering, is it? The problem is not only serialization, you also have to send the objects over TCP/IP (if I understand you idea correctly). Each operation (including Node.getProperty, Property.getString and so on) would result in at least one TCP/IP conversation. I don't think performance would be acceptable. Regards, Thomas
Re: Clustering w/ distributed cache
Hi, Do you have experience with memcached for Java? http://www.thimbleware.com/projects/jmemcached From what I read it is a client-server solution, you would have to serialize / deserialize objects, which would slow down things a lot (compared to having the cache in the Java heap memory). Regards, Thomas On Mon, Feb 16, 2009 at 9:02 PM, defeng defeng...@gmail.com wrote: I am using Jackrabbit 1.4.4 clustering. DB for persistent manager, and NFS for datastore. Everything works well, but since the Jackrabbit uses a Cluster-wide lock, many times, other JCR clients need to wait for a long time to acquire the Global lock. To solve this issue, I want to use a distributed cache(memcached) in SharedISM. To disable cache in SessionISM and LocalISM (I did not use XA ). So there is no necessary to sync any data in cache. In addition, I donot need to register Namespace or Nodetype at runtime. The only thing is to sync local search index in the Looping of ClusterNode. (I did not use AccessManager in Jackrabbit) When updating an item, a distributed lock is acquired. It is used to ensure the data consistence between persisten manager and distributed cache (2-phase commit). Is the proposal feasible? Any comment is highly appreciated! -- View this message in context: http://www.nabble.com/Clustering-w--distributed-cache-tp22044598p22044598.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Clustering w/ distributed cache
Thank for you reply. I used the memcache in other projects before, the performance seems good. Facebook did some enhancement on it. http://github.com/blog/267-facebook-s-memcached-on-github. You are right, we have to serialize/deserialize objects. But that's the price we have to pay for the clustering, is it? In current clustering, one operation (for example, modify a property) will block entire clustering. It's terrible for us. we want to change the cluster-wide lock to item-wide, based on distributed lock with memcached. Another thought is to disable clustering/journal configuration. All cluster nodes use same distributed cache, DB and NFS. Since no local cache again, we only need to use JMS (activemq) to notify Local Search Index udpating. I noticed Native Clustering was on the Jackrabbit Roadmap - 3.0. What's the schedule for 3.0? Thomas Müller-2 wrote: Hi, Do you have experience with memcached for Java? http://www.thimbleware.com/projects/jmemcached From what I read it is a client-server solution, you would have to serialize / deserialize objects, which would slow down things a lot (compared to having the cache in the Java heap memory). Regards, Thomas On Mon, Feb 16, 2009 at 9:02 PM, defeng defeng...@gmail.com wrote: I am using Jackrabbit 1.4.4 clustering. DB for persistent manager, and NFS for datastore. Everything works well, but since the Jackrabbit uses a Cluster-wide lock, many times, other JCR clients need to wait for a long time to acquire the Global lock. To solve this issue, I want to use a distributed cache(memcached) in SharedISM. To disable cache in SessionISM and LocalISM (I did not use XA ). So there is no necessary to sync any data in cache. In addition, I donot need to register Namespace or Nodetype at runtime. The only thing is to sync local search index in the Looping of ClusterNode. (I did not use AccessManager in Jackrabbit) When updating an item, a distributed lock is acquired. It is used to ensure the data consistence between persisten manager and distributed cache (2-phase commit). Is the proposal feasible? Any comment is highly appreciated! -- View this message in context: http://www.nabble.com/Clustering-w--distributed-cache-tp22044598p22044598.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Clustering-w--distributed-cache-tp22044598p22059652.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
