September 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4697) Single cache operation generates two sequential synchronous calls to the indexing engine

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4697?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-4697: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2893 > Single cache operation generates two sequential synchronous calls to the indexing engine > ---------------------------------------------------------------------------------------- > > Key: ISPN-4697 > URL: https://issues.jboss.org/browse/ISPN-4697 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 7.0.0.Beta1 > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > > For a similar reason as explained in ISPN-4650, the method > {{org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(PutKeyValueCommand, InvocationContext, Object, TransactionContext)}} > is likely to invoke a {{removeFromIndexes}} first and then an {{updateIndexes}}. > When using transactions, the {{transactionContext}} will enqueue both operations for execution in the same call to the backend, but when no transaction is in progress, this will generate two sequential and independent calls to the backend. > When the backend happens to be the {{InfinispanIndexManager}}, this implies we're generating two sequential synchronous RPCs rather than bacthing the two operations in a single Update statement: the first call is completely redundant in most cases, and can be incorporated in the second call for all remaining edge cases. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4731) Update classpath to ensure Weld loads Guava instead of Google Collections

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4731?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4731: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1142230|https://bugzilla.redhat.com/show_bug.cgi?id=1142230] from NEW to POST > Update classpath to ensure Weld loads Guava instead of Google Collections > ------------------------------------------------------------------------- > > Key: ISPN-4731 > URL: https://issues.jboss.org/browse/ISPN-4731 > Project: Infinispan > Issue Type: Bug > Components: CDI Integration, Integration > Affects Versions: 7.0.0.Beta2 > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Labels: maven > Fix For: 7.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4743) Rebalance can hang after the coordinator and another node leave

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4743?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4743: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2891 > Rebalance can hang after the coordinator and another node leave > --------------------------------------------------------------- > > Key: ISPN-4743 > URL: https://issues.jboss.org/browse/ISPN-4743 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 7.0.0.CR1 > > > This caused a failure in {{ClusterTopologyManagerTest.testAbruptLeaveAfterGetStatus}}. > When the coordinator changes, the new coordinator first sends a {{CacheTopologyControlCommand(type=CH_UPDATE)}} to reset any ongoing rebalance, then a {{CacheTopologyControlCommand(type=REBALANCE_START)}} to start a new rebalance with the remaining members. If another node leaves afterwards, the coordinator sends yet another {{CacheTopologyControlCommand(type=CH_UPDATE)}} to remove the leaver from the CHs. > If one node (in this case the coordinator itself) processes the last {{CH_UPDATE}} before the other two commands, it will fail to confirm the rebalance, and the cache will stay in "rebalancing" state until another node joins or leaves. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4748) Source codo always recompiled (no incremental compilation)

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-4748?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-4748: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2895 > Source codo always recompiled (no incremental compilation) > ---------------------------------------------------------- > > Key: ISPN-4748 > URL: https://issues.jboss.org/browse/ISPN-4748 > Project: Infinispan > Issue Type: Task > Affects Versions: 7.0.0.Beta2 > Reporter: Ion Savin > Assignee: Ion Savin > Fix For: 7.0.0.Final > > > Incremental compilation is broken. > Running: > {noformat} > $ mvn -DskipTests clean install > $ mvn test > {noformat} > will have the source code recompiled on the second call. > The source of the problem is an issue in the 3.x maven-compiler-plugin which is confused by the package-info.java source files (details here: https://jira.codehaus.org/browse/MCOMPILER-205) > Solving this problem could improve the build time slightly. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4748) Source codo always recompiled (no incremental compilation)

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-4748?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-4748: ---------------------------- Status: Open (was: New) > Source codo always recompiled (no incremental compilation) > ---------------------------------------------------------- > > Key: ISPN-4748 > URL: https://issues.jboss.org/browse/ISPN-4748 > Project: Infinispan > Issue Type: Task > Affects Versions: 7.0.0.Beta2 > Reporter: Ion Savin > Assignee: Ion Savin > Fix For: 7.0.0.Final > > > Incremental compilation is broken. > Running: > {noformat} > $ mvn -DskipTests clean install > $ mvn test > {noformat} > will have the source code recompiled on the second call. > The source of the problem is an issue in the 3.x maven-compiler-plugin which is confused by the package-info.java source files (details here: https://jira.codehaus.org/browse/MCOMPILER-205) > Solving this problem could improve the build time slightly. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4748) Source codo always recompiled (no incremental compilation)

