September 2020 - infinispan-issues

[JBoss JIRA] (ISPN-12317) WildFly modules integration tests do not start after surefire 3.0.0-M5 upgrade

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-12317?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-12317: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8684 > WildFly modules integration tests do not start after surefire 3.0.0-M5 upgrade > ------------------------------------------------------------------------------ > > Key: ISPN-12317 > URL: https://issues.redhat.com/browse/ISPN-12317 > Project: Infinispan > Issue Type: Bug > Components: Build, Test Suite > Affects Versions: 12.0.0.Dev03 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 12.0.0.Dev04 > > > The {{integrationtests/server-integration/wildfly-modules}} tests do not start because of a {{NoClassDefFoundError}}: > {noformat} > ./integrationtests/server-integration/wildfly-modules/target/failsafe-reports/2020-09-07T07-11-49_195-jvmRun1.dump > # Created at 2020-09-07T07:24:46.704 > java.lang.NoClassDefFoundError: org/infinispan/test/integration/as/client/AbstractHotRodClientIT > at java.base/java.lang.ClassLoader.defineClass1(Native Method) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1096) > at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:206) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:759) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:680) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:605) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > at org.apache.maven.surefire.api.util.DefaultScanResult.loadClass(DefaultScanResult.java:136) > at org.apache.maven.surefire.api.util.DefaultScanResult.applyFilter(DefaultScanResult.java:100) > at org.apache.maven.surefire.junitcore.JUnitCoreProvider.scanClassPath(JUnitCoreProvider.java:292) > at org.apache.maven.surefire.junitcore.JUnitCoreProvider.setTestsToRun(JUnitCoreProvider.java:198) > at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:132) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428) > at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162) > at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548) > Caused by: java.lang.ClassNotFoundException: org.infinispan.test.integration.as.client.AbstractHotRodClientIT > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > ... 19 more > {noformat} > Further investigation shows that {{AbstractHotRodClientIT}} does exist on the classpath, but the classloader is trying to load it from the wrong jar: {{infinispan-wildfly-module-integrationtests-12.0.0-SNAPSHOT.jar}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (ISPN-12317) WildFly modules integration tests do not start after surefire 3.0.0-M5 upgrade

by Dan Berindei (Jira)

Dan Berindei created ISPN-12317: ----------------------------------- Summary: WildFly modules integration tests do not start after surefire 3.0.0-M5 upgrade Key: ISPN-12317 URL: https://issues.redhat.com/browse/ISPN-12317 Project: Infinispan Issue Type: Bug Components: Build, Test Suite Affects Versions: 12.0.0.Dev03 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 12.0.0.Dev04 The {{integrationtests/server-integration/wildfly-modules}} tests do not start because of a {{NoClassDefFoundError}}: {noformat} ./integrationtests/server-integration/wildfly-modules/target/failsafe-reports/2020-09-07T07-11-49_195-jvmRun1.dump # Created at 2020-09-07T07:24:46.704 java.lang.NoClassDefFoundError: org/infinispan/test/integration/as/client/AbstractHotRodClientIT at java.base/java.lang.ClassLoader.defineClass1(Native Method) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1096) at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:206) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:759) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:680) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:605) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) at org.apache.maven.surefire.api.util.DefaultScanResult.loadClass(DefaultScanResult.java:136) at org.apache.maven.surefire.api.util.DefaultScanResult.applyFilter(DefaultScanResult.java:100) at org.apache.maven.surefire.junitcore.JUnitCoreProvider.scanClassPath(JUnitCoreProvider.java:292) at org.apache.maven.surefire.junitcore.JUnitCoreProvider.setTestsToRun(JUnitCoreProvider.java:198) at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:132) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428) at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162) at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548) Caused by: java.lang.ClassNotFoundException: org.infinispan.test.integration.as.client.AbstractHotRodClientIT at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) ... 19 more {noformat} Further investigation shows that {{AbstractHotRodClientIT}} does exist on the classpath, but the classloader is trying to load it from the wrong jar: {{infinispan-wildfly-module-integrationtests-12.0.0-SNAPSHOT.jar}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (ISPN-12316) Convert expiration to no longer use transactions

by Will Burns (Jira)

