October 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1359) SetExternalizer Cannot Properly Handle TreeSets Constructed With Comparator

by Ryan Scharer (JIRA)

SetExternalizer Cannot Properly Handle TreeSets Constructed With Comparator --------------------------------------------------------------------------- Key: ISPN-1359 URL: https://issues.jboss.org/browse/ISPN-1359 Project: Infinispan Issue Type: Bug Components: Marshalling Affects Versions: 5.0.0.FINAL Environment: OSX 10.7.1, System JDK Reporter: Ryan Scharer Assignee: Manik Surtani TreeSets can be used to hold objects that don't implement Comparable, so long as you provide a Comparator during construction. The current implementation of SetExternalizer doesn't support this pattern... trying to deserialize a TreeSet that holds objects that don't implement Comparable results in a ClassCastException. This seriously reduces the flexibility of TreeSet. JBoss Cache doesn't have this limitation, presumably because it delegates to native Java serialization. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

4
7
0 / 0

[JBoss JIRA] (ISPN-2433) Produce source jars for test jars

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2433: -------------------------------------- Summary: Produce source jars for test jars Key: ISPN-2433 URL: https://issues.jboss.org/browse/ISPN-2433 Project: Infinispan Issue Type: Task Components: Build process Reporter: Galder Zamarreño Assignee: Mircea Markus Priority: Minor Fix For: 5.2.0.CR1, 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, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-328) Async store to support frequency based flushing

by Galder Zamarreno (JIRA)

Async store to support frequency based flushing ----------------------------------------------- Key: ISPN-328 URL: https://jira.jboss.org/jira/browse/ISPN-328 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Implement frequency based flushing in the async store. This is also called, Scheduled Write-Behing Strategy. -- 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

11 years, 8 months

5
11
0 / 0

[JBoss JIRA] (ISPN-2448) Queries with offset are broken for iteration

by Ales Justin (JIRA)

Ales Justin created ISPN-2448: --------------------------------- Summary: Queries with offset are broken for iteration Key: ISPN-2448 URL: https://issues.jboss.org/browse/ISPN-2448 Project: Infinispan Issue Type: Bug Components: Querying Affects Versions: 5.2.0.Beta2 Reporter: Ales Justin Assignee: Sanne Grinovero Fix For: 5.2.0.Beta3 The problem is with queries with offset when you iterate over them -- offset is never taken into account. There are two possible fixes -- as I see them. 1) In HS: DocumentExtractorImpl::extract takes into account "firstIndex" public EntityInfo extract(int scoreDocIndex) throws IOException { int docId = queryHits.docId( firstIndex + scoreDocIndex ); Document document = extractDocument( fistIndex + scoreDocIndex ); 2) LazyIterator in Infinispan-Query applies the offset: protected EntityInfo loadEntityInfo(int index) { try { return extractor.extract(extractor.getFirstIndex() + index); --- Since those methods are exposed in DocumentExtractor, I would guess they were meant for external code to use them, instead of putting this logic into extractor itself. -- 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, 8 months

3
3
0 / 0

[JBoss JIRA] Created: (ISPN-604) Re-design CacheStore transactions

by Mircea Markus (JIRA)

Re-design CacheStore transactions ---------------------------------- Key: ISPN-604 URL: https://jira.jboss.org/browse/ISPN-604 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores, Transactions Affects Versions: 4.1.0.CR2, 4.0.0.Final Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.0.0.Final Current(4.1.x) transaction implementation in CacheStores is brocken in several ways: 1st problem. - AbstractCacheStore.prepare: public void prepare(List<? extends Modification> mods, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException { if (isOnePhase) { applyModifications(mods); } else { transactions.put(tx, mods); } } If this is 1PC we apply the modifications in the prepare phase - we should do it in the commit phase (as JTA does it). 2nd problem. This currently exhibits during commit/rollback with JdbcXyzCacheStore, but it is rather a more general cache store issue. When using a TransactionManager, during TM.commit AbstractCacheStore.commit is being called internally which tries to apply all the modifications that happened during that transaction. Within the scope of AbstractCacheStore.commit, JdbcStore obtains a connection from a DataSource and tries to write the modifications on that connection. Now if the DataSource is managed (e.g. by an A.S.) on the DS.getConnection call the A.S. would try to enlist the connection with the ongoing transaction by calling Transaction.enlistResource(XAResource xaRes) [1] This method fails with an IllegalStateException, because the transaction's status is preparing (see javax.transaction.Transaction.enlistResource). Suggested fix: - the modifications should be registered to the transaction as they happen(vs. during prepare/commit as it happens now) - this requires API changes in CacheStore, e.g. void store(InternalCacheEntry entry) should become void store(InternalCacheEntry entry, GlobalTransaction gtx) (gtx would be null if this is not a transactional call). [1] This behavior is specified by the JDBC 2.0 Standard Extension API, chapter 7 - distributed transaction -- 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

