December 2015 - infinispan-issues

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5885?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5885: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3874 > 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.Final, 8.0.3.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, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPRK-3) Infinispan Query DSL from my Spark application

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPRK-3?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño updated ISPRK-3: --------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Infinispan Query DSL from my Spark application > ---------------------------------------------- > > Key: ISPRK-3 > URL: https://issues.jboss.org/browse/ISPRK-3 > Project: Infinispan Spark > Issue Type: Feature Request > Components: RDD > Affects Versions: 0.1 > Reporter: Pedro Zapata > Assignee: Gustavo Fernandes > Labels: jdg7 > Fix For: 0.2 > > > As an application developer, I want to use Infinispan Query DSL from my Spark application written in Java. > Once Java is supported, Scala can be supported as well, no extra effort required -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5623) Retried prepare commands do not wait for backup locks

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5623?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5623: ------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/3873 (was: https://github.com/infinispan/infinispan/pull/3863) > Retried prepare commands do not wait for backup locks > ----------------------------------------------------- > > Key: ISPN-5623 > URL: https://issues.jboss.org/browse/ISPN-5623 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final, 8.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Fix For: 8.1.0.Final > > Attachments: OptimisticPrimaryOwnerCrashDuringPrepareTest.java > > > When the primary owner crashes during prepare, the prepare command is retried on the new primary owner. But because the transaction topology id stays the same, the new primary owner does not check for backup locks owned by other transactions from the previous topology. > That makes it possible for the retried prepare command to lock a key that was already locked by another transaction on the primary owner. > This wasn't a problem before the ISPN-4546 fix, because a primary owner crash would have forced the transaction to roll back. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6003) Reduce number of allocations

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6003?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6003: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from POST to MODIFIED > Reduce number of allocations > ---------------------------- > > Key: ISPN-6003 > URL: https://issues.jboss.org/browse/ISPN-6003 > Project: Infinispan > Issue Type: Task > Components: Core, Server > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: performance > Fix For: 8.1.0.Final > > > Profiling revealed some allocations that are easy to remove: > * The HotRod operations factory stores a list of flags in a thread-local. The thread-local can be removed, and the flags can be stored in an {{int}}. > * JGroupsTransport copies the list of members to check if a broadcast should be sent as a unicast, and the copy is then discarded. > * ExtendedByteBuf could use {{Array.empty}} instead of {{Array[Byte]()}}. > * DecoratedCache could avoid calling {{Arrays.asList()}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6002) Cache log.isTraceEnabled() as much as possible

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6002?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6002: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from POST to MODIFIED > Cache log.isTraceEnabled() as much as possible > ---------------------------------------------- > > Key: ISPN-6002 > URL: https://issues.jboss.org/browse/ISPN-6002 > Project: Infinispan > Issue Type: Task > Components: Core, Server > Affects Versions: 8.1.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: performance > Fix For: 8.1.0.Final > > > With log4j2 it's not that big of a problem, but there are still environments where this could make a difference (i.e. in the server). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5860) ComponentRegistry should cache the VersionGenerator in a field

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5860?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5860: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from POST to MODIFIED > ComponentRegistry should cache the VersionGenerator in a field > -------------------------------------------------------------- > > Key: ISPN-5860 > URL: https://issues.jboss.org/browse/ISPN-5860 > Project: Infinispan > Issue Type: Bug > Components: Core, Server > Affects Versions: 8.0.1.Final, 8.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Alpha2, 8.1.0.Final > > > The {{VersionGenerator}} component is read by the HotRod server for each write operation, and we can optimize it by caching the component in a field. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5859) HotRod server should not use privileged actions for common stuff

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5859?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5859: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from POST to MODIFIED > HotRod server should not use privileged actions for common stuff > ---------------------------------------------------------------- > > Key: ISPN-5859 > URL: https://issues.jboss.org/browse/ISPN-5859 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.0.1.Final, 8.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Alpha2, 8.1.0.Final > > > The HotRod server uses privileged actions to perform operations that are needed for each request, like reading the cache mode to decide what kind (if any) topology update to send to the client. Since privileged actions use thread-locals, we should try to avoid them. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5858) ValueMatcher and AvailabilityMode should have externalizers

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5858?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5858: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from POST to MODIFIED > ValueMatcher and AvailabilityMode should have externalizers > ----------------------------------------------------------- > > Key: ISPN-5858 > URL: https://issues.jboss.org/browse/ISPN-5858 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.0.1.Final, 8.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Alpha2, 8.1.0.CR1 > > > The default enum serialization is pretty bad, it writes both the enum name and value name as strings. > {{ValueMatcher}} is needed in each write command, so we should optimize it. > {{AvailabilityMode}} doesn't matter that much, except when the coordinator changes, and the new coordinator has to retrieve the status of all the caches on all the nodes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5857) HotRod client should use the consistent hash in replicated mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5857?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5857: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from POST to MODIFIED > HotRod client should use the consistent hash in replicated mode > --------------------------------------------------------------- > > Key: ISPN-5857 > URL: https://issues.jboss.org/browse/ISPN-5857 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.0.1.Final, 8.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: hotrod > Fix For: 8.1.0.Alpha2, 8.1.0.Final > > > The HotRod server assumes that in replicated mode the server accessed by the client doesn't matter, so it doesn't send a consistent hash in the topology updates. > However, since replicated mode is now implemented on top of distributed mode, hitting the primary owner or another node makes a big difference. We should change the server to send the consistent hash for replicated caches as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5922) Recovery MBean showInDoubtTransactions fails because of missing RecoveryManager

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5922?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5922: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.1.0.Final Resolution: Done > Recovery MBean showInDoubtTransactions fails because of missing RecoveryManager > -------------------------------------------------------------------------------- > > Key: ISPN-5922 > URL: https://issues.jboss.org/browse/ISPN-5922 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management, Transactions > Reporter: Tristan Tarrant > Assignee: Pedro Ruivo > Labels: jdg6 > Fix For: 8.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2015