March 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10081) Fetch physical addresses of cluster members

by Tristan Tarrant (Jira)

Tristan Tarrant created ISPN-10081: -------------------------------------- Summary: Fetch physical addresses of cluster members Key: ISPN-10081 URL: https://issues.jboss.org/browse/ISPN-10081 Project: Infinispan Issue Type: Enhancement Components: JMX, reporting and management Affects Versions: 10.0.0.Beta3 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 10.0.0.Beta4 It is possible to retrieve the physical address of the local node. It would be helpful to obtain the physical addresses of all members in the cluster. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10080) Test cache managers created in other threads cannot join the UDP cluster

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10080?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10080: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6794, https://github.com/infinispan/infinispan/pull/6795 > Test cache managers created in other threads cannot join the UDP cluster > ------------------------------------------------------------------------ > > Key: ISPN-10080 > URL: https://issues.jboss.org/browse/ISPN-10080 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 10.0.0.Beta3, 9.4.11.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.12.Final > > > When a test wants to create a cache manager in another thread (e.g. with {{fork()}}) it should be able to call {{TestResourceTracker.testThreadStarted(this)}} and join the same cluster. > That works with TCP, but with UDP each thread gets its own multicast address and port, so multicast messages from one node don't reach the other. Unicast messages and {{TEST_PING}} do work. > This is the issue that made {{FunctionalTxTest}} fail in https://github.com/infinispan/infinispan/pull/6442 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10080) Test cache managers created in other threads cannot join the UDP cluster

by Dan Berindei (Jira)

Dan Berindei created ISPN-10080: ----------------------------------- Summary: Test cache managers created in other threads cannot join the UDP cluster Key: ISPN-10080 URL: https://issues.jboss.org/browse/ISPN-10080 Project: Infinispan Issue Type: Bug Components: Test Suite - Core Affects Versions: 9.4.11.Final, 10.0.0.Beta3 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 10.0.0.Beta4, 9.4.12.Final When a test wants to create a cache manager in another thread (e.g. with {{fork()}}) it should be able to call {{TestResourceTracker.testThreadStarted(this)}} and join the same cluster. That works with TCP, but with UDP each thread gets its own multicast address and port, so multicast messages from one node don't reach the other. Unicast messages and {{TEST_PING}} do work. This is the issue that made {{FunctionalTxTest}} fail in https://github.com/infinispan/infinispan/pull/6442 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10080) Test cache managers created in other threads cannot join the UDP cluster

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10080?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10080: -------------------------------- Status: Open (was: New) > Test cache managers created in other threads cannot join the UDP cluster > ------------------------------------------------------------------------ > > Key: ISPN-10080 > URL: https://issues.jboss.org/browse/ISPN-10080 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 10.0.0.Beta3, 9.4.11.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.12.Final > > > When a test wants to create a cache manager in another thread (e.g. with {{fork()}}) it should be able to call {{TestResourceTracker.testThreadStarted(this)}} and join the same cluster. > That works with TCP, but with UDP each thread gets its own multicast address and port, so multicast messages from one node don't reach the other. Unicast messages and {{TEST_PING}} do work. > This is the issue that made {{FunctionalTxTest}} fail in https://github.com/infinispan/infinispan/pull/6442 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 1 month

1
0
0 / 0

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

by William Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10073?page=com.atlassian.jira.plugin... ] William Burns commented on ISPN-10073: -------------------------------------- [~jbtrystram]I am not sure how we want to fix this yet, but you should be able to workaround this easily by making sure you don't perform blocking operations inside the callback from the CompletableFuture or by transferring execution over to a different thread. > 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, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2575) Key Transformer registration is required on all nodes of the cluster, in case of custom keys

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-2575?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2575: ---------------------------------- Fix Version/s: 10.0.0.Beta4 (was: 10.0.0.Beta3) > Key Transformer registration is required on all nodes of the cluster, in case of custom keys > -------------------------------------------------------------------------------------------- > > Key: ISPN-2575 > URL: https://issues.jboss.org/browse/ISPN-2575 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 5.2.0.Beta5 > Reporter: Anna Manukyan > Assignee: Adrian Nistor > Priority: Minor > Fix For: 10.0.0.Beta4 > > Attachments: ClusteredCacheTest.java > > > The case is the following: > I have a clustered cache on which I want to perform a search. I'm doing the following: > I'm initializing SearchManager on node1, I'm registering a custom key transformer for my key using the created searchmanager, but then when I'm trying to put data into the cache on node1 (which is in REPL_SYNC mode with cache on node2), I'm getting the exception: > java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.query.test.CustomKey3. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer > When I'm initializing the SearchManager using node2 cache and register the keyTransformer on it as well, then everything works perfectly, even though I am not using the second created SearchManager. > The test which reproduces the issue is attached to the jira. Please see the test case: testSearchKeyTransformer() -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10070) DefaultCacheManager should stop components after start failure

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10070?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10070: ----------------------------------- Fix Version/s: 10.0.0.Beta4 (was: 10.0.0.Beta3) > DefaultCacheManager should stop components after start failure > -------------------------------------------------------------- > > Key: ISPN-10070 > URL: https://issues.jboss.org/browse/ISPN-10070 > 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.Beta4, 9.4.12.Final > > > Currently it is impossible to release all the resources allocated during startup if the {{DefaultCacheManager}} instance was created with {{start=true}}. The user has to do something like this: > {code:java} > DefaultCacheManager manager = new DefaultCacheManager(..., false); > try { > manager.start(); > } catch (Throwable t) { > manager.stop(); > throw t; > } > {code} > Both the constructor and the public {{start()}} method should clean up the started components after a startup failure, so that the user doesn't have to call {{stop()}} explicitly. > Our tests do not currently call {{stop()}} explicitly, so they leak threads and sockets when a manager fails to start (e.g. because something went wrong with the {{CONFIG}} cache). -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10062) Docs refer to infinispan-cli-server instead of infinispan-cli-interpreter

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10062?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10062: ----------------------------------- Fix Version/s: 10.0.0.Beta4 (was: 10.0.0.Beta3) > Docs refer to infinispan-cli-server instead of infinispan-cli-interpreter > ------------------------------------------------------------------------- > > Key: ISPN-10062 > URL: https://issues.jboss.org/browse/ISPN-10062 > Project: Infinispan > Issue Type: Bug > Components: Documentation-Core > Affects Versions: 10.0.0.Beta2, 9.4.10.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.12.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10041) Locking interceptor should check the topology before acquiring locks

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10041?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10041: ----------------------------------- Fix Version/s: 10.0.0.Beta4 (was: 10.0.0.Beta3) > Locking interceptor should check the topology before acquiring locks > -------------------------------------------------------------------- > > Key: ISPN-10041 > URL: https://issues.jboss.org/browse/ISPN-10041 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.11.Final, 9.3.6.Final, 10.0.0.Beta2, 9.4.9.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta4 > > > The distribution interceptors check the command topology is the same as the current topology before sending a command to remote nodes, but the locking interceptors do not have any check. > On a remote node, this means the inbound invocation handler acquires some locks in topology {{T}}, then the locking interceptor acquires other locks in topology {{T+1}}, and finally the distribution interceptor throws {{OutdatedTopologyException}} and releases the locks. In older versions there is also a potential for blocking a remote executor thread while waiting for the lock, but luckily that is not a problem in 9.4+. It would be more efficient if the locking interceptor was throwing {{OutdatedTopologyException}} instead. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 1 month

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10040?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10040: ----------------------------------- Fix Version/s: 10.0.0.Beta4 (was: 10.0.0.Beta3) > 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.Beta4, 9.4.12.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, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2019