11 years, 8 months

4
9
0 / 0

[JBoss JIRA] (ISPN-2183) Add the ability to fetch a set of keys at once (getAll)

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2183: ----------------------------------- Summary: Add the ability to fetch a set of keys at once (getAll) Key: ISPN-2183 URL: https://issues.jboss.org/browse/ISPN-2183 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Manik Surtani -- 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, 8 months

1
2
0 / 0

[JBoss JIRA] (ISPN-2414) Optimise memory hotspots for local caches

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2414: -------------------------------------- Summary: Optimise memory hotspots for local caches Key: ISPN-2414 URL: https://issues.jboss.org/browse/ISPN-2414 Project: Infinispan Issue Type: Enhancement Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.2.0.CR1, 5.2.0.Final Several small memory hotspots have been discovered during some performance testing of local caches. Optimise them. 1. Collections.EmptySet.Iterator: Screen%20Shot%202012-10-17%20at%201.21.48%20PM.png - First of all, iterating over an empty set returns a brand new iterator instance all the time. WTF? - Second, why does get() have to call unlockAll()? We do not acquire locks on get (unless it has a FORCE_WRITE_LOCK flag on it), right? 2. ThreadLocal.set: Screen%20Shot%202012-10-17%20at%201.25.45%20PM.png - Is this neeeded at all? - If it's needed for any use case, can it be optimised away to avoid using it for a local cache where no marshaller is used, and where no cluster cache loader is used? 3. AbstractInvocationContext instances: Screen%20Shot%202012-10-17%20at%201.30.09%20PM.png - Why is this expensive? Is it cos the reference to the ClassLoader? - If it's the ClassLoader ref, can we move this away for local caches? 4. AbstractFlagAffectedCommand instances: Screen%20Shot%202012-10-17%20at%201.33.46%20PM.png - Might be worth thinking how can we shrink these commands for local, unflagged, operations, such as get? -- 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, 8 months

2
4
0 / 0

[JBoss JIRA] (ISPN-2412) The CLI should allow setting the default cache

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2412: ------------------------------------- Summary: The CLI should allow setting the default cache Key: ISPN-2412 URL: https://issues.jboss.org/browse/ISPN-2412 Project: Infinispan Issue Type: Enhancement Components: CLI Affects Versions: 5.2.0.Beta2 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Priority: Critical Fix For: 5.2.0.CR1 Currently the CLI uses the ___defaultcache if a cache has not been selected. This is incorrect in the case of running within JDG/AS7/EAP since the default cache for a container there doesn't coincide with Infinispan's concept of default cache. Also the CLI URL connection scheme should support specifying the container + cache and also display them as part of the prompt -- 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, 8 months

2
2
0 / 0

[JBoss JIRA] (ISPN-2447) Upgrade to Netty 3.5.9.Final

by Norman Maurer (JIRA)

Norman Maurer created ISPN-2447: ----------------------------------- Summary: Upgrade to Netty 3.5.9.Final Key: ISPN-2447 URL: https://issues.jboss.org/browse/ISPN-2447 Project: Infinispan Issue Type: Task Reporter: Norman Maurer Assignee: Mircea Markus I just released a new version of Netty that fixes a possible NPE which is can be triggered when using the HashedWheelTimer[1]. This seems to be because of a JDK bug, anyway a workaround is now included in Netty. So it would be a good idea to upgrade [1] https://github.com/netty/netty/issues/679 -- 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, 8 months

2
4
0 / 0

[JBoss JIRA] (ISPN-2430) Two instances of InterceptorChain instantiated for a single cache

by Marko Lukša (JIRA)

Marko Lukša created ISPN-2430: --------------------------------- Summary: Two instances of InterceptorChain instantiated for a single cache Key: ISPN-2430 URL: https://issues.jboss.org/browse/ISPN-2430 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.2.0.Beta2 Reporter: Marko Lukša Assignee: Marko Lukša This can be observed when running QueryCacheRestartTest. I have the fix already, but still need to make a test for this. -- 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, 8 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2012