November 2018 - infinispan-issues

[JBoss JIRA] (ISPN-7415) Immortal entries use EmbeddedExpirableMetadata instead of EmbeddedMetadata

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-7415?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7415: ------------------------------- Fix Version/s: 9.4.3.Final (was: 9.4.2.Final) > Immortal entries use EmbeddedExpirableMetadata instead of EmbeddedMetadata > -------------------------------------------------------------------------- > > Key: ISPN-7415 > URL: https://issues.jboss.org/browse/ISPN-7415 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 9.4.3.Final > > > The default lifespan and maxIdle are -1 to signal no expiration, but calling {{EmbeddedMetadata.Builder.lifespan\(x)}} with any value will make it create an {{EmbeddedExpirableMetadata}} instance. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7302) ClusteredConditionalCommandTest.testPutIfAbsentOnNonOwnerWithIgnoreReturnValues random failures

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-7302?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7302: ------------------------------- Fix Version/s: 9.4.3.Final (was: 9.4.2.Final) > ClusteredConditionalCommandTest.testPutIfAbsentOnNonOwnerWithIgnoreReturnValues random failures > ----------------------------------------------------------------------------------------------- > > Key: ISPN-7302 > URL: https://issues.jboss.org/browse/ISPN-7302 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 9.4.3.Final > > > When the backup owner replies before the primary had a chance to load the value from persistence, the number of loads from the primary can be {{0}} at the time the test checks it. > {noformat} > 00:21:48,941 TRACE (testng-Test:[]) [JGroupsTransport] dests=[Test-NodeB-56150, Test-NodeA-13512], command=ClusteredGetCommand{key=Test-key, flags=[IGNORE_RETURN_VALUES]}, mode=WAIT_FOR_VALID_RESPONSE, timeout=15000 > 00:21:48,942 TRACE (jgroups-7,Test-NodeB-56150:[]) [InvocationContextInterceptor] Invoked with command GetCacheEntryCommand {key=Test-key, flags=[SKIP_REMOTE_LOOKUP, IGNORE_RETURN_VALUES]} and InvocationContext [org.infinispan.context.impl.NonTxInvocationContext@5f931934] > 00:21:48,943 TRACE (jgroups-7,Test-NodeB-56150:[]) [EntryFactoryImpl] Wrap Test-key for read. Entry=NullCacheEntry{} > 00:21:48,946 TRACE (jgroups-8,Test-NodeA-13512:[]) [InvocationContextInterceptor] Invoked with command GetCacheEntryCommand {key=Test-key, flags=[SKIP_REMOTE_LOOKUP, IGNORE_RETURN_VALUES]} and InvocationContext [org.infinispan.context.impl.NonTxInvocationContext@265c6c97] > 00:21:48,946 TRACE (jgroups-8,Test-NodeA-13512:[]) [PersistenceUtil] Loaded MarshalledEntryImpl{keyBytes=null, valueBytes=null, metadataBytes=null, key=Test-key, value=Test-value1, metadata=null, marshaller=org.infinispan.marshall.core.GlobalMarshaller@1aee2408} for key Test-key from persistence. > 00:21:48,946 TRACE (jgroups-8,Test-NodeA-13512:[]) [CommandAwareRpcDispatcher] About to send back response SuccessfulResponse{responseValue=ImmortalCacheValue {value=Test-value1}} for command ClusteredGetCommand{key=Test-key, flags=[IGNORE_RETURN_VALUES]} > 00:21:48,948 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.persistence.ClusteredTxConditionalCommandTest.testPutIfAbsentOnNonOwnerWithIgnoreReturnValues[tx=true] > java.lang.AssertionError: primary owner load expected:<1> but was:<0> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:170) ~[testng-6.8.8.jar:?] > at org.infinispan.persistence.ClusteredTxConditionalCommandTest.assertLoadAfterOperation(ClusteredTxConditionalCommandTest.java:46) ~[test-classes/:?] > at org.infinispan.persistence.ClusteredConditionalCommandTest.doTest(ClusteredConditionalCommandTest.java:121) ~[test-classes/:?] > at org.infinispan.persistence.ClusteredConditionalCommandTest.testPutIfAbsentOnNonOwnerWithIgnoreReturnValues(ClusteredConditionalCommandTest.java:242) ~[test-classes/:?] > 00:21:48,953 TRACE (jgroups-7,Test-NodeB-56150:[]) [PersistenceUtil] Loaded null for key Test-key from persistence. > 00:21:48,953 TRACE (jgroups-7,Test-NodeB-56150:[]) [CommandAwareRpcDispatcher] About to send back response SuccessfulResponse{responseValue=null} for command ClusteredGetCommand{key=Test-key, flags=[IGNORE_RETURN_VALUES]} > {noformat} > Possible fix: replace {{assertEquals}} with {{eventuallyEquals}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7288) Indexed queries with IN clause should use TermsQuery

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-7288?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7288: ------------------------------- Fix Version/s: 9.4.3.Final (was: 9.4.2.Final) > Indexed queries with IN clause should use TermsQuery > ---------------------------------------------------- > > Key: ISPN-7288 > URL: https://issues.jboss.org/browse/ISPN-7288 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 8.2.5.Final, 9.0.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Adrian Nistor > Priority: Major > Fix For: 9.4.3.Final > > > There are two reasons for it: > * TermsQuery don't have a clause limit as Boolean Queries do (default is 1024) > * Performance for high number of clauses is vastly superior -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7167) ExampleConfigsIT.testTopologyConfigRackAttribute random failures

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-7167?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7167: ------------------------------- Fix Version/s: 9.4.3.Final (was: 9.4.2.Final) > ExampleConfigsIT.testTopologyConfigRackAttribute random failures > ----------------------------------------------------------------- > > Key: ISPN-7167 > URL: https://issues.jboss.org/browse/ISPN-7167 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 9.4.3.Final > > > {noformat} > java.lang.AssertionError: Unexpected number of entries in server1: 0 > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.infinispan.server.test.configs.ExampleConfigsIT.verifyTopologyHinting(ExampleConfigsIT.java:482) > at org.infinispan.server.test.configs.ExampleConfigsIT.testTopologyConfigRackAttribute(ExampleConfigsIT.java:419) > {noformat} > The test is also inconsistent about the names of the servers, sometimes it starts counting from 0 and sometimes it starts counting from 1. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7654) Ickle parser should have a different representation for each literal type instead of using string for everything

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-7654?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7654: ------------------------------- Fix Version/s: 9.4.3.Final (was: 9.4.2.Final) > Ickle parser should have a different representation for each literal type instead of using string for everything > ---------------------------------------------------------------------------------------------------------------- > > Key: ISPN-7654 > URL: https://issues.jboss.org/browse/ISPN-7654 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Major > Fix For: 9.4.3.Final > > > All constant literals regardless of type are represented as string now and are later parsed into integers, booleans, etc, when the query is translated. We should do this at the beginning phase of parsing. See ConstantLiteralTree class. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7643) Coordinator status is unavailable in Infinispan cluster

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-7643?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7643: ------------------------------- Fix Version/s: 9.4.3.Final (was: 9.4.2.Final) > Coordinator status is unavailable in Infinispan cluster > ------------------------------------------------------- > > Key: ISPN-7643 > URL: https://issues.jboss.org/browse/ISPN-7643 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Reporter: Sebastian Łaskawiec > Priority: Major > Fix For: 9.4.3.Final > > > It seems that Coordinator field uses JGroups Address class which can be displayed properly. Since we already have a Coordinator Address field, maybe the best way would be to remove this from JMX. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7606) DistributedExecutorMassIndexer.executeInternal should use an existing pool

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-7606?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7606: ------------------------------- Fix Version/s: 9.4.3.Final (was: 9.4.2.Final) > DistributedExecutorMassIndexer.executeInternal should use an existing pool > -------------------------------------------------------------------------- > > Key: ISPN-7606 > URL: https://issues.jboss.org/browse/ISPN-7606 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 9.0.0.CR2 > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 9.4.3.Final > > > {{DistributedExecutorMassIndexer.executeInternal}} creates 2 executors: > 1. {{new DefaultExecutorService(cache)}} implicitly creates a single-threaded executor to run tasks on the local node. > 2. {{compositeFuture.whenCompleteAsync(consumer, Executors.newSingleThreadExecutor())}} explicitly creates a new single-threaded executor to run the consumer on. > Neither of these executors are shut down, and rather than complicating the code to stop them properly it would be better to use an existing executor. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7600) Add Jolokia support for Managment Console

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-7600?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7600: ------------------------------- Fix Version/s: 9.4.3.Final (was: 9.4.2.Final) > Add Jolokia support for Managment Console > ----------------------------------------- > > Key: ISPN-7600 > URL: https://issues.jboss.org/browse/ISPN-7600 > Project: Infinispan > Issue Type: Feature Request > Components: JMX, reporting and management > Reporter: Sebastian Łaskawiec > Assignee: Vladimir Blagojevic > Priority: Major > Fix For: 9.4.3.Final > > > The Management Console should be able to support Jolokia-enabled endpoints. This is required for supporting the console in Embedded Mode. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7590) Invocation idempotence

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-7590?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7590: ------------------------------- Fix Version/s: 9.4.3.Final (was: 9.4.2.Final) > Invocation idempotence > ---------------------- > > Key: ISPN-7590 > URL: https://issues.jboss.org/browse/ISPN-7590 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.CR2 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Major > Labels: consistency > Fix For: 9.4.3.Final > > > This is an umbrella JIRA to change the way how we deal with retries after topology change. > Please link any outstanding issues that refer to incorrect return values of command during topology change. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

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

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-7811?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7811: ------------------------------- Fix Version/s: 9.4.3.Final (was: 9.4.2.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.3.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)

7 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2018