Will Burns created ISPN-12316: --------------------------------- Summary: Convert expiration to no longer use transactions Key: ISPN-12316 URL: https://issues.redhat.com/browse/ISPN-12316 Project: Infinispan Issue Type: Enhancement Reporter: Will Burns Fix For: 12.0.0.Final Currently when an entry is expired we remove it via the transactional mode of the cache, ie. if transaction we start a new transaction. We should instead always remove these elements in a non transactional way similar to putForExternalRead. This will make transaction processing much simpler as there is only one mode instead of 3+. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (ISPN-12029) Replace Blocking Executor with an EnhancedQueueExecutor

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12029?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12029: ------------------------------- Fix Version/s: 12.0.0.Dev03 (was: 12.0.0.Final) > Replace Blocking Executor with an EnhancedQueueExecutor > ------------------------------------------------------- > > Key: ISPN-12029 > URL: https://issues.redhat.com/browse/ISPN-12029 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Dev03, 11.0.4.Final > > > The blocking executor today uses a simple ThreadPoolExecutor. Unfortunately, this means that we will eventually start all configured threads (since core = max and we require a queue). Setting core size to less than max is not desirable as well as it will enqueue additional tasks rather than spawn a thread. > > The EnhancedQueueExecutor does exactly what we want and also has some additional features. We should utilize this which will keep our blocking thread pool size down during times of less activity. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (ISPN-12029) Replace Blocking Executor with an EnhancedQueueExecutor

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12029?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12029: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Replace Blocking Executor with an EnhancedQueueExecutor > ------------------------------------------------------- > > Key: ISPN-12029 > URL: https://issues.redhat.com/browse/ISPN-12029 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.4.Final, 12.0.0.Dev03 > > > The blocking executor today uses a simple ThreadPoolExecutor. Unfortunately, this means that we will eventually start all configured threads (since core = max and we require a queue). Setting core size to less than max is not desirable as well as it will enqueue additional tasks rather than spawn a thread. > > The EnhancedQueueExecutor does exactly what we want and also has some additional features. We should utilize this which will keep our blocking thread pool size down during times of less activity. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (ISPN-12162) Fix marshaller inconsistent configuration

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12162?page=com.atlassian.jira.plugi... ] Pedro Ruivo closed ISPN-12162. ------------------------------ > Fix marshaller inconsistent configuration > ----------------------------------------- > > Key: ISPN-12162 > URL: https://issues.redhat.com/browse/ISPN-12162 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 11.0.1.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > Fix For: 12.0.0.Dev01, 11.0.4.Final > > > When we use the marshaller method > public ConfigurationBuilder marshaller(Class<? extends Marshaller> marshaller) > or > public ConfigurationBuilder marshaller(String marshaller) > > if a mashaller was already configured, we can't override the configuration, as it may happen that the marshaller and marshaller class don't match. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (ISPN-12162) Fix marshaller inconsistent configuration

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12162?page=com.atlassian.jira.plugi... ] Pedro Ruivo resolved ISPN-12162. -------------------------------- Resolution: Done > Fix marshaller inconsistent configuration > ----------------------------------------- > > Key: ISPN-12162 > URL: https://issues.redhat.com/browse/ISPN-12162 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 11.0.1.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > Fix For: 11.0.4.Final, 12.0.0.Dev01 > > > When we use the marshaller method > public ConfigurationBuilder marshaller(Class<? extends Marshaller> marshaller) > or > public ConfigurationBuilder marshaller(String marshaller) > > if a mashaller was already configured, we can't override the configuration, as it may happen that the marshaller and marshaller class don't match. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (ISPN-12162) Fix marshaller inconsistent configuration

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12162?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12162: ------------------------------- Fix Version/s: 11.0.4.Final > Fix marshaller inconsistent configuration > ----------------------------------------- > > Key: ISPN-12162 > URL: https://issues.redhat.com/browse/ISPN-12162 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 11.0.1.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > Fix For: 12.0.0.Dev01, 11.0.4.Final > > > When we use the marshaller method > public ConfigurationBuilder marshaller(Class<? extends Marshaller> marshaller) > or > public ConfigurationBuilder marshaller(String marshaller) > > if a mashaller was already configured, we can't override the configuration, as it may happen that the marshaller and marshaller class don't match. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (ISPN-12162) Fix marshaller inconsistent configuration

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12162?page=com.atlassian.jira.plugi... ] Pedro Ruivo reopened ISPN-12162: -------------------------------- > Fix marshaller inconsistent configuration > ----------------------------------------- > > Key: ISPN-12162 > URL: https://issues.redhat.com/browse/ISPN-12162 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 11.0.1.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > Fix For: 12.0.0.Dev01 > > > When we use the marshaller method > public ConfigurationBuilder marshaller(Class<? extends Marshaller> marshaller) > or > public ConfigurationBuilder marshaller(String marshaller) > > if a mashaller was already configured, we can't override the configuration, as it may happen that the marshaller and marshaller class don't match. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (ISPN-12250) Add exponential back-off for cross-site network failures

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12250?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12250: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/8672, https://github.com/infinispan/infinispan/pull/8682 (was: https://github.com/infinispan/infinispan/pull/8672) > Add exponential back-off for cross-site network failures > -------------------------------------------------------- > > Key: ISPN-12250 > URL: https://issues.redhat.com/browse/ISPN-12250 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication > Affects Versions: 12.0.0.Dev02 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 12.0.0.Dev04 > > > If the remote site doesn't exist (crash or shutdown), the IRAC algorithm keeps trying to send the updates to the remote site (until automatic take offline is triggered, when configured). > Add an exponential backoff to avoid CPU consumption. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2020