by Ion Savin (JIRA)

Ion Savin created ISPN-4748: ------------------------------- Summary: Source codo always recompiled (no incremental compilation) Key: ISPN-4748 URL: https://issues.jboss.org/browse/ISPN-4748 Project: Infinispan Issue Type: Task Affects Versions: 7.0.0.Beta2 Reporter: Ion Savin Assignee: Ion Savin Fix For: 7.0.0.Final Incremental compilation is broken. Running: {noformat} $ mvn -DskipTests clean install $ mvn test {noformat} will have the source code recompiled on the second call. The source of the problem is an issue in the 3.x maven-compiler-plugin which is confused by the package-info.java source files (details here: https://jira.codehaus.org/browse/MCOMPILER-205) Solving this problem could improve the build time slightly. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4744) RemoteCacheOsgiIT fails to run

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4744?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4744: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1145006|https://bugzilla.redhat.com/show_bug.cgi?id=1145006] from ASSIGNED to MODIFIED > RemoteCacheOsgiIT fails to run > ------------------------------ > > Key: ISPN-4744 > URL: https://issues.jboss.org/browse/ISPN-4744 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.0.0.Beta2 > Reporter: Adrian Nistor > Assignee: Ion Savin > Fix For: 7.0.0.CR1 > > > Three problems: > * the 3 nodes started using antrun fail to start if JBOSS_HOME is set to a location different from the ones holding the configs (target/server/node{1,2,3}) > * the test probe doesn't export the Person class used in the test and commons fails to find this class > * paxurl fails to find the osgi features if custom maven local repository paths are used -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4579) SingleNodeJdbcStoreIT.cleanup NPE after test failure

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4579?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-4579: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated. Thanks! > SingleNodeJdbcStoreIT.cleanup NPE after test failure > ---------------------------------------------------- > > Key: ISPN-4579 > URL: https://issues.jboss.org/browse/ISPN-4579 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Labels: testsuite_stability > Fix For: 7.0.0.CR1 > > > After a failure in {{SingleNodeJdbcStoreIT.testForcedShutdown}}, it seems not all the test stores are properly initialized, and cleanup fails with a NullPointerException: > {noformat} > [00:57:07] : [testForcedShutdown] java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertNotNull(Assert.java:621) > at org.junit.Assert.assertNotNull(Assert.java:631) > at org.infinispan.server.test.cs.jdbc.SingleNodeJdbcStoreIT.testRestartStringStoreBefore(SingleNodeJdbcStoreIT.java:223) > at org.infinispan.server.test.cs.jdbc.SingleNodeJdbcStoreIT.testForcedShutdown(SingleNodeJdbcStoreIT.java:163) > ... > [00:57:07]W: [org.infinispan.server:test-suite] java.lang.NullPointerException > at org.infinispan.server.test.cs.jdbc.SingleNodeJdbcStoreIT.cleanup(SingleNodeJdbcStoreIT.java:82) > {noformat} > This bug is only about the NPE, the test failure is agent-specific (probably caused by the low open files/user processes limits). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4746) NPE when preloading cache with DeltaAware values

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4746?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-4746: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2892 > NPE when preloading cache with DeltaAware values > ------------------------------------------------ > > Key: ISPN-4746 > URL: https://issues.jboss.org/browse/ISPN-4746 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Beta2 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > {code:java} > public class DeltaAwarePreloadTest extends MultipleCacheManagersTest { > private static final int CLUSTER_SIZE = 1; > @Override > protected void createCacheManagers() throws Throwable { > ConfigurationBuilder c = getDefaultClusteredCacheConfig(CacheMode.DIST_SYNC, false); > c.persistence().addStore(new DummyInMemoryStoreConfigurationBuilder(c.persistence()).storeName(getClass().getSimpleName())).preload(true); > createCluster(c, CLUSTER_SIZE); > waitForClusterToForm(); > } > @Test > public void testPreloadOnStart() throws PersistenceException { > Cache<Object, Object> cache = caches().get(0); > cache.put(1, new TestDeltaAware()); > cache.stop(); > cache.start(); > } > } > {code} > During preload, the {{NonTxDistributionInterceptor}} decides that is requires values from previous owners and tries to check if the local node is the primary owner. At this point, the WriteCH is null since no topology was ever updated. Here's the stacktrace: > {code} > Caused by: org.infinispan.persistence.spi.PersistenceException: Unable to preload! > at org.infinispan.persistence.manager.PersistenceManagerImpl.preloadKey(PersistenceManagerImpl.java:620) > at org.infinispan.persistence.manager.PersistenceManagerImpl.access$000(PersistenceManagerImpl.java:70) > at org.infinispan.persistence.manager.PersistenceManagerImpl$1.processEntry(PersistenceManagerImpl.java:228) > at org.infinispan.persistence.dummy.DummyInMemoryStore.process(DummyInMemoryStore.java:165) > at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:220) > 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.getWriteConsistentHash(DistributionManagerImpl.java:115) > at org.infinispan.distribution.impl.DistributionManagerImpl.getConsistentHash(DistributionManagerImpl.java:105) > at org.infinispan.distribution.impl.DistributionManagerImpl.getPrimaryLocation(DistributionManagerImpl.java:95) > at org.infinispan.interceptors.locking.ClusteringDependentLogic$DistributionLogic.localNodeIsPrimaryOwner(ClusteringDependentLogic.java:395) > at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.remoteGetBeforeWrite(NonTxDistributionInterceptor.java:131) > at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleNonTxWriteCommand(BaseDistributionInterceptor.java:195) > at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutKeyValueCommand(NonTxDistributionInterceptor.java:72) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.DistCacheWriterInterceptor.visitPutKeyValueCommand(DistCacheWriterInterceptor.java:72) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.CacheLoaderInterceptor.visitPutKeyValueCommand(CacheLoaderInterceptor.java:113) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:376) > at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:464) > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4746) NPE when preloading cache with DeltaAware values

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4746?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-4746: ------------------------------------ Status: Open (was: New) > NPE when preloading cache with DeltaAware values > ------------------------------------------------ > > Key: ISPN-4746 > URL: https://issues.jboss.org/browse/ISPN-4746 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Beta2 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > {code:java} > public class DeltaAwarePreloadTest extends MultipleCacheManagersTest { > private static final int CLUSTER_SIZE = 1; > @Override > protected void createCacheManagers() throws Throwable { > ConfigurationBuilder c = getDefaultClusteredCacheConfig(CacheMode.DIST_SYNC, false); > c.persistence().addStore(new DummyInMemoryStoreConfigurationBuilder(c.persistence()).storeName(getClass().getSimpleName())).preload(true); > createCluster(c, CLUSTER_SIZE); > waitForClusterToForm(); > } > @Test > public void testPreloadOnStart() throws PersistenceException { > Cache<Object, Object> cache = caches().get(0); > cache.put(1, new TestDeltaAware()); > cache.stop(); > cache.start(); > } > } > {code} > During preload, the {{NonTxDistributionInterceptor}} decides that is requires values from previous owners and tries to check if the local node is the primary owner. At this point, the WriteCH is null since no topology was ever updated. Here's the stacktrace: > {code} > Caused by: org.infinispan.persistence.spi.PersistenceException: Unable to preload! > at org.infinispan.persistence.manager.PersistenceManagerImpl.preloadKey(PersistenceManagerImpl.java:620) > at org.infinispan.persistence.manager.PersistenceManagerImpl.access$000(PersistenceManagerImpl.java:70) > at org.infinispan.persistence.manager.PersistenceManagerImpl$1.processEntry(PersistenceManagerImpl.java:228) > at org.infinispan.persistence.dummy.DummyInMemoryStore.process(DummyInMemoryStore.java:165) > at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:220) > 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.getWriteConsistentHash(DistributionManagerImpl.java:115) > at org.infinispan.distribution.impl.DistributionManagerImpl.getConsistentHash(DistributionManagerImpl.java:105) > at org.infinispan.distribution.impl.DistributionManagerImpl.getPrimaryLocation(DistributionManagerImpl.java:95) > at org.infinispan.interceptors.locking.ClusteringDependentLogic$DistributionLogic.localNodeIsPrimaryOwner(ClusteringDependentLogic.java:395) > at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.remoteGetBeforeWrite(NonTxDistributionInterceptor.java:131) > at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleNonTxWriteCommand(BaseDistributionInterceptor.java:195) > at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutKeyValueCommand(NonTxDistributionInterceptor.java:72) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.DistCacheWriterInterceptor.visitPutKeyValueCommand(DistCacheWriterInterceptor.java:72) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.CacheLoaderInterceptor.visitPutKeyValueCommand(CacheLoaderInterceptor.java:113) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:376) > at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:464) > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 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 September 2014