November 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5909) Speed up StateTransferLargeObjectTest

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5909?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5909: -------------------------------- Fix Version/s: 8.1.0.Beta2 (was: 8.1.0.Beta1) > Speed up StateTransferLargeObjectTest > ------------------------------------- > > Key: ISPN-5909 > URL: https://issues.jboss.org/browse/ISPN-5909 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Core > Affects Versions: 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Beta2 > > > The test queries the caches twice at the end, once to check the value types and then again to check the actual values. The second check should be sufficient. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5908) Stop applying state when a cache is stopping

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5908?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5908: -------------------------------- Fix Version/s: 8.1.0.Beta2 (was: 8.1.0.Beta1) > Stop applying state when a cache is stopping > -------------------------------------------- > > Key: ISPN-5908 > URL: https://issues.jboss.org/browse/ISPN-5908 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Beta2 > > > Trying to apply state after the cache was stopped only fills the logs with error messages, and slows down the test suite (especially with TRACE enabled). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5907) Clear the cache stores between tests

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5907?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5907: -------------------------------- Fix Version/s: 8.1.0.Beta2 (was: 8.1.0.Beta1) > Clear the cache stores between tests > ------------------------------------ > > Key: ISPN-5907 > URL: https://issues.jboss.org/browse/ISPN-5907 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Core > Affects Versions: 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Beta2 > > > The fact that entries accumulate in the cache store slows down StateTransferDistCacheLoaderSharedTest. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5892) XML configuration should include number of segments for replicated caches

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5892?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5892: -------------------------------- Fix Version/s: 8.1.0.Beta2 (was: 8.1.0.Beta1) > XML configuration should include number of segments for replicated caches > ------------------------------------------------------------------------- > > Key: ISPN-5892 > URL: https://issues.jboss.org/browse/ISPN-5892 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 8.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Beta2 > > > The primary owner of a key is determined based on the segment, so for remote caches it's good to increase the number of segments when there are many nodes in the cluster. Groups configuration may be useful as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5885) NonTotalOrderPerCacheInvocationHandlerImpl should release locks

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5885?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5885: -------------------------------- Fix Version/s: 8.1.0.Beta2 (was: 8.1.0.Beta1) > NonTotalOrderPerCacheInvocationHandlerImpl should release locks > --------------------------------------------------------------- > > Key: ISPN-5885 > URL: https://issues.jboss.org/browse/ISPN-5885 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.0.1.Final, 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Labels: testsuite_stability > Fix For: 8.1.0.Beta2, 8.0.2.Final > > Attachments: ThreeNodesReplicatedSplitAndMergeTest.log.zip > > > Traditionally, the locking interceptor is the one that releases key locks. But after the ISPN-2849 fix, the locks are acquired by {{NonTotalOrderPerCacheInvocationHandlerImpl}} before the interceptor chain even starts executing. If there's an exception between the lock acquisition and the locking interceptor, the locks will never be released. > There is currently one situation where I have reproduced this, in {{ThreeNodesReplicatedSplitAndMergeTest.testSplitAndMerge0}}. Node {{C}} is split in a partition by itself, and then it is merged with the {{AB}} partition. After the merge, JGroups sometimes replays the put command broadcasted in the {{AB}} partition on {{C}}. {{C}}'s cache is still in degraded mode, so the write fails, but its lock is never released. > {noformat} > 12:53:41,088 INFO (testng-ThreeNodesReplicatedSplitAndMergeTest:[]) [JGroupsTransport] ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[NodeA-44116|10] (3) [NodeA-44116, NodeB-58097, NodeC-3920], 2 subgroups: [NodeA-44116|8] (2) [NodeA-44116, NodeB-58097], [NodeC-3920|9] (1) [NodeC-3920] > 12:53:42,143 TRACE (OOB-1,NodeC-3920:[]) [GlobalInboundInvocationHandler] Attempting to execute CacheRpcCommand: SingleRpcCommand{cacheName='___defaultcache', command=PutKeyValueCommand{key=MagicKey#null{ced8b1f2@NodeC-3920/9}, value=v22, flags=null, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null}, successful=true}} [sender=NodeB-58097] > 12:53:42,144 TRACE (OOB-1,NodeC-3920:[]) [DefaultLockManager] Lock key=MagicKey#null{ced8b1f2@NodeC-3920/9} for owner=CommandUUID{address=NodeB-58097, id=48899}. timeout=10000 (MILLISECONDS) > 12:53:42,144 TRACE (OOB-1,NodeC-3920:[]) [InfinispanLock] LockPlaceHolder{lockState=ACQUIRED, owner=CommandUUID{address=NodeB-58097, id=48899}} successfully acquired the lock. > 12:53:42,144 TRACE (remote-thread-NodeC-p36993-t5:[]) [InvocationContextInterceptor] Invoked with command PutKeyValueCommand{key=MagicKey#null{ced8b1f2@NodeC-3920/9}, value=v22, flags=null, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null}, successful=true} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@67bb1b50] > 12:53:42,144 TRACE (remote-thread-NodeC-p36993-t5:[]) [PartitionHandlingManagerImpl] Checking availability for key=MagicKey#null{ced8b1f2@NodeC-3920/9}, status=DEGRADED_MODE > 12:53:42,144 TRACE (remote-thread-NodeC-p36993-t5:[]) [PartitionHandlingManagerImpl] Partition is in DEGRADED_MODE mode, access is not allowed for key MagicKey#null{ced8b1f2@NodeC-3920/9} > 12:53:42,144 ERROR (remote-thread-NodeC-p36993-t5:[]) [InvocationContextInterceptor] ISPN000136: Execution error > org.infinispan.partitionhandling.AvailabilityException: ISPN000306: Key 'MagicKey#null{ced8b1f2@NodeC-3920/9}' is not available. Not all owners are in this partition > 12:53:42,144 WARN (remote-thread-NodeC-p36993-t5:[]) [NonTotalOrderPerCacheInboundInvocationHandler] ISPN000071: Caught exception when handling command SingleRpcCommand{cacheName='___defaultcache', command=PutKeyValueCommand{key=MagicKey#null{ced8b1f2@NodeC-3920/9}, value=v22, flags=null, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null}, successful=true}} > {noformat} > Of course, knowing that {{C}} is in degraded mode, perhaps we should not try to acquire the lock at all. But then we'd move even more responsibility into the invocation handler. There's also the possibility of having exceptions caused by -topology changes or- programming errors, so a solution that handles any exception would be preferable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5883) Node can apply new topology after sending status response

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5883?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5883: -------------------------------- Fix Version/s: 8.1.0.Beta2 (was: 8.1.0.Beta1) > Node can apply new topology after sending status response > --------------------------------------------------------- > > Key: ISPN-5883 > URL: https://issues.jboss.org/browse/ISPN-5883 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 8.0.1.Final, 7.2.5.Final, 8.1.0.Alpha2 > Reporter: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 8.1.0.Beta2 > > > {{LocalTopologyManagerImpl}} is responsible for sending the {{ClusterTopologyControlCommand(GET_STATUS)}} response, and when it sends the response it doesn't check the current view id against the new coordinator's view id. If the old coordinator already sent a topology update before the merge, that topology update might be processed after sending the status response. The new coordinator will send a topology update with a topology id of {{max(status response topology ids) + 1}}. The node will then process the topology update from the old coordinator, but it will ignore the topology update from the new coordinator with the same topology id. > This is extra common in the partition handling tests, e.g. {{BasePessimisticTxPartitionAndMergeTest}} subclasses, because the test "injects" the JGroups view on each node serially, and often the 4th node sends the status response before it gets the new view. > {noformat} > 22:16:37,776 DEBUG (remote-thread-NodeD-p26-t6:[]) [LocalTopologyManagerImpl] Sending cluster status response for view 10 > // Topology from NodeC > 22:16:37,778 DEBUG (transport-thread-NodeD-p28-t2:[]) [LocalTopologyManagerImpl] Updating local topology for cache pes-cache: CacheTopology{id=8, rebalanceId=3, currentCH=DefaultConsistentHash{ns=60, owners = (4)[NodeA-37631: 15+15, NodeB-47846: 15+15, NodeC-46467: 15+15, NodeD-30486: 15+15]}, pendingCH=null, unionCH=null, actualMembers=[NodeC-46467, NodeD-30486]} > // Later, topology from NodeA > 22:16:37,827 DEBUG (transport-thread-NodeD-p28-t1:[]) [LocalTopologyManagerImpl] Ignoring late consistent hash update for cache pes-cache, current topology is 8: CacheTopology{id=8, rebalanceId=3, currentCH=DefaultConsistentHash{ns=60, owners = (4)[NodeA-37631: 15+15, NodeB-47846: 15+15, NodeC-46467: 15+15, NodeD-30486: 15+15]}, pendingCH=null, unionCH=null, actualMembers=[NodeA-37631, NodeB-47846, NodeC-46467, NodeD-30486]} > {noformat} > As a solution, we can delay sending the status response until we have the same view as the coordinator (or a later one). We already check that the sender is the current coordinator before applying a topology update, so this will guarantee that the we don't apply other topology updates from the old coordinator. Since the status request is only sent after the new view was installed, this will not introduce any delays in the vast majority of cases. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5889) Merge views not dealt with in Hot Rod server

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5889?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5889: -------------------------------- Fix Version/s: 8.1.0.Beta2 (was: 8.1.0.Beta1) > Merge views not dealt with in Hot Rod server > -------------------------------------------- > > Key: ISPN-5889 > URL: https://issues.jboss.org/browse/ISPN-5889 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.0.1.Final, 8.1.0.Alpha2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.1.0.Beta2, 8.1.0.Final > > > Hot Rod server does not deal with merge views, so when members return back to the cluster, the view is not updated. The Hot Rod server view change listener currently only deals with nodes leaving or crashing. This problem is not a big one since it just means that until the next view change happens, clients will work with a reduced view, working in a suboptimal way, but it won't have correctness impact. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5881) AbstractControlledLocalTopologyManager.setCacheRebalancingEnabled() loops infinitely

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5881?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5881: -------------------------------- Fix Version/s: 8.1.0.Beta2 (was: 8.1.0.Beta1) > AbstractControlledLocalTopologyManager.setCacheRebalancingEnabled() loops infinitely > ------------------------------------------------------------------------------------ > > Key: ISPN-5881 > URL: https://issues.jboss.org/browse/ISPN-5881 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Minor > Fix For: 8.1.0.Beta2 > > > the method is recursively invoked and looping forever. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5878) Deprecate MurmurHash2 and remove MurmurHash2Compat

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5878?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5878: -------------------------------- Fix Version/s: 8.1.0.Beta2 (was: 8.1.0.Beta1) > Deprecate MurmurHash2 and remove MurmurHash2Compat > -------------------------------------------------- > > Key: ISPN-5878 > URL: https://issues.jboss.org/browse/ISPN-5878 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Beta2, 8.1.0.Final > > > {{MurmurHash3}} was introduced in version 5.0, obsoleting {{MurmurHash2}}. > {{MurmurHash2Compat}} was only introduced to preserve compatibility with the pre-4.2.1 {{MurmurHash2}} implementation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5806) Add transaction support for Functional API

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5806?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5806: -------------------------------- Fix Version/s: 8.1.0.Beta2 (was: 8.1.0.Beta1) > Add transaction support for Functional API > ------------------------------------------ > > Key: ISPN-5806 > URL: https://issues.jboss.org/browse/ISPN-5806 > Project: Infinispan > Issue Type: Sub-task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.1.0.Beta2, 8.1.0.Final > > > A local cache with batching enabled produces this: > {code:java} > java.lang.IllegalArgumentException: Cannot create a transactional > context without a valid Transaction instance. > at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:69) > at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:63) > at org.infinispan.functional.impl.ReadWriteMapImpl.eval(ReadWriteMapImpl.java:56) > at org.infinispan.lucene.impl.FileListOperations.addFileName(FileListOperations.java:60) > (<-- experimental uncommitted code here) > {code} > For single operations that carry no transaction context, don't try to start a transaction and create a transactional context. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 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 2015