September 2018 - infinispan-issues

[JBoss JIRA] (ISPN-9542) DistributedStreamRehashStressTest fails many of the tests

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-9542?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-9542: ------------------------------------- Another failure is: {code} java.lang.AssertionError: We didn't get a matching size! Expected 25000 but was 24247 expected [24247] but found [25000] Expected :24247 Actual :25000 <Click to see difference> at org.testng.Assert.fail(Assert.java:94) at org.testng.Assert.failNotEquals(Assert.java:496) at org.testng.Assert.assertEquals(Assert.java:125) at org.testng.Assert.assertEquals(Assert.java:267) at org.infinispan.stream.stress.DistributedStreamRehashStressTest.lambda$testStressNodesLeavingWhileMultipleCount$1(DistributedStreamRehashStressTest.java:96) at org.infinispan.stream.stress.DistributedStreamRehashStressTest.lambda$testStressNodesLeavingWhilePerformingCallable$5(DistributedStreamRehashStressTest.java:190) at org.infinispan.commands.StressTest.lambda$forkWorkerThreads$1(StressTest.java:96) at org.infinispan.test.AbstractInfinispanTest$CallableWrapper.call(AbstractInfinispanTest.java:528) 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} > DistributedStreamRehashStressTest fails many of the tests > --------------------------------------------------------- > > Key: ISPN-9542 > URL: https://issues.jboss.org/browse/ISPN-9542 > Project: Infinispan > Issue Type: Bug > Components: Streams > Affects Versions: 9.4.0.CR3 > Reporter: William Burns > Assignee: William Burns > > Many of the stress tests either fail, timeout or say they processed no iterations. We need to ensure these are working properly. One of the causes was from https://github.com/infinispan/infinispan/pull/6270/files#r220378591. That luckily is a simple fix, however we need to plug the others. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9542) DistributedStreamRehashStressTest fails many of the tests

by William Burns (JIRA)

William Burns created ISPN-9542: ----------------------------------- Summary: DistributedStreamRehashStressTest fails many of the tests Key: ISPN-9542 URL: https://issues.jboss.org/browse/ISPN-9542 Project: Infinispan Issue Type: Bug Components: Streams Affects Versions: 9.4.0.CR3 Reporter: William Burns Assignee: William Burns Many of the stress tests either fail, timeout or say they processed no iterations. We need to ensure these are working properly. One of the causes was from https://github.com/infinispan/infinispan/pull/6270/files#r220378591. That luckily is a simple fix, however we need to plug the others. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9538) Allow for segmentation to be configurable via Features

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-9538?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9538: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/6274 > Allow for segmentation to be configurable via Features > ------------------------------------------------------ > > Key: ISPN-9538 > URL: https://issues.jboss.org/browse/ISPN-9538 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 9.4.0.Final > > > We want to allow the segmented containers to be able to be disabled for users where this is not supported. We recently added ISPN-9535 which allows for a nice easy way to do this. We just need to plug this into the DataContainerFactory class and have it enabled by default. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6212) InfinispanBackendQueueProcessor is assuming all IndexManager implementations are DirectoryBasedIndexManager

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6212?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6212: -------------------------------- Status: Open (was: New) > InfinispanBackendQueueProcessor is assuming all IndexManager implementations are DirectoryBasedIndexManager > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-6212 > URL: https://issues.jboss.org/browse/ISPN-6212 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying > Reporter: Sanne Grinovero > Fix For: 9.4.0.Final > > > See also the FIXME note in {{InfinispanBackendQueueProcessor}}: this needs to be cleaned up. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9541) Modules should not replace components after they were registered

by Dan Berindei (JIRA)

