August 2014 - infinispan-issues - Jboss List Archives

[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: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1135580|https://bugzilla.redhat.com/show_bug.cgi?id=1135580] from NEW to MODIFIED > 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 > Security Level: Public(Everyone can see) > 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)

9 years, 8 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: ----------------------------------------------- Gustavo Fernandes <gfernand(a)redhat.com> changed the Status of [bug 1135608|https://bugzilla.redhat.com/show_bug.cgi?id=1135608] from NEW to CLOSED > 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 > Security Level: Public(Everyone can see) > 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)

9 years, 8 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 updated ISPN-2932: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1135608, https://bugzilla.redhat.com/show_bug.cgi?id=1135580 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1135608) > 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 > Security Level: Public(Everyone can see) > 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)

9 years, 8 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 updated ISPN-2932: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1135608 > 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 > Security Level: Public(Everyone can see) > 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)

9 years, 8 months

1
0
0 / 0

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

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-4677: ------------------------------------- Summary: 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: Dan Berindei 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, 8 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 updated ISPN-4601: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1135580 > 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 > Security Level: Public(Everyone can see) > 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)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4627) QueryInterceptor start() event mutates the SearchFactory multiple times

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4627?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4627: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1135575, https://bugzilla.redhat.com/show_bug.cgi?id=1135553 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1135575) > QueryInterceptor start() event mutates the SearchFactory multiple times > ----------------------------------------------------------------------- > > Key: ISPN-4627 > URL: https://issues.jboss.org/browse/ISPN-4627 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 7.0.0.Beta1 > > > Just spotted while reviewing unrelated patches: > the {{@Start}} annotated method of component {{QueryInterceptor}} loops throught the known entries of the {{clusterRegistry}} field, and will reboot the {{SearchFactory}} once for each entry. > It's important to use the capability to pass multiple class types at once when mutating the SearchFactory, as this is an extremely slow operation, and especially in this case, if it's a node joining an existing cluster we expect to see a considerable amount of indexed types (probably all of them). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4627) QueryInterceptor start() event mutates the SearchFactory multiple times

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4627?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4627: ----------------------------------------------- Gustavo Fernandes <gfernand(a)redhat.com> changed the Status of [bug 1135575|https://bugzilla.redhat.com/show_bug.cgi?id=1135575] from NEW to CLOSED > QueryInterceptor start() event mutates the SearchFactory multiple times > ----------------------------------------------------------------------- > > Key: ISPN-4627 > URL: https://issues.jboss.org/browse/ISPN-4627 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 7.0.0.Beta1 > > > Just spotted while reviewing unrelated patches: > the {{@Start}} annotated method of component {{QueryInterceptor}} loops throught the known entries of the {{clusterRegistry}} field, and will reboot the {{SearchFactory}} once for each entry. > It's important to use the capability to pass multiple class types at once when mutating the SearchFactory, as this is an extremely slow operation, and especially in this case, if it's a node joining an existing cluster we expect to see a considerable amount of indexed types (probably all of them). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4627) QueryInterceptor start() event mutates the SearchFactory multiple times

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4627?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4627: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1135575 > QueryInterceptor start() event mutates the SearchFactory multiple times > ----------------------------------------------------------------------- > > Key: ISPN-4627 > URL: https://issues.jboss.org/browse/ISPN-4627 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 7.0.0.Beta1 > > > Just spotted while reviewing unrelated patches: > the {{@Start}} annotated method of component {{QueryInterceptor}} loops throught the known entries of the {{clusterRegistry}} field, and will reboot the {{SearchFactory}} once for each entry. > It's important to use the capability to pass multiple class types at once when mutating the SearchFactory, as this is an extremely slow operation, and especially in this case, if it's a node joining an existing cluster we expect to see a considerable amount of indexed types (probably all of them). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[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 commented on ISPN-2392: ------------------------------------ REPL mode has been implemented on top of DIST mode in 5.3.0, so the lock is only acquired once (on the primary owner). > 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 > > 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, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2014