[GitHub] [ignite-nodejs-thin-client] ptupitsyn commented on a change in pull request #4: IGNITE-16490 Node.js: Fix API documentation main page
ptupitsyn commented on a change in pull request #4: URL: https://github.com/apache/ignite-nodejs-thin-client/pull/4#discussion_r801325319 ## File path: api_spec/index.md ## @@ -0,0 +1,9 @@ +# Node.js Client for Apache Ignite + +This thin client allows your Node.js applications to work with Ignite clusters via TCP. + +A thin client is a lightweight Ignite client that connects to the cluster via a standard socket connection. It does not start in JVM process (Java is not required at all), does not become a part of the cluster topology, never holds any data or used as a destination of compute grid calculations. + +What it does is it simply establishes a socket connection to a standard Ignite node and performs all operations through that node. + Review comment: Feels like the same thing is repeated 3 times here (TCP/socket connection/socket connection). A socket connection is how any DB driver works, do we need to put it here at all? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@ignite.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: decorrelate before subquery removing
Hello, Flag expand=false is required to support some types of subqueries. But we can also perform decorrelation explicitly after subquery rewriting. I've filled the ticket [1]. Thank you! [1]: https://issues.apache.org/jira/browse/IGNITE-16493 сб, 5 февр. 2022 г. в 14:50, Chang Chen : > Hi All > > > IIUC, the current implementation may be problematic. > > Ignite disabled subquery rewriting in this PR( > https://github.com/apache/ignite/pull/9251), and I think the correct > process would be sqlnode => relnode => convert RexSubQuery to Correlate => > decorrelateQuery, however, the last two steps are inverse in the current > implementation. See PlannerHelper#optimize. > > > >1. IgnitePlanner#rel will be called first, and >SqlToRelConverter#decorrelate will be called in this function. >2. Then, HEP_DECORRELATE will be called. The rules of this phase are all >subquery removing(i.e. convert RexSubQuery to Correlate). > > > Although IgniteCorrelatedNestedLoopJoin could be used to implement > LogicalCorrelate, this is inefficient. >
Ignite Summit 2022: The Call for Papers is Open!
Hi, Igniters! Hosted by GridGain Systems with the Apache Software Foundation as a Community Partner, Ignite Summit[1] was the biggest community event in 2021[2][3]. And we will meet again on June 14, 2022, to shine the spotlight on Apache Ignite! The idea is to share architectural best practices from Ignite users' experience, meet Ignite developers, and develop expertise. The event is virtual and free of charge. We are now accepting proposals for 30-minutes talks and 15-minutes lightning talks: - Apache Ignite user story - An Ignite architectural deep dive - The experience of integrating Apache Ignite with other technologies - The use of Apache Ignite in a cloud environment - Apache Ignite monitoring and troubleshooting Please submit your proposal via https://sessionize.com/IgniteSummit-2022 before April 29. You can help to promote Summit by sharing a Twitter[4] or LinkedIn[5] post. Also, join the LinkedIn event[6] to receive the updates. If you have any questions about attending or speaking at the Summit, I would be happy to answer. Cheers, Kseniya [1] https://ignite-summit.org [2] Ignite Summit 2021 recordings https://www.youtube.com/playlist?list=PLMc7NR20hA-KF8c_hVICKpzKnWkjzfC2V [3]Ignite Summit 2021: Cloud Edition recordings https://www.youtube.com/playlist?list=PLMc7NR20hA-JvgLWtvp2R9tEnD5vlp9l0 [4]https://twitter.com/ApacheIgnite/status/1490741175548002314 [5]https://www.linkedin.com/feed/update/urn:li:activity:6896497935580770304 [6] https://www.linkedin.com/events/6896527308195528704/about/
A new feedback has been added : 60
A new feedback has been added, go to bugyard.io to see all the details... https://bugyard.io A new feedback has been added "DUDS Account verification. How to reverse SHell ANY/ALL mainframes through illegal immigration loopholes. DONE" by ianjoe83 View feedback https://app.bugyard.io/web/app/rycqZJDyY/f/61fd653a454f870014303db5
Re: IEP-83 Thin Client Keepalive (heartbeat)
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 : > > 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 > 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 : > > > > > 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 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 > > > > 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
Re: IEP-83 Thin Client Keepalive (heartbeat)
> 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 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 : > > > 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 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 > > > 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 > > > > 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
Re: IEP-83 Thin Client Keepalive (heartbeat)
>> 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 : > 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 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 > > 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 > > > 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 > > > > 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
Re: IEP-83 Thin Client Keepalive (heartbeat)
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 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 > 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 > > 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 > > > 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 >: > > >> > > >> > 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 > > > >> > 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
Re: IEP-83 Thin Client Keepalive (heartbeat)
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 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 > 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 > > 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 : > >> > >> > 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 > >> > 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
Re: IEP-83 Thin Client Keepalive (heartbeat)
Maksim, agree. Let's not be too clever and only log a warning. On Mon, Feb 7, 2022 at 5:23 PM Pavel Tupitsyn 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 > 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 : >> >> > 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 >> > 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 > > >> > > > 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,
Re: IEP-83 Thin Client Keepalive (heartbeat)
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 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 : > > > 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 > > 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 > > > > 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 > > > > 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.
Re: IEP-83 Thin Client Keepalive (heartbeat)
>>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 : > 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 > 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 > > 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 > > > 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 > > > > > 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 >: > > > > > > > > > > > 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 > > >
Re: IEP-83 Thin Client Keepalive (heartbeat)
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 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 > 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 > > 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 > > > 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 : > > > > > > > > > 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 > > >
Re: IEP-83 Thin Client Keepalive (heartbeat)
> 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 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 > 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 > > 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 : > > > > > > > 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 > > > > > 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 >: > > > > > > > > > > > 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]
Re: IEP-83 Thin Client Keepalive (heartbeat)
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 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 > 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 : > > > > > 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 > > > 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 : > > > > > > > > > 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,
Re: Travis service is not working properly
Folks, Let's vote for the issue [1], I wish this may help to solve the problem faster. [1] https://issues.apache.org/jira/browse/INFRA-22827 On Fri, Feb 4, 2022 at 2:31 PM Anton Vinogradov wrote: > >> Should I add this info for the INFRA ticket? > Please do > > On Fri, Feb 4, 2022 at 1:52 PM Maksim Timonin > wrote: > >> Hi, I have a similar issue for my PR [1]: >> >> 1. Github shows that the previous commit check is not completed yet. But >> on >> Travis' side I see that it actually has already finished [2]. >> 2. There is a new commit after the previous and Travis ignores it and >> doesn't schedule a new build. >> >> Should I add this info for the INFRA ticket? >> >> [1] https://github.com/apache/ignite/pull/9788 >> [2] https://app.travis-ci.com/github/apache/ignite/builds/245860409 >> >> >> >> On Wed, Feb 2, 2022 at 5:42 PM Anton Vinogradov wrote: >> >> > Asked the INFRA [1] >> > >> > [1] https://issues.apache.org/jira/browse/INFRA-22827 >> > >> > On Wed, Feb 2, 2022 at 5:29 PM Anton Vinogradov wrote: >> > >> > > Igniters, >> > > >> > > Seems the Travis service is not working properly. >> > > For example, it never checked my PR [1], any ideas why? >> > > >> > > Who knows how to fix it? >> > > >> > > [1] https://github.com/apache/ignite/pull/9661 >> > > >> > >> >
Re: IEP-83 Thin Client Keepalive (heartbeat)
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 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 : > > > 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 > > 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 : > > > > > > > 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
Re: IEP-83 Thin Client Keepalive (heartbeat)
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 : > 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 > 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 : > > > > > 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 > > > > 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 > > > > 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: > > > >> > > > >>
Re: IEP-83 Thin Client Keepalive (heartbeat)
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 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 : > > > 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 > > 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 > > > 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 >
Re: [DISCUSSION] Shmem removal.
Patch is ready for review пт, 4 февр. 2022 г. в 14:45, Ivan Daschinsky : > https://issues.apache.org/jira/browse/IGNITE-16480 -- I've filed ticked. > > пт, 7 янв. 2022 г. в 23:44, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > >> Doesn't look like there are any objections - it's been a month since you >> started this thread. Let's create a ticket. >> >> -Val >> >> >> On Thu, Jan 6, 2022 at 1:22 AM Ivan Daschinsky >> wrote: >> >> > Hi, Val. My plan was to file a specific ticket after discussion. If the >> > community agrees that this module should be removed, I will file a >> specific >> > ticket for it. >> > >> > ср, 5 янв. 2022 г., 22:26 Valentin Kulichenko < >> > valentin.kuliche...@gmail.com >> > >: >> > >> > > Hi Ivan, >> > > >> > > Do we have a ticket for this? >> > > >> > > -Val >> > > >> > > On Fri, Dec 3, 2021 at 10:58 AM Valentin Kulichenko < >> > > valentin.kuliche...@gmail.com> wrote: >> > > >> > > > I think we can safely remove it. >> > > > >> > > > -Val >> > > > >> > > > On Thu, Dec 2, 2021 at 11:52 PM Ivan Daschinsky < >> ivanda...@gmail.com> >> > > > wrote: >> > > > >> > > >> Hi, igniters. >> > > >> >> > > >> Recently I've discovered one fact >> > > >> 1. GridShmemCommunicationClient and all shmem functionality are >> broken >> > > >> since 2.10. In master it is broken since August 2020. And nobody >> have >> > > >> noticed it, only one thread in user list. >> > > >> 2. We have source code for native JNI library (that is shipped in >> > > >> ignite-shmem.jar), but we never built it since 2015. >> > > >> 3. This code is of questionable quality, contains outdated internal >> > gcc >> > > >> api >> > > >> (__sync builtins, now deprecated in favour of __atomic builtins in >> gcc >> > > and >> > > >> is not advisable to use since C++ 11). It contains a lot of >> autotool >> > > mess, >> > > >> while just one CMakeFile.txt is enough to build the same >> > > >> 4. This code doesn't even compile on modern gcc (gcc 9.3.0 namely) >> > > >> >> > > >> We have 2 options >> > > >> 1. If this concept is useful, we (for example I can do it) should >> > > rewrite >> > > >> native part, >> > > >> a. Use C++ 11 and header-only boost.interprocess [1] >> > > >> b. Build it regularly with CMake and incorporate build in regular >> TC >> > > runs >> > > >> (via maven-cmake-plugin, >> > > >> see for example my numa-allocator [2]). >> > > >> 2. If this concept and functionality is not useful, we should >> remove >> > it, >> > > >> may be even in 2.12 >> > > >> >> > > >> >> > > >> [1] -- >> > https://www.boost.org/doc/libs/1_77_0/doc/html/interprocess.html >> > > >> [2] -- >> > > >> >> > > >> >> > > >> > >> https://github.com/apache/ignite/pull/9569/files#diff-77baf2378aa83911a8c3091814db3ff60b7bf328c4ab4850f707717ed96f3d92 >> > > >> -- >> > > >> Sincerely yours, Ivan Daschinskiy >> > > >> >> > > > >> > > >> > >> > > > -- > Sincerely yours, Ivan Daschinskiy > -- Sincerely yours, Ivan Daschinskiy
Re: IEP-83 Thin Client Keepalive (heartbeat)
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 : > 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 > 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 > > 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
Re: IEP-83 Thin Client Keepalive (heartbeat)
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 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 > 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 >> >
