Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
If your changes can lead to this failure(s): We're grateful that you were a
volunteer to make the contribution to this project, but things change and you
may no longer be able to finalize
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
*Test with high flaky rate in master WebSessionSelfTest.testRestarts
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=6720374228021379378&branch=%3Cdef
Aleksey Plekhanov created IGNITE-13685:
--
Summary: Flaky failure of
FunctionalTest.testOptimitsticRepeatableReadUpdatesValue
Key: IGNITE-13685
URL: https://issues.apache.org/jira/browse/IGNITE-13685
Here are the slides from Alexey Goncharuk. Let's think this over and
continue on Monday:
https://go.gridgain.com/rs/491-TWR-806/images/Ignite_3_Plans_and_development_process.pdf
чт, 5 нояб. 2020 г. в 11:13, Anton Vinogradov :
> Folks,
>
> Should we perform cleanup work before (r)evolutional chang
Igniters,
Let's finalize the discussion [1] about the next upcoming major Apache
Ignite 2.10 release. The major improvements related to the proposed
release:
- Improvements for partition clearing related parts
- Add tracing of SQL queries.
- CPP: Implement Cluster API
- .NET: Thin client: Transa
Anton Kalashnikov created IGNITE-13684:
--
Summary: Rewrite PageIo resolver from static to explicit dependency
Key: IGNITE-13684
URL: https://issues.apache.org/jira/browse/IGNITE-13684
Project: Igni
Anton Kalashnikov created IGNITE-13683:
--
Summary: Added MVCC validation to ValidateIndexesClosure
Key: IGNITE-13683
URL: https://issues.apache.org/jira/browse/IGNITE-13683
Project: Ignite
Anton Kalashnikov created IGNITE-13682:
--
Summary: Added generic to maintenance mode feature
Key: IGNITE-13682
URL: https://issues.apache.org/jira/browse/IGNITE-13682
Project: Ignite
Issu
Anton Kalashnikov created IGNITE-13681:
--
Summary: Non markers checkpoint implementation
Key: IGNITE-13681
URL: https://issues.apache.org/jira/browse/IGNITE-13681
Project: Ignite
Issue Ty
Alex, thanks for pointing that out. Shame that I missed it.
пт, 6 нояб. 2020 г. в 13:45, Alex Plehanov :
> Guys,
>
> We already have FileWriteAheadLogManager#maxSegCountWithoutCheckpoint.
> Checkpoint triggered if there are too many WAL segments without checkpoint.
> Looks like you are talking ab
Guys,
We already have FileWriteAheadLogManager#maxSegCountWithoutCheckpoint.
Checkpoint triggered if there are too many WAL segments without checkpoint.
Looks like you are talking about this feature.
пт, 6 нояб. 2020 г. в 13:21, Ivan Daschinsky :
> Kirill and I discussed privately proposed appro
Kirill and I discussed privately proposed approach. As far as I understand,
Kirill suggests to implement some
heuristic to do a force checkpoint in some cases if user by mistake
misconfigured cluster in order to preserve
requested size of WAL archive.
Currently, as for me, this approach is question
The tickets are: [1] disables linger by default and [2] is the doc.
[1] https://issues.apache.org/jira/browse/IGNITE-13643
[2] https://issues.apache.org/jira/browse/IGNITE-13662
05.11.2020 11:00, Anton Vinogradov пишет:
Folks,
Seems, we've got an agreement that the fix is necessary.
Do we
Hi Frank!
There is an old ticket [1] - We will try to prioritize it to finish before
the end of the year it should prevent OOM for most cases.
[1] https://issues.apache.org/jira/browse/IGNITE-9182
вт, 3 нояб. 2020 г. в 18:53, frank li :
> Current code logic for DELETE is as follows:
> if WHERE
Kirill, how your approach will help if user tuned a cluster to do
checkpoints rarely under load?
No way.
пт, 6 нояб. 2020 г. в 12:19, ткаленко кирилл :
> Ivan, I agree with you that the archive is primarily about optimization.
>
> If the size of the archive is critical for the user, we have no pr
Ivan, I agree with you that the archive is primarily about optimization.
If the size of the archive is critical for the user, we have no protection
against this, we can always go beyond this limit.
Thus, the user needs to remember this and configure it in some way.
I suggest not to exceed this
Guys, fisrt of all, archiving is not for PITR at all, this is optimization.
If we disable archiving, every rollover we need to create new file. If we
enable archiving, we reserve 10 (by default) segments filled with zeroes.
We use mmap by default, so if we use no-archiver approach:
1. We firstly cr
17 matches
Mail list logo
