Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-4212

Unable to get entries from newly started non-defined caches

This issue belongs to an archived project. You can view it, but you can't modify it. Learn more

XMLWordPrintable

      If you use hotrod to put entries into a cache which is not defined in standalone.xml, it will be started:

      15:35:50,676 INFO  [org.jboss.as.clustering.infinispan] (HotRodServerWorker-1) JBAS010281: Started nonDefinedCache cache from local container

      but when you try to retrieve the entry back, you'll get null.

      RemoteCacheManager rcm = new RemoteCacheManager(new ConfigurationBuilder().addServer().host("localhost").port(11222).build());
RemoteCache<String, String> cache = rcm.getCache("nonDefinedCache");
cache.put("key", "value");
cache.get("key"); // returns null

      Happens in the current server snapshot.
      A while back you'd get this

      WARN: ISPN004005: Error received from the server: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'nonDefinedCache' not found amongst the configured caches

      So it seems we're somewhere in the middle now (not throwing exception, but also not working). The documentation here is also wrong https://github.com/infinispan/infinispan/blob/master/client/hotrod-client/src/main/java/org/infinispan/client/hotrod/RemoteCacheManager.java#L511 .

            [ISPN-4212] Unable to get entries from newly started non-defined caches

            Galder Zamarreño added a comment - - edited

            Jakub/Martin, we will be reinstating the limitation of talking only to predefined caches. Details can be found in ISPN-4296. Putting back the limit should fix this issue.

            Galder Zamarreño added a comment - - edited Jakub/Martin, we will be reinstating the limitation of talking only to predefined caches. Details can be found in ISPN-4296 . Putting back the limit should fix this issue.

            Galder Zamarreño added a comment -

            To further clarify, Martin's fix should only work when the cache is not defined anywhere else in the cluster.

            Galder Zamarreño added a comment - To further clarify, Martin's fix should only work when the cache is not defined anywhere else in the cluster.

            Galder Zamarreño added a comment -

            Martin/Jakub, recently I lifted this limitation since asymmetric clusters are already supported (ISPN-833), which is why you see this issue. I haven't looked at the root cause of 4212 specifically, but I've also been looking into ISPN-3530, and until that is fixed, we won't be able to truly have the capability for Hot Rod clients to be able to go a node requested for a particular cache, if this cache is only deployed in a subset of the cluster.

            Talking about 4212, Martin's fix does not solve the issue where the cache might be defined in another node, but the one where you arrived does not have it. In that case, creating a default cache would be the wrong thing to do. The client should receive some failure or be redirected to the node(s) that have that cache pre-defined.

            Part of me is tempted to reinstate the limitation of pre-defined caches until ISPN-3530 and the test case in 4212 are fixed.

            Galder Zamarreño added a comment - Martin/Jakub, recently I lifted this limitation since asymmetric clusters are already supported ( ISPN-833 ), which is why you see this issue. I haven't looked at the root cause of 4212 specifically, but I've also been looking into ISPN-3530 , and until that is fixed, we won't be able to truly have the capability for Hot Rod clients to be able to go a node requested for a particular cache, if this cache is only deployed in a subset of the cluster. Talking about 4212, Martin's fix does not solve the issue where the cache might be defined in another node, but the one where you arrived does not have it. In that case, creating a default cache would be the wrong thing to do. The client should receive some failure or be redirected to the node(s) that have that cache pre-defined. Part of me is tempted to reinstate the limitation of pre-defined caches until ISPN-3530 and the test case in 4212 are fixed.

            Martin Gencur added a comment -

            The root cause is following: When a cache is request by hotrod client and the cache is not among configured caches, a default Infinispan configuration is used (new ConfigurationBuilder().build()). As a result, the AnyServerEquivalence and some other settings are not applied. The problem is that Infinispan subsystem in the server does not set any cache configuration and rather creates every cache by calling .definedConfiguration on the cache manager (this call ignores default cache configuration).

            We have two options here. The first one is quite easy and I already have a fix.
            1) In Infinispan subsystem, pass a default configuration to constructor of DefaultCacheManager. The default configuration is the one from infinispan-defaults.xml (it's a local cache!) and we can easily parse it and pass to DefaultCacheManager
            2) The first option is not ideal because users can not set the settings in any way (infinispan-defaults.xml is internal file of the server). Ideally, any new cache that is not configured in standalone.xml would be configured according to the "default" cache in that file. It would have the same configuration as default cache. This is tricky to implement but I'll look if it can be done.

            Martin Gencur added a comment - The root cause is following: When a cache is request by hotrod client and the cache is not among configured caches, a default Infinispan configuration is used (new ConfigurationBuilder().build()). As a result, the AnyServerEquivalence and some other settings are not applied. The problem is that Infinispan subsystem in the server does not set any cache configuration and rather creates every cache by calling .definedConfiguration on the cache manager (this call ignores default cache configuration). We have two options here. The first one is quite easy and I already have a fix. 1) In Infinispan subsystem, pass a default configuration to constructor of DefaultCacheManager. The default configuration is the one from infinispan-defaults.xml (it's a local cache!) and we can easily parse it and pass to DefaultCacheManager 2) The first option is not ideal because users can not set the settings in any way (infinispan-defaults.xml is internal file of the server). Ideally, any new cache that is not configured in standalone.xml would be configured according to the "default" cache in that file. It would have the same configuration as default cache. This is tricky to implement but I'll look if it can be done.

            Martin Gencur added a comment -

            I'm looking into this. The entry is really stored in the cache via put operation but can't be retrieved via get(). This points to the Equivalence classes that are badly configured. Currently, all caches that are defined in the XML file and started at the beginning have keyEquivalence and valueEquivalence equal to org.jboss.as.clustering.infinispan.equivalence.AnyServerEquivalence while cache started later have org.infinispan.commons.equivalence.AnyEquivalence. I will look for the right fix.

            Martin Gencur added a comment - I'm looking into this. The entry is really stored in the cache via put operation but can't be retrieved via get(). This points to the Equivalence classes that are badly configured. Currently, all caches that are defined in the XML file and started at the beginning have keyEquivalence and valueEquivalence equal to org.jboss.as.clustering.infinispan.equivalence.AnyServerEquivalence while cache started later have org.infinispan.commons.equivalence.AnyEquivalence. I will look for the right fix.

              rh-ee-galder Galder Zamarreño
              jmarkos Jakub Markos (Inactive)
              Archiver:
              rhn-support-adongare Amol Dongare

                Created:
                Updated:
                Resolved:
                Archived: