January 2020 - infinispan-issues - Jboss List Archives

[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 updated ISPN-11179: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7784 > 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

[JBoss JIRA] (ISPN-3215) Improve message routing for PutMapCommand for non transactional caches

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-3215?page=com.atlassian.jira.plugin... ] Dan Berindei resolved ISPN-3215. -------------------------------- Fix Version/s: 9.0.0.Final Resolution: Done Fixed with ISPN-6919 (triangle algorithm). > Improve message routing for PutMapCommand for non transactional caches > ---------------------------------------------------------------------- > > Key: ISPN-3215 > URL: https://issues.redhat.com/browse/ISPN-3215 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 6.0.0.Final > Reporter: Radim Vansa > Priority: Major > Fix For: 9.0.0.Final > > > Current implementation: > A wants to execute PutMapCommand with many keys - let's assume that in fact the keys span all nodes in the cluster. > 1. A locks all local keys and sends via unicast a message to each primary owner of some of the keys in the map > 2. A sends unicast message to each node, requesting the operation > 3. Each node locks its keys and sends multicast message to ALL other nodes in the cluster > This happens N - 1 times: > 4. Each node receives the multicast message, (updates the non-primary segments) and sends reply back to the sender of mcast message. > 5. The primary owners send confirmation back to A. > Let's compute how many messages are here received - it's > N - 1 // A's request > (N - 1) * (N - 1) // multicast message received > (N - 1) * (N - 1) // reply to the multicast message received > N - 1 // response to A > That's 2*N^2 - 2*N messages. In case nobody needs flow control replenishments, nothing is lost etc. That ^2 exponent does not look like the cluster is really scaling. > Could the requestor orchestrate the whole operation? The idea is that all messages are sent only between requestor and other nodes, never between the other nodes. The requestor would lock the primary keys by one set of messages (waiting for reply), updating the non-primaries by another set of messages and then again unlocking all primaries by last message. > The set of messages could be either unicast with selected keys only for the recipient, or multicast with whole map - rationalization which one is actually better is subject to performance test. > This results in 6*N - 6 messages (or 5*N - 5 if the last message wouldn't require the reply). You can easily see when 5*(N - 1) is better than 2*N*(N - 1). > Or is this too similar to transactions with multiple keys? > I think that with current implementation, the putAll operation should be discouraged as it does not provide better performance than multiple put (and in terms of atomicity it's probably not much better either). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6835) Improve user guide section "The Problem of Caching Arrays"

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-6835?page=com.atlassian.jira.plugin... ] Dan Berindei resolved ISPN-6835. -------------------------------- Resolution: Out of Date The section was removed in 9.0.0.Alpha1 > Improve user guide section "The Problem of Caching Arrays" > ---------------------------------------------------------- > > Key: ISPN-6835 > URL: https://issues.redhat.com/browse/ISPN-6835 > Project: Infinispan > Issue Type: Task > Components: Documentation > Affects Versions: 9.0.0.Alpha2 > Reporter: Dan Berindei > Priority: Minor > > We should make it clear that a proper implementation of equals() and hashCode() is always required for keys, but it's only necessary for values if one intends to use conditional operations. > The section should also say more about how Infinispan uses equals() and hashCode() and what our requirements are, instead of how "users would like to call" one method or another. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10839) Doc Productization: Configuring Caches Declaratively and Programmatically

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-10839?page=com.atlassian.jira.plugi... ] Donald Naro updated ISPN-10839: ------------------------------- Status: Open (was: New) > Doc Productization: Configuring Caches Declaratively and Programmatically > ------------------------------------------------------------------------- > > Key: ISPN-10839 > URL: https://issues.redhat.com/browse/ISPN-10839 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Affects Versions: 10.0.0.Final > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > These sections in the Configuration Guide need to be updated and improved. > Internal review draft is at: http://file.rdu.redhat.com/dnaro/10x-review/ISPN-10839/titles/configuring... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10839) Doc Productization: Configuring Caches Declaratively and Programmatically

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-10839?page=com.atlassian.jira.plugi... ] Donald Naro updated ISPN-10839: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7774 > Doc Productization: Configuring Caches Declaratively and Programmatically > ------------------------------------------------------------------------- > > Key: ISPN-10839 > URL: https://issues.redhat.com/browse/ISPN-10839 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Affects Versions: 10.0.0.Final > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > These sections in the Configuration Guide need to be updated and improved. > Internal review draft is at: http://file.rdu.redhat.com/dnaro/10x-review/ISPN-10839/titles/configuring... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7191) CacheManager.removeCache leaks

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-7191?page=com.atlassian.jira.plugin... ] Dan Berindei commented on ISPN-7191: ------------------------------------ The description doesn't say exactly which objects are leaked, but the reproducer goes into more detail: 1. The cache JMX bean is not removed 2. {{NumericVersionGenerator}} registers a view change listener and doesn't remove it. The cache JMX leak has been fixed, but the NumericVersionGenerator leak is still present. We have also added one new leak: {{InternalCacheFactory.bootstrap()}} registers a {{TranscoderMarshallerAdapter}} in the global {{EncoderRegistry}}, and never removes it. > CacheManager.removeCache leaks > ------------------------------ > > Key: ISPN-7191 > URL: https://issues.redhat.com/browse/ISPN-7191 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.4.Final, 10.1.1.Final > Reporter: Ryan Gustafson > Assignee: Dan Berindei > Priority: Major > Attachments: TransientInfinispanCacheTest.java > > > Tests to try to use Infinispan caches for a large number of anonymous transient caches eventually runs out of memory. 3 different kinds of leaks were identified. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7191) CacheManager.removeCache leaks

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-7191?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-7191: ------------------------------- Affects Version/s: 10.1.1.Final > CacheManager.removeCache leaks > ------------------------------ > > Key: ISPN-7191 > URL: https://issues.redhat.com/browse/ISPN-7191 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.4.Final, 10.1.1.Final > Reporter: Ryan Gustafson > Assignee: Dan Berindei > Priority: Major > Attachments: TransientInfinispanCacheTest.java > > > Tests to try to use Infinispan caches for a large number of anonymous transient caches eventually runs out of memory. 3 different kinds of leaks were identified. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7191) CacheManager.removeCache leaks

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-7191?page=com.atlassian.jira.plugin... ] Dan Berindei reassigned ISPN-7191: ---------------------------------- Assignee: Dan Berindei (was: Tristan Tarrant) > CacheManager.removeCache leaks > ------------------------------ > > Key: ISPN-7191 > URL: https://issues.redhat.com/browse/ISPN-7191 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.4.Final, 10.1.1.Final > Reporter: Ryan Gustafson > Assignee: Dan Berindei > Priority: Major > Attachments: TransientInfinispanCacheTest.java > > > Tests to try to use Infinispan caches for a large number of anonymous transient caches eventually runs out of memory. 3 different kinds of leaks were identified. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11219) Docs: Capacity Factor = 0 for site masters

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-11219?page=com.atlassian.jira.plugi... ] Donald Naro updated ISPN-11219: ------------------------------- Fix Version/s: (was: 9.4.18.Final) Sprint: DataGrid Sprint #39 > Docs: Capacity Factor = 0 for site masters > ------------------------------------------ > > Key: ISPN-11219 > URL: https://issues.redhat.com/browse/ISPN-11219 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > Add changes from https://github.com/infinispan/infinispan/pull/7766 into 10.1 and master. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11219) Docs: Capacity Factor = 0 for site masters

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-11219?page=com.atlassian.jira.plugi... ] Donald Naro updated ISPN-11219: ------------------------------- Git Pull Request: (was: https://github.com/infinispan/infinispan/pull/7766) > Docs: Capacity Factor = 0 for site masters > ------------------------------------------ > > Key: ISPN-11219 > URL: https://issues.redhat.com/browse/ISPN-11219 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > Add changes from https://github.com/infinispan/infinispan/pull/7766 into 10.1 and master. -- 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