January 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1632) Add XML documentation generation from XSD

by Pete Muir (Created) (JIRA)

Add XML documentation generation from XSD ----------------------------------------- Key: ISPN-1632 URL: https://issues.jboss.org/browse/ISPN-1632 Project: Infinispan Issue Type: Feature Request Components: Configuration Affects Versions: 5.1.0.CR1 Reporter: Pete Muir Assignee: Pete Muir Fix For: 5.1.0.FINAL -- 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, 6 months

9
17
0 / 0

[JBoss JIRA] Created: (ISPN-1189) config schema - clustering mode should validate format of the string

by Michal Linhard (JIRA)

config schema - clustering mode should validate format of the string -------------------------------------------------------------------- Key: ISPN-1189 URL: https://issues.jboss.org/browse/ISPN-1189 Project: Infinispan Issue Type: Enhancement Components: Configuration Affects Versions: 5.0.0.CR5 Reporter: Michal Linhard Assignee: Manik Surtani Priority: Minor currently the schema for the clustering mode says it's a string and the mode is decided by first letter of the string. this means that any garbage starting with the correct letter may lead to use of a specific mode e.g.: lasjadgadfg -> local rhdbhgh -> replication dfghbmjfgh -> distribution IlkHhdf -> invalidation what about forcing only the documented values "For distribution, set mode to either 'd', 'dist' or 'distribution'. For replication, use either 'r', 'repl' or 'replication'. Finally, for invalidation, 'i', 'inv' or 'invalidation'." + LOCAL -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

5
5
0 / 0

[JBoss JIRA] Created: (ISPN-1120) Wiki for putForExternalRead usage

by Galder Zamarreño (JIRA)

Wiki for putForExternalRead usage --------------------------------- Key: ISPN-1120 URL: https://issues.jboss.org/browse/ISPN-1120 Project: Infinispan Issue Type: Task Reporter: Galder Zamarreño Assignee: Galder Zamarreño Priority: Minor Fix For: 5.0.0.CR3 Create wiki on usage pattern of putForExternal() read. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

3
7
0 / 0

[JBoss JIRA] Created: (ISPN-1341) Eviction treats FIFO as LRU

by Jozef Vilkolak (JIRA)

Eviction treats FIFO as LRU --------------------------- Key: ISPN-1341 URL: https://issues.jboss.org/browse/ISPN-1341 Project: Infinispan Issue Type: Bug Components: Eviction Affects Versions: 5.0.0.FINAL Reporter: Jozef Vilkolak Assignee: Manik Surtani When a cache is created with eviction strategy set to FIFO it is actually treated as being LRU. This can be seen in org.infinispan.container.DefaultDataContainer.java. Functional test for FIFO eviction can be found at [https://svn.devel.redhat.com/repos/jboss-qa/edg/edg-functional-tests/trunk/] in the eviction-strategy module. Basically what the test does is insert 3 values into the cache then retrieves the first value(to differentiate FIFO and LRU) and inserts 4th value which sets eviction in motion because of maxEntries=3. I would expect the first entered value ("A") to be evicted instead it evicts the second ("B"). It uses the following cache configuration: {code:xml} <local-cache name="fifo" start="EAGER" batching="false" indexing="NONE"> <locking isolation="REPEATABLE_READ" acquire-timeout="20000" concurrency-level="500" striping="false" /> <eviction strategy="FIFO" max-entries="3" interval="2000"/> </local-cache> {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

5
6
0 / 0

[JBoss JIRA] (ISPN-1581) Improve resiliency of retrying commits on state transfer

by Erik Salter (Created) (JIRA)

Improve resiliency of retrying commits on state transfer --------------------------------------------------------- Key: ISPN-1581 URL: https://issues.jboss.org/browse/ISPN-1581 Project: Infinispan Issue Type: Enhancement Affects Versions: 5.1.0.CR1 Reporter: Erik Salter Assignee: Manik Surtani The current implementation of ISPN-1484 will retry up to 3 times to retry a commit on a remote node. This is resilient to 3 state transfers happening in rapid succession. However, if the cluster loses > 3 nodes, there can still be stale locks. This is evident in testing this with the TopologyAwareConsistentHash. I lost a "site" consisting of 4 nodes, and I was able to get stale locks. -- 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, 6 months

9
10
0 / 0

[JBoss JIRA] (ISPN-1650) Sample configurations to be updated to reflect new transaction options

