I understand now, thanks Pavel, initial discussion didn`t touch kuber theme ...
>Вторник, 15 сентября 2020, 18:22 +03:00 от Pavel Tupitsyn ><ptupit...@apache.org>: > >Zhenya, sure, let me explain. > >Health checks are a common practice in modern deployments, quote [1]: >"Health probes can be used by container orchestrators and load balancers to >check an app's status. >For example, a container orchestrator may respond to a failing health check by >halting a rolling deployment or restarting a container. >A load balancer might react to an unhealthy app by routing traffic away from >the failing instance to a healthy instance." > >Kubernetes has various probes [2] to determine the pod status. > >So Ignite users need a proper mechanism to determine connectivity status of >the thin client >to integrate with frameworks and orchestrators. > >[1] https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks >[2] >https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ > >On Tue, Sep 15, 2020 at 4:36 PM Zhenya Stanilovsky < >arzamas...@mail.ru.invalid > wrote: > >>Pavel, i read whole thread, show me the reason why this functionality need to >>be external ? >> >>> >>> >>>Health checks are the primary use case. See linked user list thread. >>> >>>On Tue, Sep 15, 2020 at 12:26 PM Zhenya Stanilovsky >>>< arzamas...@mail.ru.invalid > wrote: >>> >>>> >>>> Whats the usage of such API ? Igor can you clarify please ? >>>> >>>> >Personally I believe that public API still can be helpful, as it gives >>>> user >>>> >an ability to check connection in the specific point in time, even if >>>> >automatic >>>> >ping is implemented (which is more complex and hard-to-maintain feature >>>> >by the way). >>>> > >>>> >Not sure there should be "ping" in API though, maybe something more like >>>> >client.checkConnection(); >>>> > >>>> >Best Regards, >>>> >Igor >>>> > >>>> > >>>> >On Mon, Sep 14, 2020 at 11:37 AM Alex Plehanov < plehanov.a...@gmail.com >>>> > >>>> >wrote: >>>> > >>>> >> Hello guys, >>>> >> >>>> >> We've already raised the question about ping requests here [1]. >>>> >> >>>> >> I'm not sure about public API, but at least we can have auto-ping as an >>>> >> internal mechanism. This will be helpful if the client doesn't send any >>>> new >>>> >> requests but only waits for server-side notifications (for example, if >>>> the >>>> >> client subscribed to CQ events). The client can't detect a connection >>>> lost >>>> >> until sending something to the server. Using periodic ping requests this >>>> >> problem can be solved. >>>> >> >>>> >> So, +1 to add ping to the protocol, +0 to expose it to public API. >>>> >> >>>> >> [1] >>>> >> >>>> >> >>>> >>>>http://apache-ignite-developers.2346864.n4.nabble.com/IEP-44-Thin-Client-Discovery-tp47129p47318.html >>>> >> >>>> >> пн, 14 сент. 2020 г. в 10:32, Pavel Tupitsyn < ptupit...@apache.org >: >>>> >> >>>> >> > Nikolay, >>>> >> > >>>> >> > See the discussion on the user list: >>>> >> > >>>> >> > 1. It is not immediately obvious which APIs perform server calls and >>>> >> which >>>> >> > don't. >>>> >> > 2. It is not clear which APIs can cause heavy resource usage on the >>>> >> server >>>> >> > side. >>>> >> > We don't want to stress servers by pinging them. >>>> >> > cache.size() is an example - it is tempting to use and seems to be >>>> >> > simple, but actually queries every server node in the cluster. >>>> >> > >>>> >> > > dedicated `ping` operation makes our API heavier >>>> >> > The operation is so trivial that I would not worry about increased >>>> >> > complexity or future maintenance. >>>> >> > >>>> >> > On Mon, Sep 14, 2020 at 10:17 AM Nikolay Izhikov < >>>> nizhi...@apache.org > >>>> >> > wrote: >>>> >> > >>>> >> > > Hello, Igor. >>>> >> > > >>>> >> > > On the other hand, dedicated `ping` operation makes our API heavier >>>> >> > > without adding new feature - >>>> >> > > We can do the same with the other part of the API. >>>> >> > > >>>> >> > > Moreover, response to the ping doesn’t mean that SQL or cache query >>>> can >>>> >> > be >>>> >> > > served. >>>> >> > > >>>> >> > > > 14 сент. 2020 г., в 10:08, Igor Sapego < isap...@apache.org > >>>> >> > написал(а): >>>> >> > > > >>>> >> > > > Николай, >>>> >> > > > >>>> >> > > > It looks a little bit hacky to me. I believe SQL drivers usually >>>> use >>>> >> > that >>>> >> > > > approach >>>> >> > > > as a workaround because there is no other common way to do that. >>>> >> > > > >>>> >> > > > Sure we can recommend users to use cache.size() or anything other >>>> >> > > > similar way >>>> >> > > > to ensure the connection is alive, but it still looks like a >>>> >> workaround >>>> >> > > to >>>> >> > > > me. >>>> >> > > > >>>> >> > > > Best Regards, >>>> >> > > > Igor >>>> >> > > > >>>> >> > > > >>>> >> > > > On Sun, Sep 13, 2020 at 10:16 PM Николай Ижиков < >>>> nizhi...@apache.org >>>> >> > >>>> >> > > wrote: >>>> >> > > > >>>> >> > > >> Hello, Pavel. >>>> >> > > >> >>>> >> > > >> SQL drivers usually use “SELECT 1” query to ensure connection is >>>> >> > alive. >>>> >> > > >> >>>> >> > > >> Can we use similar approach? >>>> >> > > >> >>>> >> > > >> Отправлено с iPhone >>>> >> > > >> >>>> >> > > >>> 13 сент. 2020 г., в 13:26, Pavel Tupitsyn < >>>> ptupit...@apache.org > >>>> >> > > >> написал(а): >>>> >> > > >>> >>>> >> > > >>> Igniters, >>>> >> > > >>> >>>> >> > > >>> There is a feature request for a thin client Ping operation on >>>> the >>>> >> > user >>>> >> > > >>> list [1]. >>>> >> > > >>> I think that is a good idea - IgniteClient.ping() will be a >>>> >> valuable >>>> >> > > >>> addition. >>>> >> > > >>> >>>> >> > > >>> Any objections? >>>> >> > > >>> >>>> >> > > >>> [1] >>>> >> > > >>> >>>> >> > > >> >>>> >> > > >>>> >> > >>>> >> >>>> >>>>http://apache-ignite-users.70518.x6.nabble.com/Feature-request-method-to-test-active-connection-in-Ignite-thin-client-td33985.html >>>> >> > > >> >>>> >> > > >>>> >> > > >>>> >> > >>>> >> >>>> >>>> >>>> >>>> >> >> >> >>
