Re: Re[6]: Thin Client ping operation?
Looks like there are no major objections, so I'll move on with the implementation https://issues.apache.org/jira/browse/IGNITE-13454 On Wed, Sep 16, 2020 at 4:35 PM Guru Stron wrote: > Hello Pavel, > > +1 for external API. > > On Tue, 15 Sep 2020 at 19:58, Zhenya Stanilovsky > > wrote: > > > > > 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
Re: Re[6]: Thin Client ping operation?
Hello Pavel, +1 for external API. On Tue, 15 Sep 2020 at 19:58, Zhenya Stanilovsky wrote: > > 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 > >>
Re[6]: Thin Client ping operation?
I understand now, thanks Pavel, initial discussion didn`t touch kuber theme ... >Вторник, 15 сентября 2020, 18:22 +03:00 от Pavel Tupitsyn >: > >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.
