[infinispan-dev] Streams & missing segments
Radim Vansa
rvansa at redhat.com
Tue Apr 11 02:59:37 EDT 2017
Yes, I am trying to reuse those components and I've did only minor
modifications so far. Without topology change that works. But I
understand that you had some concept behind these components and I am
looking for a natural extension.
So, if I need to add waiting, is it acceptable to add StateTransferLock
and DistributionManager into ClusterStreamManager? That sounds like the
most convenient way, but then I should remove CH as the parameter from
calls from DistributedCacheStream, because routing information is
already available in ClusterStreamManager.
Radim
On 04/10/2017 05:56 PM, William Burns wrote:
> Comments inline
>
> To be honest it might be easier to talk on IRC sometime since I am not
> sure the exact part you are trying to work on now. I am guessing you
> are reusing the ClusterStreamManager and LocalStreamManager parts and
> adapting as needed but I don't know for sure.
>
> On Mon, Apr 10, 2017 at 6:41 AM Radim Vansa <rvansa at redhat.com
> <mailto:rvansa at redhat.com>> wrote:
>
> Hi Will,
>
> rebasing scattered cache PR I've found a test failure when handling
> streams, and I'd like to ask you guidance, how to address it.
>
> My problem is that temporarily primary owners can be unknown (when a
> node crashes), but streams assume that there's always a primary owner.
> Therefore, a remote streams operation must be delayed until a topology
> arrives where the new owner is decided.
>
>
> One thing to reduce this is if a node was primary there is a special
> exception. If this node becomes a backup owner after being primary
> this is fine. The segment is only suspected if it loses ownership
> completely.
>
> There is no waiting currently it will submit the request again until
> it eventually gets what it wants. (this could be improved) There is a
> wait though when the originator has a newer topology if a remote node
> doesn't yet have the updated topology (StreamRequestCommand implements
> TopologyAffectedCommand).
>
>
> Could you suggest how should I adapt the code?
>
>
> The ClusterStreamManager only does one invocation and stores the
> results from that invocation. The caller then has to adapt the next
> call with the segments it still needs and call back into the
> ClusterStreamManager if needed (segments could be owned locally now).
>
> ClusteredStreamManagerImpl currently does not hold DistributionManager
> reference, ConsistenHash is passed down from
> DistributedCacheStream, and
> it seems that segments are suspected after any unsuccessful response.
> Which components should react to topology changes?
>
>
> The only component currently that reacts to topology change is in the
> LocalStreamManagerImpl which registers a listener to detect when a
> segment is lost. This is done on remote nodes only. When this segment
> is lost it will send that those segments weren't completed back to the
> requester (ClusterStreamManager) on its next response.
>
> As you mentioned any unsuccessful response is treated as suspected,
> since we can't really trust that node, so there is no code on
> originator required to listen for topology changes.
>
>
> Thanks!
>
> Radim
>
>
> --
> Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
> https://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
--
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team
More information about the infinispan-dev
mailing list