October 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1459) Speedup removal of expired entries by reusing current time

by Sanne Grinovero (Created) (JIRA)

Speedup removal of expired entries by reusing current time ---------------------------------------------------------- Key: ISPN-1459 URL: https://issues.jboss.org/browse/ISPN-1459 Project: Infinispan Issue Type: Enhancement Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.1.0.BETA2 -- 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

12 years, 5 months

4
4
0 / 0

[JBoss JIRA] (ISPN-1497) FileCacheStore config doesn't allow streamBufferSize to be set

by Aaron Douglas (Created) (JIRA)

FileCacheStore config doesn't allow streamBufferSize to be set -------------------------------------------------------------- Key: ISPN-1497 URL: https://issues.jboss.org/browse/ISPN-1497 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 5.0.1.FINAL, 4.2.1.FINAL Reporter: Aaron Douglas Assignee: Manik Surtani Inside of the FileCacheStoreConfig class, the setter (now being deprecated in 5) for streamBufferSize has a typo when checking for immutability. This prevents the value from actually being overridden from default. While this is being deprecated, it's the only option available for those of us stuck in Infinispan 4.x for the time being. {code} public void setStreamBufferSize(int streamBufferSize) { testImmutability("steamBufferSize"); this.streamBufferSize = streamBufferSize; } {code} Notice it is spelled STEAM buffer size instead of streamBufferSize in the testImmutability method call. -- 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

12 years, 5 months

4
4
0 / 0

[JBoss JIRA] Created: (ISPN-1343) Stale locks occurring on rehashing into a running cluster.

by Erik Salter (JIRA)

Stale locks occurring on rehashing into a running cluster. ---------------------------------------------------------- Key: ISPN-1343 URL: https://issues.jboss.org/browse/ISPN-1343 Project: Infinispan Issue Type: Bug Affects Versions: 5.0.0.FINAL Reporter: Erik Salter Assignee: Manik Surtani There is a stale lock issue that occurs when a client thread requests the same set of eagerly-locked keys across a rehash. Attached is a unit test that can reproduce the issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

9
17
0 / 0

[JBoss JIRA] (ISPN-1487) AdvancedCache.with(ClassLoader) API not working as expected

by Galder Zamarreño (Created) (JIRA)

AdvancedCache.with(ClassLoader) API not working as expected ----------------------------------------------------------- Key: ISPN-1487 URL: https://issues.jboss.org/browse/ISPN-1487 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.0.BETA1 Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.CR1 Changes in ISPN-1397 broke this functionality. Make sure WithClassLoaderTest works. -- 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

12 years, 6 months

5
9
0 / 0

[JBoss JIRA] (ISPN-61) Transaction 2-phase protocol optimizations

by Galder Zamarreño (Updated) (JIRA)

