April 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5987) Create concurrent topology switch under failover unit test

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-5987?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-5987: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > Create concurrent topology switch under failover unit test > ---------------------------------------------------------- > > Key: ISPN-5987 > URL: https://issues.jboss.org/browse/ISPN-5987 > Project: Infinispan > Issue Type: Task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.0.0.Alpha2 > > > Create a unit test for ISPN-5879. > Matej built a very interesting one [here|https://raw.githubusercontent.com/mcimbora/infinispan/da971738e326a7...] but needs some further work. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5990) Upgrade javassist dependency in protostream to ensure java 8 compatibility

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-5990?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-5990: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > Upgrade javassist dependency in protostream to ensure java 8 compatibility > -------------------------------------------------------------------------- > > Key: ISPN-5990 > URL: https://issues.jboss.org/browse/ISPN-5990 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.0.0.Final, 8.1.0.Alpha1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.0.3.Final, 9.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5979) Server cache operations that don't affect the model should be executable in profile and per-server

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-5979?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-5979: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > Server cache operations that don't affect the model should be executable in profile and per-server > -------------------------------------------------------------------------------------------------- > > Key: ISPN-5979 > URL: https://issues.jboss.org/browse/ISPN-5979 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.1.0.Beta1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.0.0.Alpha2 > > > Server cache commands can be executed in both profiles and per-server, so they should be set "runtme only" when they don't affect the model. > Additionally server commands should use a more robust method of obtaining the container/cache from the operation's path address -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5975) Flush cache operation for server

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-5975?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-5975: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > Flush cache operation for server > -------------------------------- > > Key: ISPN-5975 > URL: https://issues.jboss.org/browse/ISPN-5975 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.0.0.Alpha2 > > > Implement a flush-cache operation registered for every cache type which, if passivation is enabled, evicts all entries to the store, otherwise if a write-behind cache store is enabled, it waits for completion, otherwise it does nothing. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5976) Server ops which don't manipulate the model should be runtime only

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-5976?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-5976: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > Server ops which don't manipulate the model should be runtime only > ------------------------------------------------------------------ > > Key: ISPN-5976 > URL: https://issues.jboss.org/browse/ISPN-5976 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Affects Versions: 8.1.0.Beta1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5929) InfinispanQueryIT.testQueryOnFirstNode random failures

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-5929?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-5929: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > InfinispanQueryIT.testQueryOnFirstNode random failures > ------------------------------------------------------ > > Key: ISPN-5929 > URL: https://issues.jboss.org/browse/ISPN-5929 > Project: Infinispan > Issue Type: Bug > Components: Integration , Test Suite - Query > Affects Versions: 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Adrian Nistor > Priority: Blocker > Fix For: 9.0.0.Alpha2 > > > {{InfinispanQueryIT.testQueryOnFirstNode()}} and {{InfinispanQueryIT.testQueryOnSecondNode()}} fail randomly in CI with this assertion: > {noformat} > java.lang.AssertionError: expected:<3> but was:<2> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:555) > at org.junit.Assert.assertEquals(Assert.java:542) > at org.infinispan.test.integration.as.query.InfinispanQueryIT.testQueryOnFirstNode(InfinispanQueryIT.java:99) > {noformat} > Example: http://ci.infinispan.org/viewLog.html?buildId=31810&tab=buildResultsDiv&b... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5894) Move near cache demo from source to a separate repo

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-5894?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-5894: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > Move near cache demo from source to a separate repo > --------------------------------------------------- > > Key: ISPN-5894 > URL: https://issues.jboss.org/browse/ISPN-5894 > Project: Infinispan > Issue Type: Task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.0.0.Alpha2 > > > Move near cache demo from source to a separate repo. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6041) Remote Listeners: Client event reader thread reports EOF as error

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-6041?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-6041: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > Remote Listeners: Client event reader thread reports EOF as error > ----------------------------------------------------------------- > > Key: ISPN-6041 > URL: https://issues.jboss.org/browse/ISPN-6041 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Priority: Minor > Fix For: 9.0.0.Alpha2 > > > {noformat} > 14:02:14,904 ERROR (Client-Listener-87aa07aee56d43e1) [ClientListenerNotifier] ISPN004043: Unrecoverable error reading event from server /127.0.0.1:15530, exiting event reader thread > org.infinispan.client.hotrod.exceptions.TransportException: End of stream reached! > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:198) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:305) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:147) > at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:252) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6040) FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-6040?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-6040: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-6040 > URL: https://issues.jboss.org/browse/ISPN-6040 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Priority: Blocker > Labels: testsuite_stability > Fix For: 9.0.0.Alpha2 > > > Similar to ISPN-6039, the test failure is caused by the state transfer put happening after the test's remove. > In this case, the command types are different, so blocking works correctly. However, when the {{ReadWriteKeyValueCommand}} executes before the state transfer put, it doesn't find any value, and it doesn't commit the entry. This means the key is not added to {{CommitManager}}'s {{tracker}} map, and the state transfer put is allowed to write to it - effectively undoing the remove. > {noformat} > java.lang.AssertionError: expected:<null> but was:<v0> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88) > at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.doTest(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:194) > at org.infinispan.functional.distribution.rehash.FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove(FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.java:103) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6071) NullPointerException when executing RemoveExpiredCommand

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-6071?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-6071: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > NullPointerException when executing RemoveExpiredCommand > -------------------------------------------------------- > > Key: ISPN-6071 > URL: https://issues.jboss.org/browse/ISPN-6071 > Project: Infinispan > Issue Type: Bug > Components: Expiration > Affects Versions: 8.0.2.Final > Reporter: Jason Hoetger > Assignee: William Burns > Fix For: 9.0.0.Alpha2, 8.1.4.Final, 8.2.2.Final > > > I'm running Infinispan 8.0.2 in a clustered environment with a replicated cache with a single file cache store. I'm seeing some NullPointerExceptions when Infinispan executes the RemoveExpiredCommand. Here's a snippet from the stack trace: > {noformat} > ISPN000136: Error executing command RemoveExpiredCommand, writing keys [...large key here...] > ... > Caused by: java.lang.NullPointerException: null > at org.infinispan.commands.write.RemoveExpiredCommand.setParameters(RemoveExpiredCommand.java:142) > {noformat} > Here's RemoveExpiredCommand#setParameters(...): > {code} @Override > public void setParameters(int commandId, Object[] args) { > if (commandId != COMMAND_ID) throw new IllegalStateException("Invalid method id"); > int i = 0; > commandInvocationId = (CommandInvocationId) args[i++]; > key = args[i++]; > value = args[i++]; > lifespan = (long) args[i++]; > }{code} > Line 142 is the cast of assignment of {{args\[3\]}} to primitive type long, which is causing the NPE. lifespan is actually a Long, not a long, and the {{perform()}} method seems to anticipate null lifespans at line 72: > {code} // If the provided lifespan is null, that means it is a store removal command, so we can't compare lifespan > if (lifespan == null) {}{code} > Could this be fixed by simply changing the cast at line 142 from (long) to (Long)? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2016