January 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11182) SiteMasterPickerImpl should return null when there are no addresses

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11182?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11182: ----------------------------------- Fix Version/s: 10.1.2.Final (was: 10.1.1.Final) > SiteMasterPickerImpl should return null when there are no addresses > ------------------------------------------------------------------- > > Key: ISPN-11182 > URL: https://issues.redhat.com/browse/ISPN-11182 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication > Affects Versions: 9.4.17.Final, 10.1.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 9.4.18.Final, 10.1.2.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11179) server-runtime test suite okhttp thread leaks

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11179?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11179: ----------------------------------- Fix Version/s: 10.1.2.Final (was: 10.1.1.Final) > server-runtime test suite okhttp thread leaks > --------------------------------------------- > > Key: ISPN-11179 > URL: https://issues.redhat.com/browse/ISPN-11179 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite > Affects Versions: 10.1.0.Final > Reporter: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 10.1.2.Final > > > {{Testcontainers}} connects to the Docker daemon using the REST API over the Unix socket at {{/var/run/docker.sock}} (using {{dockerjava}} and {{OkHttpClient}}). > Following logs requires a long-running connection, and {{LogUtils.attachConsumer}} discards the stream from OkHttpClient/dockerjava, so the connection is never closed. Perhaps the Testcontainers authors assumed that the docker server will kill the connection when the container is stopped, but that doesn't happen. > {noformat} > testng-ResilienceIT starting thread tc-okhttp-stream-1106493516 > at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.executeAndStream(OkHttpInvocationBuilder.java:322) > at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.executeAndStream(OkHttpInvocationBuilder.java:295) > at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.get(OkHttpInvocationBuilder.java:89) > at com.github.dockerjava.core.exec.LogContainerCmdExec.execute0(LogContainerCmdExec.java:42) > at com.github.dockerjava.core.exec.LogContainerCmdExec.execute0(LogContainerCmdExec.java:12) > at com.github.dockerjava.core.exec.AbstrAsyncDockerCmdExec.execute(AbstrAsyncDockerCmdExec.java:56) > at com.github.dockerjava.core.exec.AbstrAsyncDockerCmdExec.exec(AbstrAsyncDockerCmdExec.java:21) > at com.github.dockerjava.core.exec.AbstrAsyncDockerCmdExec.exec(AbstrAsyncDockerCmdExec.java:12) > at com.github.dockerjava.core.command.AbstrAsyncDockerCmd.exec(AbstrAsyncDockerCmd.java:21) > at org.testcontainers.utility.LogUtils.attachConsumer(LogUtils.java:99) > at org.testcontainers.utility.LogUtils.followOutput(LogUtils.java:36) > at org.testcontainers.utility.LogUtils.followOutput(LogUtils.java:51) > at org.testcontainers.containers.Container.followOutput(Container.java:391) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1540) > at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:412) > at org.testcontainers.containers.GenericContainer.lambda$doStart$0(GenericContainer.java:317) > at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:81) > at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:315) > at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:302) > at org.infinispan.server.test.ContainerInfinispanServerDriver.start(ContainerInfinispanServerDriver.java:146) > at org.infinispan.server.test.InfinispanServerDriver.start(InfinispanServerDriver.java:109) > at org.infinispan.server.test.InfinispanServerRule$1.evaluate(InfinispanServerRule.java:86) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11173) Add --excludeGeneratedBy cmdline option to javadoc tool to allow excluding classes generated by certain code generators

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11173?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11173: ----------------------------------- Fix Version/s: 10.1.2.Final (was: 10.1.1.Final) > Add --excludeGeneratedBy cmdline option to javadoc tool to allow excluding classes generated by certain code generators > ----------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-11173 > URL: https://issues.redhat.com/browse/ISPN-11173 > Project: Infinispan > Issue Type: Bug > Components: Documentation > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 10.1.2.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4936) Upgrage commons-pool to 2.2

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-4936?page=com.atlassian.jira.plugin... ] Tristan Tarrant closed ISPN-4936. --------------------------------- Fix Version/s: 9.3.0.Final (was: 7.0.0.Final) Resolution: Out of Date The Hot Rod client no longer uses commons-pool for pooling > Upgrage commons-pool to 2.2 > --------------------------- > > Key: ISPN-4936 > URL: https://issues.redhat.com/browse/ISPN-4936 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 7.0.0.Final > Reporter: gattu8883 gattu8883 > Priority: Blocker > Fix For: 9.3.0.Final > > > Please upgrade commons-pool version to 2.2 for client-hotrod protocol properties. In newer version there is a lot of done to avoid locking in connection pool -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11154) Use Log4j's BasicContextSelector in the server

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11154?page=com.atlassian.jira.plugi... ] Tristan Tarrant resolved ISPN-11154. ------------------------------------ Resolution: Done > Use Log4j's BasicContextSelector in the server > ---------------------------------------------- > > Key: ISPN-11154 > URL: https://issues.redhat.com/browse/ISPN-11154 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 10.1.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.1.1.Final > > > https://logging.apache.org/log4j/2.x/manual/logsep.html > because of the use of the default ClassLoaderContextSelector the server creates three LoggerContexts (one for JUL, one for JBoss Logging and one for RMI). > We should switch to the BasicContextSelector so that only a single loggercontext is created. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11038) Remove splash resources from server

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11038?page=com.atlassian.jira.plugi... ] Tristan Tarrant resolved ISPN-11038. ------------------------------------ Fix Version/s: 10.1.0.Final Resolution: Done > Remove splash resources from server > ----------------------------------- > > Key: ISPN-11038 > URL: https://issues.redhat.com/browse/ISPN-11038 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Affects Versions: 10.1.0.Beta1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.1.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11186) Updating from 9.X to 10.X breaks