[ https://issues.jboss.org/browse/ISPN-61?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño updated ISPN-61: --------------------------------- Fix Version/s: 5.1.0.BETA4 (was: 5.1.0.BETA3) > Transaction 2-phase protocol optimizations > ------------------------------------------ > > Key: ISPN-61 > URL: https://issues.jboss.org/browse/ISPN-61 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 4.0.0.ALPHA4 > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Critical > Fix For: 5.1.0.BETA4, 5.1.0.FINAL > > > Following 2 optimizations might be implemented with respect to transactions. > 1) From an email on infinispan-dev (horizon-dev actually): > if there are only two members int the cluster always use an 1PC. If the 1st phase fails remotely, then also rollback locally. This would reduce one network roundtrip. > While this is an interesting thought, it does raise the potential for race conditions - since this decision will have to be taken in the TxInterceptor in the beforeCompletion phase of a transaction, and by the time the call gets to the interceptor for replication, the topology may have changed such that you need to replicate to 2 instead of 1 other peer. Which would mean a 2PC again. So it does need some thought. > 2) when asked to prepare, a participant might return a value indicating that no changes were made (read-only participant), so this one won't need an commit message, so less roundtrip. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1484) The commit command can fail with a RehashInProgressException and not release the key locks

by Dan Berindei (Created) (JIRA)

The commit command can fail with a RehashInProgressException and not release the key locks ------------------------------------------------------------------------------------------ Key: ISPN-1484 URL: https://issues.jboss.org/browse/ISPN-1484 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Affects Versions: 5.1.0.BETA2, 5.0.1.FINAL Reporter: Dan Berindei Assignee: Dan Berindei Priority: Critical Fix For: 5.1.0.CR1 Because a commit command usually has at least one locked key, it is much more likely than other commands to fail on the originator with a RehashInProgressException. There is no retry mechanism in this case, so the transaction will fail (after we have confirmed the prepare to the TM) and the transaction's keys will not be unlocked (because the failure happens in StateTransferLockInterceptor, which is below the locking interceptor in the invocation chain). -- 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

12 years, 6 months

3
5
0 / 0

[JBoss JIRA] (ISPN-1483) Stale locks with eager/pessimistic locking after the prepare command fails on a remote node

by Dan Berindei (Created) (JIRA)

Stale locks with eager/pessimistic locking after the prepare command fails on a remote node ------------------------------------------------------------------------------------------- Key: ISPN-1483 URL: https://issues.jboss.org/browse/ISPN-1483 Project: Infinispan Issue Type: Bug Reporter: Dan Berindei Assignee: Dan Berindei When a PrepareCommand fails (in our case because it didn't get a reply from the remote node in 15 seconds), the locking interceptor catches the exception and releases all the locks acquired by the transaction. After that TransactionCoordinator starts a proper rollback, but the entries in the invocation context are no longer locked (and in 5.0 that means they only have the VALID flag set, not CHANGED or CREATED). That means local locks are not released twice, but it also means the PrepareCommand is not executed remotely (BaseRpcInterceptor.shouldInvokeRemoteTxCommand() returns false). In 5.1 we no longer have the entry flags but the entries are still locked. I see 3 possible solutions: 1. Don't clean up the locks at all in LockingInterceptor (if the invocation context is transactional) and rely on TransactionCoordinator to do it. 2. Clean up the locks but don't call rollback() on the entry. 3. Rely on LocalTransaction's getRemoteLocksAcquired() instead of the locked entries to determine if the rollback command should be executed on the remote nodes. -- 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

12 years, 6 months

3
5
0 / 0

[JBoss JIRA] (ISPN-1493) Write commands fail too often with RehashInProgressException during state transfer

by Dan Berindei (Created) (JIRA)

Write commands fail too often with RehashInProgressException during state transfer ---------------------------------------------------------------------------------- Key: ISPN-1493 URL: https://issues.jboss.org/browse/ISPN-1493 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.1.0.BETA2, 5.0.1.FINAL Reporter: Dan Berindei Assignee: Manik Surtani Fix For: 5.1.0.BETA3 With the blocking state transfer we have since 5.0, we can sometimes have a deadlock between the state transfer process and executing write/prepare/commit commands. The commands need to acquire the state transfer lock on the originator and on the key owners, in this order, and the state transfer also needs to acquire the state transfer lock on these nodes but in an undefined order (see ISPN-1106). This is solved by failing fast when acquiring the command's state transfer lock on the remote node, but this means that a write command can fail with a RehashInProgressException and the user is forced to retry. We can do better and retry the command ourselves after waiting for the state transfer to end. -- 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

12 years, 6 months

3
2
0 / 0

[JBoss JIRA] Created: (ISPN-1115) Fine-grained AtomicMaps

by Manik Surtani (JIRA)

Fine-grained AtomicMaps ----------------------- Key: ISPN-1115 URL: https://issues.jboss.org/browse/ISPN-1115 Project: Infinispan Issue Type: Feature Request Components: Core API Affects Versions: 5.0.0.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.Final Atomic Maps are locked by acquiring a single lock on the entire map and this causes concurrency issues for certain use cases. This JIRA is to allow for concurrent modifications of keys within the AtomicMap, provided the keys do not overlap. The design is as follows: * {{AtomicMapLookup}} gets a WL on the {{AtomicMap}}'s key (AMK) when creating and removing a new AtomicMap * Modifications to the AtomicMap (which go through the {{AtomicMapProxy}}) do _not_ acquire a WL on AMK. Instead, * {{AdvancedCache}} exposes a new API, {{applyDelta(K deltaAwareValueKey, Delta delta, Object... locksToAcquire)}} * {{AtomicMapProxy}} makes changes by calling {{applyDelta}} and passing in the key within the map that is being modified, along with the delta to apply. * The implementation could offer lock pooling to prevent a large number of locks being created for AtomicMaps with a large number of entries This can then be used by other {{Delta}}/{{DeltaAware}} types in future as well, perhaps JSON documents, etc. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

12
22
0 / 0

[JBoss JIRA] (ISPN-1489) Upgrade to Seam Solder 3.1.0.Beta4

by Kevin Pollet (Created) (JIRA)

Upgrade to Seam Solder 3.1.0.Beta4 ---------------------------------- Key: ISPN-1489 URL: https://issues.jboss.org/browse/ISPN-1489 Project: Infinispan Issue Type: Component Upgrade Components: CDI integration Reporter: Kevin Pollet Assignee: Kevin Pollet Fix For: 5.1.0.BETA3, 5.1.0.FINAL -- 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

12 years, 6 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2011