Thin Client ping operation?

[Pavel Tupitsyn]

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

[Nikolay Izhikov-2]

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 <[hidden email]> написал(а):
>
> 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

[Igor Sapego-2]

Николай,

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 Николай Ижиков <[hidden email]> 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 <[hidden email]>
> написал(а):
> >
> > 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
>

[Nikolay Izhikov-2]

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 <[hidden email]> написал(а):
>
> Николай,
>
> 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 Николай Ижиков <[hidden email]> 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 <[hidden email]>
>> написал(а):
>>>
>>> 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
>>

[Pavel Tupitsyn]

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 <[hidden email]>
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 <[hidden email]> написал(а):
> >
> > Николай,
> >
> > 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 Николай Ижиков <[hidden email]>
> 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 <[hidden email]>
> >> написал(а):
> >>>
> >>> 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
> >>
>
>

[Alexey Plekhanov]

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 <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>
> написал(а):
> > >
> > > Николай,
> > >
> > > 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 Николай Ижиков <[hidden email]>
> > 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 <[hidden email]>
> > >> написал(а):
> > >>>
> > >>> 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
> > >>
> >
> >
>

[Igor Sapego-2]

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 <[hidden email]>
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 <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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 <[hidden email]>
> > написал(а):
> > > >
> > > > Николай,
> > > >
> > > > 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 Николай Ижиков <[hidden email]
> >
> > > 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 <[hidden email]>
> > > >> написал(а):
> > > >>>
> > > >>> 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
> > > >>
> > >
> > >
> >
>

[Zhenya Stanilovsky]

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 < [hidden email] >
>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 < [hidden email] >:
>>
>> > 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 < [hidden email] >
>> > 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 < [hidden email] >
>> > написал(а):
>> > > >
>> > > > Николай,
>> > > >
>> > > > 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 Николай Ижиков < [hidden email]
>> >
>> > > 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 < [hidden email] >
>> > > >> написал(а):
>> > > >>>
>> > > >>> 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
>> > > >>
>> > >
>> > >
>> >
>>

 
 
 
 

[Pavel Tupitsyn]

> 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
<[hidden email]> 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 < [hidden email]
> >
> >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 < [hidden email] >:
> >>
> >> > 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 <
> [hidden email] >
> >> > 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 < [hidden email] >
> >> > написал(а):
> >> > > >
> >> > > > Николай,
> >> > > >
> >> > > > 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 Николай Ижиков <
> [hidden email]
> >> >
> >> > > 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 <
> [hidden email] >
> >> > > >> написал(а):
> >> > > >>>
> >> > > >>> 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
> >> > > >>
> >> > >
> >> > >
> >> >
> >>
>
>
>
>

[Zhenya Stanilovsky]

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
>< [hidden email] > 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 <  [hidden email]
>> >
>> >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 <  [hidden email] >:
>> >>
>> >> > 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 <
>>  [hidden email] >
>> >> > 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 <  [hidden email] >
>> >> > написал(а):
>> >> > > >
>> >> > > > Николай,
>> >> > > >
>> >> > > > 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 Николай Ижиков <
>>  [hidden email]
>> >> >
>> >> > > 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 <
>>  [hidden email] >
>> >> > > >> написал(а):
>> >> > > >>>
>> >> > > >>> 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
>> >> > > >>
>> >> > >
>> >> > >
>> >> >
>> >>
>>
>>
>>
>>

 
 
 
 

