1 2 Previous Next 22 Replies Latest reply on Jul 1, 2010 10:18 AM by mircea.markus Go to original post
      • 15. Re: Distributed Cache
        mircea.markus

        The problem with HotRod (at least as I understand it now)  is that the client is aware of the cluster changes of storage nodes, but not about other client(=business) nodes!

        There's another architecture that might fit this requirement.

        You can run two clusters, the storage one and the client one. Client one has a aggressive eviction, and uses a RemoteCacheStore [1] to communicate with the storage cluster.  RemoteCacheStore relies on HotRod transparently. With this architecture:

        - all the clients are aware of other clients

        - storage nodes are aware of other  storage nodes

        - clients are aware of store nodes, not the other way around

        - clients only contain a subset of the data stored in the storage cluster

        - you can even configure two different transport layer between the two clusters

        - you end up running two clusters, but the good thing is storage nodes won't spent time processing leaves and joins of client nodes, so adding/removing 1 or 100 clients would not affect the storage cluster. 

         

        Does this look like something you might use?

         

         

        [1] http://community.jboss.org/docs/DOC-14893?uniqueTitle=false#Remote_cache_loader

        • 16. Re: Distributed Cache

          Got your point about Infinispan being only the distributed cache.

           

          Still it seems so easy to disable part of functionality in some nodes (that are configured that way), so that they don't have the cache in them.  Then, after you implement ispn-39, it will be not only the distributed cache - but the complete clustering solution.

           

          Hm...maybe you don't want that, not to compete with JBoss clustering?

          • 17. Re: Distributed Cache
            mircea.markus

            Still it seems so easy to disable part of functionality in some nodes (that are configured that way), so that they don't have the cache in them.  Then, after you implement ispn-39, it will be not only the distributed cache - but the complete clustering solution.

            Mind creating an JIRA for that and vote for it? I think this is a fair point

            • 18. Re: Distributed Cache

               

              There's another architecture that might fit this requirement.

              You can run two clusters, the storage one and the client one. Client one has a aggressive eviction, and uses a RemoteCacheStore [1] to communicate with the storage cluster.  RemoteCacheStore relies on HotRod transparently.

               

              Interesting workaround! Will play with that. 

               

              Also does RemoteCacheStore  have the near cache feature?

              • 19. Re: Distributed Cache

                Mind creating an JIRA for that and vote for it? I think this is a fair point

                ok.  I 'll try to do that.

                • 20. Re: Distributed Cache
                  mircea.markus
                  Also does RemoteCacheStore  have the near cache feature?

                  No it doesn't. It's the cache that's using it where some of the data is being used.

                  • 21. Re: Distributed Cache
                    manik

                    Mircea, we really need to document the RemoteCacheStore.  It is a powerful building-block with which people can build powerful architectures, but it isn't very clearly understood at the moment.  Perhaps a wiki page about this, with some diagrams to make it clear? 

                    • 22. Re: Distributed Cache
                      mircea.markus

                      +1. This's on my todo list post CR1.

                      1 2 Previous Next