January 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (IPROTO-62) Implement annotation based schema generation support for 'oneof'

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-62?page=com.atlassian.jira.plugin... ] Nistor Adrian updated IPROTO-62: -------------------------------- Fix Version/s: 4.3.3.Final (was: 4.3.2.Final) > Implement annotation based schema generation support for 'oneof' > ---------------------------------------------------------------- > > Key: IPROTO-62 > URL: https://issues.redhat.com/browse/IPROTO-62 > Project: Infinispan ProtoStream > Issue Type: Enhancement > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 4.3.3.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-63) writeObject throws IllegalArgumentException with oneof label

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-63?page=com.atlassian.jira.plugin... ] Nistor Adrian updated IPROTO-63: -------------------------------- Fix Version/s: 4.3.3.Final (was: 4.3.2.Final) > writeObject throws IllegalArgumentException with oneof label > ------------------------------------------------------------ > > Key: IPROTO-63 > URL: https://issues.redhat.com/browse/IPROTO-63 > Project: Infinispan ProtoStream > Issue Type: Bug > Reporter: Ryan Emerson > Assignee: Nistor Adrian > Priority: Major > Fix For: 4.3.3.Final > > > The below schema results in the following exception: > Schema: > {code:java} > message EntryVersion { > oneof version { > NumericVersion numeric = 1; > ClusteredVersion clustered = 2; > } > // optional NumericVersion numeric = 1; > // optional ClusteredVersion clustered = 2; > } > message NumericVersion { > required int64 version = 1; > } > message ClusteredVersion { > required int64 version = 1; > required int32 topology = 2; > } > {code} > Exception: > {code:java} > java.lang.IllegalArgumentException: Declared field type is not a message or an enum : numeric > {code} > It seems this is caused because the type for the field "numeric" is null in the associated FieldDescriptor object that is retrieved in the [writeObject impl|https://github.com/infinispan/protostream/blob/master/core/src/main/...]. > If the oneof label is replaced with the commented optional fields, the marshallers work as expected. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-42) Add Protostream support in the jvm-serializers benchmark

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-42?page=com.atlassian.jira.plugin... ] Nistor Adrian updated IPROTO-42: -------------------------------- Fix Version/s: 4.3.3.Final (was: 4.3.2.Final) > Add Protostream support in the jvm-serializers benchmark > -------------------------------------------------------- > > Key: IPROTO-42 > URL: https://issues.redhat.com/browse/IPROTO-42 > Project: Infinispan ProtoStream > Issue Type: Feature Request > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 4.3.3.Final > > > This is a well-known (but not a 'standard') benchmark comparing performance of various serilization libs that can be used on the JVM: > https://eishay.github.io/jvm-serializers/prototype-results-page/ > Adding Protostream support is a must before continuing any perf improvements. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-47) A new declarative API using entity field bindings with lambdas

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-47?page=com.atlassian.jira.plugin... ] Nistor Adrian updated IPROTO-47: -------------------------------- Fix Version/s: 4.3.3.Final (was: 4.3.2.Final) > A new declarative API using entity field bindings with lambdas > -------------------------------------------------------------- > > Key: IPROTO-47 > URL: https://issues.redhat.com/browse/IPROTO-47 > Project: Infinispan ProtoStream > Issue Type: Feature Request > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 4.3.3.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-40) Handle proto files which begin with the BOM

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-40?page=com.atlassian.jira.plugin... ] Nistor Adrian updated IPROTO-40: -------------------------------- Fix Version/s: 4.3.3.Final (was: 4.3.2.Final) > Handle proto files which begin with the BOM > -------------------------------------------- > > Key: IPROTO-40 > URL: https://issues.redhat.com/browse/IPROTO-40 > Project: Infinispan ProtoStream > Issue Type: Enhancement > Reporter: Tristan Tarrant > Assignee: Nistor Adrian > Priority: Major > Fix For: 4.3.3.Final > > > Protostream should be able to handle files which begin with the UTF-8 BOM (EF BB BF) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-126) JDK version check in the annotation processor fails on JDK 14-ea / 15-ea

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-126?page=com.atlassian.jira.plugi... ] Nistor Adrian updated IPROTO-126: --------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/protostream/pull/88 > JDK version check in the annotation processor fails on JDK 14-ea / 15-ea > ------------------------------------------------------------------------ > > Key: IPROTO-126 > URL: https://issues.redhat.com/browse/IPROTO-126 > Project: Infinispan ProtoStream > Issue Type: Bug > Affects Versions: 4.3.1.Final > Reporter: Rostislav Svoboda > Assignee: Nistor Adrian > Priority: Major > Fix For: 4.3.2.Final > > > JDK version check in the annotation processor fails on JDK 14-ea / 15-ea > Currently https://github.com/infinispan/protostream/blob/master/processor/src/main/... can't handle {{XY-ea}} builds of JDK > {code} > Caused by: java.lang.NumberFormatException: For input string: "14-ea" > at java.lang.NumberFormatException.forInputString (NumberFormatException.java:68) > at java.lang.Integer.parseInt (Integer.java:652) > at java.lang.Integer.parseInt (Integer.java:770) > at org.infinispan.protostream.annotations.impl.processor.AutoProtoSchemaBuilderAnnotationProcessor.getJavaMajorVersion (AutoProtoSchemaBuilderAnnotationProcessor.java:214) > {code} > Noticed via integration-tests/infinispan-client when trying to verify https://github.com/quarkusio/quarkus/issues/5554 with latest jdk builds. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-126) JDK version check in the annotation processor fails on JDK 14-ea / 15-ea

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-126?page=com.atlassian.jira.plugi... ] Nistor Adrian updated IPROTO-126: --------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Fixed, to be released in 4.3.2.Final > JDK version check in the annotation processor fails on JDK 14-ea / 15-ea > ------------------------------------------------------------------------ > > Key: IPROTO-126 > URL: https://issues.redhat.com/browse/IPROTO-126 > Project: Infinispan ProtoStream > Issue Type: Bug > Affects Versions: 4.3.1.Final > Reporter: Rostislav Svoboda > Assignee: Nistor Adrian > Priority: Major > Fix For: 4.3.2.Final > > > JDK version check in the annotation processor fails on JDK 14-ea / 15-ea > Currently https://github.com/infinispan/protostream/blob/master/processor/src/main/... can't handle {{XY-ea}} builds of JDK > {code} > Caused by: java.lang.NumberFormatException: For input string: "14-ea" > at java.lang.NumberFormatException.forInputString (NumberFormatException.java:68) > at java.lang.Integer.parseInt (Integer.java:652) > at java.lang.Integer.parseInt (Integer.java:770) > at org.infinispan.protostream.annotations.impl.processor.AutoProtoSchemaBuilderAnnotationProcessor.getJavaMajorVersion (AutoProtoSchemaBuilderAnnotationProcessor.java:214) > {code} > Noticed via integration-tests/infinispan-client when trying to verify https://github.com/quarkusio/quarkus/issues/5554 with latest jdk builds. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11212) Ensure max idle works with passivation