by Manik Surtani (Created) (JIRA)

Sample configurations to be updated to reflect new transaction options ---------------------------------------------------------------------- Key: ISPN-1650 URL: https://issues.jboss.org/browse/ISPN-1650 Project: Infinispan Issue Type: Task Components: Configuration, Transactions Affects Versions: 5.1.0.CR2 Reporter: Manik Surtani Assignee: Mircea Markus Fix For: 5.1.0.CR3 Sample config files - like config-samples/sample.xml - contains references to old transactional attributes. These are commented out and meant for reuse by uncommenting; they should have the new attributes. -- 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, 6 months

4
4
0 / 0

[JBoss JIRA] (ISPN-1608) Update Infinispan sample module

by Galder Zamarreño (Created) (JIRA)

Update Infinispan sample module ------------------------------- Key: ISPN-1608 URL: https://issues.jboss.org/browse/ISPN-1608 Project: Infinispan Issue Type: Task Reporter: Galder Zamarreño Assignee: Galder Zamarreño Priority: Minor Fix For: 5.1.0.FINAL Once 5.1.0.CR2 is out, update the sample module. -- 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, 6 months

5
4
0 / 0

[JBoss JIRA] (ISPN-1602) Single view change causes stale locks

by Erik Salter (Created) (JIRA)

Single view change causes stale locks ------------------------------------- Key: ISPN-1602 URL: https://issues.jboss.org/browse/ISPN-1602 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.1.0.CR1 Reporter: Erik Salter Assignee: Manik Surtani During load testing of 5.1.0.CR1, we're encountering JGroups 3.x dropping views. We know due to ISPN-1581, if the number of view changes > 3, there could be a stale lock on a failed commit. However, we're seeing stale locks occur on a single view change. In the following logs, the affected cluster is the erm-cluster-xxxx (We also don't know why JGroups 3.x is unstable. We suspected FLUSH and incorrect FD settings, but we removed them, and we're still getting dropped messages) The trace logs (It isn't long at all before the issue occurs) are at: http://dl.dropbox.com/u/50401510/5.1.0.CR1/dec08viewchange/dht10/server.l... http://dl.dropbox.com/u/50401510/5.1.0.CR1/dec08viewchange/dht11/server.l... http://dl.dropbox.com/u/50401510/5.1.0.CR1/dec08viewchange/dht12/server.l... http://dl.dropbox.com/u/50401510/5.1.0.CR1/dec08viewchange/dht13/server.l... http://dl.dropbox.com/u/50401510/5.1.0.CR1/dec08viewchange/dht14/server.l... http://dl.dropbox.com/u/50401510/5.1.0.CR1/dec08viewchange/dht15/server.l... -- 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, 6 months

12
27
0 / 0

[JBoss JIRA] (ISPN-1662) CacheViewsManager should call the cache view listener's commitView() method committing the view

by Dan Berindei (Created) (JIRA)

CacheViewsManager should call the cache view listener's commitView() method committing the view ----------------------------------------------------------------------------------------------- Key: ISPN-1662 URL: https://issues.jboss.org/browse/ISPN-1662 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.1.0.CR2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.1.0.CR3, 5.1.0.FINAL Currently the keys that are no longer owned by a node are only invalidated during the listener's `commitView()`, we may be invalidate the keys only after another state transfer has already started - which could lead to inconsistencies. -- 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, 6 months

6
9
0 / 0

[JBoss JIRA] (ISPN-1658) RPCs invoked with SYNCRONOUS_IGNORE_LEAVERS taking too long if one of the targets had already left

by Dan Berindei (Created) (JIRA)

RPCs invoked with SYNCRONOUS_IGNORE_LEAVERS taking too long if one of the targets had already left -------------------------------------------------------------------------------------------------- Key: ISPN-1658 URL: https://issues.jboss.org/browse/ISPN-1658 Project: Infinispan Issue Type: Bug Components: RPC Affects Versions: 5.1.0.CR2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.1.0.CR3, 5.1.0.FINAL We were waiting for responses from the leavers as well, and then we were ignoring the timeout. Instead we should remove the leavers from the targets list before sending the command. `SYNCHRONOUS_IGNORE_LEAVERS` is used for `CommitCommand`s and `CacheViewControlCommand{COMMIT_VIEW}`s, if this happens it will block the cache view installation (and so the entire cluster) until the RPC timeout expires. -- 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, 6 months

8
10
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2012