[DISCUSSION] Redis and memcached protocol support.
Igniters, I'd like to discuss the future of this functionality in Apache Ignite Today this functionality seems to be unusable 1. It is limited (especially redis) 2. It doesn't support HA (redis sentinel or redis cluster) 3. Nobody maintains it and even nobody fixes bugs. (i.e. [1] is not merged for years). If we want to support redis protocol, we should rewrite it and add HA features. Otherwise, I suppose that we should consider complete removal of this code from codebase. WDYT? [1] -- https://issues.apache.org/jira/browse/IGNITE-7153
Apache Ignite 2.13 RELEASE [Time, Scope, Manager]
Dear Ignite Community! I suggest starting Apache Ignite 2.13 release activities. There is a plan to merge the new Calcite SQL engine. [1] I think that 2.13 is a good candidate for it. Moreover, we've accumulated a hundred resolved [2] issues with new features and bug fixes which are waiting for their release date. For example, BinaryArray introduced, Read Repair strategies implemented, CPP Thin: asynchronous network events handling, NUMA-aware allocator for data regions etc. I want to propose myself to be the release manager of the planning release. I propose the following timeline: Scope Freeze: February 21, 2022 Code Freeze: March 7, 2022 Voting Date: March 21, 2022 Release Date: March 28, 2022 WDYT? [1] https://issues.apache.org/jira/browse/IGNITE-15436 [2] https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.13%27))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)%20ORDER%20BY%20priority -- Best wishes, Amelchev Nikita
Re: [DISCUSSION] Shmem removal.
Patch has been reviewed by Andrey Mashenkov and Max Muzafarov and approved. If nobody disagrees, I will merge it in a few hours. пн, 7 февр. 2022 г. в 12:21, Ivan Daschinsky : > 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 > -- Sincerely yours, Ivan Daschinskiy
[GitHub] [ignite-nodejs-thin-client] asfgit closed pull request #4: IGNITE-16490 Node.js: Fix API documentation main page
asfgit closed pull request #4: URL: https://github.com/apache/ignite-nodejs-thin-client/pull/4 -- 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
[GitHub] [ignite-nodejs-thin-client] isapego commented on a change in pull request #4: IGNITE-16490 Node.js: Fix API documentation main page
isapego commented on a change in pull request #4: URL: https://github.com/apache/ignite-nodejs-thin-client/pull/4#discussion_r801366727 ## 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: You are right. Fixed. -- 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
Looks like it useful remark, thanks ! 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.
