Re: ignite PureJavaCrc32 vs java.util.zip.CRC32 bench.

> > > > > > > >> > > >> > > > > > > > > > > >> > > > Hello, Igniters! >> > > > > > > > > > > >> > > > >> > > > > > > > > > > >> > > > In java8 java.lang.zip.CRC32 methods become >> > > > intrinsic, >> > > > > > > > > moreover >> > > > > > > > > > > new >> > > > > > > > > > > >> > > > "update" method, which use ByteBuffer was >> > > > introduced. >> > > > > > > Since >> > > > > > > > we >> > > > > > > > > > > >> moved >> > > > > > > > > > > >> to >> > > > > > > > > > > >> > > > java8, perhaps we really can get performance >> > boost >> > > > by >> > > > > > > using >> > > > > > > > > > > >> standard >> > > > > > > > > > > >> > > > java.lang.zip.CRC32 instead of >> PureJavaCrc32. >> > > > > > > > > > > >> > > > >> > > > > > > > > > > >> > > > About compatibility: looks like >> PureJavaCrc32 >> > > > > implements >> > > > > > > the >> > > > > > > > > > same >> > > > > > > > > > > >> > > algorithm >> > > > > > > > > > > >> > > > as java.lang.zip.CRC32. These two >> > implementations >> > > > uses >> > > > > > the >> > > > > > > > > same >> > > > > > > > > > > >> > > polynomial >> > > > > > > > > > > >> > > > and the same initial value. The only >> difference >> > is >> > > > > final >> > > > > > > xor >> > > > > > > > > > mask >> > > > > > > > > > > >> > > > (0x for java.lang.zip.CRC32). So, we >> can >> > > > > easily >> > > > > > > > > convert >> > > > > > > > > > > >> from >> > > > > > > > > > > >> > > > PureJavaCrc32 >> > > > > > > > > > > >> > > > to standard CRC32 and vice versa, using this >> > > > > expression: >> > > > > > > > crc32 >> > > > > > > > > > ^= >> > > > > > > > > > > >> > > > 0x >> > > > > > > > > > > >> > > > >> > > > > > > > > > > >> > > > >> > > > > > > > > > > >> > > > 2018-08-14 0:19 GMT+03:00 Eduard Shangareev >> < >> > > > > > > > > > > >> > eduard.shangar...@gmail.com >> > > > > > > > > > > >> > > >: >> > > > > > > > > > > >> > > > >> > > > > > > > > > > >> > > > > Evgeniy, >> > > > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > Could you share benchmark code? And please >> > share >> > > > > what >> > > > > > > > > version >> > > > > > > > > > of >> > > > > > > > > > > >> JVM >> > > > > > > > > > > >> > > > > you have used. >> > > > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > On Mon, Aug 13, 2018 at 10:44 PM Zhenya >> > > > > > > > > > > >> < arzamas...@mail.ru.invalid >> > > > > > > > > > > >> > >> > > > > > > > > > > >> > > > > wrote: >> > > > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > > I think it would break backward >> > compatibility, >> > > > as >> > > > > > > > Nikolay >> > > > > > > > > > > >> mentioned >> > > > > > > > > > > >> > > > above >> > > > > > > > > > > >> > > > > > we would take exception here: >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > [1] >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > https://github.com/apache/ >> > > > > > > ignite/blob/master/modules/ >> > > > > > > > > > > >> > > > > core/src/main/java/org/apache/ >> > > > > > > ignite/internal/processors/ >> > > > > > > > > > > >> > > > > >> cache/persistence/file/FilePageStore.java#L372 >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > thats why i question for community >> thoughts >> > > > here. >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > > Hi Evgeniy, >> > > > > > > > > > > >> > > > > > > >> > > > > > > > > > > >> > > > > > > would you like to submit a patch with >> > CRC32 >> > > > > > > > > implementation >> > > > > > > > > > > >> > change? >> > > > > > > > > > > >> > > > > > > >> > > > > > > > > > > >> > > > > > > Sincerely, >> > > > > > > > > > > >> > > > > > > Dmitriy Pavlov >> > > > > > > > > > > >> > > > > > > >> > > > > > > > > > > >> > > > > > > пн, 13 авг. 2018 г. в 22:08, Евгений >> > > > > Станиловский >> > > > > > > > > > > >> > > > > > > < arzamas...@mail.ru.invalid >: >> > > > > > > > > > > >> > > > > > > >> > > > > > > > > > > >> > > > > > >> Hi, igniters, i wrote a simple bench, >> > looks >> > > > > like >> > > > > > > > > > > >> PureJavaCrc32 >> > > > > > > > > > > >> > has >> > > > > > > > > > > >> > > > > > >> performance problems in compatible >> with >> > > > > > zip.CRC32. >> > > > > > > > > > > >> > > > > > >> >> > > > > > > > > > > >> > > > > > >> Benchmark Mode Cnt Score Error Units >> > > > > > > > > > > >> > > > > > >> BenchmarkCRC.Crc32 avgt 5 >> 1088914.540 ± >> > > > > > 368851.822 >> > > > > > > > > ns/op >> > > > > > > > > > > >> > > > > > >> BenchmarkCRC.pureJavaCrc32 avgt 5 >> > > > 6619408.049 ± >> > > > > > > > > > 3746712.210 >> > > > > > > > > > > >> > ns/op >> > > > > > > > > > > >> > > > > > >> >> > > > > > > > > > > >> > > > > > >> thoughts? >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > >> > > > > > > > > > > >> > > >> > > > > > > > > > > >> > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > -- >> > > > > > > > > > > Евгений Станиловский >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > -- >> > > > > > > Sergey Kozlov >> > > > > > > GridGain Systems >> > > > > > > www.gridgain.com >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Sergey Kozlov >> > > > > GridGain Systems >> > > > > www.gridgain.com >> > > > > >> > > > >> > > >> > > >> > > >> > > -- >> > > Sergey Kozlov >> > > GridGain Systems >> > > www.gridgain.com >> > > >> > -- Zhenya Stanilovsky

Re: Case sensitive indexes question.

e index if it can be useful for anyone. Having same field set >> indexed >> with same index type is pretty strange and adds a lot of risk for >> performance of the system. If this is hard to support in 2.x then let's >> do >> it in 3.0. Vladimir, what do you think? >> >> -- Yakov -- Zhenya Stanilovsky

