[JBoss JIRA] (ISPN-10290) JGroupsTransport.invokeCommandStaggered allocates too much
by Dan Berindei (Jira)
Dan Berindei created ISPN-10290:
-----------------------------------
Summary: JGroupsTransport.invokeCommandStaggered allocates too much
Key: ISPN-10290
URL: https://issues.jboss.org/browse/ISPN-10290
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.4.14.Final, 10.0.0.Beta3
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 10.0.0.Beta4
I assumed the {{logRequest(requestId, command, "staggered " + targets)}} call would be inlined and the JIT would eliminate the allocation when trace logging is disabled, but apparently that doesn't always happen, and a {{StringBuilder}} instance is always created.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (ISPN-10137) Component dependency injection should not use reflection
by Will Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-10137?page=com.atlassian.jira.plugin... ]
Will Burns updated ISPN-10137:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> 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)
5 years, 7 months
[JBoss JIRA] (ISPN-10286) Segmented Store can get stuck with bulk write
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-10286?page=com.atlassian.jira.plugin... ]
Ryan Emerson resolved ISPN-10286.
---------------------------------
Assignee: Will Burns
Resolution: Done
> 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)
5 years, 7 months