[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, 9 months
[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, 9 months
[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, 9 months
[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, 9 months
[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, 9 months
[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, 9 months