Re: [DISCUSSION] Performance issue with cluster-wide cache metrics distribution

mple). > >Also maybe we should change cache metrics distributing strategy? For >example, collect metrics by request via communication SPI or subscribe to a >limited set of cache/metrics, etc. > >Thoughts? > >[1]: https://issues.apache.org/jira/browse/IGNITE-10172 -- Zhenya Stanilovsky

Re: Case sensitive indexes question.

uestion: why do we need this functional? >> >> i found that other vendors not allow such indexes [2] >> >> if we can`t change this in 2.x version due to some backward compatibility >> reasons, plz show them, i have no clue why we can`t change it in near >> release versions. >> >> [1] https://apacheignite-sql.readme.io/docs/create-index >> [2] >> >> >> https://oracle-base.com/articles/12c/multiple-indexes-on-same-set-of-columns-12cr1 >> >> thanks! -- Zhenya Stanilovsky

Re[4]: Cache scan efficiency

chieve "pinning" semantics. > >On Wed, Sep 19, 2018 at 8:34 AM Zhenya Stanilovsky >< arzamas...@mail.ru.invalid > wrote: > >> hi, but how to deal with page replacements, which Dmitriy Pavlov mentioned? >> this approach would be efficient if all data fits into memor

Re[2]: Cache scan efficiency

a >> lot >> > of >> > > > > other >> > > > > > > > > pages, >> > > > > > > > > > > what will ultimately lead to bad performance of >> > subsequent >> > > > > > queries >> > > > > > > > and >> > > > > > > > > > > defeat LRU algorithms, which are of great improtance >> for >> > > good >> > > > > > > > database >> > > > > > > > > > > performance. >> > > > > > > > > > > >> > > > > > > > > > > Database vendors choose another approach - skip BTrees, >> > > > iterate >> > > > > > > > > direclty >> > > > > > > > > > > over data pages, read them in multi-block fashion, use >> > > > separate >> > > > > > > scan >> > > > > > > > > > buffer >> > > > > > > > > > > to avoid excessive evictions of other hot pages. >> > > > Corresponding >> > > > > > > ticket >> > > > > > > > > for >> > > > > > > > > > > SQL exists [1], but idea is common for all parts of the >> > > > system, >> > > > > > > > > requiring >> > > > > > > > > > > scans. >> > > > > > > > > > > >> > > > > > > > > > > As far as proposed solution, it might be good idea to >> add >> > > > > special >> > > > > > > API >> > > > > > > > > to >> > > > > > > > > > > "warmup" partition with clear explanation of pros (fast >> > > scan >> > > > > > after >> > > > > > > > > > warmup) >> > > > > > > > > > > and cons (slowdown of any other operations). But I >> think >> > we >> > > > > > should >> > > > > > > > not >> > > > > > > > > > make >> > > > > > > > > > > this approach part of normal scans. >> > > > > > > > > > > >> > > > > > > > > > > Vladimir. >> > > > > > > > > > > >> > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-6057 >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > On Sun, Sep 16, 2018 at 6:44 PM Alexei Scherbakov < >> > > > > > > > > > > alexey.scherbak...@gmail.com > wrote: >> > > > > > > > > > > >> > > > > > > > > > > > Igniters, >> > > > > > > > > > > > >> > > > > > > > > > > > My use case involves scenario where it's necessary to >> > > > iterate >> > > > > > > over >> > > > > > > > > > > > large(many TBs) persistent cache doing some >> calculation >> > > on >> > > > > read >> > > > > > > > data. >> > > > > > > > > > > > >> > > > > > > > > > > > The basic solution is to iterate cache using >> ScanQuery. >> > > > > > > > > > > > >> > > > > > > > > > > > This turns out to be slow because iteration over >> cache >> > > > > > involves a >> > > > > > > > lot >> > > > > > > > > > of >> > > > > > > > > > > > random disk access for reading data pages referenced >> > from >> > > > > leaf >> > > > > > > > pages >> > > > > > > > > by >> > > > > > > > > > > > links. >> > > > > > > > > > > > >> > > > > > > > > > > > This is especially true when data is stored on disks >> > with >> > > > > slow >> > > > > > > > random >> > > > > > > > > > > > access, like SAS disks. In my case on modern SAS >> disks >> > > > array >> > > > > > > > reading >> > > > > > > > > > > speed >> > > > > > > > > > > > was like several MB/sec while sequential read speed >> in >> > > perf >> > > > > > test >> > > > > > > > was >> > > > > > > > > > > about >> > > > > > > > > > > > GB/sec. >> > > > > > > > > > > > >> > > > > > > > > > > > I was able to fix the issue by using ScanQuery with >> > > > explicit >> > > > > > > > > partition >> > > > > > > > > > > set >> > > > > > > > > > > > and running simple warmup code before each partition >> > > scan. >> > > > > > > > > > > > >> > > > > > > > > > > > The code pins cold pages in memory in sequential >> order >> > > thus >> > > > > > > > > eliminating >> > > > > > > > > > > > random disk access. Speedup was like x100 magnitude. >> > > > > > > > > > > > >> > > > > > > > > > > > I suggest adding the improvement to the product's >> core >> > > by >> > > > > > always >> > > > > > > > > > > > sequentially preloading pages for all internal >> > partition >> > > > > > > iterations >> > > > > > > > > > > (cache >> > > > > > > > > > > > iterators, scan queries, sql queries with scan plan) >> if >> > > > > > partition >> > > > > > > > is >> > > > > > > > > > cold >> > > > > > > > > > > > (low number of pinned pages). >> > > > > > > > > > > > >> > > > > > > > > > > > This also should speed up rebalancing from cold >> > > partitions. >> > > > > > > > > > > > >> > > > > > > > > > > > Ignite JIRA ticket [1] >> > > > > > > > > > > > >> > > > > > > > > > > > Thoughts ? >> > > > > > > > > > > > >> > > > > > > > > > > > [1] >> https://issues.apache.org/jira/browse/IGNITE-8873 >> > > > > > > > > > > > >> > > > > > > > > > > > -- >> > > > > > > > > > > > >> > > > > > > > > > > > Best regards, >> > > > > > > > > > > > Alexei Scherbakov >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > -- >> > > > > > > > > -- >> > > > > > > > > Maxim Muzafarov >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > >> > > > -- >> > > > >> > > > Best regards, >> > > > Alexei Scherbakov >> > > > >> > > >> > >> -- Zhenya Stanilovsky

