March 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5813) View of cache container configuration

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-5813?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic resolved ISPN-5813. --------------------------------------- Fix Version/s: 8.2.0.Final Resolution: Done Integrated for 8.2.0.Final release. > View of cache container configuration > ------------------------------------- > > Key: ISPN-5813 > URL: https://issues.jboss.org/browse/ISPN-5813 > Project: Infinispan > Issue Type: Sub-task > Components: Console > Reporter: Pedro Zapata > Assignee: Vladimir Blagojevic > Fix For: 8.2.0.Final > > > As an administrator, I want to view and set Cache Container level settings such transport, thread pools, security, cache templates, deployment of remote Executables/Scripts.Each cache container should be associated with a cluster. > An option ‘View / edit configuration’ will be added to the Cache container screen, as shown in https://rawgit.com/infinispan/infinispan-console-mockup/master/cache-cont... > The configuration screens are shown at: > https://rawgit.com/infinispan/infinispan-console-mockup/master/cache-cont... > Scope will be defined as follows: > * Transport: https://rawgit.com/infinispan/infinispan-console-mockup/master/cache-cont... > * Security (https://rawgit.com/infinispan/infinispan-console-mockup/master/cache-cont... > * Thread pool: https://rawgit.com/infinispan/infinispan-console-mockup/master/cache-cont... > * Schemas: > https://rawgit.com/infinispan/infinispan-console-mockup/master/cache-cont... > * Templates: > https://rawgit.com/infinispan/infinispan-console-mockup/master/cache-cont... > * Deployments: > https://rawgit.com/infinispan/infinispan-console-mockup/master/cache-cont... > * Scripts tasks: Form with Task name, name of parameters if any, Execution Mode, Auditable and the script itself (in text area). > * Deployed jars: Form to upload a binary jar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6392) Convert NotifyingFuture and friends to CompletableFuture

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6392?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6392: -------------------------------- Summary: Convert NotifyingFuture and friends to CompletableFuture (was: Convert FutureListener and friends to CompletableFuture) > Convert NotifyingFuture and friends to CompletableFuture > -------------------------------------------------------- > > Key: ISPN-6392 > URL: https://issues.jboss.org/browse/ISPN-6392 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 9.0.0.Alpha1 > > > Now that we have Java 8 we should be using standard classes as much as possible. Before we had special future instances to handle callbacks and we should change all of these to use CompletableFuture instead so the API is what users would be used to. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6392) Convert FutureListener and friends to CompletableFuture

by William Burns (JIRA)

William Burns created ISPN-6392: ----------------------------------- Summary: Convert FutureListener and friends to CompletableFuture Key: ISPN-6392 URL: https://issues.jboss.org/browse/ISPN-6392 Project: Infinispan Issue Type: Enhancement Components: Core Reporter: William Burns Assignee: William Burns Fix For: 9.0.0.Alpha1 Now that we have Java 8 we should be using standard classes as much as possible. Before we had special future instances to handle callbacks and we should change all of these to use CompletableFuture instead so the API is what users would be used to. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6390) Transport initial cluster timeout resets whenever a new node joins

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6390?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-6390: ------------------------------------ This is especially visible in {{InitialClusterSizeTest}} after fixing ISPN-6391: when a node times out and disconnects, the other nodes receive a new view and restart their timeout. > Transport initial cluster timeout resets whenever a new node joins > ------------------------------------------------------------------ > > Key: ISPN-6390 > URL: https://issues.jboss.org/browse/ISPN-6390 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Final, 8.2.1.Final > > > {{JGroupsTransport.waitForInitialNodes()}} calls {{waitForView(currentViewId + 1, timeout, MILLISECONDS)}} repeatedly, and doesn't adjust the timeout when a new view is installed. > This means a node joining/leaving just before the timeout expire will effectively double the timeout. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6391) Cache managers failing to start do not stop global components

by Dan Berindei (JIRA)

