April 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9064) SiteManualSwitchTest.testManualClusterSwitch randomly fails

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9064?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9064: ----------------------------------- Status: Open (was: New) > SiteManualSwitchTest.testManualClusterSwitch randomly fails > ----------------------------------------------------------- > > Key: ISPN-9064 > URL: https://issues.jboss.org/browse/ISPN-9064 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Reporter: Galder Zamarreño > Labels: testsuite_stability > Fix For: 9.3.0.Beta1, 9.3.0.Final > > > {code} > java.lang.AssertionError: expected:<1> but was:<0> > at org.infinispan.client.hotrod.xsite.AbstractHotRodSiteFailoverTest.assertSiteHit(AbstractHotRodSiteFailoverTest.java:146) > at org.infinispan.client.hotrod.xsite.SiteManualSwitchTest.assertSingleSiteHit(SiteManualSwitchTest.java:47) > at org.infinispan.client.hotrod.xsite.SiteManualSwitchTest.testManualClusterSwitch(SiteManualSwitchTest.java:37) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9064) SiteManualSwitchTest.testManualClusterSwitch randomly fails

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9064?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9064: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5913 > SiteManualSwitchTest.testManualClusterSwitch randomly fails > ----------------------------------------------------------- > > Key: ISPN-9064 > URL: https://issues.jboss.org/browse/ISPN-9064 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Reporter: Galder Zamarreño > Labels: testsuite_stability > Fix For: 9.3.0.Beta1, 9.3.0.Final > > > {code} > java.lang.AssertionError: expected:<1> but was:<0> > at org.infinispan.client.hotrod.xsite.AbstractHotRodSiteFailoverTest.assertSiteHit(AbstractHotRodSiteFailoverTest.java:146) > at org.infinispan.client.hotrod.xsite.SiteManualSwitchTest.assertSingleSiteHit(SiteManualSwitchTest.java:47) > at org.infinispan.client.hotrod.xsite.SiteManualSwitchTest.testManualClusterSwitch(SiteManualSwitchTest.java:37) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9065) JGroupsTransport should only send messages to nodes in the cluster view

by Pedro Zapata (JIRA)

