December 2011 - infinispan-issues

[JBoss JIRA] Created: (ISPN-586) ManagedConnectionPool doesn't work in a transactional context

by Manik Surtani (JIRA)

ManagedConnectionPool doesn't work in a transactional context ------------------------------------------------------------- Key: ISPN-586 URL: https://jira.jboss.org/browse/ISPN-586 Project: Infinispan Issue Type: Bug Components: Loaders and Stores, Transactions Affects Versions: 4.1.0.CR2 Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR3 >From the reporter: "Anyways, what seems to be the real problem is that all the things that need to be persisted are saved in memory and then when the transaction is completing (either in prepare or commit phase) the loader attempts to get a connection from the datasource. Apparently this is illegal and throws an exception which is what causes the HeuristicMixedException further up the chain. This only fails when using a ManagedConnectionFactory. If I swap out a PooledConnectionFactory it works fine. I presume the managed version fails because it returns the same connection that is part of the active transaction for that thread and you can't perform new operations on that connection once the transaction is already in prepare or commit. This feels like a bit of a design flaw to me... I didn't see an obvious fix." This possibly has to do with the AbstractCacheStore doing the following in prepare(): " public void prepare(List<? extends Modification> mods, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException { if (isOnePhase) { applyModifications(mods); } else { transactions.put(tx, mods); } } " and later during commit actually writing the changes to the store. This generic, "abstract" behaviour is intended for non-transactional data stores (such as a filesystem). Behaviour should be different when it comes to transactional data stores. -- 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, 11 months

8
25
0 / 0

[JBoss JIRA] (ISPN-1610) Timeouts waiting for StateTransferLock

by Tristan Tarrant (Created) (JIRA)

Timeouts waiting for StateTransferLock -------------------------------------- Key: ISPN-1610 URL: https://issues.jboss.org/browse/ISPN-1610 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.1.0.CR1 Reporter: Tristan Tarrant Assignee: Dan Berindei In a four node performance tests we're seeing these exceptions during cluster startup: org.infinispan.distribution.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view X The timeout is set to the default 1min. It's quite suspicious that a state transfer takes that long ( > 1min) since caches are empty. -- 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, 11 months

6
29
0 / 0

[JBoss JIRA] (ISPN-1588) IndexOutOfBoundsException while using clustered query

by Mathieu Lachance (Created) (JIRA)

IndexOutOfBoundsException while using clustered query ----------------------------------------------------- Key: ISPN-1588 URL: https://issues.jboss.org/browse/ISPN-1588 Project: Infinispan Issue Type: Bug Components: Querying, RPC Affects Versions: 5.1.0.BETA5 Reporter: Mathieu Lachance Assignee: Sanne Grinovero when using clustered query with dist sync mode i'm running into index out of bound exception. java.lang.IndexOutOfBoundsException: Index: 100, Size: 100 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at org.infinispan.query.clustered.DistributedIterator.current(DistributedIterator.java:138) at org.infinispan.query.clustered.DistributedIterator.next(DistributedIterator.java:114) at org.infinispan.query.clustered.ClusteredCacheQueryImpl.list(ClusteredCacheQueryImpl.java:136) at com.XXX.DistributedCache.cacheQueryList(DistributedCache.java:239) at com.XXX.DistributedCache.cacheQueryList(DistributedCache.java:200) at com.XXX.ClientCache.getClientsByServerId(ClientCache.java:168) at com.XXX.getClientsByServerId(ClientManager.java:157) at com.XXX$PingClient.run(PlayerBll.java:890) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) i do not have any reproductible step, but here's what i know : it only seems to happen under high contention ; when i'm running stress test. when running a stress test i might get query that return over than 100 results. tough i've also seen it happen on query that can only return few (4-6) results. i never saw the stack trace with different index and size different than 100 (it's always the exact same exception). i've also tried the lazy iterator to see if it would have a different behavior, but i get the same stack trace. is there anything i could look up in the source code to debug and maybe find the repro steps ? thanks, -- 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, 11 months

3
2
0 / 0

[JBoss JIRA] Created: (ISPN-949) Have something like Hibernate's ResultTransformer for Query results

by Sanne Grinovero (JIRA)

Have something like Hibernate's ResultTransformer for Query results ------------------------------------------------------------------- Key: ISPN-949 URL: https://issues.jboss.org/browse/ISPN-949 Project: Infinispan Issue Type: Enhancement Components: Querying Reporter: Sanne Grinovero Assignee: Manik Surtani Priority: Minor Fix For: 6.0.0.Final Be able to transform an array of projected fields into a nice object. So return a List<CustomBean>, instead of a List<Object[]> -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

2
6
0 / 0

[JBoss JIRA] (ISPN-1535) Implement a cachestore for HBase

by Justin Hayes (Created) (JIRA)

