Denis,
>> Node availability check is based on the fact, that it receives fresh
>> metrics once in metricsUpdateFreq ms.
I see the problem here.
Node availability should be checked using some ping (fast and small)
message instead of huge and slow metrics message.
On Wed, Jan 30, 2019 at 4:08 PM
Yakov,
> You can put hard limit and process enqued MetricsUpdate message
> if last one of the kind was processed more than metricsUpdFreq millisecs
ago.
Makes sense. I'll try implementing it.
> I would suggest we allow queue overflow for 1 min, but if situation does
not go to normal then node
>
Folks,
Did we already check that omitting hearbeat priority does not break
discovery? I am currently working on another issue with discovery and
skipping hearbeat priority would help a lot in my case.
--AG
пт, 11 янв. 2019 г. в 23:21, Yakov Zhdanov :
> > How big the message worker's queue may
> How big the message worker's queue may grow until it becomes a problem?
Denis, you never know. Imagine node may be flooded with messages because of
the increased timeouts and network problems. I remember some cases with
hundreds of messages in queue on large topologies. Please, no O(n)
Denis,
+1 to the idea to get rid of priority.
Discovery should handle only messages used to update cluster state and
topology.
They are all small and have high priority.
There is no real reason to use discovery for metrics and similar "readonly"
features.
Maybe, better case it to have special
I like the idea to make all messages be processed with equal priority.
It will make nodes with overgrown discovery message queues die more often,
though. But maybe, this is how it's supposed to work.
Denis
пт, 11 янв. 2019 г. в 16:26, Denis Mekhanikov :
> Yakov,
>
> Sounds good. But there is a
Yakov,
Sounds good. But there is a flaw in the procedure, that you described.
If we have a TcpDiscoveryMetricsUpdateMessage in a queue, and a newer one
arrives, then we will consider the existing one obsolete and won't process
it. The newest metrics update message will be moved to the queue's
Denis, what if we remove priority difference for messages and always add
new to the end of the queue?
As far as traversing the queue - I don't like O(n) approaches =). So, with
adding all messages to the end of the queue (removing prio difference) I
would suggest that we save latest 1st lap
Denis,
Correct me in case I got it all wrong.
Since metrics are scheduled, a possible situation is to have more than 1
TcpDiscoveryMetricsUpdateMessage inside the queue due to slow ... some
reasons.
Proposed solution looks like a fix hides the real problem.
My proposal is
1) Write a warning
