April 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1079) Allow users to specify a build directory

by Dan Berindei (JIRA)

Allow users to specify a build directory ---------------------------------------- Key: ISPN-1079 URL: https://issues.jboss.org/browse/ISPN-1079 Project: Infinispan Issue Type: Enhancement Affects Versions: 5.0.0.BETA2, 4.2.1.FINAL, 4.2.2.BETA1 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Optional Fix For: 4.2.2.FINAL, 5.0.0.CR1, 5.0.0.FINAL If a user wants to speed up the build by compiling to a ramdisk, he should be able to set the build directory in ~/.m2/settings.xml, something like this: <settings> <profiles> <profile> <properties> <buildDirectory>/tmp/privatebuild/${project.basedir}/${project.version}</buildDirectory> </properties> </profile> </profiles> </settings> -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

4
10
0 / 0

[JBoss JIRA] Created: (ISPN-1077) Multiple leaves are not handled correctly with DIST

by Mircea Markus (JIRA)

Multiple leaves are not handled correctly with DIST ---------------------------------------------------- Key: ISPN-1077 URL: https://issues.jboss.org/browse/ISPN-1077 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 4.2.0.Final Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 4.2.2.FINAL, 5.0.0.FINAL When multiple caches are leaving at the same time(i.e. the diff between jgroups views is more than one address), Infinispan ends up with an inconsistent hash function: it is aware about nodes that are no longer present in the cluster. The root cause of the problem is in DistributionManagerImpl.rehash(...): - the list of leavers is determined as follows: Address leaver = MembershipArithmetic.getMemberLeft(oldMembers, newMembers); - this method always assumes a single leaver, but there can be many. Unit test attached. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
12
0 / 0

[JBoss JIRA] Created: (ISPN-909) Segments locked during merge

by Tristan Tarrant (JIRA)

Segments locked during merge ---------------------------- Key: ISPN-909 URL: https://issues.jboss.org/browse/ISPN-909 Project: Infinispan Issue Type: Bug Components: Lucene Directory Affects Versions: 4.2.0.Final Reporter: Tristan Tarrant Assignee: Sanne Grinovero Attachments: rabbit-1-mergelock.log, rabbit-2-mergelock.log We're getting failures on acquiring locks during merges. Here is the configuration: Infinispan: 3 caches: lockCache (replicated, volatile, no eviction), metadataCache (replicated, persisted, no eviction), dataCache (distributed, persisted, eviction). Node 1: coordinator, IndexWriter open constantly and writing a stream of documents Node 2: opens a read-only IndexReader on-demand to perform queries (we're moving to use IndexReader.reopen() ). Occasionally when performing queries on node 2 we get the attached stack traces. We then get corrupt indexes (java.io.IOException: Read past EOF). We are using the default Distributed Segment Lock Reader, default 16K chunks and no tuning of the merge policies. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
7
0 / 0

[JBoss JIRA] Created: (ISPN-1049) transaction participant failure after prepare causes data inconsistency

by Mircea Markus (JIRA)

transaction participant failure after prepare causes data inconsistency ------------------------------------------------------------------------ Key: ISPN-1049 URL: https://issues.jboss.org/browse/ISPN-1049 Project: Infinispan Issue Type: Feature Request Components: Transactions Affects Versions: 4.2.1.FINAL Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.0.0.FINAL cluster {A, B, C, D}, dist, numOwners=3. transaction started on A touches B and C. A prepares then C crashes. When TM commits the user gets a TimeoutException as commit rpc to C failed. The state of the cluster after commit is: tx state successfully applied on A and B, but not on D! The tx should successfully be applied on D as well, as numOwners=3. Or, at least, it should rollback on A and B as well; the point being the cluster should remain in a consistent state. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-878) update documentation for http://community.jboss.org/wiki/MultipleTiersofCaches

by Mircea Markus (JIRA)

