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 > > >
