You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Zhenya Stanilovsky <ar...@mail.ru.INVALID> on 2020/09/15 13:36:01 UTC
Re[4]: Thin Client ping operation?
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
>< arzamas123@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.alex@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 < ptupitsyn@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 <
>> nizhikov@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 < isapego@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 Николай Ижиков <
>> nizhikov@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 <
>> ptupitsyn@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
>> >> > > >>
>> >> > >
>> >> > >
>> >> >
>> >>
>>
>>
>>
>>
Re: Re[6]: Thin Client ping operation?
Posted by Pavel Tupitsyn <pt...@apache.org>.
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 <gu...@gmail.com>
wrote:
> Hello Pavel,
>
> +1 for external API.
>
> On Tue, 15 Sep 2020 at 19:58, Zhenya Stanilovsky
> <ar...@mail.ru.invalid>
> wrote:
>
> >
> > I understand now, thanks Pavel, initial discussion didn`t touch kuber
> > theme ...
> >
> >
> > >Вторник, 15 сентября 2020, 18:22 +03:00 от Pavel Tupitsyn <
> > ptupitsyn@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 <
> > arzamas123@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
> > >>>< arzamas123@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.alex@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 <
> > ptupitsyn@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 <
> > >>>> nizhikov@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 <
> > isapego@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 Николай Ижиков <
> > >>>> nizhikov@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 <
> > >>>> ptupitsyn@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
> > >>>> >> > > >>
> > >>>> >> > >
> > >>>> >> > >
> > >>>> >> >
> > >>>> >>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>
> > >>
> > >>
> > >>
> >
> >
> >
> >
>
Re: Re[6]: Thin Client ping operation?
Posted by Guru Stron <gu...@gmail.com>.
Hello Pavel,
+1 for external API.
On Tue, 15 Sep 2020 at 19:58, Zhenya Stanilovsky <ar...@mail.ru.invalid>
wrote:
>
> I understand now, thanks Pavel, initial discussion didn`t touch kuber
> theme ...
>
>
> >Вторник, 15 сентября 2020, 18:22 +03:00 от Pavel Tupitsyn <
> ptupitsyn@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 <
> arzamas123@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
> >>>< arzamas123@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.alex@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 <
> ptupitsyn@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 <
> >>>> nizhikov@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 <
> isapego@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 Николай Ижиков <
> >>>> nizhikov@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 <
> >>>> ptupitsyn@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
> >>>> >> > > >>
> >>>> >> > >
> >>>> >> > >
> >>>> >> >
> >>>> >>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>
> >>
>
>
>
>
Re[6]: Thin Client ping operation?
Posted by Zhenya Stanilovsky <ar...@mail.ru.INVALID>.
I understand now, thanks Pavel, initial discussion didn`t touch kuber theme ...
>Вторник, 15 сентября 2020, 18:22 +03:00 от Pavel Tupitsyn <pt...@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 < arzamas123@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
>>>< arzamas123@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.alex@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 < ptupitsyn@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 <
>>>> nizhikov@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 < isapego@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 Николай Ижиков <
>>>> nizhikov@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 <
>>>> ptupitsyn@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
>>>> >> > > >>
>>>> >> > >
>>>> >> > >
>>>> >> >
>>>> >>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
Re: Re[4]: Thin Client ping operation?
Posted by Pavel Tupitsyn <pt...@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
<ar...@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
> >< arzamas123@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.alex@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 < ptupitsyn@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 <
> >> nizhikov@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 < isapego@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 Николай Ижиков <
> >> nizhikov@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 <
> >> ptupitsyn@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
> >> >> > > >>
> >> >> > >
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >>
> >>
>
>
>
>