August 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-689) Read past EOF caused in Lucene Directory when Lucene flushes but doesn't close the segment

by Sanne Grinovero (JIRA)

Read past EOF caused in Lucene Directory when Lucene flushes but doesn't close the segment ------------------------------------------------------------------------------------------ Key: ISPN-689 URL: https://jira.jboss.org/browse/ISPN-689 Project: Infinispan Issue Type: Bug Components: Lucene Directory Affects Versions: 4.2.0.ALPHA2, 4.1.0.Final Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.2.0.BETA1, 4.2.0.Final, 5.0.0.Final While this is not the default access scenario performed by Lucene it's possible in some branches to flush the segment and be able to read it before the close. I could reproduce the following stacktrace in high load / huge sized index but not in a unit test; disabling the batching started between .flush() and .close() seems to resolve the issue; also this batch seems totally useless as I couldn't find any chance in performance when disabling it. java.io.IOException: Read past EOF: Chunk value could not be found for key _ni.fdt|4|issues at org.infinispan.lucene.InfinispanIndexInput.setBufferToCurrentChunk(InfinispanIndexInput.java:138) at org.infinispan.lucene.InfinispanIndexInput.nextChunk(InfinispanIndexInput.java:131) at org.infinispan.lucene.InfinispanIndexInput.readBytes(InfinispanIndexInput.java:96) at org.apache.lucene.store.IndexInput.readBytes(IndexInput.java:61) at org.apache.lucene.index.CompoundFileWriter.copyFile(CompoundFileWriter.java:228) at org.apache.lucene.index.CompoundFileWriter.close(CompoundFileWriter.java:184) at org.apache.lucene.index.IndexWriter.flushDocStores(IndexWriter.java:2342) at org.apache.lucene.index.IndexWriter.doFlushInternal(IndexWriter.java:4359) at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:4264) at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:4255) at org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:4133) at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:4206) at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:4179) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

5
6
0 / 0

[JBoss JIRA] Created: (ISPN-1132) Locking optimization: reorder lock acquisition to avoid deadlocks

by Mircea Markus (JIRA)

Locking optimization: reorder lock acquisition to avoid deadlocks ------------------------------------------------------------------- Key: ISPN-1132 URL: https://issues.jboss.org/browse/ISPN-1132 Project: Infinispan Issue Type: Feature Request Components: Transactions Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.1.0.Final Detailed here, as the 3rd improvement: http://community.jboss.org/wiki/PossibleLockingImprovements -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
12
0 / 0

[JBoss JIRA] Created: (ISPN-1137) Locking optimization: for dist lock only main data owner

by Mircea Markus (JIRA)

Locking optimization: for dist lock only main data owner --------------------------------------------------------- Key: ISPN-1137 URL: https://issues.jboss.org/browse/ISPN-1137 Project: Infinispan Issue Type: Feature Request Components: Transactions Affects Versions: 4.2.1.FINAL Reporter: Mircea Markus Assignee: Manik Surtani Detailed here, as the 4th improvement: http://community.jboss.org/wiki/PossibleLockingImprovements As without ISPN-1131 locks are being acquired as the transaction progresses this optimization makes more sense after having ISPN-1131 in place. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

5
18
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] 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, 7 months

12
22
0 / 0

[JBoss JIRA] Created: (ISPN-439) Define and implement configuration file backward and forward compatibility policy

by Vladimir Blagojevic (JIRA)

Define and implement configuration file backward and forward compatibility policy --------------------------------------------------------------------------------- Key: ISPN-439 URL: https://jira.jboss.org/jira/browse/ISPN-439 Project: Infinispan Issue Type: Task Affects Versions: 4.1.0.BETA1 Reporter: Vladimir Blagojevic Assignee: Manik Surtani Fix For: 4.1.0.CR1 Backward compatibility: Process any previous version configuration file from the same minor version. For example, Infinispan release 4.2 should process configuration file produced for version 4.1 without any configuration file changes or any other adjustments. For configuration options present in 4.2, but not in 4.1 assume default values. However, Infinispan version 5.0 is not required to process configuration files from previous major versions, i.e 4.0...4.x. Forward compatibility. Do not process any forward version configuration file. For example, Infinispan release 4.1, give configuration file input from any succeeding versions (i.e 4.2...4.x, 5.x) would simply fail outright with proper error message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

