June 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10271) JMX URL Needs Change for Productization

by Donald Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10271?page=com.atlassian.jira.plugin... ] Donald Naro closed ISPN-10271. ------------------------------ > JMX URL Needs Change for Productization > --------------------------------------- > > Key: ISPN-10271 > URL: https://issues.jboss.org/browse/ISPN-10271 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Servers > Affects Versions: 9.4.6.Final > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.15.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9614) Convert listeners to work with async interceptor stack

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-9614?page=com.atlassian.jira.plugin.... ] Will Burns updated ISPN-9614: ----------------------------- Status: Open (was: New) > Convert listeners to work with async interceptor stack > ------------------------------------------------------ > > Key: ISPN-9614 > URL: https://issues.jboss.org/browse/ISPN-9614 > Project: Infinispan > Issue Type: Enhancement > Components: Listeners > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 10.0.0.Final > > > Currently a sync listener will block the thread that is notifying it. It should return a _CompletableFuture_ to integrate properly with the async stack to be notified upon completion. > Also we should not invoke "alien" listeners on the same thread as they could block. We should allow listener to make itself async in some manner (ie. return type is CompletableFuture<Void>). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9614) Convert listeners to work with async interceptor stack

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-9614?page=com.atlassian.jira.plugin.... ] Will Burns resolved ISPN-9614. ------------------------------ Resolution: Done > Convert listeners to work with async interceptor stack > ------------------------------------------------------ > > Key: ISPN-9614 > URL: https://issues.jboss.org/browse/ISPN-9614 > Project: Infinispan > Issue Type: Enhancement > Components: Listeners > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 10.0.0.Final > > > Currently a sync listener will block the thread that is notifying it. It should return a _CompletableFuture_ to integrate properly with the async stack to be notified upon completion. > Also we should not invoke "alien" listeners on the same thread as they could block. We should allow listener to make itself async in some manner (ie. return type is CompletableFuture<Void>). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9729) Continuous Query needs to be converted to non blocking

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-9729?page=com.atlassian.jira.plugin.... ] Will Burns updated ISPN-9729: ----------------------------- Parent: (was: ISPN-9614) Issue Type: Enhancement (was: Sub-task) > Continuous Query needs to be converted to non blocking > ------------------------------------------------------ > > Key: ISPN-9729 > URL: https://issues.jboss.org/browse/ISPN-9729 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Listeners > Affects Versions: 9.4.1.Final > Reporter: Will Burns > Priority: Major > Fix For: 10.0.0.Final > > > The object filter which powers embedded continuous query interfaces currently are not conducive to non blocking operations. Listeners will now support non blocking in ISPN-9714. > Changing the API will allow us to not block the calling thread (such as hotrod worker, user, remote and others). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10313) EvictInvalidatedNearCacheTest.testEvictAfterReachingMax random failures

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10313?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10313: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > EvictInvalidatedNearCacheTest.testEvictAfterReachingMax random failures > ----------------------------------------------------------------------- > > Key: ISPN-10313 > URL: https://issues.jboss.org/browse/ISPN-10313 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 10.0.0.Beta3 > Reporter: Dan Berindei > Assignee: Will Burns > Priority: Major > Labels: testsuite_stability > Fix For: 10.0.0.Beta4 > > Attachments: ISPN-9599_globalcomponentregistry_permission_20190616-2133_EvictInvalidatedNearCacheTest-infinispan-client-hotrod.log.gz > > > From the log, it looks like the near cache may ignore put requests, and {{EvictInvalidatedNearCacheTest}} doesn't expect that: > {noformat} > 22:02:29,709 TRACE (testng-Test:[]) [RetryOnFailureOperation] About to start executing operation GetWithMetadataOperation{(default), key=[B0x034B00000002, flags=0} on [id: 0x2ca8c2fb, L:/127.0.0.1:40582 - R:127.0.0.1/127.0.0.1:33741] > 22:02:29,709 TRACE (testng-Test:[]) [Codec] [] Wrote header for messageId=5085 to PooledUnsafeDirectByteBuf(ridx: 0, widx: 13, cap: 21). Operation code: 0x1b(UNKNOWN). Flags: 0x0. Topology id: -1 > 22:02:29,710 TRACE (Test-Client-Async-108-1:[]) [HeaderDecoder] Response 5085 belongs to GetWithMetadataOperation{(default), key=[B0x034B00000002, flags=0} on [id: 0x2ca8c2fb, L:/127.0.0.1:40582 - R:127.0.0.1/127.0.0.1:33741] > 22:02:29,710 TRACE (Test-Client-Async-108-1:[]) [NearCacheService] Conditionally put key=2 and value=MetadataValueImpl [created=-1, lifespan=-1, lastUsed=-1, maxIdle=-1, getVersion()=2, getValue()=v1] if absent in near cache (listenerId=[B0xD532F51E0F6632E1..[16]) > 22:02:29,725 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.client.hotrod.near.EvictInvalidatedNearCacheTest.testEvictAfterReachingMax > java.lang.AssertionError: expected:<v1> but was:<null> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.14.3.jar:?] > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.14.3.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.14.3.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88) ~[testng-6.14.3.jar:?] > at org.infinispan.client.hotrod.near.AssertsNearCache.assertGetKeyValue(AssertsNearCache.java:235) ~[test-classes/:?] > at org.infinispan.client.hotrod.near.AssertsNearCache.expectNearGetValue(AssertsNearCache.java:130) ~[test-classes/:?] > at org.infinispan.client.hotrod.near.EvictInvalidatedNearCacheTest.testEvictAfterReachingMax(EvictInvalidatedNearCacheTest.java:39) ~[test-classes/:?] > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10322) Create unified interface for initializing commands

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10322?page=com.atlassian.jira.plugin... ] Ryan Emerson commented on ISPN-10322: ------------------------------------- Initial RP merged, but we should take this approach further as detailed [here|https://github.com/infinispan/infinispan/pull/6834#issuecomment-5043...]. > Create unified interface for initializing commands > -------------------------------------------------- > > Key: ISPN-10322 > URL: https://issues.jboss.org/browse/ISPN-10322 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 10.0.0.Beta3 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta4 > > > Currently we rely on CommandsFactoryImpl and ModuleCommandInitializer implementations to initiatilize commands once they have been received over the wire. However, currently we do this on a per method basis, resulting in commands having various initialisation naming schemes such as {{init}}, {{inject}} etc. We should provide a interface that can be implemented by commands that require initialization and utilise this method for all initialization. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10339) Investigate and Rework Multiple Cache Loaders Support

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10339?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10339: ------------------------------ Fix Version/s: 10.0.0.Final > Investigate and Rework Multiple Cache Loaders Support > ----------------------------------------------------- > > Key: ISPN-10339 > URL: https://issues.jboss.org/browse/ISPN-10339 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Will Burns > Priority: Major > Fix For: 10.0.0.Final > > > Today having more than one loader configured is possible. However the way it operates is not well defined or even documented. > Currently for single key operations we try each loader one by one until one returns non null. For writes we write to all stores. However for bulk operations we only load from the first AdvancedLoader. This can be a bit confusing how these are done, but makes sense at least when thought about. > The other concern that is new is now that we have segmented loaders that perform better under bulk operations that their non segmented counterparts. ISPN-9816 makes it better, however its checking is not the most foolproof. We may want to instead explicitly find per invocation if the current loader is segmented or not before invoking the appropriate method. Currently we only check at startup if any loader is segmented; however this can be problematic if the first loader is not segmented and not advanced or handle the case of a loader being removed at runtime. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10339) Investigate and Rework Multiple Cache Loaders Support

by Will Burns (Jira)

Will Burns created ISPN-10339: --------------------------------- Summary: Investigate and Rework Multiple Cache Loaders Support Key: ISPN-10339 URL: https://issues.jboss.org/browse/ISPN-10339 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Reporter: Will Burns Today having more than one loader configured is possible. However the way it operates is not well defined or even documented. Currently for single key operations we try each loader one by one until one returns non null. For writes we write to all stores. However for bulk operations we only load from the first AdvancedLoader. This can be a bit confusing how these are done, but makes sense at least when thought about. The other concern that is new is now that we have segmented loaders that perform better under bulk operations that their non segmented counterparts. ISPN-9816 makes it better, however its checking is not the most foolproof. We may want to instead explicitly find per invocation if the current loader is segmented or not before invoking the appropriate method. Currently we only check at startup if any loader is segmented; however this can be problematic if the first loader is not segmented and not advanced or handle the case of a loader being removed at runtime. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10329) Remote listener comments

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10329?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10329: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/7075 > Remote listener comments > ------------------------ > > Key: ISPN-10329 > URL: https://issues.jboss.org/browse/ISPN-10329 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 10.0.0.Beta4 > > > We should cover fixing the comments from https://github.com/infinispan/infinispan/pull/6995 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10329) Remote listener comments

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10329?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10329: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.0.0.Beta4 (was: 10.0.0.Final) Resolution: Done > Remote listener comments > ------------------------ > > Key: ISPN-10329 > URL: https://issues.jboss.org/browse/ISPN-10329 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 10.0.0.Beta4 > > > We should cover fixing the comments from https://github.com/infinispan/infinispan/pull/6995 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 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 June 2019