March 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10040) Embedded and server thread pool defaults should be the same

by William Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10040?page=com.atlassian.jira.plugin... ] William Burns updated ISPN-10040: --------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/6788, https://github.com/infinispan/infinispan/pull/6789 (was: https://github.com/infinispan/infinispan/pull/6788) > Embedded and server thread pool defaults should be the same > ----------------------------------------------------------- > > Key: ISPN-10040 > URL: https://issues.jboss.org/browse/ISPN-10040 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 8.2.11.Final, 10.0.0.Beta2, 9.4.9.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta3, 9.4.11.Final > > > Embedded: > {code:java} > DEFAULT_THREAD_COUNT.put(REMOTE_COMMAND_EXECUTOR, 200); > DEFAULT_QUEUE_SIZE.put(REMOTE_COMMAND_EXECUTOR, 0); > {code} > Server: > {code:java} > REMOTE_COMMAND("remote-command", 25, 25, 100000, 60000), > {code} > Using a huge queue is not ok for the remote thread pool, but I missed it before because I assumed the server was using the {{KnownComponentNames}} defaults. We should unify the thread pool defaults in another class with a more topical name and remove {{KnownComponentNames}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10040) Embedded and server thread pool defaults should be the same

by William Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10040?page=com.atlassian.jira.plugin... ] William Burns updated ISPN-10040: --------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6788 > Embedded and server thread pool defaults should be the same > ----------------------------------------------------------- > > Key: ISPN-10040 > URL: https://issues.jboss.org/browse/ISPN-10040 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 8.2.11.Final, 10.0.0.Beta2, 9.4.9.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta3, 9.4.11.Final > > > Embedded: > {code:java} > DEFAULT_THREAD_COUNT.put(REMOTE_COMMAND_EXECUTOR, 200); > DEFAULT_QUEUE_SIZE.put(REMOTE_COMMAND_EXECUTOR, 0); > {code} > Server: > {code:java} > REMOTE_COMMAND("remote-command", 25, 25, 100000, 60000), > {code} > Using a huge queue is not ok for the remote thread pool, but I missed it before because I assumed the server was using the {{KnownComponentNames}} defaults. We should unify the thread pool defaults in another class with a more topical name and remove {{KnownComponentNames}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10059) Clustered cache cannot start with off-heap and segmentation disabled