by Tristan Tarrant (Jira)

Tristan Tarrant created ISPN-11212: -------------------------------------- Summary: Ensure max idle works with passivation Key: ISPN-11212 URL: https://issues.redhat.com/browse/ISPN-11212 Project: Infinispan Issue Type: Bug Components: Expiration, Loaders and Stores Affects Versions: 10.1.1.Final Reporter: Tristan Tarrant Assignee: Will Burns Fix For: 11.0.0.Final We need to have tests in place that ensure that maxIdle expiration works in combination with passivation. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11210) Classloading issues when using annotation generated marshallers in deployed server tasks

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/ISPN-11210?page=com.atlassian.jira.plugi... ] Nistor Adrian updated ISPN-11210: --------------------------------- Fix Version/s: 10.1.2.Final 11.0.0.Alpha1 > Classloading issues when using annotation generated marshallers in deployed server tasks > ---------------------------------------------------------------------------------------- > > Key: ISPN-11210 > URL: https://issues.redhat.com/browse/ISPN-11210 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.4.0.Final > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1 > > > A server task is deployed and the task generates annotation based protostream marshallers during context init. > A NullPointerException is thrown as seen in this stacktrace, but this is another issue in javassist which obscures the real reason, a java.lang.NoClassDefFoundError: org/infinispan/protostream/ImmutableSerializationContext. > The NoClassDefFoundError is caused by the use of the thread context classloader in the ClassPool of javassist. The TCL is not always suitable. At least it never is for deployed server tasks. There is no workaround for this, and the only option is to modify ProtoSchemaBuilder.build signature, or add an overloaded method that also accepts a ClassLoader so the user can take control. > {code} > 18:40:18,528 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderPerCacheInboundInvocationHandler] (remote-thread--p2-t1) ISPN000071: Caught exception when handling command DistributedExecuteCommand [cache=Cache 'addressbook'@manapakam, keys=[], callable=org.infinispan.server.infinispan.task.DistributedServerTask@5403bdfd]: org.infinispan.protostream.annotations.ProtoSchemaBuilderException: Failed to generate marshaller implementation class > at org.infinispan.protostream.annotations.impl.ProtoSchemaGenerator.generateAndRegister(ProtoSchemaGenerator.java:144) > at org.infinispan.protostream.annotations.ProtoSchemaBuilder.build(ProtoSchemaBuilder.java:235) > at test.cacheloader.impl.RemoveObjectsTask.setTaskContext(RemoveObjectsTask.java:57) > at org.infinispan.server.infinispan.task.ServerTaskWrapper.inject(ServerTaskWrapper.java:43) > at org.infinispan.server.infinispan.task.DistributedServerTask.call(DistributedServerTask.java:46) > at org.infinispan.commands.read.DistributedExecuteCommand.invokeAsync(DistributedExecuteCommand.java:99) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:117) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40) > 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) > Caused by: java.lang.NullPointerException > at protostream.javassist.CannotCompileException.<init>(CannotCompileException.java:77) > at protostream.javassist.util.proxy.DefineClassHelper.toClass(DefineClassHelper.java:249) > at protostream.javassist.ClassPool.toClass(ClassPool.java:1120) > at protostream.javassist.ClassPool.toClass(ClassPool.java:1083) > at protostream.javassist.ClassPool.toClass(ClassPool.java:1041) > at protostream.javassist.CtClass.toClass(CtClass.java:1278) > at org.infinispan.protostream.annotations.impl.MarshallerCodeGenerator.generateMessageMarshaller(MarshallerCodeGenerator.java:230) > at org.infinispan.protostream.annotations.impl.ProtoSchemaGenerator.generateMarshallers(ProtoSchemaGenerator.java:172) > at org.infinispan.protostream.annotations.impl.ProtoSchemaGenerator.generateAndRegister(ProtoSchemaGenerator.java:142) > ... 12 more > {code} -- 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 Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11179?page=com.atlassian.jira.plugi... ] Dan Berindei commented on ISPN-11179: ------------------------------------- Some tests also leak the {{OkHttpClient}} connection themselves. It's currently hard to track, because {{OkHttpClient}} uses {{java.util.logging}}, and one can't change its log level from the log4j2 configuration: {noformat} 16:32:36,349 WARN (OkHttp ConnectionPool:[]) [OkHttpClient] A connection to http://localhost:11222/ was leaked. Did you forget to close a response body? To see where this was allocated, set the OkHttpClient logger level to FINE: Logger.getLogger(OkHttpClient.class.getName()).setLevel(Level.FINE); {noformat} The allocation stack trace becomes visible after adding a dependency to {{log4j-jul}} and setting the log level {code:xml} <Logger name="org.testcontainers.shaded.okhttp3.OkHttpClient" level="ALL"/> {code} {noformat} 16:32:36,349 WARN (OkHttp ConnectionPool:[]) [OkHttpClient] A connection to http://localhost:11222/ was leaked. Did you forget to close a response body? java.lang.Throwable: response.body().close() at okhttp3.internal.platform.Platform.getStackTraceForCloseable(Platform.java:149) ~[okhttp-3.14.3.jar:?] at okhttp3.internal.connection.Transmitter.callStart(Transmitter.java:116) ~[okhttp-3.14.3.jar:?] at okhttp3.RealCall.enqueue(RealCall.java:92) ~[okhttp-3.14.3.jar:?] at org.infinispan.client.rest.impl.okhttp.RestClientOkHttp.execute(RestClientOkHttp.java:240) ~[infinispan-client-rest-11.0.0-SNAPSHOT.jar:11.0.0-SNAPSHOT] at org.infinispan.client.rest.impl.okhttp.RestClientOkHttp.execute(RestClientOkHttp.java:271) ~[infinispan-client-rest-11.0.0-SNAPSHOT.jar:11.0.0-SNAPSHOT] at org.infinispan.client.rest.impl.okhttp.RestClientOkHttp.execute(RestClientOkHttp.java:255) ~[infinispan-client-rest-11.0.0-SNAPSHOT.jar:11.0.0-SNAPSHOT] at org.infinispan.client.rest.impl.okhttp.RestServerClientOkHttp.configuration(RestServerClientOkHttp.java:26) ~[infinispan-client-rest-11.0.0-SNAPSHOT.jar:11.0.0-SNAPSHOT] at org.infinispan.server.functional.ShutdownRestIT.isServerShutdown(ShutdownRestIT.java:42) ~[test-classes/:?] {noformat} > 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 > Assignee: 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} > 23:30:59,573 ERROR [TestSuiteProgress] Test failed: UNKNOWN.ThreadLeakChecker > org.infinispan.commons.test.ThreadLeakChecker$LeakException: Leaked thread: tc-okhttp-stream-513080861 << testng-ResilienceIT << UNKNOWN > at org.testcontainers.shaded.org.scalasbt.ipcsocket.UnixDomainSocketLibrary.read(Native Method) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.shaded.org.scalasbt.ipcsocket.UnixDomainSocket$UnixDomainSocketInputStream.doRead(UnixDomainSocket.java:149) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.shaded.org.scalasbt.ipcsocket.UnixDomainSocket$UnixDomainSocketInputStream.read(UnixDomainSocket.java:136) ~[testcontainers-1.12.4.jar:?] > at java.io.FilterInputStream.read(FilterInputStream.java:133) ~[?:?] > at org.testcontainers.dockerclient.transport.okhttp.UnixSocketFactory$1$1.read(UnixSocketFactory.java:46) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.shaded.okio.Okio$2.read(Okio.java:140) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.shaded.okio.AsyncTimeout$2.read(AsyncTimeout.java:237) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.shaded.okio.RealBufferedSource.request(RealBufferedSource.java:72) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.shaded.okio.RealBufferedSource.require(RealBufferedSource.java:65) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.shaded.okio.RealBufferedSource.readHexadecimalUnsignedLong(RealBufferedSource.java:307) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.shaded.okhttp3.internal.http1.Http1ExchangeCodec$ChunkedSource.readChunkSize(Http1ExchangeCodec.java:492) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.shaded.okhttp3.internal.http1.Http1ExchangeCodec$ChunkedSource.read(Http1ExchangeCodec.java:471) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.shaded.okhttp3.internal.connection.Exchange$ResponseBodySource.read(Exchange.java:286) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.shaded.okio.RealBufferedSource.exhausted(RealBufferedSource.java:61) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder$FramedSink.accept(OkHttpInvocationBuilder.java:363) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder$FramedSink.accept(OkHttpInvocationBuilder.java:352) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.lambda$executeAndStream$3(OkHttpInvocationBuilder.java:314) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder$$Lambda$1863/0x0000000100fd5840.run(Unknown Source) ~[?:?] > at java.lang.Thread.run(Thread.java:834) ~[?:?] > Caused by: org.infinispan.commons.test.ThreadLeakChecker$LeakException: testng-ResilienceIT << UNKNOWN > at org.infinispan.commons.test.ThreadLeakChecker$ThreadInfoLocal.childValue(ThreadLeakChecker.java:107) ~[infinispan-commons-test-11.0.0-SNAPSHOT.jar:11.0.0-SNAPSHOT] > at org.infinispan.commons.test.ThreadLeakChecker$ThreadInfoLocal.childValue(ThreadLeakChecker.java:104) ~[infinispan-commons-test-11.0.0-SNAPSHOT.jar:11.0.0-SNAPSHOT] > at java.lang.ThreadLocal$ThreadLocalMap.<init>(ThreadLocal.java:411) ~[?:?] > at java.lang.ThreadLocal.createInheritedMap(ThreadLocal.java:276) ~[?:?] > at java.lang.Thread.<init>(Thread.java:450) ~[?:?] > at java.lang.Thread.<init>(Thread.java:709) ~[?:?] > at java.lang.Thread.<init>(Thread.java:630) ~[?:?] > at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.executeAndStream(OkHttpInvocationBuilder.java:319) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.executeAndStream(OkHttpInvocationBuilder.java:295) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.get(OkHttpInvocationBuilder.java:89) ~[testcontainers-1.12.4.jar:?] > at com.github.dockerjava.core.exec.LogContainerCmdExec.execute0(LogContainerCmdExec.java:42) ~[testcontainers-1.12.4.jar:?] > at com.github.dockerjava.core.exec.LogContainerCmdExec.execute0(LogContainerCmdExec.java:12) ~[testcontainers-1.12.4.jar:?] > at com.github.dockerjava.core.exec.AbstrAsyncDockerCmdExec.execute(AbstrAsyncDockerCmdExec.java:56) ~[testcontainers-1.12.4.jar:?] > at com.github.dockerjava.core.exec.AbstrAsyncDockerCmdExec.exec(AbstrAsyncDockerCmdExec.java:21) ~[testcontainers-1.12.4.jar:?] > at com.github.dockerjava.core.exec.AbstrAsyncDockerCmdExec.exec(AbstrAsyncDockerCmdExec.java:12) ~[testcontainers-1.12.4.jar:?] > at com.github.dockerjava.core.command.AbstrAsyncDockerCmd.exec(AbstrAsyncDockerCmd.java:21) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.utility.LogUtils.attachConsumer(LogUtils.java:99) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.utility.LogUtils.followOutput(LogUtils.java:36) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.utility.LogUtils.followOutput(LogUtils.java:51) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.containers.Container.followOutput(Container.java:391) ~[testcontainers-1.12.4.jar:?] > at java.util.ArrayList.forEach(ArrayList.java:1540) ~[?:?] > at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:412) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.containers.GenericContainer.lambda$doStart$0(GenericContainer.java:317) ~[testcontainers-1.12.4.jar:?] > at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:81) ~[duct-tape-1.0.8.jar:?] > at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:315) ~[testcontainers-1.12.4.jar:?] > at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:302) ~[testcontainers-1.12.4.jar:?] > at org.infinispan.server.test.ContainerInfinispanServerDriver.start(ContainerInfinispanServerDriver.java:146) ~[test-classes/:?] > at org.infinispan.server.test.InfinispanServerDriver.start(InfinispanServerDriver.java:109) ~[test-classes/:?] > at org.infinispan.server.test.InfinispanServerRule$1.evaluate(InfinispanServerRule.java:86) ~[test-classes/:?] > {noformat} -- 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