July 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7831) Administration console - adjust node memory graph to match PatternFly widget

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7831?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7831: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > Administration console - adjust node memory graph to match PatternFly widget > ----------------------------------------------------------------------------- > > Key: ISPN-7831 > URL: https://issues.jboss.org/browse/ISPN-7831 > Project: Infinispan > Issue Type: Enhancement > Components: Console > Affects Versions: 9.0.0.Final > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Minor > Fix For: 9.2.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7811) Improve out-of-the-box server security in cloud

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7811?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7811: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > Improve out-of-the-box server security in cloud > ----------------------------------------------- > > Key: ISPN-7811 > URL: https://issues.jboss.org/browse/ISPN-7811 > Project: Infinispan > Issue Type: Enhancement > Components: Security, Server > Affects Versions: 9.0.0.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.2.0.Final > > > When running Infinispan 9.0.0.Final in a cloud env, the default security code enforcements are causing issues when trying to register a proto file. > The "___protobuf_metadata" cache cannot be written remotely any more. Accessing this cache to add protofile descriptors to server. The default configuration throws this error: > {code} > [datagrid-1-akxoi] > [datagrid-1-akxoi] 12:15:56,602 ERROR [org.infinispan.server.hotrod.CacheDecodeContext] (HotRod-ServerWorker-4-2) ISPN005003: Exception reported: org.infinispan.server.hotrod.RequestParsingException: Remote requests are allowed to protected caches only over loopback or if authorization is enabled. Do no send remote requests to cache '___protobuf_metadata' > [datagrid-1-akxoi] at org.infinispan.server.hotrod.CacheDecodeContext.obtainCache(CacheDecodeContext.java:116) > [datagrid-1-akxoi] at org.infinispan.server.hotrod.HotRodDecoder.decodeHeader(HotRodDecoder.java:162) > [datagrid-1-akxoi] at org.infinispan.server.hotrod.HotRodDecoder.decode(HotRodDecoder.java:93) > {code} > The code in CacheDecodeContext that enables this check does the following: > {code} > if (!cacheManager.getCacheManagerConfiguration().security().authorization().enabled()... > {code} > In order to have better out-of-the-box experience in cloud but still be secured, the following should be done: > * Remove the code check for authorization in CacheDecodeContext. > * Server's default configuration should require authentication. > * Docker image allows passing in APP_USER and APP_PASS as env variables easily, but it provides default usernames and passwords for both APP and MGMT. These defaults should be removed since they're a security risk. > * Docker image should have the possibility to set APP_GROUPS so that we can pass in optionally the role groups associated with a user. This is handy for making it easier in the future for users to add authorization on top of authentication. > I will create JIRA subtasks for these so that the work can be divided. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7801) RehashWithL1Test.testPutWithRehashAndCacheClear random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7801?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7801: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > RehashWithL1Test.testPutWithRehashAndCacheClear random failures > --------------------------------------------------------------- > > Key: ISPN-7801 > URL: https://issues.jboss.org/browse/ISPN-7801 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 9.2.0.Final > > > The test kills the only owner of a key and checks that when a node starts owning an L1 entry, it doesn't send it to other nodes during state transfer. Then it adds a new node (owning the key) and checks that the key isn't transferred to the new node, and it's deleted from L1 on the old nodes. The problem is that it doesn't wait, it assumes all the nodes have already removed it by the time {{getCache()}} returns on the joiner. > {noformat} > 03:24:27,606 TRACE (jgroups-5,Test-NodeB-54331:[]) [L1WriteSynchronizer] Caching remotely retrieved entry for key k0 in L1 > 03:24:27,607 TRACE (jgroups-5,Test-NodeB-54331:[]) [DefaultDataContainer] Store MortalCacheEntry{key=k0, value=some data} in container > 03:24:26,754 DEBUG (testng-Test:[]) [Test] Populating L1 on Test-NodeA-2588 > 03:24:27,514 DEBUG (testng-Test:[]) [Test] Populating L1 on Test-NodeB-54331 > 03:24:27,777 DEBUG (testng-Test:[]) [Test] Populating L1 on Test-NodeC-65326 > 03:24:27,777 DEBUG (testng-Test:[]) [Test] Killing node Test-NodeC-65326 > 03:24:27,781 TRACE (transport-thread-Test-NodeA-p51-t2:[Topology-___defaultcache]) [DefaultDataContainer] Removed MortalCacheEntry{key=k0, value=some data} from container > *** The entry is not removed from NodeB at this point > 03:24:27,936 DEBUG (testng-Test:[]) [Test] Checking values on Test-NodeA-2588 > 03:24:27,998 TRACE (jgroups-5,Test-NodeB-54331:[]) [CommandAwareRpcDispatcher] About to send back response SuccessfulResponse{responseValue=MortalCacheValue{value=some data, lifespan=600000, created=1493943867607}} for command ClusteredGetCommand{key=k0, flags=[]} > 03:24:28,034 TRACE (jgroups-7,Test-NodeA-2588:[]) [L1WriteSynchronizer] Caching remotely retrieved entry for key k0 in L1 > 03:24:28,044 TRACE (jgroups-7,Test-NodeA-2588:[]) [DefaultDataContainer] Store MortalCacheEntry{key=k0, value=some data} in container > 03:24:28,519 DEBUG (testng-Test:[]) [Test] Checking values on Test-NodeB-54331 > 03:24:28,595 DEBUG (testng-Test:[]) [Test] Starting a new joiner > 03:24:30,261 TRACE (transport-thread-Test-NodeA-p51-t6:[Topology-___defaultcache]) [InvocationContextInterceptor] Invoked with command InvalidateCommand{keys=[k0, k1, k2, k3, k4, k5, k6, k7, k8, k9]} and InvocationContext [org.infinispan.context.impl.NonTxInvocationContext@54c5cc1d] > 03:24:30,292 DEBUG (testng-Test:[]) [Test] Checking values on Test-NodeA-2588 > 03:24:30,355 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.distribution.rehash.RehashWithL1Test.testPutWithRehashAndCacheClear > java.lang.AssertionError: wrong value for k0 > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertNull(AssertJUnit.java:282) ~[testng-6.8.8.jar:?] > at org.infinispan.distribution.rehash.RehashWithL1Test.testPutWithRehashAndCacheClear(RehashWithL1Test.java:78) ~[test-classes/:?] > *** Too late > 03:24:30,360 TRACE (transport-thread-Test-NodeA-p51-t6:[Topology-___defaultcache]) [DefaultDataContainer] Removed MortalCacheEntry{key=k0, value=some data} from container > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7775) AdminOperationHandler for Domain server mode

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7775?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7775: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > AdminOperationHandler for Domain server mode > -------------------------------------------- > > Key: ISPN-7775 > URL: https://issues.jboss.org/browse/ISPN-7775 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.2.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7770) Admin operations to REST server

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7770?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7770: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > Admin operations to REST server > ------------------------------- > > Key: ISPN-7770 > URL: https://issues.jboss.org/browse/ISPN-7770 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Reporter: Tristan Tarrant > Assignee: Sebastian Łaskawiec > Fix For: 9.2.0.Final > > > We should support the following admin operations for REST: > * CACHE_CREATE: implemented using the WebDAV MKCOL /context/cachename operation > * CACHE_REMOVE: implemented using the WebDAV DELETE /context/cachename operation -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7774) AdminOperationHandler for Standalone server mode

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7774?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7774: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > AdminOperationHandler for Standalone server mode > ------------------------------------------------ > > Key: ISPN-7774 > URL: https://issues.jboss.org/browse/ISPN-7774 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.2.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7769) Add admin operations to server protocols

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7769?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7769: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > Add admin operations to server protocols > ---------------------------------------- > > Key: ISPN-7769 > URL: https://issues.jboss.org/browse/ISPN-7769 > Project: Infinispan > Issue Type: Task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.2.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7739) CacheMgmtInterceptor should collect total writes stat

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7739?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7739: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > CacheMgmtInterceptor should collect total writes stat > ----------------------------------------------------- > > Key: ISPN-7739 > URL: https://issues.jboss.org/browse/ISPN-7739 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management > Affects Versions: 9.0.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.2.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7749) A node leaving during rebalance causes extra segment transfers

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7749?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7749: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > A node leaving during rebalance causes extra segment transfers > -------------------------------------------------------------- > > Key: ISPN-7749 > URL: https://issues.jboss.org/browse/ISPN-7749 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 9.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.2.0.Final > > > If a node leaves during a rebalance, the only change is that other nodes will no longer request segments from that node. Otherwise the rebalance proceeds as usual, and at the end a node may delete its copy of a segment even if that leaves less than {{numOwners}} copies in the cluster. > When the leaver is the joiner, a 2nd rebalance is very likely to return to the initial CH, but only after transferring some segments twice: > {noformat} > Rebalance starts: current_owners(s) = AB, pending_owners(s) = AC > C leaves: current_owners(s) = AB, pending_owners(s) = A > Rebalance finishes: current_owners(s) = A, pending_owners(s) = A > 2nd rebalance starts: current_owners(s) = A, pending_owners(s) = AB > {noformat} > Even if the leaver is one of the old owners and the 2 segment transfers are necessary, the cluster stays for too long with less than {{numOwners}} copies of the segment: > {noformat} > Rebalance starts: current_owners(s) = AB, pending_owners(s) = AC > A leaves: current_owners(s) = B, pending_owners(s) = C > C transfers segment s from B > Rebalance finishes: current_owners(s) = C, pending_owners(s) = C > 2nd rebalance starts: current_owners(s) = C, pending_owners(s) = DC > {noformat} > We can fix this by making the pending CH a union of the current and pending CH whenever a node leavers, and only removing extra segment copies after the 2nd rebalance. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7729) Cache managers share a mutable GenericTransactionManagerLookup instance

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7729?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7729: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > Cache managers share a mutable GenericTransactionManagerLookup instance > ----------------------------------------------------------------------- > > Key: ISPN-7729 > URL: https://issues.jboss.org/browse/ISPN-7729 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Core > Affects Versions: 9.0.0.Final > Reporter: Dan Berindei > Fix For: 9.2.0.Final > > > {{GenericTransactionManagerLookup}} is mutable, so different cache managers should use different instances. Even if two deployments see the same {{GenericTransactionManagerLookup}} class from a common parent classloader, each deployment could include its own transaction manager. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2017