Pedro Zapata created ISPN-9065: ---------------------------------- Summary: JGroupsTransport should only send messages to nodes in the cluster view Key: ISPN-9065 URL: https://issues.jboss.org/browse/ISPN-9065 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.2.1.Final Reporter: Pedro Zapata Assignee: Dan Berindei Fix For: 9.2.2.Final, 9.3.0.Alpha1 {{JGroupsTransport}} only waits for responses from nodes in the JGroups cluster view, but it still sends messages to all the nodes specified as a target. The idea was to optimize the common case by avoiding a {{HashSet.contains()}} call. However, when a node is not in the view, messages to it still pass through the entire JGroups stack, and UNICAST3 keeps those messages in a send table for a long time ({{UNICAST3.conn_expiry_timeout}}, changed with ISPN-9038 from {{0}} (unlimited) to 2 minutes (JGroups default)). Having a potentially unlimited number of messages of non-members, each with its own send table, makes it much harder to estimate memory usage. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9064) SiteManualSwitchTest.testManualClusterSwitch randomly fails

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-9064: -------------------------------------- Summary: SiteManualSwitchTest.testManualClusterSwitch randomly fails Key: ISPN-9064 URL: https://issues.jboss.org/browse/ISPN-9064 Project: Infinispan Issue Type: Bug Components: Remote Protocols Reporter: Galder Zamarreño Fix For: 9.3.0.Beta1, 9.3.0.Final {code} java.lang.AssertionError: expected:<1> but was:<0> at org.infinispan.client.hotrod.xsite.AbstractHotRodSiteFailoverTest.assertSiteHit(AbstractHotRodSiteFailoverTest.java:146) at org.infinispan.client.hotrod.xsite.SiteManualSwitchTest.assertSingleSiteHit(SiteManualSwitchTest.java:47) at org.infinispan.client.hotrod.xsite.SiteManualSwitchTest.testManualClusterSwitch(SiteManualSwitchTest.java:37) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9063) Average stats should be calculated in Nanoseconds but exposed in Milliseconds

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-9063?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9063: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5911 > Average stats should be calculated in Nanoseconds but exposed in Milliseconds > ----------------------------------------------------------------------------- > > Key: ISPN-9063 > URL: https://issues.jboss.org/browse/ISPN-9063 > Project: Infinispan > Issue Type: Bug > Components: Console, JMX, reporting and management > Affects Versions: 9.2.1.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.3.0.Alpha1 > > > ISPN-7768 changed the precision of the exposed average-<read|write>time stats from Milliseconds to Nanoseconds. This causes backwards compatibility issues with previous versions of Infinispan and JDG. Therefore we need to ensure that these stats are exposed to the user in Milliseconds, however they should still be calculated in Nanoseconds internally to improve accuracy and avoid rounding errors. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9063) Average stats should be calculated in Nanoseconds but exposed in Milliseconds

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-9063?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9063: ------------------------------- Status: Open (was: New) > Average stats should be calculated in Nanoseconds but exposed in Milliseconds > ----------------------------------------------------------------------------- > > Key: ISPN-9063 > URL: https://issues.jboss.org/browse/ISPN-9063 > Project: Infinispan > Issue Type: Bug > Components: Console, JMX, reporting and management > Affects Versions: 9.2.1.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.3.0.Alpha1 > > > ISPN-7768 changed the precision of the exposed average-<read|write>time stats from Milliseconds to Nanoseconds. This causes backwards compatibility issues with previous versions of Infinispan and JDG. Therefore we need to ensure that these stats are exposed to the user in Milliseconds, however they should still be calculated in Nanoseconds internally to improve accuracy and avoid rounding errors. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9062) JGroupsTransport should only send messages to nodes in the cluster view

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9062?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9062: ------------------------------- Status: Open (was: New) > JGroupsTransport should only send messages to nodes in the cluster view > ----------------------------------------------------------------------- > > Key: ISPN-9062 > URL: https://issues.jboss.org/browse/ISPN-9062 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.2.2.Final, 9.3.0.Alpha1 > > > {{JGroupsTransport}} only waits for responses from nodes in the JGroups cluster view, but it still sends messages to all the nodes specified as a target. The idea was to optimize the common case by avoiding a {{HashSet.contains()}} call. > However, when a node is not in the view, messages to it still pass through the entire JGroups stack, and UNICAST3 keeps those messages in a send table for a long time ({{UNICAST3.conn_expiry_timeout}}, changed with ISPN-9038 from {{0}} (unlimited) to 2 minutes (JGroups default)). Having a potentially unlimited number of messages of non-members, each with its own send table, makes it much harder to estimate memory usage. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9063) Average stats should be calculated in Nanoseconds but exposed in Milliseconds

by Ryan Emerson (JIRA)

Ryan Emerson created ISPN-9063: ---------------------------------- Summary: Average stats should be calculated in Nanoseconds but exposed in Milliseconds Key: ISPN-9063 URL: https://issues.jboss.org/browse/ISPN-9063 Project: Infinispan Issue Type: Bug Components: Console, JMX, reporting and management Affects Versions: 9.2.1.Final Reporter: Ryan Emerson Assignee: Ryan Emerson Fix For: 9.3.0.Alpha1 ISPN-7768 changed the precision of the exposed average-<read|write>time stats from Milliseconds to Nanoseconds. This causes backwards compatibility issues with previous versions of Infinispan and JDG. Therefore we need to ensure that these stats are exposed to the user in Milliseconds, however they should still be calculated in Nanoseconds internally to improve accuracy and avoid rounding errors. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9062) JGroupsTransport should only send messages to nodes in the cluster view

by Dan Berindei (JIRA)

Dan Berindei created ISPN-9062: ---------------------------------- Summary: JGroupsTransport should only send messages to nodes in the cluster view Key: ISPN-9062 URL: https://issues.jboss.org/browse/ISPN-9062 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.2.1.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 9.2.2.Final, 9.3.0.Alpha1 {{JGroupsTransport}} only waits for responses from nodes in the JGroups cluster view, but it still sends messages to all the nodes specified as a target. The idea was to optimize the common case by avoiding a {{HashSet.contains()}} call. However, when a node is not in the view, messages to it still pass through the entire JGroups stack, and UNICAST3 keeps those messages in a send table for a long time ({{UNICAST3.conn_expiry_timeout}}, changed with ISPN-9038 from {{0}} (unlimited) to 2 minutes (JGroups default)). Having a potentially unlimited number of messages of non-members, each with its own send table, makes it much harder to estimate memory usage. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9061) X-site replication with functional commands throws NullPointerException