update documentation for http://community.jboss.org/wiki/MultipleTiersofCaches ------------------------------------------------------------------------------- Key: ISPN-878 URL: https://issues.jboss.org/browse/ISPN-878 Project: Infinispan Issue Type: Task Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.0.0.Final Update http://community.jboss.org/wiki/MultipleTiersofCaches as follows: Feedback from Galder: though, the text in the diagram is very very small and can hardly be read. Maybe you can improve it a little? Feedback from Manik: Also some more feedback: * Spelling: "Multi-Tiered", not "Multiered" * Your diagram probably wants to demonstrate 2 separate tiers, not just 1 client with a clustered server backend. E.g., FE1 --- FE2 --- FE3 =============== BE1 --- BE2 --- BE3 where FE = front-end servers (embedded, maybe an app server running a webapp, with an embedded Infinispan instance as a "near cache") BE = backend, dedicated cache tier, running Hot Rod endpoints FE configured with RemoteCacheStore, and also using Invalidation so that FE's can invalidate each other BE's running DIST for max addressable space + ultimate scalability This way, with the FE's running in INVAL mode, it doesn't matter if the BE's cannot communicate changes back to the FE's, since the FE's wil already know about changes and will invalidate accordingly. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-1080) Investigate and document XA recovery integration with JBossTS

by Mircea Markus (JIRA)

Investigate and document XA recovery integration with JBossTS ------------------------------------------------------------- Key: ISPN-1080 URL: https://issues.jboss.org/browse/ISPN-1080 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.0.0.FINAL Reading the JBossTS recovery documentation[1], the recovery process should be able to pull recovery info from ISPN's XAResource implementation by calling .recover(). The issue is that this method needs to be called in the same process where ISPN node leaves and ATM its not possible to invoke it from a different process. This would also be useful for users that want to set up/play with transaction recovery in general. [1] http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/4... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
4
0 / 0

[JBoss JIRA] Created: (ISPN-877) analyse, document and suggest indexing the JDBC cache store

by Mircea Markus (JIRA)

analyse, document and suggest indexing the JDBC cache store ----------------------------------------------------------- Key: ISPN-877 URL: https://issues.jboss.org/browse/ISPN-877 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Affects Versions: 4.2.0.Final Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.0.0.ALPHA2 Adding indexes to the JDBC cache store's backend table can drastically increase performance especially for the JdbcStringBasedCacheStore and partially for the JdbcMixedCacheStore. Investigate weather indexes can be defined through Jdbc in a portable manner (same way the tables are created on startup) or at least update documentation to describe how indexes should be defined and the advantages of having them defined. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
9
0 / 0

[JBoss JIRA] Created: (ISPN-965) Query for loading some rows from CacheStore is not correct for HSQLDB 1.8.0.7

by Anatoliy Bazko (JIRA)

Query for loading some rows from CacheStore is not correct for HSQLDB 1.8.0.7 ----------------------------------------------------------------------------- Key: ISPN-965 URL: https://issues.jboss.org/browse/ISPN-965 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.2.0.Final Environment: JBoss AS 5.1.0.GA HSQLDB 1.8.0.7 Reporter: Anatoliy Bazko Assignee: Manik Surtani Loading data from CacheStore using method public final Set<InternalCacheEntry> loadSome(int maxEntries) throws CacheLoaderException failed due to query "SELECT %s, %s FROM %s LIMIT ?" is not correct for HSQLDB 1.8.0.7 since it required "ORDER BY" before "LIMIT" -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

4
10
0 / 0

[JBoss JIRA] Created: (ISPN-977) KeyAffinityService issue on topology change

by Mircea Markus (JIRA)

KeyAffinityService issue on topology change ------------------------------------------- Key: ISPN-977 URL: https://issues.jboss.org/browse/ISPN-977 Project: Infinispan Issue Type: Bug Affects Versions: 4.2.1.CR4 Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.0.0.Final Complete bug description and usable UT on the forums: http://community.jboss.org/message/592275#592275 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
12
0 / 0

[JBoss JIRA] Created: (ISPN-360) create NodeJoined event

by Mircea Markus (JIRA)

create NodeJoined event ----------------------- Key: ISPN-360 URL: https://jira.jboss.org/jira/browse/ISPN-360 Project: Infinispan Issue Type: Feature Request Components: Listeners, State transfer Reporter: Mircea Markus Assignee: Manik Surtani In relation to http://community.jboss.org/message/529547#529547 It's an well known scenario to start a cluster, and only after the ENTIRE cluster is started to start and do work. Right now, we have CacheStarted and ViewChanged notifications. First only tells us that the local node is started but other nodes might still be in the process of starting. Second one tells us that the view has changed, but not that the cluster has started, i.e. the cache might be in the process of rebalancing state etc. A possible solution would be to have an NodeJoined event, that would be called whenever a new node finished joining the cluster. Finished joining means state transfer happened and that node is started. For a possible workaround to this feature see the forum post. -- 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, 7 months

4
12
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2011