You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Pavel Tupitsyn <pt...@apache.org> on 2020/09/13 10:26:16 UTC
Thin Client ping operation?
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
> >> >> > > >>
> >> >> > >
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >>
> >>
>
>
>
>
Re[4]: Thin Client ping operation?
Posted by Zhenya Stanilovsky <ar...@mail.ru.INVALID>.
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[2]: Thin Client ping operation?
Posted by Pavel Tupitsyn <pt...@apache.org>.
> Whats the usage of such API
Health checks are the primary use case. See linked user list thread.
On Tue, Sep 15, 2020 at 12:26 PM Zhenya Stanilovsky
<ar...@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[2]: Thin Client ping operation?
Posted by Zhenya Stanilovsky <ar...@mail.ru.INVALID>.
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: Thin Client ping operation?
Posted by Igor Sapego <is...@apache.org>.
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 <pl...@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 <pt...@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 <ni...@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 <is...@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 <pt...@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: Thin Client ping operation?
Posted by Alex Plehanov <pl...@gmail.com>.
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 <pt...@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 <ni...@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 <is...@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 Николай Ижиков <ni...@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 <pt...@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: Thin Client ping operation?
Posted by Pavel Tupitsyn <pt...@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 <ni...@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 <is...@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 Николай Ижиков <ni...@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 <pt...@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: Thin Client ping operation?
Posted by Nikolay Izhikov <ni...@apache.org>.
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 <is...@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 Николай Ижиков <ni...@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 <pt...@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: Thin Client ping operation?
Posted by Igor Sapego <is...@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 Николай Ижиков <ni...@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 <pt...@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: Thin Client ping operation?
Posted by Николай Ижиков <ni...@apache.org>.
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 <pt...@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