October 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5889) Merge views not dealt with in Hot Rod server

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5889?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5889: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/3787 > Merge views not dealt with in Hot Rod server > -------------------------------------------- > > Key: ISPN-5889 > URL: https://issues.jboss.org/browse/ISPN-5889 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.0.1.Final, 8.1.0.Alpha2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.1.0.Beta1, 8.1.0.Final > > > Hot Rod server does not deal with merge views, so when members return back to the cluster, the view is not updated. The Hot Rod server view change listener currently only deals with nodes leaving or crashing. This problem is not a big one since it just means that until the next view change happens, clients will work with a reduced view, working in a suboptimal way, but it won't have correctness impact. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5613) Replication timeouts should show more information of the affected entries

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5613?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5613: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3792 > Replication timeouts should show more information of the affected entries > ------------------------------------------------------------------------- > > Key: ISPN-5613 > URL: https://issues.jboss.org/browse/ISPN-5613 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Wolf-Dieter Fink > Assignee: Dan Berindei > > Typical timeouts for replication are > ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread-595) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for jboss####-##### > and > ERROR .... > Caused by: org.infinispan.util.concurrent.TimeoutException: Node jboss####-##### timed out > The issue is that it is not possible to check what key/entry is affected. > The cache can become inconsistent between nodes. > There should be an information which key is affected. > For some operations it is not possible at all as there is no information about the entries (i.e. commit) or the key is binary or custom without a valid toString() method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5897) Enhance filter_failed_tests.sh to support compressed logs

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5897?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5897: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3791 > Enhance filter_failed_tests.sh to support compressed logs > --------------------------------------------------------- > > Key: ISPN-5897 > URL: https://issues.jboss.org/browse/ISPN-5897 > Project: Infinispan > Issue Type: Task > Components: Build process > Affects Versions: 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Beta1 > > > Currently the trace build uses a lot of disk space. Using `CompressedFileAppender` should reduce the size of the logs considerably, but we still want to save only the logs of the failed tests in the build artifacts. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5897) Enhance filter_failed_tests.sh to support compressed logs

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5897?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5897: ------------------------------- Status: Open (was: New) > Enhance filter_failed_tests.sh to support compressed logs > --------------------------------------------------------- > > Key: ISPN-5897 > URL: https://issues.jboss.org/browse/ISPN-5897 > Project: Infinispan > Issue Type: Task > Components: Build process > Affects Versions: 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Beta1 > > > Currently the trace build uses a lot of disk space. Using `CompressedFileAppender` should reduce the size of the logs considerably, but we still want to save only the logs of the failed tests in the build artifacts. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5897) Enhance filter_failed_tests.sh to support compressed logs

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5897: ---------------------------------- Summary: Enhance filter_failed_tests.sh to support compressed logs Key: ISPN-5897 URL: https://issues.jboss.org/browse/ISPN-5897 Project: Infinispan Issue Type: Task Components: Build process Affects Versions: 8.1.0.Alpha2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 8.1.0.Beta1 Currently the trace build uses a lot of disk space. Using `CompressedFileAppender` should reduce the size of the logs considerably, but we still want to save only the logs of the failed tests in the build artifacts. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5895) RebalancePolicyJmxTest.testJoinAndLeaveWithRebalanceSuspendedAwaitingInitialTransfer random failures

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5895?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5895: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated. Thanks [~dan.berindei]! > RebalancePolicyJmxTest.testJoinAndLeaveWithRebalanceSuspendedAwaitingInitialTransfer random failures > ---------------------------------------------------------------------------------------------------- > > Key: ISPN-5895 > URL: https://issues.jboss.org/browse/ISPN-5895 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 8.1.0.Beta1 > > > The test sometimes fails because the rebalance finishes too quickly after it is enabled. > {noformat} > 17:22:35,605 DEBUG (testng-RebalancePolicyJmxTest:[]) [RebalancePolicyJmxTest] Rebalancing with nodes NodeI-11719 NodeJ-4803 NodeK-58683 NodeL-10033 > 17:22:35,621 INFO (remote-thread-NodeI-p45498-t6:[]) [CLUSTER] ISPN000310: Starting cluster-wide rebalance for cache ___defaultcache, topology CacheTopology{id=3, rebalanceId=2, currentCH=DefaultConsistentHash{ns=60, owners = (2)[NodeI-11719: 30+30, NodeJ-4803: 30+30]}, pendingCH=DefaultConsistentHash{ns=60, owners = (4)[NodeI-11719: 15+15, NodeJ-4803: 15+15, NodeK-58683: 15+15, NodeL-10033: 15+15]}, unionCH=null, actualMembers=[NodeI-11719, NodeJ-4803, NodeK-58683, NodeL-10033]} > 17:22:35,643 INFO (remote-thread-NodeI-p45498-t6:[]) [CLUSTER] ISPN000336: Finished cluster-wide rebalance for cache ___defaultcache, topology id = 3 > 17:22:37,630 ERROR (testng-RebalancePolicyJmxTest:[]) [UnitTestTestNGListener] Test testJoinAndLeaveWithRebalanceSuspended(org.infinispan.statetransfer.RebalancePolicyJmxTest) failed. > java.lang.AssertionError: expected:<IN_PROGRESS> but was:<COMPLETE> > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:101) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:108) ~[testng-6.8.8.jar:?] > at org.infinispan.statetransfer.RebalancePolicyJmxTest.doTest(RebalancePolicyJmxTest.java:111) ~[test-classes/:?] > at org.infinispan.statetransfer.RebalancePolicyJmxTest.testJoinAndLeaveWithRebalanceSuspended(RebalancePolicyJmxTest.java:36) ~[test-classes/:?] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5896) ClusterStreamManager segment generation should use locatePrimaryOwnerForSegment

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5896?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5896: -------------------------------- Status: Open (was: New) > ClusterStreamManager segment generation should use locatePrimaryOwnerForSegment > ------------------------------------------------------------------------------- > > Key: ISPN-5896 > URL: https://issues.jboss.org/browse/ISPN-5896 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.1.0.Alpha2 > Reporter: William Burns > Assignee: William Burns > Fix For: 8.1.0.Beta1, 8.0.2.Final > > > ClusterStreamManager has to find all of the addresses for a given set of segments. Unfortunately it does this by finding the segments per address. This ends up having n * m time complexity. If we instead did it so we find the primary owner per segment it would only have n time complexity as finding the primary owner of a segment is constant time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5896) ClusterStreamManager segment generation should use locatePrimaryOwnerForSegment

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5896?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5896: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3790 > ClusterStreamManager segment generation should use locatePrimaryOwnerForSegment > ------------------------------------------------------------------------------- > > Key: ISPN-5896 > URL: https://issues.jboss.org/browse/ISPN-5896 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.1.0.Alpha2 > Reporter: William Burns > Assignee: William Burns > Fix For: 8.1.0.Beta1, 8.0.2.Final > > > ClusterStreamManager has to find all of the addresses for a given set of segments. Unfortunately it does this by finding the segments per address. This ends up having n * m time complexity. If we instead did it so we find the primary owner per segment it would only have n time complexity as finding the primary owner of a segment is constant time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5896) ClusterStreamManager segment generation should use locatePrimaryOwnerForSegment

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5896?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-5896: ----------------------------------- Assignee: William Burns > ClusterStreamManager segment generation should use locatePrimaryOwnerForSegment > ------------------------------------------------------------------------------- > > Key: ISPN-5896 > URL: https://issues.jboss.org/browse/ISPN-5896 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.1.0.Alpha2 > Reporter: William Burns > Assignee: William Burns > Fix For: 8.1.0.Beta1, 8.0.2.Final > > > ClusterStreamManager has to find all of the addresses for a given set of segments. Unfortunately it does this by finding the segments per address. This ends up having n * m time complexity. If we instead did it so we find the primary owner per segment it would only have n time complexity as finding the primary owner of a segment is constant time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5896) ClusterStreamManager segment generation should use locatePrimaryOwnerForSegment

by William Burns (JIRA)

William Burns created ISPN-5896: ----------------------------------- Summary: ClusterStreamManager segment generation should use locatePrimaryOwnerForSegment Key: ISPN-5896 URL: https://issues.jboss.org/browse/ISPN-5896 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 8.1.0.Alpha2 Reporter: William Burns Fix For: 8.1.0.Beta1, 8.0.2.Final ClusterStreamManager has to find all of the addresses for a given set of segments. Unfortunately it does this by finding the segments per address. This ends up having n * m time complexity. If we instead did it so we find the primary owner per segment it would only have n time complexity as finding the primary owner of a segment is constant time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2015