May 2014 - infinispan-issues - Jboss List Archives

[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

1
0
0 / 0

[JBoss JIRA] (ISPN-3967) Create a feature file for HotRod client for easy installation in Karaf

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3967?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3967: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1083017|https://bugzilla.redhat.com/show_bug.cgi?id=1083017] from ON_QA to VERIFIED > Create a feature file for HotRod client for easy installation in Karaf > ---------------------------------------------------------------------- > > Key: ISPN-3967 > URL: https://issues.jboss.org/browse/ISPN-3967 > Project: Infinispan > Issue Type: Feature Request > Reporter: Martin Gencur > Assignee: Martin Gencur > Labels: 630, 630betablocker > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > A "feature" file is a descriptor of bundles required by a feature. (More info at http://icodebythesea.blogspot.cz/2012/03/making-osgi-deployments-easier-w...) > We should provide such a file for easy deployment on Karaf. Otherwise users will have to install all artifacts one by one (jboss-loggin, jgroups, infinispan-commons, infinispan-core, commons-pool, jboss-marshalling-osgi, ...) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (ISPN-3904) Migrate JDBC cache store tests

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3904?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3904: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1088310|https://bugzilla.redhat.com/show_bug.cgi?id=1088310] from ON_QA to VERIFIED > Migrate JDBC cache store tests > ------------------------------ > > Key: ISPN-3904 > URL: https://issues.jboss.org/browse/ISPN-3904 > Project: Infinispan > Issue Type: Task > Components: Server > Reporter: Vitalii Chepeliuk > Assignee: Vitalii Chepeliuk > Labels: task > Fix For: 7.0.0.Alpha3 > > > Migrating finctional tests for JDBC cache store > Following modules will be migrated: async-store, binary-no-passivation, binary-with-passivation, invalidation-cache, mixed-no-passivation, mixed-with-passivation, string-based-multinode, string-based-no-passivation, string-based-with-passivation > There is issue with passivating oldest entries https://issues.jboss.org/browse/ISPN-4187 . Should be resolved -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4214) Custom cache store and cache loader sets SHARED attribute to the value of NAME attribute

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4214?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4214: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1088214|https://bugzilla.redhat.com/show_bug.cgi?id=1088214] from ON_QA to VERIFIED > Custom cache store and cache loader sets SHARED attribute to the value of NAME attribute > ---------------------------------------------------------------------------------------- > > Key: ISPN-4214 > URL: https://issues.jboss.org/browse/ISPN-4214 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final, 7.0.0.Alpha3 > Reporter: Martin Gencur > Assignee: Martin Gencur > Labels: 630betablocker > Fix For: 7.0.0.Alpha4 > > > This will be a problem when the server gets rebased to latest WildFly components - where it will fail to parse the whole configuration due to an exception being thrown. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (ISPN-2344) StateTransferReplicationQueueTest.testStateTransferWithNodeRestartedAndBusy

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2344?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2344: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1021479|https://bugzilla.redhat.com/show_bug.cgi?id=1021479] from NEW to MODIFIED > StateTransferReplicationQueueTest.testStateTransferWithNodeRestartedAndBusy > --------------------------------------------------------------------------- > > Key: ISPN-2344 > URL: https://issues.jboss.org/browse/ISPN-2344 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Reporter: Galder Zamarreño > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 7.0.0.Alpha4 > > Attachments: testStateTransferWithNodeRestartedAndBusy-0.tgz > > > {code}java.lang.AssertionError > at org.infinispan.statetransfer.StateTransferReplicationQueueTest.thirdWritingCacheTest(StateTransferReplicationQueueTest.java:146) > at org.infinispan.statetransfer.StateTransferReplicationQueueTest.testStateTransferWithNodeRestartedAndBusy(StateTransferReplicationQueueTest.java:108){code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3652) Some tests from org.infinispan.statetransfer package hang on Windows and fails randomly on RHEL and Solaris

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3652?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3652: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1021479|https://bugzilla.redhat.com/show_bug.cgi?id=1021479] from NEW to MODIFIED > Some tests from org.infinispan.statetransfer package hang on Windows and fails randomly on RHEL and Solaris > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-3652 > URL: https://issues.jboss.org/browse/ISPN-3652 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 6.0.0.CR1 > Environment: Windows 2012 && JDK6 > Reporter: Anna Manukyan > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 7.0.0.Alpha4 > > > The tests for the environment specified hang randomly on package org.infinispan.statetransfer. > Due to not being able to login to executing machine at the moment I cannot provide logs/thread dump for the hanged tests. > The logs would be attached later. > Jenkins jobs could be found here > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... > Failure description here > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... > and here > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2014