[JBoss JIRA] (ISPN-7889) BaseDistributionInterceptor.remoteGet may cause concurrency issues
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-7889?page=com.atlassian.jira.plugin.... ]
Work on ISPN-7889 started by Dan Berindei.
------------------------------------------
> BaseDistributionInterceptor.remoteGet may cause concurrency issues
> ------------------------------------------------------------------
>
> Key: ISPN-7889
> URL: https://issues.jboss.org/browse/ISPN-7889
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Alpha1
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Major
>
> {{BaseDistributionInterceptor.remoteGet}} or any call that accesses the context in an async future handler that is called multiple times in parallel may lead to concurrent modifications of the context.
> These calls are usually handled using {{CompletableFuture.allOf()}} or using a CF with counter, but if one of the calls results in exceptional completion of the composed future, the processing continues (e.g. with a retry). The other parallel operation handlers are not stopped, though.
> {{BaseDistributionInterceptor.remoteGet}} shouldn't be called in parallel because it does not even synchronize regular successful invocations.
> A problem like this caused failures in {{GetAllCommandStressTest}}, and the issue was addressed for {{GetAllCommand}} in ISPN-7884.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (ISPN-8616) DistAsyncFuncTest.testMergeFromNonOwner random failures
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-8616?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-8616:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.4.1.Final
Resolution: Done
> DistAsyncFuncTest.testMergeFromNonOwner random failures
> -------------------------------------------------------
>
> Key: ISPN-8616
> URL: https://issues.jboss.org/browse/ISPN-8616
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.2.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Alpha1, 9.4.1.Final
>
>
> {noformat}
> java.lang.AssertionError: Fail on owner cache DistAsyncFuncTest[DIST_ASYNC, tx=false]-NodeA-42474: dc.get(k1) returned null
> at org.infinispan.distribution.BaseDistFunctionalTest.assertOwnershipAndNonOwnership(BaseDistFunctionalTest.java:191)
> at org.infinispan.distribution.BaseDistFunctionalTest.assertOnAllCachesAndOwnership(BaseDistFunctionalTest.java:162)
> at org.infinispan.distribution.BaseDistFunctionalTest.initAndTest(BaseDistFunctionalTest.java:142)
> at org.infinispan.distribution.DistSyncFuncTest.testMergeFromNonOwner(DistSyncFuncTest.java:387)
> {noformat}
> The test method is new and the interceptors have changed, but it's probably the same problem with {{asyncWait}} signaled in ISPN-3741. I commented out the entire implementation of {{asyncWait}} in {{DistAsyncFuncTest}} and it still passed when run by itself, so we need a way to delay the commands and check that the test is not sensitive to such delays.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (ISPN-9667) DefaultCacheManager inconsistent status checks
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9667?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9667:
-------------------------------
Description:
{{DefaultCacheManager.getTransport()}} returns {{null}} when the manager is stopping, it should not.
To make things worse, {{DefaultCacheManager.getStatus()}} returns the status of the {{GlobalComponentRegistry}}, which is still {{RUNNING}} while caches are shutting down. That means {{DCM.getTransport()}} and {{DCM.getAddress()}} return {{null}} while the cache are stopping, and breaks distributed streams on caches that are still running.
was:
{{DefaultCacheManager.getTransport()}} returns {{null}} when the manager is stopping, it should not.
To make things worse, {{DefaultCacheManager.getStatus()}} returns the status of the {{GlobalComponentRegistry}}, which is still {{RUNNING}} while caches are shutting down.
> DefaultCacheManager inconsistent status checks
> ----------------------------------------------
>
> Key: ISPN-9667
> URL: https://issues.jboss.org/browse/ISPN-9667
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Alpha1, 9.4.2.Final
>
>
> {{DefaultCacheManager.getTransport()}} returns {{null}} when the manager is stopping, it should not.
> To make things worse, {{DefaultCacheManager.getStatus()}} returns the status of the {{GlobalComponentRegistry}}, which is still {{RUNNING}} while caches are shutting down. That means {{DCM.getTransport()}} and {{DCM.getAddress()}} return {{null}} while the cache are stopping, and breaks distributed streams on caches that are still running.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (ISPN-9615) Move command perform logic into CallInterceptor directly
by William Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-9615?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-9615:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Move command perform logic into CallInterceptor directly
> --------------------------------------------------------
>
> Key: ISPN-9615
> URL: https://issues.jboss.org/browse/ISPN-9615
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core
> Reporter: William Burns
> Assignee: William Burns
> Priority: Major
> Fix For: 10.0.0.Alpha1
>
>
> By having the command perform logic in the CallInterceptor, we can avoid additional allocations for every command as the dependencies are stored in the interceptor stack. This would include things such as CacheNotifier and others.
> This also provides us the ability to more easily utilize the async interceptor stack for the actual command invocations.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (ISPN-9615) Move command perform logic into CallInterceptor directly
by William Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-9615?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-9615:
--------------------------------
Fix Version/s: 10.0.0.Alpha1
> Move command perform logic into CallInterceptor directly
> --------------------------------------------------------
>
> Key: ISPN-9615
> URL: https://issues.jboss.org/browse/ISPN-9615
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core
> Reporter: William Burns
> Assignee: William Burns
> Priority: Major
> Fix For: 10.0.0.Alpha1
>
>
> By having the command perform logic in the CallInterceptor, we can avoid additional allocations for every command as the dependencies are stored in the interceptor stack. This would include things such as CacheNotifier and others.
> This also provides us the ability to more easily utilize the async interceptor stack for the actual command invocations.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (ISPN-9726) Document max clause property on boolean query
by Katia Aresti (Jira)
[ https://issues.jboss.org/browse/ISPN-9726?page=com.atlassian.jira.plugin.... ]
Katia Aresti updated ISPN-9726:
-------------------------------
Summary: Document max clause property on boolean query (was: Document the overriding mechanism of BooleanQuery.maxClauseCount)
> Document max clause property on boolean query
> ---------------------------------------------
>
> Key: ISPN-9726
> URL: https://issues.jboss.org/browse/ISPN-9726
> Project: Infinispan
> Issue Type: Task
> Components: Embedded Querying, Remote Querying
> Affects Versions: 10.0.0.Alpha1
> Reporter: Katia Aresti
> Assignee: Adrian Nistor
> Priority: Major
> Fix For: 10.0.0.Alpha1, 9.4.2.Final
>
>
> Document the ability to override org.apache.lucene.search.BooleanQuery.maxClauseCount using infinispan.query.lucene.max-boolean-clauses JVM system property.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (ISPN-9726) Document the overriding mechanism of BooleanQuery.maxClauseCount
by Adrian Nistor (Jira)
[ https://issues.jboss.org/browse/ISPN-9726?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-9726:
--------------------------------
Summary: Document the overriding mechanism of BooleanQuery.maxClauseCount (was: Document max bool property on query)
> Document the overriding mechanism of BooleanQuery.maxClauseCount
> ----------------------------------------------------------------
>
> Key: ISPN-9726
> URL: https://issues.jboss.org/browse/ISPN-9726
> Project: Infinispan
> Issue Type: Task
> Components: Embedded Querying, Remote Querying
> Affects Versions: 10.0.0.Alpha1
> Reporter: Katia Aresti
> Assignee: Adrian Nistor
> Priority: Major
> Fix For: 10.0.0.Alpha1, 9.4.2.Final
>
>
> Document the ability to override org.apache.lucene.search.BooleanQuery.maxClauseCount using infinispan.query.lucene.max-boolean-clauses JVM system property.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month