Dan Berindei created ISPN-9541: ---------------------------------- Summary: Modules should not replace components after they were registered Key: ISPN-9541 URL: https://issues.jboss.org/browse/ISPN-9541 Project: Infinispan Issue Type: Bug Components: Core, Server Affects Versions: 9.4.0.CR3 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 9.4.0.Final In my ISPN-9127 fix I created a {{BasicComponentRegistry}} interface that represents a mostly-read-only collection of components. It has {{replaceComponent()}} method and a {{rewire()}} method for testing purposes, but it turns out modules were also relying on the ability to replace existing components in order to work. Replacing global components is normally safe during the {{ModuleLifecycle.cacheManagerStarting()}}, because none of the components are started yet, so when a component starts later we can still start its dependencies first. But because some modules starts some global components, e.g. by calling {{manager.getCache(name)}}, that assumption breaks. The {{infinispan-server-event-logger}} module is a bit more sneaky: it doesn't replace a component, instead it replaces the actual implementation of the event logger in the {{EventLogManager}} component. Events that happen before the module's {{cacheManagerStarting()}} or after {{cacheManagerStopping()}} will be silently dropped from the persistent event log. I am investigating making the module a factory of factories. Instead of having a monolitic {{cacheManagerStarting()}} method, it could define a set of components that it can create, and a set of components that should be started before the cache manager is "running". We probably need a way to depend on other modules as well, maybe reusing the {{@Inject}} and {{@ComponentName}} annotations. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9541) Modules should not replace components after they were registered

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9541?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9541: ------------------------------- Status: Open (was: New) > Modules should not replace components after they were registered > ---------------------------------------------------------------- > > Key: ISPN-9541 > URL: https://issues.jboss.org/browse/ISPN-9541 > Project: Infinispan > Issue Type: Bug > Components: Core, Server > Affects Versions: 9.4.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.4.0.Final > > > In my ISPN-9127 fix I created a {{BasicComponentRegistry}} interface that represents a mostly-read-only collection of components. It has {{replaceComponent()}} method and a {{rewire()}} method for testing purposes, but it turns out modules were also relying on the ability to replace existing components in order to work. > Replacing global components is normally safe during the {{ModuleLifecycle.cacheManagerStarting()}}, because none of the components are started yet, so when a component starts later we can still start its dependencies first. But because some modules starts some global components, e.g. by calling {{manager.getCache(name)}}, that assumption breaks. > The {{infinispan-server-event-logger}} module is a bit more sneaky: it doesn't replace a component, instead it replaces the actual implementation of the event logger in the {{EventLogManager}} component. Events that happen before the module's {{cacheManagerStarting()}} or after {{cacheManagerStopping()}} will be silently dropped from the persistent event log. > I am investigating making the module a factory of factories. Instead of having a monolitic {{cacheManagerStarting()}} method, it could define a set of components that it can create, and a set of components that should be started before the cache manager is "running". We probably need a way to depend on other modules as well, maybe reusing the {{@Inject}} and {{@ComponentName}} annotations. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9540) Remove the deprecated org.infinispan.affinity.KeyAffinityServiceImpl

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-9540: ----------------------------------- Summary: Remove the deprecated org.infinispan.affinity.KeyAffinityServiceImpl Key: ISPN-9540 URL: https://issues.jboss.org/browse/ISPN-9540 Project: Infinispan Issue Type: Task Components: Core Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 10.0.0.Final, 10.0.0.Beta1 This class is deprecated in favor of org.infinispan.affinity.impl.KeyAffinityServiceImpl -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9540) Remove the deprecated org.infinispan.affinity.KeyAffinityServiceImpl

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-9540?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-9540: -------------------------------- Status: Open (was: New) > Remove the deprecated org.infinispan.affinity.KeyAffinityServiceImpl > -------------------------------------------------------------------- > > Key: ISPN-9540 > URL: https://issues.jboss.org/browse/ISPN-9540 > Project: Infinispan > Issue Type: Task > Components: Core > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 10.0.0.Final, 10.0.0.Beta1 > > > This class is deprecated in favor of org.infinispan.affinity.impl.KeyAffinityServiceImpl -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

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

7 years, 6 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7272?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-7272: ---------------------------------- Assignee: (was: Dan Berindei) > 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 > > 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)

7 years, 6 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 September 2018