> > > > > > > > > >> look. The most annoying thing is poorly documented code :(
> > > > > > > > > Since your comments mostly about Javadoc (does this mean
> > that my
> > > > > > > solution
> > > > > > > > > is so great that you ask me only to fix Javadocs :) ?),
> > > > > > > > > I'd like to propo
t; > > > > > > >
> > > > > > > > >> By the way, is it required to add test related to
> fail-over
> > > > > > scenarios?
> > > > > > > > The best check is to use RR at real code.
> > > > > > > > For example, I'm injecting RR now to the test with concurrent
> > > &
; > that
> > > > > > > >> should cover existing limitations/improvements.
> > > > > > > >> I would suggest creating the following tasks, at least:
> > > > > > > Mostly agree with you, but
> > > > > > > - MVCC is not p
d Thin Client support?
> > > > > > Also, we should not produce stillborn issue.
> > > > > > All limitations listed at proxy creation method and they
> definitely
> > > are
> > > > > not
> > > > > > showstoppers and
gt; > > > > impossible (require much more time that feature's cost) to support
> > them
> > > > > all.
> > > > > I will be pretty happy in case someone will do this and provide
> help
> > if
> > > > > necessary!
> > > > >
&g
the recovery too
> > > > Do you mean per partition check and recovery?
> > > > That's a good idea, but I found it's not easy to imagine API to for
> > such
> > > > tool.
> > > > In case you ready to assist with proper API/design this will
> def
Вячеслав Коптилин <
> > > slava.kopti...@gmail.com>
> > > wrote:
> > >
> > > > Perhaps, it would be a good idea to think about the recovery tool/
> > > > control-utility command that will allow achieving the same goal.
> > &
s, it would be a good idea to think about the recovery tool/
> > > control-utility command that will allow achieving the same goal.
> > > If I am not mistaken it was already proposed in the email thread.
> > >
> > > Thanks,
> > > S.
> > >
> > &
> >
> > > Unfortunately, I cannot find a consensus about the whole functionality
> in
> > > any of these topics:
> > > -
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Consistency-check-and-fix-review-request-td41629.html
> >
ommand that will allow achieving the same goal.
> > > If I am not mistaken it was already proposed in the email thread.
> > >
> > > Thanks,
> > > S.
> > >
> > > ср, 10 июл. 2019 г. в 15:33, Вячеслав Коптилин <
> slava.kopti...@gmail.com>
lly merged and that is good news :)
> > >
> > > Unfortunately, I cannot find a consensus about the whole functionality in
> > > any of these topics:
> > > -
> > >
> >
> > http://apache-ignite-developers.2346864.n4.nabble.com/Consis
; Unfortunately, I cannot find a consensus about the whole functionality in
> > any of these topics:
> > -
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Consistency-check-and-fix-review-request-td41629.html
> > -
> >
> http://apache-ignite-developers.2346864.n4.n
; -
> http://apache-ignite-developers.2346864.n4.nabble.com/Read-Repair-ex-Consistency-Check-review-request-2-td42421.html
> Also, there are no comments/discussion in JIRA. That makes me sad :(
> especially when a feature is huge, not obvious and involves changing public
> API (and that is
://apache-ignite-developers.2346864.n4.nabble.com/Read-Repair-ex-Consistency-Check-review-request-2-td42421.html
Also, there are no comments/discussion in JIRA. That makes me sad :(
especially when a feature is huge, not obvious and involves changing public
API (and that is the case, I think
Folks,
Thanks to everyone for tips and reviews.
Yardstick checked, no performance drop found.
Additional measurement: RR get() is just up to 7% slower than regular get
on real benchmarks (8 clients, 4 servers, 3 backups)
Code merged to the master.
"Must have" tasks created and attached to the
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
- unexpected repairs at tx caches
- inconsistent state after the test finished (different entries across the
topology)
Slava,
>> I will take a look at your pull request if you don't mind.
Great news!
>> In any way, could you please update the IEP page with the list of
>> constraints/limitations of the proposed approach, TODOs, etc?
Not sure we should keep this at IEP until list (#4 from original letter) is
not
Hi Anton,
I will take a look at your pull request if you don't mind.
In any way, could you please update the IEP page with the list of
constraints/limitations of the proposed approach, TODOs, etc?
For instance, I would like to see all these limitations on the IEP page as
JIRA tickets. Perhaps,
Nikolay,
>> Should we consider it's removal in Ignite 3
Don't think so.
My initial ReadRepair implementation uses version to detect inconsistency.
Strategy can be changed later (most likely it will) or even provided
ability to use own strategy.
Data streamer's and cache.load's cases can be
Anton.
I worried about this limitation:
> Entries streamed using data streamer (using not a "cache.put" based updater)
> and loaded by cache.load.
As we discussed privately in this modes
*ALL ENTRIES ON ALL OWNERS WILL HAVE DIFFERENT VERSIONS*
Why we need this modes, in the first place?
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
21 matches
Mail list logo
