September 2014 - infinispan-issues

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3807?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3807: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1136438|https://bugzilla.redhat.com/show_bug.cgi?id=1136438] from ON_QA to VERIFIED > Caching of parsed HQL queries > ----------------------------- > > Key: ISPN-3807 > URL: https://issues.jboss.org/browse/ISPN-3807 > Project: Infinispan > Issue Type: Enhancement > 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)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2932) Preloading a read only index in a cache will never hit the cacheloader

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2932?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2932: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1135580|https://bugzilla.redhat.com/show_bug.cgi?id=1135580] from ON_QA to VERIFIED > Preloading a read only index in a cache will never hit the cacheloader > ---------------------------------------------------------------------- > > Key: ISPN-2932 > URL: https://issues.jboss.org/browse/ISPN-2932 > Project: Infinispan > Issue Type: Task > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Beta1 > > > With a warm cache (with no eviction) we should never need to hit the CacheLoader again. > Was reported - specifically with DIST on multiple nodes - that occasionall IO is triggered; we should add tests to verify this doesn't happen (or to understand why it should) > I'm suspecting demand of null valued entries. > mailing list thread: http://lists.jboss.org/pipermail/infinispan-dev/2013-March/012261.html -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4601) DirectoryLoaderAdaptor computes the auto-chunk factor applying wrong rounding

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4601?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4601: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1135580|https://bugzilla.redhat.com/show_bug.cgi?id=1135580] from ON_QA to VERIFIED > DirectoryLoaderAdaptor computes the auto-chunk factor applying wrong rounding > ----------------------------------------------------------------------------- > > Key: ISPN-4601 > URL: https://issues.jboss.org/browse/ISPN-4601 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 7.0.0.Beta1 > > > Better described by the patch. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4396) DSL Query: right condition lost

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4396?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4396: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1108695|https://bugzilla.redhat.com/show_bug.cgi?id=1108695] from ON_QA to VERIFIED > DSL Query: right condition lost > ------------------------------- > > Key: ISPN-4396 > URL: https://issues.jboss.org/browse/ISPN-4396 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 7.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Adrian Nistor > Fix For: 7.0.0.Alpha5 > > > Condition created through query like this: > {code} > Query q = qf.from(User.class) > .not( > qf.having("name").eq("John") > .or(qf.having("surname").eq("Man"))) > .toBuilder().build(); > {code} > is not correctly parsed into JPQL query; it is > {code} > FROM org.infinispan.query.dsl.embedded.sample_domain_model.User _gen0 WHERE NOT (_gen0.name = 'John') > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 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: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1132121|https://bugzilla.redhat.com/show_bug.cgi?id=1132121] from ON_QA to VERIFIED > 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 > 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)

11 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 commented on ISPN-3329: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1135924|https://bugzilla.redhat.com/show_bug.cgi?id=1135924] from ON_QA to VERIFIED > DatabaseStoredIndexTest.indexWasStored random failures > ------------------------------------------------------ > > Key: ISPN-3329 > URL: https://issues.jboss.org/browse/ISPN-3329 > Project: Infinispan > Issue Type: Bug > 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)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4605) Race condition during Marshalling of Lucene Directory components would trigger nonsense during unmarshalling

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4605?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4605: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1135924|https://bugzilla.redhat.com/show_bug.cgi?id=1135924] from ON_QA to VERIFIED > Race condition during Marshalling of Lucene Directory components would trigger nonsense during unmarshalling > ------------------------------------------------------------------------------------------------------------ > > Key: ISPN-4605 > URL: https://issues.jboss.org/browse/ISPN-4605 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Affects Versions: 7.0.0.Alpha5 > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 7.0.0.Beta1 > > > Some components in the Lucene Directory are highly concurrent, when these are marshalled we need to ensure a consistent snapshot is written to the byte stream. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4685) Lucene Directory Externalizers not used on server deployment

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4685?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4685: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1136064|https://bugzilla.redhat.com/show_bug.cgi?id=1136064] from ON_QA to VERIFIED > Lucene Directory Externalizers not used on server deployment > ------------------------------------------------------------ > > Key: ISPN-4685 > URL: https://issues.jboss.org/browse/ISPN-4685 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 7.0.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Beta2 > > > Infinispan server module does not import services from lucene directory module, and java serialization is used since all Lucene cache objets (wrongly) implements Serializable -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 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: ------------------------------------ [~mgencur] If you want to always copy the buffer to the exact size, yes, growing by 2 is probably better than 1.5. I was thinking that a growth factor of 1.5 would remove the need for some of the buffer copies, because the wasted space would be small enough. One more thing: not all values that are serialized are stored in the data container, some are just sent to another node and discarded (e.g. if the originator is not the primary owner, in non-tx caches). In that case, it really doesn't make sense to copy the buffer, regardless of the amount of space saved. > 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 > 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)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4045) String literal escaping for new query dsl is not properly done

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4045?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4045: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1116927|https://bugzilla.redhat.com/show_bug.cgi?id=1116927] from ON_QA to VERIFIED > String literal escaping for new query dsl is not properly done > -------------------------------------------------------------- > > Key: ISPN-4045 > URL: https://issues.jboss.org/browse/ISPN-4045 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying, Remote Querying > Affects Versions: 6.0.1.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 630 > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > Some tests are disabled because of this, see QueryDslConditionsTest.testStringEscape() and the remote equivalent. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2014