June 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10362) Unify remove command initialization and invocation

by Dan Berindei (Jira)

Dan Berindei created ISPN-10362: ----------------------------------- Summary: Unify remove command initialization and invocation Key: ISPN-10362 URL: https://issues.jboss.org/browse/ISPN-10362 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 10.0.0.Beta3 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 10.0.0.Beta4, 10.0.0.Final ISPN-10322 unified command initialization with {{InitializableCommand}}, but we should go further and unify initialization with invocation. We can replace the current {{ReplicableCommand.invokeAsync}} and {{InitializableCommand.init(ComponentRegistry()}} methods with a method {{CacheRpcCommand.invokeAsync(ComponentRegistry)}} (or maybe {{execute}}?). For global commands we can create a {{GlobalRpcCommand}} interface with a method {{invokeAsync(GlobalComponentRegistry)}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6483) CacheRpcCommandExternalizer frequently performs lookups from GlobalComponentRegistry

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-6483?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-6483. -------------------------------- Fix Version/s: 9.0.0.Final Resolution: Done The cache marshaller was removed with ISPN-6905 > CacheRpcCommandExternalizer frequently performs lookups from GlobalComponentRegistry > ------------------------------------------------------------------------------------ > > Key: ISPN-6483 > URL: https://issues.jboss.org/browse/ISPN-6483 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Sanne GRINOVERO > Priority: Major > Labels: performance > Fix For: 9.0.0.Final > > > This is a significant CPU consumer; talking with Dan and Galder it looks like the reasons for the design might have changed and this could be simplified. > {noformat} > org.infinispan.factories.GlobalComponentRegistry.getNamedComponentRegistry(String) > org.infinispan.marshall.exts.CacheRpcCommandExternalizer.getCacheMarshaller(String) > org.infinispan.marshall.exts.CacheRpcCommandExternalizer.writeObject(ObjectOutput, CacheRpcCommand) > org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(ObjectInput) > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9850) State transfer enabled attribute is overridden by store fetch-state attribute

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9850?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9850: ------------------------------- Sprint: DataGrid Sprint #30 > State transfer enabled attribute is overridden by store fetch-state attribute > ----------------------------------------------------------------------------- > > Key: ISPN-9850 > URL: https://issues.jboss.org/browse/ISPN-9850 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Core > Affects Versions: 10.0.0.Alpha2, 9.4.5.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > > The decision whether to request state is made based on {{(configuration.clustering().stateTransfer().fetchInMemoryState() || configuration.persistence().fetchPersistentState())}}. In the XML {{fetchInMemoryState}} is {{<state-transfer enabled=X/>}}, {{fetchPersistentState}} is {{<store fetch-state=X/>}}. > We should rename {{fetchInMemoryState}} to match the XML and to indicate that it enables/disables all state transfer, and stores should not be allowed to fetch state if state transfer was disabled in the state transfer configuration. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9852) Invocations waiting for a new topology should resume in parallel

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9852?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-9852. -------------------------------- Fix Version/s: (was: 9.4.16.Final) Resolution: Out of Date With ISPN-10309 we are moving the blocking operations to a separate thread pool, so this is no longer relevant. > Invocations waiting for a new topology should resume in parallel > ---------------------------------------------------------------- > > Key: ISPN-9852 > URL: https://issues.jboss.org/browse/ISPN-9852 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.11.Final, 10.0.0.Alpha2, 9.4.5.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta4 > > > When a command requires a topology newer than the current topology, it uses {{StateTransferLock.transactionDataFuture()}} to wait for the newer topology. When the tx data is received for the newer topology, some (most?) of the waiting operations do not use a separate executor, instead they are all resumed on the thread that received the tx data. If some operations block (e.g. because of a store), it could take a very long time to finish all the blocked operations. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

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