GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/4818
IGNITE-9451: Cache.size for key-value API
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9451
Alternatively
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/4873
IGNITE-5935: MVCC transaction recovery
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-5935
Alternatively you
Github user pavlukhin closed the pull request at:
https://github.com/apache/ignite/pull/4818
---
Github user pavlukhin closed the pull request at:
https://github.com/apache/ignite/pull/4873
---
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/4904
IGNITE-9783: MVCC: Track all nodes participating in transaction
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/4913
IGNITE-5935: WIP server origin transactions recovery
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-5935-wip2
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/4920
IGNITE-5935: WIP client origin transactions recovery
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-5935-wip3
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5040
IGNITE-9944: GridDhtTxAbstractEnlistFuture near nodes update race
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5042
Investigation: Queries (Binary Objects Simple Mapper)
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite investigation1
Github user pavlukhin closed the pull request at:
https://github.com/apache/ignite/pull/5042
---
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5065
Limit test execution time to 10 sec
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite 10sec-test-limit
Alternatively
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5074
IGNITE-9622: MVCC Cache API: prohibit non PESSIMISTIC REPEATABLE_READ
transactions
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5086
IGNITE-9982: SQLLine: can't run with option --autoCommit=false or true
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/a
Github user pavlukhin closed the pull request at:
https://github.com/apache/ignite/pull/5065
---
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5192
IGNITE-10024: MVCC TX: Stackoverflow during DhtEnlistFuture mapping
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5201
IGNITE-10007: Deactivation hangs if an open transaction exists
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5220
Pre-touch off-heap memory
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite
off-heap-pre-touch-spike
Alternatively
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5222
IGNITE-8987: Fix testSequenceAfterAutoactivation
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8987-fix
Github user pavlukhin closed the pull request at:
https://github.com/apache/ignite/pull/5222
---
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5230
IGNITE-10103: Fix
IgnitePersistentStoreDataStructuresTest.testSequenceAfterAutoactivation
You can merge this pull request into a Git repository by running:
$ git pull https://github.com
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5284
IGNITE-7955: MVCC TX: cache peek for key-value API
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-7955
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5326
Test drive Junit4
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite junit4
Alternatively you can review and apply
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5354
Juni4 fast and rude approach
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite juni4-rude
Alternatively you can review
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5357
IGNITE-10167: MVCC-compatible IgniteCache.localEntries
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10167
Github user pavlukhin closed the pull request at:
https://github.com/apache/ignite/pull/5354
---
Github user pavlukhin closed the pull request at:
https://github.com/apache/ignite/pull/5326
---
Github user pavlukhin closed the pull request at:
https://github.com/apache/ignite/pull/4913
---
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5419
Measure grid start/stop overhead in tests
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite
measure-grid-start-stop
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5579
IGNITE-9322: MVCC deadlock detection
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9322
Alternatively you
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5586
Static factory method approach for IGNITE-8227
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite
ignite-8227-ivan
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/4622
Ignite-8149-tc
For Team City.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8149-2
Alternatively you can
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/4631
Ignite-8149-2-merged-tc
For Team City.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8149-2-merged-tc
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/4654
IGNITE-8149: MVCC TX: Size method should use tx snapshot
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8149
Github user pavlukhin closed the pull request at:
https://github.com/apache/ignite/pull/4631
---
Github user pavlukhin closed the pull request at:
https://github.com/apache/ignite/pull/4622
---
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/4728
IGNITE-9516: workaround hanging vacuum after test
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9516
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/4743
IGNITE-8149: fix for CI
Fail DataStreamProcessorMvccSeflTest referring to IGNITE-9451 and mention
same ticket in GridDhtPartitionsStateValidator.
You can merge this pull request into a Git
Github user pavlukhin closed the pull request at:
https://github.com/apache/ignite/pull/4743
---
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/4745
IGNITE-9411: mvcc timeouts
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9411
Alternatively you can review
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/4772
Refine CacheAtomicityMode.TRANSACTIONAL_SNAPSHOT javadoc
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite
mvcc
Github user pavlukhin closed the pull request at:
https://github.com/apache/ignite/pull/4772
---
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/4777
Refine CacheAtomicityMode.TRANSACTIONAL_SNAPSHOT javadoc
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9624
eed 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 06:06:54 20-02-2021
>
> --
> Regards,
>
> Atri
> Apache Concerted
>
--
Best regards,
Ivan Pavlukhin
15 Mar 2021 at 17:25, Ilya Kasnacheev <
>> ilya.kasnach...@gmail.com
>> > >
>> > > wrote:
>> > > >
>> > > > Hello!
>> > > >
>> > > > When adding new users to the Contributor role, we usually give them
>> > > > a
>> > > link
>> > > > to "How to Contribute" wiki page.
>> > > >
>> > > > However, I was feeling that it was in many ways outdated, referring
>> to
>> > > > outdated development practices and not emphasising TC tests and
>> > > > MTCGA
>> > > bot.
>> > > >
>> > > > So we took liberty to rewrite this page, meet
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute+2021
>> > > >
>> > > > We tried to streamline it, make it more friendly to newcomers and
>> just
>> > > > shorter.
>> > > >
>> > > > Please check it out, share your feelings.
>> > > >
>> > > > I plan to replace the legacy
>> > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>> > > with
>> > > > this page based on your feedback..
>> > > >
>> > > > Regards,
>> > > > --
>> > > > Ilya Kasnacheev
>> > >
>> >
>>
>
--
Best regards,
Ivan Pavlukhin
; > > configuration (importation of checkstyle.xml to the IDE).
>> > >> > >
>> > >> > I would be glad if somebody contributes to it, or we may just
>> > >> > provide
>> > a
>> > >> > link to coding guidelines and mention it there.
>> > >> >
>> > >> >
>> > >> >
>> > >> > > > GIT workflow
>> > >> > >
>> > >> > > Do we need it?
>> > >> > >
>> > >> > I think we do, this workflow is non-trivial and I don't think it
>> > >> > is
>> > >> > documented anywhere. We can get rid of ASCII art section, though.
>> > >> >
>> > >> > WDYT?
>> > >> >
>> > >> > Regards,
>> > >> >
>> > >> >
>> > >> > >
>> > >> > >
>> > >> > > On Mon, 15 Mar 2021 at 17:25, Ilya Kasnacheev <
>> > >> ilya.kasnach...@gmail.com
>> > >> > >
>> > >> > > wrote:
>> > >> > > >
>> > >> > > > Hello!
>> > >> > > >
>> > >> > > > When adding new users to the Contributor role, we usually give
>> > them
>> > >> a
>> > >> > > link
>> > >> > > > to "How to Contribute" wiki page.
>> > >> > > >
>> > >> > > > However, I was feeling that it was in many ways outdated,
>> > referring
>> > >> to
>> > >> > > > outdated development practices and not emphasising TC tests
>> > >> > > > and
>> > >> MTCGA
>> > >> > > bot.
>> > >> > > >
>> > >> > > > So we took liberty to rewrite this page, meet
>> > >> > > >
>> > >> > >
>> > >> >
>> > >>
>> > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute+2021
>> > >> > > >
>> > >> > > > We tried to streamline it, make it more friendly to newcomers
>> > >> > > > and
>> > >> just
>> > >> > > > shorter.
>> > >> > > >
>> > >> > > > Please check it out, share your feelings.
>> > >> > > >
>> > >> > > > I plan to replace the legacy
>> > >> > > >
>> > >> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>> > >> > > with
>> > >> > > > this page based on your feedback..
>> > >> > > >
>> > >> > > > Regards,
>> > >> > > > --
>> > >> > > > Ilya Kasnacheev
>> > >> > >
>> > >> >
>> > >>
>> > >
>> >
>
--
Best regards,
Ivan Pavlukhin
ionStage() to restrict harmful method usage.
>> > >>>>>> Thus, this look like an applicable solution, but we should be
>> > >> careful
>> > >>>>>> exposing internal future to the outside.
>> > >>>>>>
>> > >>>>>> 2. The second approach is to implement our own interface like
>> > >>>>>> the
>> > >>> next
>> > >>>>> one:
>> > >>>>>>
>> > >>>>>> interface IgniteFuture extends CompletableStage, Future
>> > >>>>>> {
>> > >>>>>> }
>> > >>>>>>
>> > >>>>>> Pros and cons are
>> > >>>>>> + Our interfaces/classes contracts will expose an interface
>> > >>>>>> rather
>> > >>> than
>> > >>>>>> concrete implementation.
>> > >>>>>> + All methods are safe.
>> > >>>>>> - Some implementation is required.
>> > >>>>>> - CompletableStage has a method toCompletableFuture() and can be
>> > >>>>> converted
>> > >>>>>> to CompletableFuture. This should be supported.
>> > >>>>>>
>> > >>>>>> However, we still could wrap CompletableFuture and don't bother
>> > >> about
>> > >>>>>> creating a defensive copy.
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> Other project experience:
>> > >>>>>> * Spotify uses CompletableFuture directly [1].
>> > >>>>>> * Redis goes the second approach [2]
>> > >>>>>> * Vertx explicitly extends CompletableFuture [3]. However, they
>> > >> have
>> > >>>>> custom
>> > >>>>>> future classes and a number of helpers that could be replaced
>> > >>>>>> with
>> > >>>>>> CompletableStage. Maybe it is just a legacy.'
>> > >>>>>>
>> > >>>>>> Any thoughts?
>> > >>>>>>
>> > >>>>>> [1]
>> > >>>>>>
>> > >>>>>>
>> > >>>>>
>> > >>>>
>> > >>>
>> > >>
>> >
>> https://spotify.github.io/completable-futures/apidocs/com/spotify/futures/ConcurrencyReducer.html
>> > >>>>>> [2]
>> > >>>>>>
>> > >>>>>>
>> > >>>>>
>> > >>>>
>> > >>>
>> > >>
>> >
>> https://lettuce.io/lettuce-4/release/api/com/lambdaworks/redis/RedisFuture.html
>> > >>>>>> [3]
>> > >>>>>>
>> > >>>>>>
>> > >>>>>
>> > >>>>
>> > >>>
>> > >>
>> >
>> https://javadoc.io/static/org.jspare.vertx/vertx-jspare/1.1.0-M03/org/jspare/vertx/concurrent/VertxCompletableFuture.html
>> > >>>>>> --
>> > >>>>>> Best regards,
>> > >>>>>> Andrey V. Mashenkov
>> > >>>>>>
>> > >>>>>
>> > >>>>
>> > >>>>
>> > >>>> --
>> > >>>>
>> > >>>> Best regards,
>> > >>>> Alexei Scherbakov
>> > >>>>
>> > >>>
>> > >>
>> > >>
>> > >> --
>> > >> Best regards,
>> > >> Alexey
>> > >>
>> >
>> >
>>
>> --
>> Best regards,
>> Andrey V. Mashenkov
>>
>
--
Best regards,
Ivan Pavlukhin
ow that I have worked on some issues, I would like to get my hands
>> deeper
>> and with larger issues in the core. Also, some more intermediate tickets
>> to
>> tackle, my queue has gotten empty :)
>>
>> Please help and advice.
>>
>> Regards,
>>
>> Atri
>
--
Best regards,
Ivan Pavlukhin
3, returning
> CompletableFuture is surely wrong in my view.
>
> At the same time, if we take a fundamentally different route with the async
> APIs, this whole discussion might become irrelevant. For example, can you
> elaborate on your thinking around the reactive API? Do you have
t; > > harm.
>> > > > > > >
>> > > > > > > вт, 30 мар. 2021 г. в 13:14, Andrey Mashenkov <
>> > > > > > andrey.mashen...@gmail.com
>> > > > > > > >:
>> > > &
xample.
> Reactive abstractions look more suitable for Queries rather than
> cache/table async operations and don't offer the power of chaining like
> CompletableStage.
> AFAIK, guys who involved in SQL engine development based on Calcite already
> use reactive patterns.
>
&g
/docs/core/release/api/reactor/core/publisher/Mono.html#fromFuture-java.util.concurrent.CompletableFuture-
> [2]
> https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/internal/jdk8/CompletableFromCompletionStage.java
>
> On Thu, Apr 1, 2021 at 1:29 PM Ivan P
ith all the
> examples for the table, transaction, compute APIs?
> WDYT?
>
> [1]
> https://stackoverflow.com/questions/43389894/recursively-cancel-an-allof-completablefuture
>
> On Sat, Apr 3, 2021 at 1:40 AM Ivan Pavlukhin wrote:
>
>> Andrey,
>>
>>
ve community member.
>>>
>>> Being a committer enables easier contribution to the project since there
>>> is
>>> no need to go via the patch submission process. This should enable
>>> better
>>> productivity.
>>>
>>> Please join me in welcoming Ivan, and congratulating him on the new role
>>> in
>>> the Apache Ignite Community.
>>>
>>> Best Regards,
>>> Igor
>>
>>
>>
>>
>
>
--
Best regards,
Ivan Pavlukhin
; > subscribe to these messages in their JIRA account settings. I imagine
>> > most
>> > > of you already filter these messages out, so you may need to adjust
>> > > your
>> > > filters slightly.
>> > >
>> > > A distant second is MTCGA messages, which are also autogenerated and
>> > > not
>> > > informative for most readers of the channel, since they are at best
>> > > targeted at a single committer and at worst flaky.
>> > >
>> > > Where could we move those? What is your opinion here, on both issues?
>> > >
>> > > Regards,
>> >
>> > --
>> > Regards,
>> >
>> > Atri
>> > Apache Concerted
>> >
>
--
Best regards,
Ivan Pavlukhin
her exclude tests from style checks at all, which looks
> like not a good idea,
> or have different configs with different policies for source and test code.
>
> Any thoughts?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-14591
> [2] https://github.com/apache/ignite-3/pull/98
> [3] http://openjdk.java.net/jeps/8068562
>
> --
> Best regards,
> Andrey V. Mashenkov
>
--
Best regards,
Ivan Pavlukhin
;> > > example.
>> > > > > >
>> > > > > > We already have issues@ mailing list. I propose that we stop
>> > > sending any
>> > > > > > JIRA emails to dev@. If anyone wishes to get just Created
>> emails,
>> > > they
>> > > > > can
>> > > > > > subscribe to these messages in their JIRA account settings. I
>> > imagine
>> > > > > most
>> > > > > > of you already filter these messages out, so you may need to
>> adjust
>> > > your
>> > > > > > filters slightly.
>> > > > > >
>> > > > > > A distant second is MTCGA messages, which are also
>> > > > > > autogenerated
>> > and
>> > > not
>> > > > > > informative for most readers of the channel, since they are at
>> best
>> > > > > > targeted at a single committer and at worst flaky.
>> > > > > >
>> > > > > > Where could we move those? What is your opinion here, on both
>> > issues?
>> > > > > >
>> > > > > > Regards,
>> > > > >
>> > > > > --
>> > > > > Regards,
>> > > > >
>> > > > > Atri
>> > > > > Apache Concerted
>> > > > >
>> > >
>> >
>>
>
--
Best regards,
Ivan Pavlukhin
tter I siggest improving analysis to avoid odd
> emails and leave only relevant
>
> чт, 22 апр. 2021 г., 18:16 Ivan Pavlukhin :
>
>> > All issues notifications are also sent to iss...@ignite.apache.org so
>> one can subscribe to this list in order to track the created
-26 12:28 GMT+03:00, Ilya Kasnacheev :
> Hello!
>
> I have added you to "Contributors 1" role. Everybody in this role will
> still get those "issue created" e-mail.
>
> Feel free in asking me to enlist.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
&
;> вт, 27 апр. 2021 г. в 11:39, Dmitriy Pavlov :
>>
>> > I guess so. It was always not clear for me why do we have 'contributors
>> > 1'
>> > role.
>> >
>> > It might worth to rename role itself to contibutors with notifications.
>&g
gt; > >> >
>> > >> > Regards,
>> > >> > --
>> > >> > Ilya Kasnacheev
>> > >> >
>> > >> >
>> > >> > чт, 15 апр. 2021 г. в 11:30, Nikolay Izhikov < nizhi...@apache.org
>> > >> > >:
>> > >> > Hello, Igniters.
>> > >> >
>> > >> > Right now, we have a code style rule [1] - the line should fit in
>> > >> > 120
>> > >> characters.
>> > >> > But, this rule violated in many and many places through code.
>> > >> > I have a plan to add a check style rule to force maximum line
>> > >> > length.
>> > >> >
>> > >> > For me, personally, 120 characters a bit old-fashioned
>> > >> > restriction.
>> > >> > Should we increase the maximum line length to 150 or even 180
>> > characters?
>> > >> >
>> > >> > [1]
>> > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
>> > >> >
>> > >>
>> > >>
>> > >--
>> > >Sincerely yours, Ivan Daschinskiy
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> Sincerely yours, Ivan Daschinskiy
>
--
Best regards,
Ivan Pavlukhin
dependencies. I downgraded to
>> > Maven
>> > 3.8.0 with no change to the result.
>> >
>> > Is there an easy work around for this?
>> >
>> > Thanks,
>> > Raymond.
>> >
>> >
>> > --
>> > <http://www.trimble.com/>
>> > Raymond Wilson
>> > Trimble Distinguished Engineer, Civil Construction Software (CCS)
>> > 11 Birmingham Drive | Christchurch, New Zealand
>> > raymond_wil...@trimble.com
>> >
>> > <
>> >
>> https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch
>> > >
>> >
>>
>
>
> --
> <http://www.trimble.com/>
> Raymond Wilson
> Trimble Distinguished Engineer, Civil Construction Software (CCS)
> 11 Birmingham Drive | Christchurch, New Zealand
> raymond_wil...@trimble.com
>
> <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
>
--
Best regards,
Ivan Pavlukhin
ername*Korol*.
>
> Thanks!
>
>
--
Best regards,
Ivan Pavlukhin
ing it up-to-date in the repository. Also
> it's impossible to tell right now if it is or it is not up-to-date (without
> executing ClassesGenerator).
>
> Kind regards, Semyon.
>
--
Best regards,
Ivan Pavlukhin
t.java:97:
>> > > >>>>>>>> Abbrevation should be used for CACHE_NAME_LOCAL_TX! Please,
>> > > >>>>>>>> use
>> > > >>> loc,
>> > > >>>>>>>> instead of LOCAL [IgniteAbbrevationsRule]
>> > > >>>>>>>> [ERROR]
>> > > >>>>>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>
>> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWithTtlTest.java:264:
>> > > >>>>>>>> Abbrevation should be used for checkpointManager! Please, use
>> > > >>>>>>>> mgr,
>> > > >>>>> instead
>> > > >>>>>>>> of Manager [IgniteAbbrevationsRule]
>> > > >>>>>>>> [ERROR]
>> > > >>>>>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>
>> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsPartitionPreloadTest.java:63:
>> > > >>>>>>>> Abbrevation should be used for DEFAULT_REGION! Please, use
>> > > >>>>>>>> dflt,
>> > > >>>>> instead of
>> > > >>>>>>>> DEFAULT [IgniteAbbrevationsRule]
>> > > >>>>>>>> [ERROR]
>> > > >>>>>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>
>> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWholeClusterRestartTest.java:47:
>> > > >>>>>>>> Abbrevation should be used for ENTRIES_COUNT! Please, use
>> > > >>>>>>>> cnt,
>> > > >>>> instead
>> > > >>>>> of
>> > > >>>>>>>> COUNT [IgniteAbbrevationsRule]
>> > > >>>>>>>> [ERROR]
>> > > >>>>>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>
>> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsRebalancingOnNotStableTopologyTest.java:49:
>> > > >>>>>>>> Abbrevation should be used for CHECKPOINT_FREQUENCY! Please,
>> > > >>>>>>>> use
>> > > >>>> freq,
>> > > >>>>>>>> instead of FREQUENCY [IgniteAbbrevationsRule]
>> > > >>>>>>>> [ERROR]
>> > > >>>>>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>
>> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsTransactionsHangTest.java:75:
>> > > >>>>>>>> Abbrevation should be used for MAX_KEY_COUNT! Please, use
>> > > >>>>>>>> cnt,
>> > > >>>> instead
>> > > >>>>> of
>> > > >>>>>>>> COUNT [IgniteAbbrevationsRule]
>> > > >>>>>>>> [ERROR]
>> > > >>>>>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>
>> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsTransactionsHangTest.java:78:
>> > > >>>>>>>> Abbrevation should be used for CHECKPOINT_FREQUENCY! Please,
>> > > >>>>>>>> use
>> > > >>>> freq,
>> > > >>>>>>>> instead of FREQUENCY [IgniteAbbrevationsRule]
>> > > >>>>>>>> [ERROR]
>> > > >>>>>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>
>> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/SlowHistoricalRebalanceSmallHistoryTest.java:57:
>> > > >>>>>>>> Abbrevation should be used for SUPPLY_MESSAGE_LATCH! Please,
>> > > >>>>>>>> use
>> > > >>> msg,
>> > > >>>>>>>> instead of MESSAGE [IgniteAbbrevationsRule]
>> > > >>>>>>>> [ERROR]
>> > > >>>>>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>
>> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgniteLogicalRecoveryTest.java:74:
>> > > >>>>>>>> Abbrevation should be used for SHARED_GROUP_NAME! Please, use
>> > > >>>>>>>> grp,
>> > > >>>>> instead
>> > > >>>>>>>> of GROUP [IgniteAbbrevationsRule]
>> > > >>>>>>>> [ERROR]
>> > > >>>>>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>
>> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgniteLogicalRecoveryTest.java:200:
>> > > >>>>>>>> Abbrevation should be used for cacheLoader! Please, use ldr,
>> > > >>> instead
>> > > >>>> of
>> > > >>>>>>>> Loader [IgniteAbbrevationsRule]
>> > > >>>>>>>> ```
>> > > >>>>>>>>
>> > > >>>>>>>> [1]
>> > > >>>>>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>
>> > > https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-VariableAbbreviation
>> > > >>>>>>>> [2] https://github.com/apache/ignite/pull/9153
>> > > >>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>
>> > > >>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>
>> > > >>
>> > > >>
>> > > >> --
>> > > >>
>> > > >> Best regards,
>> > > >> Alexei Scherbakov
>> > > >
>> > >
>> > >
>
--
Best regards,
Ivan Pavlukhin
to enforce usage of abbreviations.
> Internal/public code differs by package.
>
> PoC of rule [1]
>
> [1] https://github.com/apache/ignite/pull/9153
>
>> 17 июня 2021 г., в 07:01, Ivan Pavlukhin
>> написал(а):
>>
>> Nikita,
>>
>> Do you have a
;> > > are
>> > > about constant's namings.
>> > >
>> > > I suppose that we should define strict and clear rules about
>> > > constants
>> > > naming.
>> > >
>> > > [1] --
>> > https://
; > > access point. Ignition seems to be a good candidate for this.
>> > > > > > >
>> > > > > > > Ignition#start should eventually be removed from the public
>> API.
>> > It
>> > > > is
>> > > > > > > currently there only because we don't have the thin client
>> > > > > > > yet.
>> > > > > > >
>> > > > > > > -Val
>> > > > > > >
>> > > > > > >> On Wed, Jul 7, 2021 at 5:47 AM Pavel Tupitsyn <
>> > > ptupit...@apache.org
>> > > > >
>> > > > > > wrote:
>> > > > > > >>
>> > > > > > >> Igniters,
>> > > > > > >>
>> > > > > > >> I have a few questions regarding server node startup and
>> > > > > > >> thin
>> > > > clients.
>> > > > > > >>
>> > > > > > >> State of things:
>> > > > > > >> - Server nodes will be started with 'ignite run' from CLI
>> > > > > > >> [1]
>> > > > > > >> - ignite-api module represents our public API
>> > > > > > >> - ignite-api has Ignition interface to start server nodes
>> > > > > > >>
>> > > > > > >> Questions:
>> > > > > > >> - What's the idea behind Ignition interface in the public
>> > > > > > >> API?
>> > Are
>> > > > we
>> > > > > > going
>> > > > > > >> to have an "embedded mode" where servers can be started from
>> > > code? I
>> > > > > > >> thought this was not planned.
>> > > > > > >> - How are users supposed to retrieve an instance of the
>> Ignition
>> > > > > > interface?
>> > > > > > >> - Are there any plans to start thin clients from Ignition
>> > > interface,
>> > > > > or
>> > > > > > >> should we have a separate way of doing this?
>> > > > > > >>
>> > > > > > >>
>> > > > > > >> [1]
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158873958
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
--
Best regards,
Ivan Pavlukhin
> > >
>> > > > > > > > >
>> > > > > > > > > > separate facades for sync, async
>> > > > > > > > >
>> > > > > > >
don`t want to link additional discussion about pos. 2 i think that harm
>> is obvious.
>> I suggest to get rid of them.
>>
>> what do you think ?
>>
>>
>>
>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>
--
Best regards,
Ivan Pavlukhin
. We Index into Solr and use the Solr indices and others to
>> >> > fulfill over all queries with Ignite just being one of the
>> >> > possible storage
>> >> > targets Calcite pushes down to. If we could get to the calcite
>> >> > API from an
>> >> > Ignite thick client, it would enable us to remove a layer of
>> >> > abstraction
>> >> > and complexity and make Ignite our primary that we then link
>> >> > with Solr and
>> >> > others to fulfill queries.
>> >> >4. Will the unified storage model enable different versions of
>> >> Ignite to
>> >> >be in the cluster when persistence is enabled so that rolling
>> >> restarts
>> >> > can
>> >> >be done?
>> >> >1. We have to do a strange dance to perform Ignite upgrades
>> >> > without
>> >> > downtime because pods/nodes will fail to start on version
>> mismatch
>> >> > and if
>> >> > we get that dance wrong, we will corrupt a node's data. It
>> >> > will
>> >> make
>> >> > admin/upgrades far less brittle and error prone if this was
>> >> possible.
>> >> >5. Will it be possible to provide a custom cache store still and
>> will
>> >> >these changes enable custom cache stores to be queryable from
>> >> > SQL?
>> >> >1. Our Ignite usage is wide and complex because we use KV, SQL
>> >> > and
>> >> other
>> >> > APIs. The inconsistency of what can and can't be used from one
>> >> API to
>> >> > another is a real challenge and has forced us over time to
>> >> > stick
>> >> > to one API
>> >> > and write alternative solutions outside of Ignite. It will
>> >> > drastically
>> >> > simplify things if any CacheStore (or some new equivalent)
>> >> > could
>> >> > be plugged
>> >> > in and be made accessible to SQL (and in fact all other APIs)
>> >> without
>> >> > having to load all the data from the underlying CacheStore
>> >> > first
>> >> > into memory
>> >> >6. This question wasn't mine but I was going to ask it as well:
>> What
>> >> >will happen to the Indexing API since H2 is being removed?
>> >> > 1. As I mentioned above, we Index into Solr, in earlier
>> >> > versions
>> >> of
>> >> > our product we used the indexing SPI to index into Lucene on
>> >> > the
>> >> > Ignite
>> >> > nodes but this presented so many challenges we ultimately
>> >> > abandoned it and
>> >> > replaced it with the current Solr solution.
>> >> > 2. Lucene indexing was ideal because it meant we didn't have
>> >> > to
>> >> > re-invent Solr or Elasticsearch's sharding capabilities, that
>> was
>> >> > almost
>> >> > automatic with Ignite only giving you the data that was meant
>> for
>> >> the
>> >> > current node.
>> >> > 3. The Lucene API enabled more flexibility and removed a
>> >> > network
>> >> > round trip from our queries.
>> >> > 4. Given Calcite's ability to support custom SQL functions,
>> >> > I'd
>> >> love
>> >> > to have the ability to define custom functions that Lucene was
>> >> > answering
>> >> >7. What impact does RAFT now have on conflict resolution, off the
>> >> top of
>> >> >my head there are two cases
>> >> > 1. On startup after a split brain Ignite currently takes an
>> >> "exercise
>> >> > for the reader" approach and dumps a log along the lines of
>> >> >
>> >> > >1. BaselineTopology of joining node is not compatible with
>> >> > > BaselineTopology in the cluster.
>> >> > >1. Branching history of cluster BlT doesn't contain branching
>> point
>> >> > > hash of joining node BlT. Consider cleaning persistent
>> >> > > storage
>> >> of
>> >> > the node
>> >> > > and adding it to the cluster again.
>> >> > >
>> >> >1. This leaves you with no choice except to take one half and
>> >> manually
>> >> > copy, write data back over to the other half then destroy the
>> bad
>> >> > one.
>> >> > 2. The second case is conflicts on keys, I
>> >> > beleive CacheVersionConflictResolver and manager are used
>> >> > by GridCacheMapEntry which just says if use old value do this
>> >> > otherwise use
>> >> > newVal. Ideally this will be exposed in the new API so that
>> >> > one
>> >> can
>> >> > override this behaviour. The last writer wins approach isn't
>> >> always
>> >> > ideal
>> >> > and the semantics of the domain can mean that what is consider
>> >> > "correct" in
>> >> > a conflict is not so for a different domain.
>> >> >8. This is last on the list but is actually the most important
>> >> > for
>> us
>> >> >right now as it is an impending and growing risk. We allow
>> customers
>> >> to
>> >> >create their own tables on demand. We're already using the same
>> cache
>> >> > group
>> >> >etc for data structures to be re-used but now that we're getting
>> >> > to
>> >> >thousands of tables/caches our startup times are sometimes
>> >> unpredictably
>> >> >long - at present it seems to depend on the state of the
>> cache/table
>> >> > before
>> >> >the restart but we're into the order of 5 - 7 mins and steadily
>> >> > increasing
>> >> >with the growth of tables. Are there any provisions in Ignite 3
>> >> > for
>> >> >ensuring startup time isn't proportional to the number of
>> >> tables/caches
>> >> >available?
>> >> >
>> >> >
>> >> > Those are the key things I can think of at the moment. Val and
>> >> > others
>> >> I'd
>> >> > love to open a conversation around these.
>> >> >
>> >> > Regards,
>> >> > Courtney Robinson
>> >> > Founder and CEO, Hypi
>> >> > Tel: ++44 208 123 2413 (GMT+0) <https://hypi.io>
>> >> >
>> >> > <https://hypi.io>
>> >> > https://hypi.io
>> >> >
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >> Andrey V. Mashenkov
>> >>
>> >
>>
>
--
Best regards,
Ivan Pavlukhin
least since yesterday), however, this site hosted on GridGain
>> > domain [2] is working.
>> > Can anyone have a look what's happening?
>> >
>> > [1] : mtcga.ignite.apache.org
>> > [2] : mtcga.gridgain.com
>>
>>
>
--
Best regards,
Ivan Pavlukhin
ries.
>> > > > > > > For
>> > > > > > > > the
>> > > > > > > > > > last ticket I'm doing I see some obvious issues with
>> > > > > > > > > > them
>> > (no
>> > > > page
>> > > > > > > size
>> > > > > > > > > > support, for example). I'm glad that somebody wants to
>> > maintain
>> > > > > > this
>> > > > > > > > > > functionality. Thanks a lot!
>> > > > > > > > > >
>> > > > > > > > > > For the MergeSort algorithm there is already a patch
>> > > > > > > > > > for
>> > that
>> > > > [1].
>> > > > > > > It's
>> > > > > > > > > > currently on review. This patch introduces an abstract
>> > reducer
>> > > > for
>> > > > > > > > > > CacheQueries with 2 implementations (unordered,
>> > merge-sort).
>> > > > Then
>> > > > > > > > TextQuery
>> > > > > > > > > > leverages on MergeSort to order results from multiple
>> > nodes by
>> > > > > > score.
>> > > > > > > > This
>> > > > > > > > > > patch also fixes the pageSize issue, I've mentioned
>> > > > > > > > > > before.
>> > > > Could
>> > > > > > you
>> > > > > > > > > > please check if it fully matches your idea? Any issues
>> > > > > > > > > > or
>> > > > comments
>> > > > > > > are
>> > > > > > > > > > welcome.
>> > > > > > > > > >
>> > > > > > > > > > I've prepared this ticket, because I need the MergeSort
>> > > > algorithm
>> > > > > > for
>> > > > > > > > the
>> > > > > > > > > > new type of queries I'm implementing (IndexQuery, it
>> > > > > > > > > > should
>> > > > also
>> > > > > > > > provide
>> > > > > > > > > > ordered results over multiple nodes). Currently I'm not
>> > > > planning to
>> > > > > > > go
>> > > > > > > > > > further with TextQuery, so if you're going to support
>> > > > > > > > > > this
>> > > > it'll
>> > > > > > be a
>> > > > > > > > great
>> > > > > > > > > > contribution, I think.
>> > > > > > > > > >
>> > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14703
>> > > > > > > > > > [2] https://github.com/apache/ignite/pull/9081
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > On Mon, Jun 21, 2021 at 11:11 AM Atri Sharma <
>> > a...@apache.org>
>> > > > > > > wrote:
>> > > > > > > > > >
>> > > > > > > > > > > Hi All,
>> > > > > > > > > > >
>> > > > > > > > > > > I have been looking into our text queries support and
>> > > > > > > > > > > see
>> > > > that it
>> > > > > > > has
>> > > > > > > > > > > limited community support.
>> > > > > > > > > > >
>> > > > > > > > > > > Therefore, I volunteer to be the maintainer of the
>> > module and
>> > > > > > work
>> > > > > > > on
>> > > > > > > > > > > enhancing it further.
>> > > > > > > > > > >
>> > > > > > > > > > > First goal would be to move to Lucene 8.x, then work
>> > > > > > > > > > > on
>> > > > sorted
>> > > > > > > reduce
>> > > > > > > > > > > - merge across nodes. Fundamentally, this is doable
>> > > > > > > > > > > since
>> > > > Lucene
>> > > > > > > > ranks
>> > > > > > > > > > > documents according to their score, and documents are
>> > > > returned in
>> > > > > > > the
>> > > > > > > > > > > order of their score. Since the scoring function is
>> > > > homogeneous,
>> > > > > > > this
>> > > > > > > > > > > means that across nodes, we can compare scores and
>> > > > > > > > > > > merge
>> > > > sort.
>> > > > > > > > > > >
>> > > > > > > > > > > Please let me know if I can take this up.
>> > > > > > > > > > >
>> > > > > > > > > > > Atri
>> > > > > > > > > > >
>> > > > > > > > > > > --
>> > > > > > > > > > > Regards,
>> > > > > > > > > > >
>> > > > > > > > > > > Atri
>> > > > > > > > > > > Apache Concerted
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > --
>> > > > > > > > >
>> > > > > > > > > Best regards,
>> > > > > > > > > Alexei Scherbakov
>> > > > > > > >
>> > > > > > > > --
>> > > > > > > > Regards,
>> > > > > > > >
>> > > > > > > > Atri
>> > > > > > > > Apache Concerted
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Best regards,
>> > > > > Andrey V. Mashenkov
>> > > >
>> > > > --
>> > > > Regards,
>> > > >
>> > > > Atri
>> > > > Apache Concerted
>> > > >
>> > >
>> > >
>> > > --
>> > > Best regards,
>> > > Andrey V. Mashenkov
>> >
>> > --
>> > Regards,
>> >
>> > Atri
>> > Apache Concerted
>> >
>>
>>
>> --
>> Best regards,
>> Andrey V. Mashenkov
>
> --
> Regards,
>
> Atri
> Apache Concerted
>
--
Best regards,
Ivan Pavlukhin
, Atri Sharma :
> Hi Ivan,
>
> Would you like to propose an alternative to Lucene?
>
> Atri
>
> On Mon, 2 Aug 2021, 13:48 Ivan Pavlukhin, wrote:
>
>> Folks,
>>
>> Sorry if read the thread not thoroughly enough, but do we consider
>> Lucene as ob
nderlying data distribution changes and the cached plan is
>> no
>> longer optimal for the given statistics.
>>
>> On Sat, 31 Jul 2021, 12:54 Ivan Pavlukhin, wrote:
>>
>> > Hi Courtney,
>> >
>> > Please clarify what do you mean by prepared queries a
ng a feedback button (let’s call it a «Documentation
>> > > > feedback» button) to the web site documentation pages so everyone
>> could
>> > > > leave a comment to what is already published.
>> > > >
>> > > > The feedback may refer to the Ignite documentation in general or to
>> > > > a
>> > > > particular section, paragraph, or even term or value.
>> > > >
>> > > > I do believe that we would harvest dozens and hundreds of ideas,
>> > > > suggestions, and observations.
>> > > >
>> > > > I would also suggest using bugyard.io as a solid service for
>> gathering
>> > > > feedback (I’m quite familiar with it, it is easy to implement, use,
>> and
>> > > > maintain).
>> > > >
>> > > > So folks, what do you think of this?
>> > > >
>> > > > With best regards,
>> > > > Nikita
>> > > >
>> > >
>> >
>>
>
--
Best regards,
Ivan Pavlukhin
c379156f0bb0%40%3Cdev.ignite.apache.org%3E
--
Best regards,
Ivan Pavlukhin
:
> Hi Ivan,
>
> I didn't quite understand. Are you proposing that Ignite should not
> have FTS capabilities?
>
> Atri
>
> On Tue, Aug 3, 2021 at 2:57 PM Ivan Pavlukhin wrote:
>>
>> Hi Atri,
>>
>> My main concern is non-maleficence. Every task h
eeping the dev list clean.
>
> On Mon, Aug 9, 2021 at 11:00 AM Pavel Tupitsyn
> wrote:
>
>> I agree, let's keep the dev list clean.
>> Automated notifications of any kind should not be sent to dev@i.a.o.
>>
>> PS Ivan, links 2 and 3 are the same.
>>
>&
#x27;s better to have a single dev@ account on this service so
> that any community member can log in and handle feedback (we already follow
> this practice for other services).
>
> -
> Denis
>
>
> On Monday, August 9, 2021, Ivan Pavlukhin wrote:
>
>> Igniters,
&g
d of guidance,
>> review
>> and then ensuring the code is included.
>>
>> Regards,
>>
>> --
>> Ilya Kasnacheev
>>
>
--
Best regards,
Ivan Pavlukhin
Most of our APIs will be on the hot path.
>>
>> One can argue about performance differences in real-world scenarios,
>> but increasing GC pressure just to make the code a little bit nicer is
>> unacceptable.
>>
>> I propose to ban streams usage in the codebase (except for the tests).
>>
>> Thoughts, objections?
>>
>> [1] https://gist.github.com/ptupitsyn/5934bbbf8f92ac4937e534af9386da97
>>
>
>
> --
> Sincerely yours,
> Ivan Bessonov
>
--
Best regards,
Ivan Pavlukhin
t; > >> thrpt
>> > 3
>> > >> ≈ 0counts
>> > >>
>> > >> * StreamVsLoopBenchmark.streamSum
>> > >> thrpt
>> > 3
>> > >> 1060.244 ± 36.485 ops/ms
>> > >> * StreamVsLoopBenchmark.streamSum:·gc.alloc.rate
>> > >> thrpt
>> > 3
>> > >> 315.819 ± 10.844 MB/sec
>> > >> * StreamVsLoopBenchmark.streamSum:·gc.count
>> > >> thrpt
>> > 3
>> > >> 55.000counts
>> > >>
>> > >> Loop is several times faster and does not allocate at all.
>> > >>
>> > >> 1. Performance is one of the most important features of our product.
>> > >> 2. Most of our APIs will be on the hot path.
>> > >>
>> > >> One can argue about performance differences in real-world scenarios,
>> > >> but increasing GC pressure just to make the code a little bit nicer
>> > >> is
>> > >> unacceptable.
>> > >>
>> > >> I propose to ban streams usage in the codebase (except for the
>> > >> tests).
>> > >>
>> > >> Thoughts, objections?
>> > >>
>> > >> [1]
>> > >> https://gist.github.com/ptupitsyn/5934bbbf8f92ac4937e534af9386da97
>> > >>
>> > >
>> > >
>> > > --
>> > > Sincerely yours,
>> > > Ivan Bessonov
>> >
>> >
>
--
Best regards,
Ivan Pavlukhin
>>>> 5. VS projects are not backward compatible. We have to add manually (or
>>>> by
>>>> sed or patch) some dependencies in order to build current VS projects
>>>> on
>>>> newer versions of VS.
>>>>
>>>> So I suggest simpy to remove VS projects because of reasons I've
>>>> written
>>>> above.
>>>>
>>>> WDYT?
>>>>
>>>>
>>>>
>>>> [1] -- https://issues.apache.org/jira/browse/IGNITE-15511
>>>
>>>
>>>
>>>
>
>
--
Best regards,
Ivan Pavlukhin
;>>>>>>>> - jira
>>>>>>>>>> - confluence
>>>>>>>>>>
>>>>>>>>>> Should we accept the fact that thing we calling as "Ignite3" is
>>>> just
>>>>>>> another project?
>>>>>>>>>> Can you, please, share your vision on how Ignite and Ignite3
>>> should
>>>>>>> coexists?
>>>>>>>>>>
>>>>>>>>>> вт, 21 сент. 2021 г. в 17:13, Dmitry Pavlov >>> :
>>>>>>>>>>>
>>>>>>>>>>> Ok, if nobody minds, I'll create spaces a bit later.
>>>>>>>>>>>
>>>>>>>>>>> I hope it is not too urgent.
>>>>>>>>>>>
>>>>>>>>>>> Sincerely,
>>>>>>>>>>> Dmitriy Pavlov
>>>>>>>>>>>
>>>>>>>>>>> On 2021/09/21 10:37:42, Valentin Kulichenko <
>>>>>>> valentin.kuliche...@gmail.com> wrote:
>>>>>>>>>>>> Hi Dmitry,
>>>>>>>>>>>>
>>>>>>>>>>>> According to Infra, this has to be done through
>>>>>>> http://selfserve.apache.org/,
>>>>>>>>>>>> but only PMC chairs have access.
>>>>>>>>>>>>
>>>>>>>>>>>> Could you please assist with the creation of the Jira project
>>>> and
>>>>>>>>>>>> Confluence space?
>>>>>>>>>>>>
>>>>>>>>>>>> -Val
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Sep 21, 2021 at 10:46 AM Valentin Kulichenko <
>>>>>>>>>>>> valentin.kuliche...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Infra requests created:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - https://issues.apache.org/jira/browse/INFRA-22349
>>>>>>>>>>>>> - https://issues.apache.org/jira/browse/INFRA-22350
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Val
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Sep 20, 2021 at 10:50 AM Petr Ivanov <
>>>>>>> mr.wei...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Since we've agreed that there are two projects (that are
>>>>>>> Ignite2 and
>>>>>>>>>>>>>> Ignite3), separate development environments seem to be
>>>> logical
>>>>>>> and natural
>>>>>>>>>>>>>> course of things.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 18 Sep 2021, at 12:42, Alexander Polovtcev <
>>>>>>> alexpolovt...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>> This is a welcome proposal, because we already have some
>>>>>>> pending Ignite
>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>> specific documents, and it is not clear where to put them
>>>> at
>>>>>>> the moment.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sat, Sep 18, 2021 at 4:22 AM Valentin Kulichenko <
>>>>>>>>>>>>>>> valentin.kuliche...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Igniters,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think it's clear to all of us that Ignite 2.x and 3.x
>>>>>>> will coexist
>>>>>>>>>>>>>> for a
>>>>>>>>>>>>>>>> while. They are developed in separate Git repos, but we
>>>>>>> still
>>>>>>>>>>>>>> accumulate
>>>>>>>>>>>>>>>> the tickets for both versions in the same Jira project,
>>>>>>> which seems to
>>>>>>>>>>>>>>>> complicate the ticket management.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For example, we use the "ignite-3" label for 3.x
>>> tickets,
>>>>>>> but this
>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>>> is fragile. If someone forgets to add the label to a new
>>>>>>> ticket, it's
>>>>>>>>>>>>>>>> likely to be lost. We need a better separation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All the above is true for Wiki as well - we use a single
>>>>>>> Confluence
>>>>>>>>>>>>>> space.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I suggest creating a new Jira project and a new
>>> Confluence
>>>>>>> space for
>>>>>>>>>>>>>> Ignite
>>>>>>>>>>>>>>>> 3 and moving all the relevant tickets and pages there.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Any thoughts or objections?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Val
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> With regards,
>>>>>>>>>>>>>>> Aleksandr Polovtcev
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>
>
--
Best regards,
Ivan Pavlukhin
I mean that Ignite 2.x will continue to use old scheme and Ignite 3
will be e.g. Ignite 21.1 and so on.
2021-09-27 14:57 GMT+03:00, Petr Ivanov :
> How will not they clash if version is based only on date?
>
>> On 27 Sep 2021, at 14:33, Ivan Pavlukhin wrote:
>>
>> Today i
uence space for Ignite 3
>>>>>>>> (initial suggestion).
>>>>>>>> 2. Add a *mandatory* field in Jira to identify whether a ticket
>>>>>>>> belongs to
>>>>>>>> 2.x or 3.x.
>>>>>>>>
>>>>
influences the
> development. "Do nothing" is not really an option here.
>
> Either way, I will put the initial suggestion for the vote.
>
> -Val
>
> On Thu, Sep 30, 2021 at 12:24 AM Ivan Pavlukhin
> wrote:
>
>> Val,
>>
>> > Let's discuss th
s a majority vote.
>>
>> Voting ends in 72 hours, at 5pm PDT on October 7:
>> https://www.timeanddate.com/counters/fullscreen.html?mode=a&iso=20211007T17&year=2021&month=10&day=7&hour=17&min=0&sec=0&p0=224
>>
>> -Val
>
--
Best regards,
Ivan Pavlukhin
;string","validated":true,"case_sensitive":true},
> "bool":{"type":"boolean","validated":false},
>
> "phrase":{"type":"text","validated":false,"analyzer":"
to this role
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> пт, 30 апр. 2021 г. в 11:55, Mikhail Petrov :
>>
>>> Hi, Ilya, could you please add me to "Contributors 1" role? Or can I do
>>> it myself somehow?
>>>
>>> On 29.04.2021 18:59, Ilya Kasnacheev wrote:
>>>
>>> Hello!
>>>
>>> Pavel, Yurii, I have added you both to the role.
>>>
>>> Regards,
>>>
>>>
>
--
Best regards,
Ivan Pavlukhin
>>>
>>> > > > >>> +1
>>> > > > >>>
>>> > > > >>> On Fri, Oct 15, 2021 at 3:41 PM Nikita Amelchev <
>>> > namelc...@apache.org>
>>> > > > >>> wrote:
>>> > > > >>>
>>> > > > >>>> +1 for deprecation in the 2.12 release
>>> > > > >>>>
>>> > > > >>>> пт, 15 окт. 2021 г. в 15:35, Nikolay Izhikov <
>>> nizhi...@apache.org
>>> > >:
>>> > > > >>>>>
>>> > > > >>>>> Hello, Igniters.
>>> > > > >>>>>
>>> > > > >>>>> I’ve prepared IEP-80 [1] to track breaking changes that
>>> > > > >>>>> should
>>> > be done
>>> > > > >>>> in Ignite 2.x.
>>> > > > >>>>>
>>> > > > >>>>> We agreed on the following algorithm to deal with breaking
>>> > changes:
>>> > > > >>>>>
>>> > > > >>>>> - Ignite 2.[x] - deprecate the API + notification of the
>>> users.
>>> > > > >>>>> - Ignite 2.[x+1] - API removal.
>>> > > > >>>>>
>>> > > > >>>>>
>>> > > > >>>>> I propose to start these improvements with the d&r
>>> (depuration &
>>> > > > >>>> removal) of the following features:
>>> > > > >>>>>
>>> > > > >>>>> - LOCAL caches
>>> > > > >>>>> - MVCC caches
>>> > > > >>>>> - legacy service grid implementation
>>> > > > >>>>> - legacy JMX metrics beans.
>>> > > > >>>>>
>>> > > > >>>>> Deprecation in 2.12
>>> > > > >>>>> Removal in 2.13
>>> > > > >>>>>
>>> > > > >>>>> Please, share your opinion.
>>> > > > >>>>>
>>> > > > >>>>> [1]
>>> > > > >>>>
>>> >
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191334475
>>> > > > >>>>
>>> > > > >>>>
>>> > > > >>>>
>>> > > > >>>> --
>>> > > > >>>> Best wishes,
>>> > > > >>>> Amelchev Nikita
>>> > > > >>>>
>>> > > > >
>>> > > >
>>> >
>>>
>>>
>>> --
>>> Best Regards,
>>> Vyacheslav D.
>>>
>>
>>
>> --
>> Sincerely yours, Ivan Daschinskiy
>>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>
--
Best regards,
Ivan Pavlukhin
n failure (if a user already fetched some
> data).
>
> I don't like the idea of this optimistic approach because in case a user
> got some data, we don't have a better solution than to fail a query in case
> of cluster instability and reservation failure.
>
> Igniters, WDYT?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12591
> [2] https://issues.apache.org/jira/browse/IGNITE-16031
>
--
Best regards,
Ivan Pavlukhin
/jira/browse/IGNITE-12591
>>
>> On Thu, Dec 9, 2021 at 10:39 AM Pavel Tupitsyn
>> wrote:
>>
>> > Agree with Ivan regarding compatibility.
>> > Partition reservation should be opt-in if we decide to proceed.
>> >
>> > > is there a real
no objections, the short-term plan is:
> 1. Implement partition reservation for IndexQuery.
> 2. Add the option for ScanQuery.
> 3. Make tests that show that IndexQuery / SQL / ScanQuery is replaceable
> for some types of queries in terms of result consistency.
> 4. Then discuss a
rge of query results) on an
> initiator node has its own implementation for IndexQuery (MergeSort), but
> it's built into existing ScanQuery processing.
>
> On Mon, Dec 13, 2021 at 11:00 AM Ivan Pavlukhin
> wrote:
>
>> > Then, if there are no objections, the short-
different encodings?
>> >>
>> >> As a result, we will be sure that all cluster nodes have the same
>> >> encoding and all related problems will be solved.
>> >>
>> >> [1] - https://issues.apache.org/jira/browse/IGNITE-16106
>> >> [2] - https://issues.apache.org/jira/browse/IGNITE-16068
>> >>
>> >> --
>> >> Mikhail
>> >>
>> >>
>> >
>> > --
>> > Sincerely yours, Ivan Daschinskiy
>>
>>
>
> --
> Sincerely yours, Ivan Daschinskiy
>
--
Best regards,
Ivan Pavlukhin
cters.
>> >
>> > Actually, we already has some modes to support this restriction of
>> > UTF-8.
>> > Please, take a look at BinaryUtils#utf8BytesToStr [3]
>> >
>> >
>> > [1] https://en.wikipedia.org/wiki/UTF-8
>> > [2] htt
after Ilya Kasnacheev mentioned that we already
>> have a warning "Differing character encodings across cluster may lead
>> to erratic behavior"). It will help to avoid "erratic behavior", not
>> just warn about it. It is important since the problems related to
thub.com/uber/NullAway
>>
>> On Fri, Dec 17, 2021 at 9:04 AM ткаленко кирилл
>> wrote:
>>
>> > I'm for the second option.
>> >
>>
>
>
> --
> With regards,
> Aleksandr Polovtcev
>
--
Best regards,
Ivan Pavlukhin
can insist on not using nulls as much as possible.
>>
>> Same here, I agree with you and it correlates with clear API design in
>> general. However, sometimes nullable parameters and return values are
>> justified, so how can we formalize that?
>>
>> On Sat, D
1 - 100 of 582 matches
Mail list logo
