September 2014 - infinispan-issues

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

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-4677?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic commented on ISPN-4677: ------------------------------------------- Sanne, thank you! I am inclined to simplify this by throwing exception rather than adding some flag: throw new ExecutionException("Map phase executing at " + mapTaskPart.getAddress() + " timed out", cause); Exception cause will provide the details, it could be Node timed out like in your example or it could be one of the "Timed out waiting for valid responses!" exception. Both cases will be covered and the code will be future proofed. WDYT? > 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)

11 years, 3 months

1
0
0 / 0

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

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-3807?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-3807: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > 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)

11 years, 3 months

1
0
0 / 0

[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: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1136438|https://bugzilla.redhat.com/show_bug.cgi?id=1136438] from POST to MODIFIED > 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)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4686) Make Infinispan 7.0 binary compatible with 6.x

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4686?page=com.atlassian.jira.plugin.... ] Galder Zamarreño edited comment on ISPN-4686 at 9/3/14 3:04 AM: ---------------------------------------------------------------- Other incompatibilities: * org.infinispan.manager.AbstractDelegatingEmbeddedCacheManager -> org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager <- ISPN-4074 * org.infinispan.cache.impl.AbstractDelegatingCache -> org.infinispan.AbstractDelegatingCache <- ISPN-4074 * org.infinispan.affinity.KeyAffinityServiceImpl -> org.infinispan.affinity.impl.KeyAffinityServiceImpl <- ISPN-4074 * org.infinispan.persistence.jdbc.DatabaseType -> org.infinispan.persistence.jdbc.Dialect <- ISPN-4211 * org.infinispan.distribution.ch.[Default|Replicated|Sync|TopologyAware|TopologyAware]SyncConsistentHashFactory -> org.infinispan.distribution.ch.impl.[Default|Replicated|Sync|TopologyAware|TopologyAwareSync]ConsistentHashFactory <- ISPN-4074 was (Author: pferraro): Other incompatibilities: * org.infinispan.manager.AbstractDelegatingEmbeddedCacheManager -> org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager <- ISPN-4074 * org.infinispan.affinity.KeyAffinityServiceImpl -> org.infinispan.affinity.impl.KeyAffinityServiceImpl <- ISPN-4074 * org.infinispan.persistence.jdbc.DatabaseType -> org.infinispan.persistence.jdbc.Dialect <- ISPN-4211 * org.infinispan.distribution.ch.[Default|Replicated|Sync|TopologyAware|TopologyAware]SyncConsistentHashFactory -> org.infinispan.distribution.ch.impl.[Default|Replicated|Sync|TopologyAware|TopologyAwareSync]ConsistentHashFactory <- ISPN-4074 > Make Infinispan 7.0 binary compatible with 6.x > ---------------------------------------------- > > Key: ISPN-4686 > URL: https://issues.jboss.org/browse/ISPN-4686 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Beta1 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Beta2 > > > The idea here is to try to produce a Infinispan 7.0 jar that's binary compatible with 6.0 in order to ease upgrading. So far, the following elements have been found to be problematic: > * FileLookupFactory -> FileLookup changes - ISPN-3850 > * JBossStandaloneJTAManagerLookup.init changes - ISPN-3850 > * org.infinispan.AbstractDelegatingAdvancedCache refactoring to org.infinispan.cache.impl.AbstractDelegatingAdvancedCache - ISPN-4074 > XML configuration stays apart since one of the key aspects of 7.0 is to produce WF-like configuration that's as close as possible, to improve usability between library and server mode. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4686) Make Infinispan 7.0 binary compatible with 6.x

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4686?page=com.atlassian.jira.plugin.... ] Work on ISPN-4686 started by Galder Zamarreño. ---------------------------------------------- > Make Infinispan 7.0 binary compatible with 6.x > ---------------------------------------------- > > Key: ISPN-4686 > URL: https://issues.jboss.org/browse/ISPN-4686 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Beta1 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Beta2 > > > The idea here is to try to produce a Infinispan 7.0 jar that's binary compatible with 6.0 in order to ease upgrading. So far, the following elements have been found to be problematic: > * FileLookupFactory -> FileLookup changes - ISPN-3850 > * JBossStandaloneJTAManagerLookup.init changes - ISPN-3850 > * org.infinispan.AbstractDelegatingAdvancedCache refactoring to org.infinispan.cache.impl.AbstractDelegatingAdvancedCache - ISPN-4074 > XML configuration stays apart since one of the key aspects of 7.0 is to produce WF-like configuration that's as close as possible, to improve usability between library and server mode. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4686) Make Infinispan 7.0 binary compatible with 6.x

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4686?page=com.atlassian.jira.plugin.... ] Galder Zamarreño edited comment on ISPN-4686 at 9/3/14 2:36 AM: ---------------------------------------------------------------- Other incompatibilities: * org.infinispan.manager.AbstractDelegatingEmbeddedCacheManager -> org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager <- ISPN-4074 * org.infinispan.affinity.KeyAffinityServiceImpl -> org.infinispan.affinity.impl.KeyAffinityServiceImpl <- ISPN-4074 * org.infinispan.persistence.jdbc.DatabaseType -> org.infinispan.persistence.jdbc.Dialect <- ISPN-4211 * org.infinispan.distribution.ch.[Default|Replicated|Sync|TopologyAware|TopologyAware]SyncConsistentHashFactory -> org.infinispan.distribution.ch.impl.[Default|Replicated|Sync|TopologyAware|TopologyAwareSync]ConsistentHashFactory <- ISPN-4074 was (Author: pferraro): Other incompatibilities: * org.infinispan.manager.AbstractDelegatingEmbeddedCacheManager -> org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager * org.infinispan.affinity.KeyAffinityServiceImpl -> org.infinispan.affinity.impl.KeyAffinityServiceImpl * org.infinispan.persistence.jdbc.DatabaseType -> org.infinispan.persistence.jdbc.Dialect * org.infinispan.distribution.ch.[Default|Replicated|Sync|TopologyAware|TopologyAware]SyncConsistentHashFactory -> org.infinispan.distribution.ch.impl.[Default|Replicated|Sync|TopologyAware|TopologyAwareSync]ConsistentHashFactory > Make Infinispan 7.0 binary compatible with 6.x > ---------------------------------------------- > > Key: ISPN-4686 > URL: https://issues.jboss.org/browse/ISPN-4686 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Beta1 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Beta2 > > > The idea here is to try to produce a Infinispan 7.0 jar that's binary compatible with 6.0 in order to ease upgrading. So far, the following elements have been found to be problematic: > * FileLookupFactory -> FileLookup changes - ISPN-3850 > * JBossStandaloneJTAManagerLookup.init changes - ISPN-3850 > * org.infinispan.AbstractDelegatingAdvancedCache refactoring to org.infinispan.cache.impl.AbstractDelegatingAdvancedCache - ISPN-4074 > XML configuration stays apart since one of the key aspects of 7.0 is to produce WF-like configuration that's as close as possible, to improve usability between library and server mode. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4682) Improve SyncConsistentHashFactory key distribution

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4682?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4682: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1136109|https://bugzilla.redhat.com/show_bug.cgi?id=1136109] from POST to MODIFIED > Improve SyncConsistentHashFactory key distribution > -------------------------------------------------- > > Key: ISPN-4682 > URL: https://issues.jboss.org/browse/ISPN-4682 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 6.0.2.Final, 7.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: performance > Fix For: 7.0.0.Beta2 > > > {{SyncConsistentHashFactory}} and {{TopologyAwareSyncConsistentHashFactory}} distribute the segments between nodes randomly, and the number of segments distributed to different nodes is not very even. > They should have a fail-safe mechanism to limit the variation in segment number between nodes. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4674) Hot Rod client receives ArrayIndexOutOfBoundsException and InvalidResponseException when topology changes

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4674?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4674: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Final Resolution: Done > Hot Rod client receives ArrayIndexOutOfBoundsException and InvalidResponseException when topology changes > --------------------------------------------------------------------------------------------------------- > > Key: ISPN-4674 > URL: https://issues.jboss.org/browse/ISPN-4674 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remote Protocols > Affects Versions: 7.0.0.Beta1 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 7.0.0.Beta2, 7.0.0.Final > > > Upon a topology change, the client receives: > {code} > 17:27:57,406 WARNING [com.example.Main] (main) Loop 43058 failed.: java.lang.ArrayIndexOutOfBoundsException: 2 > at org.infinispan.client.hotrod.impl.protocol.Codec20.readNewTopologyAndHash(Codec20.java:334) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.protocol.Codec20.readNewTopologyIfPresent(Codec20.java:310) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:78) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:71) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:49) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at com.example.Main.main(Main.java:31) [:] > 17:28:02,410 ERROR [org.infinispan.client.hotrod.impl.protocol.Codec20] (main) ISPN004003: Invalid magic number. Expected 0xa1 and received 0x0 > 17:28:02,412 WARNING [com.example.Main] (main) Loop 43059 failed.: org.infinispan.client.hotrod.exceptions.InvalidResponseException:: Invalid magic number. Expected 0xa1 and received 0x0 > at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:247) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:68) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:49) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1] > at com.example.Main.main(Main.java:31) [:] > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 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: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1135924|https://bugzilla.redhat.com/show_bug.cgi?id=1135924] from NEW to MODIFIED > 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)

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

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2014