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 <gurustronpub...@gmail.com> wrote: > Hello Pavel, > > +1 for external API. > > On Tue, 15 Sep 2020 at 19:58, Zhenya Stanilovsky > <arzamas...@mail.ru.invalid> > 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 > > >>>> >> > > > 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 > > >>>> >> > > >> > > >>>> >> > > > > >>>> >> > > > > >>>> >> > > > >>>> >> > > >>>> > > >>>> > > >>>> > > >>>> > > >> > > >> > > >> > > >> > > > > > > > > >