by Lingchao Chen (Jira)

Lingchao Chen created ISPN-11186: ------------------------------------ Summary: Updating from 9.X to 10.X breaks Key: ISPN-11186 URL: https://issues.redhat.com/browse/ISPN-11186 Project: Infinispan Issue Type: Feature Request Reporter: Lingchao Chen When I try to upgrade infinispan-core from 9.X to 10.X. The following code breaks. {code:java} import org.infinispan.health.ClusterHealth; public class Demo { private ClusterHealth clusterHealth; public void test() { switch (clusterHealth.getHealthStatus()) { case HEALTHY: // do sth case REBALANCING: // do sth case UNHEALTHY: // do sth } } } {code} The code should pass, but it throws an error: {code:java} [ERROR] /Demo.java:[14,14] an enum switch case label must be the unqualified name of an enumeration constant [ERROR] /Demo.java:[16,14] an enum switch case label must be the unqualified name of an enumeration constant {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11185) Infinispan should not auto-export 'base' and 'vendor' MicroProfile metric registries

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11185?page=com.atlassian.jira.plugi... ] Gustavo Fernandes reassigned ISPN-11185: ---------------------------------------- Assignee: Nistor Adrian (was: Gustavo Fernandes) > Infinispan should not auto-export 'base' and 'vendor' MicroProfile metric registries > ------------------------------------------------------------------------------------ > > Key: ISPN-11185 > URL: https://issues.redhat.com/browse/ISPN-11185 > Project: Infinispan > Issue Type: Bug > Components: Analytics > Affects Versions: 10.0.1.Final, 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Nistor Adrian > Priority: Major > > ISPN-11106 seems to assume that Infinispan is the only component using MicroProfile metrics. > However, ultimately, the task of exporting base and vendor metrics is the responsibility of the MicroProfile container - not of an individual component. > At the very least, I need to be able to disable this logic. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11185) Infinispan should not auto-export 'base' and 'vendor' MicroProfile metric registries

by Paul Ferraro (Jira)

Paul Ferraro created ISPN-11185: ----------------------------------- Summary: Infinispan should not auto-export 'base' and 'vendor' MicroProfile metric registries Key: ISPN-11185 URL: https://issues.redhat.com/browse/ISPN-11185 Project: Infinispan Issue Type: Bug Components: Analytics Affects Versions: 10.1.0.Final, 10.0.1.Final Reporter: Paul Ferraro Assignee: Gustavo Fernandes ISPN-11106 seems to assume that Infinispan is the only component using MicroProfile metrics. However, ultimately, the task of exporting base and vendor metrics is the responsibility of the MicroProfile container - not of an individual component. At the very least, I need to be able to disable this logic. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11184) Infinispan MicroProfile metrics are registered to the wrong scope

by Paul Ferraro (Jira)

Paul Ferraro created ISPN-11184: ----------------------------------- Summary: Infinispan MicroProfile metrics are registered to the wrong scope Key: ISPN-11184 URL: https://issues.redhat.com/browse/ISPN-11184 Project: Infinispan Issue Type: Bug Components: Analytics Affects Versions: 10.1.0.Final, 10.0.1.Final Reporter: Paul Ferraro Assignee: Nistor Adrian Infinispan registers MicroProfile metrics using application scope. This scope is reserved for applications, and use vendor scope instead. https://download.eclipse.org/microprofile/microprofile-metrics-2.2/microp... Without a mechanism to override the ApplicationMetricsRegistry, I've file this as a blocker as it currently blocks integration into WildFly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 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 January 2020