June 2018 - infinispan-issues - Jboss List Archives

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

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-7415?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-7415: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.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 > Fix For: 9.4.0.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.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7407) Investigate flow control performance

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-7407?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-7407: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > Investigate flow control performance > ------------------------------------ > > Key: ISPN-7407 > URL: https://issues.jboss.org/browse/ISPN-7407 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.4.0.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7401) AbstractProtocolServer relying on startDefaultCache

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-7401?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-7401: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > AbstractProtocolServer relying on startDefaultCache > --------------------------------------------------- > > Key: ISPN-7401 > URL: https://issues.jboss.org/browse/ISPN-7401 > Project: Infinispan > Issue Type: Task > Components: Server > Reporter: Sanne Grinovero > Assignee: Tristan Tarrant > Fix For: 9.4.0.Final > > > The {{AbstractProtocolServer}} class is used/extended by various other tools, including testing infrastructure of OGM. > It currently is "booting" the system by starting the default cache. This concept needs an update. > See {{org.infinispan.server.core.AbstractProtocolServer.startDefaultCache()}} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

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

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-7302?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-7302: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.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.0.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.5.0#75005)

6 years, 6 months

1
0
0 / 0

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

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-7288?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-7288: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.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 > Fix For: 9.4.0.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.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7272) Remove replication statistics from RpcManagerImpl

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-7272?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-7272: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > Remove replication statistics from RpcManagerImpl > ------------------------------------------------- > > Key: ISPN-7272 > URL: https://issues.jboss.org/browse/ISPN-7272 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.1.6.Final, 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.4.0.Final > > > The replication statistics exposed by {{RpcManagerImpl}} are too low-level. For instance, in non-transactional caches, the times of the RPCs from the primary to the backups are counted both on the primary and on the originator (as part of the originator-to-primary RPC). They also aren't split by operation, like the {{CacheMgmtInterceptor}} statistics, which makes them even less useful. > The triangle algorithm changes things again, but only for distributed caches, so there is now one more way of interpreting the {{RpcManagerImpl}} statistics. It would be better to remove them altogether. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7168) Prevent user from configuring passivation with a shared store

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-7168?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-7168: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > Prevent user from configuring passivation with a shared store > ------------------------------------------------------------- > > Key: ISPN-7168 > URL: https://issues.jboss.org/browse/ISPN-7168 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.4.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 9.4.0.Final > > > Passivation only makes sense with a non shared cache store. --The problem is that if an entry is passivated on a shared cache store only the first node will be able to activate the entry and subsequent nodes will always see null.-- > Looking closer the bigger issue is if an entry becomes passivated and then subsequently written to you will have a different value in the store as you would in memory. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

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

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-7167?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-7167: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.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.0.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.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7159) CompleteShutdownDistRetryTest.testRetryAfterCompleteShutdown random failures

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-7159?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-7159: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > CompleteShutdownDistRetryTest.testRetryAfterCompleteShutdown random failures > ---------------------------------------------------------------------------- > > Key: ISPN-7159 > URL: https://issues.jboss.org/browse/ISPN-7159 > 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.0.Final > > > {noformat} > java.lang.AssertionError: expected:<two> but was:<null> > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:101) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:108) > at org.infinispan.client.hotrod.retry.CompleteShutdownDistRetryTest.testRetryAfterCompleteShutdown(CompleteShutdownDistRetryTest.java:58) > {noformat} > I think the problem is that killing node 0 can make node 2's key move from node 2 to node 1, and then it's lost after node 1 is also killed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7145) Rebase JGroups subsystem on WildFly 10.1

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-7145?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-7145: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > Rebase JGroups subsystem on WildFly 10.1 > ---------------------------------------- > > Key: ISPN-7145 > URL: https://issues.jboss.org/browse/ISPN-7145 > Project: Infinispan > Issue Type: Task > Components: Server > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.4.0.Final > > > Our JGroups subsystem is based on the corresponding subsystem from WildFly 9. We should rebase on WildFly 10, most notably in order to pick up the WFCORE-1127 fix. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 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 June 2018