March 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-989) Clarify default value of clustering type on missing transport in configuration API javadocs

by Sanne Grinovero (JIRA)

Clarify default value of clustering type on missing transport in configuration API javadocs ------------------------------------------------------------------------------------------- Key: ISPN-989 URL: https://issues.jboss.org/browse/ISPN-989 Project: Infinispan Issue Type: Enhancement Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Trivial Fix For: 4.2.1.FINAL, 5.0.0.BETA1 When the transport is not defined, clustering is disabled and the default cache mode is LOCAL. Not currently very clear from the docs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
2
0 / 0

[JBoss JIRA] Resolved: (ISPN-186) Smart L1 cache invalidation

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-186?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño resolved ISPN-186. ----------------------------------- Resolution: Done > Smart L1 cache invalidation > --------------------------- > > Key: ISPN-186 > URL: https://issues.jboss.org/browse/ISPN-186 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Reporter: Manik Surtani > Assignee: Pete Muir > Labels: l1 > Fix For: 5.0.0.BETA1, 5.0.0.FINAL > > > Need to build a mechanism in which L1 invalidation is NOT multicast, but instead is unicast _if necessary_ to specific nodes that may have cached a given entry. This can be detected by maintaining a list of nodes who have requested a key via a remote get, but this would need to be relayed by all data owners. > Benefits would be performance by removing unnecessary invalidation where this is not needed, and by reducing noise in network stacks of most nodes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Reopened: (ISPN-39) Distributed executors

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-39?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño reopened ISPN-39: ---------------------------------- Map/Reduce part still in the making. > Distributed executors > --------------------- > > Key: ISPN-39 > URL: https://issues.jboss.org/browse/ISPN-39 > Project: Infinispan > Issue Type: Feature Request > Components: RPC > Reporter: Manik Surtani > Assignee: Vladimir Blagojevic > Priority: Critical > Labels: hackathon > Fix For: 5.0.0.BETA1, 5.0.0.FINAL > > > A new API to allow users to provide a Runnable/Callable and a set of keys to run this on, and the ability to move the code to where the data is and execute it there, returning results (if any) across a network. > Scope and objectives of this task are described in https://community.jboss.org/wiki/InfinispanDistributedExecutionFramework -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-39) Distributed executors

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-39?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño updated ISPN-39: --------------------------------- Fix Version/s: 5.0.0.BETA1 (was: 5.0.0.ALPHA2) > Distributed executors > --------------------- > > Key: ISPN-39 > URL: https://issues.jboss.org/browse/ISPN-39 > Project: Infinispan > Issue Type: Feature Request > Components: RPC > Reporter: Manik Surtani > Assignee: Vladimir Blagojevic > Priority: Critical > Labels: hackathon > Fix For: 5.0.0.BETA1, 5.0.0.FINAL > > > A new API to allow users to provide a Runnable/Callable and a set of keys to run this on, and the ability to move the code to where the data is and execute it there, returning results (if any) across a network. > Scope and objectives of this task are described in https://community.jboss.org/wiki/InfinispanDistributedExecutionFramework -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-923) Incorrect rehashing on merge

by Bela Ban (JIRA)

Incorrect rehashing on merge ---------------------------- Key: ISPN-923 URL: https://issues.jboss.org/browse/ISPN-923 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 4.2.1.CR1 Reporter: Bela Ban Assignee: Manik Surtani When I simulate a network partition and subsequent merge, data added to the different nodes during the partition are only partially rehashed correctly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
7
0 / 0

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

by Manik Surtani (JIRA)

Support eventual consistency ---------------------------- Key: ISPN-998 URL: https://issues.jboss.org/browse/ISPN-998 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

13 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (ISPN-995) NoClassDefFoundError exception when using jdbc cache loader

by Daniel Parda (JIRA)

NoClassDefFoundError exception when using jdbc cache loader ----------------------------------------------------------- Key: ISPN-995 URL: https://issues.jboss.org/browse/ISPN-995 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.2.1.CR4 Environment: Windows XP, java version "1.6.0_20" Reporter: Daniel Parda Assignee: Manik Surtani An exception is raised when I start a cache: java.lang.NoClassDefFoundError: org/infinispan/config/PluggableConfigurationComponent. It was worked fine with CR3. I ran strings against compiled JdbcStringBasedCacheStoreConfig.class: * CR3: $ strings JdbcStringBasedCacheStoreConfig.class | grep -i configuration =()Lorg/infinispan/config/AbstractNamedCacheConfigurationBean; 9()Lorg/infinispan/config/CloneableConfigurationComponent; * CR4: $ strings JdbcStringBasedCacheStoreConfig.class | grep -i configuration 9()Lorg/infinispan/config/PluggableConfigurationComponent; =()Lorg/infinispan/config/AbstractNamedCacheConfigurationBean; 9()Lorg/infinispan/config/CloneableConfigurationComponent; Please note I used precompiled packages downloaded from sourceforge.net: infinispan-4.2.1.CR4-bin.zip and infinispan-4.2.1.CR4-all.zip. There exists workaround: there is no issue when modules/jdbc is compiled from source distribution. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
6
0 / 0

