September 2011 - infinispan-issues

[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, 12 months

5
6
0 / 0

[JBoss JIRA] Created: (ISPN-951) Infinispan Query module should load entities using getAsync

by Sanne Grinovero (JIRA)

Infinispan Query module should load entities using getAsync ----------------------------------------------------------- Key: ISPN-951 URL: https://issues.jboss.org/browse/ISPN-951 Project: Infinispan Issue Type: Enhancement Components: Querying Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.1.0.BETA1 Requires migration to new Loader API from Hibernate Search -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

2
9
0 / 0

[JBoss JIRA] Created: (ISPN-284) Streamed rehashing

by Manik Surtani (JIRA)

Streamed rehashing ------------------ Key: ISPN-284 URL: https://jira.jboss.org/jira/browse/ISPN-284 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Affects Versions: 4.0.0.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.BETA1, 4.1.0.GA Currently rehashing uses RPC which uses byte array representations of state. These could use streams, perhaps using JGroups' STREAMING_STATE_TRANSFER sockets, for greater performance and robustness. -- 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

12 years, 12 months

9
22
0 / 0

[JBoss JIRA] Created: (ISPN-956) Update RESTEasy version used by REST server

by Michal Linhard (JIRA)

Update RESTEasy version used by REST server ------------------------------------------- Key: ISPN-956 URL: https://issues.jboss.org/browse/ISPN-956 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Michal Linhard Assignee: Michal Linhard Priority: Minor Fix For: 4.2.1.FINAL, 5.0.0.BETA1 Update RESTEasy version (currently 2.0-beta-2) used by REST server to a stable one (2.0.1.GA or 2.1.0.GA). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

4
8
0 / 0

[JBoss JIRA] Created: (ISPN-1429) remove lock guards(if trace.enabled() .. ) where possible

by Mircea Markus (JIRA)

remove lock guards(if trace.enabled() .. ) where possible --------------------------------------------------------- Key: ISPN-1429 URL: https://issues.jboss.org/browse/ISPN-1429 Project: Infinispan Issue Type: Enhancement Reporter: Mircea Markus Assignee: Manik Surtani Citing from David Lloyd's email: <snip> If you're using the jboss-logging API, and your log statement does not do any interpolation, then it is just as fast to do any of the following (with no if): log.trace("blah"); log.tracef("the %s happened to %s", foo, bar); log.tracev("the {0} happened to {1}", foo, bar); In the case where trace logging is disabled, these are exactly as efficient as the if (log.isTraceEnabled()) variants. In the case where it is enabled, it is marginally more efficient (though the trace log itself is substantially more expensive of course). Overall I'd avoid the "if" forms unless you're doing complex interpolation: log.trace("Foo " + bar + " baz " + zap); log.tracef("the %s happened to %s", fooMethod().barMethod(), bar); ...both of which incur the expense of the expression resolution even if the log message is ultimately discarded. </snip> This JIRA is about: 1. removing all the "if (trace)" statements from the code (where possible, see below) 2. making sure that this is a documented policy and people are aware of it -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

5
6
0 / 0

[JBoss JIRA] Created: (ISPN-1309) Provide a way to use Flags without resorting to a ThreadLocal

by Sanne Grinovero (JIRA)

Provide a way to use Flags without resorting to a ThreadLocal ------------------------------------------------------------- Key: ISPN-1309 URL: https://issues.jboss.org/browse/ISPN-1309 Project: Infinispan Issue Type: Feature Request Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 6.0.0.FINAL A brief performance analysis highlighted a significant impact on performance because of the use of ThreadLocals to hold the enabled flags in the current context. We should check these findings with a proper test and provide an alternative way, ideally one which doesn't need to lookup in the flagHolder either (avoid both the put and the get in the threadlocal). We'll need a method which returns a new Cache instance having the mentioned Flags always implicitly added to the invocation context. I think it would be fine in such an alternative implementation to not support dynamic flags. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

3
2
0 / 0

[JBoss JIRA] Created: (ISPN-1058) Add tests to verify virtual nodes distribution

by Pete Muir (JIRA)

Add tests to verify virtual nodes distribution ---------------------------------------------- Key: ISPN-1058 URL: https://issues.jboss.org/browse/ISPN-1058 Project: Infinispan Issue Type: Task Affects Versions: 5.0.0.BETA2 Reporter: Pete Muir Assignee: Pete Muir Fix For: 5.0.0.CR1 Whilst virtual nodes are passing existing tests verifying Inifinispan works, we don't have any tests verifying how virtual nodes distribute data. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

6
12
0 / 0

[JBoss JIRA] Created: (ISPN-263) Handle JGroups MERGE events to help deal with split brains

by Manik Surtani (JIRA)

Handle JGroups MERGE events to help deal with split brains ---------------------------------------------------------- Key: ISPN-263 URL: https://jira.jboss.org/jira/browse/ISPN-263 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.BETA1, 5.0.0.GA JGroups already detects split brains and issues a callback. The cache layer needs to decide what to do. The idea is to implement a few canned policies (restart, wipe, etc) and allow custom handlers to be attached as well. Analogous to JBCACHE-471 -- 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
3
0 / 0

[JBoss JIRA] Created: (ISPN-1123) Stabilise test suite

by Manik Surtani (JIRA)

Stabilise test suite -------------------- Key: ISPN-1123 URL: https://issues.jboss.org/browse/ISPN-1123 Project: Infinispan Issue Type: Task Components: Core API Affects Versions: 5.0.0.CR2 Reporter: Manik Surtani Assignee: Dan Berindei Priority: Blocker Fix For: 5.0.0.FINAL The current test suite on http://hudson.infinispan.org is pretty unstable. Some tests have been disabled to allow it to run with 100% pass rate. Please investigate these disabled tests. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

8
33
0 / 0

[JBoss JIRA] Created: (ISPN-1065) Use a better mechanism to parse config files

by Manik Surtani (JIRA)

Use a better mechanism to parse config files -------------------------------------------- Key: ISPN-1065 URL: https://issues.jboss.org/browse/ISPN-1065 Project: Infinispan Issue Type: Enhancement Components: Configuration Affects Versions: 4.2.1.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.Final The current codebase heavily relies on JAXB to: 1. Generate a XSD schema from a Configuration bean 2. Generate a parser to use with an XML configuration This is known to be slow, and can significantly add to start up time: {quote} We did some analysis of our AS6 descriptor code which was using JAXB (800ms), compared to straight stax (10ms) {quote} A possible solution could be to still use JAXB to generate the schema, but to also write a Maven plugin which would generate a STAX parser based on the XSD schema and Configuration bean at build time. Infinispan would then use this STAX parser rather than a JAXB generated parser, which would be a lot faster. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

8
24
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2011