Ignite 2.7.5 Release scope

;> >> > https://issues.apache.org/jira/browse/IGNITE-11600 >> >> > >> >> > >> >> > чт, 21 мар. 2019 г. в 16:55, Petr Ivanov < mr.wei...@gmail.com >: >> >> > >> >> > > Huge +1 >> >> > > >> >> > > Will try to add new JDK in nearest time to our Teamcity. >> >> > > >> >> > > >> >> > > > On 21 Mar 2019, at 16:27, Dmitriy Pavlov < dpav...@apache.org > >> >> wrote: >> >> > > > >> >> > > > Hi Igniters, >> >> > > > >> >> > > > Meanwhile, Java 12 GA is available. I suggest at least test our >> new >> >> tests >> >> > > > scripts with a couple of Java builds. WDYT? >> >> > > > >> >> > > > Sincerely, >> >> > > > Dmitriy Pavlov >> >> > > > >> >> > > > ср, 20 мар. 2019 г. в 19:21, Dmitriy Pavlov >> < dpav...@apache.org >: >> >> > > > >> >> > > >> Hi Ignite Developers, >> >> > > >> >> >> > > >> In a separate discussion, I've shared a log with all commits. >> >> > > >> >> >> > > >> As far as I can see, nobody removed commits from this sheet, so >> the >> >> > > scope >> >> > > >> of release will be discussed in another way: only explicitly >> >> declared >> >> > > >> commits will be cherry-picked. >> >> > > >> >> >> > > >> Sincerely, >> >> > > >> Dmitriy Pavlov >> >> > > >> >> >> > > >> >> > > >> >> >> > -- Zhenya Stanilovsky

Re: {DISCUSSION] Cluster read-only mode.

hi, Sergey. What's the purpose for ignite-sys-cache updates still be available ? thanks ! Hello Igniters! I'm working on cluster read-only mode [1] feature. In this mode cluster will be available only for read operations, all data modification operations in user caches will be rejected with

Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

> > Unfortunately, >> > > > > > there is a couple of issues still not fixed in that release, so I >> > > >> > > would >> > > > > > like to propose to prepare one more minor release for Apache >> Ignite. >> > > > > > >> > > > > > >> > > > > > >> > > > > > I propose my candidacy to be release manager once again. >> > > > > > >> > > > > > >> > > > > > >> > > > > > I could (of course with help from Peter Ivanov) do some >> additional >> > > > >> > > > efforts >> > > > > > to complete and improve process doc >> > > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process >> > > > > > >> > > > > > >> > > > > > >> > > > > > I propose (most optimistic) dates for release stages: >> > > > > > >> > > > > > Scope Freeze: August 12, 2019 >> > > > > > >> > > > > > Code Freeze: August 15, 2019 >> > > > > > >> > > > > > Voting Date: August 22, 2019 >> > > > > > >> > > > > > Release Date: August 27, 2019 >> > > > > > >> > > > > > >> > > > > > WDYT? >> > > > > > >> > > > > > >> > > > > > If nobody minds, I will create branch 2.7.6 based on 2.7.5 and >> set up >> > > > >> > > > in >> > > > > > the TC Bot during the weekend. >> > > > > > >> > > > > > >> > > > > > >> > > > > > Sincerely, >> > > > > > >> > > > > > Dmitriy Pavlov >> > > > > > >> > > > >> > > > >> > > > >> > > > -- >> > > > Best regards, >> > > > Ivan Pavlukhin >> > > > >> -- Zhenya Stanilovsky

Re: Re[4]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

> > Unresolved tickets are: > IGNITE-12071 Eduard Shangareev > IGNITE-12068 Ivan Pavlukhin > IGNITE-9562 Eduard Shangareev > IGNITE-12057 Anton Kalashnikov > IGNITE-12061 Stanilovsky Evgeny > > Sincerely, > Dmitriy Pavlov > > чт, 15 авг. 2019 г. в 20:12, Zh

Re: Re[4]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

would be an impact on users if we don' include it into 2.7.6? Is it a critical/data loss issue? If not, I agree it can wait for 2.8 release. Sincerely, Dmitriy Pavlov сб, 17 авг. 2019 г. в 12:43, Zhenya Stanilovsky : hi Dmitriy, Ivan Pavlukhin suggest to exclude IGNITE-12061 from 2.7.6, i have

Re[4]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

> > > > > can finalize the timelines based on chosen scope. >> > > > > > >> > > > > > - >> > > > > > Denis >> > > > > > >> > > > > > >> > > > > > On Mon, Aug 12, 2019 a

Re[2]: Asynchronous registration of binary metadata

> Denis >>> >>>> On 14 Aug 2019, at 11:53, Павлухин Иван < vololo...@gmail.com > wrote: >>>> >>>> Denis, >>>> >>>> Several clarifying questions: >>>> 1. Do you have an idea why metadata registration takes so long? So >

Re: Re[4]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

Dmitriy, review passed, plz proceed. thanks ! I removed https://issues.apache.org/jira/browse/IGNITE-12032 until nobody volunteer to complete the task. Evgeniy, please keep me updated about IGNITE-12061. чт, 15 авг. 2019 г. в 16:56, Zhenya Stanilovsky : yep, i`l try to call someone

Re[2]: Asynchronous registration of binary metadata

ill have such >> future, that will reflect the current state of persisting the metadata to >> disk. >> > After that, if some operation needs this binary type, it will need to >> wait on that future until flushing to disk is finished. >> > This way discovery threads won’t be blocked, but other threads, that >> actually need this type, will be. >> > >> > Please let me know what you think about that. >> > >> > Denis >> >> > >-- > >Best regards, >Alexei Scherbakov -- Zhenya Stanilovsky

Re[2]: Replacing default work dir from tmp to current dir

r - Ignite binary distribution already >> > > does it, why should embedded scenario be different? >> > > >> > > In Docker age, packages are becoming extinct. Nobody wants them >> anymore, >> > > anyway. I don't see why we should aim for those since we don't even >> have >> > > very good packages today, and nobody wants to contribute towards their >> > > improvement. >> > > >> > > I also think we should not copy what other DBMS do since their >> > ease-of-use >> > > is usually lacking (this is from someone who had to support mysql and >> > pgsql >> > > deployments). >> > > >> > > Regards, >> > >> -- Zhenya Stanilovsky

Remove setIncludeEventTypes from GridAbstractTest.