by Dan Berindei (JIRA)

Dan Berindei created ISPN-9061: ---------------------------------- Summary: X-site replication with functional commands throws NullPointerException Key: ISPN-9061 URL: https://issues.jboss.org/browse/ISPN-9061 Project: Infinispan Issue Type: Bug Components: Cross-Site Replication Affects Versions: 9.2.1.Final Reporter: Dan Berindei {{CacheOperationsTest.testFunctional()}} checks that some keys do not exist in the cache by calling {{evalMany}} on a read-write map, but with a read-only lambda. This creates a {{VersionedRepeatableReadEntry(value=null)}} in the tx invocation context, and {{BackupSenderImpl.filterModifications()}} sends that to the remote site as a {{PutKeyValueCommand(value=null)}}. On the remote site this is translated as {{cache.put(key, null)}}, which finally throws a {{NullPointerException}}: {noformat} 15:18:54,543 WARN (remote-thread-CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeD-p40433-t6:[]) [GlobalInboundInvocationHandler] ISPN000071: Caught exception when handling command SingleXSiteRpcCommand{command=PrepareCommand {modifications=[PutKeyValueCommand{key=MagicKey#k2{1910/3D34DA4D/67@CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeB-4295}, value=null, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=0, version=0}}, successful=true, topologyId=-1}, PutKeyValueCommand{key=MagicKey#k0{190E/360DCEC7/18@CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeA-60870}, value=null, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=0, version=0}}, successful=true, topologyId=-1}, PutKeyValueCommand{key=MagicKey#k1{190F/71AF2073/6@CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeB-4295}, value=null, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=0, version=0}}, successful=true, topologyId=-1}], onePhaseCommit=false, retried=false, gtx=GlobalTx:CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeA-60870:26069, cacheName='___defaultcache', topologyId=-1}} java.lang.NullPointerException: Null values are not supported! at java.util.Objects.requireNonNull(Objects.java:228) ~[?:1.8.0_152] at org.infinispan.cache.impl.CacheImpl.assertValueNotNull(CacheImpl.java:199) ~[classes/:?] at org.infinispan.cache.impl.CacheImpl.assertKeyValueNotNull(CacheImpl.java:204) ~[classes/:?] at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1331) ~[classes/:?] at org.infinispan.cache.impl.DecoratedCache.put(DecoratedCache.java:654) ~[classes/:?] at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.put(AbstractDelegatingAdvancedCache.java:355) ~[classes/:?] at org.infinispan.cache.impl.EncoderCache.put(EncoderCache.java:425) ~[classes/:?] at org.infinispan.xsite.BaseBackupReceiver$BackupCacheUpdater.visitPutKeyValueCommand(BaseBackupReceiver.java:110) ~[classes/:?] at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67) ~[classes/:?] at org.infinispan.xsite.BaseBackupReceiver$BackupCacheUpdater.replayModifications(BaseBackupReceiver.java:259) ~[classes/:?] at org.infinispan.xsite.BaseBackupReceiver$BackupCacheUpdater.visitPrepareCommand(BaseBackupReceiver.java:155) ~[classes/:?] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:185) ~[classes/:?] at org.infinispan.xsite.BaseBackupReceiver.handleRemoteCommand(BaseBackupReceiver.java:76) ~[classes/:?] at org.infinispan.xsite.SingleXSiteRpcCommand.performInLocalSite(SingleXSiteRpcCommand.java:37) ~[classes/:?] at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.runXSiteReplicableCommand(GlobalInboundInvocationHandler.java:126) ~[classes/:?] at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.lambda$handleFromRemoteSite$0(GlobalInboundInvocationHandler.java:95) ~[classes/:?] {noformat} There's no exception on the local node, maybe because entries with null values are not committed regardless of what their flags say. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2018