Dan Berindei created ISPN-6391: ---------------------------------- Summary: Cache managers failing to start do not stop global components Key: ISPN-6391 URL: https://issues.jboss.org/browse/ISPN-6391 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 8.2.0.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 9.0.0.Final, 8.2.1.Final If one of the global components fails to start, {{GlobalComponentRegistry.start()}} removes the volatile components, but it doesn't call {{stop()}} on those components. The most likely reason for a global component start failure is a timeout in {{JGroupsTransport.waitForInitialNodes()}}. After such a timeout, the transport isn't stopped, so the channel's sockets and threads are only freed after a few GC cycles (via finalization). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6391) Cache managers failing to start do not stop global components

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6391?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6391: ------------------------------- Status: Open (was: New) > Cache managers failing to start do not stop global components > ------------------------------------------------------------- > > Key: ISPN-6391 > URL: https://issues.jboss.org/browse/ISPN-6391 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Final, 8.2.1.Final > > > If one of the global components fails to start, {{GlobalComponentRegistry.start()}} removes the volatile components, but it doesn't call {{stop()}} on those components. > The most likely reason for a global component start failure is a timeout in {{JGroupsTransport.waitForInitialNodes()}}. After such a timeout, the transport isn't stopped, so the channel's sockets and threads are only freed after a few GC cycles (via finalization). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6390) Transport initial cluster timeout resets whenever a new node joins

by Dan Berindei (JIRA)

Dan Berindei created ISPN-6390: ---------------------------------- Summary: Transport initial cluster timeout resets whenever a new node joins Key: ISPN-6390 URL: https://issues.jboss.org/browse/ISPN-6390 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 8.2.0.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 9.0.0.Final, 8.2.1.Final {{JGroupsTransport.waitForInitialNodes()}} calls {{waitForView(currentViewId + 1, timeout, MILLISECONDS)}} repeatedly, and doesn't adjust the timeout when a new view is installed. This means a node joining/leaving just before the timeout expire will effectively double the timeout. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6390) Transport initial cluster timeout resets whenever a new node joins

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6390?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6390: ------------------------------- Status: Open (was: New) > Transport initial cluster timeout resets whenever a new node joins > ------------------------------------------------------------------ > > Key: ISPN-6390 > URL: https://issues.jboss.org/browse/ISPN-6390 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Final, 8.2.1.Final > > > {{JGroupsTransport.waitForInitialNodes()}} calls {{waitForView(currentViewId + 1, timeout, MILLISECONDS)}} repeatedly, and doesn't adjust the timeout when a new view is installed. > This means a node joining/leaving just before the timeout expire will effectively double the timeout. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6239) InitialClusterSizeTest.testInitialClusterSizeFail random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6239?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-6239: ------------------------------------ On my machine, I have also seen the initial connection delayed by 3 seconds because of JGRP-2028. > InitialClusterSizeTest.testInitialClusterSizeFail random failures > ----------------------------------------------------------------- > > Key: ISPN-6239 > URL: https://issues.jboss.org/browse/ISPN-6239 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 8.2.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_failure > Fix For: 8.2.0.CR1, 8.2.0.Final > > > The test starts 3 nodes concurrently, but configures Infinispan to wait for a cluster of 4 nodes, and expects that the nodes fail to start in {{initialClusterTimeout}} + 1 second. > However, because of a bug in {{TEST_PING}}, the first 2 nodes see each other as coordinator and send a {{JOIN}} request to each other, and it takes 3 seconds to recover and start the cluster properly. > The bug in {{TEST_PING}} is actually a hack introduced for {{ISPN-5106}}. The problem was that the first node (A) to start would install a view with itself as the single node, but the second node to start (B) would start immediately, and the discovery request from B would reach B's {{TEST_PING}} before it saw the view. That way, B could choose itself as the coordinator based on the order of A's and B's UUIDs, and the cluster would start as 2 partitions. Since most of our tests actually remove {{MERGE3}} from the protocol stack, the partitions would never merge and the test would fail with a timeout. > I fixed this in {{TEST_PING}} by assuming that the sender of the first discovery response is a coordinator, when there is a single response. This worked because all but a few tests start their managers sequentially, however it sometimes introduces this 3 seconds delay when nodes start in parallel. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6275) Double invalidate of invalid Hot Rod connections

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-6275?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-6275: ----------------------------------- Fix Version/s: 9.0.0.Final > Double invalidate of invalid Hot Rod connections > ------------------------------------------------ > > Key: ISPN-6275 > URL: https://issues.jboss.org/browse/ISPN-6275 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 6.0.2.Final > Reporter: Dennis Reed > Assignee: Galder Zamarreño > Fix For: 9.0.0.Final > > > When there's a problem with a Hot Rod operation, RetryOnFailureOperation invalidates the connection twice (once in a catch block, and once in a finally block). > This causes the GenericKeyedObjectPool counts to get off, and anything relying on that count (such as the maxTotal configuration for the pool) to break. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2016