4 Replies Latest reply on Aug 5, 2010 9:56 AM by Shane Johnson

    Hot Rod Clarifications

    Shane Johnson Novice

      Assume that we have a Hot Rod cluster (A and B) set up for replication, and that we have to clients (1 and 2)

       

      When using a remote cache store on the clients, can 'fetchPersistentState' be used to have the clients retrieve all entries in the Hot Rod cluster at start up?

       

      If not, I also noticed a 'loadAll' method. Can this be used to force the clients to retrieve all entries in the Hot Rod cluster at startup?

       

      I noticed that ISPN-374 is still open.

      • Does that mean we run the risk of having stale entries on our clients?
      • Also, even if we did load all of the entries at start up, does that mean that if subsequent entries were added via 1 that they would not end up on 2 unless it specifically requested them?
      • It looks like ISPN-374 is geared towards invalidation. I'm wondering if it can or will be expanded to actually push the 'entries' instead of just notifications based on the key.

       

      From what I can tell, it looks like the remote cache store is intended to operate as an L1 cache. We were considering the use of Hot Rod as a means to survive application cluster failures by separating the cache. However, now it looks like we just want a 4 node cluster such that 2 nodes are on the same VMs as our application while 2 nodes are just running Infinispan. Thus we could lose our applications, but the cache would survive.

       

      On the otherhand, as an L1 cache, we may not be able to handle the delay in fetching the entry over the wire each time. That's why I'm wondering if I can have the best of both worlds by having the Hot Rod instances replicate with the clients.