November 2012 - infinispan-issues

[JBoss JIRA] (ISPN-2384) Entry lost after Eviction/Passivation

by Thomas Fromm (JIRA)

Thomas Fromm created ISPN-2384: ---------------------------------- Summary: Entry lost after Eviction/Passivation Key: ISPN-2384 URL: https://issues.jboss.org/browse/ISPN-2384 Project: Infinispan Issue Type: Bug Components: Eviction Affects Versions: 5.2.0.Beta1 Reporter: Thomas Fromm Assignee: Mircea Markus Attachments: eviction.log Cache is LOCAL, eviction + passivation enabled. After put the entry gets passivated, shortly after an other thread tries to get() the entry, but get null. Attached a log file. The key is "50b2c9e7-0a38-0043-01fc-76cdf49fa2ce". Tried JDBC and File store with same results, also sync/async store tested. It happens under some load. -- 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

4
15
0 / 0

[JBoss JIRA] (ISPN-2362) Potential inconsistency during NBST

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2362: ----------------------------------- Summary: Potential inconsistency during NBST Key: ISPN-2362 URL: https://issues.jboss.org/browse/ISPN-2362 Project: Infinispan Issue Type: Feature Request Components: State transfer Affects Versions: 5.2.0.Alpha3 Reporter: Mircea Markus Assignee: Dan Berindei Priority: Critical Fix For: 5.2.0.CR1 The NBST functionality leaves place to inconsistencies during removals: 1. the joiner first requests transaction data 2. after all transaction data is integrated (i.e. tx is prepared on the state receiver node) it requests the rest of the data (from data container) 3. in order not to override the data from transactions which is more recent (transactions at step 1 might have been committed during step 2), the data at 2 inserts data in the cache with putIfAbsent. Whilst this prevents from overriding newer values as written by transactions, it doesn't guard against the situation in which the tx removed data. So it is possible for deleted data a to resurrect. A possible solution to this inconsistency issue is by using tombstones for the duration of the state transfer. -- 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

2
11
0 / 0

[JBoss JIRA] (ISPN-2469) lock() producing timeout exceptions after nodes have left

by Carsten Lohmann (JIRA)

Carsten Lohmann created ISPN-2469: ------------------------------------- Summary: lock() producing timeout exceptions after nodes have left Key: ISPN-2469 URL: https://issues.jboss.org/browse/ISPN-2469 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Affects Versions: 5.2.0.Beta3 Reporter: Carsten Lohmann Assignee: Mircea Markus Attachments: LockAfterNodesLeftTest.java I have a replicated cache with locking mode set to PESSIMISTIC on which I use explicit locking before putting some value. After nodes have left the cluster, this does not work anymore and I get TimeoutExceptions like: {noformat} 2012-11-02 11:14:12,057 ERROR [InvocationContextInterceptor] (LockAfterNodesLeftTest.Putter-0) ISPN000136: Execution error org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on key on behalf of transaction GlobalTransaction:<NodeA-31597>:4:local. Lock is being held by GlobalTransaction:<NodeA-31597>:4:local at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.newTimeoutException(AbstractTxLockingInterceptor.java:230) at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.waitForTransactionsToComplete(AbstractTxLockingInterceptor.java:210) at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:175) at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPutKeyValueCommand(PessimisticLockingInterceptor.java:120) {noformat} This can be reproduced with the attached unit test. (Use NUM_NODES_TO_STOP_FOR_TEST=0 to not stop any nodes - the test succeeds in that case) -- 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

3
17
0 / 0

[JBoss JIRA] (ISPN-2502) State transfer can lead to inconsitencies because it applies data using putIfAbsent without locking

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-2502: ----------------------------------- Summary: State transfer can lead to inconsitencies because it applies data using putIfAbsent without locking Key: ISPN-2502 URL: https://issues.jboss.org/browse/ISPN-2502 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.2.0.Beta3 Reporter: Adrian Nistor Assignee: Adrian Nistor Priority: Critical Fix For: 5.2.0.Final -- 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

2
7
0 / 0

[JBoss JIRA] (ISPN-2483) State transfer issue with the transactions for which the originator has crashed

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2483: ----------------------------------- Summary: State transfer issue with the transactions for which the originator has crashed Key: ISPN-2483 URL: https://issues.jboss.org/browse/ISPN-2483 Project: Infinispan Issue Type: Feature Request Components: State transfer, Transactions Affects Versions: 5.1.8.Final, 5.2.0.Beta3 Reporter: Mircea Markus Assignee: Mircea Markus Priority: Critical Fix For: 5.2.0.CR1, 5.2.0.Final State transfer migrates and prepares the transactions for which the originator has left. On the receiving node, this results in the transaction being prepared and acquiring backup locks which are never released (unless manual intervention). This should behave as follows: - if there's no recovery enabled, the state producer should not send such transactions but drop them - if recovery is enabled these transactions should be sent across. They shouldn't be prepared/acquire backup locks, but be placed in the recovery cache (see RecoveryManagerImpl.inDoubtTransactions) -- 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

