Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Denis, there were minor test failures on tc. Alex will fix them on Mon and I expect merge to happen right after. -- Yakov Zhdanov On Apr 22, 2017 2:22 AM, "Denis Magda" wrote: > Yakov, Sasha, > > Are you ready to merge all the changes and close the ticket? As far as I > understand, we plan to f

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Yakov, Sasha, Are you ready to merge all the changes and close the ticket? As far as I understand, we plan to freeze 2.0 branch the next week. — Denis > On Apr 11, 2017, at 8:59 AM, Denis Magda wrote: > > Yasha, > > I’ve updated the javadoc for IgniteConfiguration.metricsUpdateFrequency and

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Yasha, I’ve updated the javadoc for IgniteConfiguration.metricsUpdateFrequency and merged the changes into your branch (see JIRA). The rest is fine for now. An advance documentation on how the heartbeats are implemented can be done in readme.io . — Denis > On Apr 11, 2017,

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Messages renaming is never compatible =) Denis, did you try to update javadocs? --Yakov 2017-04-10 21:41 GMT+03:00 Denis Magda : > Yasha, > > Thanks, I’ve replied you in the ticket. > > In a nutshel, let’s try to merge current breaking changes to 2.0 and do > the rest of compatible refactoring

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Yasha, Thanks, I’ve replied you in the ticket. In a nutshel, let’s try to merge current breaking changes to 2.0 and do the rest of compatible refactoring in further releases. Are you agree with this? — Denis > On Apr 10, 2017, at 8:39 AM, Yakov Zhdanov wrote: > > Alex Belyak, please go ahead

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Alex Belyak, please go ahead. Thank you for your help! There were some work I did not expect to happen. --Yakov 2017-04-10 18:13 GMT+03:00 Sasha Belyak : > Yakov, I can do replacement "heartbeat" -> "metricsUpdate". Can I get > https://issues.apache.org/jira/browse/IGNITE-4799 ? > > 2017-04-10

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Yakov, I can do replacement "heartbeat" -> "metricsUpdate". Can I get https://issues.apache.org/jira/browse/IGNITE-4799 ? 2017-04-10 14:50 GMT+03:00 Yakov Zhdanov : > Guys, I have finished with initial changes. There were a little bit more > work to do than I originally estimated. > > Denis, can

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Guys, I have finished with initial changes. There were a little bit more work to do than I originally estimated. Denis, can you please reply in the ticket? I would like you to propose documentation changes. Can you help? There is also another question - we have a lot of "heartbeat" mentions in TC

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Alex, I am finishing this up. --Yakov 2017-03-30 14:03 GMT+03:00 Александр Меньшиков : > Yakov, can I take this ticket or you have already started to implement it? > Ask because you are an assignee in JIRA. > > 2017-03-07 22:21 GMT+03:00 Denis Magda : > >> Good, the ticket is ready: >> https://i

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Yakov, can I take this ticket or you have already started to implement it? Ask because you are an assignee in JIRA. 2017-03-07 22:21 GMT+03:00 Denis Magda : > Good, the ticket is ready: > https://issues.apache.org/jira/browse/IGNITE-4799 < > https://issues.apache.org/jira/browse/IGNITE-4799> > >

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Good, the ticket is ready: https://issues.apache.org/jira/browse/IGNITE-4799 — Denis > On Mar 7, 2017, at 1:47 AM, Yakov Zhdanov wrote: > >>> What’s about compute engine load balancers then? They rely on the > metrics received from remote nod

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

>> What’s about compute engine load balancers then? They rely on the metrics received from remote nodes. First of all, that was poor design decision - to make different components dependant, possibly, through user-defined implementation of Discovery Spi. What you say makes sense to me. Let's remo

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

> On Mar 1, 2017, at 11:22 PM, Yakov Zhdanov wrote: > > I don't think new name makes things better. > > Btw, what if we remove metrics from heartbeats at all and make metrics > local and allow aggregations only via management console? > What’s about compute engine load balancers then? They rel

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

I don't think new name makes things better. Btw, what if we remove metrics from heartbeats at all and make metrics local and allow aggregations only via management console? --Yakov 2017-03-02 2:24 GMT+03:00 Denis Magda : > Yasha, > > Is there any other reason rather than compatibility that prev

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Yasha, Is there any other reason rather than compatibility that prevents us from both improving documentation and renaming the parameter? — Denis > On Mar 1, 2017, at 1:13 AM, Yakov Zhdanov wrote: > > I think we should not rename this, but properly document the behavior and > all the relation

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

I think we should not rename this, but properly document the behavior and all the relationships. --Yakov 2017-02-28 20:40 GMT+03:00 Dani Traphagen : > I had this thought when exploring this parameter at first and only was able > to change my understanding when evaluating it more deeply in the so

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

I had this thought when exploring this parameter at first and only was able to change my understanding when evaluating it more deeply in the source and reaching out to other users/devs. There could be an issue with new users who think increasing the hb frequency will impact inter-node failure dete

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

They expect exactly what the name of the TcpDiscoverySpi.heartbeatsFrequency method says - rate of heartbeats will be adjusted if you play with this parameter. However, this is not true because the frequency of heartbeats is calculated from the failure detection timeout. — Denis > On Feb 28,

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Denis, I did not get your last message. What did users expect from changing hbFreq? --Yakov 2017-02-28 4:08 GMT+03:00 Dmitriy Setrakyan : > Yakov, what do you think? > > On Mon, Feb 27, 2017 at 4:17 PM, Denis Magda wrote: > > > Frankly, I decided to initiate this discussion after talking to man

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Yakov, what do you think? On Mon, Feb 27, 2017 at 4:17 PM, Denis Magda wrote: > Frankly, I decided to initiate this discussion after talking to many > Apache Ignite users who had initially thought that > TcpDiscoverySpi.heartbeatsFrequency > manages the heartbeats and they had tried to tweak it

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Frankly, I decided to initiate this discussion after talking to many Apache Ignite users who had initially thought that TcpDiscoverySpi.heartbeatsFrequency manages the heartbeats and they had tried to tweak it not getting a desired outcome. Even more, TcpDiscoverySpi.heartbeatsFrequenc’s javadoc

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

To me it sounds rather as an aesthetic change. Is it really worth breaking the API for this? On Mon, Feb 27, 2017 at 3:30 PM, Denis Magda wrote: > The heartbeats frequency has to be lower than the failure detection > timeout. This is why we decided to calculate the former basing on a value > set

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

The heartbeats frequency has to be lower than the failure detection timeout. This is why we decided to calculate the former basing on a value set for the latter rather than making a user to adjust both properties properly. This is how both parameters became related some time ago :) Honestly, I

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Hm... I don't think that heartbeat frequency has to be associated with failure detection. What if we just update the javadoc for this parameter, stating that it has to do with metrics update only? On Mon, Feb 27, 2017 at 11:44 AM, Denis Magda wrote: > Igniters, > > Long time ago we updated the l

Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Igniters, Long time ago we updated the logic in discovery SPI that issues heartbeats messages from one node to another. Presently, heartbeats frequency is calculated basing on IgniteConfiguration.failureDetectionTimeout meaning that TcpDiscoverySpi.heartbeatsFrequency has nothing to do with hea