Re: SQL query timeout: in progress or abandoned
Pavel Tupitsyn, Igor Sapego I wanted to connect and confirm on changes for this PR. https://github.com/apache/ignite/pull/6490 Do you think keeping the change for PlatformConfigurationUtils.java will cause regression on the .NET component or C++ components? Jira : https://issues.apache.org/jira/browse/IGNITE-7285 Regards, Saikat On Mon, Oct 14, 2019 at 3:14 AM Ivan Pavlukhin wrote: > Hi Saikat, > > Sorry for delay. I will do my best to check it in the beginning of this > week. > > сб, 12 окт. 2019 г. в 08:15, Saikat Maitra : > > > > Hello Ivan, > > > > I have updated the PR as per our discussion. > > > > Please review and share your feedback. > > > > Regards, > > Saikat > > > > On Sun, Sep 1, 2019 at 3:20 PM Saikat Maitra > > wrote: > > > > > Hi Ivan, > > > > > > I have taken care of review comments and also have shared a question > for > > > the application of default Query timeout value. > > > > > > Can you please review and share feedback? > > > > > > Regards, > > > Saikat > > > > > > On Sat, Aug 24, 2019 at 7:22 PM Saikat Maitra > > > > wrote: > > > > > >> Hi Ivan, > > >> > > >> Thank you, I have shared my comments and have few questions related to > > >> the issue. > > >> > > >> Please take a look and share your thoughts. > > >> > > >> Regards, > > >> Saikat > > >> > > >> On Tue, Aug 20, 2019 at 4:03 PM Павлухин Иван > > >> wrote: > > >> > > >>> Hi Saikat, > > >>> > > >>> I left a comment in JIRA ticket [1]. Also, I invited Andrey to help > > >>> with a further review. > > >>> > > >>> Andrey, could you please step in and continue the review? > > >>> Unfortunately, for a couple of weeks I have limited access to my > > >>> computer and cannot do a review in a timely manner. > > >>> > > >>> [1] https://issues.apache.org/jira/browse/IGNITE-7285 > > >>> > > >>> 2019-08-19 7:24 GMT+11:00, Saikat Maitra : > > >>> > Hi Ivan, > > >>> > > > >>> > I have updated the PR and made changes in IgniteH2Indexing for > query > > >>> > timeout so that default query timeout get used during query > execution. > > >>> > > > >>> > Please take a look and let me know if this change looks good. > > >>> > > > >>> > I will update tests if the approach looks good. > > >>> > > > >>> > PR https://github.com/apache/ignite/pull/6490 > > >>> > > > >>> > Regards, > > >>> > > > >>> > Saikat > > >>> > > > >>> > On Sat, Aug 17, 2019 at 8:30 PM Saikat Maitra < > saikat.mai...@gmail.com > > >>> > > > >>> > wrote: > > >>> > > > >>> >> Hi Ivan, Denis > > >>> >> > > >>> >> Thank you for your feedback, I am looking into the changes needed > for > > >>> >> this > > >>> >> issue. > > >>> >> > > >>> >> I am also looking into these configurations parameters > > >>> >> https://apacheignite.readme.io/v2.2/docs/configuration-parameters > to > > >>> see > > >>> >> if there are similar attributes being used in SqlFieldsQuery and > > >>> >> SqlQuery. > > >>> >> > > >>> >> > > >>> >> Regards, > > >>> >> > > >>> >> Saikat > > >>> >> > > >>> >> > > >>> >> > > >>> >> On Thu, Aug 15, 2019 at 6:13 AM Павлухин Иван < > vololo...@gmail.com> > > >>> >> wrote: > > >>> >> > > >>> >>> Saikat, Denis, > > >>> >>> > > >>> >>> I left comments in the ticket [1]. > > >>> >>> > > >>> >>> [1] https://issues.apache.org/jira/browse/IGNITE-7285 > > >>> >>> > > >>> >>> вт, 13 авг. 2019 г. в 21:53, Denis Magda : > > >>> >>> > > > >>> >>> > Hi Saikat, > > >>> >>> > > > >>> >>> > Thanks for a quick turnaround! Ivan, could you please step in > and > > >>> do a > > >>> >>> > review? > > >>> >>> > > > >>> >>> > - > > >>> >>> > Denis > > >>> >>> > > > >>> >>> > > > >>> >>> > On Sun, Aug 11, 2019 at 6:26 AM Saikat Maitra > > >>> >>> > > > >>> >>> > wrote: > > >>> >>> > > > >>> >>> > > Hi Denis, Ivan > > >>> >>> > > > > >>> >>> > > As discussed I have updated the PR and incorporated review > > >>> comments. > > >>> >>> > > > > >>> >>> > > https://github.com/apache/ignite/pull/6490/files > > >>> >>> > > > > >>> >>> > > Please take a look and share your feedback. > > >>> >>> > > > > >>> >>> > > Regard, > > >>> >>> > > Saikat > > >>> >>> > > > > >>> >>> > > > > >>> >>> > > > > >>> >>> > > On Sat, Aug 10, 2019 at 5:51 PM Saikat Maitra < > > >>> >>> saikat.mai...@gmail.com> > > >>> >>> > > wrote: > > >>> >>> > > > > >>> >>> > > > Hello Denis, Ivan > > >>> >>> > > > > > >>> >>> > > > Yes, I can take up the changes for IGNITE-7825. > > >>> >>> > > > > > >>> >>> > > > I had a doubt on the usage of the Default Query Timeout. > > >>> >>> > > > > > >>> >>> > > > I had raised the PR in an assumption that Default Query > Timeout > > >>> >>> will only > > >>> >>> > > > be used if user had not provided Cache Query Timeout > > >>> >>> > > > > > >>> >>> > > > https://github.com/apache/ignite/pull/6490/files > > >>> >>> > > > > > >>> >>> > > > I wanted to discuss if it is correct intended usage of > Default > > >>> >>> > > > Query > > >>> >>> > > > Timeout or should we reconsider? > > >>> >>> > > > > > >>> >>> > > > Regards, > > >>> >>> > > > Saikat > > >>> >>> > > > > > >>> >>> > > > > > >
Re: Calcite based SQL query engine. Local queries
Take the amount of cashback calculation or payments authorization as examples of compute tasks with local SQL. In the first case, all transactions are collocated per account and a bank needs to calculate the cashback monthly by broadcasting the task that executes special logic across all accounts and SQL is used by the logic to access the data with various filters. The same is done for an individual account with an affinity call. In the second case, a man swipes a card at a shop register, systems sends a compute task to the node that collocates a lot of data per the man account and begins calculating hundreds or thousands of variables retrieving data with both key-value and SQL. Also, take drugs discovery and other pharmaceutical examples. Those are compute-heavy and the users from that space were sharing the stories how compute, scan, sql and key-value apis are used together with compute. At all, each industry has compute-heavy use cases that need to retrieve local data with local SQL, there are real Ignite users who do this in prod. Again, we also need to think about our compute as of advanced stored and complex procedures that can retrieve local/collocated data not only with key-value and scans but with SQL as well that supports conditions, joins, etc. Denis On Thursday, November 7, 2019, Ivan Pavlukhin wrote: > Denis, > > To make things really clearer we need to provide some concrete example > of Compute + LocalSQL and reason about it to figure out whether > "smart" SQL engine can deliver the same (or better) results or not. > > пт, 8 нояб. 2019 г. в 01:48, Denis Magda : > > > > Folks, > > > > See our compute tasks as an advanced version of stored procedures that > let > > the users code the logic of various complexity with Java, .NET or C++ > (and > > not with PL/SQL). The logic can use a combination of APIs (key-value, > SQL, > > etc.) to access data both locally and remotely while being executed on > > server nodes. The logic can make N key-value requests or run M SQL > queries. > > > > We kept supporting local SQL queries exactly for such scenarios (for our > > version of stored procedures) to ensure the distributed map-reduce phase > is > > canceled if all the data is local. And affinityCalls were improved one > day > > to pin the partitions. > > > > If the new engine is smart enough to understand that all the partitions > are > > available locally during the affinityRun execution then it's totally fine > > to remove the 'local' flag. Otherwise, we need to instruct the engine > > manually that a distributed phase is redundant via 'local' flag or by > other > > means. > > > > Does it make things clearer? > > > > > > - > > Denis > > > > > > On Thu, Nov 7, 2019 at 3:53 AM Ivan Pavlukhin > wrote: > > > > > Stephen, > > > > > > In my understanding we need to do a better job to realize use-cases of > > > Compute + LocalSQL ourselves. > > > > > > Ideally smart optimizer should do the best job of query deployment. > > > > > > чт, 7 нояб. 2019 г. в 13:04, Stephen Darlington > > > : > > > > > > > > I made a (bad) assumption that this would also affect queries against > > > partitions. If “setLocal()” goes away but “setPartitions()” remains I’m > > > happy. > > > > > > > > What I would say is that the “broadcast / local” method is one I see > > > fairly often. Do we need to do a better job educating people of the > > > “correct” way? > > > > > > > > Regards, > > > > Stephen > > > > > > > > > On 7 Nov 2019, at 08:30, Alexey Goncharuk < > alexey.goncha...@gmail.com> > > > wrote: > > > > > > > > > > Denis, Stephen, > > > > > > > > > > Running a local query in a broadcast closure won't work on changing > > > > > topology. We specifically added an affinityCall method to the > compute > > > API > > > > > in order to pin a partition to prevent its moving and eviction > > > throughout > > > > > the task execution. Therefore, the query inside an affinityCall is > > > always > > > > > executed against some partitions (otherwise the query may give > > > incorrect > > > > > results when topology is changed). > > > > > > > > > > I support Igor's question and think that the 'local' flag for the > query > > > > > should be deprecated and eventually removed. A 'local' query can > > > always be > > > > > expressed as a query agains a set of partitions. If those > partitions > > > are > > > > > located on the same node - good, we get fast and correct results. > If > > > not - > > > > > we may either raise an exception and ask user to remap the query, > or > > > > > fallback to a distributed query execution. > > > > > > > > > > Given that the Calcite prototype is in its early stages, it's > likely > > > its > > > > > first version will be available in 3.x, and it's a good chance to > get > > > rid > > > > > of wrong API pieces. > > > > > > > > > > --AG > > > > > > > > > > пн, 4 нояб. 2019 г. в 14:02, Stephen Darlington < > > > > > stephen.darling...@gridgain.com>: > > > > > > > > > >> A common use case is where you want
Re: Calcite based SQL query engine. Local queries
Yes, I understand that it is straightforward and, may be, naive approach. Which is why I'm asking how to do map-reduce on cache C data in Ignite with proper partition pinning. About Predefined/Implemented aggregate - I'm not sure I agree that we can predict everything. It is real perk of Ignite that you can send any of your code (which, BTW, can be developed in lifetime of the system) to your data. So I propose map and reduce phase should allow user code to be executed. If I know any other better approach, I would somehow document it (e.g. add to some next training/workshop). Sincerely, Dmitriy Pavlov пт, 8 нояб. 2019 г. в 15:45, Ivan Pavlukhin : > Dmitriy, > > First, what kind of cumulative metric can it be? A lot of cumulative > metrics can be compared using SQL. MIN, MAX, AVG are simple ones. For > more complex ones I can think about user-define aggregate functions > (UDAF). We do not have them in Ignite so far, but can introduce them. > > Second, naive approaches of such ComputeScan can lead to incorrect > results as partitions might not be properly pinned and duplicate > entries might appear. > > пт, 8 нояб. 2019 г. в 15:27, Dmitriy Pavlov : > > > > Hi Ivan, Igniters, imagine you need to scan all entities in the cluster. > > > > Ideally, you don't want to de-serialize all of entries, so you can use > > withKeepBinary(). e.g. you need a couple of fields and get some > cumulative > > metric on this data. You can send compute to all cluster nodes and run > > there SQL scan queries with local mode is on. In that manner you can > > implement Map-Reduce. > > > > It may be there is another way of doing that, so I encourage to share > it. I > > could update workshops/training I preparing in background. > > > > Sincerely, > > Dmitriy Pavlov > > > > пт, 8 нояб. 2019 г. в 08:57, Ivan Pavlukhin : > > > > > Denis, > > > > > > To make things really clearer we need to provide some concrete example > > > of Compute + LocalSQL and reason about it to figure out whether > > > "smart" SQL engine can deliver the same (or better) results or not. > > > > > > пт, 8 нояб. 2019 г. в 01:48, Denis Magda : > > > > > > > > Folks, > > > > > > > > See our compute tasks as an advanced version of stored procedures > that > > > let > > > > the users code the logic of various complexity with Java, .NET or C++ > > > (and > > > > not with PL/SQL). The logic can use a combination of APIs (key-value, > > > SQL, > > > > etc.) to access data both locally and remotely while being executed > on > > > > server nodes. The logic can make N key-value requests or run M SQL > > > queries. > > > > > > > > We kept supporting local SQL queries exactly for such scenarios (for > our > > > > version of stored procedures) to ensure the distributed map-reduce > phase > > > is > > > > canceled if all the data is local. And affinityCalls were improved > one > > > day > > > > to pin the partitions. > > > > > > > > If the new engine is smart enough to understand that all the > partitions > > > are > > > > available locally during the affinityRun execution then it's totally > fine > > > > to remove the 'local' flag. Otherwise, we need to instruct the engine > > > > manually that a distributed phase is redundant via 'local' flag or by > > > other > > > > means. > > > > > > > > Does it make things clearer? > > > > > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Thu, Nov 7, 2019 at 3:53 AM Ivan Pavlukhin > > > wrote: > > > > > > > > > Stephen, > > > > > > > > > > In my understanding we need to do a better job to realize > use-cases of > > > > > Compute + LocalSQL ourselves. > > > > > > > > > > Ideally smart optimizer should do the best job of query deployment. > > > > > > > > > > чт, 7 нояб. 2019 г. в 13:04, Stephen Darlington > > > > > : > > > > > > > > > > > > I made a (bad) assumption that this would also affect queries > against > > > > > partitions. If “setLocal()” goes away but “setPartitions()” > remains I’m > > > > > happy. > > > > > > > > > > > > What I would say is that the “broadcast / local” method is one I > see > > > > > fairly often. Do we need to do a better job educating people of the > > > > > “correct” way? > > > > > > > > > > > > Regards, > > > > > > Stephen > > > > > > > > > > > > > On 7 Nov 2019, at 08:30, Alexey Goncharuk < > > > alexey.goncha...@gmail.com> > > > > > wrote: > > > > > > > > > > > > > > Denis, Stephen, > > > > > > > > > > > > > > Running a local query in a broadcast closure won't work on > changing > > > > > > > topology. We specifically added an affinityCall method to the > > > compute > > > > > API > > > > > > > in order to pin a partition to prevent its moving and eviction > > > > > throughout > > > > > > > the task execution. Therefore, the query inside an > affinityCall is > > > > > always > > > > > > > executed against some partitions (otherwise the query may give > > > > > incorrect > > > > > > > results when topology is changed). > > > > > > > > > > > > > > I support Igor's question and think that the 'l
Re: Calcite based SQL query engine. Local queries
Dmitriy, First, what kind of cumulative metric can it be? A lot of cumulative metrics can be compared using SQL. MIN, MAX, AVG are simple ones. For more complex ones I can think about user-define aggregate functions (UDAF). We do not have them in Ignite so far, but can introduce them. Second, naive approaches of such ComputeScan can lead to incorrect results as partitions might not be properly pinned and duplicate entries might appear. пт, 8 нояб. 2019 г. в 15:27, Dmitriy Pavlov : > > Hi Ivan, Igniters, imagine you need to scan all entities in the cluster. > > Ideally, you don't want to de-serialize all of entries, so you can use > withKeepBinary(). e.g. you need a couple of fields and get some cumulative > metric on this data. You can send compute to all cluster nodes and run > there SQL scan queries with local mode is on. In that manner you can > implement Map-Reduce. > > It may be there is another way of doing that, so I encourage to share it. I > could update workshops/training I preparing in background. > > Sincerely, > Dmitriy Pavlov > > пт, 8 нояб. 2019 г. в 08:57, Ivan Pavlukhin : > > > Denis, > > > > To make things really clearer we need to provide some concrete example > > of Compute + LocalSQL and reason about it to figure out whether > > "smart" SQL engine can deliver the same (or better) results or not. > > > > пт, 8 нояб. 2019 г. в 01:48, Denis Magda : > > > > > > Folks, > > > > > > See our compute tasks as an advanced version of stored procedures that > > let > > > the users code the logic of various complexity with Java, .NET or C++ > > (and > > > not with PL/SQL). The logic can use a combination of APIs (key-value, > > SQL, > > > etc.) to access data both locally and remotely while being executed on > > > server nodes. The logic can make N key-value requests or run M SQL > > queries. > > > > > > We kept supporting local SQL queries exactly for such scenarios (for our > > > version of stored procedures) to ensure the distributed map-reduce phase > > is > > > canceled if all the data is local. And affinityCalls were improved one > > day > > > to pin the partitions. > > > > > > If the new engine is smart enough to understand that all the partitions > > are > > > available locally during the affinityRun execution then it's totally fine > > > to remove the 'local' flag. Otherwise, we need to instruct the engine > > > manually that a distributed phase is redundant via 'local' flag or by > > other > > > means. > > > > > > Does it make things clearer? > > > > > > > > > - > > > Denis > > > > > > > > > On Thu, Nov 7, 2019 at 3:53 AM Ivan Pavlukhin > > wrote: > > > > > > > Stephen, > > > > > > > > In my understanding we need to do a better job to realize use-cases of > > > > Compute + LocalSQL ourselves. > > > > > > > > Ideally smart optimizer should do the best job of query deployment. > > > > > > > > чт, 7 нояб. 2019 г. в 13:04, Stephen Darlington > > > > : > > > > > > > > > > I made a (bad) assumption that this would also affect queries against > > > > partitions. If “setLocal()” goes away but “setPartitions()” remains I’m > > > > happy. > > > > > > > > > > What I would say is that the “broadcast / local” method is one I see > > > > fairly often. Do we need to do a better job educating people of the > > > > “correct” way? > > > > > > > > > > Regards, > > > > > Stephen > > > > > > > > > > > On 7 Nov 2019, at 08:30, Alexey Goncharuk < > > alexey.goncha...@gmail.com> > > > > wrote: > > > > > > > > > > > > Denis, Stephen, > > > > > > > > > > > > Running a local query in a broadcast closure won't work on changing > > > > > > topology. We specifically added an affinityCall method to the > > compute > > > > API > > > > > > in order to pin a partition to prevent its moving and eviction > > > > throughout > > > > > > the task execution. Therefore, the query inside an affinityCall is > > > > always > > > > > > executed against some partitions (otherwise the query may give > > > > incorrect > > > > > > results when topology is changed). > > > > > > > > > > > > I support Igor's question and think that the 'local' flag for the > > query > > > > > > should be deprecated and eventually removed. A 'local' query can > > > > always be > > > > > > expressed as a query agains a set of partitions. If those > > partitions > > > > are > > > > > > located on the same node - good, we get fast and correct results. > > If > > > > not - > > > > > > we may either raise an exception and ask user to remap the query, > > or > > > > > > fallback to a distributed query execution. > > > > > > > > > > > > Given that the Calcite prototype is in its early stages, it's > > likely > > > > its > > > > > > first version will be available in 3.x, and it's a good chance to > > get > > > > rid > > > > > > of wrong API pieces. > > > > > > > > > > > > --AG > > > > > > > > > > > > пн, 4 нояб. 2019 г. в 14:02, Stephen Darlington < > > > > > > stephen.darling...@gridgain.com>: > > > > > > > > > > > >> A common use case is where you want to wo
Re: Calcite based SQL query engine. Local queries
Hi Ivan, Igniters, imagine you need to scan all entities in the cluster. Ideally, you don't want to de-serialize all of entries, so you can use withKeepBinary(). e.g. you need a couple of fields and get some cumulative metric on this data. You can send compute to all cluster nodes and run there SQL scan queries with local mode is on. In that manner you can implement Map-Reduce. It may be there is another way of doing that, so I encourage to share it. I could update workshops/training I preparing in background. Sincerely, Dmitriy Pavlov пт, 8 нояб. 2019 г. в 08:57, Ivan Pavlukhin : > Denis, > > To make things really clearer we need to provide some concrete example > of Compute + LocalSQL and reason about it to figure out whether > "smart" SQL engine can deliver the same (or better) results or not. > > пт, 8 нояб. 2019 г. в 01:48, Denis Magda : > > > > Folks, > > > > See our compute tasks as an advanced version of stored procedures that > let > > the users code the logic of various complexity with Java, .NET or C++ > (and > > not with PL/SQL). The logic can use a combination of APIs (key-value, > SQL, > > etc.) to access data both locally and remotely while being executed on > > server nodes. The logic can make N key-value requests or run M SQL > queries. > > > > We kept supporting local SQL queries exactly for such scenarios (for our > > version of stored procedures) to ensure the distributed map-reduce phase > is > > canceled if all the data is local. And affinityCalls were improved one > day > > to pin the partitions. > > > > If the new engine is smart enough to understand that all the partitions > are > > available locally during the affinityRun execution then it's totally fine > > to remove the 'local' flag. Otherwise, we need to instruct the engine > > manually that a distributed phase is redundant via 'local' flag or by > other > > means. > > > > Does it make things clearer? > > > > > > - > > Denis > > > > > > On Thu, Nov 7, 2019 at 3:53 AM Ivan Pavlukhin > wrote: > > > > > Stephen, > > > > > > In my understanding we need to do a better job to realize use-cases of > > > Compute + LocalSQL ourselves. > > > > > > Ideally smart optimizer should do the best job of query deployment. > > > > > > чт, 7 нояб. 2019 г. в 13:04, Stephen Darlington > > > : > > > > > > > > I made a (bad) assumption that this would also affect queries against > > > partitions. If “setLocal()” goes away but “setPartitions()” remains I’m > > > happy. > > > > > > > > What I would say is that the “broadcast / local” method is one I see > > > fairly often. Do we need to do a better job educating people of the > > > “correct” way? > > > > > > > > Regards, > > > > Stephen > > > > > > > > > On 7 Nov 2019, at 08:30, Alexey Goncharuk < > alexey.goncha...@gmail.com> > > > wrote: > > > > > > > > > > Denis, Stephen, > > > > > > > > > > Running a local query in a broadcast closure won't work on changing > > > > > topology. We specifically added an affinityCall method to the > compute > > > API > > > > > in order to pin a partition to prevent its moving and eviction > > > throughout > > > > > the task execution. Therefore, the query inside an affinityCall is > > > always > > > > > executed against some partitions (otherwise the query may give > > > incorrect > > > > > results when topology is changed). > > > > > > > > > > I support Igor's question and think that the 'local' flag for the > query > > > > > should be deprecated and eventually removed. A 'local' query can > > > always be > > > > > expressed as a query agains a set of partitions. If those > partitions > > > are > > > > > located on the same node - good, we get fast and correct results. > If > > > not - > > > > > we may either raise an exception and ask user to remap the query, > or > > > > > fallback to a distributed query execution. > > > > > > > > > > Given that the Calcite prototype is in its early stages, it's > likely > > > its > > > > > first version will be available in 3.x, and it's a good chance to > get > > > rid > > > > > of wrong API pieces. > > > > > > > > > > --AG > > > > > > > > > > пн, 4 нояб. 2019 г. в 14:02, Stephen Darlington < > > > > > stephen.darling...@gridgain.com>: > > > > > > > > > >> A common use case is where you want to work on many rows of data > > > across > > > > >> the grid. You’d broadcast a closure, running the same code on > every > > > node > > > > >> with just the local data. SQL doesn’t work in isolation — it’s > often > > > used > > > > >> as a filter for future computations. > > > > >> > > > > >> Regards, > > > > >> Stephen > > > > >> > > > > >>> On 1 Nov 2019, at 17:53, Ivan Pavlukhin > wrote: > > > > >>> > > > > >>> Denis, > > > > >>> > > > > >>> I am mostly concerned about gathering use cases. It would be > great to > > > > >>> critically assess such cases to identify why it cannot be solved > by > > > > >>> using distributed SQL. Also it sounds similar to some kind of > > > "hints", > > > > >>> but very limited and with all hints dra
Re: Review for IGNITE-12300
Hi, Ilya! I've fixed the flaky test. Could you have a look? Thank you! чт, 7 нояб. 2019 г. в 17:12, Ilya Kasnacheev : > Hello! > > When I run this test, each case takes 10-40 seconds of hardcore disk usage > for some reason. > > Oops, sorry. I have just commented your ticket. > > Regards, > -- > Ilya Kasnacheev > > > чт, 7 нояб. 2019 г. в 16:18, Denis Garus : > > > >> but keep data in-memory? > > > > I don't use any data in tests for this issue; only compute task. > > > > > > >> I have commented JIRA with example of test failure. > > > > Unfortunately, I don't see your comment in JIRA [1]. > > > > > > 1. https://issues.apache.org/jira/browse/IGNITE-12300 > > > > чт, 7 нояб. 2019 г. в 15:45, Ilya Kasnacheev >: > > > > > Hello! > > > > > > I can see that, but for some reason I can see a lot of disk I/O while > > > running this test. Is it possible to only use persistence for auth > > > purposes, but keep data in-memory? > > > > > > I have commented JIRA with example of test failure. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > чт, 7 нояб. 2019 г. в 15:36, Denis Garus : > > > > > > > Hi, Ilya! > > > > > > > > Thank you for the review! > > > > > > > > > For some reason, when I run it locally, it starts to use > persistence, > > > do > > > > > you have ideas why that would happen? > > > > > > > > The reason is "Authentication can be enabled only for cluster with > > > enabled > > > > persistence." [1] > > > > > > > > > It also seems to me that > > > > > > > > > > > > > > > > > > > org.apache.ignite.internal.processors.security.compute.closure.ComputeTaskCancelRemoteSecurityContextCheckTest#testClientTaskInitatorCancelOnSrvNode > > > > > is flaky. > > > > > > > > I have started this test 25 times, and it is green. Could you please > > > > clarify why do you think the test is flaky? > > > > > > > > > > > > 1. > > > > > > > > > > > > > > https://github.com/apache/ignite/blob/720706d794e4935779cc2531462595032a547852/modules/core/src/main/java/org/apache/ignite/internal/processors/authentication/IgniteAuthenticationProcessor.java#L158 > > > > > > > > чт, 7 нояб. 2019 г. в 15:02, Ilya Kasnacheev < > > ilya.kasnach...@gmail.com > > > >: > > > > > > > > > Hello! > > > > > > > > > > I will re-run tests against fresh master, and then commit if they > > pass. > > > > > > > > > > For some reason, when I run it locally, it starts to use > persistence, > > > do > > > > > you have ideas why that would happen? > > > > > > > > > > It also seems to me that > > > > > > > > > > > > > > > > > > > > org.apache.ignite.internal.processors.security.compute.closure.ComputeTaskCancelRemoteSecurityContextCheckTest#testClientTaskInitatorCancelOnSrvNode > > > > > is flaky. > > > > > > > > > > Regards, > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > чт, 7 нояб. 2019 г. в 12:10, Denis Garus : > > > > > > > > > > > Hello, Igniters! > > > > > > > > > > > > I've raised the PR [1] for the issue [2]. > > > > > > Could somebody review it? > > > > > > > > > > > > 1. https://github.com/apache/ignite/pull/7017 > > > > > > 2. https://issues.apache.org/jira/browse/IGNITE-12300 > > > > > > > > > > > > > > > > > > > > >
