[infinispan-dev] Failover and state of Callable in dist.exec

[Dan Berindei]

I'd keep it as it is, by making promises about preserving the callable
state you're opening a lot of edge cases that you need to document. You
have to also specify when the state is not preserved: if the target leaves
the cluster, if there is a replication timeout, if there is a problem with
serialization of the intermediate state, and so on...

Besides, I don't think this feature would interact with transactions very
well, because the Callable would be reading values from the cache in one
transaction (on the original target) and using the same values in a
different transaction (on the failover target) - with no consistency
guarantees.

Cheers
Dan



On Thu, Nov 22, 2012 at 6:30 PM, Vladimir Blagojevic <vblagoje at redhat.com>wrote:

> Hey guys,
>
> As Anna and I were working on failover tests we discovered one
> peculiarity - state of Callable is not preserved as we send it to
> various nodes for execution. I am not 100% this is important but it
> might be for some clients. As things stand right now we always failover
> to different nodes from master node. Every time Callables fails the call
> unwinds immediately back to originating node and originating node sends
> callable to another node. Fairly straight forward and expected. However,
> for repeated executions, we send fresh "originating" copy of Callable,
> in virgin state as it was submitted to dist.exec to begin with. In order
> to preserve state we would have to serialize back state from failed node
> and use that Callable state instead of virgin copy.
>
> What do you think? Is this state preservation a deal breaker? Or should
> we postpone it for next release?
>
> Regards,
> Vladimir
> _______________________________________________
> 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/20121122/b96b6b65/attachment.html