by William Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10059?page=com.atlassian.jira.plugin... ] William Burns updated ISPN-10059: --------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Clustered cache cannot start with off-heap and segmentation disabled > -------------------------------------------------------------------- > > Key: ISPN-10059 > URL: https://issues.jboss.org/browse/ISPN-10059 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.0.0.Beta2, 9.4.10.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 10.0.0.Beta3, 9.4.11.Final > > > With segmentation disabled and exception eviction is enabled, {{DataContainerFactory}} creates an instance of {{OffHeapDataContainer}}. Because the cache is clustered and {{OffHeapDataContainer}} implements {{InternalDataContainer}}, {{addSegments()}} will be invoked during startup and will throw {{UnsupportedOperationException}}. > {{LocalTopologyManagerImpl}} sees this as a join problem and retries every 100ms until the state transfer timeout expires (4 minutes by default). However, {{ExceptionEvictionTest}} seems to retry forever when running the full test suite, preventing the generation of any test reports. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10074) DefaultSegmentedDataContainer executeTask() and iterator() include expired entries

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10074?page=com.atlassian.jira.plugin... ] Dan Berindei commented on ISPN-10074: ------------------------------------- Will clarified that this is expected behaviour: because we don't want entries to disappear in one cache iteration and reappear in a later iteration, entries which should be expired according to maxidle are returned until a read operation or the purge worker thread removes them. However, this is only implemented in the segmented data container implementations. We need to modify the non-segmented implementations to also ignore entries expired only because of maxidle. > DefaultSegmentedDataContainer executeTask() and iterator() include expired entries > ---------------------------------------------------------------------------------- > > Key: ISPN-10074 > URL: https://issues.jboss.org/browse/ISPN-10074 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.0.0.Beta2, 9.4.10.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta3, 9.4.11.Final > > > The {{executeTask()}} javadoc doesn't mention expired entries, but {{iterator()}}'s says they shouldn't be included, and non-segmented containers do not include them. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9748) Default transport for the test suite should be same except if it was activated by another profile

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9748?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-9748: ---------------------------------- Assignee: Diego Lovison > Default transport for the test suite should be same except if it was activated by another profile > ------------------------------------------------------------------------------------------------- > > Key: ISPN-9748 > URL: https://issues.jboss.org/browse/ISPN-9748 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.4.1.Final > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > Fix For: 10.0.0.Beta3 > > > The pom.xml configuration should be: > {code:xml} > <default.transport.stack>udp</default.transport.stack> > <infinispan.test.jgroups.protocol>${default.transport.stack}</infinispan.test.jgroups.protocol> > <transport.stack>-Djboss.default.jgroups.stack=${infinispan.test.jgroups.protocol}</transport.stack> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9748) Default transport for the test suite should be same except if it was activated by another profile

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9748?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9748: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.0.0.Beta3 Resolution: Done > Default transport for the test suite should be same except if it was activated by another profile > ------------------------------------------------------------------------------------------------- > > Key: ISPN-9748 > URL: https://issues.jboss.org/browse/ISPN-9748 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.4.1.Final > Reporter: Diego Lovison > Priority: Major > Fix For: 10.0.0.Beta3 > > > The pom.xml configuration should be: > {code:xml} > <default.transport.stack>udp</default.transport.stack> > <infinispan.test.jgroups.protocol>${default.transport.stack}</infinispan.test.jgroups.protocol> > <transport.stack>-Djboss.default.jgroups.stack=${infinispan.test.jgroups.protocol}</transport.stack> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10074) DefaultSegmentedDataContainer executeTask() and iterator() include expired entries

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10074?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10074: -------------------------------- Status: Open (was: New) > DefaultSegmentedDataContainer executeTask() and iterator() include expired entries > ---------------------------------------------------------------------------------- > > Key: ISPN-10074 > URL: https://issues.jboss.org/browse/ISPN-10074 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.0.0.Beta2, 9.4.10.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta3, 9.4.11.Final > > > The {{executeTask()}} javadoc doesn't mention expired entries, but {{iterator()}}'s says they shouldn't be included, and non-segmented containers do not include them. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10074) DefaultSegmentedDataContainer executeTask() and iterator() include expired entries

by Dan Berindei (Jira)

Dan Berindei created ISPN-10074: ----------------------------------- Summary: DefaultSegmentedDataContainer executeTask() and iterator() include expired entries Key: ISPN-10074 URL: https://issues.jboss.org/browse/ISPN-10074 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.4.10.Final, 10.0.0.Beta2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 10.0.0.Beta3, 9.4.11.Final The {{executeTask()}} javadoc doesn't mention expired entries, but {{iterator()}}'s says they shouldn't be included, and non-segmented containers do not include them. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10073) Nested async operations with HotRod client hang

by Jean-Baptiste Trystram (Jira)

