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 >
