> 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.
