[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, 9 months
[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, 9 months
[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, 9 months
[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, 9 months
[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, 9 months
[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, 9 months
[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, 9 months