October 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6638) Implement multi-tenancy for Web Sockets

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-6638?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6638: ---------------------------------- Fix Version/s: 9.4.2.Final (was: 9.4.1.Final) > Implement multi-tenancy for Web Sockets > --------------------------------------- > > Key: ISPN-6638 > URL: https://issues.jboss.org/browse/ISPN-6638 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Reporter: Sebastian Łaskawiec > Priority: Optional > Fix For: 9.4.2.Final > > > Currently this implementation is out of scope. Please vote for it if you'd like it to be implemented. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7982) Ickle purely negative fulltext subqueries cause empty results

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-7982?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7982: ---------------------------------- Fix Version/s: 9.4.2.Final (was: 9.4.1.Final) > Ickle purely negative fulltext subqueries cause empty results > ------------------------------------------------------------- > > Key: ISPN-7982 > URL: https://issues.jboss.org/browse/ISPN-7982 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 9.0.0.Final > Reporter: Gustavo Fernandes > Assignee: Adrian Nistor > Priority: Major > Fix For: 9.4.2.Final > > > When using parethesis in an Ickle full text predicate, it can generate subqueries that are pure negative, e.g. > {{from IspnEvent where (tags : ('tagA' and (not 'a0')))}} > In Lucene, the query > {{+tags:taga +(-tags:a0)}} > is different from > {{+tags:taga -tags:a0}} > The latter works as expected, but the former brings empty results since Lucene does no support purely negative subqueries. In order for the former query to work, it needs to add all documents as another term to the subquery, for e.g. {{+tags:taga +(\*:\* -tags:a0)}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7935) Document Server Tasks

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-7935?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7935: ---------------------------------- Fix Version/s: 9.4.2.Final (was: 9.4.1.Final) > Document Server Tasks > --------------------- > > Key: ISPN-7935 > URL: https://issues.jboss.org/browse/ISPN-7935 > Project: Infinispan > Issue Type: Enhancement > Components: Server, Tasks > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Major > Fix For: 9.4.2.Final > > > There's literally no documentation on using ServerTask. They're very powerful and we should promote them more since they can act as a stop gap solution for any missing features in HR client. > I'll add documentation for ServerTasks once Infinispan can execute ServerTasks fine, even if they're POJOs. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7956) Investigate removing PartitionHandlingInterceptor

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-7956?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7956: ---------------------------------- Fix Version/s: 9.4.2.Final (was: 9.4.1.Final) > Investigate removing PartitionHandlingInterceptor > ------------------------------------------------- > > Key: ISPN-7956 > URL: https://issues.jboss.org/browse/ISPN-7956 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.1.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 9.4.2.Final > > > When all the owners of a key leave the cluster, the distribution interceptor doesn't know how to handle that key. Instead, it has to signal that to the {{PartitionHandlingInterceptor}} somehow, and PHI decides whether to return a {{null}} value or throw an {{AvailabilityException}}. > Single-key read commands and write commands are handled by throwing an {{AllOwnersLostException}} (initially an {{RpcException}}) from the distribution interceptor and catching it in {{PartitionHandlingInterceptor}}. If partitioning handling is disabled, the {{AllOwnersLostException}} is instead caught by {{StateTransferInterceptor}}, which returns the {{null}} value (for read commands) or waits for a new topology and retries (for write commands). > For multi-key read commands the distribution interceptor can't throw an exception, because that would lose the values that were retrieved successfully. For {{GetAllCommand}} we could get away with storing the values in the context, but that wouldn't work for functional commands because they transform the values on the remote node. ISPN-7884 removing the values with missing owners from the result collection, but that means values that are simply missing have to be treated differently, and {{StateTransferInterceptor}} has to iterate through the list of results again in order to remove them. > It should be simpler to move all the availability checks to the distribution interceptor, and remove the {{PartitionHandlingInterceptor}}. DI already calls some {{PartitionHandlingManager}} methods directly, in order to keep track of partially committed transactions. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7931) Uber jars should not be pushed to Maven

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-7931?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7931: ---------------------------------- Fix Version/s: 9.4.2.Final (was: 9.4.1.Final) > Uber jars should not be pushed to Maven > --------------------------------------- > > Key: ISPN-7931 > URL: https://issues.jboss.org/browse/ISPN-7931 > Project: Infinispan > Issue Type: Bug > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Major > Fix For: 9.4.2.Final > > > Instead they should be treated just like other zip distros that are not pushed. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7943) Test remote continuous query in compat mode with jboss marshalling

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-7943?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7943: ---------------------------------- Fix Version/s: 9.4.2.Final (was: 9.4.1.Final) > Test remote continuous query in compat mode with jboss marshalling > ------------------------------------------------------------------ > > Key: ISPN-7943 > URL: https://issues.jboss.org/browse/ISPN-7943 > Project: Infinispan > Issue Type: Task > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Major > Fix For: 9.4.2.Final > > > Remote CQ was only tested with Protobuf. We did not initially aim at making this work without protobuf (ie using java serialization/jboss marshalling) but it seems it should work out of the box. We just need to add a test to prove this, and then document it. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7912) Prevent RocksDBStore writes blocking on full expiry queue

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-7912?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7912: ---------------------------------- Fix Version/s: 9.4.2.Final (was: 9.4.1.Final) > Prevent RocksDBStore writes blocking on full expiry queue > --------------------------------------------------------- > > Key: ISPN-7912 > URL: https://issues.jboss.org/browse/ISPN-7912 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Affects Versions: 9.1.0.Alpha1 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 9.4.2.Final > > > Currently you can only insert 10000 elements into the rocks db store until you will block a thread until the expiration reaper is ran. Instead we should offer elements to the queue and upon failure utilise the persistence executors to run purge. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7859) Return proper 2XX codes in REST PUT/POST methods

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-7859?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7859: ---------------------------------- Fix Version/s: 9.4.2.Final (was: 9.4.1.Final) > Return proper 2XX codes in REST PUT/POST methods > ------------------------------------------------ > > Key: ISPN-7859 > URL: https://issues.jboss.org/browse/ISPN-7859 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.1.0.Final > Reporter: Sebastian Łaskawiec > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 9.4.2.Final > > > The REST interface currently returns only 200 on PUT/POST calls. We should adjust it to 201, 204 and 200. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 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.4.2.Final (was: 9.4.1.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 > Priority: Major > Fix For: 9.4.2.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.12.1#712002)

5 years, 6 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.4.2.Final (was: 9.4.1.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 > Priority: Major > Labels: testsuite_stability > Fix For: 9.4.2.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.12.1#712002)

5 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2018