[JBoss JIRA] (ISPN-4187) LRU eviction algorithm does not evict the eldest entry
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4187?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4187:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1090591|https://bugzilla.redhat.com/show_bug.cgi?id=1090591] from ON_QA to VERIFIED
> LRU eviction algorithm does not evict the eldest entry
> ------------------------------------------------------
>
> Key: ISPN-4187
> URL: https://issues.jboss.org/browse/ISPN-4187
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 7.0.0.Alpha2
> Reporter: Martin Gencur
> Assignee: William Burns
> Labels: 630betablocker
> Fix For: 7.0.0.Alpha4
>
> Attachments: server2.log
>
>
> The following test for JDBC cache stores fails:
> {code:java}
> @Test
> @WithRunningServer({@RunningServer(name = CONTAINER1, config = CONFIG_FETCH_STATE_1)})
> public void testFetchState() throws Exception {
> try {
> mc1 = createMemcachedClient(server1);
> assertCleanCacheAndStore1();
> mc1.set("k1", "v1");
> mc1.set("k2", "v2");
> mc1.set("k3", "v3");
> assertNotNull(dbServer1.stringTable.getValueByKey("k1"));
> startContainer(controller, CONTAINER2, CONFIG_FETCH_STATE_2);
> mc2 = createMemcachedClient(server2);
> assertTrue(0 < server2.getCacheManager(MANAGER_NAME).getCache(CACHE_NAME).getNumberOfEntries());
> //the cache store should fetch state from the others
> //since eviction.max-entries==2, first k2 and k3 is loaded from the other cache, then k1 is loaded
> //from the other cache's loader and thus k2 is evicted and ends up in a cache loader
> assertNull(dbServer2.stringTable.getValueByKey("k1"));
> assertEquals("v1", mc2.get("k1"));
> assertEquals("v2", mc2.get("k2"));
> assertNull(dbServer2.stringTable.getValueByKey("k1"));
> //^^^^^fails here, the K1 was evicted even though it was used recently
> //K3 was supposed to be evicted but it did not happen
> assertNull(dbServer2.stringTable.getValueByKey("k2"));
> assertCleanCacheAndStore2();
> } finally {
> controller.stop(CONTAINER2);
> }
> }
> {code}
> This tests works properly if the following commit is reverted, so it was caused by this commit:
> https://github.com/infinispan/infinispan/commit/b190230d84beb41474bae0239...
> Note that there's another commit with the same name but different commit hash: b71da1c
> The test above can be run from https://github.com/chepa653/infinispan/tree/t_ISPN-3904 by going to server/integration/testsuite and running mvn clean verify -Dtest=StringBasedStoreMultinodeTest#testFetchState -Dlog.level.infinispan=TRACE
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4147) the new EAP-based CLI is not yet compatibile with the old JDG CLI
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4147?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4147:
-----------------------------------------------
Vitalii Chepeliuk <vchepeli(a)redhat.com> changed the Status of [bug 1079883|https://bugzilla.redhat.com/show_bug.cgi?id=1079883] from ON_QA to VERIFIED
> the new EAP-based CLI is not yet compatibile with the old JDG CLI
> -----------------------------------------------------------------
>
> Key: ISPN-4147
> URL: https://issues.jboss.org/browse/ISPN-4147
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 7.0.0.Alpha1
> Reporter: Vitalii Chepeliuk
> Assignee: Pedro Ruivo
> Labels: 630betablocker
>
> * Running JDG tests for CLI
> Fcli/standalone_caches_test.rb:84: warning: Insecure world writable dir /qa/tools in PATH, mode 040777
> Exception in thread "main" java.lang.UnsupportedClassVersionError: org/jboss/as/cli/CommandLineMain : Unsupported major.minor version 51.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76)
> at org.jboss.modules.Module.loadModuleClass(Module.java:548)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:249)
> at org.jboss.modules.Module.run(Module.java:280)
> at org.jboss.modules.Main.main(Main.java:455)
> ** Jobs are here
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/j...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/j...
> * ispn-cli --help
> Usage:
> jboss-cli.sh/jboss-cli.bat [--help] [--version] [--controller=host:port]
> [--connect] [--file=file_path]
> [--commands=command_or_operation1,command_or_operation2...]
> [--command=command_or_operation]
> [--user=username --password=password]
> [--no-local-auth]
> [--timeout=timeout]
> --help (-h) - prints (this) basic description of the command line utility.
> --version - prints the version info of the JBoss AS release, JVM and system environment.
> --controller - the default controller host and port to connect to when
> --connect option (described below) is specified or when the connect command is issued w/o the arguments. The default controller host is localhost and the port is 9999.
> --connect (-c) - instructs the CLI to connect to the controller on start-up (to avoid issuing a separate connect command later).
> --gui - GUI built on top of the CLI, the only difference is that it brings up a GUI instead of a command line. In this mode, the CLI will automatically connect during start-up. You can
> optionally specify --controller, if necessary.
> --file - specifies a path to a file which contains commands operations (one per line) that should be executed (in a non-interactive mode). The CLI will terminate the session
> immediately after the last command has been executed or if
> some command or operation failed.
> ... etc
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4296) Restore predefined cache limitation for Hot Rod servers
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4296?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4296:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2564
> Restore predefined cache limitation for Hot Rod servers
> -------------------------------------------------------
>
> Key: ISPN-4296
> URL: https://issues.jboss.org/browse/ISPN-4296
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Protocols
> Affects Versions: 7.0.0.Alpha3
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Beta1
>
>
> Even after asymmetric cluster support was implemented, each node still does not know which other nodes contain which caches. The coordinator of the cluster knows, but no one else. This is because the aim has never really been to have different nodes containing different caches, but more about making sure that caches can be started lazily. With this in mind, the limitation in ISPN-833 will be reinstated.
> Being able to work only with predefined caches also simplifies a solution for ISPN-3530 because we can safely assume that all servers contain the defined caches. Each cache might have a different consistent hash (see dev list discussion on why this can easily happen - ) but at least knowing that the nodes that have it is the same makes it easier to come up with a solution.
> Finally, restoring the limitation avoids other can of worms such as the edge cases discovered by Jakub in ISPN-4212.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4212) Unable to get entries from newly started non-defined caches
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4212?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-4212:
----------------------------------------
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 this issue.
> Unable to get entries from newly started non-defined caches
> -----------------------------------------------------------
>
> Key: ISPN-4212
> URL: https://issues.jboss.org/browse/ISPN-4212
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, Server
> Affects Versions: 7.0.0.Alpha3
> Reporter: Jakub Markos
> Assignee: Galder Zamarreño
>
> If you use hotrod to put entries into a cache which is not defined in standalone.xml, it will be started:
> {code}
> 15:35:50,676 INFO [org.jboss.as.clustering.infinispan] (HotRodServerWorker-1) JBAS010281: Started nonDefinedCache cache from local container
> {code}
> but when you try to retrieve the entry back, you'll get null.
> {code}
> 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
> {code}
> Happens in the current server snapshot.
> A while back you'd get this
> {code}
> WARN: ISPN004005: Error received from the server: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'nonDefinedCache' not found amongst the configured caches
> {code}
> 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... .
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4296) Restore predefined cache limitation for Hot Rod servers
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-4296:
--------------------------------------
Summary: Restore predefined cache limitation for Hot Rod servers
Key: ISPN-4296
URL: https://issues.jboss.org/browse/ISPN-4296
Project: Infinispan
Issue Type: Enhancement
Components: Remote Protocols
Affects Versions: 7.0.0.Alpha3
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 7.0.0.Beta1
Even after asymmetric cluster support was implemented, each node still does not know which other nodes contain which caches. The coordinator of the cluster knows, but no one else. This is because the aim has never really been to have different nodes containing different caches, but more about making sure that caches can be started lazily. With this in mind, the limitation in ISPN-833 will be reinstated.
Being able to work only with predefined caches also simplifies a solution for ISPN-3530 because we can safely assume that all servers contain the defined caches. Each cache might have a different consistent hash (see dev list discussion on why this can easily happen - ) but at least knowing that the nodes that have it is the same makes it easier to come up with a solution.
Finally, restoring the limitation avoids other can of worms such as the edge cases discovered by Jakub in ISPN-4212.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months