November 2018 - infinispan-issues

[JBoss JIRA] (ISPN-9728) Ickl query ignore an IN clause if there is only one value

by Wolf-Dieter Fink (Jira)

Wolf-Dieter Fink created ISPN-9728: -------------------------------------- Summary: Ickl query ignore an IN clause if there is only one value Key: ISPN-9728 URL: https://issues.jboss.org/browse/ISPN-9728 Project: Infinispan Issue Type: Bug Reporter: Wolf-Dieter Fink If an Ickl query has an IN clause in combination with another condition the IN clause seems completely ignored if it has only one value. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9727) Ickl query ignore an IN clause if there is only one value

by Wolf-Dieter Fink (Jira)

Wolf-Dieter Fink created ISPN-9727: -------------------------------------- Summary: Ickl query ignore an IN clause if there is only one value Key: ISPN-9727 URL: https://issues.jboss.org/browse/ISPN-9727 Project: Infinispan Issue Type: Bug Reporter: Wolf-Dieter Fink If an Ickl query has an IN clause in combination with another condition the IN clause seems completely ignored if it has only one value. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9647) Docs: Include details on default analyzers

by Don Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-9647?page=com.atlassian.jira.plugin.... ] Don Naro updated ISPN-9647: --------------------------- Fix Version/s: 10.0.0.Alpha1 9.4.2.Final > Docs: Include details on default analyzers > ------------------------------------------ > > Key: ISPN-9647 > URL: https://issues.jboss.org/browse/ISPN-9647 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core, Documentation-Query > Affects Versions: 9.4.0.Final > Reporter: Don Naro > Assignee: Don Naro > Priority: Major > Fix For: 10.0.0.Alpha1, 9.4.2.Final > > > ISPN-9429 is included in DG 7.3. Need to document the default analyzers. Merge details from 7.2.3 into 7.3 User Guide. > https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.2... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[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)

7 years, 5 months

1
0
0 / 0

[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)

7 years, 5 months

1
0
0 / 0

[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)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9710) Upgrade Surefire 3.0.0-M1

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9710?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9710: ---------------------------------- Fix Version/s: 9.4.2.Final > Upgrade Surefire 3.0.0-M1 > ------------------------- > > Key: ISPN-9710 > URL: https://issues.jboss.org/browse/ISPN-9710 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build > Affects Versions: 9.4.1.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.Alpha1, 9.4.2.Final > > > Fixes https://issues.apache.org/jira/browse/SUREFIRE-1588 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[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: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/6351 > 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)

7 years, 5 months

1
0
0 / 0

[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)

7 years, 5 months

1
0
0 / 0

[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)

7 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2018