November 2014 - infinispan-issues

[JBoss JIRA] (ISPN-5002) InfinispanQueryIT fails using wrong infinispan-storage module slot

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-5002?page=com.atlassian.jira.plugin.... ] Vojtech Juranek updated ISPN-5002: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3090 > InfinispanQueryIT fails using wrong infinispan-storage module slot > ------------------------------------------------------------------- > > Key: ISPN-5002 > URL: https://issues.jboss.org/browse/ISPN-5002 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Labels: testsuite_stability > > Fails with > {noformat} > org.jboss.modules.ModuleLoadError: org.hibernate.search.infinispan-storage:ispn-7.1 > at org.jboss.modules.ModuleLoadException.toError(ModuleLoadException.java:78) > {noformat} > See e.g. http://ci.infinispan.org/viewLog.html?buildId=14327&tab=buildResultsDiv&b... > It's loaded from Hibernate Search which uses older version of ISPN. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5002) InfinispanQueryIT fails using wrong infinispan-storage module slot

by Vojtech Juranek (JIRA)

Vojtech Juranek created ISPN-5002: ------------------------------------- Summary: InfinispanQueryIT fails using wrong infinispan-storage module slot Key: ISPN-5002 URL: https://issues.jboss.org/browse/ISPN-5002 Project: Infinispan Issue Type: Bug Components: Test Suite - Core Reporter: Vojtech Juranek Assignee: Vojtech Juranek Fails with {noformat} org.jboss.modules.ModuleLoadError: org.hibernate.search.infinispan-storage:ispn-7.1 at org.jboss.modules.ModuleLoadException.toError(ModuleLoadException.java:78) {noformat} See e.g. http://ci.infinispan.org/viewLog.html?buildId=14327&tab=buildResultsDiv&b... It's loaded from Hibernate Search which uses older version of ISPN. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4979) CacheStatusResponse map uses too much memory

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4979?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4979: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/3085 > CacheStatusResponse map uses too much memory > -------------------------------------------- > > Key: ISPN-4979 > URL: https://issues.jboss.org/browse/ISPN-4979 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.0.Final > Reporter: Dan Berindei > Assignee: William Burns > Priority: Critical > Fix For: 7.1.0.Final > > > When the cluster is large and there are a log of caches, the {{CacheStatusResponse}} map on the new coordinator can get quite large. One of the problems that seems to be that the addresses in {{DefaultConsistentHash}} are duplicated on serialization, so the deserialized version occupies more memory. > We need to investigate why the objects are not "shared" by the River marshaller, and maybe work around the problem by de-duplicating the addresses in the externalizer. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5001) NPE on preload with tx caches containing DeltaAware values

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-5001: --------------------------------------- Summary: NPE on preload with tx caches containing DeltaAware values Key: ISPN-5001 URL: https://issues.jboss.org/browse/ISPN-5001 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 7.0.2.Final, 7.0.0.Final Reporter: Gustavo Fernandes A similar bug was fixed for non-tx caches on ISPN-4746 To reproduce the issue, change the {{DeltaAwarePreloadTest}} to use transactional cache. Error: {code} org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170) at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216) at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:813) at org.infinispan.distribution.DeltaAwarePreloadTest.testPreloadOnStart(DeltaAwarePreloadTest.java:38) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) at org.testng.TestRunner.privateRun(TestRunner.java:767) at org.testng.TestRunner.run(TestRunner.java:617) at org.testng.SuiteRunner.runTest(SuiteRunner.java:348) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:343) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305) at org.testng.SuiteRunner.run(SuiteRunner.java:254) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224) at org.testng.TestNG.runSuitesLocally(TestNG.java:1149) at org.testng.TestNG.run(TestNG.java:1057) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111) at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204) at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175) at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:125) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) Caused by: org.infinispan.persistence.spi.PersistenceException: Unable to preload! at org.infinispan.persistence.manager.PersistenceManagerImpl.preloadKey(PersistenceManagerImpl.java:633) at org.infinispan.persistence.manager.PersistenceManagerImpl.access$000(PersistenceManagerImpl.java:70) at org.infinispan.persistence.manager.PersistenceManagerImpl$1.processEntry(PersistenceManagerImpl.java:232) at org.infinispan.persistence.dummy.DummyInMemoryStore.process(DummyInMemoryStore.java:165) at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:224) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) ... 37 more Caused by: java.lang.NullPointerException at org.infinispan.distribution.impl.DistributionManagerImpl.getReadConsistentHash(DistributionManagerImpl.java:110) at org.infinispan.interceptors.distribution.TxDistributionInterceptor.remoteGet(TxDistributionInterceptor.java:319) at org.infinispan.interceptors.distribution.TxDistributionInterceptor.remoteGetBeforeWrite(TxDistributionInterceptor.java:311) at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:269) at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitPutKeyValueCommand(TxDistributionInterceptor.java:105) {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3982) TransactionTable leaks memory when JTS is activated

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3982?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3982: ------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/3086, https://github.com/infinispan/infinispan/pull/3087, https://github.com/infinispan/infinispan/pull/3088 (was: https://github.com/infinispan/infinispan/pull/3086, https://github.com/infinispan/infinispan/pull/3087) > TransactionTable leaks memory when JTS is activated > --------------------------------------------------- > > Key: ISPN-3982 > URL: https://issues.jboss.org/browse/ISPN-3982 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.7.Final > Reporter: Andrey Smirnov > Assignee: Pedro Ruivo > Fix For: 7.1.0.Alpha1, 6.0.3.Final, 5.2.11.Final > > Attachments: 0001-ISPN-3982-fixed.patch.gz > > > JBoss EAP 6.2 uses jbossjts-jacorb as it's JTS implementation. In this component com.arjuna.ats.internal.jta.transaction.jts.TransactionImple class has unstable hashCode behaviour. > This causes mem-leak in TransactionTable when activating JTS. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3982) TransactionTable leaks memory when JTS is activated

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3982?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3982: ------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/3086, https://github.com/infinispan/infinispan/pull/3087 (was: https://github.com/infinispan/infinispan/pull/3086) > TransactionTable leaks memory when JTS is activated > --------------------------------------------------- > > Key: ISPN-3982 > URL: https://issues.jboss.org/browse/ISPN-3982 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.7.Final > Reporter: Andrey Smirnov > Assignee: Pedro Ruivo > Fix For: 7.1.0.Alpha1, 6.0.3.Final, 5.2.11.Final > > Attachments: 0001-ISPN-3982-fixed.patch.gz > > > JBoss EAP 6.2 uses jbossjts-jacorb as it's JTS implementation. In this component com.arjuna.ats.internal.jta.transaction.jts.TransactionImple class has unstable hashCode behaviour. > This causes mem-leak in TransactionTable when activating JTS. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4967) Deprecate ProtobufMetadataManagerMBean.registerProtofiles(String... classPathResources)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4967?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4967: ----------------------------------------------- Tomas Sykora <tsykora(a)redhat.com> changed the Status of [bug 1163031|https://bugzilla.redhat.com/show_bug.cgi?id=1163031] from ON_QA to VERIFIED > Deprecate ProtobufMetadataManagerMBean.registerProtofiles(String... classPathResources) > --------------------------------------------------------------------------------------- > > Key: ISPN-4967 > URL: https://issues.jboss.org/browse/ISPN-4967 > Project: Infinispan > Issue Type: Task > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.1.0.Alpha1 > > > This method should no longer be used as there are better alternatives in ProtobufMetadataManagerMBean. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3982) TransactionTable leaks memory when JTS is activated

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3982?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3982: ------------------------------ Fix Version/s: 7.1.0.Alpha1 6.0.3.Final > TransactionTable leaks memory when JTS is activated > --------------------------------------------------- > > Key: ISPN-3982 > URL: https://issues.jboss.org/browse/ISPN-3982 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.7.Final > Reporter: Andrey Smirnov > Assignee: Pedro Ruivo > Fix For: 7.1.0.Alpha1, 6.0.3.Final, 5.2.11.Final > > Attachments: 0001-ISPN-3982-fixed.patch.gz > > > JBoss EAP 6.2 uses jbossjts-jacorb as it's JTS implementation. In this component com.arjuna.ats.internal.jta.transaction.jts.TransactionImple class has unstable hashCode behaviour. > This causes mem-leak in TransactionTable when activating JTS. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3982) TransactionTable leaks memory when JTS is activated

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3982?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3982: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/3086 > TransactionTable leaks memory when JTS is activated > --------------------------------------------------- > > Key: ISPN-3982 > URL: https://issues.jboss.org/browse/ISPN-3982 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.7.Final > Reporter: Andrey Smirnov > Assignee: Pedro Ruivo > Fix For: 5.2.11.Final > > Attachments: 0001-ISPN-3982-fixed.patch.gz > > > JBoss EAP 6.2 uses jbossjts-jacorb as it's JTS implementation. In this component com.arjuna.ats.internal.jta.transaction.jts.TransactionImple class has unstable hashCode behaviour. > This causes mem-leak in TransactionTable when activating JTS. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4972) Two concurrent replaceWithVersions may both succeed

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4972?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4972: ----------------------------------- Forum Reference: http://lists.jboss.org/pipermail/infinispan-dev/2014-November/015685.html > Two concurrent replaceWithVersions may both succeed > --------------------------------------------------- > > Key: ISPN-4972 > URL: https://issues.jboss.org/browse/ISPN-4972 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 7.0.0.Final > Reporter: Radim Vansa > > Cache contains entry {{K = V}}. Two concurrent threads, that execute: > {code} > long version = cache.getVersioned(K).getVersion(); > boolean succeeded = cache.replaceWithVersion(K, V, version); > {code} > Both of these threads can get {{succeeded = true}}. > Reason: > When the server receives the operation ReplaceIfUnmodified=replaceWithVersion, it retrieves the entry (key + value + metadata) from the cache and checks that the version stored (in metadata) is the same as the version in the request. If so, it creates conditional ReplaceCommand which contains the value (retrieved atomically with version from the cache) and executes this one. Therefore, as the value is in both requests identical (and is not changed by the replace), two concurrent ReplaceCommands can both succeed, and this value is returned to the HotRod client. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 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 November 2014