February 2020 - infinispan-issues

[JBoss JIRA] (ISPN-11209) Max Idle changes caused a REPL read performance regression

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11209?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11209: ------------------------------ Status: Open (was: New) > Max Idle changes caused a REPL read performance regression > ---------------------------------------------------------- > > Key: ISPN-11209 > URL: https://issues.redhat.com/browse/ISPN-11209 > Project: Infinispan > Issue Type: Bug > Reporter: Will Burns > Priority: Major > Fix For: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1 > > > The changes in ISPN-11020 inadverdently caused a slow down in read performance, which is unexpected. It should have been faster instead as it is no longer hitting the interceptor stack. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11209) Max Idle changes caused a REPL read performance regression

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11209?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11209: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7777 > Max Idle changes caused a REPL read performance regression > ---------------------------------------------------------- > > Key: ISPN-11209 > URL: https://issues.redhat.com/browse/ISPN-11209 > Project: Infinispan > Issue Type: Bug > Reporter: Will Burns > Priority: Major > Fix For: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1 > > > The changes in ISPN-11020 inadverdently caused a slow down in read performance, which is unexpected. It should have been faster instead as it is no longer hitting the interceptor stack. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11209) Max Idle changes caused a REPL read performance regression

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11209?page=com.atlassian.jira.plugi... ] Will Burns reassigned ISPN-11209: --------------------------------- Assignee: Will Burns > Max Idle changes caused a REPL read performance regression > ---------------------------------------------------------- > > Key: ISPN-11209 > URL: https://issues.redhat.com/browse/ISPN-11209 > Project: Infinispan > Issue Type: Bug > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1 > > > The changes in ISPN-11020 inadverdently caused a slow down in read performance, which is unexpected. It should have been faster instead as it is no longer hitting the interceptor stack. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11271) Convert async transport executor to the non blocking thread pool

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11271?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11271: ------------------------------ Status: Open (was: New) > Convert async transport executor to the non blocking thread pool > ---------------------------------------------------------------- > > Key: ISPN-11271 > URL: https://issues.redhat.com/browse/ISPN-11271 > Project: Infinispan > Issue Type: Sub-task > Reporter: Will Burns > Priority: Major > Fix For: 11.0.0.Alpha1 > > > The ASYNC_TRANSPORT_EXECUTOR should be consolidated with the async thread pool and make sure that operations performed on it are not blocking. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11271) Convert async transport executor to the non blocking thread pool

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11271?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11271: ------------------------------ Fix Version/s: 11.0.0.Alpha1 > Convert async transport executor to the non blocking thread pool > ---------------------------------------------------------------- > > Key: ISPN-11271 > URL: https://issues.redhat.com/browse/ISPN-11271 > Project: Infinispan > Issue Type: Sub-task > Reporter: Will Burns > Priority: Major > Fix For: 11.0.0.Alpha1 > > > The ASYNC_TRANSPORT_EXECUTOR should be consolidated with the async thread pool and make sure that operations performed on it are not blocking. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11271) Convert async transport executor to the non blocking thread pool

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11271?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11271: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7823 > Convert async transport executor to the non blocking thread pool > ---------------------------------------------------------------- > > Key: ISPN-11271 > URL: https://issues.redhat.com/browse/ISPN-11271 > Project: Infinispan > Issue Type: Sub-task > Reporter: Will Burns > Priority: Major > Fix For: 11.0.0.Alpha1 > > > The ASYNC_TRANSPORT_EXECUTOR should be consolidated with the async thread pool and make sure that operations performed on it are not blocking. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11277) Off Heap expiration with custom metadata doesn't work

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11277?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11277: ------------------------------ Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Off Heap expiration with custom metadata doesn't work > ----------------------------------------------------- > > Key: ISPN-11277 > URL: https://issues.redhat.com/browse/ISPN-11277 > Project: Infinispan > Issue Type: Bug > Components: Core, Off Heap > Reporter: Will Burns > Priority: Major > Fix For: 11.0.0.Beta1 > > > Off heap assumed when a custom metadata was used that it didn't have to track expiration. However this is incorrect, we need to make sure to track the expiration values (created and/or last used) so it can expire properly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11204) Response Collector addResponse value can be ignored

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11204?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11204: ------------------------------ Description: A ResponseCollector can return a non null value from `addResponse` that is a sign that the response is complete. However it is possible to get a non null value from one response and get another response that has null and the `finish` value is used instead. We should make sure that when a non null value is returned via `addResponse` that its value is always used. (was: A ResponseCollector can return a non value from `addResponse` that is a sign that the response is complete. However it is possible to get a non null value from one response and get another response that has null and the `finish` value is used instead. We should make sure that when a non null value is returned via `addResponse` that its value is always used.) > Response Collector addResponse value can be ignored > --------------------------------------------------- > > Key: ISPN-11204 > URL: https://issues.redhat.com/browse/ISPN-11204 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Alpha1 > > > A ResponseCollector can return a non null value from `addResponse` that is a sign that the response is complete. However it is possible to get a non null value from one response and get another response that has null and the `finish` value is used instead. We should make sure that when a non null value is returned via `addResponse` that its value is always used. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11204) Response Collector addResponse value can be ignored

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11204?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11204: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Response Collector addResponse value can be ignored > --------------------------------------------------- > > Key: ISPN-11204 > URL: https://issues.redhat.com/browse/ISPN-11204 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Alpha1 > > > A ResponseCollector can return a non value from `addResponse` that is a sign that the response is complete. However it is possible to get a non null value from one response and get another response that has null and the `finish` value is used instead. We should make sure that when a non null value is returned via `addResponse` that its value is always used. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9082) Off Heap maxIdle expiration is not implemented

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-9082?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-9082: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Off Heap maxIdle expiration is not implemented > ---------------------------------------------- > > Key: ISPN-9082 > URL: https://issues.redhat.com/browse/ISPN-9082 > Project: Infinispan > Issue Type: Bug > Components: Expiration, Off Heap > Affects Versions: 9.2.1.Final > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Alpha1 > > > Due to the usage of read/write locks Off Heap cannot easily update the last access time of an off heap entry. It would have to release the read lock and try to acquire the write lock to then finally update the last access time of an object. We would also have to guarantee the address pointer hadn't changed between when the read and write lock were obtained, since the value could have changed during that time period. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 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 February 2020