March 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-555) Remote nodes should have a user cfg timeout before heuristic rollback

by Mircea Markus (JIRA)

Remote nodes should have a user cfg timeout before heuristic rollback --------------------------------------------------------------------- Key: ISPN-555 URL: https://jira.jboss.org/browse/ISPN-555 Project: Infinispan Issue Type: Feature Request Components: Transactions Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.1.0.BETA1 This is code in TransactionTable.StaleTransactionCleanup. This is because the failing might get restarted and it can finish the transaction in a coordinated, non-heuristic manner. -- 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

13 years, 1 month

4
10
0 / 0

[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

13 years, 1 month

3
6
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

13 years, 1 month

5
6
0 / 0

[JBoss JIRA] Created: (ISPN-439) Define and implement configuration file backward and forward compatibility policy

by Vladimir Blagojevic (JIRA)

Define and implement configuration file backward and forward compatibility policy --------------------------------------------------------------------------------- Key: ISPN-439 URL: https://jira.jboss.org/jira/browse/ISPN-439 Project: Infinispan Issue Type: Task Affects Versions: 4.1.0.BETA1 Reporter: Vladimir Blagojevic Assignee: Manik Surtani Fix For: 4.1.0.CR1 Backward compatibility: Process any previous version configuration file from the same minor version. For example, Infinispan release 4.2 should process configuration file produced for version 4.1 without any configuration file changes or any other adjustments. For configuration options present in 4.2, but not in 4.1 assume default values. However, Infinispan version 5.0 is not required to process configuration files from previous major versions, i.e 4.0...4.x. Forward compatibility. Do not process any forward version configuration file. For example, Infinispan release 4.1, give configuration file input from any succeeding versions (i.e 4.2...4.x, 5.x) would simply fail outright with proper error message. -- 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, 2 months

7
26
0 / 0

[JBoss JIRA] Created: (ISPN-658) DistributionManager not considerate of cache state changes

by Paul Ferraro (JIRA)

DistributionManager not considerate of cache state changes ---------------------------------------------------------- Key: ISPN-658 URL: https://jira.jboss.org/browse/ISPN-658 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 4.2.0.ALPHA2 Reporter: Paul Ferraro Assignee: Manik Surtani Considering a cache manager with 2 caches in DIST mode (C1 and C2) deployed on 2 nodes (N1 and N2). Currently, the DistributionManager does not properly handle the following scenarios: 1. Stop C1 on N1. This ought to trigger a rehash for the C1 cache. Currently, rehashing is only triggered via view change. Failure to rehash on stopping of a cache can inadvertently cause data loss, if all backups of a given cache entry have stopped. 2. A new DIST mode cache, C3, is started on N2. If N1 is the coordinator, the join request sent to N1 will get stuck in an infinite loop, since the cache manager on N1 does not contain a C3 cache. 3. Less critically, a new node, N3 is started. It does not yet have a C1 or C2 cache, though it's cache manager is started. This prematurely triggers a rehash of C1 and C2, even though there are no new caches instances to consider. -- 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

13 years, 2 months

11
24
0 / 0

[JBoss JIRA] Created: (ISPN-434) Creating a new distributed cache on a non-coordinator node causes rehashing to hang

by Manik Surtani (JIRA)

Creating a new distributed cache on a non-coordinator node causes rehashing to hang ----------------------------------------------------------------------------------- Key: ISPN-434 URL: https://jira.jboss.org/jira/browse/ISPN-434 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 4.1.0.ALPHA3 Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR1, 4.1.0.Final If a cluster is already formed (perhaps due to another cache instance being started, such as a replicated one) and subsequently a distributed cache is created and started, first on a non-coordinator node, the startup sequence will hang until the cache is also started on the coordinator. E.g., 1. C1 (coord) starts replicated cache 2. C2 starts replicated cache 3. C2 starts distributed cache 4. C1 starts distributed cache Step 3 will hang until step 4 completes. So unless these happen in different threads - on different servers - this rehash will hang. -- 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, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-448) Consider all topology cache updates to be done by coordinator in Hot Rod

by Galder Zamarreno (JIRA)

Consider all topology cache updates to be done by coordinator in Hot Rod ------------------------------------------------------------------------ Key: ISPN-448 URL: https://jira.jboss.org/browse/ISPN-448 Project: Infinispan Issue Type: Task Components: Cache Server Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 5.0.0.BETA1 Based on the discussion below, consider all topology cache updates to be done by coordinator to avoid concurrency issues when updating it. > Looks good. > What is causing this unsuccessful add? If it is caused by timeouts due > to multiple caches operating on the same key an alternative would be > to only perform the operation on the coordinator and rest of the > members to have node added listeners ... Currently, each node when it starts, it's responsible of adding itself to the view and when it stops, it's responsible from removing itself. Apart from this, there's a crashed member listener running only in coordinator that detects whether any member left without updating the topology view. Your suggestion to have the coordinator control it all seems like could work and get around potential timeouts. I'll create a JIRA to investigate this but won't do it for CR1 since I'm expect this to be a major issue. Metadata size is small and it's not constantly uddated. -- 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

13 years, 3 months

4
7
0 / 0

[JBoss JIRA] Created: (ISPN-302) Enable templated values for manually adding instances via jopr

by Galder Zamarreno (JIRA)

Enable templated values for manually adding instances via jopr -------------------------------------------------------------- Key: ISPN-302 URL: https://jira.jboss.org/jira/browse/ISPN-302 Project: Infinispan Issue Type: Feature Request Components: JMX, reporting and management Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Enable templated values for manually adding instances via jopr >> For manually importing - you should in the plugin descriptor put the JMX-remoting url as >> >> default -- perhaps with the port as XXX, so the user does not have to copy& paste from an >> >> external location, but only click in the text field and replace XXX by the real port. >> >> same for Objectname of the cache manager. > > > > I did that. I told you it did not work and your reply was that it was fragile and you didn't looked into it further... You / we were talking about c:template - which would allow to have several templates -- see jmx-plugin e.g http://git.fedorahosted.org/git/rhq/rht.git?p=rhq/rhq.git;a=blob;f=module... from line 47 on What you can do, an which works is <c:simple-property name="v1Community" type="string" default="public"/> Here the default value 'public' is shown to the user for this property. Sorry that I was confusing things Heiko -- 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, 3 months

3
3
0 / 0

[JBoss JIRA] Created: (ISPN-200) Distributed queries

by Manik Surtani (JIRA)

Distributed queries ------------------- Key: ISPN-200 URL: https://jira.jboss.org/jira/browse/ISPN-200 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, Querying Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.GA The holy grail of querying. * Indexes are _never_ shared. * Each node maintains local indexes for state it is responsible for (-Dinfinispan.query.indexLocalOnly=true). * Indexes could be in memory or disk. * Queries themselves are distributed. * The query object is built and broadcast to the entire cluster. * Each node executes the query on its own _local_ index, returning results. * The calling node returns a CacheQuery impl that lazily fetches and collates results from the cluster. * I expect this Map/Reduce model to perform very well since the workload is split up and happens in parallel across multiple CPUs against much smaller (individual) datasets. * Works with all cache modes, including DIST. * Need to make sure duplicates are handled, as well as failover. -- 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, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-813) "Infinispan Cache Manager" option doesn't show up in the drop down menu for "Manually add" function

by Michal Linhard (JIRA)

"Infinispan Cache Manager" option doesn't show up in the drop down menu for "Manually add" function --------------------------------------------------------------------------------------------------- Key: ISPN-813 URL: https://jira.jboss.org/browse/ISPN-813 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Affects Versions: 4.2.0.CR2 Reporter: Michal Linhard Assignee: Manik Surtani infinispan 4.2.0.CR2 RHQ version: 3.0.0 build number: 59e9341 postgresql 8.4.5 I've setup RHQ with infinispan-jopr-plugin as described here: http://community.jboss.org/wiki/MonitoringInfinispanwithRHQ I'm running this on my local machine having these virtual interfaces 192.168.10.101 test1 192.168.10.102 test2 192.168.10.103 test3 192.168.10.104 test4 192.168.10.105 test5 192.168.10.106 test6 test1 - test4 running jboss 5.1.0.GA with infinispan-gridfs-webdav demo (ran with -Dcom.sun.management.jmxremote.port=6991 to 9664 respectively) test1 - test2 running rhq-agent bound to respective interface test5 running rhq-server sucessfully installed RHQ server sucessfully installed agents test1 test2 sucessfully imported platforms test1 and test2 sucessfully installed infinispan-jopr-plugin, updated agents tried to manually add Infinispan Cache Manager according to the instructions: "To add Infinispan instances manually, go to Resources > Platforms > localhost and then click on Inventory. At the bottom of the page, there's a section that says "Manually Add" and next to it there's a drop down list. Open this list, select "Infinispan Cache Manager" and click Ok." but the option "Infinispan Cache Manager" doesn't appear in the drop down box. i don't know wheter this is a RHQ bug or plugin bug or wheter there's something wrong with my installation steps. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
32
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2011