[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
<[hidden email]> 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
> >< [hidden email] > 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 <
> [hidden email]
> >> >
> >> >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 <  [hidden email]
> >:
> >> >>
> >> >> > 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 <
> >>  [hidden email] >
> >> >> > 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 <  [hidden email] >
> >> >> > написал(а):
> >> >> > > >
> >> >> > > > Николай,
> >> >> > > >
> >> >> > > > 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 Николай Ижиков <
> >>  [hidden email]
> >> >> >
> >> >> > > 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 <
> >>  [hidden email] >
> >> >> > > >> написал(а):
> >> >> > > >>>
> >> >> > > >>> 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
> >> >> > > >>
> >> >> > >
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >>
> >>
>
>
>
>

[Zhenya Stanilovsky]

I understand now, thanks Pavel, initial discussion didn`t touch kuber theme ...

 

>Вторник, 15 сентября 2020, 18:22 +03:00 от Pavel Tupitsyn <[hidden email]>:
> 
>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 < [hidden email] > 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
>>><  [hidden email] > 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 <   [hidden email]
>>>> >
>>>> >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 <   [hidden email] >:
>>>> >>
>>>> >> > 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 <
>>>>   [hidden email] >
>>>> >> > 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 <   [hidden email] >
>>>> >> > написал(а):
>>>> >> > > >
>>>> >> > > > Николай,
>>>> >> > > >
>>>> >> > > > 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 Николай Ижиков <
>>>>   [hidden email]
>>>> >> >
>>>> >> > > 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 <
>>>>   [hidden email] >
>>>> >> > > >> написал(а):
>>>> >> > > >>>
>>>> >> > > >>> 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
>>>> >> > > >>
>>>> >> > >
>>>> >> > >
>>>> >> >
>>>> >>
>>>>
>>>>
>>>>
>>>>
>> 
>> 
>> 
>> 

 
 
 
 

[Sergey Stronchinskiy]

Hello Pavel,

+1 for external API.

On Tue, 15 Sep 2020 at 19:58, Zhenya Stanilovsky <[hidden email]>
wrote:

>
> I understand now, thanks Pavel, initial discussion didn`t touch kuber
> theme ...
>
>
> >Вторник, 15 сентября 2020, 18:22 +03:00 от Pavel Tupitsyn <
> [hidden email]>:
> >
> >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 <
> [hidden email] > 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
> >>><  [hidden email] > 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 <
> [hidden email]
> >>>> >
> >>>> >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 <
> [hidden email] >:
> >>>> >>
> >>>> >> > 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 <
> >>>>   [hidden email] >
> >>>> >> > 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 <
> [hidden email] >
> >>>> >> > написал(а):
> >>>> >> > > >
> >>>> >> > > > Николай,
> >>>> >> > > >
> >>>> >> > > > 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 Николай Ижиков <
> >>>>   [hidden email]
> >>>> >> >
> >>>> >> > > 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 <
> >>>>   [hidden email] >
> >>>> >> > > >> написал(а):
> >>>> >> > > >>>
> >>>> >> > > >>> 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
> >>>> >> > > >>
> >>>> >> > >
> >>>> >> > >
> >>>> >> >
> >>>> >>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>
> >>
>
>
>
>

[Pavel Tupitsyn]

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 <[hidden email]>
wrote:

> Hello Pavel,
>
> +1 for external API.
>
> On Tue, 15 Sep 2020 at 19:58, Zhenya Stanilovsky
> <[hidden email]>
> wrote:
>
> >
> > I understand now, thanks Pavel, initial discussion didn`t touch kuber
> > theme ...
> >
> >
> > >Вторник, 15 сентября 2020, 18:22 +03:00 от Pavel Tupitsyn <
> > [hidden email]>:
> > >
> > >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 <
> > [hidden email] > 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
> > >>><  [hidden email] > 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 <
> > [hidden email]
> > >>>> >
> > >>>> >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 <
> > [hidden email] >:
> > >>>> >>
> > >>>> >> > 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 <
> > >>>>   [hidden email] >
> > >>>> >> > 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 <
> > [hidden email] >
> > >>>> >> > написал(а):
> > >>>> >> > > >
> > >>>> >> > > > Николай,
> > >>>> >> > > >
> > >>>> >> > > > 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 Николай Ижиков <
> > >>>>   [hidden email]
> > >>>> >> >
> > >>>> >> > > 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 <
> > >>>>   [hidden email] >
> > >>>> >> > > >> написал(а):
> > >>>> >> > > >>>
> > >>>> >> > > >>> 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
> > >>>> >> > > >>
> > >>>> >> > >
> > >>>> >> > >
> > >>>> >> >
> > >>>> >>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>
> > >>
> > >>
> > >>
> >
> >
> >
> >
>