. If no objections i plan to set this events only for really requiring tests. thanks! [1] https://issues.apache.org/jira/browse/IGNITE-12122 -- Zhenya Stanilovsky

Re: [VOTE] Release Apache Ignite 2.7.6-rc1

+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification > >This vote will be open for at least 3 days till Sun Aug 25, 18:00 UTC. >https://www.timeanddate.com/countdown/to?year=2019=8=25=18=0=0=utc-1 > >Best Regards, >Dmitriy Pavlov -- Zhenya Stanilovsky

Re[2]: Partition map exchange metrics

issues.apache.org/jira/browse/IGNITE-11961 >> >>>>>>>>>>> >> >>>>>>>>>>> вт, 16 июл. 2019 г. в 14:58, Nikolay Izhikov < >> >>>>> nizhi...@apache.org >> >>>>>>>> : >> >>>>>>>>>>>> I think administator of Ignite cluster should be able to >> >>>>> monitor >> >>>>>>> all >> >>>>>>>>>>> Ignite process, including non blocking PME. >> >>>>>>>>>>>> В Вт, 16/07/2019 в 14:57 +0300, Anton Vinogradov пишет: >> >>>>>>>>>>>>> BTW, >> >>>>>>>>>>>>> Found PME metric - getCurrentPmeDuration(). >> >>>>>>>>>>>>> Seems, it shows exactly PME time and not so useful >> >> because >> >>>> of >> >>>>>>> this. >> >>>>>>>>>>>>> The goal it so show exactly blocking period. >> >>>>>>>>>>>>> When PME cause no blocking, it's a good PME and I see >> >> no >> >>>>>>> reason to have >> >>>>>>>>>>>>> monitoring related to it :) >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> On Tue, Jul 16, 2019 at 2:50 PM Nikolay Izhikov < >> >>>>>>> nizhi...@apache.org > >> >>>>>>>>>>> wrote: >> >>>>>>>>>>>>>> Anton. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Why do we need to postpone implementation of this >> >>>> metrics? >> >>>>>>>>>>>>>> For now, implementation of new metric is very simple. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> I think we can implement this metrics as a single >> >>>>>>> contribution. >> >>>>>>>>>>>>>> В Вт, 16/07/2019 в 13:47 +0300, Anton Vinogradov >> >> пишет: >> >>>>>>>>>>>>>>> Nikita, >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Looks like all we need now is a 1 simple metric: >> >> are >> >>>>>>> operations >> >>>>>>>>>>> blocked? >> >>>>>>>>>>>>>>> Just a true or false. >> >>>>>>>>>>>>>>> Lest start from this. >> >>>>>>>>>>>>>>> All other metrics can be extracted from logs now >> >> and >> >>>> can >> >>>>> be >> >>>>>>>>>>> implemented >> >>>>>>>>>>>>>>> later. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> On Tue, Jul 16, 2019 at 12:46 PM Nikolay Izhikov < >> >>>>>>>>>>> nizhi...@apache.org > >> >>>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> +1. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Nikita, please, go ahead. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> вт, 16 июля 2019 г., 11:45 Nikita Amelchev < >> >>>>>>> nsamelc...@gmail.com >> >>>>>>>>>>>> : >> >>>>>>>>>>>>>>>>> Hello, Igniters. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> I suggest to add some useful metrics about the >> >>>>>>> partition map >> >>>>>>>>>>> exchange >> >>>>>>>>>>>>>>>>> (PME). For now, the duration of PME stages >> >>>> available >> >>>>>>> only in >> >>>>>>>>>>> log >> >>>>>>>>>>>>>> files >> >>>>>>>>>>>>>>>>> and cannot be obtained using JMX or other >> >> external >> >>>>>>> tools. [1] >> >>>>>>>>>>>>>>>>> I made the list of local node metrics that >> >> help to >> >>>>>>> understand >> >>>>>>>>>>> the >> >>>>>>>>>>>>>>>>> actual status of current PME: >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> 1. initialVersion. Topology version that >> >> initiates >> >>>>> the >> >>>>>>>>>>> exchange. >> >>>>>>>>>>>>>>>>> 2. initTime. Time PME was started. >> >>>>>>>>>>>>>>>>> 3. initEvent. Event that triggered PME. >> >>>>>>>>>>>>>>>>> 4. partitionReleaseTime. Time when a node has >> >>>>> finished >> >>>>>>> waiting >> >>>>>>>>>>> for >> >>>>>>>>>>>>>> all >> >>>>>>>>>>>>>>>>> updates and translations on a previous >> >> topology. >> >>>>>>>>>>>>>>>>> 5. sendSingleMessageTime. Time when a node >> >> sent a >> >>>>>>> single >> >>>>>>>>>>> message. >> >>>>>>>>>>>>>>>>> 6. recieveFullMessageTime. Time when a node >> >>>> received >> >>>>> a >> >>>>>>> full >> >>>>>>>>>>> message. >> >>>>>>>>>>>>>>>>> 7. finishTime. Time PME was ended. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> When new PME started all these metrics resets. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> These metrics help to understand: >> >>>>>>>>>>>>>>>>> - how long PME was (current or previous). >> >>>>>>>>>>>>>>>>> - how long awaited for all updates was >> >> completed. >> >>>>>>>>>>>>>>>>> - what node blocks PME (didn't send a single >> >>>> message) >> >>>>>>>>>>>>>>>>> - what triggered PME. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> Thoughts? >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> [1] >> >>>>> https://issues.apache.org/jira/browse/IGNITE-11961 >> >>>>>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>>>>> Best wishes, >> >>>>>>>>>>>>>>>>> Amelchev Nikita >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> -- >> >>>>>>>>>>> Best wishes, >> >>>>>>>>>>> Amelchev Nikita >> >>>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> -- >> >>>>>>>>> Best wishes, >> >>>>>>>>> Amelchev Nikita >> >>>>>>> >> >>>>>>> >> >>>>>>> -- >> >>>>>>> Best wishes, >> >>>>>>> Amelchev Nikita >> >>>>>>> >> >> >> >> >> >> -- >> >> Best wishes, >> >> Amelchev Nikita >> >> >> -- Zhenya Stanilovsky

Re[2]: [VOTE] Apache Ignite PMC Chair

