Re: Getting started
Hi Charles, Welcome to Apache Ignite Community! I added your JIRA account to the contributor list. A following page can help you to start https://ignite.apache.org/community/contribute.html Feel free to write a message to dev@ignite.apache.org if you need any assistance. 2020-09-15 3:28 GMT+03:00, Charles Fonseca : > Hello you all! > > I am Charles, 19 years old, Java/Kotlin developer, I'm new to open source. > I would like to take any kind of task in order to know the project > better, as I am looking for a topic of interest. My Jira user is 'barddoo'. > > Best Regards, > Charles Fonseca. > -- Best regards, Ivan Pavlukhin
Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]
Alexey, We've benchmarked the whole set of tests tonight in both persistent and in-memory modes on the current 2.9 branch (with minor tracing optimization merged). And on our environment, we've got 0-2.5% drop for each benchmark compared to 2.8.1. I think it is an acceptable result. So, I'm ok with keeping the message factory as is and fix the regression in the next release. Guys, WDYT? пн, 14 сент. 2020 г. в 12:41, Alexey Goncharuk : > Alexey, Andrey, Igniters, > > So what do you think? Should we proceed with a 'hacked' version of the > message factory in 2.9 and go for the runtime message generation in later > release, or keep the code clean and fix the regression in the next > releases? > Andrey, can you take a look at my change? I think it is fairly > straightforward and does not change the semantics, just skips the factory > closures for certain messages. > > Personally, I would prefer fixing the regression given that we also > introduced tracing in this release. > > > > пт, 11 сент. 2020 г. в 12:09, Alex Plehanov : > >> Alexey, >> >> We've benchmarked by yardstick commits 130376741bf vs ed52559eb95 and the >> performance of ed52559eb95 is better for about 2.5% on average on our >> environment (about the same results we got benchmarking 65c30ec6 vs >> 0606f03d). We've made 24 runs for each commit of >> IgnitePutTxImplicitBenchmark (we got maximum drop for 2.9 on this >> benchmark), 200 seconds warmup, 300 seconds benchmark, 6 servers, 5 clients >> 50 threads each. Yardstick results for this configuration: >> Commit 130376741bf: avg TPS=164096, avg latency=9173464 ns >> Commit ed52559eb95: avg TPS=168283, avg latency=8945908 ns >> >> пт, 11 сент. 2020 г. в 09:51, Artem Budnikov > >: >> >>> Hi Everyone, >>> >>> I posted an instruction on how to publish the docs on >>> ignite.apache.org/docs [1]. When you finish with Ignite 2.9, you can >>> update the docs by following the instruction. Unfortunately, I won't be >>> able to spend any time on this project any longer. You can send your pull >>> requests and questions about the documentation to Denis Magda. >>> >>> -Artem >>> >>> [1] : https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document >>> >>> On Thu, Sep 10, 2020 at 2:45 PM Alexey Goncharuk < >>> alexey.goncha...@gmail.com> wrote: >>> Alexey, I've tried to play with message factories locally, but unfortunately, I cannot spot the difference between old and new implementation in distributed benchmarks. I pushed an implementation of MessageFactoryImpl with the old switch statement to the ignite-2.9-revert-12568 branch (discussed this with Andrey Gura, the change should be compatible with the new metrics as we still use the register() mechanics). Can you check if this change makes any difference performance-wise in your environment? If yes, we can go with runtime code generation in the long term: register classes and generate a dynamic message factory with a switch statement once all messages are registered (not in 2.9 though, obviously). ср, 9 сент. 2020 г. в 14:53, Alex Plehanov : > Hello guys, > > I've tried to optimize tracing implementation (ticket [1]), it reduced the > drop, but not completely removed it. > Ivan Rakov, Alexander Lapin, can you please review the patch? > Ivan Artiukhov, can you please benchmark the patch [2] against 2.8.1 > release on your environment? > With this patch on our environment, it's about a 3% drop left, it's close > to measurement error and I think such a drop is not a showstopper. Guys, > WDYT? > > Also, I found that compatibility is broken for JDBC thin driver between 2.8 > and 2.9 versions (ticket [3]). I think it's a blocker and should be > fixed in 2.9. I've prepared the patch. > Taras Ledkov, can you please review this patch? > > And one more ticket I propose to include into 2.9 [4] (NIO message > send problem in some circumstances). I will cherry-pick it if there is no > objection. > > [1] https://issues.apache.org/jira/browse/IGNITE-13411 > [2] https://github.com/apache/ignite/pull/8223 > [3] https://issues.apache.org/jira/browse/IGNITE-13414 > [4] https://issues.apache.org/jira/browse/IGNITE-13361 > > пн, 7 сент. 2020 г. в 14:14, Maxim Muzafarov : > > > Alexey, > > > > I propose to include [1] issue to the 2.9 release. Since this issue is > > related to the new master key change functionality which haven't been > > released yet I think it will be safe to cherry-pick commit to the > > release branch. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13390 > > > > On Tue, 1 Sep 2020 at 12:13, Nikolay Izhikov > wrote: > > > > > > Hello, Igniters. > > > > > > Alexey, please, include one more Python thin cl
Re: Thin Client ping operation?
Personally I believe that public API still can be helpful, as it gives user an ability to check connection in the specific point in time, even if automatic ping is implemented (which is more complex and hard-to-maintain feature by the way). Not sure there should be "ping" in API though, maybe something more like client.checkConnection(); Best Regards, Igor On Mon, Sep 14, 2020 at 11:37 AM Alex Plehanov wrote: > Hello guys, > > We've already raised the question about ping requests here [1]. > > I'm not sure about public API, but at least we can have auto-ping as an > internal mechanism. This will be helpful if the client doesn't send any new > requests but only waits for server-side notifications (for example, if the > client subscribed to CQ events). The client can't detect a connection lost > until sending something to the server. Using periodic ping requests this > problem can be solved. > > So, +1 to add ping to the protocol, +0 to expose it to public API. > > [1] > > http://apache-ignite-developers.2346864.n4.nabble.com/IEP-44-Thin-Client-Discovery-tp47129p47318.html > > пн, 14 сент. 2020 г. в 10:32, Pavel Tupitsyn : > > > Nikolay, > > > > See the discussion on the user list: > > > > 1. It is not immediately obvious which APIs perform server calls and > which > > don't. > > 2. It is not clear which APIs can cause heavy resource usage on the > server > > side. > > We don't want to stress servers by pinging them. > > cache.size() is an example - it is tempting to use and seems to be > > simple, but actually queries every server node in the cluster. > > > > > dedicated `ping` operation makes our API heavier > > The operation is so trivial that I would not worry about increased > > complexity or future maintenance. > > > > On Mon, Sep 14, 2020 at 10:17 AM Nikolay Izhikov > > wrote: > > > > > Hello, Igor. > > > > > > On the other hand, dedicated `ping` operation makes our API heavier > > > without adding new feature - > > > We can do the same with the other part of the API. > > > > > > Moreover, response to the ping doesn’t mean that SQL or cache query can > > be > > > served. > > > > > > > 14 сент. 2020 г., в 10:08, Igor Sapego > > написал(а): > > > > > > > > Николай, > > > > > > > > It looks a little bit hacky to me. I believe SQL drivers usually use > > that > > > > approach > > > > as a workaround because there is no other common way to do that. > > > > > > > > Sure we can recommend users to use cache.size() or anything other > > > > similar way > > > > to ensure the connection is alive, but it still looks like a > workaround > > > to > > > > me. > > > > > > > > Best Regards, > > > > Igor > > > > > > > > > > > > On Sun, Sep 13, 2020 at 10:16 PM Николай Ижиков > > > > wrote: > > > > > > > >> Hello, Pavel. > > > >> > > > >> SQL drivers usually use “SELECT 1” query to ensure connection is > > alive. > > > >> > > > >> Can we use similar approach? > > > >> > > > >> Отправлено с iPhone > > > >> > > > >>> 13 сент. 2020 г., в 13:26, Pavel Tupitsyn > > > >> написал(а): > > > >>> > > > >>> Igniters, > > > >>> > > > >>> There is a feature request for a thin client Ping operation on the > > user > > > >>> list [1]. > > > >>> I think that is a good idea - IgniteClient.ping() will be a > valuable > > > >>> addition. > > > >>> > > > >>> Any objections? > > > >>> > > > >>> [1] > > > >>> > > > >> > > > > > > http://apache-ignite-users.70518.x6.nabble.com/Feature-request-method-to-test-active-connection-in-Ignite-thin-client-td33985.html > > > >> > > > > > > > > >
[MTCGA]: new failures in builds [5600915, 5599346] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New Critical Failure in master Cache (Restarts) 1 https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_CacheRestarts1?branch=%3Cdefault%3E No changes in the build *New Critical Failure in master-nightly Disk Page Compressions https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_DiskPageCompressions?branch=%3Cdefault%3E No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 12:22:06 15-09-2020
Re[2]: Thin Client ping operation?
Whats the usage of such API ? Igor can you clarify please ? >Personally I believe that public API still can be helpful, as it gives user >an ability to check connection in the specific point in time, even if >automatic >ping is implemented (which is more complex and hard-to-maintain feature >by the way). > >Not sure there should be "ping" in API though, maybe something more like >client.checkConnection(); > >Best Regards, >Igor > > >On Mon, Sep 14, 2020 at 11:37 AM Alex Plehanov < plehanov.a...@gmail.com > >wrote: > >> Hello guys, >> >> We've already raised the question about ping requests here [1]. >> >> I'm not sure about public API, but at least we can have auto-ping as an >> internal mechanism. This will be helpful if the client doesn't send any new >> requests but only waits for server-side notifications (for example, if the >> client subscribed to CQ events). The client can't detect a connection lost >> until sending something to the server. Using periodic ping requests this >> problem can be solved. >> >> So, +1 to add ping to the protocol, +0 to expose it to public API. >> >> [1] >> >> >> http://apache-ignite-developers.2346864.n4.nabble.com/IEP-44-Thin-Client-Discovery-tp47129p47318.html >> >> пн, 14 сент. 2020 г. в 10:32, Pavel Tupitsyn < ptupit...@apache.org >: >> >> > Nikolay, >> > >> > See the discussion on the user list: >> > >> > 1. It is not immediately obvious which APIs perform server calls and >> which >> > don't. >> > 2. It is not clear which APIs can cause heavy resource usage on the >> server >> > side. >> > We don't want to stress servers by pinging them. >> > cache.size() is an example - it is tempting to use and seems to be >> > simple, but actually queries every server node in the cluster. >> > >> > > dedicated `ping` operation makes our API heavier >> > The operation is so trivial that I would not worry about increased >> > complexity or future maintenance. >> > >> > On Mon, Sep 14, 2020 at 10:17 AM Nikolay Izhikov < nizhi...@apache.org > >> > wrote: >> > >> > > Hello, Igor. >> > > >> > > On the other hand, dedicated `ping` operation makes our API heavier >> > > without adding new feature - >> > > We can do the same with the other part of the API. >> > > >> > > Moreover, response to the ping doesn’t mean that SQL or cache query can >> > be >> > > served. >> > > >> > > > 14 сент. 2020 г., в 10:08, Igor Sapego < isap...@apache.org > >> > написал(а): >> > > > >> > > > Николай, >> > > > >> > > > It looks a little bit hacky to me. I believe SQL drivers usually use >> > that >> > > > approach >> > > > as a workaround because there is no other common way to do that. >> > > > >> > > > Sure we can recommend users to use cache.size() or anything other >> > > > similar way >> > > > to ensure the connection is alive, but it still looks like a >> workaround >> > > to >> > > > me. >> > > > >> > > > Best Regards, >> > > > Igor >> > > > >> > > > >> > > > On Sun, Sep 13, 2020 at 10:16 PM Николай Ижиков < nizhi...@apache.org >> > >> > > wrote: >> > > > >> > > >> Hello, Pavel. >> > > >> >> > > >> SQL drivers usually use “SELECT 1” query to ensure connection is >> > alive. >> > > >> >> > > >> Can we use similar approach? >> > > >> >> > > >> Отправлено с iPhone >> > > >> >> > > >>> 13 сент. 2020 г., в 13:26, Pavel Tupitsyn < ptupit...@apache.org > >> > > >> написал(а): >> > > >>> >> > > >>> Igniters, >> > > >>> >> > > >>> There is a feature request for a thin client Ping operation on the >> > user >> > > >>> list [1]. >> > > >>> I think that is a good idea - IgniteClient.ping() will be a >> valuable >> > > >>> addition. >> > > >>> >> > > >>> Any objections? >> > > >>> >> > > >>> [1] >> > > >>> >> > > >> >> > > >> > >> >> http://apache-ignite-users.70518.x6.nabble.com/Feature-request-method-to-test-active-connection-in-Ignite-thin-client-td33985.html >> > > >> >> > > >> > > >> > >>
Escaping dots in cache metric names
Hi, guys! Cache names may contain dots, but in metic names we create hierarchy with dots. So with the cache name "Person.statistic" we will have a metric "io.statistics.sortedIndexes.SQL_PUBLIC_Person.statistic._key_PK" which is not obvious what is a cache name and what is next hierarchical element. I suggest replacing dots with the special symbol during metrics names construction.
Re: Escaping dots in cache metric names
Hello! This seems suspiciously similar to https://issues.apache.org/jira/browse/IGNITE-7264 Maybe we need to restrict cache names after all. Regards, -- Ilya Kasnacheev вт, 15 сент. 2020 г. в 13:49, Alex Kozhenkov : > Hi, guys! > > Cache names may contain dots, but in metic names we create hierarchy with > dots. > So with the cache name "Person.statistic" we will have a metric > "io.statistics.sortedIndexes.SQL_PUBLIC_Person.statistic._key_PK" which is > not obvious what is a cache name and what is next hierarchical element. > > I suggest replacing dots with the special symbol during metrics names > construction. >
Re: Re[2]: Thin Client ping operation?
> Whats the usage of such API Health checks are the primary use case. See linked user list thread. On Tue, Sep 15, 2020 at 12:26 PM Zhenya Stanilovsky wrote: > > Whats the usage of such API ? Igor can you clarify please ? > > >Personally I believe that public API still can be helpful, as it gives > user > >an ability to check connection in the specific point in time, even if > >automatic > >ping is implemented (which is more complex and hard-to-maintain feature > >by the way). > > > >Not sure there should be "ping" in API though, maybe something more like > >client.checkConnection(); > > > >Best Regards, > >Igor > > > > > >On Mon, Sep 14, 2020 at 11:37 AM Alex Plehanov < plehanov.a...@gmail.com > > > >wrote: > > > >> Hello guys, > >> > >> We've already raised the question about ping requests here [1]. > >> > >> I'm not sure about public API, but at least we can have auto-ping as an > >> internal mechanism. This will be helpful if the client doesn't send any > new > >> requests but only waits for server-side notifications (for example, if > the > >> client subscribed to CQ events). The client can't detect a connection > lost > >> until sending something to the server. Using periodic ping requests this > >> problem can be solved. > >> > >> So, +1 to add ping to the protocol, +0 to expose it to public API. > >> > >> [1] > >> > >> > http://apache-ignite-developers.2346864.n4.nabble.com/IEP-44-Thin-Client-Discovery-tp47129p47318.html > >> > >> пн, 14 сент. 2020 г. в 10:32, Pavel Tupitsyn < ptupit...@apache.org >: > >> > >> > Nikolay, > >> > > >> > See the discussion on the user list: > >> > > >> > 1. It is not immediately obvious which APIs perform server calls and > >> which > >> > don't. > >> > 2. It is not clear which APIs can cause heavy resource usage on the > >> server > >> > side. > >> > We don't want to stress servers by pinging them. > >> > cache.size() is an example - it is tempting to use and seems to be > >> > simple, but actually queries every server node in the cluster. > >> > > >> > > dedicated `ping` operation makes our API heavier > >> > The operation is so trivial that I would not worry about increased > >> > complexity or future maintenance. > >> > > >> > On Mon, Sep 14, 2020 at 10:17 AM Nikolay Izhikov < > nizhi...@apache.org > > >> > wrote: > >> > > >> > > Hello, Igor. > >> > > > >> > > On the other hand, dedicated `ping` operation makes our API heavier > >> > > without adding new feature - > >> > > We can do the same with the other part of the API. > >> > > > >> > > Moreover, response to the ping doesn’t mean that SQL or cache query > can > >> > be > >> > > served. > >> > > > >> > > > 14 сент. 2020 г., в 10:08, Igor Sapego < isap...@apache.org > > >> > написал(а): > >> > > > > >> > > > Николай, > >> > > > > >> > > > It looks a little bit hacky to me. I believe SQL drivers usually > use > >> > that > >> > > > approach > >> > > > as a workaround because there is no other common way to do that. > >> > > > > >> > > > Sure we can recommend users to use cache.size() or anything other > >> > > > similar way > >> > > > to ensure the connection is alive, but it still looks like a > >> workaround > >> > > to > >> > > > me. > >> > > > > >> > > > Best Regards, > >> > > > Igor > >> > > > > >> > > > > >> > > > On Sun, Sep 13, 2020 at 10:16 PM Николай Ижиков < > nizhi...@apache.org > >> > > >> > > wrote: > >> > > > > >> > > >> Hello, Pavel. > >> > > >> > >> > > >> SQL drivers usually use “SELECT 1” query to ensure connection is > >> > alive. > >> > > >> > >> > > >> Can we use similar approach? > >> > > >> > >> > > >> Отправлено с iPhone > >> > > >> > >> > > >>> 13 сент. 2020 г., в 13:26, Pavel Tupitsyn < > ptupit...@apache.org > > >> > > >> написал(а): > >> > > >>> > >> > > >>> Igniters, > >> > > >>> > >> > > >>> There is a feature request for a thin client Ping operation on > the > >> > user > >> > > >>> list [1]. > >> > > >>> I think that is a good idea - IgniteClient.ping() will be a > >> valuable > >> > > >>> addition. > >> > > >>> > >> > > >>> Any objections? > >> > > >>> > >> > > >>> [1] > >> > > >>> > >> > > >> > >> > > > >> > > >> > http://apache-ignite-users.70518.x6.nabble.com/Feature-request-method-to-test-active-connection-in-Ignite-thin-client-td33985.html > >> > > >> > >> > > > >> > > > >> > > >> > > > >
Re[4]: Thin Client ping operation?
Pavel, i read whole thread, show me the reason why this functionality need to be external ? > > >Health checks are the primary use case. See linked user list thread. > >On Tue, Sep 15, 2020 at 12:26 PM Zhenya Stanilovsky >< arzamas...@mail.ru.invalid > wrote: > >> >> Whats the usage of such API ? Igor can you clarify please ? >> >> >Personally I believe that public API still can be helpful, as it gives >> user >> >an ability to check connection in the specific point in time, even if >> >automatic >> >ping is implemented (which is more complex and hard-to-maintain feature >> >by the way). >> > >> >Not sure there should be "ping" in API though, maybe something more like >> >client.checkConnection(); >> > >> >Best Regards, >> >Igor >> > >> > >> >On Mon, Sep 14, 2020 at 11:37 AM Alex Plehanov < plehanov.a...@gmail.com >> > >> >wrote: >> > >> >> Hello guys, >> >> >> >> We've already raised the question about ping requests here [1]. >> >> >> >> I'm not sure about public API, but at least we can have auto-ping as an >> >> internal mechanism. This will be helpful if the client doesn't send any >> new >> >> requests but only waits for server-side notifications (for example, if >> the >> >> client subscribed to CQ events). The client can't detect a connection >> lost >> >> until sending something to the server. Using periodic ping requests this >> >> problem can be solved. >> >> >> >> So, +1 to add ping to the protocol, +0 to expose it to public API. >> >> >> >> [1] >> >> >> >> >> >> http://apache-ignite-developers.2346864.n4.nabble.com/IEP-44-Thin-Client-Discovery-tp47129p47318.html >> >> >> >> пн, 14 сент. 2020 г. в 10:32, Pavel Tupitsyn < ptupit...@apache.org >: >> >> >> >> > Nikolay, >> >> > >> >> > See the discussion on the user list: >> >> > >> >> > 1. It is not immediately obvious which APIs perform server calls and >> >> which >> >> > don't. >> >> > 2. It is not clear which APIs can cause heavy resource usage on the >> >> server >> >> > side. >> >> > We don't want to stress servers by pinging them. >> >> > cache.size() is an example - it is tempting to use and seems to be >> >> > simple, but actually queries every server node in the cluster. >> >> > >> >> > > dedicated `ping` operation makes our API heavier >> >> > The operation is so trivial that I would not worry about increased >> >> > complexity or future maintenance. >> >> > >> >> > On Mon, Sep 14, 2020 at 10:17 AM Nikolay Izhikov < >> nizhi...@apache.org > >> >> > wrote: >> >> > >> >> > > Hello, Igor. >> >> > > >> >> > > On the other hand, dedicated `ping` operation makes our API heavier >> >> > > without adding new feature - >> >> > > We can do the same with the other part of the API. >> >> > > >> >> > > Moreover, response to the ping doesn’t mean that SQL or cache query >> can >> >> > be >> >> > > served. >> >> > > >> >> > > > 14 сент. 2020 г., в 10:08, Igor Sapego < isap...@apache.org > >> >> > написал(а): >> >> > > > >> >> > > > Николай, >> >> > > > >> >> > > > It looks a little bit hacky to me. I believe SQL drivers usually >> use >> >> > that >> >> > > > approach >> >> > > > as a workaround because there is no other common way to do that. >> >> > > > >> >> > > > Sure we can recommend users to use cache.size() or anything other >> >> > > > similar way >> >> > > > to ensure the connection is alive, but it still looks like a >> >> workaround >> >> > > to >> >> > > > me. >> >> > > > >> >> > > > Best Regards, >> >> > > > Igor >> >> > > > >> >> > > > >> >> > > > On Sun, Sep 13, 2020 at 10:16 PM Николай Ижиков < >> nizhi...@apache.org >> >> > >> >> > > wrote: >> >> > > > >> >> > > >> Hello, Pavel. >> >> > > >> >> >> > > >> SQL drivers usually use “SELECT 1” query to ensure connection is >> >> > alive. >> >> > > >> >> >> > > >> Can we use similar approach? >> >> > > >> >> >> > > >> Отправлено с iPhone >> >> > > >> >> >> > > >>> 13 сент. 2020 г., в 13:26, Pavel Tupitsyn < >> ptupit...@apache.org > >> >> > > >> написал(а): >> >> > > >>> >> >> > > >>> Igniters, >> >> > > >>> >> >> > > >>> There is a feature request for a thin client Ping operation on >> the >> >> > user >> >> > > >>> list [1]. >> >> > > >>> I think that is a good idea - IgniteClient.ping() will be a >> >> valuable >> >> > > >>> addition. >> >> > > >>> >> >> > > >>> Any objections? >> >> > > >>> >> >> > > >>> [1] >> >> > > >>> >> >> > > >> >> >> > > >> >> > >> >> >> >> http://apache-ignite-users.70518.x6.nabble.com/Feature-request-method-to-test-active-connection-in-Ignite-thin-client-td33985.html >> >> > > >> >> >> > > >> >> > > >> >> > >> >> >> >> >> >>
Re: Escaping dots in cache metric names
Yeah, that would be even better for all cases. вт, 15 сент. 2020 г. в 15:51, Ilya Kasnacheev : > Hello! > > This seems suspiciously similar to > https://issues.apache.org/jira/browse/IGNITE-7264 > > Maybe we need to restrict cache names after all. > > Regards, > -- > Ilya Kasnacheev > > > вт, 15 сент. 2020 г. в 13:49, Alex Kozhenkov : > > > Hi, guys! > > > > Cache names may contain dots, but in metic names we create hierarchy with > > dots. > > So with the cache name "Person.statistic" we will have a metric > > "io.statistics.sortedIndexes.SQL_PUBLIC_Person.statistic._key_PK" which > is > > not obvious what is a cache name and what is next hierarchical element. > > > > I suggest replacing dots with the special symbol during metrics names > > construction. > > >
Re: Escaping dots in cache metric names
Hello, Alex. We can’t restrict dot in the cache name because it will break backward compatibility of Ignite. > 15 сент. 2020 г., в 16:38, Alex Kozhenkov написал(а): > > Yeah, that would be even better for all cases. > > вт, 15 сент. 2020 г. в 15:51, Ilya Kasnacheev : > >> Hello! >> >> This seems suspiciously similar to >> https://issues.apache.org/jira/browse/IGNITE-7264 >> >> Maybe we need to restrict cache names after all. >> >> Regards, >> -- >> Ilya Kasnacheev >> >> >> вт, 15 сент. 2020 г. в 13:49, Alex Kozhenkov : >> >>> Hi, guys! >>> >>> Cache names may contain dots, but in metic names we create hierarchy with >>> dots. >>> So with the cache name "Person.statistic" we will have a metric >>> "io.statistics.sortedIndexes.SQL_PUBLIC_Person.statistic._key_PK" which >> is >>> not obvious what is a cache name and what is next hierarchical element. >>> >>> I suggest replacing dots with the special symbol during metrics names >>> construction. >>> >>
Re: Re[4]: Thin Client ping operation?
Zhenya, sure, let me explain. Health checks are a common practice in modern deployments, quote [1]: "Health probes can be used by container orchestrators and load balancers to check an app's status. For example, a container orchestrator may respond to a failing health check by halting a rolling deployment or restarting a container. A load balancer might react to an unhealthy app by routing traffic away from the failing instance to a healthy instance." Kubernetes has various probes [2] to determine the pod status. So Ignite users need a proper mechanism to determine connectivity status of the thin client to integrate with frameworks and orchestrators. [1] https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks [2] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ On Tue, Sep 15, 2020 at 4:36 PM Zhenya Stanilovsky wrote: > > > Pavel, i read whole thread, show me the reason why this functionality need > to be external ? > > > > > > >Health checks are the primary use case. See linked user list thread. > > > >On Tue, Sep 15, 2020 at 12:26 PM Zhenya Stanilovsky > >< arzamas...@mail.ru.invalid > wrote: > > > >> > >> Whats the usage of such API ? Igor can you clarify please ? > >> > >> >Personally I believe that public API still can be helpful, as it gives > >> user > >> >an ability to check connection in the specific point in time, even if > >> >automatic > >> >ping is implemented (which is more complex and hard-to-maintain feature > >> >by the way). > >> > > >> >Not sure there should be "ping" in API though, maybe something more > like > >> >client.checkConnection(); > >> > > >> >Best Regards, > >> >Igor > >> > > >> > > >> >On Mon, Sep 14, 2020 at 11:37 AM Alex Plehanov < > plehanov.a...@gmail.com > >> > > >> >wrote: > >> > > >> >> Hello guys, > >> >> > >> >> We've already raised the question about ping requests here [1]. > >> >> > >> >> I'm not sure about public API, but at least we can have auto-ping as > an > >> >> internal mechanism. This will be helpful if the client doesn't send > any > >> new > >> >> requests but only waits for server-side notifications (for example, > if > >> the > >> >> client subscribed to CQ events). The client can't detect a connection > >> lost > >> >> until sending something to the server. Using periodic ping requests > this > >> >> problem can be solved. > >> >> > >> >> So, +1 to add ping to the protocol, +0 to expose it to public API. > >> >> > >> >> [1] > >> >> > >> >> > >> > http://apache-ignite-developers.2346864.n4.nabble.com/IEP-44-Thin-Client-Discovery-tp47129p47318.html > >> >> > >> >> пн, 14 сент. 2020 г. в 10:32, Pavel Tupitsyn < ptupit...@apache.org > >: > >> >> > >> >> > Nikolay, > >> >> > > >> >> > See the discussion on the user list: > >> >> > > >> >> > 1. It is not immediately obvious which APIs perform server calls > and > >> >> which > >> >> > don't. > >> >> > 2. It is not clear which APIs can cause heavy resource usage on the > >> >> server > >> >> > side. > >> >> > We don't want to stress servers by pinging them. > >> >> > cache.size() is an example - it is tempting to use and seems to be > >> >> > simple, but actually queries every server node in the cluster. > >> >> > > >> >> > > dedicated `ping` operation makes our API heavier > >> >> > The operation is so trivial that I would not worry about increased > >> >> > complexity or future maintenance. > >> >> > > >> >> > On Mon, Sep 14, 2020 at 10:17 AM Nikolay Izhikov < > >> nizhi...@apache.org > > >> >> > wrote: > >> >> > > >> >> > > Hello, Igor. > >> >> > > > >> >> > > On the other hand, dedicated `ping` operation makes our API > heavier > >> >> > > without adding new feature - > >> >> > > We can do the same with the other part of the API. > >> >> > > > >> >> > > Moreover, response to the ping doesn’t mean that SQL or cache > query > >> can > >> >> > be > >> >> > > served. > >> >> > > > >> >> > > > 14 сент. 2020 г., в 10:08, Igor Sapego < isap...@apache.org > > >> >> > написал(а): > >> >> > > > > >> >> > > > Николай, > >> >> > > > > >> >> > > > It looks a little bit hacky to me. I believe SQL drivers > usually > >> use > >> >> > that > >> >> > > > approach > >> >> > > > as a workaround because there is no other common way to do > that. > >> >> > > > > >> >> > > > Sure we can recommend users to use cache.size() or anything > other > >> >> > > > similar way > >> >> > > > to ensure the connection is alive, but it still looks like a > >> >> workaround > >> >> > > to > >> >> > > > me. > >> >> > > > > >> >> > > > Best Regards, > >> >> > > > Igor > >> >> > > > > >> >> > > > > >> >> > > > On Sun, Sep 13, 2020 at 10:16 PM Николай Ижиков < > >> nizhi...@apache.org > >> >> > > >> >> > > wrote: > >> >> > > > > >> >> > > >> Hello, Pavel. > >> >> > > >> > >> >> > > >> SQL drivers usually use “SELECT 1” query to ensure connection > is > >> >> > alive. > >> >> > > >> > >> >> > > >> Can we use similar approach? > >> >> > > >> > >> >> > > >> Отправл
Re: [DISCUSSION] Add autocompletion for commands in control.sh
Hello, This idea looks great in my opinion. I agree that a more common approach would be better but I am the same as Kirill haven't found the better one. So in my point of view, this library is better than nothing, and if nobody will recommend a different one we can take picocli right now. -- Best regards, Anton Kalashnikov 14.09.2020, 13:15, "Данилов Семён" : > Hello! > > I've looked through the picocli manual and it looks really great. > We will be able easily add i18n and stuff like this. > Nevertheless, we will get rid of the manual formatting of examples and help > texts. > > Kind regards, > Semyon. > > 14.09.2020, 13:00, "Alexey Goncharuk" : >> Hi folks, >> >> Despite the autocompletion support only for bash, I see the following >> benefits from this change: >> * It may unify all the CLI tooliing in Ignite, providing a better user >> experience >> * The library has an ability to generate man pages, which may be nice >> * I see there is an open issue for adding support to powershell, so >> Windows platform will be also somewhat covered >> >> Overall, I support this idea. >> >> вт, 8 сент. 2020 г. в 10:43, ткаленко кирилл : >> >>> Hello, Ilya! >>> >>> I agree that it would be better if we found a common approach, but I >>> haven't found one yet. >>> >>> 07.09.2020, 18:50, "Ilya Kasnacheev" : >>> > Hello! >>> > >>> > Not everyone is using bash, which leads me to question whether there's >>> any >>> > common approach where we can hint a shell what our executable can do so >>> > that it can discover and auto-complete our control.sh >>> > >>> > Regards, >>> > -- >>> > Ilya Kasnacheev >>> > >>> > пн, 7 сент. 2020 г. в 17:47, ткаленко кирилл : >>> > >>> >> Hello, folks! >>> >> >>> >> I spent time to analyze the possibility of adding auto completion for >>> the >>> >> "control.sh" with the [1]. >>> >> >>> >> To do this, at the beginning, we need to adapt the "control.sh" code to >>> >> [1], then we can automatically create a "bash completion script" via >>> [2], >>> >> and then install it, for example, with the "source" command and the >>> >> "control.sh" script itself via "install". >>> >> >>> >> This is only possible for nix systems. >>> >> >>> >> It is theoretically possible to add the "control.sh" extension via >>> plugins >>> >> and auto-generate "bash completion script". >>> >> >>> >> Thus, I propose a plan: >>> >> 1)Adapt "control.sh" to [1]; >>> >> 2)Automatic creation of "bash completion script" for the release build; >>> >> 3)Adding extensibility "control.sh" and automatic re-creation of "bash >>> >> completion script". (optional) >>> >> >>> >> What do you think, comments? >>> >> >>> >> [1] - https://picocli.info/ >>> >> [2] - >>> >> >>> >>> https://picocli.info/autocomplete.html#_completion_script_generation_details
Re: Checkpoint refactoring(part of IEP-47)
Hello, I have finished the last checkpoint refactoring ticket(https://issues.apache.org/jira/browse/IGNITE-13207). In general, there are several new classes were created(it mostly extracted from GridDatabaseSharedManager). More detailed description you can find on the ticket. If somebody interested then they can take a look at pull-request and maybe suggest different class segregation. -- Best regards, Anton Kalashnikov 22.06.2020, 11:52, "Anton Kalashnikov" : > In fact, It is also one of my targets. I believe it will be possible when > checkpoint's classes will be restructured to smaller classes with more clear > responsibilities. So if everything goes good we can do it after step 3 which > I described above. > > -- > Best regards, > Anton Kalashnikov > > 19.06.2020, 17:28, "Ivan Pavlukhin" : >> Hi Anton, >> >> A side question. Do you feel that it is possible to cover extracted >> classes with unit tests (I mean unit tests which do not start Ignite >> nodes)? >> >> 2020-06-19 16:59 GMT+03:00, Anton Kalashnikov : >>> Hi Igniters, >>> >>> IEP-47(Native persistence defragmentation) contains a part that implies >>> refactoring of checkpoint(with the goal of reusing this feature in >>> defragmentation). >>> >>> I just to want to emphasize this part(refactoring) here and share my view >>> to >>> implementation >>> I want to split this job to at least 2(but maybe 3) separated tasks: >>> 1. Extracting checkpoint related classes from >>> GridCacheDatabaseSharedManager(ex. Checkpoint, Checkpointer, >>> WriteCheckpointPages, etc.) - >>> https://issues.apache.org/jira/browse/IGNITE-13151(almost done) >>> 2. Simplifying result code - I don't sure it is possible, but right now I >>> see some code which on the first eye has duplication and redundancy >>> 3. Reorganizing code - There is a lot of work which Checkpointer do right >>> now, I believe at least this class should be split. >>> >>> Perhaps, 2 and 3 items will be done in one ticket. >>> I believe you understand that I suggested several tickets instead of one >>> in >>> the target of simplification of review and find bugs. >>> >>> Any objections? >>> >>> -- >>> Best regards, >>> Anton Kalashnikov >> >> -- >> >> Best regards, >> Ivan Pavlukhin
Re[6]: Thin Client ping operation?
I understand now, thanks Pavel, initial discussion didn`t touch kuber theme ... >Вторник, 15 сентября 2020, 18:22 +03:00 от Pavel Tupitsyn >: > >Zhenya, sure, let me explain. > >Health checks are a common practice in modern deployments, quote [1]: >"Health probes can be used by container orchestrators and load balancers to >check an app's status. >For example, a container orchestrator may respond to a failing health check by >halting a rolling deployment or restarting a container. >A load balancer might react to an unhealthy app by routing traffic away from >the failing instance to a healthy instance." > >Kubernetes has various probes [2] to determine the pod status. > >So Ignite users need a proper mechanism to determine connectivity status of >the thin client >to integrate with frameworks and orchestrators. > >[1] https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks >[2] >https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ > >On Tue, Sep 15, 2020 at 4:36 PM Zhenya Stanilovsky < >arzamas...@mail.ru.invalid > wrote: > >>Pavel, i read whole thread, show me the reason why this functionality need to >>be external ? >> >>> >>> >>>Health checks are the primary use case. See linked user list thread. >>> >>>On Tue, Sep 15, 2020 at 12:26 PM Zhenya Stanilovsky >>>< arzamas...@mail.ru.invalid > wrote: >>> Whats the usage of such API ? Igor can you clarify please ? >Personally I believe that public API still can be helpful, as it gives user >an ability to check connection in the specific point in time, even if >automatic >ping is implemented (which is more complex and hard-to-maintain feature >by the way). > >Not sure there should be "ping" in API though, maybe something more like >client.checkConnection(); > >Best Regards, >Igor > > >On Mon, Sep 14, 2020 at 11:37 AM Alex Plehanov < plehanov.a...@gmail.com > >wrote: > >> Hello guys, >> >> We've already raised the question about ping requests here [1]. >> >> I'm not sure about public API, but at least we can have auto-ping as an >> internal mechanism. This will be helpful if the client doesn't send any new >> requests but only waits for server-side notifications (for example, if the >> client subscribed to CQ events). The client can't detect a connection lost >> until sending something to the server. Using periodic ping requests this >> problem can be solved. >> >> So, +1 to add ping to the protocol, +0 to expose it to public API. >> >> [1] >> >> http://apache-ignite-developers.2346864.n4.nabble.com/IEP-44-Thin-Client-Discovery-tp47129p47318.html >> >> пн, 14 сент. 2020 г. в 10:32, Pavel Tupitsyn < ptupit...@apache.org >: >> >> > Nikolay, >> > >> > See the discussion on the user list: >> > >> > 1. It is not immediately obvious which APIs perform server calls and >> which >> > don't. >> > 2. It is not clear which APIs can cause heavy resource usage on the >> server >> > side. >> > We don't want to stress servers by pinging them. >> > cache.size() is an example - it is tempting to use and seems to be >> > simple, but actually queries every server node in the cluster. >> > >> > > dedicated `ping` operation makes our API heavier >> > The operation is so trivial that I would not worry about increased >> > complexity or future maintenance. >> > >> > On Mon, Sep 14, 2020 at 10:17 AM Nikolay Izhikov < nizhi...@apache.org > >> > wrote: >> > >> > > Hello, Igor. >> > > >> > > On the other hand, dedicated `ping` operation makes our API heavier >> > > without adding new feature - >> > > We can do the same with the other part of the API. >> > > >> > > Moreover, response to the ping doesn’t mean that SQL or cache query can >> > be >> > > served. >> > > >> > > > 14 сент. 2020 г., в 10:08, Igor Sapego < isap...@apache.org > >> > написал(а): >> > > > >> > > > Николай, >> > > > >> > > > It looks a little bit hacky to me. I believe SQL drivers usually use >> > that >> > > > approach >> > > > as a workaround because there is no other common way to do that. >> > > > >> > > > Sure we can recommend users to use cache.size() or anything other >> > > > similar way >> > > > to ensure the connection is alive, but it still looks like a >> workaround >> > > to >> > > > me. >> > > > >> > > > Best Regards, >> > > > Igor >> > > > >> > > > >> > > > On Sun, Sep 13, 2020 at 10:16 PM Николай Ижиков < nizhi...@apache.org >> > >> > > wrote: >> > > > >> > > >> Hello, Pavel. >>>
How to eliminate frequent restarts - maybe changes with Ignite 3.0?
Hi Everyone, I'd like to start a discussion on how to eliminate the need to restart the entire cluster whenever configuration changes need to be made to caches. The need to deactivate and restart the entire cluster every time config changes must be made has caused problems with our ability to scale. Every time we onboard a new tenant to Ignite, we increase the frequency of needing to restart the cluster because each tenant has their own needs, and with each restart, we increase the downtime for all of the tenants. One workaround we've considered is setting up a separate cluster for each tenant, but this large number of clusters wastes hardware and is expensive to maintain. How can we resolve this issue? I asked this question in the chat during the webinar today, but we ran out of time before the question could be addressed. Thanks, Devin G. Bost
[MTCGA]: new failures in builds [5597129] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *Test with high flaky rate in master ZookeeperDiscoveryMiscTest.testClientNodesStatus https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4452788328573744433&branch=%3Cdefault%3E&tab=testDetails No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 21:36:43 15-09-2020
[MTCGA]: new failures in builds [5602181] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New Critical Failure in master MVCC Cache 7 https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_MvccCache7?branch=%3Cdefault%3E No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 21:51:44 15-09-2020
Re: Ignite 3.0 meetups
Hi, igniters! Thanks to all who attended today's event, that was a really warm community gathering even though we met online! And thanks to Val for his presentation. I hope these materials will help to run the discussion about Ignite 3.0[1] Video: https://youtu.be/zPuLJgUfLaM Slides with all links: https://bit.ly/32vDR42 I remind, that the Russian speaking community is gathering on September 17: https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/272675398/ [1] https://lists.apache.org/thread.html/reea1639499689d6a0cb2f11d7699cdbfd7102e540aeffdd4d361858c%40%3Cdev.ignite.apache.org%3E пн, 14 сент. 2020 г. в 13:55, Kseniya Romanova : > Hi! Just a reminder that we will meet this week. > Hope to see you there. > > ср, 26 авг. 2020 г. в 01:26, Saikat Maitra : > >> Hi Val, >> >> Thank you for scheduling the meetups. Will join and connect on Ignite 3.0 >> release planning. >> >> Regards, >> Saikat >> >> On Tue, Aug 25, 2020 at 4:49 PM Valentin Kulichenko < >> valentin.kuliche...@gmail.com> wrote: >> >>> Igniters, >>> >>> As was discussed before, we've scheduled two meetups devoted to Ignite >>> 3.0: >>> >>>- Sep 15 (in English): >>>https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/272675408/ >>>- Sep 17 (in Russian): >>>https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/272675398/ >>> >>> I will present the proposed changes and the preliminary roadmap for >>> Ignite 3.0. Everyone is welcome to join and participate in the discussion! >>> >>> -Val >>> >>
Re: Apache Ignite 3.0
Just wanted to submit a link to the video about some offered changes. @valentin.kuliche...@gmail.com please add it to the wiki page. I created timestamps in the description, so one can browse the presentation fast or link the particular section: https://youtu.be/zPuLJgUfLaM Thanks a lot for the presentation! вт, 18 авг. 2020 г. в 14:13, Ilya Kasnacheev : > Hello! > > Maybe we can implement messaging via compute? Share underlying code but > have a different API for convenience (maybe in extras). > > Regards, > -- > Ilya Kasnacheev > > > вт, 18 авг. 2020 г. в 11:59, Pavel Tupitsyn : > > > Val, > > > > > Is see the ".NET Modernization for Ignite 3.0" item in the roadmap, but > > it > > > doesn't provide much detail. What are the actual changes in .NET that > you > > > propose for 3.0? > > > > I've updated the roadmap with a brief description. > > We want to move away from an old, long unsupported .NET version, > > and remove integrations with legacy technologies (old ASP.NET and EF). > > > > > As for the messaging, so far I haven't seen use cases that would > require > > > this API. Sometimes users attempt to use it for remote code invocation, > > but > > > compute is usually a better option for this. Do you have any examples > > where > > > messaging is a better fit then compute? > > > > I guess you are right, Compute can replace Messaging in most scenarios. > > > > Messaging can be more convenient, since it is pub-sub - subscriber > controls > > whether it receives messages on the given topic. But this can be achieved > > with a little more work with Compute as well. > > > > Thanks, > > Pavel > > > > > > > > On Tue, Aug 18, 2020 at 3:16 AM Saikat Maitra > > wrote: > > > > > Hi Pavel, > > > > > > Awesome, thank you. > > > > > > Yes, I remember having .Net modernization as part of Apache Ignite 3.0 > > > roadmap. > > > > > > Regards, > > > Saikat > > > > > > On Sun, Aug 16, 2020 at 11:04 AM Pavel Tupitsyn > > > wrote: > > > > > > > Saikat, yes, most definitely. > > > > This is mentioned in the wishlist under ".NET: Target .NET Standard > > 2.0, > > > > discontinue .NET 4.0 support". > > > > I'm already working towards this goal by making more code and tests > > work > > > > properly under .NET Core, > > > > so when the time for breaking changes comes, it will be simpler. > > > > > > > > On Sat, Aug 15, 2020 at 10:06 PM Saikat Maitra < > > saikat.mai...@gmail.com> > > > > wrote: > > > > > > > > > Hi Val, > > > > > > > > > > Thank you for adding the Cleanup section and Removals list. > > > > > > > > > > Pavel, As part of Apache Ignite Roadmap we had mentioned we will > add > > > > > modernization of .NET. Are we still targeting it in Apache Ignite > 3.0 > > > > > release? > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap > > > > > > > > > > Regards, > > > > > Saikat > > > > > > > > > > > > > > > > > > > > On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam < > > > > > adam.carb...@bottomline.com> > > > > > wrote: > > > > > > > > > > > If you want to make is simpler to have the components that you > > want, > > > > but > > > > > > have that be immutable at install time you could take an approach > > > > similar > > > > > > to the way spring does it with their initializer ( > > > > > > https://start.spring.io/ ) as an example... Basically the > concept > > > > being > > > > > > something that produces a set of configurations that are used to > > > define > > > > > > what the environment looks like ( these could be k8s objects ) > they > > > > could > > > > > > be spring-configuration objects? They could be something that you > > > > develop > > > > > > all upon ignite ( probably wouldn’t recommend this approach ) > > there > > > > > seems > > > > > > to be plenty of these types of things already > > > > > > > > > > > > Example > > > > > > * https://spring.io/guides/gs/centralized-configuration > > > > > > * > > > > > > > > > > > > > > > > > > > > > https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html > > > > > > > > > > > > And I'm by no means saying to use spring these are just examples > > > that I > > > > > > came across > > > > > > > > > > > > I'm thinking the outcome needs to be a platform config of source > ( > > > that > > > > > > can be checked in for those doing gitops ) and maybe ends up as a > > > > config > > > > > > map for those doing k8s, and some other fashion for those doing > > > > something > > > > > > else. > > > > > > > > > > > > Honestly I am not deep enough into the internals of ignite to > know > > > how > > > > > > this might work for the platform, was more describing what I'm > > seeing > > > > > from > > > > > > a bigger picture trend > > > > > > > > > > > > Regards > > > > > > > > > > > > Adam Carbone | Director of Innovation – Intelligent Platform > Team | > > > > > > Bottomline Technologies > > > > > > Office: 603-501-6446 | Mobile: 603-570-8418 > > > > > > www.bottomline.com > > > > > > > > > > > > >
Re: How to eliminate frequent restarts - maybe changes with Ignite 3.0?
Hi Devin, What are the exact configuration changes that force you to restart the cluster? What is your process of onboarding a tenant? The reason I'm asking is that adding new caches should not require a cluster restart, even in the current version, but it's possible that you're hitting one of the edge cases. Please provide more details so that I could properly address the issue. -Val On Tue, Sep 15, 2020 at 11:14 AM Devin Bost wrote: > Hi Everyone, > > I'd like to start a discussion on how to eliminate the need to restart the > entire cluster whenever configuration changes need to be made to caches. > The need to deactivate and restart the entire cluster every time config > changes must be made has caused problems with our ability to scale. Every > time we onboard a new tenant to Ignite, we increase the frequency of > needing to restart the cluster because each tenant has their own needs, and > with each restart, we increase the downtime for all of the tenants. One > workaround we've considered is setting up a separate cluster for each > tenant, but this large number of clusters wastes hardware and is expensive > to maintain. How can we resolve this issue? > > I asked this question in the chat during the webinar today, but we ran out > of time before the question could be addressed. > > Thanks, > > Devin G. Bost >
Re: Apache Ignite 3.0
For what it is worth, we use messaging in Ignite to provide grid notifications for various purposes. These might stimulate compute operations in the message recipients, but they don't represent compute. If messaging is removed, how would Ignite provide the ability for a node to listen to events without the event sender being explicitly aware that the listener does, or should, exist, to produce a compute projection to send messages-as-compute-requests to? On Wed, Sep 16, 2020 at 9:28 AM Kseniya Romanova wrote: > Just wanted to submit a link to the video about some offered changes. > @valentin.kuliche...@gmail.com please add > it to the wiki page. I created timestamps in the description, so one can > browse the presentation fast or link the particular section: > https://youtu.be/zPuLJgUfLaM > Thanks a lot for the presentation! > > вт, 18 авг. 2020 г. в 14:13, Ilya Kasnacheev : > > > Hello! > > > > Maybe we can implement messaging via compute? Share underlying code but > > have a different API for convenience (maybe in extras). > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > вт, 18 авг. 2020 г. в 11:59, Pavel Tupitsyn : > > > > > Val, > > > > > > > Is see the ".NET Modernization for Ignite 3.0" item in the roadmap, > but > > > it > > > > doesn't provide much detail. What are the actual changes in .NET that > > you > > > > propose for 3.0? > > > > > > I've updated the roadmap with a brief description. > > > We want to move away from an old, long unsupported .NET version, > > > and remove integrations with legacy technologies (old ASP.NET and EF). > > > > > > > As for the messaging, so far I haven't seen use cases that would > > require > > > > this API. Sometimes users attempt to use it for remote code > invocation, > > > but > > > > compute is usually a better option for this. Do you have any examples > > > where > > > > messaging is a better fit then compute? > > > > > > I guess you are right, Compute can replace Messaging in most scenarios. > > > > > > Messaging can be more convenient, since it is pub-sub - subscriber > > controls > > > whether it receives messages on the given topic. But this can be > achieved > > > with a little more work with Compute as well. > > > > > > Thanks, > > > Pavel > > > > > > > > > > > > On Tue, Aug 18, 2020 at 3:16 AM Saikat Maitra > > > > wrote: > > > > > > > Hi Pavel, > > > > > > > > Awesome, thank you. > > > > > > > > Yes, I remember having .Net modernization as part of Apache Ignite > 3.0 > > > > roadmap. > > > > > > > > Regards, > > > > Saikat > > > > > > > > On Sun, Aug 16, 2020 at 11:04 AM Pavel Tupitsyn < > ptupit...@apache.org> > > > > wrote: > > > > > > > > > Saikat, yes, most definitely. > > > > > This is mentioned in the wishlist under ".NET: Target .NET Standard > > > 2.0, > > > > > discontinue .NET 4.0 support". > > > > > I'm already working towards this goal by making more code and tests > > > work > > > > > properly under .NET Core, > > > > > so when the time for breaking changes comes, it will be simpler. > > > > > > > > > > On Sat, Aug 15, 2020 at 10:06 PM Saikat Maitra < > > > saikat.mai...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hi Val, > > > > > > > > > > > > Thank you for adding the Cleanup section and Removals list. > > > > > > > > > > > > Pavel, As part of Apache Ignite Roadmap we had mentioned we will > > add > > > > > > modernization of .NET. Are we still targeting it in Apache Ignite > > 3.0 > > > > > > release? > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap > > > > > > > > > > > > Regards, > > > > > > Saikat > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam < > > > > > > adam.carb...@bottomline.com> > > > > > > wrote: > > > > > > > > > > > > > If you want to make is simpler to have the components that you > > > want, > > > > > but > > > > > > > have that be immutable at install time you could take an > approach > > > > > similar > > > > > > > to the way spring does it with their initializer ( > > > > > > > https://start.spring.io/ ) as an example... Basically the > > concept > > > > > being > > > > > > > something that produces a set of configurations that are used > to > > > > define > > > > > > > what the environment looks like ( these could be k8s objects ) > > they > > > > > could > > > > > > > be spring-configuration objects? They could be something that > you > > > > > develop > > > > > > > all upon ignite ( probably wouldn’t recommend this approach ) > > > there > > > > > > seems > > > > > > > to be plenty of these types of things already > > > > > > > > > > > > > > Example > > > > > > > * https://spring.io/guides/gs/centralized-configuration > > > > > > > * > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html > > > > > > > > > > > > > > And I'm by no means saying to use spring these are just > examples > > > > that I > > > > >
Re: Ignite 3.0 meetups
It seems that the new Calcite based SQL Engine is not included in the plan, and this proposal is abandoned? 在 2020/9/16 上午5:24, Kseniya Romanova 写道: Hi, igniters! Thanks to all who attended today's event, that was a really warm community gathering even though we met online! And thanks to Val for his presentation. I hope these materials will help to run the discussion about Ignite 3.0[1] Video: https://youtu.be/zPuLJgUfLaM Slides with all links: https://bit.ly/32vDR42 I remind, that the Russian speaking community is gathering on September 17: https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/272675398/ [1] https://lists.apache.org/thread.html/reea1639499689d6a0cb2f11d7699cdbfd7102e540aeffdd4d361858c%40%3Cdev.ignite.apache.org%3E пн, 14 сент. 2020 г. в 13:55, Kseniya Romanova : Hi! Just a reminder that we will meet this week. Hope to see you there. ср, 26 авг. 2020 г. в 01:26, Saikat Maitra : Hi Val, Thank you for scheduling the meetups. Will join and connect on Ignite 3.0 release planning. Regards, Saikat On Tue, Aug 25, 2020 at 4:49 PM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: Igniters, As was discussed before, we've scheduled two meetups devoted to Ignite 3.0: - Sep 15 (in English): https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/272675408/ - Sep 17 (in Russian): https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/272675398/ I will present the proposed changes and the preliminary roadmap for Ignite 3.0. Everyone is welcome to join and participate in the discussion! -Val
Re: Ignite 3.0 meetups
The Calcilte-based engine will be released gradually in 2.x releases. As far as I know, we don't need for Ignite 3.0. - Denis On Tue, Sep 15, 2020 at 7:43 PM 18624049226 <18624049...@163.com> wrote: > It seems that the new Calcite based SQL Engine is not included in the > plan, and this proposal is abandoned? > > 在 2020/9/16 上午5:24, Kseniya Romanova 写道: > > Hi, igniters! > > Thanks to all who attended today's event, that was a really warm > community > > gathering even though we met online! And thanks to Val for his > > presentation. I hope these materials will help to run the discussion > about > > Ignite 3.0[1] > > Video: https://youtu.be/zPuLJgUfLaM > > Slides with all links: https://bit.ly/32vDR42 > > > > I remind, that the Russian speaking community is gathering on September > 17: > > https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/272675398/ > > > > [1] > > > https://lists.apache.org/thread.html/reea1639499689d6a0cb2f11d7699cdbfd7102e540aeffdd4d361858c%40%3Cdev.ignite.apache.org%3E > > > > > > пн, 14 сент. 2020 г. в 13:55, Kseniya Romanova < > romanova.ks@gmail.com>: > > > >> Hi! Just a reminder that we will meet this week. > >> Hope to see you there. > >> > >> ср, 26 авг. 2020 г. в 01:26, Saikat Maitra : > >> > >>> Hi Val, > >>> > >>> Thank you for scheduling the meetups. Will join and connect on Ignite > 3.0 > >>> release planning. > >>> > >>> Regards, > >>> Saikat > >>> > >>> On Tue, Aug 25, 2020 at 4:49 PM Valentin Kulichenko < > >>> valentin.kuliche...@gmail.com> wrote: > >>> > Igniters, > > As was discussed before, we've scheduled two meetups devoted to Ignite > 3.0: > > - Sep 15 (in English): > > https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/272675408/ > - Sep 17 (in Russian): > > https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/272675398/ > > I will present the proposed changes and the preliminary roadmap for > Ignite 3.0. Everyone is welcome to join and participate in the > discussion! > > -Val > > >
