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