May 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4247) JPA cachestore fails with Oracle12c and PostgreadPlus 9

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-4247?page=com.atlassian.jira.plugin.... ] Vojtech Juranek reopened ISPN-4247: ----------------------------------- Reopening: not fixed for PostgresPlus9 ([jenkins job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/j...]), Oracle 12 should be fixed, however I still see the same issue ([jenkins job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/j...]) > JPA cachestore fails with Oracle12c and PostgreadPlus 9 > ------------------------------------------------------- > > Key: ISPN-4247 > URL: https://issues.jboss.org/browse/ISPN-4247 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Vojtech Juranek > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > JPA cache store fails on Oracle12c and PostgreadPlus 9 as Hibernate is not able to determine the dialect to be used: > {noformat} > [java] Caused by: org.hibernate.HibernateException: Unable to determine Dialect to use [name=Oracle, majorVersion=12]; user must register resolver or explicitly set 'hibernate.dialect' > {noformat} > resp. > {noformat} > [java] Caused by: org.hibernate.HibernateException: Unable to determine Dialect to use [name=EnterpriseDB, majorVersion=9]; user must register resolver or explicitly set 'hibernate.dialect' > {noformat} > To fix it, HIbernate upgrade is needed. PotgresPlus is fixed in 4.3.0.Beta4 (tracking JIRA is [HHH-8349|https://hibernate.atlassian.net/browse/HHH-8349]), Oracle12c is fixed in Hibernate 5.0.0 (tracking JIRA is [HHH-9044|https://hibernate.atlassian.net/browse/HHH-9044]) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[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)

11 years, 10 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)

11 years, 10 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)

11 years, 10 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)

11 years, 10 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)

11 years, 10 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)

11 years, 10 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)

11 years, 10 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)

11 years, 10 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)

11 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2014