+1 for Nikolay Izhikov.   >Среда, 30 октября 2019, 15:16 +03:00 от Alexey Zinoviev >: >  >+1 Dmitry Pavlov > >ср, 30 окт. 2019 г. в 13:50, Nikolay Izhikov < nizhi...@apache.org >: >  >> +1 for Nikolay Izhikov (binding) >> >> В Вт, 29/10/2019 в 20:13 +0300, Pavel Tupitsyn пишет: >> > +1 for

Re: Adding support for Ignite secondary indexes to Apache Calcite planner

Roman just as fast remark, Phoenix builds their approach on already existing monolith HBase architecture, most cases it`s just a stub for someone who wants use secondary indexes with a base with no native support of it. Don`t think it`s good idea here.     > > >--- Forwarded message

Re: [ANNOUNCE] New committer: Aleksei Scherbakov

Big deal and huge responsibility. Congrats Aleksei! Hello Ignite Community, The Project Management Committee (PMC) for Apache Ignite has invited Aleksei Scherbakov to become a committer and we are pleased to announce that he has accepted. Aleksei investigated and fixed a lot of critical

Re[4]: Text queries/indexes (GridLuceneIndex, @QueryTextFiled)

e. We >can't match that. > >Maybe we could integrate with Solr/Solr Cloud instead, by feeding our cache >information into their storage for indexing and relying on their own >mechanisms for distributed IR sorting? > >Regards, >-- >Ilya Kasnacheev > > >вт,

Re[2]: Text queries/indexes (GridLuceneIndex, @QueryTextFiled)

Ilya Kasnacheev, what a problem in Solr with Ignite functionality ?   thanks !   >Вторник, 26 ноября 2019, 13:50 +03:00 от Ilya Kasnacheev >: >  >Hello! > >I have a hunch that we are trying to build Apache Solr (or Solr Cloud) into >Apache Ignite. I think that's a lot of effort that is not very

Re[2]: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

Folks, The issue [1] already in master, submit minor fix with performance enhancements. i think it`s not risky to gather it too. thanks! [1] https://issues.apache.org/jira/browse/IGNITE-12442   >Пятница, 20 декабря 2019, 16:09 +03:00 от Maxim Muzafarov : >  >Folks, > >The issue [1] has pinned

Re[2]: Cache operations performance metrics

>> Is it become slower or faster? > >Very correct question! User saw "cache put time" metric becomes x2 >bigger. Does it become slower or faster? Or we just put into the cache >values that 4x bigger in size? Or all time before we put values >locally and now we put values on remote nodes. Or our

Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality

I know guys who use this setting (may be erroneously)  = MAX_INT for real rebalance delaying (very small sla) grid without persistence. But i don`t know further algo, may be if backup nodes  become extremely small they creates the same cluster near it. Can ignite simple disable rebalance?  

Re[2]: [DISCUSSION] Deprecation of obsolete rebalancing functionality

>>> Classification: Public >>> >>> Hi, Alexey. >>> I believe it can't be done until in-memory caches will use baseline >>> topology [1]. >>> In our case we are using rebalanceDelay for in-memory caches. >>> >>> [1] https://

Re[4]: [DISCUSSION] Deprecation of obsolete rebalancing functionality

, 12 февр. 2020 г. в 12:18, Zhenya Stanilovsky < arzamas...@mail.ru.invalid >>: > >> >> >> But baseline, it`s about persistence [1] isn`t it? I wrote about >> pure inmemory case. >> >> [1] https://apacheignite.readme.io/docs/baseline-topology >> &

Who can merge excessive backups warning ticket?

Hello, no objections found, plz who can merge it [1]?   [1] https://issues.apache.org/jira/browse/IGNITE-12725      

Excessive backups performance suggestion.

;Anton Vinogradov" < a...@apache.org > >To: dev@ignite.apache.org >Cc: "Zhenya Stanilovsky" < arzamas...@mail.ru > >Subject: Re: Excessive backups performance suggestion. >Date: Thu, 06 Feb 2020 14:11:50 +0300 > >>> most users do not want to lose data b

Excessive backups performance suggestion.

Igniters, i found that suggesting zero backup for performance improvements sounds like malicious and further problems suggestion. May be it`s time to remove it ?   Example: [07:59:27] Performance suggestions for grid (fix if possible) [07:59:27] To disable, set

Cache 6 suite is broken

Looks like i found problem root cause, first run completed on TC, hope it would be ok with other builds.   > > >--- Forwarded message --- >From: "Ivan Pavlukhin" < vololo...@gmail.com > >To: dev < dev@ignite.apache.org > >Cc: >Subject: Re: Cache 6 suite is broken >Date: Fri, 20 Dec 2019

Re: [VOTE] Allow or prohibit a joint use of @deprecated and @IgniteExperimental

-1, sounds confusing, i wan`t use deprecated API and @IgniteExperimental it`s something unknown with undefined «time for support».   >Dear Apache Ignite community, > >We would like to conduct a formal vote on the subject of whether to allow >or prohibit a joint existence of @deprecated

Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

Maxim, performance fix issue [1] already in master, if no objections, can u merge it into 2.8 ? Thanks ! [1] https://issues.apache.org/jira/browse/IGNITE-12547   >Igniters, > > >Here is the actual list of BLOCKER release issues: > >IGNITE-12456 Cluster Data Store grid gets Corrupted for Load

Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

forget about thin client changes, since it will be strange if we >> introduce some methods to thin client API and protocol and in the same >> Ignite version deprecate these methods for servers and thick clients. >> >> [1]: https://issues.apache.org/jira/browse/IGNITE-11709

Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

