[JBoss JIRA] (ISPN-11510) Convert detection of blocking or non blocking threads
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-11510?page=com.atlassian.jira.plugi... ]
Will Burns updated ISPN-11510:
------------------------------
Status: Open (was: New)
> Convert detection of blocking or non blocking threads
> -----------------------------------------------------
>
> Key: ISPN-11510
> URL: https://issues.redhat.com/browse/ISPN-11510
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 11.0.0.Dev04
>
>
> Unfortunately detecting a blocking thread by name is very fragile as a user can change the name of the threads.
> Also a non blocking thread is detected by checking the implementation of the thread. This will not work for Java 15 with loom as we may not have a thread but rather a fiber.
> We should detect these instead by using a thread group which will work for both and be more explicit.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (ISPN-11510) Convert detection of blocking or non blocking threads
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-11510?page=com.atlassian.jira.plugi... ]
Will Burns updated ISPN-11510:
------------------------------
Fix Version/s: 11.0.0.Dev04
> Convert detection of blocking or non blocking threads
> -----------------------------------------------------
>
> Key: ISPN-11510
> URL: https://issues.redhat.com/browse/ISPN-11510
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 11.0.0.Dev04
>
>
> Unfortunately detecting a blocking thread by name is very fragile as a user can change the name of the threads.
> Also a non blocking thread is detected by checking the implementation of the thread. This will not work for Java 15 with loom as we may not have a thread but rather a fiber.
> We should detect these instead by using a thread group which will work for both and be more explicit.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (ISPN-11518) IndexingDuringStateTransferTest random failures
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-11518?page=com.atlassian.jira.plugi... ]
Will Burns updated ISPN-11518:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> IndexingDuringStateTransferTest random failures
> -----------------------------------------------
>
> Key: ISPN-11518
> URL: https://issues.redhat.com/browse/ISPN-11518
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Test Suite
> Affects Versions: 11.0.0.Dev03
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 11.0.0.Dev04
>
>
> {{IndexingDuringStateTransferTest.test}} blocks {{StateResponseCommand}} so that state transfer doesn't finish during the test. Since state transfer is now non-blocking, blocking the thread that's trying to send the {{StateResponseCommand}} also prevents it from sending the response to the {{StateTransferStartCommand}}.
> Because the {{StateTransferStartCommand}} is blocked, the requestor can't complete the transaction data future in {{StateTransferLockImpl}}, and the test can't proceed to unblock the {{StateResumeCommand}}.
> The {{RpcManager}} wrapper is supposed to send the command anyway, but it doesn't catch {{AssertionError}}, so the command isn't sent and the rebalance hangs.
> Eventually the put times out, and the next test also fails because it can't add a new manager:
> {noformat}
> java.lang.RuntimeException: java.util.concurrent.TimeoutException
> at org.infinispan.query.blackbox.IndexingDuringStateTransferTest.test(IndexingDuringStateTransferTest.java:189)
> at org.infinispan.query.blackbox.IndexingDuringStateTransferTest.testPut(IndexingDuringStateTransferTest.java:78)
> at org.infinispan.commons.test.TestNGLongTestsHook.run(TestNGLongTestsHook.java:24)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.util.concurrent.TimeoutException
> {noformat}
> {noformat}
> org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Initial state transfer timed out for cache defaultcache on IndexingDuringStateTransferTest-NodeF
> at org.infinispan.manager.DefaultCacheManager.internalStart(DefaultCacheManager.java:746)
> at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:712)
> at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:268)
> at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:232)
> at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:225)
> at org.infinispan.query.blackbox.IndexingDuringStateTransferTest.test(IndexingDuringStateTransferTest.java:144)
> at org.infinispan.query.blackbox.IndexingDuringStateTransferTest.testPutIgnoreReturnValue(IndexingDuringStateTransferTest.java:82)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (ISPN-11530) Only allow numOwners=1 and ALLOW_READ_WRITES strategy
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-11530?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated ISPN-11530:
--------------------------------
Summary: Only allow numOwners=1 and ALLOW_READ_WRITES strategy (was: Only allow numOwners=1 and ALLOW_READ_WRITES configuration)
> Only allow numOwners=1 and ALLOW_READ_WRITES strategy
> -----------------------------------------------------
>
> Key: ISPN-11530
> URL: https://issues.redhat.com/browse/ISPN-11530
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Core
> Affects Versions: 11.0.0.Dev03
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 11.0.0.Dev04
>
>
> DENY_READ_WRITES or ALLOW_READS results in the cluster becoming degraded in the event of a single node leaving the cluster, therefore we should throw an exception and explain that ALLOW_READ_WRITES should be used with numOwners=1.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (ISPN-11530) Only allow numOwners=1 and ALLOW_READ_WRITES configuration
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-11530?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated ISPN-11530:
--------------------------------
Summary: Only allow numOwners=1 and ALLOW_READ_WRITES configuration (was: Prevent numOwners=1 and DENY_READ_WRITES configuration)
> Only allow numOwners=1 and ALLOW_READ_WRITES configuration
> ----------------------------------------------------------
>
> Key: ISPN-11530
> URL: https://issues.redhat.com/browse/ISPN-11530
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Core
> Affects Versions: 11.0.0.Dev03
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 11.0.0.Dev04
>
>
> This configuration results in the cluster becoming degraded in the event of a single node leaving the cluster, therefore we should throw an exception and explain that ALLOW_READ_WRITES should be used with numOwners=1.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months