December 2014 - infinispan-issues

[JBoss JIRA] (ISPN-5030) NPE during node rebalance after a leave

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5030?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5030: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1161214 > NPE during node rebalance after a leave > --------------------------------------- > > Key: ISPN-5030 > URL: https://issues.jboss.org/browse/ISPN-5030 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.0.Alpha1 > Reporter: Sanne Grinovero > Assignee: Dan Berindei > Priority: Minor > Fix For: 7.1.0.Beta1 > > > I'm seeing stacktraces dumped to standard out during the normal test run of the infinispan-core module: > {noformat} > 2014-11-28 21:39:52,652 WARN [CacheTopologyControlCommand] (remote-thread-DistributedEntryRetrieverTest-NodeA-p610-t6) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=org.infinispan.iteration.DistributedEntryRetrieverTest, type=LEAVE, sender=DistributedEntryRetrieverTest-NodeC-12939, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=2} > java.lang.NullPointerException > at org.infinispan.topology.ClusterCacheStatus.updateRebalanceMembers(ClusterCacheStatus.java:307) > at org.infinispan.topology.ClusterCacheStatus.doLeave(ClusterCacheStatus.java:578) > at org.infinispan.topology.ClusterTopologyManagerImpl.handleLeave(ClusterTopologyManagerImpl.java:148) > at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:164) > at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:144) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$4.run(CommandAwareRpcDispatcher.java:278) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {noformat} > This is the unmodified testsuite, in current master {{33c5f85}}. It doesn't seem to cause actual test failures. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4949) Split brain: inconsistent data after merge

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4949?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4949: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1161214|https://bugzilla.redhat.com/show_bug.cgi?id=1161214] from ASSIGNED to POST > Split brain: inconsistent data after merge > ------------------------------------------ > > Key: ISPN-4949 > URL: https://issues.jboss.org/browse/ISPN-4949 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 7.0.0.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Alpha1 > > > 1) cluster A, B, C, D splits into 2 parts: > A, B (coord A) finds this out immediately and enters degraded mode with CH [A, B, C, D] > C, D (coord D) first detects that B is lost, gets view A, C, D and starts rebalance with CH [A, C, D]. Segment X is primary owned by C (it had backup on B but this got lost) > 2) D detects that A was lost as well, therefore enters degraded mode with CH [A, C, D] > 3) C inserts entry into X: all owners (only C) is present, therefore the modification is allowed > 4) cluster is merged and coordinator finds out that the max stable topology has CH [A, B, C, D] (it is the older of the two partitions' topologies, got from A, B) - logs 'No active or unavailable partitions, so all the partitions must be in degraded mode' (yes, all partitions are in degraded mode, but write has happened in the meantime) > 5) The old CH is broadcast in newest topology, no rebalance happens > 6) Inconsistency: read in X may miss the update -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5036) Develop tests for infinispan uber-jars

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5036?page=com.atlassian.jira.plugin.... ] Galder Zamarreño resolved ISPN-5036. ------------------------------------ Fix Version/s: 7.1.0.Beta1 Resolution: Done > Develop tests for infinispan uber-jars > -------------------------------------- > > Key: ISPN-5036 > URL: https://issues.jboss.org/browse/ISPN-5036 > Project: Infinispan > Issue Type: Task > Reporter: Tomas Sykora > Assignee: Tomas Sykora > Labels: test-devel > Fix For: 7.1.0.Beta1 > > > Tracking JIRA for our effort. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5031) Subject pretty print in logs

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5031?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5031: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.1.0.Beta1 Resolution: Done > Subject pretty print in logs > ---------------------------- > > Key: ISPN-5031 > URL: https://issues.jboss.org/browse/ISPN-5031 > Project: Infinispan > Issue Type: Enhancement > Components: Security > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Priority: Trivial > Fix For: 7.1.0.Beta1 > > > Implement pretty print for subject to have cleaner logs: > {noformat} > <ttarrant> vjuranek, we need a subject pretty printer which puts all principals on one line > <vjuranek> ttarrant: what is the use case? For more easy debugging? > <ttarrant> vjuranek, for cleaner logs > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5014) Remove "clean" goal trigger from the "prepare-package" phase of all/*

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-5014?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-5014: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove "clean" goal trigger from the "prepare-package" phase of all/* > --------------------------------------------------------------------- > > Key: ISPN-5014 > URL: https://issues.jboss.org/browse/ISPN-5014 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 7.0.2.Final > Reporter: Ion Savin > Assignee: Ion Savin > > To resolve ISPN-4939 a "clean" goal was attached to the "prepare-package" phase. > This fix is not appropriate in combination with ISPN-4942 (uberjars in OSGi) as needed resources are created before this phase ("initialize" is not appropriate as a clean will be triggered when the distribution module prepares the javadoc and before the uberjars are added to the distribution package). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4542) Programmatic configuration doesn't have loaders() method

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4542?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4542: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.1.0.Beta1 7.1.0.Final Resolution: Done > Programmatic configuration doesn't have loaders() method > -------------------------------------------------------- > > Key: ISPN-4542 > URL: https://issues.jboss.org/browse/ISPN-4542 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 6.0.0.Final > Reporter: Mikhail Dobrinin > Assignee: Vojtech Juranek > Priority: Minor > Fix For: 7.1.0.Beta1, 7.1.0.Final > > > The ConfigurationBuilder class does not actually have a {{loaders}} method. However, the documentation mentions it in a few places such as here -- http://infinispan.org/docs/6.0.x/user_guide/user_guide.html if you search for {{loaders()}} on the page. Also it's not clear to a user if it's possible to configure a custom cache loader programmatically because of this. I'm guessing it's not actually possible. That makes it hard to write tests with a mocked cacheloader. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5028) BaseEntryRetrieverEvictionTest.testExpiredEntryNotReturned random failures

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5028?page=com.atlassian.jira.plugin.... ] Galder Zamarreño resolved ISPN-5028. ------------------------------------ Fix Version/s: 7.1.0.Beta1 Resolution: Done > BaseEntryRetrieverEvictionTest.testExpiredEntryNotReturned random failures > -------------------------------------------------------------------------- > > Key: ISPN-5028 > URL: https://issues.jboss.org/browse/ISPN-5028 > Project: Infinispan > Issue Type: Bug > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.1.0.Beta1 > > > {noformat} > 01:40:35,536 ERROR (testng-LocalEntryRetrieverEvictionTest:) [UnitTestTestNGListener] Test testExpiredEntryNotReturned(org.infinispan.iteration.LocalEntryRetrieverEvictionTest) failed. > java.lang.AssertionError: expected:<{0=0 stay in cache, 1=1 stay in cache, 2=2 stay in cache, 3=3 stay in cache, 4=4 stay in cache}> but was:<{0=0 stay in cache, 1=1 stay in cache, 2=2 stay in cache, expired=this shouldn't be returned, 3=3 stay in cache, 4=4 stay in cache}> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88) > at org.infinispan.iteration.BaseEntryRetrieverEvictionTest.testExpiredEntryNotReturned(BaseEntryRetrieverEvictionTest.java:56) > {noformat} > The problem is that the test measures the time expired since _before_ inserting the value, it should measure the time since _after_ inserting the value (actually {{Thread.sleep()}} would suffice). Computing the time since before the insert is only useful when check that the entry didn't expire too soon. > I have seen a failure in {{LocalEntryRetrieverEvictionTest}} on my machine, but only failures in {{ReplicatedEntryRetrieverEvictionTest}} and {{DistributedEntryRetrieverEvictionTest}} in CI: > http://ci.infinispan.org/viewLog.html?buildId=14438&tab=buildResultsDiv&b... > http://ci.infinispan.org/viewLog.html?buildId=14568&tab=buildResultsDiv&b... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5035) DeltaAware support for conditional operations

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5035?page=com.atlassian.jira.plugin.... ] Radim Vansa edited comment on ISPN-5035 at 12/2/14 4:07 AM: ------------------------------------------------------------ I've realized that it can be done using DeltaAware. However, the return value is always the old value, which is quite limiting and can use more bandwidth than necessary, and more complicated conditions require double verification of the return value (to check if the operation could be done on the remote side). was (Author: rvansa): I've realized that it can be done using DeltaAware. However, the return value is always the old value, which is quite limiting and can use more bandwidth than necessary. > DeltaAware support for conditional operations > --------------------------------------------- > > Key: ISPN-5035 > URL: https://issues.jboss.org/browse/ISPN-5035 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Radim Vansa > > Current delta-aware approach is implemented only in PutKeyValueCommand and ApplyDeltaCommand. This implementation does not allow to execute conditional delta-aware commands - or rather it does not allow to return any kind of value (the condition itself can be implemented inside the delta). > One use-case when this would be required is equivalent of AtomicLong.getAndIncrement(). Currently we can implement this using > {code} > Long previous; > do { > previous = cache.get(key); > } while (cache.replace(key, previous, previous + 1); > {code} > which requires at least two RPCs. With more generic interface, such as JCache's EntryProcessor this could be implemented using single RPC. > (so, this JIRA is basically a request to native support for EntryProcessor) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5030) NPE during node rebalance after a leave

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5030?page=com.atlassian.jira.plugin.... ] Galder Zamarreño resolved ISPN-5030. ------------------------------------ Fix Version/s: 7.1.0.Beta1 Resolution: Done > NPE during node rebalance after a leave > --------------------------------------- > > Key: ISPN-5030 > URL: https://issues.jboss.org/browse/ISPN-5030 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.0.Alpha1 > Reporter: Sanne Grinovero > Assignee: Dan Berindei > Priority: Minor > Fix For: 7.1.0.Beta1 > > > I'm seeing stacktraces dumped to standard out during the normal test run of the infinispan-core module: > {noformat} > 2014-11-28 21:39:52,652 WARN [CacheTopologyControlCommand] (remote-thread-DistributedEntryRetrieverTest-NodeA-p610-t6) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=org.infinispan.iteration.DistributedEntryRetrieverTest, type=LEAVE, sender=DistributedEntryRetrieverTest-NodeC-12939, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=2} > java.lang.NullPointerException > at org.infinispan.topology.ClusterCacheStatus.updateRebalanceMembers(ClusterCacheStatus.java:307) > at org.infinispan.topology.ClusterCacheStatus.doLeave(ClusterCacheStatus.java:578) > at org.infinispan.topology.ClusterTopologyManagerImpl.handleLeave(ClusterTopologyManagerImpl.java:148) > at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:164) > at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:144) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$4.run(CommandAwareRpcDispatcher.java:278) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {noformat} > This is the unmodified testsuite, in current master {{33c5f85}}. It doesn't seem to cause actual test failures. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5035) DeltaAware support for conditional operations

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5035?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-5035: ----------------------------------- I've realized that it can be done using DeltaAware. However, the return value is always the old value, which is quite limiting and can use more bandwidth than necessary. > DeltaAware support for conditional operations > --------------------------------------------- > > Key: ISPN-5035 > URL: https://issues.jboss.org/browse/ISPN-5035 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Radim Vansa > > Current delta-aware approach is implemented only in PutKeyValueCommand and ApplyDeltaCommand. This implementation does not allow to execute conditional delta-aware commands - or rather it does not allow to return any kind of value (the condition itself can be implemented inside the delta). > One use-case when this would be required is equivalent of AtomicLong.getAndIncrement(). Currently we can implement this using > {code} > Long previous; > do { > previous = cache.get(key); > } while (cache.replace(key, previous, previous + 1); > {code} > which requires at least two RPCs. With more generic interface, such as JCache's EntryProcessor this could be implemented using single RPC. > (so, this JIRA is basically a request to native support for EntryProcessor) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 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 December 2014