>>> CVE-2016-131 >>>>>>>> >>>>>> >>> storm-core-1.1.1.jar/META-INF/maven/org.apache.hadoop/hadoop-auth/pom.xml >>>>>>>> (pkg:maven/org.apache.hadoop/hadoop-auth@2.6.1, >>>>>>>> cpe:2

Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

Igniters, i`l try to compare 2.8 release candidate vs 2.7.6, last sha 2.8 was build from :  9d114f3137f92aebc2562a i use yardstick benchmarks, 4 bare machine with:  2x Xeon X5570 96Gb 512GB SSD 2048GB HDD 10GB/s 1 for  client (driver) and 3 for servers. this mappings for graphs and real

Re[2]: Visor plugin

+1 here.   >Hi, All! > >I think that the best way is to do the following: >1. Move controls.sh to separate module (this will allow us to use any third >party libs for argument parsing, interactive mode, and other stuff). >2. Move all colde from visorcmd to controls.sh >3. Drop visorcmd > >On

Apache Ignite 2.8.1 RELEASE [Time, Scope, Manager]

This ticket is very important too, as for me [1] Anton Kalashnikov, what do you think ?   [1] https://issues.apache.org/jira/browse/IGNITE-12801 >Folks, > >I'd like to add ticket IGNITE-12805 "NullPointerException on node restart >when 3rd party persistence and Ignite native persistence are

Who can update TC Bot version.

ew version to the server (since it is now sponsored by >> GrigGain, we need someone who will deploy). >> >> Sincerely, >> Dmitriy Pavlov >> >> пн, 23 мар. 2020 г. в 08:59, Zhenya Stanilovsky < arzamas...@mail.ru >: >> >>> Igniters, 2.8 version

Possible concurrency bug in GridCacheLockImpl

Ivan, i found that mentioned problem correctly highlighted, if we still not  step on this rake, its probably due to some locks above, anyway it would be correct to fix this part. Are you fill the ticket ?   > > >--- Forwarded message --- >From: "Ivan Daschinsky" < ivanda...@gmail.com >

Re: Proposal: set default transaction timeout to 5 minutes

+1 here. Hi Igniters, I have a very simple proposal. Let's set default TX timeout to 5 minutes (right now it's 0 = no timeout). Pros: 1. Deadlock detection procedure is triggered on timeout. In case user will get into key-level deadlock, he'll be able to discover root cause from the logs

Re: IGNITE-6499 Compact NULL fields

Good catch Steve ! I also think about that. Ticket unassigned — you can proceed with it. Also you need to ask your jira account for granting rights for further ticket assignation. High level review can make i (@zstan) and probably (@ivandasch). Also you need to explain how to run new

Discuss idle_verify with moving partitions changes.

Igniters, i found that near idle check commands only shows partitions in MOVING states as info in log and not take into account this fact as erroneous idle cluster state. control.sh --cache idle_verify, control.sh --cache validate_indexes --check-crc   for example command would show something

Re[2]: Discuss idle_verify with moving partitions changes.

>> operation of cache happened. >> >> May be enough showing some message more clear for end user. For example: >> "Result has not valid, rebalance is going." >> >> Another thing you meaning - issue in indexes, when rebalance is following. >> I think ide

Who can update TC Bot version.

Igniters, 2.8 version already released, but looks like TC bot [1] [2] still using 2.7.6 ver. , who can update it ? Thanks !   [1]  https://github.com/apache/ignite-teamcity-bot [2] https://mtcga.gridgain.com/      

Re[2]: [DISCUSS] Ignite process exit code on node stop by failure handler

Thank you Sergey, as for me — very useful proposal huge +1 here.   >Четверг, 21 мая 2020, 0:51 +03:00 от Sergey Antonov >: >  >I've created the Ignite ticket for this improvement [1]. > >[1] https://issues.apache.org/jira/browse/IGNITE-13047 > >чт, 21 мая 2020 г. в 00:46, Sergey Antonov <

Re[2]: Proposal: set default transaction timeout to 5 minutes

Ivan, does global timeout change through jmx in scope of this ticket ? If so, can you add it ? Opposite we need additional ticket, i hope ? We still have no somehow store for jmx changed params, every one need to remember that cluster restart will reset this setting to default, in this case

Cpp thin client transactions support ready for review.

t;On Mon, Aug 24, 2020 at 8:33 AM Zhenya Stanilovsky >< arzamas...@mail.ru.invalid > wrote: > >> >> >> Thanks Ivan Daschinsky for review, does anyone more who could check it ? >> >> thanks ! >> >Igniters, seems i complete with transactions in thin c

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

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:

Re[6]: Thin Client ping operation?

tors. >  >[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 < >arza

Re: Broken test in master: BasicIndexTest

Thanks Maxim, the test is correct no need for removal. I checked 2.9 too, but looks it all ok there. I will take a look. >Hi, Igniters! > >I was discovering how indexes work and found a failed test. >BasicIndexTest#testInlineSizeChange is broken in master and it's not a >flaky case [1]. But it

Re: [VOTE] Release Apache Ignite 2.9.0 RC4

build with checkstyle from sources is failed: Starting audit... [ERROR] /home/zstan/Downloads/apache-ignite-2.9.0-src/modules/indexing/src/test/java/org/apache/ignite/internal/processors/query/WrongQueryEntityFieldTypeTest.java:35:8: Unused import - org.apache.ignite.client.ClientException.

Re[2]: [VOTE] Release Apache Ignite 2.9.0 RC4

d scripts to check compilation with enabled checkstyle for >future releases.  >Guys, WDYT?   >чт, 15 окт. 2020 г. в 16:21, Zhenya Stanilovsky < arzamas...@mail.ru.invalid >: >  >>build with checkstyle from sources is failed: >>Starting audit... >>[ERROR] >>/h

Re[2]: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

without [2] and [3] we obtain unexpected fields in index creation and as a consequence buggy sql execution and pla of course.   >Guys, > >I've found 3 more tickets which were targeted to 2.9 but merged only to the >master branch ([1], [2], [3]). >Do we need these tickets in 2.9? Are they

Re[2]: IEP-58: Statistics

Andrey, thanks for firing this !  Sasha it`s unclear for me « These part consists of two processes: statistics collection process itself and acquiring statistics by the client. »: * I agree that in both cases local statistics are useless. May be we need more informative use cases for such

Re[2]: Broken test in master: BasicIndexTest

s problem to me. > >--  >Best regards, >Anton Kalashnikov > > > >09.10.2020, 10:19, "Sergey Chugunov" < sergey.chugu...@gmail.com >: >> Max, >> >> Thanks for spotting this, great catch! >> >> Zhenya, could you please file a ticket o

Re[2]: Exception handling in thin client: should we pass stack traces to the client?

Thanks ! now its clear for me, ones more want to repeat my position — sending exceptions to the client side looks like bad design, because exceptions its about unhealthy system recognition from administrator side, not from client of course, but looks like for now it`s more informative than

[SQL] Correct index usage with primary key constraint.

Folks, want to pay your attention that after [1] was merged into master, primary key index usage became predictable and correct and as a consequence old behavior was broken.   for example table creation: CREATE TABLE PUBLIC.T1 (F1 VARCHAR, F2 VARCHAR, F3 VARCHAR, CONSTRAINT PK PRIMARY KEY (F2,

Re: Update of the default inline size for variable types

>Hi guys,   Evgeniy, hola! > >Currently if a varlength type (such as String or byte[]) is encountered in >the composite index inline size just defaults to 10, which is almost always >not enough. I am going to change this and implement following changes: > >1) For a column of the variable length

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Good catch, as for me, do you plan some autogeneration here?   >  >>  >>>Hello, Igniters. >>> >>>For now, we have dozens of the `IgniteSystemProperties` [1] that can tweak >>>Ignite behaviour in the very wide limits. >>>But, the issue, for the administrator is the following >>> >>>-

Exception handling in thin client: should we pass stack traces to the client?

I want to resurrect this discussion, i don`t understand what sensitive information you are talking about ? Can you show some examples or something else ? I never listen that thread dumps belong to sensitive info. I believe that one linear error can`t help user to recognize problem and logs

Re[2]: Update of the default inline size for variable types

Earlier I remember we panned to replace inline value to hash code in the >> > case where size of value more than inline size. >> > It will help to comparison of "==", "!=", but will not grow size of >> > storage. >> > >> > I think optimi

Exception handling in thin client: should we pass stack traces to the client?

apache.org > wrote: >  >> Link to the original discussion: >> >> >> >> http://apache-ignite-developers.2346864.n4.nabble.com/Exception-handling-in-thin-client-should-we-pass-stack-traces-to-the-client-td22392.html >> >> On Thu, Aug 20, 2020 at 4:46 PM Z

Cpp thin client transactions support ready for review.

Thanks Ivan Daschinsky for review, does anyone more who could check it ?    thanks ! >Igniters, seems i complete with transactions in thin cpp client >implementation [1], part of iep-34 [2]. >Can anyone review my decision ? >Failed test seems not mine, looks like after fresh master rebase it

Re[4]: IGNITE-6499 Compact NULL fields

Compress of whole binary inside ignite.   >Sorry I do not actual get what are you opposing? the compress of the binary >or the null compaction or both? >And can you ellaborate on why you are opposing it? > > > >-- >Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/        

Re[2]: IGNITE-6499 Compact NULL fields

I`m currently against this approach, everyone can previously compress Binary Object for further using,  no additional code need here. This discussion only about currently not optimal null storing and looks like we can improve it without performance pay.     >Понедельник, 25 мая 2020, 13:42

Re[2]: [VOTE] Release Apache Ignite 2.8.1 RC1

Nikolay, performance boost is always good news for all customers at all and for me too ) Can you give more info (looks like in different mail thread) ? What kind of benchmarks have been done, is it about persistence or both ? thanks ! >+1 (binding). > >We made some internal benchmarking and

