[infinispan-dev] Cluster Executor failover and execution policy

[William Burns]

On Tue, Feb 21, 2017 at 10:33 AM Vladimir Blagojevic <vblagoje at redhat.com>
wrote:

> Will,
>
> I like the API proposal but one thing that jumps out for me is to combine
> or rather overload singleNodeSubmission with singleNodeSubmission(int
> failOverCount) and remove failoverRetries method. The first
> singleNodeSubmission does not failover while the second one does with the
> specified failOverCount. That way we don't have to keep state and throw
> IllegalStateException when someone erroneously calls failOverRetries.
>

Sounds good to me.  Not sure why I didn't think of that before.  It felt
awkward to me as well.  Guess I was stuck on having the method have the
name failover in it :)


>
> Vladimir
>
>
>
> On 2017-02-21 10:11 AM, William Burns wrote:
>
> As many of you are may or may not be aware the ClusterExecutor interface
> and implementation were introduced into Infinispan 8.2 [1].  This class is
> a new API that can be used to submit commands to other nodes in a way
> similar to DistributedExecutor does while also not being tied to a cache.
>
> The first implementation of ClusterExecutor did not include a couple
> features that DistributedExecutor has. For this post I will concentrate on
> failover and execution policies. My plan is to introduce some API to
> Infinispan 9 to allow for ClusterExecutor to also offer these capabilities.
>
> The first change is that I wanted to add additional options to Execution
> Policies.  The execution policy is used to limit sending messages to nodes
> based on their topology (site, rack & machine id).  The old execution
> policy allowed for SAME_MACHINE, SAME_RACK, SAME_SITE and ALL.  I plan on
> adding the opposite of the SAME and also supporting DIFFERENT_MACHINE,
> DIFFERENT_RACK and DIFFERENT_SITE in case if the user wants to ensure that
> data is processed elsewhere. Unless you think this is unneeded?
>
> The API changes I am thinking of are as below (included in email to allow
> for responses inline).  Note that existing methods would be unchanged and
> thus submit and execute methods would be used to send commands still. One
> big difference is that I have not allowed for the user to control the
> failover node or the target node when doing a single submission with
> multiple available targets.  In my mind if a user wants this they should do
> it themselves manually, but this is open for discussion as well.
>
> /** * When a command is submitted it will only be submitted to one node of the available nodes, there is no strict * requirements as to which node is chosen and is implementation specific. Fail over can be used with configuration, * please see {@link ClusterExecutor#failOverRetries(int)} for more information. * @return this executor again with commands submitted to a single node */ClusterExecutor singleNodeSubmission();
> /** * When a command is submitted it will submit this command to all of the available nodes.  Fail over is not supported * with this configuration. This is the default submission method. * @return this executor again with commands submitted to all nodes */ClusterExecutor allNodeSubmission();
> /** * Enables fail over to occur when using {@link ClusterExecutor#singleNodeSubmission()}. If the executor * is not currently in the single node submission mode, this method will throw {@link IllegalStateException}. * When fail over count is applied, a submitted command will be retried up to that many times on the available * command up to desired amount of times until an exception is not met. The one exception that is not retried is a * TimeoutException since this could be related to {@link ClusterExecutor#timeout(long, TimeUnit)}. Each time the * fail over occurs a random node in the available nodes will be used (trying not to reuse the same node). * @param failOverCount how many times this executor will attempt a failover * @return this executor again with fail over retries applied * @throws IllegalStateException if this cluster executor is not currently configured for single node submission */ClusterExecutor failOverRetries(int failOverCount) throws IllegalStateException;
> /** * Allows for filtering of address nodes by only allowing addresses that match the given execution policy to be used. * Note this method overrides any previous filtering that was done (ie. calling * {@link ClusterExecutor#filterTargets(Collection)}). * @param policy the policy to determine which nodes can be used * @return this executor again with the execution policy applied to determine which nodes are contacted */ClusterExecutor filterTargets(ClusterExecutionPolicy policy);
> /** * Allows for filtering of address nodes dynamically per invocation.  The predicate is applied to each member that * is part of the execution policy. Note that this method overrides any previous * filtering that was done (ie. calling {@link ClusterExecutor#filterTargets(Collection)}). * @param policy the execution policy applied before predicate to allow only nodes in that group * @param predicate the dynamic predicate applied each time an invocation is done * @return */ClusterExecutor filterTargets(ClusterExecutionPolicy policy, Predicate<? super Address> predicate);
>
>
> Thanks for any input,
>
>  - Will
>
> [1]
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/manager/ClusterExecutor.java
>
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing listinfinispan-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170221/ca738bc3/attachment-0001.html