May 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3098) Check if TOA is working properly when a node crashes

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3098: --------------------------------- Summary: Check if TOA is working properly when a node crashes Key: ISPN-3098 URL: https://issues.jboss.org/browse/ISPN-3098 Project: Infinispan Issue Type: Bug Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 5.3.0.Final Check if TOA is working properly when a node crashes -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3097) Improve total order test suite

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3097: --------------------------------- Summary: Improve total order test suite Key: ISPN-3097 URL: https://issues.jboss.org/browse/ISPN-3097 Project: Infinispan Issue Type: Enhancement Components: Transactions Affects Versions: 5.3.0.Beta1 Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 5.3.0.Final with async configurations, the total order test suite can make the assertions before the transaction reach all the nodes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-484) Querying over HotRod

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-484?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-484: ------------------------------- Fix Version/s: 6.0.0.Beta1 (was: 6.0.0.Beta2) > Querying over HotRod > -------------------- > > Key: ISPN-484 > URL: https://issues.jboss.org/browse/ISPN-484 > Project: Infinispan > Issue Type: Feature Request > Components: Querying, Remote protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 6.0.0.Beta1, 6.0.0.Final > > > Investigate how to allow Hot Rod servers to be queries, particularly since server stores key/values in serialized byte arrays. > Also, look into how to improve the protocol to potentially allow remote querying. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2342) The x-site implementation needs an inter-site state transfer mechanism

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2342?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2342: -------------------------------- Fix Version/s: 6.0.0.Beta1 (was: 6.0.0.Beta2) > The x-site implementation needs an inter-site state transfer mechanism > ---------------------------------------------------------------------- > > Key: ISPN-2342 > URL: https://issues.jboss.org/browse/ISPN-2342 > Project: Infinispan > Issue Type: Feature Request > Components: Cross-Site Replication > Reporter: Erik Salter > Assignee: Erik Salter > Fix For: 6.0.0.Beta1, 6.0.0.Final > > > To bring up a new site or recover a failed site, I need an inter-site state transfer mechanism for synchronizing keys. > Note that initially, this should a manual process that is invoked on one site to one of its configured backups. > This should be based on the non-blocking state transfer mechanism for consistency. > The pseudo-design may look similar to the following: > - Manually invokable, background thread > - Since the bridge end is open, there are writes happening to keys. Keep track of the puts/removes on the main data owner. > - Iterate through the key set. > - If the key has already been modified since the process started, discard. > - Else synchronously write the key value in a TX context -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3095) Cache.replace() succeeds on originator but fails randomly on remote owners during state transfer in DIST mode with pessimistic locking

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3095?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3095: -------------------------------- Description: TxDistributionInterceptor.ignorePreviousValueOnBackup() should return true to force backups to apply the update (unless write skew check is enabled). Not doing so might lead to a situation where the key is not available locally yet (state transfer in progress) and will be fetched remotely from another owner that has already executed the conditional command. The previous value check would fail then. The check adds little value on backup owners so it should not be done at all. (was: TxDistributionInterceptor.ignorePreviousValueOnBackup() should return true to force backup to apply the update (unless write skew check is enabled).) > Cache.replace() succeeds on originator but fails randomly on remote owners during state transfer in DIST mode with pessimistic locking > -------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3095 > URL: https://issues.jboss.org/browse/ISPN-3095 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Cache > Affects Versions: 5.2.5.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.3.0.Beta2, 5.3.0.Final > > > TxDistributionInterceptor.ignorePreviousValueOnBackup() should return true to force backups to apply the update (unless write skew check is enabled). Not doing so might lead to a situation where the key is not available locally yet (state transfer in progress) and will be fetched remotely from another owner that has already executed the conditional command. The previous value check would fail then. The check adds little value on backup owners so it should not be done at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3095) Cache.replace() succeeds on originator but fails randomly on remote owners during state transfer in DIST mode with pessimistic locking

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3095?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3095: -------------------------------- Description: TxDistributionInterceptor.ignorePreviousValueOnBackup() should return true to force backup to apply the update (unless write skew check is enabled). (was: TxDistributionInterceptor.ignorePreviousValueOnBackup() should return true if pessimistic locking is enabled.) > Cache.replace() succeeds on originator but fails randomly on remote owners during state transfer in DIST mode with pessimistic locking > -------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3095 > URL: https://issues.jboss.org/browse/ISPN-3095 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Cache > Affects Versions: 5.2.5.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.3.0.Beta2, 5.3.0.Final > > > TxDistributionInterceptor.ignorePreviousValueOnBackup() should return true to force backup to apply the update (unless write skew check is enabled). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3055) Unreleased lock after node restart

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3055?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3055: -------------------------------- Labels: 5.2.x (was: ) > Unreleased lock after node restart > ---------------------------------- > > Key: ISPN-3055 > URL: https://issues.jboss.org/browse/ISPN-3055 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.1.Final > Environment: Debian Squeeze Amd 64, JDK 1.6.0_32 > Reporter: Deyan Pandulev > Assignee: Pedro Ruivo > Labels: 5.2.x > Fix For: 5.3.0.Beta2, 5.3.0.Final > > Attachments: SimpleClusterRead.java, SimpleClusterWriter.java, simple_cluster_node1.xml, simple_cluster_node2.xml > > > Using dummy transaction manager I was able to produce locks that are not released. The same behavior can be reproduced with Glassfish AS 3.1.1 using its own TM. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3055) Unreleased lock after node restart

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3055?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3055: -------------------------------- Fix Version/s: 5.3.0.Beta2 5.3.0.Final (was: 6.0.0.Final) (was: 6.0.0.Alpha1) > Unreleased lock after node restart > ---------------------------------- > > Key: ISPN-3055 > URL: https://issues.jboss.org/browse/ISPN-3055 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.1.Final > Environment: Debian Squeeze Amd 64, JDK 1.6.0_32 > Reporter: Deyan Pandulev > Assignee: Pedro Ruivo > Fix For: 5.3.0.Beta2, 5.3.0.Final > > Attachments: SimpleClusterRead.java, SimpleClusterWriter.java, simple_cluster_node1.xml, simple_cluster_node2.xml > > > Using dummy transaction manager I was able to produce locks that are not released. The same behavior can be reproduced with Glassfish AS 3.1.1 using its own TM. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2995) AtomicHashMap locking issue [optimistic]

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2995?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-2995: ----------------------------------- I though that ApplyDeltaCommand was used in both cases AtomicHashMap and FineGrainedAtomicHashMap :) the first solution I want to try is that one: change the hashCode() to return the hashCode() from the parent key and see if it works. btw, the composite keys are kept in the same node as the parent key (at least, the DeltaAwareCacheEntry.commit() is only invoked in the node in which the parent is located). > AtomicHashMap locking issue [optimistic] > ---------------------------------------- > > Key: ISPN-2995 > URL: https://issues.jboss.org/browse/ISPN-2995 > Project: Infinispan > Issue Type: Bug > Components: Fine-grained API > Affects Versions: 5.3.0.Alpha1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: atomic_map, locking > Fix For: 5.3.0.Beta2 > > > In OptimisticLockingInterceptor, we are collecting the composite keys from ApplyDeltaCommand is the key belongs to the node: > {code} > case ApplyDeltaCommand.COMMAND_ID: > ApplyDeltaCommand command = (ApplyDeltaCommand) wc; > if (cdl.localNodeIsOwner(command.getKey())) { > Object[] compositeKeys = command.getCompositeKeys(); > set.addAll(Arrays.asList(compositeKeys)); > } > break; > {code} > However, when we are going to acquire the lock in the node if it is the primary owner: > {code} > protected final void lockAndRegisterBackupLock(TxInvocationContext ctx, Object key, long lockTimeout, boolean skipLocking) throws InterruptedException { > if (cdl.localNodeIsPrimaryOwner(key)) { > lockKeyAndCheckOwnership(ctx, key, lockTimeout, skipLocking); > } else if (cdl.localNodeIsOwner(key)) { > ctx.getCacheTransaction().addBackupLockForKey(key); > } > } > {code} > The CompositeKey should always acquire the lock. > This is probably a bug. Add an unit test to verify that locking works as expected for AtomicHashMap. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3096) ComponentRegistryTest.testConcurrentLookupSameComponentRegistry intermittent failure

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3096?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-3096. --------------------------------- Resolution: Done > ComponentRegistryTest.testConcurrentLookupSameComponentRegistry intermittent failure > ------------------------------------------------------------------------------------ > > Key: ISPN-3096 > URL: https://issues.jboss.org/browse/ISPN-3096 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 5.3.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 5.3.0.Beta2 > > > The test checks that when the injection method is blocked, calling {{ComponentRegistry.getComponent(...)}} in another thread will return null. > However, if the thread doing the check is delayed for a long time (longer than 1s), the check will fail because the injection thread will have been unblocked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2013