Re: [DISCUSSION] Ignite.C++ and CMake

Ivan huge +1 with your proposal. I had some problems with odbc tests building too, looks like cmake will make it more easy. >Hello Igniters. > >I’d like to discuss porting build process of Ignite.C++. I think that there is >time to change it. > >*Motivation* >Currently, it is hard to build

Re[2]: [DISCUSSION] Ignite.C++ and CMake

tests? I found one flag that must be >> supplied to boost.tests. >> This flag should fix JVM crash of C++ suites on Linux. >> >> Zhenya Stanilovsky and me have checked, that without this flag tests failed >> with SIGSEGV early (boost catch this signal from jvm, but it is

Re[4]: Proposal: set default transaction timeout to 5 minutes

t TX timeout via JMX? It looks feasible and >perhaps may work as a hotfix for live deployments experiencing issues with >long transactions, but it's definitely a separate issue. > >On Fri, May 22, 2020 at 6:20 PM Zhenya Stanilovsky >< arzamas...@mail.ru.invalid > wrote: >  &g

Re: [DISCUSSION] Add autocompletion for commands in control.sh

good catch ! it`s a little bit pain for now to working with it.   >Hi, Igniters! > >At the moment to work with the control.sh we need to know exactly what the >name of the command and its options are and so the user can often make >mistakes when using it. So I think it would be useful to do

Re[2]: Please grant me privileges to edit ignite wiki pages.

Ilya, thanks !  full name : evgeny stanilovsky , short : zstan   >  >>  >>>Hello! >>> >>>Do you have a Wiki account? What's its username? >>> >>>Thanks, >>>-- >>>Ilya Kasnacheev >>> >>> >>>чт

Re[2]: new connection event

may be jmx would be enough here ?   >Hello! > >Why not the Failure Handler then? > >(I'm only half-joking). > >Regards, > >-- >Ilya Kasnacheev > > >ср, 12 авг. 2020 г. в 09:54, Oleg Ostanin < oleg.alex.osta...@gmail.com >: >  >> Thank you for the response. Yes, we have a simple warning in log,

Cpp thin client transactions support ready for review.

  Igniters, seems i complete with transactions in thin cpp client implementation [1], part of iep-34 [2]. Can anyone review my decision ? Failed test seems not mine, looks like after fresh master rebase it will gone.   [1]  https://issues.apache.org/jira/browse/IGNITE-13308 [2] 

Please grant me privileges to edit ignite wiki pages.

I`m currently working on cpp thin client transactions support [1] and need to edit, for example this page [2]. Can someone grant me this privileges ? thanks !   [1]  https://issues.apache.org/jira/browse/IGNITE-13308 [2] https://cwiki.apache.org/confluence/display/IGNITE/Thin+clients+features    

Re[2]: Request for contributors permissions

now its all ok, i rerun your pr here :  https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll_IgniteTests24Java8=pull%2F7906%2Fhead=buildTypeStatusDiv   >Hi Ivan, > >let me first apologize for the question, sure they are stupid and I am >missing something obvious but

Re: IGNITE-6499 Compact NULL fields

Steve i place some comments in ticket, still have no response.   > > >--- Forwarded message --- >From: " steve.hostett...@gmail.com " < steve.hostett...@gmail.com > >To: dev@ignite.apache.org >Cc: >Subject: Re: Re[4]: IGNITE-6499 Compact NULL fields >Date: Fri, 12 Jun 2020 16:15:37

Re[2]: IGNITE-6499 Compact NULL fields

request it, check for example [1]   also you need to run [2] tests.   [1]  http://apache-ignite-developers.2346864.n4.nabble.com/Phani-Introduction-td47788.html [2] https://mtcga.gridgain.com  >Hello, > >Look at the ticket and the only comment I can see is creating a branch on >git in the main

Re[2]: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

  Alex, i also suggest to merge this  https://issues.apache.org/jira/browse/IGNITE-13229 too, GridClient leakage and further TC OOM preventing.   >Ivan, > >It was already in release scope as discussed in this thread. > >вт, 14 июл. 2020 г. в 14:31, Ivan Rakov < ivan.glu...@gmail.com >: >  >>

Re[2]: [DISCUSS] Extra test coverage for ACTIVE_READ_ONLY cluster state

Sergey, changes looks good to me.   >Четверг, 4 июня 2020, 12:39 +03:00 от Sergey Antonov >: >  >Igniters, I faced several problems during write tests for the read-only >mode: > >   1. You can create/destroy cache on the read-only cluster. Fixed in [1]. >   2. The read-only mode doesn't affect

Re: [DISCUSSION] Cache warmup

Looks like we need additional func for static caches, for example:  warmup(List cconf) it would be helpful for spring too.   > >--- Forwarded message --- >From: "Вячеслав Коптилин" < slava.kopti...@gmail.com > >To: dev@ignite.apache.org >Cc: >Subject: Re: [DISCUSSION] Cache warmup >Date:

Re[2]: 2.9.1 release scope and dates

hello ! seems it [1] need to be included too, if it`s not too late, of course. May be you can bump reviewer somehow?)   [1]  https://issues.apache.org/jira/browse/IGNITE-13765   >Ivan, it's added, thanks for pointing that out > >On Mon, Nov 30, 2020 at 5:44 PM Ivan Daschinsky <

Re[2]: [DISCUSSION] Modules organization in Ignite 3

Hello Nikolay, if i find out introduced features structure in some project, i would prefer to choose different one )   >  >>  >>>Hello, Alexey. >>> >>>Think we can extend our @IgniteExperimental annotation. >>> >>>`@IgniteExperimental` - mark features that are truly experimental and can be

Re[2]: [DISCUSS] Page replacement improvement

ce more, do you really observe such problems with 2.9 ver ? >Any graphs maybe ? >I don't have production usage feedback after IGNITE-13086, but I doubt >something changed significantly.   Lets wait ?:) In any case (Nikolay, Alex) IGNITE-13086 includes yardstik bench for PR proven, we can u

[DISCUSS] Page replacement improvement

Alexey, we already have changes that partially fixes this issue [1] Easy way: Looks like we already have converge in page replacement. If we change 5 times touch iterator from random lru algo into, for example — 7 we will obtain fast improvement from scratch.   » Batch page replacement This

Re[2]: [DISCUSS] Page replacement improvement

ence ? >> As I described before, we can implement both manual and automatic "batch >> page replacement" triggering. For automatic triggering, there is no >> artificial intelligence needed, just several conditions with reasonable >> thresholds. Automatic triggering also can be d

Re: Hard limit WAL archive size

Hello ! this is unclear for me, all you described near brings no info why node work improperly and why FH can possibly fail this node. Can you explain ?   >Hello, everyone! > >Currently, property DataStorageConfiguration#maxWalArchiveSize is not working >as expected by users. We can easily go

[DISCUSSION] Request for thread unsafe Compute functionality deprecation.

Hello Igniters ! In the process of Ignite usage i found that some part of Compute functionality  are thread unsafe and seems was designed with such limitations initially. Example : one (client, but it doesn`t matter at all) instance is shared between numerous of fabric, all of them calls