2
8
0 / 0

[JBoss JIRA] (ISPN-2192) Allow using Distributed Execution against any cache (not just clustered caches)

by Randall Hauch (JIRA)

Randall Hauch created ISPN-2192: ----------------------------------- Summary: Allow using Distributed Execution against any cache (not just clustered caches) Key: ISPN-2192 URL: https://issues.jboss.org/browse/ISPN-2192 Project: Infinispan Issue Type: Enhancement Affects Versions: 5.1.2.FINAL Reporter: Randall Hauch Assignee: Manik Surtani Priority: Critical It is often desirable to process all entries in a cache, and there is no reliable and consistent way to do that for any cache. If a cache is clustered, then map-reduce can be used (although IIUC it currently doesn't guarantee to process non-materialized entries for caches that have a cache store) and distributed execution can be used (IIUC this will be called for all keys owned by the cluster node). However, neither of these work on local caches. If a cache is local and there is no cache store, then apparently {{keySet()}} does work and allows a client to iterate over the keys in the local cache. However, if the local cache is configured to have a cache store, then the {{keySet()}} method will return only the keys for the materialized entries and does not return all of the keys in the cache. Of course, if a local cache does have a cache store, then its possible to obtain the keys using {{CacheLoader.loadAllKeys(...)}} (obviously this is probably not something a client should do). In short, it should be possible to use Distributed Execution against any cache, regardless of its configuration. (Ideally, it would be possible for Map-Reduce to also be used against any cache.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

5
13
0 / 0

[JBoss JIRA] (ISPN-2106) StateTransferFunctionalTest.testSTWithThirdWritingNonTxCache failing randomly

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2106: -------------------------------------- Summary: StateTransferFunctionalTest.testSTWithThirdWritingNonTxCache failing randomly Key: ISPN-2106 URL: https://issues.jboss.org/browse/ISPN-2106 Project: Infinispan Issue Type: Bug Components: State transfer, Test Suite Reporter: Galder Zamarreño Assignee: Dan Berindei Fix For: 5.2.0.ALPHA1 See: https://infinispan.ci.cloudbees.com/job/Infinispan-master-JDK6-tcp/org.in... and https://infinispan.ci.cloudbees.com/job/Infinispan-5.1.x-JDK6-tcp/org.inf... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

5
14
0 / 0

[JBoss JIRA] (ISPN-2495) Replication on startup not reliable

by Thomas Fromm (JIRA)

Thomas Fromm created ISPN-2495: ---------------------------------- Summary: Replication on startup not reliable Key: ISPN-2495 URL: https://issues.jboss.org/browse/ISPN-2495 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.2.0.Beta3 Reporter: Thomas Fromm Assignee: Mircea Markus Priority: Blocker Attachments: 2ND.log Situation: REPL cache with Cache Loader and ~500k entries and preload = true Problem: 1st node starts and the startup (until cache loaded all entries and so on) takes lets say 2min. When starting the 2nd node after e.g. 30s, then state is requested, but contains no results. cache loader is also not used, since its not the 1st node. Log from 2nd node is attached. So I've REPL cache over two (or more ) nodes, where only the 1st node contains the entries. When starting all other nodes later, then state transfer works and the data gets replicated. -- 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

4
11
0 / 0

[JBoss JIRA] (ISPN-2563) CLI session timeout too easily

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2563: ------------------------------------- Summary: CLI session timeout too easily Key: ISPN-2563 URL: https://issues.jboss.org/browse/ISPN-2563 Project: Infinispan Issue Type: Bug Components: CLI Affects Versions: 5.2.0.Beta4 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 5.2.0.CR1 -- 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
2
0 / 0

[JBoss JIRA] (ISPN-2565) Upgrade from jreadline to aesh

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2565: ------------------------------------- Summary: Upgrade from jreadline to aesh Key: ISPN-2565 URL: https://issues.jboss.org/browse/ISPN-2565 Project: Infinispan Issue Type: Component Upgrade Components: CLI Affects Versions: 5.2.0.Beta4 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 5.2.0.CR1 -- 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

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2012