Alex, Igniters, sorry for a delay. Got swamped with other duties.
Does it wait till the next week? I'll make sure to dedicate some time for
that. Or if we'd like to run faster then I'll appreciate if someone else
steps in and prepares a list this week. I'll help to review and solidify it.
-
Jean-Denis Giguère created IGNITE-11986:
---
Summary: Failed to deserialize object with given class loader:
sun.misc.Launcher$AppClassLoader
Key: IGNITE-11986
URL:
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
Denis,
Are we ready to present the list to the user list?
вт, 2 июл. 2019 г. в 00:27, Denis Magda :
> I wouldn't kick off dozens of voting discussions. Instead, the content on
> the wiki page needs to be cleaned and rearranged. This will make the
> content readable and comprehensible. I can do
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.
>
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
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
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
+1.
Nikita, please, go ahead.
вт, 16 июля 2019 г., 11:45 Nikita Amelchev :
> 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
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
Anton,
Thank you for clarification.
вт, 16 июл. 2019 г. в 09:24, Anton Vinogradov :
>
> Ivan R.
>
> Thanks.
> I'll try to implement approach you proposed.
>
> Ivan P.
>
> >> what prevents primary partition relocation when
> >> Read Repair is in progress? Is there a transaction or an exlicit
Ivan R.
Thanks.
I'll try to implement approach you proposed.
Ivan P.
>> what prevents primary partition relocation when
>> Read Repair is in progress? Is there a transaction or an exlicit lock?
Did you mean partition eviction?
RR is almost a regular get with the same logic. It maps on some
Svala,
>> Could you please take a look at PR:
Going to review today, thanks for attaching the bot visa.
>> 1. Should I consider that my cluster is broken? There is no answer! The
>> false-positive result is possible.
That's a question about atomic nature.
It's not impossible to lock atomic entry
Anton,
You referenced to failover scenarios. I believe that everything is
described in IEP. But to make this discussion self-sufficient could
you please outline what prevents primary partition relocation when
Read Repair is in progress? Is there a transaction or an exlicit lock?
пн, 15 июл. 2019
14 matches
Mail list logo
