June 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10311) Remove all the blocking Transport methods

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10311?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10311: ------------------------------ Fix Version/s: 10.0.0.Final > Remove all the blocking Transport methods > ----------------------------------------- > > Key: ISPN-10311 > URL: https://issues.jboss.org/browse/ISPN-10311 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Will Burns > Priority: Major > Fix For: 10.0.0.Final > > > The Transport class has many blocking methods on it that have been deprecated. This class was never public as it doesn't have a package-info.java, thus we can remove these methods at will. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10311) Remove all the blocking Transport methods

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10311?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10311: ------------------------------ Status: Open (was: New) > Remove all the blocking Transport methods > ----------------------------------------- > > Key: ISPN-10311 > URL: https://issues.jboss.org/browse/ISPN-10311 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Will Burns > Priority: Major > Fix For: 10.0.0.Final > > > The Transport class has many blocking methods on it that have been deprecated. This class was never public as it doesn't have a package-info.java, thus we can remove these methods at will. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10311) Remove all the blocking Transport methods

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10311?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10311: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7048 > Remove all the blocking Transport methods > ----------------------------------------- > > Key: ISPN-10311 > URL: https://issues.jboss.org/browse/ISPN-10311 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Will Burns > Priority: Major > Fix For: 10.0.0.Final > > > The Transport class has many blocking methods on it that have been deprecated. This class was never public as it doesn't have a package-info.java, thus we can remove these methods at will. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10312) Evaluate locations that use CompletableFuture#join

by Will Burns (Jira)

Will Burns created ISPN-10312: --------------------------------- Summary: Evaluate locations that use CompletableFuture#join Key: ISPN-10312 URL: https://issues.jboss.org/browse/ISPN-10312 Project: Infinispan Issue Type: Sub-task Reporter: Will Burns Invoking join or get on a CompletableFuture is a code stink and should be evaluated if it can be refactored to something else. Quite possibly this JIRA may be to just create other JIRAs but any simple refactorings can be done here. Invocations to watch for {code}CompletionStages.join(){code}, {code}CompletableFuture.join(){code}, {code}CompletableFuture.get(){code}, {code}CompletableFuture.get(int, TimeUnit){code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9744) Cache creation should be non blocking

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-9744?page=com.atlassian.jira.plugin.... ] Will Burns updated ISPN-9744: ----------------------------- Parent: ISPN-10309 Issue Type: Sub-task (was: Enhancement) > Cache creation should be non blocking > ------------------------------------- > > Key: ISPN-9744 > URL: https://issues.jboss.org/browse/ISPN-9744 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > > Internally cache creation stores entries in a CompletableFuture. We however don't return a CompletionStage to the invoker of getCache. We should do this and utilize the same approach to async calls that {code}DefaultCacheManager#startCaches{code} does by starting a thread per cache. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10075) We should ensure that when CompletionStages are completed they are continued only on Infinispan threads

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10075?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10075: ------------------------------ Parent: ISPN-10309 Issue Type: Sub-task (was: Bug) > We should ensure that when CompletionStages are completed they are continued only on Infinispan threads > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-10075 > URL: https://issues.jboss.org/browse/ISPN-10075 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Will Burns > Priority: Major > Fix For: 10.0.0.Final > > > When a user can supply a CompletionStage to delay operations this can cause a possibility of that being completed on a different thread than expected. The new non blocking listeners will especially be affected by this (ISPN-9614). This is also problematic for CacheLoader SPI and any future API that takes a Publisher as an argument from the user. > This issue should at least fix the upcoming non blocking listeners as discussed at https://github.com/infinispan/infinispan/pull/6401#issuecomment-475181484. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10311) Remove all the blocking Transport methods

by Will Burns (Jira)

Will Burns created ISPN-10311: --------------------------------- Summary: Remove all the blocking Transport methods Key: ISPN-10311 URL: https://issues.jboss.org/browse/ISPN-10311 Project: Infinispan Issue Type: Sub-task Components: Core Reporter: Will Burns The Transport class has many blocking methods on it that have been deprecated. This class was never public as it doesn't have a package-info.java, thus we can remove these methods at will. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10310) State Transfer needs to be made non blocking

by Will Burns (Jira)

Will Burns created ISPN-10310: --------------------------------- Summary: State Transfer needs to be made non blocking Key: ISPN-10310 URL: https://issues.jboss.org/browse/ISPN-10310 Project: Infinispan Issue Type: Sub-task Components: Core, State Transfer Reporter: Will Burns Fix For: 10.0.0.Final State Transfer currently invokes many methods that are non blocking and blocks to wait for those to complete. We need to ensure that all the various usages are converted to be non blocking and when absolutely not possible convert them to using a separate thread pool. The final goal is to eventually eliminate the state transfer thread pool as well. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10309) Convert Remaining Parts to Non Blocking & Reduce Thread Pools

by Will Burns (Jira)

Will Burns created ISPN-10309: --------------------------------- Summary: Convert Remaining Parts to Non Blocking & Reduce Thread Pools Key: ISPN-10309 URL: https://issues.jboss.org/browse/ISPN-10309 Project: Infinispan Issue Type: Enhancement Components: Core Reporter: Will Burns Assignee: Will Burns Fix For: 10.0.0.Final We would love to get our thread pools down to a single CPU thread pool (size = numCores) and a blocking thread pool (arbitrarily large). We may also require a scheduler pool for various options as well (limited size 1-2?). To do this we need to remove remnants of our blocking code as possible. Possible issues for blocking are mostly around locks and io operations. The persistence layer was completed with ISPN-9722 so that is not an issue. The requirement around locking can be relaxed if the locks are guaranteed to be small in scope and do not wrap other blocking operations. An example would be a lock such as ones in CHM as long as we don't have large blocks for functional argument types. If code cannot be made non blocking we must offload the operation to the blocking thread pool. Care must be taken to ensure that once the blocking portion of code is completed that we switch back the to CPU thread pool as soon as possible. The listener API for example is violating this and will run code in Infinispan from any thread that completes the listener that could be done from a user. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10308) Allow overwrite startJGroupsChannelIfNeeded

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-10308?page=com.atlassian.jira.plugin... ] Diego Lovison updated ISPN-10308: --------------------------------- Status: Open (was: New) > Allow overwrite startJGroupsChannelIfNeeded > ------------------------------------------- > > Key: ISPN-10308 > URL: https://issues.jboss.org/browse/ISPN-10308 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 10.0.0.Beta4 > Reporter: Diego Lovison > Priority: Minor > > RadarGun need to call a custom code after the JChannel was created but before it was connected -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2019