10:30 a.m.
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
11:59 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12:14 p.m.
On 22 Nov 2012, at 16:30, Vladimir Blagojevic wrote:
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?
Users cannot rely on the partial execution state, as the failure might be caused by a node
crash, situation in which no intermediate state is obtained. For now I think we should
only document this behaviour.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
4419
days inactive
4419
days old
infinispan-dev@lists.jboss.org
2 comments
3 participants
participants (3)
-
Dan Berindei -
Mircea Markus -
Vladimir Blagojevic