I've reviewed the code again and it does not seem right to override
user-defined heartbeat interval with a *bigger* value,
so now I only set it to 1/3 of idleTimeout when the user-specified value is
not already less than that.
On Wed, Feb 16, 2022 at 7:19 PM Pavel Tupitsyn <ptupit...@apache.org> wrote:
> Ok, let's keep heartbeatInterval then.
> I've updated the code to reflect our recent agreement, please review.
>
> On Tue, Feb 15, 2022 at 8:28 PM Ivan Daschinsky <ivanda...@gmail.com>
> wrote:
>
>> I personally prefer heartbeatInterval
>>
>> вт, 15 февр. 2022 г., 18:25 Pavel Tupitsyn <ptupit...@apache.org>:
>>
>> > > What about "keepAlive", "keepAliveInterval" then? It looks more common
>> > and matches the IEP title :)
>> > According to Google, HeartbeatInterval has ~169K results, and
>> > KeepAliveInterval has ~110K :)
>> >
>> > In my experience, both are well understood. I am equally willing to use
>> any
>> > of them.
>> > Any other opinions?
>> >
>> > On Tue, Feb 15, 2022 at 6:11 PM Maksim Timonin <timoninma...@apache.org
>> >
>> > wrote:
>> >
>> > > What about "keepAlive", "keepAliveInterval" then? It looks more common
>> > and
>> > > matches the IEP title :)
>> > >
>> > > On Tue, Feb 15, 2022 at 5:54 PM Pavel Tupitsyn <ptupit...@apache.org>
>> > > wrote:
>> > >
>> > > > To summarize, we add two properties to the ClientConfiguration:
>> > > > bool heartbeatsEnabled = true;
>> > > > long defaultHeartbeatInterval = 60_000; // Default 1 minute, used
>> > > >
>> > > > Logic:
>> > > > if (heartbeatsEnabled) {
>> > > > heartbeatInterval = serverIdleTimeout > 0 ? serverIdleTimeout / 3
>> :
>> > > > defaultHeartbeatInterval;
>> > > > }
>> > > >
>> > > >
>> > > > Thoughts, objections?
>> > > >
>> > > > On Tue, Feb 15, 2022 at 4:32 PM Ivan Daschinsky <
>> ivanda...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > Pavel, sorry, i've made mistake. But current behaviour is ok for
>> me.
>> > > This
>> > > > > timeout cannot be change on server side runtime. But we can
>> simplify
>> > > > > protocol just use one opcode and message
>> > > > >
>> > > > > вт, 15 февр. 2022 г., 14:54 Ivan Daschinsky <ivanda...@gmail.com
>> >:
>> > > > >
>> > > > > > > Idle timeout can't change, why send it back with every
>> heartbeat
>> > > > > > response?
>> > > > > > May be I am wrong, but from code I see this behaviour. But if I
>> am
>> > > > wrong,
>> > > > > > this is ok behaviour for me.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > вт, 15 февр. 2022 г. в 14:00, Pavel Tupitsyn <
>> ptupit...@apache.org
>> > >:
>> > > > > >
>> > > > > >> Ivan, I mostly agree with your proposal, except this point:
>> > > > > >>
>> > > > > >> > Response to heartbeat request -- is idle timeout
>> > > > > >> Idle timeout can't change, why send it back with every
>> heartbeat
>> > > > > response?
>> > > > > >>
>> > > > > >> > possible cases with cluster restart, upgrade
>> > > > > >> In those cases, a new connection will be established, and we'll
>> > > > retrieve
>> > > > > >> the new timeout after the handshake.
>> > > > > >>
>> > > > > >>
>> > > > > >> On Tue, Feb 15, 2022 at 12:04 PM Maksim Timonin <
>> > > > > timoninma...@apache.org>
>> > > > > >> wrote:
>> > > > > >>
>> > > > > >> > Hi Ivan,
>> > > > > >> >
>> > > > > >> > Cases you described sound reasonable to me. Then the client
>> > should
>> > > > > just
>> > > > > >> set
>> > > > > >> > up the `keepAlive` flag, and it just works.
>> > > > > >> >
>> > > > > >> > So, there are 3 branches:
>> > > > > >> > 1. Users don't configure keepAlive at all.
>> > > > > >> > 2. Users configure keepAliveHeartbeatInterval (long, ms).
>> > > > > >> > 3. Users configure keepAlive (boolean).
>> > > > > >> >
>> > > > > >> > AFAIU, Pavel's proposal is about covering the second case
>> only.
>> > > But
>> > > > > >> > actually the 2nd and 3rd aren't conflicted with each other.I
>> > think
>> > > > for
>> > > > > >> both
>> > > > > >> > branches, a cluster should respond with idleTimeout value on
>> > every
>> > > > > keep
>> > > > > >> > alive client request. Because there are possible cases with
>> > > cluster
>> > > > > >> > restart, upgrade, etc. Clients should check every response
>> and
>> > in
>> > > > case
>> > > > > >> of
>> > > > > >> > changed idleTimeout. For 2nd case write a WARN message, and
>> for
>> > > 3rd
>> > > > -
>> > > > > >> > reconfigure themself in case of changed idleTimeout.
>> > > > > >> >
>> > > > > >> >
>> > > > > >> >
>> > > > > >> >
>> > > > > >> > On Tue, Feb 15, 2022 at 9:51 AM Ivan Daschinsky <
>> > > > ivanda...@gmail.com>
>> > > > > >> > wrote:
>> > > > > >> >
>> > > > > >> > > Regarding discussion here [1]
>> > > > > >> > >
>> > > > > >> > > I suppose that this feature, despite the fact that initial
>> > > > intention
>> > > > > >> of
>> > > > > >> > > Pavel was different, can drastically
>> > > > > >> > > improve the usage pattern of thin clients and give a lot of
>> > > > > >> opportunities
>> > > > > >> > > if the following is done:
>> > > > > >> > >
>> > > > > >> > > 1. GridNioServer has a great feature -- idle timeout. If a
>> > > server
>> > > > > did
>> > > > > >> > not
>> > > > > >> > > receive any from a client -- it will be kicked off.
>> > > > > >> > > But there are some scenarios that make the use of this
>> > > feature
>> > > > > >> > > impossible:
>> > > > > >> > > a. Multiple workers waiting for batch tasks and relatively
>> low
>> > > > > >> requests
>> > > > > >> > > rate -- this services will be often kicked off and must
>> > > reconnect.
>> > > > > >> > > In order to prevent this behaviour, the user must
>> implement a
>> > > kind
>> > > > > of
>> > > > > >> > > heartbeating by himself.
>> > > > > >> > > b. Quite often user may want to implement leader-follower
>> > > pattern
>> > > > > for
>> > > > > >> > > services for HA, so followers also will be considered as
>> idle.
>> > > > > Kicking
>> > > > > >> > off
>> > > > > >> > > these followers
>> > > > > >> > > is not acceptable, so user should also implement
>> heartbeating
>> > > by
>> > > > > >> > himself.
>> > > > > >> > >
>> > > > > >> > > My proposition is:
>> > > > > >> > > 1. Add two flags -- enable/disable heartbeats, and very
>> > optional
>> > > > > >> > heartbeat
>> > > > > >> > > timeout. Set enable to true by default, timeout to default
>> > > > heartbeat
>> > > > > >> > > timeout.
>> > > > > >> > > 2. If server and client both support this feature, and
>> > > heartbeats
>> > > > > are
>> > > > > >> not
>> > > > > >> > > explicitly disabled on client side:
>> > > > > >> > > 3. Response to heartbeat request -- is idle timeout. If
>> idle
>> > > > timeout
>> > > > > >> is
>> > > > > >> > set
>> > > > > >> > > on the server side , set heartbeat timeout to one-third of
>> it,
>> > > > > instead
>> > > > > >> > set
>> > > > > >> > > to default or specified value.
>> > > > > >> > >
>> > > > > >> > > Pros:
>> > > > > >> > > 1. Easy to set up -- just flag on client side and just set
>> > > timeout
>> > > > > on
>> > > > > >> > > server side.
>> > > > > >> > > 2. Hard to configure improperly, i.e set heartbeat timeout
>> not
>> > > > short
>> > > > > >> > enough
>> > > > > >> > > in order to prevent kicking out by server.
>> > > > > >> > > 3. If the user just wants heartbeats without setting idle
>> > > timeout
>> > > > --
>> > > > > >> > > heartbeats are by default on and with reasonable timeout.
>> > > > > >> > >
>> > > > > >> > > Cons:
>> > > > > >> > > 1. If someone will rely on old behavior and just wants to
>> drop
>> > > his
>> > > > > >> > clients
>> > > > > >> > > on timeout -- this will not work without reconfiguring, he
>> > > should
>> > > > > >> disable
>> > > > > >> > > heartbeats.
>> > > > > >> > > But I cannot even imagine that someone will find this
>> > behaviour
>> > > > > >> > desirable.
>> > > > > >> > > I strongly believe that this behaviour prevents users from
>> > using
>> > > > > >> > > idleTimeout on server side.
>> > > > > >> > >
>> > > > > >> > > [1] --
>> > > > > >>
>> https://github.com/apache/ignite/pull/9817#discussion_r805628955
>> > > > > >> > >
>> > > > > >> > > пт, 11 февр. 2022 г. в 10:58, Pavel Tupitsyn <
>> > > > ptupit...@apache.org
>> > > > > >:
>> > > > > >> > >
>> > > > > >> > > > I've prepared a PR, please have a look:
>> > > > > >> > > > https://github.com/apache/ignite/pull/9817
>> > > > > >> > > >
>> > > > > >> > > > On Mon, Feb 7, 2022 at 6:37 PM Ivan Daschinsky <
>> > > > > ivanda...@gmail.com
>> > > > > >> >
>> > > > > >> > > > wrote:
>> > > > > >> > > >
>> > > > > >> > > > > I see potential in this feature, especially if we use
>> > > > something
>> > > > > >> like
>> > > > > >> > > > > continuous query. Stale clients can consume a lot of
>> > > resources
>> > > > > >> and it
>> > > > > >> > > is
>> > > > > >> > > > > worth kick these clients out.
>> > > > > >> > > > >
>> > > > > >> > > > > пн, 7 февр. 2022 г. в 18:25, Pavel Tupitsyn <
>> > > > > ptupit...@apache.org
>> > > > > >> >:
>> > > > > >> > > > >
>> > > > > >> > > > > > > If we use new approach, we can reduce this timeout.
>> > But
>> > > > this
>> > > > > >> can
>> > > > > >> > > > affect
>> > > > > >> > > > > > old clients.
>> > > > > >> > > > > >
>> > > > > >> > > > > > idleTimeout is disabled by default, we are not going
>> to
>> > > > change
>> > > > > >> > this.
>> > > > > >> > > > > >
>> > > > > >> > > > > > > Also, let's think about that sending heartbeats and
>> > > > interval
>> > > > > >> of
>> > > > > >> > > > sending
>> > > > > >> > > > > > > heartbeats could be calculated on the server side
>> > (i.e.
>> > > > one
>> > > > > >> third
>> > > > > >> > > of
>> > > > > >> > > > > idle
>> > > > > >> > > > > > > timeout) and sent to the client during handshake.
>> > > > > >> > > > > > > Also we can introduce something like a negotiation
>> > > > mechanism
>> > > > > >> as
>> > > > > >> > in
>> > > > > >> > > > > > > zookeeper.
>> > > > > >> > > > > >
>> > > > > >> > > > > > I tend to agree with Maksim here, let's keep it
>> simple
>> > and
>> > > > > >> > explicit.
>> > > > > >> > > > > > Log a warning, but don't do anything clever.
>> > > > > >> > > > > >
>> > > > > >> > > > > > On Mon, Feb 7, 2022 at 6:15 PM Ivan Daschinsky <
>> > > > > >> > ivanda...@gmail.com>
>> > > > > >> > > > > > wrote:
>> > > > > >> > > > > >
>> > > > > >> > > > > > > >> idleTimeout already exists, I don't think we
>> should
>> > > > > change
>> > > > > >> the
>> > > > > >> > > way
>> > > > > >> > > > > it
>> > > > > >> > > > > > > works (or did I misunderstand you?)
>> > > > > >> > > > > > > If we use new approach, we can reduce this timeout.
>> > But
>> > > > this
>> > > > > >> can
>> > > > > >> > > > affect
>> > > > > >> > > > > > old
>> > > > > >> > > > > > > clients.
>> > > > > >> > > > > > >
>> > > > > >> > > > > > >
>> > > > > >> > > > > > > Also, let's think about that sending heartbeats and
>> > > > interval
>> > > > > >> of
>> > > > > >> > > > sending
>> > > > > >> > > > > > > heartbeats could be calculated on the server side
>> > (i.e.
>> > > > one
>> > > > > >> third
>> > > > > >> > > of
>> > > > > >> > > > > idle
>> > > > > >> > > > > > > timeout) and sent to the client
>> > > > > >> > > > > > > during handshake.
>> > > > > >> > > > > > > Also we can introduce something like a negotiation
>> > > > mechanism
>> > > > > >> as
>> > > > > >> > in
>> > > > > >> > > > > > > zookeeper.
>> > > > > >> > > > > > >
>> > > > > >> > > > > > >
>> > > > > >> > > > > > > пн, 7 февр. 2022 г. в 18:05, Pavel Tupitsyn <
>> > > > > >> > ptupit...@apache.org
>> > > > > >> > > >:
>> > > > > >> > > > > > >
>> > > > > >> > > > > > > > Igor,
>> > > > > >> > > > > > > >
>> > > > > >> > > > > > > > > Maybe clients should pass this information on
>> to
>> > the
>> > > > > >> > handshake.
>> > > > > >> > > > > > > >
>> > > > > >> > > > > > > > Do you think we should log a mismatched timeout
>> > > warning
>> > > > on
>> > > > > >> the
>> > > > > >> > > > > server,
>> > > > > >> > > > > > > not
>> > > > > >> > > > > > > > on the client?
>> > > > > >> > > > > > > > Or should we do both?
>> > > > > >> > > > > > > >
>> > > > > >> > > > > > > >
>> > > > > >> > > > > > > > I've updated the proposal with
>> OP_GET_IDLE_TIMEOUT
>> > and
>> > > > > some
>> > > > > >> > other
>> > > > > >> > > > > > details
>> > > > > >> > > > > > > > discussed above.
>> > > > > >> > > > > > > >
>> > > > > >> > > > > > > > On Mon, Feb 7, 2022 at 5:42 PM Igor Sapego <
>> > > > > >> isap...@apache.org
>> > > > > >> > >
>> > > > > >> > > > > wrote:
>> > > > > >> > > > > > > >
>> > > > > >> > > > > > > > > Feature seems useful for me as it makes
>> connection
>> > > > > >> management
>> > > > > >> > > > more
>> > > > > >> > > > > > > robust
>> > > > > >> > > > > > > > > and
>> > > > > >> > > > > > > > > predictable.
>> > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > I agree with Pavel, that we should print
>> warning
>> > > when
>> > > > > >> > heartbeat
>> > > > > >> > > > > > period
>> > > > > >> > > > > > > is
>> > > > > >> > > > > > > > > larger than
>> > > > > >> > > > > > > > > idle timeout, but I see a problem here as idle
>> > > timeout
>> > > > > is
>> > > > > >> > > > > configured
>> > > > > >> > > > > > on
>> > > > > >> > > > > > > > > server and is not
>> > > > > >> > > > > > > > > known to clients, while heartbeats configured
>> on
>> > > > clients
>> > > > > >> and
>> > > > > >> > > > their
>> > > > > >> > > > > > > period
>> > > > > >> > > > > > > > > is not known
>> > > > > >> > > > > > > > > to the server. Maybe clients should pass this
>> > > > > information
>> > > > > >> on
>> > > > > >> > to
>> > > > > >> > > > the
>> > > > > >> > > > > > > > > handshake.
>> > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > Regarding Python and PHP clients - can not we
>> use
>> > > some
>> > > > > >> kind
>> > > > > >> > of
>> > > > > >> > > > > timers
>> > > > > >> > > > > > > to
>> > > > > >> > > > > > > > > implement
>> > > > > >> > > > > > > > > this feature?
>> > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > Best Regards,
>> > > > > >> > > > > > > > > Igor
>> > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > On Mon, Feb 7, 2022 at 5:23 PM Pavel Tupitsyn <
>> > > > > >> > > > > ptupit...@apache.org>
>> > > > > >> > > > > > > > > wrote:
>> > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > Maksim, agree. Let's not be too clever and
>> only
>> > > log
>> > > > a
>> > > > > >> > > warning.
>> > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > On Mon, Feb 7, 2022 at 5:23 PM Pavel
>> Tupitsyn <
>> > > > > >> > > > > > ptupit...@apache.org>
>> > > > > >> > > > > > > > > > wrote:
>> > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > > Ivan, idleTimeout already exists, I don't
>> > think
>> > > we
>> > > > > >> should
>> > > > > >> > > > > change
>> > > > > >> > > > > > > the
>> > > > > >> > > > > > > > > way
>> > > > > >> > > > > > > > > > > it works (or did I misunderstand you?)
>> > > > > >> > > > > > > > > > >
>> > > > > >> > > > > > > > > > > Of course, enabling heartbeats means that
>> > > > otherwise
>> > > > > >> idle
>> > > > > >> > > > > clients
>> > > > > >> > > > > > > will
>> > > > > >> > > > > > > > > no
>> > > > > >> > > > > > > > > > > longer be disconnected by the server.
>> > > > > >> > > > > > > > > > > I think we should cross-link those
>> properties
>> > in
>> > > > the
>> > > > > >> > > > > > documentation
>> > > > > >> > > > > > > > and
>> > > > > >> > > > > > > > > > > explain this behavior.
>> > > > > >> > > > > > > > > > >
>> > > > > >> > > > > > > > > > > On Mon, Feb 7, 2022 at 4:39 PM Ivan
>> > Daschinsky <
>> > > > > >> > > > > > > ivanda...@gmail.com>
>> > > > > >> > > > > > > > > > > wrote:
>> > > > > >> > > > > > > > > > >
>> > > > > >> > > > > > > > > > >> >>3. Already implemented: when
>> > > > > >> > > > > > > > > ClientConnectorConfiguration#idleTimeout
>> > > > > >> > > > > > > > > > is
>> > > > > >> > > > > > > > > > >> not zero, server disconnects idle clients
>> > > > > >> > > > > > > > > > >> >>
>> > > > > >> > > > > > > > > > >> But I suppose it would be great to have:
>> > > > > >> > > > > > > > > > >> 1. If client supports keep alive, use
>> > > idleTimeout
>> > > > > >> > > > > > > > > > >> 2. If not, do not use it.
>> > > > > >> > > > > > > > > > >>
>> > > > > >> > > > > > > > > > >> But I am not sure if it is correct or not.
>> > > > > >> > > > > > > > > > >>
>> > > > > >> > > > > > > > > > >> пн, 7 февр. 2022 г. в 16:01, Maksim
>> Timonin <
>> > > > > >> > > > > > > > timoninma...@apache.org
>> > > > > >> > > > > > > > > >:
>> > > > > >> > > > > > > > > > >>
>> > > > > >> > > > > > > > > > >> > I believe explicit is better than
>> implicit
>> > :)
>> > > > > Also
>> > > > > >> in
>> > > > > >> > > case
>> > > > > >> > > > > of
>> > > > > >> > > > > > > > > dynamic
>> > > > > >> > > > > > > > > > >> > calculation of timeout, it can change
>> > > > > dynamically,
>> > > > > >> for
>> > > > > >> > > > > example
>> > > > > >> > > > > > > > > > >> restarting a
>> > > > > >> > > > > > > > > > >> > cluster with different configuration
>> should
>> > > > > >> > reconfigure
>> > > > > >> > > > > > clients
>> > > > > >> > > > > > > > too.
>> > > > > >> > > > > > > > > > >> Looks
>> > > > > >> > > > > > > > > > >> > complicated.
>> > > > > >> > > > > > > > > > >> >
>> > > > > >> > > > > > > > > > >> > My vote for WARN + javadocs with
>> mention of
>> > > > this
>> > > > > >> > issue.
>> > > > > >> > > > > > > > > > >> >
>> > > > > >> > > > > > > > > > >> > On Mon, Feb 7, 2022 at 3:51 PM Pavel
>> > > Tupitsyn <
>> > > > > >> > > > > > > > ptupit...@apache.org
>> > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > >> > wrote:
>> > > > > >> > > > > > > > > > >> >
>> > > > > >> > > > > > > > > > >> > > > WDYT, should we add a WARN message
>> for
>> > > > > clients
>> > > > > >> > that
>> > > > > >> > > > > > > configure
>> > > > > >> > > > > > > > > > >> > > > keepAliveTimeout greater than
>> > idleTimeout
>> > > > on
>> > > > > >> the
>> > > > > >> > > > server
>> > > > > >> > > > > > > side?
>> > > > > >> > > > > > > > > > >> > >
>> > > > > >> > > > > > > > > > >> > > I think we should either log a WARN,
>> or
>> > > > > retrieve
>> > > > > >> > > > > idleTimeout
>> > > > > >> > > > > > > > from
>> > > > > >> > > > > > > > > > >> server
>> > > > > >> > > > > > > > > > >> > > and configure heartbeatTimeout
>> > accordingly
>> > > > > (e.g.
>> > > > > >> > > divide
>> > > > > >> > > > by
>> > > > > >> > > > > > 2).
>> > > > > >> > > > > > > > > > >> > > Thoughts?
>> > > > > >> > > > > > > > > > >> > >
>> > > > > >> > > > > > > > > > >> > > On Mon, Feb 7, 2022 at 3:14 PM Maksim
>> > > > Timonin <
>> > > > > >> > > > > > > > > > >> timoninma...@apache.org>
>> > > > > >> > > > > > > > > > >> > > wrote:
>> > > > > >> > > > > > > > > > >> > >
>> > > > > >> > > > > > > > > > >> > > > Hi Pavel,
>> > > > > >> > > > > > > > > > >> > > >
>> > > > > >> > > > > > > > > > >> > > > Thanks for the links. Yes, I forgot
>> > that
>> > > > the
>> > > > > >> flag
>> > > > > >> > of
>> > > > > >> > > > > > changed
>> > > > > >> > > > > > > > > > >> topology
>> > > > > >> > > > > > > > > > >> > is
>> > > > > >> > > > > > > > > > >> > > > lazy. Also I missed that the
>> keepAlive
>> > > > > setting
>> > > > > >> is
>> > > > > >> > > > > > configured
>> > > > > >> > > > > > > > on
>> > > > > >> > > > > > > > > > the
>> > > > > >> > > > > > > > > > >> > > client
>> > > > > >> > > > > > > > > > >> > > > side (alternatively to idleTimeout
>> that
>> > > is
>> > > > on
>> > > > > >> the
>> > > > > >> > > > server
>> > > > > >> > > > > > > > side).
>> > > > > >> > > > > > > > > > >> > > >
>> > > > > >> > > > > > > > > > >> > > > Now I understand, this feature can
>> be
>> > > > helpful
>> > > > > >> > then.
>> > > > > >> > > > > Every
>> > > > > >> > > > > > > > client
>> > > > > >> > > > > > > > > > can
>> > > > > >> > > > > > > > > > >> > > > configure itself in case it's
>> possible
>> > to
>> > > > be
>> > > > > >> idle
>> > > > > >> > > > > > sometimes,
>> > > > > >> > > > > > > > and
>> > > > > >> > > > > > > > > > >> choose
>> > > > > >> > > > > > > > > > >> > > > an appropriate timeout by itself
>> too.
>> > And
>> > > > by
>> > > > > >> > default
>> > > > > >> > > > the
>> > > > > >> > > > > > > > feature
>> > > > > >> > > > > > > > > > >> should
>> > > > > >> > > > > > > > > > >> > > be
>> > > > > >> > > > > > > > > > >> > > > disabled.
>> > > > > >> > > > > > > > > > >> > > >
>> > > > > >> > > > > > > > > > >> > > > WDYT, should we add a WARN message
>> for
>> > > > > clients
>> > > > > >> > that
>> > > > > >> > > > > > > configure
>> > > > > >> > > > > > > > > > >> > > > keepAliveTimeout greater than
>> > idleTimeout
>> > > > on
>> > > > > >> the
>> > > > > >> > > > server
>> > > > > >> > > > > > > side?
>> > > > > >> > > > > > > > > > >> > > >
>> > > > > >> > > > > > > > > > >> > > >
>> > > > > >> > > > > > > > > > >> > > >
>> > > > > >> > > > > > > > > > >> > > > On Mon, Feb 7, 2022 at 1:05 PM Pavel
>> > > > > Tupitsyn <
>> > > > > >> > > > > > > > > > ptupit...@apache.org
>> > > > > >> > > > > > > > > > >> >
>> > > > > >> > > > > > > > > > >> > > > wrote:
>> > > > > >> > > > > > > > > > >> > > >
>> > > > > >> > > > > > > > > > >> > > > > Ivan,
>> > > > > >> > > > > > > > > > >> > > > >
>> > > > > >> > > > > > > > > > >> > > > > I suggest the following:
>> > > > > >> > > > > > > > > > >> > > > >
>> > > > > >> > > > > > > > > > >> > > > > 1. Server sends KEEP_ALIVE feature
>> > > flag,
>> > > > > >> which
>> > > > > >> > > means
>> > > > > >> > > > > it
>> > > > > >> > > > > > > > > accepts
>> > > > > >> > > > > > > > > > >> > > > > OP_KEEP_ALIVE empty message
>> > > > > >> > > > > > > > > > >> > > > > 2. Client sends OP_KEEP_ALIVE when
>> > the
>> > > > > >> > connection
>> > > > > >> > > is
>> > > > > >> > > > > > idle
>> > > > > >> > > > > > > > for
>> > > > > >> > > > > > > > > a
>> > > > > >> > > > > > > > > > >> > > > > certain period of time
>> > > > > >> > > > > > > > > > >> > > > > 3. Already implemented: when
>> > > > > >> > > > > > > > > > >> ClientConnectorConfiguration#idleTimeout
>> > > > > >> > > > > > > > > > >> > > is
>> > > > > >> > > > > > > > > > >> > > > > not zero, server disconnects idle
>> > > clients
>> > > > > >> > > > > > > > > > >> > > > >
>> > > > > >> > > > > > > > > > >> > > > > This way we don't need
>> server->client
>> > > > > >> > keepalives,
>> > > > > >> > > as
>> > > > > >> > > > > you
>> > > > > >> > > > > > > > > > correctly
>> > > > > >> > > > > > > > > > >> > > noted.
>> > > > > >> > > > > > > > > > >> > > > >
>> > > > > >> > > > > > > > > > >> > > > > On Mon, Feb 7, 2022 at 12:43 PM
>> Ivan
>> > > > > >> Daschinsky
>> > > > > >> > <
>> > > > > >> > > > > > > > > > >> ivanda...@gmail.com
>> > > > > >> > > > > > > > > > >> > >
>> > > > > >> > > > > > > > > > >> > > > > wrote:
>> > > > > >> > > > > > > > > > >> > > > >
>> > > > > >> > > > > > > > > > >> > > > > > Pavel, I suppose that ideally:
>> > > > > >> > > > > > > > > > >> > > > > > 1. Client send in handshake
>> flag,
>> > > that
>> > > > it
>> > > > > >> > > supports
>> > > > > >> > > > > > > > > KEEP_ALIVE
>> > > > > >> > > > > > > > > > >> > feature
>> > > > > >> > > > > > > > > > >> > > > and
>> > > > > >> > > > > > > > > > >> > > > > > server takes it into account.
>> > > > > >> > > > > > > > > > >> > > > > > 2. Each request of client can be
>> > > > > >> considered as
>> > > > > >> > > > > > > keep-alive
>> > > > > >> > > > > > > > > > ping.
>> > > > > >> > > > > > > > > > >> > > > > > 3. Client send failure should be
>> > > > > processed
>> > > > > >> > using
>> > > > > >> > > > > retry
>> > > > > >> > > > > > > > > policy.
>> > > > > >> > > > > > > > > > >> > > > > > 4. Server should not send
>> > keep-alive
>> > > > > >> packets,
>> > > > > >> > it
>> > > > > >> > > > is
>> > > > > >> > > > > > > > > redundant,
>> > > > > >> > > > > > > > > > >> but
>> > > > > >> > > > > > > > > > >> > > > server
>> > > > > >> > > > > > > > > > >> > > > > > should track requests from
>> client
>> > and
>> > > > if
>> > > > > >> there
>> > > > > >> > > is
>> > > > > >> > > > no
>> > > > > >> > > > > > > > > requests
>> > > > > >> > > > > > > > > > >> from
>> > > > > >> > > > > > > > > > >> > > > client
>> > > > > >> > > > > > > > > > >> > > > > > with KEEP_ALIVE feature,
>> > > > > >> > > > > > > > > > >> > > > > > automatically close connection
>> and
>> > > free
>> > > > > >> > > resources.
>> > > > > >> > > > > > > > > > >> > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > Similar approach is used in
>> > zookeeper
>> > > > > >> clients.
>> > > > > >> > > > > > > > > > >> > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > пн, 7 февр. 2022 г. в 12:24,
>> Pavel
>> > > > > >> Tupitsyn <
>> > > > > >> > > > > > > > > > >> ptupit...@apache.org
>> > > > > >> > > > > > > > > > >> > >:
>> > > > > >> > > > > > > > > > >> > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > Ivan,
>> > > > > >> > > > > > > > > > >> > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > Ideally, the check should come
>> > from
>> > > > > both
>> > > > > >> > > sides.
>> > > > > >> > > > > > > > > > >> > > > > > > - Client periodically sends
>> > > keepalive
>> > > > > to
>> > > > > >> > > server
>> > > > > >> > > > > > > > > > >> > > > > > > - Server periodically sends
>> > > keepalive
>> > > > > to
>> > > > > >> > > client
>> > > > > >> > > > > > > > > > >> > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > Feature flags will be added
>> > > > > accordingly,
>> > > > > >> so
>> > > > > >> > it
>> > > > > >> > > > is
>> > > > > >> > > > > > not
>> > > > > >> > > > > > > > > > >> necessary
>> > > > > >> > > > > > > > > > >> > to
>> > > > > >> > > > > > > > > > >> > > > > > > implement this in all thin
>> > clients.
>> > > > > >> > > > > > > > > > >> > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > On Mon, Feb 7, 2022 at 11:43
>> AM
>> > > Ivan
>> > > > > >> > > Daschinsky
>> > > > > >> > > > <
>> > > > > >> > > > > > > > > > >> > > ivanda...@gmail.com
>> > > > > >> > > > > > > > > > >> > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > wrote:
>> > > > > >> > > > > > > > > > >> > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > I suppose it is great idea,
>> but
>> > > > this
>> > > > > >> > > > > functionality
>> > > > > >> > > > > > > can
>> > > > > >> > > > > > > > > be
>> > > > > >> > > > > > > > > > >> hard
>> > > > > >> > > > > > > > > > >> > to
>> > > > > >> > > > > > > > > > >> > > > > > > implement
>> > > > > >> > > > > > > > > > >> > > > > > > > for some platforms. I.e.
>> sync
>> > > > python
>> > > > > >> > client
>> > > > > >> > > or
>> > > > > >> > > > > php
>> > > > > >> > > > > > > > > (there
>> > > > > >> > > > > > > > > > >> is no
>> > > > > >> > > > > > > > > > >> > > > real
>> > > > > >> > > > > > > > > > >> > > > > > > > multithreading for python
>> (GIL)
>> > > and
>> > > > > >> php is
>> > > > > >> > > > > single
>> > > > > >> > > > > > > > > threaded
>> > > > > >> > > > > > > > > > >> by
>> > > > > >> > > > > > > > > > >> > > > > design).
>> > > > > >> > > > > > > > > > >> > > > > > > But
>> > > > > >> > > > > > > > > > >> > > > > > > > for async clients it is not
>> > very
>> > > > hard
>> > > > > >> to
>> > > > > >> > > > > > implement.
>> > > > > >> > > > > > > > > > >> > Nevertheless,
>> > > > > >> > > > > > > > > > >> > > > > this
>> > > > > >> > > > > > > > > > >> > > > > > > > feature should be optional,
>> > > because
>> > > > > of
>> > > > > >> > > > possible
>> > > > > >> > > > > > > > > technical
>> > > > > >> > > > > > > > > > >> > > > > limitations.
>> > > > > >> > > > > > > > > > >> > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > Pavel, is this check mostly
>> for
>> > > > > client
>> > > > > >> > side?
>> > > > > >> > > > Or
>> > > > > >> > > > > > > > servers
>> > > > > >> > > > > > > > > > can
>> > > > > >> > > > > > > > > > >> do
>> > > > > >> > > > > > > > > > >> > > some
>> > > > > >> > > > > > > > > > >> > > > > > > actions
>> > > > > >> > > > > > > > > > >> > > > > > > > if there is no activity from
>> > thin
>> > > > > >> client
>> > > > > >> > > (i.e.
>> > > > > >> > > > > > > closing
>> > > > > >> > > > > > > > > > >> context
>> > > > > >> > > > > > > > > > >> > > and
>> > > > > >> > > > > > > > > > >> > > > > free
>> > > > > >> > > > > > > > > > >> > > > > > > > resources such as queries'
>> > > handles
>> > > > > and
>> > > > > >> so
>> > > > > >> > > on?)
>> > > > > >> > > > > > > > > > >> > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > пн, 7 февр. 2022 г. в 11:09,
>> > > Pavel
>> > > > > >> > Tupitsyn
>> > > > > >> > > <
>> > > > > >> > > > > > > > > > >> > > ptupit...@apache.org
>> > > > > >> > > > > > > > > > >> > > > >:
>> > > > > >> > > > > > > > > > >> > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > Hi Maksim,
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > > half-state is a possible
>> > > > > situation
>> > > > > >> > when
>> > > > > >> > > an
>> > > > > >> > > > > > > Ignite
>> > > > > >> > > > > > > > > node
>> > > > > >> > > > > > > > > > >> goes
>> > > > > >> > > > > > > > > > >> > > > down
>> > > > > >> > > > > > > > > > >> > > > > or
>> > > > > >> > > > > > > > > > >> > > > > > > > > somehow removes connection
>> > to a
>> > > > > thin
>> > > > > >> > > client
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > Half-open state is also
>> > > possible
>> > > > > >> when,
>> > > > > >> > for
>> > > > > >> > > > > > > example,
>> > > > > >> > > > > > > > an
>> > > > > >> > > > > > > > > > >> > > > intermediate
>> > > > > >> > > > > > > > > > >> > > > > > > > router
>> > > > > >> > > > > > > > > > >> > > > > > > > > is rebooted [1].
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > This is what we seem to
>> have
>> > > > > >> encountered
>> > > > > >> > > > with
>> > > > > >> > > > > > one
>> > > > > >> > > > > > > of
>> > > > > >> > > > > > > > > our
>> > > > > >> > > > > > > > > > >> > > > customers
>> > > > > >> > > > > > > > > > >> > > > > -
>> > > > > >> > > > > > > > > > >> > > > > > > they
>> > > > > >> > > > > > > > > > >> > > > > > > > > have a stable cluster, and
>> > > > > >> long-living
>> > > > > >> > > > > (multiple
>> > > > > >> > > > > > > > days)
>> > > > > >> > > > > > > > > > >> thin
>> > > > > >> > > > > > > > > > >> > > > client
>> > > > > >> > > > > > > > > > >> > > > > > > > > connections which can be
>> idle
>> > > for
>> > > > > >> some
>> > > > > >> > > time.
>> > > > > >> > > > > > > > > > >> > > > > > > > > And only when we send some
>> > data
>> > > > on
>> > > > > >> such
>> > > > > >> > an
>> > > > > >> > > > > idle
>> > > > > >> > > > > > > > > > >> connection do
>> > > > > >> > > > > > > > > > >> > > we
>> > > > > >> > > > > > > > > > >> > > > > > > discover
>> > > > > >> > > > > > > > > > >> > > > > > > > > that it is broken.
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > > But with enabled (true
>> by
>> > > > > default)
>> > > > > >> > > > > > > > > partitionAwareness
>> > > > > >> > > > > > > > > > >> > feature
>> > > > > >> > > > > > > > > > >> > > > > > clients
>> > > > > >> > > > > > > > > > >> > > > > > > > can
>> > > > > >> > > > > > > > > > >> > > > > > > > > be notified about topology
>> > > > changes
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > Partition awareness is a
>> > "lazy"
>> > > > > >> > > notification
>> > > > > >> > > > > in
>> > > > > >> > > > > > a
>> > > > > >> > > > > > > > form
>> > > > > >> > > > > > > > > > of
>> > > > > >> > > > > > > > > > >> a
>> > > > > >> > > > > > > > > > >> > > > > response
>> > > > > >> > > > > > > > > > >> > > > > > > > > message flag [2].
>> > > > > >> > > > > > > > > > >> > > > > > > > > You won't get one on an
>> idle
>> > > > > >> connection.
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > > the connections are
>> removed
>> > > on
>> > > > > the
>> > > > > >> > > server
>> > > > > >> > > > > side
>> > > > > >> > > > > > > by
>> > > > > >> > > > > > > > > > client
>> > > > > >> > > > > > > > > > >> > idle
>> > > > > >> > > > > > > > > > >> > > > > > timeout
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > Idle timeout is disabled
>> by
>> > > > > default.
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > > is it OK to keep such
>> > > > connections
>> > > > > >> > alive
>> > > > > >> > > > for
>> > > > > >> > > > > a
>> > > > > >> > > > > > > long
>> > > > > >> > > > > > > > > > time
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > I think it is up to the
>> user.
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > > in the case of partition
>> > > > > awareness
>> > > > > >> > > > features
>> > > > > >> > > > > it
>> > > > > >> > > > > > > can
>> > > > > >> > > > > > > > > > lead
>> > > > > >> > > > > > > > > > >> to
>> > > > > >> > > > > > > > > > >> > > > > wasting
>> > > > > >> > > > > > > > > > >> > > > > > > TCP
>> > > > > >> > > > > > > > > > >> > > > > > > > > sockets on Ignite nodes,
>> > can't
>> > > it
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > Can you please elaborate?
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > [1]
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > >
>> > > > > >> > > > > > > > > > >> > > > >
>> > > > > >> > > > > > > > > > >> > > >
>> > > > > >> > > > > > > > > > >> > >
>> > > > > >> > > > > > > > > > >> >
>> > > > > >> > > > > > > > > > >>
>> > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > >
>> > > > > >> > > > > > > >
>> > > > > >> > > > > > >
>> > > > > >> > > > > >
>> > > > > >> > > > >
>> > > > > >> > > >
>> > > > > >> > >
>> > > > > >> >
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>> https://blog.stephencleary.com/2009/05/detection-of-half-open-dropped.html
>> > > > > >> > > > > > > > > > >> > > > > > > > > [2]
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > >
>> > > > > >> > > > > > > > > > >> > > > >
>> > > > > >> > > > > > > > > > >> > > >
>> > > > > >> > > > > > > > > > >> > >
>> > > > > >> > > > > > > > > > >> >
>> > > > > >> > > > > > > > > > >>
>> > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > >
>> > > > > >> > > > > > > >
>> > > > > >> > > > > > >
>> > > > > >> > > > > >
>> > > > > >> > > > >
>> > > > > >> > > >
>> > > > > >> > >
>> > > > > >> >
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+Thin+Clients
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > On Fri, Feb 4, 2022 at
>> 4:01
>> > PM
>> > > > > Maksim
>> > > > > >> > > > Timonin
>> > > > > >> > > > > <
>> > > > > >> > > > > > > > > > >> > > > > > timoninma...@apache.org
>> > > > > >> > > > > > > > > > >> > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > wrote:
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > > Hi Pavel,
>> > > > > >> > > > > > > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > > Thanks for starting this
>> > > > thread!
>> > > > > >> Can I
>> > > > > >> > > ask
>> > > > > >> > > > > > some
>> > > > > >> > > > > > > > > > >> questions
>> > > > > >> > > > > > > > > > >> > > here
>> > > > > >> > > > > > > > > > >> > > > to
>> > > > > >> > > > > > > > > > >> > > > > > get
>> > > > > >> > > > > > > > > > >> > > > > > > > the
>> > > > > >> > > > > > > > > > >> > > > > > > > > > feature more clearly?
>> > > > > >> > > > > > > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > > As I understand it
>> > correctly,
>> > > > > >> > half-state
>> > > > > >> > > > is
>> > > > > >> > > > > a
>> > > > > >> > > > > > > > > possible
>> > > > > >> > > > > > > > > > >> > > > situation
>> > > > > >> > > > > > > > > > >> > > > > > when
>> > > > > >> > > > > > > > > > >> > > > > > > > an
>> > > > > >> > > > > > > > > > >> > > > > > > > > > Ignite node goes down or
>> > > > somehow
>> > > > > >> > removes
>> > > > > >> > > > > > > > connection
>> > > > > >> > > > > > > > > > to a
>> > > > > >> > > > > > > > > > >> > thin
>> > > > > >> > > > > > > > > > >> > > > > > client.
>> > > > > >> > > > > > > > > > >> > > > > > > > But
>> > > > > >> > > > > > > > > > >> > > > > > > > > > with enabled (true by
>> > > default)
>> > > > > >> > > > > > > partitionAwareness
>> > > > > >> > > > > > > > > > >> feature
>> > > > > >> > > > > > > > > > >> > > > clients
>> > > > > >> > > > > > > > > > >> > > > > > can
>> > > > > >> > > > > > > > > > >> > > > > > > > be
>> > > > > >> > > > > > > > > > >> > > > > > > > > > notified about topology
>> > > > changes.
>> > > > > >> So,
>> > > > > >> > > there
>> > > > > >> > > > > are
>> > > > > >> > > > > > > > > > possible
>> > > > > >> > > > > > > > > > >> > > cases:
>> > > > > >> > > > > > > > > > >> > > > > > > > > > 1. ThinClient connects
>> to a
>> > > > > single
>> > > > > >> > node.
>> > > > > >> > > > > > > > > > >> > > > > > > > > > 2. Ignite node removes
>> > > > connection
>> > > > > >> from
>> > > > > >> > > > > itself.
>> > > > > >> > > > > > > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > > I like the idea for the
>> > case
>> > > > > with a
>> > > > > >> > > single
>> > > > > >> > > > > > node,
>> > > > > >> > > > > > > > as
>> > > > > >> > > > > > > > > it
>> > > > > >> > > > > > > > > > >> > helps
>> > > > > >> > > > > > > > > > >> > > > fail
>> > > > > >> > > > > > > > > > >> > > > > > > fast.
>> > > > > >> > > > > > > > > > >> > > > > > > > > > But is it OK to connect
>> a
>> > > > client
>> > > > > >> to a
>> > > > > >> > > > single
>> > > > > >> > > > > > > node
>> > > > > >> > > > > > > > > > only?
>> > > > > >> > > > > > > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > > For the second one: you
>> > > mention
>> > > > > >> that a
>> > > > > >> > > > case
>> > > > > >> > > > > > for
>> > > > > >> > > > > > > > the
>> > > > > >> > > > > > > > > > >> second
>> > > > > >> > > > > > > > > > >> > > > option
>> > > > > >> > > > > > > > > > >> > > > > > is
>> > > > > >> > > > > > > > > > >> > > > > > > > > > "Long-living and mostly
>> > idle
>> > > > > >> > connections
>> > > > > >> > > > are
>> > > > > >> > > > > > > > > > especially
>> > > > > >> > > > > > > > > > >> > > > > susceptible
>> > > > > >> > > > > > > > > > >> > > > > > > to
>> > > > > >> > > > > > > > > > >> > > > > > > > > this
>> > > > > >> > > > > > > > > > >> > > > > > > > > > behavior". If I
>> understand
>> > > > > >> correctly
>> > > > > >> > the
>> > > > > >> > > > > > > > connections
>> > > > > >> > > > > > > > > > are
>> > > > > >> > > > > > > > > > >> > > > removed
>> > > > > >> > > > > > > > > > >> > > > > on
>> > > > > >> > > > > > > > > > >> > > > > > > the
>> > > > > >> > > > > > > > > > >> > > > > > > > > > server side by client
>> idle
>> > > > > timeout.
>> > > > > >> > Can
>> > > > > >> > > we
>> > > > > >> > > > > > just
>> > > > > >> > > > > > > > > > >> configure
>> > > > > >> > > > > > > > > > >> > the
>> > > > > >> > > > > > > > > > >> > > > > idle
>> > > > > >> > > > > > > > > > >> > > > > > > > > timeout
>> > > > > >> > > > > > > > > > >> > > > > > > > > > for cases where we
>> really
>> > > need
>> > > > > >> keeping
>> > > > > >> > > > alive
>> > > > > >> > > > > > > idle
>> > > > > >> > > > > > > > > > >> > > connections?
>> > > > > >> > > > > > > > > > >> > > > > Are
>> > > > > >> > > > > > > > > > >> > > > > > > > there
>> > > > > >> > > > > > > > > > >> > > > > > > > > > any other cases with
>> > > > unexpectedly
>> > > > > >> > > dropped
>> > > > > >> > > > > > > > > connections?
>> > > > > >> > > > > > > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > > I'm wondering is it OK
>> to
>> > > keep
>> > > > > such
>> > > > > >> > > > > > connections
>> > > > > >> > > > > > > > > alive
>> > > > > >> > > > > > > > > > >> for a
>> > > > > >> > > > > > > > > > >> > > > long
>> > > > > >> > > > > > > > > > >> > > > > > > time?
>> > > > > >> > > > > > > > > > >> > > > > > > > > > Also in the case of
>> > partition
>> > > > > >> > awareness
>> > > > > >> > > > > > features
>> > > > > >> > > > > > > > it
>> > > > > >> > > > > > > > > > can
>> > > > > >> > > > > > > > > > >> > lead
>> > > > > >> > > > > > > > > > >> > > to
>> > > > > >> > > > > > > > > > >> > > > > > > wasting
>> > > > > >> > > > > > > > > > >> > > > > > > > > TCP
>> > > > > >> > > > > > > > > > >> > > > > > > > > > sockets on Ignite nodes,
>> > > can't
>> > > > > it?
>> > > > > >> > > > > > > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > > Thanks!
>> > > > > >> > > > > > > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > > On Thu, Feb 3, 2022 at
>> 2:24
>> > > PM
>> > > > > >> Pavel
>> > > > > >> > > > > Tupitsyn
>> > > > > >> > > > > > <
>> > > > > >> > > > > > > > > > >> > > > > > ptupit...@apache.org>
>> > > > > >> > > > > > > > > > >> > > > > > > > > > wrote:
>> > > > > >> > > > > > > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > > >> Igniters,
>> > > > > >> > > > > > > > > > >> > > > > > > > > >>
>> > > > > >> > > > > > > > > > >> > > > > > > > > >> Please review the
>> proposal
>> > > to
>> > > > > add
>> > > > > >> > > > heartbeat
>> > > > > >> > > > > > > > > messages
>> > > > > >> > > > > > > > > > to
>> > > > > >> > > > > > > > > > >> > the
>> > > > > >> > > > > > > > > > >> > > > thin
>> > > > > >> > > > > > > > > > >> > > > > > > > client
>> > > > > >> > > > > > > > > > >> > > > > > > > > >> protocol (both 2.x and
>> > 3.x)
>> > > > and
>> > > > > >> let
>> > > > > >> > me
>> > > > > >> > > > know
>> > > > > >> > > > > > > your
>> > > > > >> > > > > > > > > > >> thoughts:
>> > > > > >> > > > > > > > > > >> > > > > > > > > >>
>> > > > > >> > > > > > > > > > >> > > > > > > > > >>
>> > > > > >> > > > > > > > > > >> > > > > > > > > >>
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > >
>> > > > > >> > > > > > > > > > >> > > > >
>> > > > > >> > > > > > > > > > >> > > >
>> > > > > >> > > > > > > > > > >> > >
>> > > > > >> > > > > > > > > > >> >
>> > > > > >> > > > > > > > > > >>
>> > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > >
>> > > > > >> > > > > > > >
>> > > > > >> > > > > > >
>> > > > > >> > > > > >
>> > > > > >> > > > >
>> > > > > >> > > >
>> > > > > >> > >
>> > > > > >> >
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-83+Thin+Client+Keepalive
>> > > > > >> > > > > > > > > > >> > > > > > > > > >>
>> > > > > >> > > > > > > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > > > --
>> > > > > >> > > > > > > > > > >> > > > > > > > Sincerely yours, Ivan
>> > Daschinskiy
>> > > > > >> > > > > > > > > > >> > > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > >
>> > > > > >> > > > > > > > > > >> > > > > >
>> > > > > >> > > > > > > > > > >> > > > > >
>> > > > > >> > > > > > > > > > >> > > > > > --
>> > > > > >> > > > > > > > > > >> > > > > > Sincerely yours, Ivan
>> Daschinskiy
>> > > > > >> > > > > > > > > > >> > > > > >
>> > > > > >> > > > > > > > > > >> > > > >
>> > > > > >> > > > > > > > > > >> > > >
>> > > > > >> > > > > > > > > > >> > >
>> > > > > >> > > > > > > > > > >> >
>> > > > > >> > > > > > > > > > >>
>> > > > > >> > > > > > > > > > >>
>> > > > > >> > > > > > > > > > >> --
>> > > > > >> > > > > > > > > > >> Sincerely yours, Ivan Daschinskiy
>> > > > > >> > > > > > > > > > >>
>> > > > > >> > > > > > > > > > >
>> > > > > >> > > > > > > > > >
>> > > > > >> > > > > > > > >
>> > > > > >> > > > > > > >
>> > > > > >> > > > > > >
>> > > > > >> > > > > > >
>> > > > > >> > > > > > > --
>> > > > > >> > > > > > > Sincerely yours, Ivan Daschinskiy
>> > > > > >> > > > > > >
>> > > > > >> > > > > >
>> > > > > >> > > > >
>> > > > > >> > > > >
>> > > > > >> > > > > --
>> > > > > >> > > > > Sincerely yours, Ivan Daschinskiy
>> > > > > >> > > > >
>> > > > > >> > > >
>> > > > > >> > >
>> > > > > >> > >
>> > > > > >> > > --
>> > > > > >> > > Sincerely yours, Ivan Daschinskiy
>> > > > > >> > >
>> > > > > >> >
>> > > > > >>
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Sincerely yours, Ivan Daschinskiy
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
