[JBoss JIRA] (ISPN-10286) Segmented Store can get stuck with bulk write
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10286?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10286:
-----------------------------------
Sprint: ISPN+RHDG Sprint #29
> Segmented Store can get stuck with bulk write
> ---------------------------------------------
>
> Key: ISPN-10286
> URL: https://issues.jboss.org/browse/ISPN-10286
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 10.0.0.Alpha3
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> The code was refactored in ComposedSegmentedLoadWriteStore to be more non blocking friendly. Unfortunately due to how groupBy and flatMap interact it is possible for the bulkUpdate to never complete.
> FlatMap by default sets a parallelism level of 128. this means it will request 128 groups from groupBy, but unfortunately if there are more than 128 groups, it will never complete as groupBy must publish all groups before a single one can complete. Thus any time we use flatMap after a groupBy we must either set the parallelism level to Integer.MAX_VALUE or to an explicit value if we know how many groups at max there will be.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (ISPN-9722) Perform all CacheStore operations on a separate thread
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9722?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9722:
----------------------------------
Sprint: ISPN+RHDG Sprint #29
> Perform all CacheStore operations on a separate thread
> ------------------------------------------------------
>
> Key: ISPN-9722
> URL: https://issues.jboss.org/browse/ISPN-9722
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> Persistence is one of the few remaining systems that are not non blocking. This needs to be remedied. We will eventually need to add an SPI that does this, but for now we need to offload the persistence operations to a different thread pool.
> This should only require changes in the PersistenceManager to return non blocking methods (ie. return CompletionStage). We should then update references to use non blocking when possible.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (ISPN-10137) Component dependency injection should not use reflection
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10137?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10137:
-----------------------------------
Sprint: ISPN+RHDG Sprint #29
> Component dependency injection should not use reflection
> --------------------------------------------------------
>
> Key: ISPN-10137
> URL: https://issues.jboss.org/browse/ISPN-10137
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 9.4.12.Final, 10.0.0.Beta3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> Quarkus allows reflection, but "[t]his is normally achieved by listing every class, method, field and constructor in a JSON file, and passing this as a parameter into the native image build", so it would be much better if we generated code to perform the injection without reflection.
> Because the generated code needs to obey Java's accessibility rules and generating code in the same class is impractical, private fields and methods annotated {{@Inject}} will not be supported.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months