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