October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3645) StateTransferLargeObjectTest hangs randomly

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3645?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3645: ------------------------------ Labels: jdg620_dm (was: ) > StateTransferLargeObjectTest hangs randomly > ------------------------------------------- > > Key: ISPN-3645 > URL: https://issues.jboss.org/browse/ISPN-3645 > Project: Infinispan > Issue Type: Bug > Components: RPC > Affects Versions: 6.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: jdg620_dm > Fix For: 6.0.0.CR2 > > Attachments: stlot.stack > > > StateTransferLargeObject sometimes hangs in the second part of the test, when it checks that all the nodes in the cluster can read the inserted values. I was able to make it hang reliably when run separately, by increasing the number of keys from 1000 to 5000. > The cause is probably JGRP-1675, as many OOB threads appear to be stuck in FlowControl.decrementIfEnoughCredits. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3315) Retry remote get after topology change if all the targets are no longer owners

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3315?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3315: ------------------------------ Labels: jdg620_dm (was: ) > Retry remote get after topology change if all the targets are no longer owners > ------------------------------------------------------------------------------ > > Key: ISPN-3315 > URL: https://issues.jboss.org/browse/ISPN-3315 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.3.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: jdg620_dm > > It's possible for a remote get to reach its intended targets only after they are no longer owners, and they don't have the key anymore. If that happens, instead of returning a {{null}} value, the originator should retry on the new owners (possibly in a loop). > Note that this is different from all the owners leaving the cluster at the same time: in that case retrying on the new owners wouldn't make a difference, because data would be lost anyway. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3585) The CDI module dependency on core and hotrod client should be optional

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3585?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3585: ------------------------------ Labels: jdg620_dm (was: ) > The CDI module dependency on core and hotrod client should be optional > ---------------------------------------------------------------------- > > Key: ISPN-3585 > URL: https://issues.jboss.org/browse/ISPN-3585 > Project: Infinispan > Issue Type: Bug > Components: CDI integration > Affects Versions: 6.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Critical > Labels: jdg620_dm > Fix For: 6.0.0.Final > > > The CDI module Extension has a hard dependency on both core and remote. We need to refactor the code so that the two dependencies are optional and features are enabled only when found in classpath -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3667) Existing cacher stores should be generic types

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3667?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3667: ------------------------------------- As per [~galderz]'s suggestion: http://infinispan.markmail.org/thread/ikfl2j5m33jymvmw > Existing cacher stores should be generic types > ---------------------------------------------- > > Key: ISPN-3667 > URL: https://issues.jboss.org/browse/ISPN-3667 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.CR1 > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 6.0.0.CR2 > > -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3667) Existing cacher stores should be generic types

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3667: ----------------------------------- Summary: Existing cacher stores should be generic types Key: ISPN-3667 URL: https://issues.jboss.org/browse/ISPN-3667 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 6.0.0.CR1 Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 6.0.0.CR2 -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3633: ------------------------------ Labels: jdg620_dm (was: ) > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: jdg620_dm > Fix For: 6.0.0.Final > > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3556) When LockControlCommand fails on an owner, the rollback command is not sent

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3556?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3556: ------------------------------ Labels: jdg26_dm (was: ) > When LockControlCommand fails on an owner, the rollback command is not sent > --------------------------------------------------------------------------- > > Key: ISPN-3556 > URL: https://issues.jboss.org/browse/ISPN-3556 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency > Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: jdg26_dm > > If a transaction starts with a {{lock()}} operation and the lock fails on one of the owners (e.g. because of a {{SuspectException}}), the rollback command should still be sent to all the live owners. > However, because a locked key is only registered in the {{affectedKeys}} collection after a successful lock operation (in {{PessimisticLockingInterceptor.acquireRemoteIfNeeded()}}, the rollback command is not sent to any owners. > This is in a pessimistic cache. However, looking at the {{OptimisticLockingInterceptor.acquireAllLocks()}} code I think I see a similar problem: it's possible that a key is locked, but the write skew check fails and the key is not added to the {{affectedKeys}} collection. We should always register the key first and attempt to lock it after. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3556) When LockControlCommand fails on an owner, the rollback command is not sent

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3556?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3556: ------------------------------ Labels: jdg620_dm (was: jdg26_dm) > When LockControlCommand fails on an owner, the rollback command is not sent > --------------------------------------------------------------------------- > > Key: ISPN-3556 > URL: https://issues.jboss.org/browse/ISPN-3556 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency > Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: jdg620_dm > > If a transaction starts with a {{lock()}} operation and the lock fails on one of the owners (e.g. because of a {{SuspectException}}), the rollback command should still be sent to all the live owners. > However, because a locked key is only registered in the {{affectedKeys}} collection after a successful lock operation (in {{PessimisticLockingInterceptor.acquireRemoteIfNeeded()}}, the rollback command is not sent to any owners. > This is in a pessimistic cache. However, looking at the {{OptimisticLockingInterceptor.acquireAllLocks()}} code I think I see a similar problem: it's possible that a key is locked, but the write skew check fails and the key is not added to the {{affectedKeys}} collection. We should always register the key first and attempt to lock it after. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2516) org.infinispan.distribution.topologyaware.TopologyAwareStateTransferTest.testNodeDown3 fails randomly

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-2516?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-2516: ------------------------------ Labels: jdg620_dm testsuite_stability (was: testsuite_stability) > org.infinispan.distribution.topologyaware.TopologyAwareStateTransferTest.testNodeDown3 fails randomly > ----------------------------------------------------------------------------------------------------- > > Key: ISPN-2516 > URL: https://issues.jboss.org/browse/ISPN-2516 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Anna Manukyan > Assignee: Dan Berindei > Labels: jdg620_dm, testsuite_stability > Fix For: 5.3.0.Final > > Attachments: infinispan.log.zip > > > The test fails randomly on Rhel6x64 IBM7JDk (for JDG testsuite). > You can find the log here: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > The bug doesn't appear when the test is run separately. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3048) Eviction needs to be transactional

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3048?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3048: ------------------------------ Labels: jdg620_dm (was: ) > Eviction needs to be transactional > ---------------------------------- > > Key: ISPN-3048 > URL: https://issues.jboss.org/browse/ISPN-3048 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.3.0.Alpha1 > Reporter: Paul Ferraro > Assignee: William Burns > Priority: Critical > Labels: jdg620_dm > > Currently, Infinispan eviction is non-transactional. This makes Infinispan's eviction manager virtually unusable, since non-transactional eviction can cause phantom reads and data loss because it violates the isolation of concurrent transactions. This is especially problematic when using a passivation-enabled cache store. In this case, a cache eviction/passivation can cause a concurrently executed cache retrieval to return null - even though the act of passivation does not change the data - it only changes where it is stored. > We work around this in the AS by performing eviction manually, using pessimistic locking in combination with eager lock acquisition prior to eviction. This is unfortunate, since it prevents me from leveraging Infinispan's build-in eviction strategies. -- 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

12 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 October 2013