[JBoss JIRA] (ISPN-10362) Unify remove command initialization and invocation
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10362?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10362:
-----------------------------------
Fix Version/s: 10.0.1.Final
(was: 10.0.0.Final)
> 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
> Priority: Major
> Fix For: 10.0.1.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.13.8#713008)
6 years, 5 months
[JBoss JIRA] (ISPN-10339) Investigate and Rework Multiple Cache Loaders Support
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10339?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10339:
-----------------------------------
Fix Version/s: 10.0.1.Final
(was: 10.0.0.Final)
> Investigate and Rework Multiple Cache Loaders Support
> -----------------------------------------------------
>
> Key: ISPN-10339
> URL: https://issues.jboss.org/browse/ISPN-10339
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Reporter: Will Burns
> Priority: Major
> Fix For: 10.0.1.Final
>
>
> Today having more than one loader configured is possible. However the way it operates is not well defined or even documented.
> Currently for single key operations we try each loader one by one until one returns non null. For writes we write to all stores. However for bulk operations we only load from the first AdvancedLoader. This can be a bit confusing how these are done, but makes sense at least when thought about.
> The other concern that is new is now that we have segmented loaders that perform better under bulk operations that their non segmented counterparts. ISPN-9816 makes it better, however its checking is not the most foolproof. We may want to instead explicitly find per invocation if the current loader is segmented or not before invoking the appropriate method. Currently we only check at startup if any loader is segmented; however this can be problematic if the first loader is not segmented and not advanced or handle the case of a loader being removed at runtime.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (ISPN-10310) State Transfer needs to be made non blocking
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10310?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10310:
-----------------------------------
Fix Version/s: 10.0.1.Final
(was: 10.0.0.Final)
> 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
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.1.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.13.8#713008)
6 years, 5 months
[JBoss JIRA] (ISPN-10301) Deprecate server media type application/x-java-object
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10301?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10301:
-----------------------------------
Fix Version/s: 10.0.1.Final
(was: 10.0.0.Final)
> Deprecate server media type application/x-java-object
> -----------------------------------------------------
>
> Key: ISPN-10301
> URL: https://issues.jboss.org/browse/ISPN-10301
> Project: Infinispan
> Issue Type: Task
> Components: Server
> Affects Versions: 10.0.0.Beta3
> Reporter: Dan Berindei
> Priority: Major
> Fix For: 10.0.1.Final
>
>
> `application/x-java-object` needs to have the application classes deployed on the server in order to do anything useful with it, and the server must also be able to do reflection on those application classes.
> We should steer users towards always using `application/x-protostream` instead, because the protobuf schemas are much easier to deploy to the server. The first step would be to make protostream the default marshalling mechanism in the client.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months