September 2014 - infinispan-issues

[JBoss JIRA] (ISPN-2392) Optimize locking behaviour in non-transactional caches

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2392?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-2392. -------------------------------- Fix Version/s: 5.3.0.Final Resolution: Done > Optimize locking behaviour in non-transactional caches > ------------------------------------------------------ > > Key: ISPN-2392 > URL: https://issues.jboss.org/browse/ISPN-2392 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Transactions > Affects Versions: 5.2.0.Beta1 > Reporter: Thomas Fromm > Assignee: Adrian Nistor > Fix For: 5.3.0.Final > > > Situation: REPL_SYNC cache, non transactional, locking isolation level NONE > Problem: when multiple threads trying to write same key on multiple nodes, the operation ends up mostly in locking timeouts > Mircea mentioned that the locking behaviour for non-tx caches could be optimized as well as for tx-caches or use the same mechanisms. > (One single lock, independed number of owners) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4677) Map/Reduce job fails with the wrong explanation on underlying TimeoutException

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4677?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4677: ------------------------------- Assignee: Vladimir Blagojevic (was: Dan Berindei) > Map/Reduce job fails with the wrong explanation on underlying TimeoutException > ------------------------------------------------------------------------------ > > Key: ISPN-4677 > URL: https://issues.jboss.org/browse/ISPN-4677 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Distributed Execution and Map/Reduce > Affects Versions: 7.0.0.Beta1 > Reporter: Sanne Grinovero > Assignee: Vladimir Blagojevic > Fix For: 7.0.0.Beta2 > > > I'm running a task which is throwing the following exception during the Map phase: > {noformat} > org.infinispan.util.concurrent.TimeoutException: Node main-NodeC-22183 timed out{noformat} > The user facing error however is this very confusing message: > {noformat}org.infinispan.commons.CacheException: java.util.concurrent.ExecutionException: Map phase executing at main-NodeA-39904 did not complete within 0 sec timeout{noformat} > I have no timeout enabled. > The problem is the instanceof operation on the cause of the error in org.infinispan.distexec.mapreduce.MapReduceTask.executeMapPhaseWithLocalReduction(Map<KOut, VOut>): the check on the type only is not good enough. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4678) Trim down ExpandableMarshalledValueByteStream to the actual data length before storing in cache

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4678?page=com.atlassian.jira.plugin.... ] Dan Berindei edited comment on ISPN-4678 at 9/2/14 7:01 AM: ------------------------------------------------------------ [~mgencur] the default max doubling size is actually 4MB, not 4KB, but I don't think we should be doubling the size at all: StringBuillder uses a 1.5 growth factor, and we could do the same. If we changed the growth factor to 1.5, I'm not sure it would still make sense to "shrink" the ExpandableMarshalledValueByteStream by moving it into a new instance (or a new ImmutableMarshalledValueByteStream). We could also do the move only if the wasted space is greater than a threshold (say 20% of the buffer). was (Author: dan.berindei): [~mgencur]] the default max doubling size is actually 4MB, not 4KB, but I don't think we should be doubling the size at all: StringBuillder uses a 1.5 growth factor, and we could do the same. If we changed the growth factor to 1.5, I'm not sure it would still make sense to "shrink" the ExpandableMarshalledValueByteStream by moving it into a new instance (or a new ImmutableMarshalledValueByteStream). We could also do the move only if the wasted space is greater than a threshold (say 20% of the buffer). > Trim down ExpandableMarshalledValueByteStream to the actual data length before storing in cache > ----------------------------------------------------------------------------------------------- > > Key: ISPN-4678 > URL: https://issues.jboss.org/browse/ISPN-4678 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Beta1 > Reporter: Martin Gencur > Assignee: Martin Gencur > > When storeAsBinary configuration flag is used, the ExpandableMarshalledValueByteStream is used to serialize objects to byte arrays. > However, for value size up to 4kB, almost half of the space for each cache entry can be wasted because the ByteStream is stored as is - with the additional space for future expansion. > For value size greater than 4kB, only additional 25% of actual value size can be wasted. But as these values can be quite large, the wasted space gets bigger too. > It is not necessary to store ExpandableMarshalledValueByteStream as is and can be shrinked to actual data size before storing in cache. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4678) Trim down ExpandableMarshalledValueByteStream to the actual data length before storing in cache

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4678?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4678: ------------------------------------ I meant it for [~mgencur], of course :) > Trim down ExpandableMarshalledValueByteStream to the actual data length before storing in cache > ----------------------------------------------------------------------------------------------- > > Key: ISPN-4678 > URL: https://issues.jboss.org/browse/ISPN-4678 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Beta1 > Reporter: Martin Gencur > Assignee: Martin Gencur > > When storeAsBinary configuration flag is used, the ExpandableMarshalledValueByteStream is used to serialize objects to byte arrays. > However, for value size up to 4kB, almost half of the space for each cache entry can be wasted because the ByteStream is stored as is - with the additional space for future expansion. > For value size greater than 4kB, only additional 25% of actual value size can be wasted. But as these values can be quite large, the wasted space gets bigger too. > It is not necessary to store ExpandableMarshalledValueByteStream as is and can be shrinked to actual data size before storing in cache. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4678) Trim down ExpandableMarshalledValueByteStream to the actual data length before storing in cache

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4678?page=com.atlassian.jira.plugin.... ] Dan Berindei edited comment on ISPN-4678 at 9/2/14 7:01 AM: ------------------------------------------------------------ [~mgencur]] the default max doubling size is actually 4MB, not 4KB, but I don't think we should be doubling the size at all: StringBuillder uses a 1.5 growth factor, and we could do the same. If we changed the growth factor to 1.5, I'm not sure it would still make sense to "shrink" the ExpandableMarshalledValueByteStream by moving it into a new instance (or a new ImmutableMarshalledValueByteStream). We could also do the move only if the wasted space is greater than a threshold (say 20% of the buffer). was (Author: dan.berindei): [~afield] the default max doubling size is actually 4MB, not 4KB, but I don't think we should be doubling the size at all: StringBuillder uses a 1.5 growth factor, and we could do the same. If we changed the growth factor to 1.5, I'm not sure it would still make sense to "shrink" the ExpandableMarshalledValueByteStream by moving it into a new instance (or a new ImmutableMarshalledValueByteStream). We could also do the move only if the wasted space is greater than a threshold (say 20% of the buffer). > Trim down ExpandableMarshalledValueByteStream to the actual data length before storing in cache > ----------------------------------------------------------------------------------------------- > > Key: ISPN-4678 > URL: https://issues.jboss.org/browse/ISPN-4678 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Beta1 > Reporter: Martin Gencur > Assignee: Martin Gencur > > When storeAsBinary configuration flag is used, the ExpandableMarshalledValueByteStream is used to serialize objects to byte arrays. > However, for value size up to 4kB, almost half of the space for each cache entry can be wasted because the ByteStream is stored as is - with the additional space for future expansion. > For value size greater than 4kB, only additional 25% of actual value size can be wasted. But as these values can be quite large, the wasted space gets bigger too. > It is not necessary to store ExpandableMarshalledValueByteStream as is and can be shrinked to actual data size before storing in cache. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3212) Modularization

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3212?page=com.atlassian.jira.plugin.... ] Tristan Tarrant resolved ISPN-3212. ----------------------------------- Fix Version/s: 6.0.0.Final (was: 7.0.0.Final) Resolution: Done > Modularization > -------------- > > Key: ISPN-3212 > URL: https://issues.jboss.org/browse/ISPN-3212 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Build process > Reporter: NadirX > Assignee: Tristan Tarrant > Fix For: 6.0.0.Final > > > This task is about restructuring Infinispan to make it more modular, including reducing compulsory dependencies -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3261) Extract clustering functionality from core to infinispan-clustering

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3261?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-3261. --------------------------------- Resolution: Rejected We're not going to do this, opting for the Uber Jar approach instead ISPN-4333 > Extract clustering functionality from core to infinispan-clustering > ------------------------------------------------------------------- > > Key: ISPN-3261 > URL: https://issues.jboss.org/browse/ISPN-3261 > Project: Infinispan > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Build process, Core > Reporter: NadirX > Assignee: Tristan Tarrant > Fix For: 7.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3807) Caching of parsed HQL queries

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3807?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3807: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2836 > Caching of parsed HQL queries > ----------------------------- > > Key: ISPN-3807 > URL: https://issues.jboss.org/browse/ISPN-3807 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Embedded Querying > Affects Versions: 6.0.0.Final > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > > We'll probably need to use a cache (lowercase) to avoid invoking ANTLR on each request. > Ideally we could think of caching parameterized templates, or recognize constants: in case of constants the output could degenerate in caching a Lucene Filter. > Priority do be defined after performance tests. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4654) AND over range queries does not work (indexless query)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4654?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4654: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1132121|https://bugzilla.redhat.com/show_bug.cgi?id=1132121] from POST to MODIFIED > AND over range queries does not work (indexless query) > ------------------------------------------------------ > > Key: ISPN-4654 > URL: https://issues.jboss.org/browse/ISPN-4654 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Embedded Querying, Remote Querying > Affects Versions: 6.0.2.Final, 7.0.0.Beta1 > Reporter: Radim Vansa > Assignee: Adrian Nistor > > Check this in QueryDslConditionsTest: > {code} > public void testAnd5() throws Exception { > QueryFactory qf = getQueryFactory(); > // range queries use different code > Query q = qf.from(getModelFactory().getUserImplClass()) > .having("id").lt(1000) > .and().having("age").lt(1000) > .toBuilder().build(); > List<User> list = q.list(); > assertEquals(3, list.size()); > } > {code} > The problem is that some subscription gets suspended and the second LT does not fire the second predicate update (and then neither the AND reevaluation). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3329) DatabaseStoredIndexTest.indexWasStored random failures

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3329?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3329: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=987927, https://bugzilla.redhat.com/show_bug.cgi?id=1135924 (was: https://bugzilla.redhat.com/show_bug.cgi?id=987927) > DatabaseStoredIndexTest.indexWasStored random failures > ------------------------------------------------------ > > Key: ISPN-3329 > URL: https://issues.jboss.org/browse/ISPN-3329 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Lucene Directory > Affects Versions: 6.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Sanne Grinovero > Labels: testsuite_stability > Fix For: 7.0.0.Beta1 > > > The test fails quite often with an assertion error like this: > {noformat} > java.lang.AssertionError: > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) > at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:41) > at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:49) > at org.infinispan.lucene.DatabaseStoredIndexTest.indexWasStored(DatabaseStoredIndexTest.java:111) > ------- Stdout: ------- > Failure on key[_0.nrm|0|16384|testing index] expected value: > ByteArray{size=6, array=0x4e524dff7c79..} actual value: > null > {noformat} > See http://ci.infinispan.org/project.html?projectId=Infinispan&tab=testDetail... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2014