Dmitriy,
Could you please check release using special TC tasks [1] "Compare w/
Previous Release" and "Check RC"
Also, I see you used some new task [2] to assembly the release.
What's the difference with original task [3]?
Please make sure correct task used and remove obsolete one. Don't forget to
>> * Twitter module
Every extension/adapter/etc module should be checked to be useful.
My wish is to get rid of all lesser-used features, to make AI as small as
possible.
It's time to clean-up legacy :)
BTW, do we really need TCK support?
On Mon, Jun 17, 2019 at 4:05 PM Andrey Mashenkov
wrote:
+1 (binding)
On Thu, Jun 20, 2019 at 10:08 AM Dmitriy Pavlov wrote:
> +1
>
> чт, 20 июн. 2019 г. в 09:15, Nikolay Izhikov :
>
> > +1
> >
> > чт, 20 июня 2019 г., 8:28 Павлухин Иван :
> >
> > > +1
> > >
> > > чт, 20 июн. 2019 г. в 04:18, Valentin Kulichenko
> > > :
> > > >
> > > > +1
> > > >
> >
Igniters,
I'm glad to introduce Read Repair feature [0] provides additional
consistency guarantee for Ignite.
1) Why we need it?
The detailed explanation can be found at IEP-31 [1].
In short, because of bugs, it's possible to gain an inconsistent state.
We need additional features to handle this
t; *ALL ENTRIES ON ALL OWNERS WILL HAVE DIFFERENT VERSIONS*
>
> Why we need this modes, in the first place?
> Should we consider it's removal in Ignite 3 or should we fix them?
>
> В Чт, 20/06/2019 в 14:15 +0300, Anton Vinogradov пишет:
> > Igniters,
> > I'm glad to int
gt;
>
> > On 17 May 2019, at 17:36, Anton Vinogradov wrote:
> >
> > Dmitriy,
> >
> > Could you please check release using special TC tasks [1] "Compare w/
> > Previous Release" and "Check RC"
> > Also, I see you used some new task
Dmitriy,
This RC can not be released without explanation of huge diff to 2.7.0.
See my message above.
So, my -1 (binding).
On Thu, May 23, 2019 at 12:34 PM Nikolay Izhikov
wrote:
> +1 (binding)
>
> чт, 23 мая 2019 г., 12:28 Dmitriy Pavlov :
>
> > Hi Denis,
> >
> > I don't feel that we have
ok with your proposal.
On Tue, Apr 30, 2019 at 9:24 PM Sergey Kozlov wrote:
> Anton
>
> I'm Ok with your proposal but IMO it should be provided as IEP?
>
> On Mon, Apr 29, 2019 at 4:05 PM Anton Vinogradov wrote:
>
> > Sergey,
> >
> > I'd like to continue th
lp
> me with it?
>
> Sent from my iPhone
>
> > On 25 Apr 2019, at 16:25, Anton Vinogradov wrote:
> >
> > Folks,
> >
> > Just an update.
> > According to all your tips I decided to refactor API, logic, and approach
> > (mostly everything :)),
Igniters and especially Ivan Rakov,
"Idle verify" [1] is a really cool tool, to make sure that cluster is
consistent.
1) But it required to have operations paused during cluster check.
At some clusters, this check requires hours (3-4 hours at cases I saw).
I've checked the code of "idle verify"
+1 to simplification.
On Mon, Apr 29, 2019 at 3:32 PM Mikhail Petrov
wrote:
> Hi Igniters!
>
> Now plugin loading is based on presence of plugin class name in
> META-INF/service/org.apache.ignite.plugin.PluginProvider file. I propose to
> add special configuration in IgniteConfiguration for
Sergey,
I'd like to continue the discussion since it closely linked to the problem
I'm currently working on.
1) writeSynchronizationMode should not be a part of cache configuration,
agree.
This should be up to the user to decide how strong should be "update
guarantee".
So, I propose to have a
e, we can automatically detect
> inconsistent partitions on every PME. What do you think?
>
> [1] -
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Durable+Memory+-+under+the+hood#IgniteDurableMemory-underthehood-Pagereplacement(rotationwithdisk)
>
> Best Regards,
>
> (several times per week), which can be enough. In case it's needed to
> check consistency more often than regular PMEs occur, we can implement
> command that will trigger fake PME for consistency checking.
>
> Best Regards,
> Ivan Rakov
>
> On 29.04.2019 18:53, Anton Vinogra
nd computing some kind of commutative
> hash. It's safe under partition write lock.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-11611
> [2] https://issues.apache.org/jira/browse/IGNITE-6324
> [3] https://issues.apache.org/jira/browse/IGNITE-11256
>
> пн, 6 мая
/jira/browse/IGNITE-10078
On Tue, Apr 30, 2019 at 3:14 PM Anton Vinogradov wrote:
> Ivan,
>
> Thanks for the detailed explanation.
> I'll try to implement the PoC to check the idea.
>
> On Mon, Apr 29, 2019 at 8:22 PM Ivan Rakov wrote:
>
>> > But how to keep this
> be a good addition to IGNITE-10078 logic: we'll be able to detect
> situations when extended update counters are equal, but for some reason
> (bug or whatsoever) partition contents are different.
>
> Best Regards,
> Ivan Rakov
>
> On 06.05.2019 12:27, Anton Vinogradov
Alexey,
Thank's for keeping an eye on page updates.
Near Caches is not a bad feature, but it should be used with caution.
At least we have to explain how it works on readme.io, why and when it
should be used because usage can drop the performance instead of increasing
it.
Anyway, I added near
approach, TODOs, etc?
> For instance, I would like to see all these limitations on the IEP page as
> JIRA tickets. Perhaps, it would be good to create an epic/umbrella ticket
> in order to track all activities related to `Read Repair` feature.
>
> Thanks,
> S.
>
> чт, 20
Folks,
Investigating now unexpected repairs [1] in case of ReadRepair usage at
testAccountTxNodeRestart.
Updated [2] the test to check is there any repairs happen.
Test's name now is "testAccountTxNodeRestartWithReadRepair".
Each get method now checks the consistency.
Check means:
1) tx lock
; etc)
> > - Ignite C++ (It looks like, .Net is already aware of that feature)
> > - Thin clients support
> > - Perhaps, it would be useful to support different strategies to resolve
> > inconsistencies
> >
> > What do you think?
> >
> > Thanks,
s are better for monitoring, but the Event is enough for my wish
> to cover AI with consistency check,
>
> Can you clarify, do you have plans to add metrics of RR events?
>
> I think it should be count of incosistency events per cache(maybe per
> partition).
>
>
> В Чт, 11/
efore updating backup.
> 4. Very fast and lucky txB writes a value 2 for the key on primary and
> backup.
> 5. txB wakes up and writes 1 for the key.
> 6. As result there is 2 on primary and 1 on backup.
>
> Naively it seems that locks should be released after all replicas are
>
com/apache/ignite/pull/5656/commits/6f6ec4434095e692af209c61833a350f3013408c
[3]
https://github.com/apache/ignite/pull/5656/commits/255e552b474839e470c66a77e74e3c807bc76f13
On Fri, Jun 28, 2019 at 2:41 PM Anton Vinogradov wrote:
> Slava,
>
> >> I will take a look at your pull request i
te-Modularization-td42486.html
> -
> Denis
>
>
> On Fri, Jun 28, 2019 at 8:54 AM Alexey Goncharuk <
> alexey.goncha...@gmail.com>
> wrote:
>
> > Anton, good point.
> >
> > Do you have any idea how we can keep track of the voting? Should we
ust like 2PC prepare does?
> > If there's HB between steps 1 (lock primary) and 2 (update primary +
> > lock backup + update backup), you may be sure that there will be no
> > false-positive results and no deadlocks as well. Protocol won't be
> > complicated: checking read from backup will just
Sergey,
+1 to your proposal.
Looks pretty similar to Kafka's approach.
Ilya,
>> Will they stay unsynced, or is there any mechanism of re-syncing?
Yes, I'm currently working [1] on it.
The current implementation allows restoring the latest value.
[1]
once refactoring will be finished.
On Tue, Apr 16, 2019 at 2:20 PM Anton Vinogradov wrote:
> Nikolay, that was the first approach
>
> >> I think we should allow to the administrator to enable/disable
> Consistency check.
> In that case, we have to introduce cluster-wide chan
m trying tell you that this proxy can produce false positive result,
> > incorrect result and just hide bugs. What will the next solution?
> > withNoBugs proxy?
> >
> > You can perform consistency check using idle verify utility. Recovery
> > tool is good idea but user sho
Nikolay Izhikov 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 Vino
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
wrote:
> +1.
>
> Nikita, please, go
Nikolay,
The approach looks good to me.
Let's just make sure this syntax is extendable.
For example, I'd like to count only latency greater than 37ms (0-37 -
ignored, 37-52, 52-infinity - recorded), it should be possible to skip some
values.
Another case is to specify 2+ windows for same metric,
My +1 to optional Javadoc at private methods, fields, and classes.
The reviewer should guaranty that everything is clear.
But, in case everything is clear without redundant Javadoc there is no need
to have it.
So, my proposal is to allow /** */ for non-public fields and methods (to
keep
;
>
> В Чт, 15/08/2019 в 10:05 +0300, Anton Vinogradov пишет:
> > My +1 to optional Javadoc at private methods, fields, and classes.
> > The reviewer should guaranty that everything is clear.
> > But, in case everything is clear without redundant Javadoc there is n
+1 for removing, but...
Is it suitable to remove some API not at major release?
On Fri, Aug 2, 2019 at 11:32 AM Maxim Muzafarov wrote:
> Igniters,
>
> I've created a ticket [1].
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12035
>
> On Thu, 1 Aug 2019 at 10:55, Pavel Kovalenko wrote:
>
Dmitriy,
Did you check RC using automated TeamCity task?
On Fri, Aug 23, 2019 at 11:09 AM Zhenya Stanilovsky
wrote:
> Build from sources, run yardstick test.
> +1
> >
> >--- Forwarded message ---
> >From: "Dmitriy Pavlov" < dpav...@apache.org >
> >To: dev < dev@ignite.apache.org >
>
Dmitriy,
This task checks nothing.
It just compares files with previous release.
On Fri, Aug 23, 2019 at 12:01 PM Dmitriy Pavlov wrote:
> In reply to
>
> > Dmitriy,
> > Did you check RC using automated TeamCity task?
>
> Hi Anton,
>
> Yes, it is now part of the process
>
>
>
gt; I see screenshots made 2 releases ago and it shows `[2] Compare w/ Previous
> Release`
>
> Also, feel free to check the whole process of release to find out what else
> can be obsolete
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
>
> пт, 23 авг. 201
Dmitriy,
Since the same recommendations were provided at "[VOTE] Accept Apache
Ignite 2.7.5-rc3" and ... were ignored,
my -1 until this becomes a part of the release process.
On Fri, Aug 23, 2019 at 1:58 PM Anton Vinogradov wrote:
> Dmitriy,
>
> I'm talking about
> https:
-1 (binding)
Explained at discussion thread.
On Fri, Aug 23, 2019 at 11:17 AM Anton Vinogradov wrote:
> Dmitriy,
>
> Did you check RC using automated TeamCity task?
>
> On Fri, Aug 23, 2019 at 11:09 AM Zhenya Stanilovsky
> wrote:
>
>> Build from sources
Igniters,
I'd like to propose you to register at the ASF Slack [1] (committers seems
to be already registered) and join the Ignite channel [2].
This should simplify communication between the contributors.
P.s. I'm not saying we have to replace devlist with the Slack, but Slack is
a more suitable
Nikolay,
Let's try ;)
On Mon, Aug 26, 2019 at 4:15 PM Nikolay Izhikov wrote:
> Anton,
>
> Can we create channels for ticket, IEP discussions in ASF slack?
>
>
> В Пн, 26/08/2019 в 16:09 +0300, Anton Vinogradov пишет:
> > Igniters,
> > I'd like to propose you t
nversations (time to think, no commitments
> > to
> > > respond ASAP) or phone calls (make things done now). But sometimes
> Slack
> > > comes handy. For instance, I'd like to have a faster channel to talk to
> > > Nikolay Izhikov, Anton Vinogradov or Roman Shtykh on
Welcome aboard :)
On Thu, Aug 29, 2019 at 3:35 AM Roman Shtykh
wrote:
> Maxim, congratulations!
>
> -- Roman
>
>
> On Thursday, August 29, 2019, 12:11:29 a.m. GMT+9, Dmitriy Pavlov <
> dpav...@apache.org> wrote:
>
> Dear community,
>
> The Project Management Committee (PMC) for Apache
Igniters,
As far as you may know, we have blocking PME now.
It means that the upcoming operation's latency may be increased or already
started operations can be canceled.
I've done some homework and found it's possible to have almost non-blocking
PME (fully non-blocked in some cases).
I'd like
lly the hard ones, and slack is
> kind of a synchronous communication channel - with no known context it will
> be hard to give appropriate feedback. Do you have something to make
> Igniters familiar with beforehand?
>
> пн, 9 сент. 2019 г. в 09:01, Anton Vinogradov :
>
> >
Igniters,
Recently we had a discussion devoted to the non-blocking PME.
We agreed that the most important case is a blocking on node failure and it
can be splitted to:
1) Affected partition’s operations latency will be increased by node
failure detection duration.
So, some operations may be
onsistent update counters and
> cluster desync. Besides, IGNITE_MAX_COMPLETED_TX_COUNT is quite a large
> value and will push HWM forward very quickly, much faster than during
> regular updates (you will have to increment it for each partition)
>
> ср, 18 сент. 2019 г. в 10:53, Anton
es.apache.org/jira/browse/IGNITE-12152
> >
> > Alex, I'm curious is this a fundamental problem. Asked the same question
> in
> > JIRA but, probably, this discussion is a better place to get to the
> bottom
> > first:
> > https://issues.apache.org/jira/browse/IGNITE-108
Alexey,
Let's combine your and Ivan's proposals.
>> vacuum command, which acquires exclusive table lock, so no concurrent
activities on the table are possible.
and
>> Could the problem be solved by stopping a node which needs to be
defragmented, clearing persistence files and restarting the
Maksim,
Could you please split IGNITE-11992 to subtasks with proper descriptions?
This will allow us to relocate discussion to the issues to solve each
problem properly.
On Thu, Jul 18, 2019 at 11:57 AM Denis Garus wrote:
> Hello, Maksim!
> Thanks for your analysis!
>
> I have a few questions
f
> > > view?
> > > > > > > }
> > > > > > >
> > > > > > > 1. Should I consider that my cluster is broken? There is no
> answer!
> > > > The
> > > > > > > false-positive result is poss
Folks,
To be clear, I'm going to merge the PR next Monday in case of interest lack
(which means the feature is obsolete and can be removed).
On Thu, Jul 18, 2019 at 2:29 PM Maxim Muzafarov wrote:
> Igniters,
>
> It seems to me that GridCachePreloader.preloadPredicate(); currently
> not used
; We can introduce a metric of total blocking duration that will
> >> accumulate at the end of the exchange. So, users will get actual
> >> information about how long operations were blocked. Cluster metric
> >> will be a maximum of local nodes metrics. And we need a boolean met
> owns lock).
> >
> > > we have just to wait
> > > until entry becomes unlocked.
> > This may work.
> > If consistency checking code has acquired lock on primary, backup can be
> > in two states:
> > - not locked - and new locks won't appear as we are
metrics are better for monitoring, but the Event is enough for my
> > > wish
> > > > to
> > > > > cover AI with consistency check,
> > > > > - do we really need Platforms and Thin Client support?
> > > > Well, near caches are widely used and fully tra
Folks,
Is it possible just to ignore obsolete PRs somehow?
Not sure this crusade worth it.
On Thu, Jul 25, 2019 at 1:18 PM Павлухин Иван wrote:
> Maxim,
>
> Quite a nice idea. Could we go even further? Add a comment to each 1-2
> year old PR asking if the author could close it (most likely
ed now.
> And closing PRs after merge or some decent waiting period of inactivity
> seems to be at least sign of respect to each other of our community.
>
> Anyway, looks like that this task can be done in half-lazy pace without
> much of the disturbance to anyone.
>
>
>
;
>> >> > > For now, we have the getCurrentPmeDuration() metric that does not
>> show
>> >> > > influence on the cluster correctly. PME can be without blocking
>> >> > > operations. For example, client node join/leave events.
>> >>
rt
> node local timestamp.
>
> пн, 22 июля 2019 г., 8:33 Anton Vinogradov :
>
> > Folks,
> >
> > What's the reason for duration counting?
> > AFAIU, it's a monitoring system feature to count the durations.
> > Sine monitoring system checks metrics periodically it
deal.
>
> ср, 18 сент. 2019 г. в 13:27, Anton Vinogradov :
> >
> > Alexey,
> >
> > >> Can you describe the complete protocol changes first
> > The current goal is to find a better way.
> > I had at least 5 scenarios discarded because of findin
t;>>> It looks like not only task should execute in the current security
> >>>> context but all operations too, that is essential to determine a
> security
> >>>> id for events.
> >>>> Also, we need to get rid of GridTaskThreadContextKey#TC_SUBJ_ID as
>
Maksim
>> I want to fix 2-3-4 points under one ticket.
Please let me know once it's become ready to be reviewed.
On Thu, Sep 26, 2019 at 5:18 PM Maksim Stepachev
wrote:
> Hi.
>
> Anton Vinogradov,
>
> I want to fix 2-3-4 points under one ticket.
>
> The first was f
akov <
> alexey.scherbak...@gmail.com>:
>
> > The poor man's solution for the problem would be stopping fragmented node
> > and removing partition data, then starting it again allowing full state
> > transfer already without deletes.
> > Rinse and repeat for a
to the IEP.
On Thu, Jul 4, 2019 at 12:18 PM Anton Vinogradov wrote:
> Folks,
>
> Just a minor update.
>
> RunAll [1] with enabled ReadRepair proxy is almost green now (~10 tests
> left, started with 6k :)).
> During the analisys, I've found some tests with
>
aitc-lin03_01 also broken
On Fri, Dec 6, 2019 at 2:49 PM Anton Vinogradov wrote:
> listed agents seem to be broken too:
> aitc-lin11_02
> aitc-lin10_02
> aitc-lin05_01
> aitc-lin04_04
>
> On Fri, Dec 6, 2019 at 2:22 PM Ivan Pavlukhin wrote:
>
>> aitc-lin08 was ha
Thanks a lot!
On Mon, Dec 9, 2019 at 4:26 PM Ivan Pavlukhin wrote:
> Folks,
>
> All agents were cleaned.
>
> пн, 9 дек. 2019 г. в 09:13, Anton Vinogradov :
> >
> > aitc-lin03_01 also broken
> >
> > On Fri, Dec 6, 2019 at 2:49 PM Anton Vinogradov wrote:
&g
;.
It will be nice if someone will check the code and tests.
Test coverage proposals are welcome!
P.s. Here's a benchmark used to check we have performance improvements
listed above
https://github.com/anton-vinogradov/ignite/blob/426f0de9185ac2938dadb7bd2cbfe488233fe7d6/modules/core/src/test/java/org/apa
> > >
> > > [1]
> https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=4814624
> > >
> > > On Thu, 5 Dec 2019 at 15:13, Ivan Pavlukhin
> wrote:
> > > >
> > > > Folks,
> > > >
> > > > Agent ait
+1 to both.
On Tue, Oct 22, 2019 at 9:15 AM Vyacheslav Daradur
wrote:
> Igniters, I'd suggest 2 candidates who perfectly fit this role, in my
> opinion:
>
> Nickolay Izhikov - one of the most active community member with the
> significant contributions, Ignite's evangelist and tech-speaker.
>
>
; club will be a honor for me.
>
>
> чт, 24 окт. 2019 г., 9:34 Anton Vinogradov :
>
> > More candidates:
> >
> > - Alexey Zinoviev.
> > He is not a PMC member, but it's definitely time to change this.
> > BigData evangelist.
> >
> > - Ivan
More candidates:
- Alexey Zinoviev.
He is not a PMC member, but it's definitely time to change this.
BigData evangelist.
- Ivan Rakov.
He is not a PMC member, but it's definitely time to change this.
Distributed systems evangelist and great lead.
- Denis Magda.
Keeping this stable is also the
t; > am ready for this role ...
> >
> > Vladimir.
> >
> > чт, 24 окт. 2019 г. в 10:34, Anton Vinogradov :
> >
> > > More candidates:
> > >
> > > - Alexey Zinoviev.
> > > He is not a PMC member, but it's definitely time to change t
+1 for Pavel Tupitsyn (binding)
On Mon, Oct 28, 2019 at 9:38 PM Kumar, Sushil (CWM-NR) <
sushil.ku...@rbccm.com> wrote:
> + 1 Dmitry Pavlov
> > On Mon, Oct 28, 2019 at 9:07 PM Denis Magda wrote:
> > >
> > > +1 for Nikolay Izhikov (binding)
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Mon, Oct
Great news, thanks!
On Wed, Nov 27, 2019 at 11:29 AM Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> Igniters,
>
> As a final action in my almost year long effort in repairing data
> consistency related issues for transactional persistent caches I've
> prepared an article explaining
to do that.
> > >> > Cons:
> > >> > - different caches may have different defragmentation but we force
> to
> > >> stop
> > >> > whole node
> > >> > - offline node is a maintenance operation will require to add +1
> &g
Folks,
As a prereviewer, I'd like to say that the solution looks good to me, but
fresh eyes would be good.
On Fri, Oct 11, 2019 at 9:40 AM Denis Garus wrote:
> Hello, Igniters!
>
> I've raised the PR [1] with the sandbox for AI [2].
> Could somebody review it?
>
> If you have questions and
change does not look big enough for an IEP for
> me.
>
> чт, 3 окт. 2019 г. в 11:18, Anton Vinogradov :
>
> > Alexey,
> >
> > Sounds good to me.
> >
> > On Thu, Oct 3, 2019 at 10:51 AM Alexey Goncharuk <
> > alexey.goncha...@gmail.com>
> > wro
ment command on all nodes in the
> cluster simultaneously - this will be the fastest way possible.
>
> --AG
>
> пн, 30 сент. 2019 г. в 09:29, Anton Vinogradov :
>
> > Alexei,
> > >> stopping fragmented node and removing partition data, then starting it
> > again
>
;- ComputeJob;
> > > >- filter and transformer for ScanQuery.
> > > >
> > > > But, sure, we should execute any user-defined code in the sandbox on
> a
> > > > remote node.
> > > > Feel free to create issues.
> > > >
&g
I am not against the feature itself.
> Moreover, it is a great feature and improvement of security.
> I just want to say that we need to be sure that we are on the right way of
> implementing this without affecting other developers.
>
> PS: This is just my opinion, which ma
ully agree and see no other way to perform this.
> > PR already created and testing check scheduled.
> >
> This is good news, this means that we are on the same page! It was not so
> clear that the integration branch has been created and will be used to
> check all the failur
e.
> > After feature battle testing we can remove it in the next release.
> >
> > чт, 19 дек. 2019 г. в 15:26, Anton Vinogradov :
> >
> > > Slava,
> > >
> > > >> It would be nice to cut off a new branch from the release and
t;
> >> Shouldn't we target IGNITE-12470 to 2.8? It kind of does not make sense
> to
> >> add an ability to disable potentially dangerous change only in the next
> >> release.
> >>
> >> чт, 19 дек. 2019 г. в 16:18, Anton Vinogradov < a...@apache.org
, obviously, 100 ms faster :)
[1] https://issues.apache.org/jira/browse/IGNITE-12272
[2]
https://github.com/anton-vinogradov/ignite/commit/f8c27253b0ecfe7381418f505aafe942efe5a0a8
Singe, no objections here -> feature merged to 2.8.
On Thu, Dec 19, 2019 at 9:10 PM Николай Ижиков wrote:
> Good news, Anton!
>
> Thanks for your work on PME feature!
>
>
> > 19 дек. 2019 г., в 21:00, Anton Vinogradov написал(а):
> >
> > Folks,
> > &q
Cherry-pick commit to the ignite-2.8 branch.
>
> WDYT?
>
> On Wed, 18 Dec 2019 at 09:26, Nikolay Izhikov wrote:
> >
> > +1 to include PME free switch to 2.8
> >
> > ср, 18 дек. 2019 г., 8:31 Anton Vinogradov :
> >
> > > Maxim,
> > > htt
ignite-schedule does not look to be properly located or useful.
My +1 here.
On Thu, Dec 19, 2019 at 8:35 AM Ivan Pavlukhin wrote:
> Ilya,
>
> I think it is a good initiative! Do we really need to keep
> run/callLocall methods at all?
>
> ср, 18 дек. 2019 г. в 17:59, Ilya Kasnacheev :
> >
> >
e code?
> > I do not think it is a good idea.
> >
> > My "-1" here.
> >
> > On Thu, Dec 19, 2019 at 8:53 AM Anton Vinogradov wrote:
> >
> > > ignite-schedule does not look to be properly located or useful.
> > > My +1 here.
> > >
&g
gt; > Anton,
> > >
> > >
> > > Thank you.
> > > Have no objections, let's do it!
> > >
> > > On Wed, 18 Dec 2019 at 23:23, Anton Vinogradov wrote:
> > > >
> > > > Sure,
> > > > You may count on my assistan
ix
> all bugs".
>
> Please don't get me wrong, I don't have objections/concerns related to the
> 'pme-free-switch' feature itself. I do not quite understand the motivation
> for that zerg rush.
>
> Thanks,
> S.
>
> ср, 18 дек. 2019 г. в 23:23, Anton Vinogradov :
&
w failures and the release engineer agrees with the
> result, then and only then this feature can be merged into the release.
>
> This is my own view of the matter, and I do not insist that you should act
> in this way, but it seems to me that it would be safer and more correct.
>
> Thank
Main problem here that TC Bot ignores such failures for feature branches
(since they also happen in master).
So, you may gain green VISA without any checks.
Everyone,
Please make sure you VISAs are legal before the merge.
On Thu, Dec 5, 2019 at 2:10 PM Maxim Muzafarov wrote:
> Igniters,
>
>
>
+1 (binding)
Checked
- TC usage completeness and results,
- Urls correctness and content
On Fri, Feb 28, 2020 at 7:50 PM Denis Magda wrote:
> +1 (binding)
>
> Downloaded, started a cluster, ran several examples pulling Maven
> artifacts from the staging.
>
>
> -
> Denis
>
>
> On Fri, Feb 28,
> though:
>
> * Are there any downsides to using this feature?
> * When users should use it? What are the recommendations?
>
>
> -Artem
>
> On 04.03.2020 13:46, Anton Vinogradov wrote:
> > Artem,
> > Is it possible to create documentation fo
Artem, great!
Some minors:
>> read operations become more costly for caches with backup copies.
Since it makes sense only for cache with backups, can we say something like
"read operations become at least 2 times costly since backups checked as
well"
>> for atomic caches, a consistency
ult: The vote PASSES with 6 votes +1 (6 bindings), 0 two votes
> > and no -1.
> >
> >
> > +1 votes:
> > - Denis Magda (binding)
> > - Anton Vinogradov (binding)
> > - Pavel Tupitsyn (binding)
> > - Ivan Pavlukhin (binding)
> > - Alexey Zinoviev (bind
Artem,
Is it possible to create documentation for ReadRepair feature [1] [2]?
Feature marked as @IgnireExperimenta but ready to be used.
Javadoc [3] explains the details.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-31+Consistency+check+and+fix
[2]
Alexey,
>> In short, the root cause of this issue is that there are configurations
>> that allow a key to be stored on primary and backup nodes with different
>> versions.
Faced with the same problem during ReadRepair development.
>> I suggest to force reads from a primary
>> node inside
annotation marking an
> >> API or feature experimental. The corresponding ticket and PR are
> [2],[3].
> >>
> >> Please take a look at the description and suggest any edits to the
> >> javadoc if necessary.
> >>
> >> A side question - Anton V
501 - 600 of 874 matches
Mail list logo