Re[2]: [DISCUSSION] Request for thread unsafe Compute functionality deprecation.

/master/modules/core/src/test/java/org/apache/ignite/internal/IgniteExplicitImplicitDeploymentSelfTest.java#L221   >  >>  >>>Hello! >>> >>>Do you have some kind of reproducer which demonstrates the issue? >>> >>>Regards, >>>-- &g

Re: [DISCUSSION] Fail on non-colocated join

Maxim it`s cool that it`s moved :) +1 for exception, but take into account such use case : T1 (country, city)  affinity_key=country  and T2 (country,city)  affinity_key=country join with «city» usage — will be correct here (i hope, need to recheck of course) thus seems you must give some

Re[4]: [DISCUSSION] Fail on non-colocated join

>https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist > >It's checklist, 1b. > >Regards, >-- >Ilya Kasnacheev > > >ср, 3 февр. 2021 г. в 14:48, Zhenya Stanilovsky < arzamas...@mail.ru.invalid >>: > >> >> >> >> >> &

Re[2]: [DISCUSSION] Fail on non-colocated join

  >If it breaks existing working code it may not be done that way.   Who reads the logs ?  Is it violates apache way approach or some existing rules ?   thanks !     >Regards, >-- >Ilya Kasnacheev > > >ср, 3 февр. 2021 г. в 09:05, Zhenya Stanilovsky < ar

Re[2]: [Discussion] Apache Ignite 2.11 Scope Freeze

Hi ! I found that very important issue [1] (already in master) is not planned to be in 2.11, may be it still possible to take it into scope ?   thanks !   [1]  https://issues.apache.org/jira/browse/IGNITE-14739   >Hi Folks, > >Branch divergence has been completed. Sorry for the delay, it was my

Re: [DISCUSS] Python thin client development approach.

Ivan, if Petr can`t help here, how can  we change it out own ? May be we need some help from pmc chair or someone else ?   >  >> >>Igniters. Almost half of a year passed since this thread begun. We >>released 0.4.0, we adopted travis-ci and use it as primary source for >>test results but nothing

[DISCUSSION] Transactional cache could be in inconsistent state after node recovery.

Igniters, as previously was found [1] in some cases transactional cache can contain unexpected data after node crash and further recovery. Short explanation: it`s all due to ignite does not save transactional records into the WAL. The simplest example: 1 node cluster and transactional cache,

Re[2]: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output

-1 for extra arg, +1 for Ivan`s upper proposal : @IgniteSystemProperty annotation. Look, someone will set some of IGNITE_* option and after possibly cluster problems will give this logs into analysis and engineer can`t reproduce such a case, cause no param is applied.   >An extra argument for

Re[2]: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output

+1 for reverting, can anybody (possibly ticket starter?) explain how jvm settings will rise some security problems ?   >I suppose, that we should revert this particular line. I don't understand >who ever considers vm options as sensitive info. > >ср, 30 июн. 2021 г., 22:52 Shishkov Ilya <

  1   2   >