Mikhail, I merged your changes.
Thanks for your contribution!
On Tue, May 12, 2020 at 8:01 PM Vyacheslav Daradur
wrote:
> Hi Mikhail, proposed changes make sense to me.
> I left some comments to the pr.
> Thank you!
>
> On Wed, May 6, 2020 at 2:28 PM Mikhail Petrov
> wrote:
>
>> Hello, Igniters
Hi Mikhail, proposed changes make sense to me.
I left some comments to the pr.
Thank you!
On Wed, May 6, 2020 at 2:28 PM Mikhail Petrov wrote:
> Hello, Igniters.
>
> I am working on IGNITE-12894 - [1]. It seems that it has the root cause
> which is similar to the problem described in this thread
Hello, Igniters.
I am working on IGNITE-12894 - [1]. It seems that it has the root cause
which is similar to the problem described in this thread.
To solve these problems, I propose to change the behavior of the
IgniteServiceProcessor#serviceTopology if the timeout argument is 0.
At the momen
Agree, sounds like a plan, thanks for taking over!
пн, 30 дек. 2019 г. в 13:00, Vyacheslav Daradur :
> Alexey,
>
> I would not make it default in the current implementation.
>
> Waiting of proxies on non-deployment-initiator nodes should be
> improved - additional checks are required:
> 1) We sho
Alexey,
I would not make it default in the current implementation.
Waiting of proxies on non-deployment-initiator nodes should be
improved - additional checks are required:
1) We should not wait if requested service has not been submitted to
deploy (when there is no info about such service)
2) If
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 concurren
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 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
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 exec
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 d
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 :
> 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 p
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
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
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
Nikolay,
Yes, I've rechecked, the new service processor is being used. I'll file a
bug shortly.
пн, 23 дек. 2019 г. в 17:33, Николай Ижиков :
> Alexey, are you sure, you are testing new service framework?
>
> Is yes - you definitely should file a bug.
>
> > 23 дек. 2019 г., в 17:02, Alexey Gonch
Alexey, are you sure, you are testing new service framework?
Is yes - you definitely should file a bug.
> 23 дек. 2019 г., в 17:02, Alexey Goncharuk
> написал(а):
>
> Igniters,
>
> I have a question based on one of my recent tests debugging.
>
> The test is related to Ignite services. I not
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
ser
17 matches
Mail list logo