7
26
0 / 0

[JBoss JIRA] Created: (ISPN-1224) Make sure a Lucene Directory can be configured in the general AS configuration independently from the Lucene version

by Sanne Grinovero (JIRA)

Make sure a Lucene Directory can be configured in the general AS configuration independently from the Lucene version -------------------------------------------------------------------------------------------------------------------- Key: ISPN-1224 URL: https://issues.jboss.org/browse/ISPN-1224 Project: Infinispan Issue Type: Enhancement Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 5.1.0.Final As discussed on forums: http://community.jboss.org/message/612561 and mailing list: http://infinispan.markmail.org/thread/hixrdqas4jn5cuok configuring such a cache needs Externalizers and optionally Key2String transformers which are bundled in the infinispan-lucene-directory module, but since this module depends on Lucene people would rather want to avoid having to move this jar to the commons lib path of the application server, but still want to configure the cache in the AS configuration to not have to start a second CacheManager. This issue would not apply anymore if support asymmetric clusters is implemented -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

4
4
0 / 0

[JBoss JIRA] Created: (ISPN-1252) Clearly document the fact asymmetric clusters are not supported

by Sanne Grinovero (JIRA)

Clearly document the fact asymmetric clusters are not supported --------------------------------------------------------------- Key: ISPN-1252 URL: https://issues.jboss.org/browse/ISPN-1252 Project: Infinispan Issue Type: Task Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 5.0.0.FINAL While I find myself explaining this quite often, I couldn't find a reference in the docs to point people to. I think it should be made very clear, covered in the introduction, in the configuration and in the FAQ too. (See forum reference) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

5
7
0 / 0

[JBoss JIRA] Created: (ISPN-658) DistributionManager not considerate of cache state changes

by Paul Ferraro (JIRA)

DistributionManager not considerate of cache state changes ---------------------------------------------------------- Key: ISPN-658 URL: https://jira.jboss.org/browse/ISPN-658 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 4.2.0.ALPHA2 Reporter: Paul Ferraro Assignee: Manik Surtani Considering a cache manager with 2 caches in DIST mode (C1 and C2) deployed on 2 nodes (N1 and N2). Currently, the DistributionManager does not properly handle the following scenarios: 1. Stop C1 on N1. This ought to trigger a rehash for the C1 cache. Currently, rehashing is only triggered via view change. Failure to rehash on stopping of a cache can inadvertently cause data loss, if all backups of a given cache entry have stopped. 2. A new DIST mode cache, C3, is started on N2. If N1 is the coordinator, the join request sent to N1 will get stuck in an infinite loop, since the cache manager on N1 does not contain a C3 cache. 3. Less critically, a new node, N3 is started. It does not yet have a C1 or C2 cache, though it's cache manager is started. This prematurely triggers a rehash of C1 and C2, even though there are no new caches instances to consider. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

11
24
0 / 0

[JBoss JIRA] Created: (ISPN-1307) REST protocol improvements for version 2

by Galder Zamarreño (JIRA)

REST protocol improvements for version 2 ---------------------------------------- Key: ISPN-1307 URL: https://issues.jboss.org/browse/ISPN-1307 Project: Infinispan Issue Type: Enhancement Components: Cache Server Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 6.0.0.FINAL This JIRA is meant to act as an umbrella for improvements we might want to do in the REST protocol. For example: - As shown in ISPN-1285 and https://docs.jboss.org/author/display/ISPN/Accessing+data+in+Infinispan+v..., the use of 0 as timeToLiveSeconds and/or maxIdleTimeSeconds parameter(s) is not very intuitive and it's not even symmetric. This should be sorted out. This JIRA should also figure out how to support multiple REST protocol versions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2011