Implement a cachestore for HBase -------------------------------- Key: ISPN-1535 URL: https://issues.jboss.org/browse/ISPN-1535 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Affects Versions: 5.1.0.BETA4 Reporter: Justin Hayes Assignee: Manik Surtani I have implemented a cachestore for HBase that is modeled after the Cassandra cachestore, albeit with fewer bells and whistles. I need to repurpose the code that was done for a different project and once done, I will submit a git pull request. -- 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

3
4
0 / 0

[JBoss JIRA] (ISPN-1625) No need to throw IllegalStateException on receiving a new view on a stopped cache

by Sanne Grinovero (Created) (JIRA)

No need to throw IllegalStateException on receiving a new view on a stopped cache --------------------------------------------------------------------------------- Key: ISPN-1625 URL: https://issues.jboss.org/browse/ISPN-1625 Project: Infinispan Issue Type: Bug Components: Distributed Cache Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.1.0.CR2 -- 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

7
9
0 / 0

[JBoss JIRA] Created: (ISPN-893) Addtional attribute on @CacheEntryCreated to get on pre notifications only

by Sudheer Krishna (JIRA)

Addtional attribute on @CacheEntryCreated to get on pre notifications only ----------------------------------------------------------------------------- Key: ISPN-893 URL: https://issues.jboss.org/browse/ISPN-893 Project: Infinispan Issue Type: Enhancement Components: Listeners Affects Versions: 4.2.0.Final Environment: ALL Reporter: Sudheer Krishna Assignee: Manik Surtani Priority: Minor I may have usescases where i need notifications only when isPre = true. I was expecting a parameter to be taken by @CacheEntryCreated. But this doesnt seem to take any parametres. Aslo i would like similar values on @CacheEntryremoved also. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

4
17
0 / 0

[JBoss JIRA] Created: (ISPN-999) Support eventual consistency

by Manik Surtani (JIRA)

Support eventual consistency ---------------------------- Key: ISPN-999 URL: https://issues.jboss.org/browse/ISPN-999 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, Locking and Concurrency Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.Final Essentially, it is about supporting eventual consistency in Infinispan. Currently Infinispan is strongly consistent when using synchronous distribution mode. Each data owner receives updates synchronously so anyone anywhere on the cluster doing a GET will see the correct value. The only exception is during a rehash (when a new node joins or leaves), that consistency is eventual since the GET may reach a new joiner who may not have applied state it receives from its neighbours yet. However this is hidden from users since the GET is sent to> 1 data owner and if an UnsureResponse is received (determined by the fact that a new joiner responds and the new joiner wouldn't have finished applying state), the caller thread waits for more definite responses. However, there is a use case for being eventually consistent as well: the main benefits being speed and partition tolerance. E.g., if we use distribution in asynchronous mode, the writes become *much* faster. However, anyone anywhere doing a GET will have to perform the GET on all data owners, and compare the versions of the data received to determine which is the latest. And if there is a conflict, to pass back all values to the user. So in terms of design, what I have in mind is: * All cache entries are versioned using vector clocks. One vector clock per node. * When a node performs a GET, the GET is sent to all data owners (concurrently), and the value + version is retrieved from each. * If the versions are all the same (or they can be "fast forwarded"), the value is returned * Otherwise, all potential values and their versions are returned * A resolve() API should be provided where application code may provide a "hint" as to which version should be "correct" - which will cause an update. * In terms of implementation, this will touch the DistributionInterceptor, InternalCacheEntry and relevant factories, some config code (since this should be consistency model should be configurable), and a new public interface. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

4
8
0 / 0

[JBoss JIRA] Created: (ISPN-1394) Investigate possibility of doing manual rehashing

by Galder Zamarreño (JIRA)

Investigate possibility of doing manual rehashing ------------------------------------------------- Key: ISPN-1394 URL: https://issues.jboss.org/browse/ISPN-1394 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Reporter: Galder Zamarreño Assignee: Manik Surtani Fix For: 5.2.0.FINAL Investigate the possibility of being able to do manual rehashing: - Approach used Dynamo (and Cassandra) - If you're adding 100 nodes, using manual rehashing could reduce traffic and make it more predictable - Could be called via JMX - But removing 10 nodes could be problematic. Unless number of owners is 11 or higher, which will guarantee that at least a copy of data is around -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

5
4
0 / 0

[JBoss JIRA] Created: (ISPN-1147) Programmatically creating cache should be automatically reflected throughout the cluster

by Randall Hauch (JIRA)

Programmatically creating cache should be automatically reflected throughout the cluster ---------------------------------------------------------------------------------------- Key: ISPN-1147 URL: https://issues.jboss.org/browse/ISPN-1147 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, State transfer Affects Versions: 4.2.1.FINAL Reporter: Randall Hauch Assignee: Manik Surtani Consider a symmetric cluster of two nodes (N1 and N2) each with a single cache (C1). Currently, a new cache (C2) must be programmatically created _on all all nodes in the cluster_ (if REPL, or all appropriate nodes if DIST) _before_ that new cache can even be _used_. Ideally, when a new cache (C2) is created on one node (N1), Infinispan should automatically propagate that creation to the appropriate nodes in the cluster so that the new cache can be used immediately. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

7
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2011