[ https://issues.jboss.org/browse/ISPN-10073?page=com.atlassian.jira.plugin... ] Jean-Baptiste Trystram commented on ISPN-10073: ----------------------------------------------- I also tried with {code:java} cache.withFlags(Flag.FORCE_RETURN_VALUE).putIfAbsentAsync {code} and the issue persists > Nested async operations with HotRod client hang > ----------------------------------------------- > > Key: ISPN-10073 > URL: https://issues.jboss.org/browse/ISPN-10073 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Affects Versions: 9.4.10.Final > Reporter: Dejan Bosanac > Assignee: William Burns > Priority: Major > > We noticed some issued with the HotRod client, when trying to use nested async calls. Originally, this was discovered in the context of Vert.x tests, but below you can find the smallest reproducer code that I could create (without any Vert.x dependencies). > {code:java} > //DefaultCacheManager cm = new DefaultCacheManager(); > //Cache<String, String> cache = cm.createCache("default", new ConfigurationBuilder().build()); > RemoteCacheManager cm = new RemoteCacheManager(); > RemoteCache<String, String> cache = cm.getCache("default"); > final CompletableFuture put = new CompletableFuture(); > cache.putIfAbsentAsync("A", "A").thenAccept(resultA -> { > final CompletableFuture nested = new CompletableFuture(); > cache.putIfAbsentAsync("B", "B").thenAccept(resultB -> { > nested.complete("B"); > }); > try { > nested.get(); > } catch (Exception e) { > e.printStackTrace(); > } > put.complete("B"); > }); > put.get(); > {code} > This would basically hang and the nested operation would never receive response. What I noticed in the original test is that response would become available after the framework timeout the test. > Everything works as expected with embedded cache. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10073) Nested async operations with HotRod client hang

by Jean-Baptiste Trystram (Jira)

[ https://issues.jboss.org/browse/ISPN-10073?page=com.atlassian.jira.plugin... ] Jean-Baptiste Trystram updated ISPN-10073: ------------------------------------------ Description: We noticed some issued with the HotRod client, when trying to use nested async calls. Originally, this was discovered in the context of Vert.x tests, but below you can find the smallest reproducer code that I could create (without any Vert.x dependencies). {code:java} //DefaultCacheManager cm = new DefaultCacheManager(); //Cache<String, String> cache = cm.createCache("default", new ConfigurationBuilder().build()); RemoteCacheManager cm = new RemoteCacheManager(); RemoteCache<String, String> cache = cm.getCache("default"); final CompletableFuture put = new CompletableFuture(); cache.putIfAbsentAsync("A", "A").thenAccept(resultA -> { final CompletableFuture nested = new CompletableFuture(); cache.putIfAbsentAsync("B", "B").thenAccept(resultB -> { nested.complete("B"); }); try { nested.get(); } catch (Exception e) { e.printStackTrace(); } put.complete("B"); }); put.get(); {code} This would basically hang and the nested operation would never receive response. What I noticed in the original test is that response would become available after the framework timeout the test. Everything works as expected with embedded cache. was: We noticed some issued with the HotRod client, when trying to use nested async calls. Originally, this was discovered in the context of Vert.x tests, but below you can find the smallest reproducer code that I could create (without any Vert.x dependencies). {code:java} //DefaultCacheManager cm = new DefaultCacheManager(); //Cache<String, String> cache = cm.createCache("default", new ConfigurationBuilder().build()); RemoteCacheManager cm = new RemoteCacheManager(); RemoteCache<String, String> cache = manager.getCache("default"); final CompletableFuture put = new CompletableFuture(); cache.putIfAbsentAsync("A", "A").thenAccept(resultA -> { final CompletableFuture nested = new CompletableFuture(); cache.putIfAbsentAsync("B", "B").thenAccept(resultB -> { nested.complete("B"); }); try { nested.get(); } catch (Exception e) { e.printStackTrace(); } put.complete("B"); }); put.get(); {code} This would basically hang and the nested operation would never receive response. What I noticed in the original test is that response would become available after the framework timeout the test. Everything works as expected with embedded cache. > Nested async operations with HotRod client hang > ----------------------------------------------- > > Key: ISPN-10073 > URL: https://issues.jboss.org/browse/ISPN-10073 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Affects Versions: 9.4.10.Final > Reporter: Dejan Bosanac > Assignee: William Burns > Priority: Major > > We noticed some issued with the HotRod client, when trying to use nested async calls. Originally, this was discovered in the context of Vert.x tests, but below you can find the smallest reproducer code that I could create (without any Vert.x dependencies). > {code:java} > //DefaultCacheManager cm = new DefaultCacheManager(); > //Cache<String, String> cache = cm.createCache("default", new ConfigurationBuilder().build()); > RemoteCacheManager cm = new RemoteCacheManager(); > RemoteCache<String, String> cache = cm.getCache("default"); > final CompletableFuture put = new CompletableFuture(); > cache.putIfAbsentAsync("A", "A").thenAccept(resultA -> { > final CompletableFuture nested = new CompletableFuture(); > cache.putIfAbsentAsync("B", "B").thenAccept(resultB -> { > nested.complete("B"); > }); > try { > nested.get(); > } catch (Exception e) { > e.printStackTrace(); > } > put.complete("B"); > }); > put.get(); > {code} > This would basically hang and the nested operation would never receive response. What I noticed in the original test is that response would become available after the framework timeout the test. > Everything works as expected with embedded cache. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2019