September 2011 - infinispan-issues

[JBoss JIRA] Created: (ISPN-465) HTTP session management for Tomcat

by Manik Surtani (JIRA)

HTTP session management for Tomcat ---------------------------------- Key: ISPN-465 URL: https://jira.jboss.org/browse/ISPN-465 Project: Infinispan Issue Type: Feature Request Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.Final Session management plugin for Glassfish, to allow running Glassfish in non-clustered mode and having all clustering of session state managed by Infinispan. -- 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, 5 months

3
6
0 / 0

[JBoss JIRA] Created: (ISPN-1297) add option to enable 1PC for induced transactions

by Mircea Markus (JIRA)

add option to enable 1PC for induced transactions ------------------------------------------------- Key: ISPN-1297 URL: https://issues.jboss.org/browse/ISPN-1297 Project: Infinispan Issue Type: Feature Request Components: Configuration, Transactions Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.1.0.ALPHA1, 5.1.0.FINAL Starting with Infinispan 5.1 a cache is only able to function in either transactional or non-transactional mode. Mixed mode won't be supported any more. This is causing a backward compatibility issue for existing users that make both transactional and non-transactional access to the same cache. A good example is the Lucene-directory that is writing to a cache through batching API *and* directly. In Lucene-D's case, one can configure autoCommit=true for a transaction: that will induce a transaction within direct (i.e. non transactional) calls. Whilst this preserves backward compatibility, it is not "good enough" as an injected transaction does results in 2 RPCs, one for each phase of 2PC, and that is less performant than the "old" direct call. In order to solve this performance shortcoming, another attribute is to be added: use1PcForInducedTransaction(default to true). Enabling this attribute causes the *induced* transaction to force an 1PC resulting in a single RPC. Other tx that induced one won't be affected by this configuration. This mail thread is also relevant: http://bit.ly/plNbLT -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

8
17
0 / 0

[JBoss JIRA] Created: (ISPN-1391) Use UNICAST2 instead of UNICAST

by Galder Zamarreño (JIRA)

Use UNICAST2 instead of UNICAST ------------------------------- Key: ISPN-1391 URL: https://issues.jboss.org/browse/ISPN-1391 Project: Infinispan Issue Type: Enhancement Components: RPC Reporter: Galder Zamarreño Assignee: Dan Berindei Fix For: 5.1.0.BETA2, 5.1.0.FINAL UNICAST2 already available in JGroups 2.12: http://www.jgroups.org/javadoc/org/jgroups/protocols/UNICAST2.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

6
8
0 / 0

[JBoss JIRA] Created: (ISPN-1130) Eager locks acquired multiple times

by Mircea Markus (JIRA)

Eager locks acquired multiple times ----------------------------------- Key: ISPN-1130 URL: https://issues.jboss.org/browse/ISPN-1130 Project: Infinispan Issue Type: Feature Request Components: Transactions Affects Versions: 4.2.1.FINAL Reporter: Mircea Markus Assignee: Manik Surtani If eager locking is enabled, a remote lock is acquired repeatedly. e.g. tx.begin() cache.put(k,v); //rpc acquiring lock on "k" ... cache.remove(k); // another rpc for acquiring lock on "k" tx.commit(); the second rpc for acquiring lock is un-necessary. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

6
13
0 / 0

[JBoss JIRA] Created: (ISPN-1397) Optimise thread local usage in Infinispan

by Manik Surtani (JIRA)

Optimise thread local usage in Infinispan ----------------------------------------- Key: ISPN-1397 URL: https://issues.jboss.org/browse/ISPN-1397 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 Three separate areas to consider: 1. Remove ThreadLocal usage in OwnableReentrantLock 2. Remove ThreadLocal usage in InvocationContextContainer 3. Remove ThreadLocal usage in Flags API Look for any other ThreadLocal usage with a critical eye. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

7
11
0 / 0

[JBoss JIRA] Created: (ISPN-1415) timeouts on startCaches on repl caches

by Sanne Grinovero (JIRA)

timeouts on startCaches on repl caches -------------------------------------- Key: ISPN-1415 URL: https://issues.jboss.org/browse/ISPN-1415 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.0.ALPHA2 , 5.0.1.FINAL, 5.0.0.FINAL Reporter: Sanne Grinovero Assignee: Dan Berindei Fix For: 5.0.2.FINAL, 5.1.0.BETA1 The failing branch on Hibernate Search is committed at https://github.com/Sanne/hibernate-search/tree/startCaches -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

5
5
0 / 0

[JBoss JIRA] Created: (ISPN-1364) Allow use of CacheContainer interface for cache manager configuration

by Kevin Pollet (JIRA)

Allow use of CacheContainer interface for cache manager configuration --------------------------------------------------------------------- Key: ISPN-1364 URL: https://issues.jboss.org/browse/ISPN-1364 Project: Infinispan Issue Type: Enhancement Components: CDI integration Affects Versions: 5.0.0.FINAL, 5.0.0.CR8 Reporter: Kevin Pollet Assignee: Kevin Pollet Fix For: 5.1.0.BETA1, 5.1.0.FINAL Currently the {{infinispan-cdi}} extension only works with the {{EmbeddedCacheManager}} interface. That means that a cache manager cannot be configured with a producer of type {{CacheContainer}}. The CDI extension has to be flexible and allow to use the interface {{EmbeddedCacheManager}} or {{CacheContainer}}. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

4
6
0 / 0

[JBoss JIRA] Created: (ISPN-1411) ISPN cache is hung when try to read data from DB

by Anatoliy Bazko (JIRA)

ISPN cache is hung when try to read data from DB ------------------------------------------------ Key: ISPN-1411 URL: https://issues.jboss.org/browse/ISPN-1411 Project: Infinispan Issue Type: Bug Components: Marshalling Affects Versions: 5.0.0.FINAL Environment: Oracle 11.1.6.0.0 Reporter: Anatoliy Bazko Assignee: Manik Surtani Have a look on AbstractMarshaller.objectFromInputStream(InputStream inputStream). When inputStream.available() returns 0 (but it doesn't mean that stream is empty) we have never ended cycle below {code} while ((bytesRead = inputStream.read(buf, 0, buf.length)) != -1) bytes.write(buf, 0, bytesRead); {code} I personally can reproduce this with Oracle DB -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

4
4
0 / 0

[JBoss JIRA] Created: (ISPN-1430) advancedCache.addInterceptorXYZ method don't inform the caller if the operation fails

by Mircea Markus (JIRA)

advancedCache.addInterceptorXYZ method don't inform the caller if the operation fails ------------------------------------------------------------------------------------- Key: ISPN-1430 URL: https://issues.jboss.org/browse/ISPN-1430 Project: Infinispan Issue Type: Feature Request Components: Core API Reporter: Mircea Markus Assignee: Manik Surtani Problem: cache.getAdvancedCache().addInterceptorAfter(new ErrorInducingInterceptor(), NonTransactionalLockingInterceptor.class); if NonTransactionalLockingInterceptor doesn't exist in the chain then the method return silently without informing the user that it didn't succeed. This is not API friendly. Suggested solution: throw an exception to inform the user that his attempt is not correct. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

7
8
0 / 0

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

5
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2011