[JBoss JIRA] Created: (ISPN-932) Failed nodes remain in the topology.

by Shane Johnson (JIRA)

Failed nodes remain in the topology. ------------------------------------ Key: ISPN-932 URL: https://issues.jboss.org/browse/ISPN-932 Project: Infinispan Issue Type: Bug Components: Distributed Cache Reporter: Shane Johnson Assignee: Manik Surtani A node will remain in the cluster topology even if it never enters the RUNNING state. 1. CacheDelegate.start 2. ComponentRegistry.start 3. AbstractComponentRegistry.start 4. AbstractComponentRegistry.internalStart 5. AbstractComponentRegistry.handleLifecycleTransitionFailure The last start method will execute the @Start methods of the components. In the event that one of the methods throws an exception, the node will enter the FAILED state. The problem is that in distributed mode the node is added to the cluster topology before the rehashing takes place. If an exception is thrown during the rehash, the join still completes successfully. 1. Broadcast new consistent hash. 2. Get state. 3. Invalidate state. (This is in a finally block. Occurs even if get state fails.) 4. Complete join. (This is in a finally block. Occurs even if get state/invalidation fail.) There needs to be a way to remove a node from the topology if it enters the FAILED state. Or, perhaps wait to add it to the topology until it enters the RUNNING state. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
6
0 / 0

[JBoss JIRA] Created: (ISPN-937) hotrod server state transfer problem during startup

by Michal Linhard (JIRA)

hotrod server state transfer problem during startup --------------------------------------------------- Key: ISPN-937 URL: https://issues.jboss.org/browse/ISPN-937 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 4.2.1.CR2 Reporter: Michal Linhard Assignee: Manik Surtani Attachments: hotrod-server-stdout.txt, hotrodconsole-0.0.1-SNAPSHOT-bin.zip, infinispan.xml This is something that happend to me when playing with hotrod servers. I've built infinispan distribution from source (mvn install -P distribution -DskipTests=true) unzipped infinispan-4.2.1.CR2-all.zip 2x to folders distro1 distro2 created 2 virtual ifaces 192.168.11.101 test1 192.168.11.102 test2 ran distro1/bin/startServer.sh -r hotrod -l test1 -c /home/mlinhard/dev/projects/infinispan/issues/infinispan.xml distro2/bin/startServer.sh -r hotrod -l test2 -c /home/mlinhard/dev/projects/infinispan/issues/infinispan.xml ran demo-hotrod-console hotrodconsole-0.0.1-SNAPSHOT/bin/console.sh test1 entered >put a a (which means put value "a" under key "a") the servers waited a bit and then server 2 wrote some errors to stdout (I guess after some timeout expired) client was still blocked, after some time produced ERROR: Invalid magic number. Expected a1 and received 50 attaching - binary version of demo-hotrod-console (source: https://github.com/mlinhard/demo-hotrod-console) - server 2 stdout - infinispan.xml I tried this with 4.2.1.CR1 and it worked. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

5
22
0 / 0

[JBoss JIRA] Created: (ISPN-272) recover from transaction failures

by Mircea Markus (JIRA)

recover from transaction failures --------------------------------- Key: ISPN-272 URL: https://jira.jboss.org/jira/browse/ISPN-272 Project: Infinispan Issue Type: Feature Request Components: Transactions Affects Versions: 5.0.0.GA Reporter: Mircea Markus Assignee: Manik Surtani We currently don't support any sort of recovery from transaction failures. E.g. tm.start(); database.delete(account); ispnCache.put(account); tm.commit(): At tm commit: -prepare is successful on both enlisted resources. - database.commit - fails What shall we do with the locks/state from ispnCache. Possible solutions: - configure to automatically commit/rollback after a timeout - keep locks on resources and allow manual intervention through JMX - others? -- 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

13 years, 1 month

4
19
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2011