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 >
