Vyacheslav, thanks for the explanation, makes sense to me. I was thinking though, should we make the behavior with the timeout default for all proxies?
Just my opinion - I think for a user it would be hard to control which node deploys the service, especially if multiple nodes deploy it concurrently. Most likely users will end up always calling the second option of the proxy (with the timeout), so, perhaps, make it default? вс, 29 дек. 2019 г. в 21:05, Vyacheslav Daradur <daradu...@gmail.com>: > Alexey, > > I've prepared pr [1] to show our proxy invocation guarantees and to > avoid misunderstanding. > > Please, let me know if you think that we should improve our guaranties > in some cases. > > [1] https://github.com/apache/ignite/pull/7213 > > On Tue, Dec 24, 2019 at 7:27 PM Vyacheslav Daradur <daradu...@gmail.com> > wrote: > > > > > even the local deployment looks broken: if a compute job > > > is sent to a remote node after the service deployment > > > > This is a different case and covered by retries: > > * If you deploy a service from node A to node B, then take a proxy > > from node A (deployment initiator) it should NOT fail even if node B > > has not received yet a message that deployment finished successfully, > > because of proxy invocation retries. > > > > Look like It's better to describe all these cases on the wiki. > > > > > Should we schedule this ticket for the further work on Services IEP? > > > > If it is a frequent use-case we definitely should implement it. > > > > > > On Tue, Dec 24, 2019 at 6:55 PM Alexey Goncharuk > > <alexey.goncha...@gmail.com> wrote: > > > > > > Ok, got it. > > > > > > I agree that this is consistent with the old behavior, but this is the > kind > > > of errors we wanted to get rid of when we started the IEP. From the > > > user perspective, even the local deployment looks broken: if a compute > job > > > is sent to a remote node after the service deployment, the job > execution > > > may fail due to this error. > > > > > > Should we schedule this ticket for the further work on Services IEP? > > > > > > вт, 24 дек. 2019 г. в 18:49, Vyacheslav Daradur <daradu...@gmail.com>: > > > > > > > Not sure that "user fallback" is the right definition, it is not new > > > > behaviour in comparison with legacy implementation. > > > > > > > > Our synchronous deployment provides guaranties for a deployment > > > > initiator to be able to start work with service immediately after > > > > deployment finished successfully. > > > > For not the deployment initiator we can't provide such guarantees > now, > > > > because of unknown deployment result and possibly fail. > > > > > > > > In this case, a reasonable timeout might be an acceptable solution. > > > > > > > > We can improve guaranties in future releases, but there is an open > > > > question: > > > > - how long taking of proxy should wait? - deployment of "heavy" > > > > service may take a while > > > > > > > > On Tue, Dec 24, 2019 at 6:19 PM Alexey Goncharuk > > > > <alexey.goncha...@gmail.com> wrote: > > > > > > > > > > What should be the user fallback in this case? Retry infinitely? Is > > > > there a > > > > > way to wait for the proper deployment? > > > > > > > > > > вт, 24 дек. 2019 г. в 12:41, Vyacheslav Daradur < > daradu...@gmail.com>: > > > > > > > > > > > I’ll take a look at the end of the week. > > > > > > > > > > > > There is one more use-case: > > > > > > * if you initiate deployment from node A, but getting proxy on > node B > > > > > > (which isn’t deployment initiator) to call service on node A - > it may > > > > fail > > > > > > with "service not found", this is expected behaviour because we > didn't > > > > > > provide such guarantees. > > > > > > > > > > > > API of getting proxy with timeout should be used in this case: > > > > > > T serviceProxy(String name, Class<? super T> svcItf, boolean > sticky, > > > > long > > > > > > timeout) > > > > > > > > > > > > > > > > > > вт, 24 дек. 2019 г. в 12:11, Alexey Goncharuk < > > > > alexey.goncha...@gmail.com > > > > > > >: > > > > > > > > > > > > > Well, this is exactly the case. The service is deployed from > node A, > > > > the > > > > > > > proxy is created on node B, and "service not found" exception > gets > > > > thrown > > > > > > > to a user anyway. Perhaps, the retry happens too fast? > > > > > > > > > > > > > > Created a ticket [1]. > > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12490 > > > > > > > > > > > > > > пн, 23 дек. 2019 г. в 22:08, Vyacheslav Daradur < > daradu...@gmail.com > > > > >: > > > > > > > > > > > > > > > Hi, Alexey > > > > > > > > > > > > > > > > Please attach a reproducer to the ticket. > > > > > > > > > > > > > > > > As far as I remember we have the following behaviour for the > > > > proxies: > > > > > > > > > > > > > > > > Let's assume you have deployed service from node A, then: > > > > > > > > * if you invoke service locally from node A - it is > guaranteed to > > > > > > > > service to be deployed and ready to work > > > > > > > > * if you take a proxy from node A to remote node B right > after > > > > deploy > > > > > > > > - there is might be a race between disco-spi (a message which > > > > releases > > > > > > > > deployed service) and comm-spi (remote call works via > Compute over > > > > > > > > comm-spi), but it shouldn't affect end-users because the > failed > > > > > > > > request will be retried in this case > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Dec 23, 2019 at 6:55 PM Alexey Goncharuk > > > > > > > > <alexey.goncha...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > Nikolay, > > > > > > > > > > > > > > > > > > Yes, I've rechecked, the new service processor is being > used. > > > > I'll > > > > > > > file a > > > > > > > > > bug shortly. > > > > > > > > > > > > > > > > > > пн, 23 дек. 2019 г. в 17:33, Николай Ижиков < > nizhi...@apache.org > > > > >: > > > > > > > > > > > > > > > > > > > Alexey, are you sure, you are testing new service > framework? > > > > > > > > > > > > > > > > > > > > Is yes - you definitely should file a bug. > > > > > > > > > > > > > > > > > > > > > 23 дек. 2019 г., в 17:02, Alexey Goncharuk < > > > > > > > > alexey.goncha...@gmail.com> > > > > > > > > > > написал(а): > > > > > > > > > > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > > > > > > > I have a question based on one of my recent tests > debugging. > > > > > > > > > > > > > > > > > > > > > > The test is related to Ignite services. I noticed that > > > > sometimes > > > > > > a > > > > > > > > proxy > > > > > > > > > > > invocation of a newly deployed service fails because > the > > > > service > > > > > > > > cannot > > > > > > > > > > be > > > > > > > > > > > found. I managed to reduce the test to a simple "start > two > > > > nodes, > > > > > > > > deploy > > > > > > > > > > a > > > > > > > > > > > service, create a proxy, invoke the proxy" scenario. > The > > > > proxy > > > > > > > > invocation > > > > > > > > > > > fails in about ~80% of runs. > > > > > > > > > > > > > > > > > > > > > > As far as I remember, the new discovery-based service > > > > deployment > > > > > > > was > > > > > > > > > > > supposed to be synchronous, so not only non-proxy > service > > > > > > instances > > > > > > > > > > should > > > > > > > > > > > work, but the proxies as well. Was my understanding > correct? > > > > > > > Should I > > > > > > > > > > file > > > > > > > > > > > a bug for the observed behavior? > > > > > > > > > > > > > > > > > > > > > > --AG > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Best Regards, Vyacheslav D. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best Regards, Vyacheslav D. > > > > > > > > > > > > -- > > Best Regards, Vyacheslav D. > > > > -- > Best Regards, Vyacheslav D. >
