This is mentioned by Tristan "L4 client intelligence" which mean HotRod not Network
On Mon, May 22, 2017 at 1:52 PM, Sebastian Laskawiec <slask...@redhat.com> wrote: > > > On Fri, May 19, 2017 at 1:18 PM Wolf Fink <wf...@redhat.com> wrote: > >> +1 for Vojtech >> >> yes the client's need to moved to the new cluster in one shot current, >> that was discussed before. >> And it makes the migration because most of the customers are not able to >> make that happen. >> So there is a small possibility of inconsistence if clients connect to >> the old server update entries until the new server already migrated it. >> >> I see two options >> 1) >> source server need to propagate active to target on update >> 2) >> with the new L4 strategy all clients are moved automatically to the >> target. So the source is not updated. >> I only see a small possibility for this to happen during switch >> - a client might still have a request to the source until other clients >> are moved to target and already accessed the key >> - a new client connects with old properties, here we need to ensure that >> the first request is redirected to the target and not update the source >> > > Could you please tell me what L4 means in this context? Are you referring > to L4 routing/switching (transport level) or new Hot Rod client > intelligence? > > In Kubernetes/OpenShift governing an Infinispan cluster by a Load Balancer > could do the trick. If all clients will use Service URL, once Kubernetes > kills all "old" Pods, all TCP socket connection will break and the client > will retry. This will result in massive load of error messages but the > client will eventually connect to the new cluster. > > >> >> On Fri, May 19, 2017 at 12:50 PM, Vojtech Juranek <vjura...@redhat.com> >> wrote: >> >>> On středa 17. května 2017 16:56:25 CEST Tristan Tarrant wrote: >>> > 2) Need a way to "rollback" the process in case of failures during the >>> > migration: redirecting the clients back to the original cluster without >>> > data loss. This would use the above L4 strategy. >>> >>> it's not only about redirecting clients - IIRC newly created entries on >>> target >>> cluster are not propagated back to source cluster during rolling >>> upgrade, so >>> we need also somehow sync these new data back to source cluster during >>> the >>> rollback to avoid data losses. Same applies to "cancel process" feature >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > > SEBASTIAN ŁASKAWIEC > > INFINISPAN DEVELOPER > > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev