[JBoss JIRA] (ISPN-9852) Invocations waiting for a new topology should resume in parallel
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9852?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9852:
----------------------------------
Fix Version/s: 9.4.13.Final
(was: 9.4.12.Final)
> Invocations waiting for a new topology should resume in parallel
> ----------------------------------------------------------------
>
> Key: ISPN-9852
> URL: https://issues.jboss.org/browse/ISPN-9852
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.11.Final, 10.0.0.Alpha2, 9.4.5.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta4, 9.4.13.Final
>
>
> When a command requires a topology newer than the current topology, it uses {{StateTransferLock.transactionDataFuture()}} to wait for the newer topology. When the tx data is received for the newer topology, some (most?) of the waiting operations do not use a separate executor, instead they are all resumed on the thread that received the tx data. If some operations block (e.g. because of a store), it could take a very long time to finish all the blocked operations.
--
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: 9.4.13.Final
(was: 9.4.12.Final)
> 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.13.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-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: 9.4.13.Final
(was: 9.4.12.Final)
> 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.13.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-10086) AllClusterExecutorTest.testExecutorTriConsumerTimeoutException random failures
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10086?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10086:
-----------------------------------
Fix Version/s: 9.4.13.Final
(was: 9.4.12.Final)
> AllClusterExecutorTest.testExecutorTriConsumerTimeoutException random failures
> ------------------------------------------------------------------------------
>
> Key: ISPN-10086
> URL: https://issues.jboss.org/browse/ISPN-10086
> 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
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta4, 9.4.13.Final
>
>
> When running tests in parallel, the remote request may complete before the thread that sent the request resumes. Because the scheduled executor is mocked to return {{null}}, this leads to a {{NullPointerException}}:
> {noformat}
> 09:43:41,995 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.manager.AllClusterExecutorTest.testExecutorTriConsumerTimeoutException
> java.lang.NullPointerException: null
> at org.infinispan.remoting.transport.AbstractRequest.setTimeoutFuture(AbstractRequest.java:94) ~[classes/:?]
> at org.infinispan.remoting.transport.AbstractRequest.setTimeout(AbstractRequest.java:55) ~[classes/:?]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeCommand(JGroupsTransport.java:831) ~[classes/:?]
> at org.infinispan.manager.impl.AllClusterExecutor.submitConsumer(AllClusterExecutor.java:182) ~[classes/:?]
> at org.infinispan.manager.ClusterExecutor.submitConsumer(ClusterExecutor.java:116) ~[classes/:?]
> at org.infinispan.manager.Test$17.call(AllClusterExecutorTest.java:402) ~[test-classes/:?]
> at org.infinispan.test.TestingUtil.withCacheManagers(TestingUtil.java:1601) ~[test-classes/:?]
> at org.infinispan.manager.AllClusterExecutorTest.testExecutorTriConsumerTimeoutException(AllClusterExecutorTest.java:382) ~[test-classes/:?]
> {noformat}
> The problem may be that the test calls {{Mockito.verify()}} from the consumer twice, once for each node, instead of doing it only on the remote node.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (ISPN-10095) Shared stores should throw exception when cache is local
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10095?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10095:
-----------------------------------
Fix Version/s: 9.4.13.Final
(was: 9.4.12.Final)
> Shared stores should throw exception when cache is local
> --------------------------------------------------------
>
> Key: ISPN-10095
> URL: https://issues.jboss.org/browse/ISPN-10095
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Core
> Affects Versions: 10.0.0.Beta3, 9.4.11.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Beta4, 9.4.13.Final
>
>
> A shared store does not make sense with a local cache, therefore we should throw a {{CacheConfigurationException}} if configured. Due to assumptions elsewhere in the PersistenceManager, prior to this fix a NPE will be thrown during the Purge method of the store as {{transport == null}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (ISPN-10099) Some modules disable execution default-test but not java8-test
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10099?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10099:
-----------------------------------
Fix Version/s: 9.4.13.Final
(was: 9.4.12.Final)
> Some modules disable execution default-test but not java8-test
> --------------------------------------------------------------
>
> Key: ISPN-10099
> URL: https://issues.jboss.org/browse/ISPN-10099
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> 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.13.Final
>
>
> ISPN-9959 introduced executions {{java8-test}} and {{java10-test}}, but some modules (e.g. {{jcache/tck-runner}}) only disable the {{default-test}} execution when they want to skip Surefire completely.
> When profile {{java8-test}} is activated, Surefire tries to run the tests for those modules and fails:
> {noformat}
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test (java8-test) on project infinispan-jcache-tck-runner: Illegal parallel='tests' -> [Help 1]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months