Internal classes are exposed in public API

[Nikolay Izhikov-2]

Hello, Igniters.

* IGNITE-12552: Move ReadOnlyMetricRegistry to public API merged to the master and cherry-picked to the 2.8.
So the main issue with the Metric API solved.

* I raised the PR [1] to fix second issue with the new Metric API: absence of the public Java API to get metrics.
This PR introduces the following changes:

1. IgniteMetric interface created: it provides Java API to access Ignite metrics created with the new Metric API.

```
public interface IgniteMetric extends Iterable<ReadOnlyMetricRegistry> {
    @Nullable ReadOnlyMetricRegistry registry(String name);
}
```

2. All deprecation javadocs regarding metrics now reference to the public IgniteMetric instead of internal GridMetricManager:

  > @deprecated Use {@link IgniteMetric} instead.

3. Tests refactored to use IgniteMetric instead of GridMetricManager when possible.

Please, review.

[1]  https://github.com/apache/ignite/pull/7283

> 21 янв. 2020 г., в 17:51, Николай Ижиков <[hidden email]> написал(а):
>
> Hello, Igniters.
>
> Alexey approved my PR [1] regarding fixing public API for metric exporters.
> I’m waiting for a bot visa and merge this PR.
>
> As we discussed, the metrics API will be marked with IgniteExperimental annotation.
>
> If anyone has any objection to this plan, please provide your feedback.
>
> [1] https://github.com/apache/ignite/pull/7269
>
>> 21 янв. 2020 г., в 13:45, Николай Ижиков <[hidden email]> написал(а):
>>
>> Thanks, for the review Alexey.
>>
>> I will fix your comment and  try to implement Monitoring facade, shortly.
>>
>>> 21 янв. 2020 г., в 13:32, Alexey Goncharuk <[hidden email]> написал(а):
>>>
>>> Nikolay,
>>>
>>> I left a single comment in the PR about the histogram metric. I think the
>>> API looks much cleaner now.
>>>
>>> I will take care of the @IgniteExperimental annotation.
>>>
>>> пн, 20 янв. 2020 г. в 20:55, Николай Ижиков <[hidden email]>:
>>>
>>>> Alexey.
>>>>
>>>> PR [1] is waiting for your review.
>>>> Please, take a look.
>>>>
>>>> I think we should do the following before 2.8 release
>>>>
>>>> * Introduce new @IgniteExperimental annotation as discussed.
>>>> * Mark Monitoring API with it.
>>>> * merge «[IEP-35] Expose MetricRegistry to the public API» to 2.8
>>>> * merge «[IEP-35] public Java metric API» to 2.8
>>>>
>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>
>>>>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk <[hidden email]>
>>>> написал(а):
>>>>>
>>>>> Nikolay,
>>>>>
>>>>> Should we wait for both of the tickets given that we agreed that we are
>>>>> putting an experimental marker on the new APIs? I'm ok to fix only the
>>>>> first one and add the experimental marker so that we do not delay 2.8
>>>>> release.
>>>>>
>>>>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков <[hidden email]>:
>>>>>
>>>>>> Andrey.
>>>>>>
>>>>>> Let’s move from the long letters to the code.
>>>>>> If you want to change API - please, propose this changes.
>>>>>> I think everybody wins if we make our API better.
>>>>>>
>>>>>> Please, describe proposed changes.
>>>>>> It would be great if you have some examples or PR for it.
>>>>>>
>>>>>> As for this release, I have plans to contribute tickets
>>>>>> «[IEP-35] Expose MetricRegistry to the public API» [1] and
>>>>>> «[IEP-35] public Java metric API» [2] for it.
>>>>>>
>>>>>> Any objections on it?
>>>>>>
>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-12553
>>>>>>
>>>>>>
>>>>>>> 20 янв. 2020 г., в 13:08, Andrey Gura <[hidden email]> написал(а):
>>>>>>>
>>>>>>> It solves problem.
>>>>>>>
>>>>>>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
>>>>>>> <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> After giving it some thought, I agree with Denis - there is nothing
>>>>>> wrong
>>>>>>>> with exposing the new APIs, we just need to make it clear that we are
>>>>>> still
>>>>>>>> going to change it.
>>>>>>>>
>>>>>>>> Should we Introduce something like @IgniteExperimental annotation (I
>>>>>>>> believe it has been discussed a dozen of times on the dev-list)?
>>>>>>>>
>>>>>>>> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov <[hidden email]>:
>>>>>>>>
>>>>>>>>> +1 to mark feature or whole release as EA.
>>>>>>>>>
>>>>>>>>> пт, 17 янв. 2020 г., 23:00 Denis Magda <[hidden email]>:
>>>>>>>>>
>>>>>>>>>> Folks, if you don't mind I'll share some thoughts/suggestions as an
>>>>>>>>>> observer who was not involved in the feature development.
>>>>>>>>>>
>>>>>>>>>> It's absolutely 'ok' to deprecate an API that is replaced with a
>>>> much
>>>>>>>>>> better version. However, we should do this only when the new APIs
>>>> are
>>>>>>>>>> production-ready. If there are still many limitations or open items
>>>>>> then
>>>>>>>>>> don't deprecate anything that exists and release the new APIs
>>>>>> labeling as
>>>>>>>>>> early access. What if release the improvements labeling as EA
>>>> instead
>>>>>> of
>>>>>>>>>> hiding them completely?
>>>>>>>>>>
>>>>>>>>>> I would also encourage us to put aside emotions, don't blame or
>>>> point
>>>>>>>>>> fingers. This IEP is a great initiative and you both have already
>>>>>> done a
>>>>>>>>>> tremendous job by developing, architecting and reviewing changes.
>>>>>> Just be
>>>>>>>>>> respectful. Nobody is trying to block the feature from being
>>>> released.
>>>>>>>>>> Everyone would be glad to tap into improvements and start using them
>>>>>> in
>>>>>>>>>> prod. But if more time is needed for the GA let's reiterate a bit.
>>>>>>>>>>
>>>>>>>>>> -
>>>>>>>>>> Denis
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков <
>>>> [hidden email]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>> Also I agree with Alexey about introducing public IgniteMonitoring
>>>>>>>>>> facade
>>>>>>>>>>>
>>>>>>>>>>> This is not an issue with the API.
>>>>>>>>>>> Just the new feature that doesn’t affects API.
>>>>>>>>>>> Moreover, I create a ticket to fix it, already.
>>>>>>>>>>>
>>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
>>>>>>>>> then
>>>>>>>>>>> test will fail. It's just not good tests.
>>>>>>>>>>>
>>>>>>>>>>> My changes doesn’t affect any `staticticsEnabled` property.
>>>>>>>>>>> I don’ understand your point here.
>>>>>>>>>>>
>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
>>>>>>>>>>>
>>>>>>>>>>> It’s not redundant.
>>>>>>>>>>> It required for exporters and provide read only access to
>>>>>>>>> MetricRegistry
>>>>>>>>>>> existing in the node.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
>>>>>>>>>>>
>>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
>>>> use
>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
>>>>>>>>>>>
>>>>>>>>>>> Why this is issue?
>>>>>>>>>>>
>>>>>>>>>>>> Inconsistent MetricRegistry API.
>>>>>>>>>>>
>>>>>>>>>>> It’s consistent.
>>>>>>>>>>>
>>>>>>>>>>>> Metrics lookups from map instead of using direct reference
>>>>>>>>>>>> (performance problem).
>>>>>>>>>>>
>>>>>>>>>>> 1. We(You and I) did this choice together to simplify creation of
>>>> the
>>>>>>>>> new
>>>>>>>>>>> metrics.
>>>>>>>>>>> 2. This is not public API issue.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
>>>>>>>>>>>
>>>>>>>>>>> I don’t ignore this flag.
>>>>>>>>>>> It just doesn’t exists in new framework(because of scope).
>>>>>>>>>>> I don’t think it’s an issue.
>>>>>>>>>>>
>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
>>>>>>>>>> practices.
>>>>>>>>>>>
>>>>>>>>>>> Please, clarify your statement.
>>>>>>>>>>> What is best MBeans practices you are talking about?
>>>>>>>>>>>
>>>>>>>>>>>> Not finished IGNITE-11927
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> How this can be API issue?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 17 янв. 2020 г., в 20:52, Andrey Gura <[hidden email]>
>>>>>> написал(а):
>>>>>>>>>>>>
>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
>>>>>> PR
>>>>>>>>>>> [1].
>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
>>>>>>>>> release.
>>>>>>>>>>>>
>>>>>>>>>>>> As I mentioned already IGNITE-11927 is part of IEP-35 and
>>>>>>>>>>>> implementation seriously affects API's. Also I agree with Alexey
>>>>>>>>> about
>>>>>>>>>>>> introducing public IgniteMonitoring facade. So thiss PR doesn't
>>>> fix
>>>>>>>>>>>> all issues.
>>>>>>>>>>>>
>>>>>>>>>>>>>> I talk about ignored existing functionality.
>>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
>>>>>>>>>>>>
>>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
>>>>>>>>>>>> then test will fail. It's just not good tests.
>>>>>>>>>>>>
>>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
>>>> will
>>>>>>>>>> fix
>>>>>>>>>>> it ASAP.
>>>>>>>>>>>>
>>>>>>>>>>>> I already fix it all in IGNITE-11927
>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>> We should move the product forward and shouldn't hide major
>>>>>>>>>>> contribution from the user just because your second guess «I don’t
>>>>>> like
>>>>>>>>>> the
>>>>>>>>>>> API I just reviewed and approved».
>>>>>>>>>>>>
>>>>>>>>>>>> We should move the product forward with with really finished
>>>>>>>>> features,
>>>>>>>>>>>> not pieces of features.
>>>>>>>>>>>>
>>>>>>>>>>>>> So I am against this proposal.
>>>>>>>>>>>>
>>>>>>>>>>>> It is not argument.
>>>>>>>>>>>>
>>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
>>>> discuss
>>>>>>>>>> them.
>>>>>>>>>>>>
>>>>>>>>>>>> We can prepare it together. But we can't block release.
>>>>>>>>>>>>
>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
>>>>>>>>>>>>> What is *ALL* problems?
>>>>>>>>>>>>
>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
>>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
>>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
>>>> use
>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
>>>>>>>>>>>> Inconsistent MetricRegistry API.
>>>>>>>>>>>> Metrics lookups from map instead of using direct reference
>>>>>>>>>>>> (performance problem).
>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
>>>>>>>>>> practices.
>>>>>>>>>>>> Not finished IGNITE-11927
>>>>>>>>>>>>
>>>>>>>>>>>> It's enough I believe.
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:28 PM Николай Ижиков <
>>>> [hidden email]
>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Andrey.
>>>>>>>>>>>>>
>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
>>>> PR
>>>>>>>>>> [1].
>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
>>>>>>>>> release.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I talk about ignored existing functionality.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
>>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
>>>> will
>>>>>>>>>> fix
>>>>>>>>>>> it ASAP.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>
>>>>>>>>>>>>> We should move the product forward and shouldn't hide major
>>>>>>>>>>> contribution from the user just because your second guess «I don’t
>>>>>> like
>>>>>>>>>> the
>>>>>>>>>>> API I just reviewed and approved».
>>>>>>>>>>>>> So I am against this proposal.
>>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
>>>> discuss
>>>>>>>>>> them.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
>>>>>>>>>>>>>
>>>>>>>>>>>>> What is *ALL* problems?
>>>>>>>>>>>>> Seems, we never be able to solve *ALL* problems.
>>>>>>>>>>>>> But, we should move the product forward.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As for your steps [1-6].
>>>>>>>>>>>>> I’m always following these steps during my contribution.
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 17 янв. 2020 г., в 19:08, Andrey Gura <[hidden email]>
>>>>>>>>> написал(а):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The discussion is hot and can be endless. So in separate post I
>>>>>>>>> want
>>>>>>>>>>>>>> propose my solution.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>> 2. Create special feature branch B.
>>>>>>>>>>>>>> 3. In branch B will be merged IGNITE-11927
>>>>>>>>>>>>>> 4. Because IGNITE-11927 doesn't solve all problems we should
>>>>>>>>> propose
>>>>>>>>>>>>>> solution and implement it in branch B.
>>>>>>>>>>>>>> 5. Testing, usability testing, fixing, etc iteratively.
>>>>>>>>>>>>>> 6. Merge it to master and in new release branch if needed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Independent step. There are some problem which should be fixed
>>>> in
>>>>>>>>> 2.8
>>>>>>>>>>>>>> before release otherwise we introduce problems with
>>>> compatibility
>>>>>>>>>>>>>> which will haunt us till next major release. I'll create
>>>> tickets.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:03 PM Andrey Gura <[hidden email]>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
>>>>>> code.
>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
>>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
>>>>>> major
>>>>>>>>>>> release.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We don't know anything about development processes our users. I
>>>>>>>>> can
>>>>>>>>>>>>>>> admit that process could require that deprecated methods/APIs
>>>> are
>>>>>>>>>> not
>>>>>>>>>>>>>>> allowed for example.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
>>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
>>>> don't
>>>>>>>>>> give
>>>>>>>>>>> me any information about it’s purpose and responsibilities.
>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I understand this. But I'm not Ignite user, I'm Ignite
>>>> developer.
>>>>>>>>>> The
>>>>>>>>>>>>>>> key moment in my message *from user stand point*. From my point
>>>>>> of
>>>>>>>>>>>>>>> view it is very not intuitive solution and this interface is
>>>>>>>>>>>>>>> redundant.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
>>>> example.
>>>>>>>>>>> There are other entities with such flag.
>>>>>>>>>>>>>>>> They still works as expected.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Actually not. I fixed many such issues during IGNITE-11927
>>>>>>>>>>> implementation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Why do you decided do in such way?
>>>>>>>>>>>>>>>> Because of the scope.
>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
>>>> other
>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I talk not about ability. I talk about ignored existing
>>>>>>>>>> functionality.
>>>>>>>>>>>>>>> So scope is not case here.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
>>>> exporter
>>>>>>>>>>> can’t.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Actually list is not metric at all as I already told.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 5:26 PM Николай Ижиков <
>>>>>>>>> [hidden email]
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Andrey.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
>>>>>> code.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
>>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
>>>>>> major
>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
>>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
>>>> don't
>>>>>>>>>> give
>>>>>>>>>>> me any information about it’s purpose and responsibilities.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Each SPI would have a `ReadOnlyMetricManager` which provides
>>>>>>>>> access
>>>>>>>>>>> to collection of `ReadOnlyMetricRegistry`
>>>>>>>>>>>>>>>> which has a collection of `Metric`.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So we reflects two-level structure we have in the internal API
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> GridMetricManager -> Collection[MetricRegistry] ->
>>>>>>>>>> Collection[Metric]
>>>>>>>>>>>>>>>> ReadOnlyMetricManager -> Collection[ReadOnlyMetricRegistry] ->
>>>>>>>>>>> Collection[Metric]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
>>>> example.
>>>>>>>>>>> There are other entities with such flag.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> They still works as expected.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Why do you decided do in such way?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because of the scope.
>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
>>>> other
>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
>>>> exporter
>>>>>>>>>>> can’t.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>> https://github.com/apache/ignite/pull/7269/files#diff-0ae5657231fc4c1f650493b02190b81bR25
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 16:57, Andrey Gura <[hidden email]>
>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
>>>>>>>>>> reviewers
>>>>>>>>>>> of the Metric API.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes. But if I'm not missing some thing you were major
>>>> developer
>>>>>>>>> of
>>>>>>>>>>>>>>>>> Metric API :) Shit happens. And it happened.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
>>>> that
>>>>>>>>>> are
>>>>>>>>>>> still supported and don't offer reasonable substitution.
>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There is such concept - backward compatibility. I understand
>>>>>>>>> that
>>>>>>>>>>>>>>>>> deprecation of some interface doesn't break backward
>>>>>>>>> compatibility
>>>>>>>>>>> but
>>>>>>>>>>>>>>>>> it leads to question^ what should I use instead of this. And
>>>>>>>>>>>>>>>>> MetricExporterSpi is not answer for this question. Because it
>>>>>> is
>>>>>>>>>>> brand
>>>>>>>>>>>>>>>>> new API and it requires rewrite client code.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
>>>> the
>>>>>>>>>>> exporters.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No it is not. It's completely artificial thing which allow
>>>>>>>>> iterate
>>>>>>>>>>> via
>>>>>>>>>>>>>>>>> all metric registries. GridMetricManager implements this
>>>>>>>>> interface
>>>>>>>>>>>>>>>>> while it is not metric registry. Form user stand point it is
>>>>>>>>> very
>>>>>>>>>>>>>>>>> strange interface which don't give me any information about
>>>>>> it's
>>>>>>>>>>>>>>>>> purpose and responsibilities.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
>>>> example.
>>>>>>>>>>> There
>>>>>>>>>>>>>>>>> are other entities with such flag.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And that done, intentionally.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Why do you decided do in such way? Why you ignore existing
>>>>>>>>>>>>>>>>> functionality? It affects user expectations and experience.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes? I'm working. Unfortunately we are not synchronized in
>>>> this
>>>>>>>>>>>>>>>>> context and I should redo all metrics related changes in
>>>> order
>>>>>>>>> to
>>>>>>>>>>>>>>>>> merge it with my changes. Anyway, my change doesn't solve all
>>>>>>>>>>> problems
>>>>>>>>>>>>>>>>> (e.g. it doesn't introduce IgniteMonitoring facade).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Unfortunately it will be just fix. In my solution it is
>>>>>>>>> redesign.
>>>>>>>>>>> Stop
>>>>>>>>>>>>>>>>> fixing issues, let's do things. It requires deeper changes.
>>>> My
>>>>>>>>>>> changes
>>>>>>>>>>>>>>>>> blocks AI 2.8 release because it big enough. So it retargeted
>>>>>> on
>>>>>>>>>> the
>>>>>>>>>>>>>>>>> next release. And it is one more reason for moving the
>>>> changes
>>>>>>>>> to
>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> internal packages. And it isn't good news for me because I
>>>> will
>>>>>>>>> go
>>>>>>>>>>>>>>>>> throughout pan and tiers of merge. But it is right.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, I know. But they should not be exported by
>>>>>>>>> MetricExporterSpi
>>>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 3:37 PM Николай Ижиков <
>>>>>>>>>> [hidden email]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Andrey, thanks for your opinion and your ownest critisism.
>>>>>>>>>>>>>>>>>> I can’t wait for your contribution.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
>>>>>>>>>> reviewers
>>>>>>>>>>> of the Metric API.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
>>>> that
>>>>>>>>>> are
>>>>>>>>>>> still supported and don't offer reasonable substitution.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
>>>>>>>>>>> MetricExporterSpi's because it are still not-production ready.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It’s ready.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
>>>> doesn't
>>>>>>>>>>> solve the problem because this interface exposes internal Metric
>>>>>>>>>> interface
>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Not, its’ not.
>>>>>>>>>>>>>>>>>> Please, see `org.apache.ignite.spi.metric.LongMetric` and
>>>>>> other
>>>>>>>>>>> public interface.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> API of MetricRegistry is inconsistent.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> MetricRegistry is the internal API.
>>>>>>>>>>>>>>>>>> Feel free to create ticket for an issues with it and I will
>>>>>> try
>>>>>>>>>> to
>>>>>>>>>>> fix it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
>>>> the
>>>>>>>>>>> exporters.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
>>>>>>>>>>>>>>>>>> And that done, intentionally.
>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 15:09, Andrey Gura <[hidden email]>
>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
>>>> that
>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still not-production
>>>>>> ready.
>>>>>>>>>>> There
>>>>>>>>>>>>>>>>>>> are some issues with it and usage of ReadOnlyMetricRegistry
>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>> just one of them.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
>>>> doesn't
>>>>>>>>>>> solve
>>>>>>>>>>>>>>>>>>> the problem because this interface exposes internal Metric
>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>> implementations. So your PR is incomplete.
>>>>>>>>>>>>>>>>>>> Moreover, API of MetricRegistry is inconsistent. E.g.
>>>>>>>>>>> register(name,
>>>>>>>>>>>>>>>>>>> supplier, desc) method returns registered metric for some
>>>>>>>>> types
>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> doesn't for other. register(metric) method is inconsistent
>>>> in
>>>>>>>>>>> sense of
>>>>>>>>>>>>>>>>>>> metric naming. ReadOnlyMetricRegistry interface is
>>>> redundant.
>>>>>>>>>>>>>>>>>>> MetricExporterSpi should be revised because it absolutely
>>>> not
>>>>>>>>>>>>>>>>>>> intuitive because it requires ReadOnlyMetricRegistry and
>>>> it's
>>>>>>>>>>> purpose
>>>>>>>>>>>>>>>>>>> is undefined.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> One more point. IEP-35 is still not fully implemented. Some
>>>>>>>>>>> things are
>>>>>>>>>>>>>>>>>>> not taken into account. Exporters expose metrics if they
>>>> are
>>>>>>>>>>> disabled.
>>>>>>>>>>>>>>>>>>> JMX beans exposes values that don't confirm to best
>>>> practices
>>>>>>>>>> [1].
>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all. Ubiquitous
>>>>>> merics
>>>>>>>>>>> lookup
>>>>>>>>>>>>>>>>>>> from hash map instead of usage reference for getting
>>>> metrics
>>>>>>>>>>> values
>>>>>>>>>>>>>>>>>>> (it is just performance issue). Also IGNITE-11927 is not
>>>>>>>>>>> implemented
>>>>>>>>>>>>>>>>>>> which also changes interfaces significantly.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Let's just admit that the implementation is immature and
>>>> must
>>>>>>>>> be
>>>>>>>>>>> moved
>>>>>>>>>>>>>>>>>>> to the internal packages.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> And because we already merged partially implemented IEP to
>>>>>> the
>>>>>>>>>>> master
>>>>>>>>>>>>>>>>>>> branch we *must move all currently public APIs to the
>>>>>> internal
>>>>>>>>>>> API*
>>>>>>>>>>>>>>>>>>> while it will not be ready for publication.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> And the last but not least. What is happening indicates a
>>>>>>>>>> immature
>>>>>>>>>>>>>>>>>>> development process which must be revised. I don't want
>>>>>>>>> discuss
>>>>>>>>>>> it in
>>>>>>>>>>>>>>>>>>> this thread but we must not allow merge of change to the
>>>>>>>>> master
>>>>>>>>>>> branch
>>>>>>>>>>>>>>>>>>> before it will completed, that is we must use feature
>>>>>> branches
>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> full IEP not only for particular tickets. And also we
>>>> should
>>>>>>>>>>>>>>>>>>> reformulate IEP process in order to avoid things like this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>> https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:49 PM Николай Ижиков <
>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Alex.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> OK, I may leverage your experience and create pure Java
>>>> API.
>>>>>>>>>>>>>>>>>>>> Ticket [1] created.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> But, personally, I don’t agree with you.
>>>>>>>>>>>>>>>>>>>> Ignite has dozens of the API that theoretically have a
>>>> usage
>>>>>>>>>>> scenario, but in real-world have 0 custom implementation and
>>>> usages.
>>>>>>>>>>>>>>>>>>>> Moreover, many APIs that were created with the intentions
>>>>>> you
>>>>>>>>>>> mentioned is abandoned now and confuses users.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You can just see count of the tests we just mute on the
>>>> TC.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Can you, please, take a look at the fix regarding puck API
>>>>>>>>>> issue
>>>>>>>>>>> you mentioned in your first letter [2], [3]
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-12553
>>>>>>>>>>>>>>>>>>>> [2] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/IGNITE-12552
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 12:12, Alexey Goncharuk <
>>>>>>>>>>> [hidden email]> написал(а):
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Nikolay,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Why do you think this is a wrong usage pattern? From the
>>>>>> top
>>>>>>>>>> of
>>>>>>>>>>> my head,
>>>>>>>>>>>>>>>>>>>>> here is a few cases of direct metric API usage that I
>>>> know
>>>>>>>>> are
>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>>>> being used in production:
>>>>>>>>>>>>>>>>>>>>> * A custom task execution scheduling service with load
>>>>>>>>>>> balancing based on
>>>>>>>>>>>>>>>>>>>>> utilization metrics readings from Java code
>>>>>>>>>>>>>>>>>>>>> * Cleanup task trigger based on metrics readings
>>>>>>>>>>>>>>>>>>>>> * A custom health-check endpoint for an application with
>>>> an
>>>>>>>>>>> embedded
>>>>>>>>>>>>>>>>>>>>> Ignite node for Kubernetes/Spring Application/etc
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>

[agura]

Nikolay,

as I wrote early in this thread API significantly changed during
IGNITE-11927 implementation so your changes are incompatible with my
changes.

ReadOnlyMetricRegistry will be removed at all (still exists in a
couple of places where it uses).

Also I don't want to introduce IgniteMetric facade in this rush. In
current implementation this interface just provides access to the
ReadOnlyMetricManager instance (which will be removed) but it is not
enough.

I agree with Denis. We should mark current API as experimental and
continue IEP-35 development. See my process proposal [1] described
early this thread. We can release Apache Ignite 2.8.1 specially for
this changes.
Public APIs require deeper thinking in order to provide comprehensive,
consistent and convenient way of metrics management for end users.

Let's add IgniteExperimental, release 2.8 and finish metrics related
issues after it.

[1] http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-tp45146p45185.html


On Wed, Jan 22, 2020 at 5:21 PM Николай Ижиков <[hidden email]> wrote:

>
> Hello, Igniters.
>
> * IGNITE-12552: Move ReadOnlyMetricRegistry to public API merged to the master and cherry-picked to the 2.8.
> So the main issue with the Metric API solved.
>
> * I raised the PR [1] to fix second issue with the new Metric API: absence of the public Java API to get metrics.
> This PR introduces the following changes:
>
> 1. IgniteMetric interface created: it provides Java API to access Ignite metrics created with the new Metric API.
>
> ```
> public interface IgniteMetric extends Iterable<ReadOnlyMetricRegistry> {
>     @Nullable ReadOnlyMetricRegistry registry(String name);
> }
> ```
>
> 2. All deprecation javadocs regarding metrics now reference to the public IgniteMetric instead of internal GridMetricManager:
>
>   > @deprecated Use {@link IgniteMetric} instead.
>
> 3. Tests refactored to use IgniteMetric instead of GridMetricManager when possible.
>
> Please, review.
>
> [1]  https://github.com/apache/ignite/pull/7283
>
> > 21 янв. 2020 г., в 17:51, Николай Ижиков <[hidden email]> написал(а):
> >
> > Hello, Igniters.
> >
> > Alexey approved my PR [1] regarding fixing public API for metric exporters.
> > I’m waiting for a bot visa and merge this PR.
> >
> > As we discussed, the metrics API will be marked with IgniteExperimental annotation.
> >
> > If anyone has any objection to this plan, please provide your feedback.
> >
> > [1] https://github.com/apache/ignite/pull/7269
> >
> >> 21 янв. 2020 г., в 13:45, Николай Ижиков <[hidden email]> написал(а):
> >>
> >> Thanks, for the review Alexey.
> >>
> >> I will fix your comment and  try to implement Monitoring facade, shortly.
> >>
> >>> 21 янв. 2020 г., в 13:32, Alexey Goncharuk <[hidden email]> написал(а):
> >>>
> >>> Nikolay,
> >>>
> >>> I left a single comment in the PR about the histogram metric. I think the
> >>> API looks much cleaner now.
> >>>
> >>> I will take care of the @IgniteExperimental annotation.
> >>>
> >>> пн, 20 янв. 2020 г. в 20:55, Николай Ижиков <[hidden email]>:
> >>>
> >>>> Alexey.
> >>>>
> >>>> PR [1] is waiting for your review.
> >>>> Please, take a look.
> >>>>
> >>>> I think we should do the following before 2.8 release
> >>>>
> >>>> * Introduce new @IgniteExperimental annotation as discussed.
> >>>> * Mark Monitoring API with it.
> >>>> * merge «[IEP-35] Expose MetricRegistry to the public API» to 2.8
> >>>> * merge «[IEP-35] public Java metric API» to 2.8
> >>>>
> >>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>
> >>>>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk <[hidden email]>
> >>>> написал(а):
> >>>>>
> >>>>> Nikolay,
> >>>>>
> >>>>> Should we wait for both of the tickets given that we agreed that we are
> >>>>> putting an experimental marker on the new APIs? I'm ok to fix only the
> >>>>> first one and add the experimental marker so that we do not delay 2.8
> >>>>> release.
> >>>>>
> >>>>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков <[hidden email]>:
> >>>>>
> >>>>>> Andrey.
> >>>>>>
> >>>>>> Let’s move from the long letters to the code.
> >>>>>> If you want to change API - please, propose this changes.
> >>>>>> I think everybody wins if we make our API better.
> >>>>>>
> >>>>>> Please, describe proposed changes.
> >>>>>> It would be great if you have some examples or PR for it.
> >>>>>>
> >>>>>> As for this release, I have plans to contribute tickets
> >>>>>> «[IEP-35] Expose MetricRegistry to the public API» [1] and
> >>>>>> «[IEP-35] public Java metric API» [2] for it.
> >>>>>>
> >>>>>> Any objections on it?
> >>>>>>
> >>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-12553
> >>>>>>
> >>>>>>
> >>>>>>> 20 янв. 2020 г., в 13:08, Andrey Gura <[hidden email]> написал(а):
> >>>>>>>
> >>>>>>> It solves problem.
> >>>>>>>
> >>>>>>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
> >>>>>>> <[hidden email]> wrote:
> >>>>>>>>
> >>>>>>>> After giving it some thought, I agree with Denis - there is nothing
> >>>>>> wrong
> >>>>>>>> with exposing the new APIs, we just need to make it clear that we are
> >>>>>> still
> >>>>>>>> going to change it.
> >>>>>>>>
> >>>>>>>> Should we Introduce something like @IgniteExperimental annotation (I
> >>>>>>>> believe it has been discussed a dozen of times on the dev-list)?
> >>>>>>>>
> >>>>>>>> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov <[hidden email]>:
> >>>>>>>>
> >>>>>>>>> +1 to mark feature or whole release as EA.
> >>>>>>>>>
> >>>>>>>>> пт, 17 янв. 2020 г., 23:00 Denis Magda <[hidden email]>:
> >>>>>>>>>
> >>>>>>>>>> Folks, if you don't mind I'll share some thoughts/suggestions as an
> >>>>>>>>>> observer who was not involved in the feature development.
> >>>>>>>>>>
> >>>>>>>>>> It's absolutely 'ok' to deprecate an API that is replaced with a
> >>>> much
> >>>>>>>>>> better version. However, we should do this only when the new APIs
> >>>> are
> >>>>>>>>>> production-ready. If there are still many limitations or open items
> >>>>>> then
> >>>>>>>>>> don't deprecate anything that exists and release the new APIs
> >>>>>> labeling as
> >>>>>>>>>> early access. What if release the improvements labeling as EA
> >>>> instead
> >>>>>> of
> >>>>>>>>>> hiding them completely?
> >>>>>>>>>>
> >>>>>>>>>> I would also encourage us to put aside emotions, don't blame or
> >>>> point
> >>>>>>>>>> fingers. This IEP is a great initiative and you both have already
> >>>>>> done a
> >>>>>>>>>> tremendous job by developing, architecting and reviewing changes.
> >>>>>> Just be
> >>>>>>>>>> respectful. Nobody is trying to block the feature from being
> >>>> released.
> >>>>>>>>>> Everyone would be glad to tap into improvements and start using them
> >>>>>> in
> >>>>>>>>>> prod. But if more time is needed for the GA let's reiterate a bit.
> >>>>>>>>>>
> >>>>>>>>>> -
> >>>>>>>>>> Denis
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков <
> >>>> [hidden email]>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>>> Also I agree with Alexey about introducing public IgniteMonitoring
> >>>>>>>>>> facade
> >>>>>>>>>>>
> >>>>>>>>>>> This is not an issue with the API.
> >>>>>>>>>>> Just the new feature that doesn’t affects API.
> >>>>>>>>>>> Moreover, I create a ticket to fix it, already.
> >>>>>>>>>>>
> >>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
> >>>>>>>>> then
> >>>>>>>>>>> test will fail. It's just not good tests.
> >>>>>>>>>>>
> >>>>>>>>>>> My changes doesn’t affect any `staticticsEnabled` property.
> >>>>>>>>>>> I don’ understand your point here.
> >>>>>>>>>>>
> >>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> >>>>>>>>>>>
> >>>>>>>>>>> It’s not redundant.
> >>>>>>>>>>> It required for exporters and provide read only access to
> >>>>>>>>> MetricRegistry
> >>>>>>>>>>> existing in the node.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
> >>>>>>>>>>>
> >>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
> >>>> use
> >>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> >>>>>>>>>>>
> >>>>>>>>>>> Why this is issue?
> >>>>>>>>>>>
> >>>>>>>>>>>> Inconsistent MetricRegistry API.
> >>>>>>>>>>>
> >>>>>>>>>>> It’s consistent.
> >>>>>>>>>>>
> >>>>>>>>>>>> Metrics lookups from map instead of using direct reference
> >>>>>>>>>>>> (performance problem).
> >>>>>>>>>>>
> >>>>>>>>>>> 1. We(You and I) did this choice together to simplify creation of
> >>>> the
> >>>>>>>>> new
> >>>>>>>>>>> metrics.
> >>>>>>>>>>> 2. This is not public API issue.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> >>>>>>>>>>>
> >>>>>>>>>>> I don’t ignore this flag.
> >>>>>>>>>>> It just doesn’t exists in new framework(because of scope).
> >>>>>>>>>>> I don’t think it’s an issue.
> >>>>>>>>>>>
> >>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
> >>>>>>>>>> practices.
> >>>>>>>>>>>
> >>>>>>>>>>> Please, clarify your statement.
> >>>>>>>>>>> What is best MBeans practices you are talking about?
> >>>>>>>>>>>
> >>>>>>>>>>>> Not finished IGNITE-11927
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> How this can be API issue?
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> 17 янв. 2020 г., в 20:52, Andrey Gura <[hidden email]>
> >>>>>> написал(а):
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
> >>>>>> PR
> >>>>>>>>>>> [1].
> >>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
> >>>>>>>>> release.
> >>>>>>>>>>>>
> >>>>>>>>>>>> As I mentioned already IGNITE-11927 is part of IEP-35 and
> >>>>>>>>>>>> implementation seriously affects API's. Also I agree with Alexey
> >>>>>>>>> about
> >>>>>>>>>>>> introducing public IgniteMonitoring facade. So thiss PR doesn't
> >>>> fix
> >>>>>>>>>>>> all issues.
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> I talk about ignored existing functionality.
> >>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
> >>>>>>>>>>>>
> >>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
> >>>>>>>>>>>> then test will fail. It's just not good tests.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
> >>>> will
> >>>>>>>>>> fix
> >>>>>>>>>>> it ASAP.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I already fix it all in IGNITE-11927
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>> We should move the product forward and shouldn't hide major
> >>>>>>>>>>> contribution from the user just because your second guess «I don’t
> >>>>>> like
> >>>>>>>>>> the
> >>>>>>>>>>> API I just reviewed and approved».
> >>>>>>>>>>>>
> >>>>>>>>>>>> We should move the product forward with with really finished
> >>>>>>>>> features,
> >>>>>>>>>>>> not pieces of features.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> So I am against this proposal.
> >>>>>>>>>>>>
> >>>>>>>>>>>> It is not argument.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
> >>>> discuss
> >>>>>>>>>> them.
> >>>>>>>>>>>>
> >>>>>>>>>>>> We can prepare it together. But we can't block release.
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> >>>>>>>>>>>>> What is *ALL* problems?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> >>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
> >>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
> >>>> use
> >>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> >>>>>>>>>>>> Inconsistent MetricRegistry API.
> >>>>>>>>>>>> Metrics lookups from map instead of using direct reference
> >>>>>>>>>>>> (performance problem).
> >>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> >>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
> >>>>>>>>>> practices.
> >>>>>>>>>>>> Not finished IGNITE-11927
> >>>>>>>>>>>>
> >>>>>>>>>>>> It's enough I believe.
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:28 PM Николай Ижиков <
> >>>> [hidden email]
> >>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Andrey.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
> >>>> PR
> >>>>>>>>>> [1].
> >>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
> >>>>>>>>> release.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> I talk about ignored existing functionality.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
> >>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
> >>>> will
> >>>>>>>>>> fix
> >>>>>>>>>>> it ASAP.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> We should move the product forward and shouldn't hide major
> >>>>>>>>>>> contribution from the user just because your second guess «I don’t
> >>>>>> like
> >>>>>>>>>> the
> >>>>>>>>>>> API I just reviewed and approved».
> >>>>>>>>>>>>> So I am against this proposal.
> >>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
> >>>> discuss
> >>>>>>>>>> them.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> What is *ALL* problems?
> >>>>>>>>>>>>> Seems, we never be able to solve *ALL* problems.
> >>>>>>>>>>>>> But, we should move the product forward.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> As for your steps [1-6].
> >>>>>>>>>>>>> I’m always following these steps during my contribution.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> 17 янв. 2020 г., в 19:08, Andrey Gura <[hidden email]>
> >>>>>>>>> написал(а):
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The discussion is hot and can be endless. So in separate post I
> >>>>>>>>> want
> >>>>>>>>>>>>>> propose my solution.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>> 2. Create special feature branch B.
> >>>>>>>>>>>>>> 3. In branch B will be merged IGNITE-11927
> >>>>>>>>>>>>>> 4. Because IGNITE-11927 doesn't solve all problems we should
> >>>>>>>>> propose
> >>>>>>>>>>>>>> solution and implement it in branch B.
> >>>>>>>>>>>>>> 5. Testing, usability testing, fixing, etc iteratively.
> >>>>>>>>>>>>>> 6. Merge it to master and in new release branch if needed.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Independent step. There are some problem which should be fixed
> >>>> in
> >>>>>>>>> 2.8
> >>>>>>>>>>>>>> before release otherwise we introduce problems with
> >>>> compatibility
> >>>>>>>>>>>>>> which will haunt us till next major release. I'll create
> >>>> tickets.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:03 PM Andrey Gura <[hidden email]>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
> >>>>>> code.
> >>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> >>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
> >>>>>> major
> >>>>>>>>>>> release.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> We don't know anything about development processes our users. I
> >>>>>>>>> can
> >>>>>>>>>>>>>>> admit that process could require that deprecated methods/APIs
> >>>> are
> >>>>>>>>>> not
> >>>>>>>>>>>>>>> allowed for example.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
> >>>> don't
> >>>>>>>>>> give
> >>>>>>>>>>> me any information about it’s purpose and responsibilities.
> >>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I understand this. But I'm not Ignite user, I'm Ignite
> >>>> developer.
> >>>>>>>>>> The
> >>>>>>>>>>>>>>> key moment in my message *from user stand point*. From my point
> >>>>>> of
> >>>>>>>>>>>>>>> view it is very not intuitive solution and this interface is
> >>>>>>>>>>>>>>> redundant.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
> >>>> example.
> >>>>>>>>>>> There are other entities with such flag.
> >>>>>>>>>>>>>>>> They still works as expected.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Actually not. I fixed many such issues during IGNITE-11927
> >>>>>>>>>>> implementation.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Why do you decided do in such way?
> >>>>>>>>>>>>>>>> Because of the scope.
> >>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
> >>>> other
> >>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I talk not about ability. I talk about ignored existing
> >>>>>>>>>> functionality.
> >>>>>>>>>>>>>>> So scope is not case here.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
> >>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
> >>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
> >>>> exporter
> >>>>>>>>>>> can’t.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Actually list is not metric at all as I already told.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 5:26 PM Николай Ижиков <
> >>>>>>>>> [hidden email]
> >>>>>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Andrey.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
> >>>>>> code.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> >>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
> >>>>>> major
> >>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
> >>>> don't
> >>>>>>>>>> give
> >>>>>>>>>>> me any information about it’s purpose and responsibilities.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Each SPI would have a `ReadOnlyMetricManager` which provides
> >>>>>>>>> access
> >>>>>>>>>>> to collection of `ReadOnlyMetricRegistry`
> >>>>>>>>>>>>>>>> which has a collection of `Metric`.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> So we reflects two-level structure we have in the internal API
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> GridMetricManager -> Collection[MetricRegistry] ->
> >>>>>>>>>> Collection[Metric]
> >>>>>>>>>>>>>>>> ReadOnlyMetricManager -> Collection[ReadOnlyMetricRegistry] ->
> >>>>>>>>>>> Collection[Metric]
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
> >>>> example.
> >>>>>>>>>>> There are other entities with such flag.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> They still works as expected.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Why do you decided do in such way?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Because of the scope.
> >>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
> >>>> other
> >>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
> >>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
> >>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
> >>>> exporter
> >>>>>>>>>>> can’t.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>> https://github.com/apache/ignite/pull/7269/files#diff-0ae5657231fc4c1f650493b02190b81bR25
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 16:57, Andrey Gura <[hidden email]>
> >>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
> >>>>>>>>>> reviewers
> >>>>>>>>>>> of the Metric API.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Yes. But if I'm not missing some thing you were major
> >>>> developer
> >>>>>>>>> of
> >>>>>>>>>>>>>>>>> Metric API :) Shit happens. And it happened.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
> >>>> that
> >>>>>>>>>> are
> >>>>>>>>>>> still supported and don't offer reasonable substitution.
> >>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> There is such concept - backward compatibility. I understand
> >>>>>>>>> that
> >>>>>>>>>>>>>>>>> deprecation of some interface doesn't break backward
> >>>>>>>>> compatibility
> >>>>>>>>>>> but
> >>>>>>>>>>>>>>>>> it leads to question^ what should I use instead of this. And
> >>>>>>>>>>>>>>>>> MetricExporterSpi is not answer for this question. Because it
> >>>>>> is
> >>>>>>>>>>> brand
> >>>>>>>>>>>>>>>>> new API and it requires rewrite client code.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> >>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
> >>>> the
> >>>>>>>>>>> exporters.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> No it is not. It's completely artificial thing which allow
> >>>>>>>>> iterate
> >>>>>>>>>>> via
> >>>>>>>>>>>>>>>>> all metric registries. GridMetricManager implements this
> >>>>>>>>> interface
> >>>>>>>>>>>>>>>>> while it is not metric registry. Form user stand point it is
> >>>>>>>>> very
> >>>>>>>>>>>>>>>>> strange interface which don't give me any information about
> >>>>>> it's
> >>>>>>>>>>>>>>>>> purpose and responsibilities.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> >>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
> >>>> example.
> >>>>>>>>>>> There
> >>>>>>>>>>>>>>>>> are other entities with such flag.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> And that done, intentionally.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Why do you decided do in such way? Why you ignore existing
> >>>>>>>>>>>>>>>>> functionality? It affects user expectations and experience.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Yes? I'm working. Unfortunately we are not synchronized in
> >>>> this
> >>>>>>>>>>>>>>>>> context and I should redo all metrics related changes in
> >>>> order
> >>>>>>>>> to
> >>>>>>>>>>>>>>>>> merge it with my changes. Anyway, my change doesn't solve all
> >>>>>>>>>>> problems
> >>>>>>>>>>>>>>>>> (e.g. it doesn't introduce IgniteMonitoring facade).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Unfortunately it will be just fix. In my solution it is
> >>>>>>>>> redesign.
> >>>>>>>>>>> Stop
> >>>>>>>>>>>>>>>>> fixing issues, let's do things. It requires deeper changes.
> >>>> My
> >>>>>>>>>>> changes
> >>>>>>>>>>>>>>>>> blocks AI 2.8 release because it big enough. So it retargeted
> >>>>>> on
> >>>>>>>>>> the
> >>>>>>>>>>>>>>>>> next release. And it is one more reason for moving the
> >>>> changes
> >>>>>>>>> to
> >>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> internal packages. And it isn't good news for me because I
> >>>> will
> >>>>>>>>> go
> >>>>>>>>>>>>>>>>> throughout pan and tiers of merge. But it is right.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Yes, I know. But they should not be exported by
> >>>>>>>>> MetricExporterSpi
> >>>>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 3:37 PM Николай Ижиков <
> >>>>>>>>>> [hidden email]>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Andrey, thanks for your opinion and your ownest critisism.
> >>>>>>>>>>>>>>>>>> I can’t wait for your contribution.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
> >>>>>>>>>> reviewers
> >>>>>>>>>>> of the Metric API.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
> >>>> that
> >>>>>>>>>> are
> >>>>>>>>>>> still supported and don't offer reasonable substitution.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
> >>>>>>>>>>> MetricExporterSpi's because it are still not-production ready.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It’s ready.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
> >>>> doesn't
> >>>>>>>>>>> solve the problem because this interface exposes internal Metric
> >>>>>>>>>> interface
> >>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Not, its’ not.
> >>>>>>>>>>>>>>>>>> Please, see `org.apache.ignite.spi.metric.LongMetric` and
> >>>>>> other
> >>>>>>>>>>> public interface.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> API of MetricRegistry is inconsistent.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> MetricRegistry is the internal API.
> >>>>>>>>>>>>>>>>>> Feel free to create ticket for an issues with it and I will
> >>>>>> try
> >>>>>>>>>> to
> >>>>>>>>>>> fix it.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
> >>>> the
> >>>>>>>>>>> exporters.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> >>>>>>>>>>>>>>>>>> And that done, intentionally.
> >>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> >>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 15:09, Andrey Gura <[hidden email]>
> >>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
> >>>> that
> >>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
> >>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still not-production
> >>>>>> ready.
> >>>>>>>>>>> There
> >>>>>>>>>>>>>>>>>>> are some issues with it and usage of ReadOnlyMetricRegistry
> >>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>> just one of them.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
> >>>> doesn't
> >>>>>>>>>>> solve
> >>>>>>>>>>>>>>>>>>> the problem because this interface exposes internal Metric
> >>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>> implementations. So your PR is incomplete.
> >>>>>>>>>>>>>>>>>>> Moreover, API of MetricRegistry is inconsistent. E.g.
> >>>>>>>>>>> register(name,
> >>>>>>>>>>>>>>>>>>> supplier, desc) method returns registered metric for some
> >>>>>>>>> types
> >>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>> doesn't for other. register(metric) method is inconsistent
> >>>> in
> >>>>>>>>>>> sense of
> >>>>>>>>>>>>>>>>>>> metric naming. ReadOnlyMetricRegistry interface is
> >>>> redundant.
> >>>>>>>>>>>>>>>>>>> MetricExporterSpi should be revised because it absolutely
> >>>> not
> >>>>>>>>>>>>>>>>>>> intuitive because it requires ReadOnlyMetricRegistry and
> >>>> it's
> >>>>>>>>>>> purpose
> >>>>>>>>>>>>>>>>>>> is undefined.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> One more point. IEP-35 is still not fully implemented. Some
> >>>>>>>>>>> things are
> >>>>>>>>>>>>>>>>>>> not taken into account. Exporters expose metrics if they
> >>>> are
> >>>>>>>>>>> disabled.
> >>>>>>>>>>>>>>>>>>> JMX beans exposes values that don't confirm to best
> >>>> practices
> >>>>>>>>>> [1].
> >>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all. Ubiquitous
> >>>>>> merics
> >>>>>>>>>>> lookup
> >>>>>>>>>>>>>>>>>>> from hash map instead of usage reference for getting
> >>>> metrics
> >>>>>>>>>>> values
> >>>>>>>>>>>>>>>>>>> (it is just performance issue). Also IGNITE-11927 is not
> >>>>>>>>>>> implemented
> >>>>>>>>>>>>>>>>>>> which also changes interfaces significantly.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Let's just admit that the implementation is immature and
> >>>> must
> >>>>>>>>> be
> >>>>>>>>>>> moved
> >>>>>>>>>>>>>>>>>>> to the internal packages.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> And because we already merged partially implemented IEP to
> >>>>>> the
> >>>>>>>>>>> master
> >>>>>>>>>>>>>>>>>>> branch we *must move all currently public APIs to the
> >>>>>> internal
> >>>>>>>>>>> API*
> >>>>>>>>>>>>>>>>>>> while it will not be ready for publication.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> And the last but not least. What is happening indicates a
> >>>>>>>>>> immature
> >>>>>>>>>>>>>>>>>>> development process which must be revised. I don't want
> >>>>>>>>> discuss
> >>>>>>>>>>> it in
> >>>>>>>>>>>>>>>>>>> this thread but we must not allow merge of change to the
> >>>>>>>>> master
> >>>>>>>>>>> branch
> >>>>>>>>>>>>>>>>>>> before it will completed, that is we must use feature
> >>>>>> branches
> >>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>> full IEP not only for particular tickets. And also we
> >>>> should
> >>>>>>>>>>>>>>>>>>> reformulate IEP process in order to avoid things like this.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>> https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:49 PM Николай Ижиков <
> >>>>>>>>>>> [hidden email]> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Alex.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> OK, I may leverage your experience and create pure Java
> >>>> API.
> >>>>>>>>>>>>>>>>>>>> Ticket [1] created.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> But, personally, I don’t agree with you.
> >>>>>>>>>>>>>>>>>>>> Ignite has dozens of the API that theoretically have a
> >>>> usage
> >>>>>>>>>>> scenario, but in real-world have 0 custom implementation and
> >>>> usages.
> >>>>>>>>>>>>>>>>>>>> Moreover, many APIs that were created with the intentions
> >>>>>> you
> >>>>>>>>>>> mentioned is abandoned now and confuses users.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> You can just see count of the tests we just mute on the
> >>>> TC.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Can you, please, take a look at the fix regarding puck API
> >>>>>>>>>> issue
> >>>>>>>>>>> you mentioned in your first letter [2], [3]
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-12553
> >>>>>>>>>>>>>>>>>>>> [2] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/IGNITE-12552
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 12:12, Alexey Goncharuk <
> >>>>>>>>>>> [hidden email]> написал(а):
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Nikolay,
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Why do you think this is a wrong usage pattern? From the
> >>>>>> top
> >>>>>>>>>> of
> >>>>>>>>>>> my head,
> >>>>>>>>>>>>>>>>>>>>> here is a few cases of direct metric API usage that I
> >>>> know
> >>>>>>>>> are
> >>>>>>>>>>> currently
> >>>>>>>>>>>>>>>>>>>>> being used in production:
> >>>>>>>>>>>>>>>>>>>>> * A custom task execution scheduling service with load
> >>>>>>>>>>> balancing based on
> >>>>>>>>>>>>>>>>>>>>> utilization metrics readings from Java code
> >>>>>>>>>>>>>>>>>>>>> * Cleanup task trigger based on metrics readings
> >>>>>>>>>>>>>>>>>>>>> * A custom health-check endpoint for an application with
> >>>> an
> >>>>>>>>>>> embedded
> >>>>>>>>>>>>>>>>>>>>> Ignite node for Kubernetes/Spring Application/etc
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >
>

[Nikolay Izhikov-2]

Andrey.

> IGNITE-11927 implementation so your changes are incompatible with my changes

We don’t discuss your changes and your proposals for the Metric API.
So I don’t think we can make the existence of some PR is an argument to introduce(or not introduce) this facade.
Moreover, As far as I know, you developing changes for the Metric API for 5 months without public discussion, for now. Let's start it.

Let’s do the following:

1. Review `IgniteMetric` facade and introduce it to the users as an experimental API.

2. Discuss your proposal to the Metric API in the separate thread you are referencing.

I think we should start a discussion from the simplified explanation of:

1. API intentions - What we want to gain with it? What is our focus?
2. Simple, minimal example of API main interfaces and desired usages.

This will help to the community and me personally better understand your idea and share feedback.

Thanks.

> 23 янв. 2020 г., в 17:15, Andrey Gura <[hidden email]> написал(а):
>
> Nikolay,
>
> as I wrote early in this thread API significantly changed during
> IGNITE-11927 implementation so your changes are incompatible with my
> changes.
>
> ReadOnlyMetricRegistry will be removed at all (still exists in a
> couple of places where it uses).
>
> Also I don't want to introduce IgniteMetric facade in this rush. In
> current implementation this interface just provides access to the
> ReadOnlyMetricManager instance (which will be removed) but it is not
> enough.
>
> I agree with Denis. We should mark current API as experimental and
> continue IEP-35 development. See my process proposal [1] described
> early this thread. We can release Apache Ignite 2.8.1 specially for
> this changes.
> Public APIs require deeper thinking in order to provide comprehensive,
> consistent and convenient way of metrics management for end users.
>
> Let's add IgniteExperimental, release 2.8 and finish metrics related
> issues after it.
>
> [1] http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-tp45146p45185.html
>
>
> On Wed, Jan 22, 2020 at 5:21 PM Николай Ижиков <[hidden email]> wrote:
>>
>> Hello, Igniters.
>>
>> * IGNITE-12552: Move ReadOnlyMetricRegistry to public API merged to the master and cherry-picked to the 2.8.
>> So the main issue with the Metric API solved.
>>
>> * I raised the PR [1] to fix second issue with the new Metric API: absence of the public Java API to get metrics.
>> This PR introduces the following changes:
>>
>> 1. IgniteMetric interface created: it provides Java API to access Ignite metrics created with the new Metric API.
>>
>> ```
>> public interface IgniteMetric extends Iterable<ReadOnlyMetricRegistry> {
>>    @Nullable ReadOnlyMetricRegistry registry(String name);
>> }
>> ```
>>
>> 2. All deprecation javadocs regarding metrics now reference to the public IgniteMetric instead of internal GridMetricManager:
>>
>>> @deprecated Use {@link IgniteMetric} instead.
>>
>> 3. Tests refactored to use IgniteMetric instead of GridMetricManager when possible.
>>
>> Please, review.
>>
>> [1]  https://github.com/apache/ignite/pull/7283
>>
>>> 21 янв. 2020 г., в 17:51, Николай Ижиков <[hidden email]> написал(а):
>>>
>>> Hello, Igniters.
>>>
>>> Alexey approved my PR [1] regarding fixing public API for metric exporters.
>>> I’m waiting for a bot visa and merge this PR.
>>>
>>> As we discussed, the metrics API will be marked with IgniteExperimental annotation.
>>>
>>> If anyone has any objection to this plan, please provide your feedback.
>>>
>>> [1] https://github.com/apache/ignite/pull/7269
>>>
>>>> 21 янв. 2020 г., в 13:45, Николай Ижиков <[hidden email]> написал(а):
>>>>
>>>> Thanks, for the review Alexey.
>>>>
>>>> I will fix your comment and  try to implement Monitoring facade, shortly.
>>>>
>>>>> 21 янв. 2020 г., в 13:32, Alexey Goncharuk <[hidden email]> написал(а):
>>>>>
>>>>> Nikolay,
>>>>>
>>>>> I left a single comment in the PR about the histogram metric. I think the
>>>>> API looks much cleaner now.
>>>>>
>>>>> I will take care of the @IgniteExperimental annotation.
>>>>>
>>>>> пн, 20 янв. 2020 г. в 20:55, Николай Ижиков <[hidden email]>:
>>>>>
>>>>>> Alexey.
>>>>>>
>>>>>> PR [1] is waiting for your review.
>>>>>> Please, take a look.
>>>>>>
>>>>>> I think we should do the following before 2.8 release
>>>>>>
>>>>>> * Introduce new @IgniteExperimental annotation as discussed.
>>>>>> * Mark Monitoring API with it.
>>>>>> * merge «[IEP-35] Expose MetricRegistry to the public API» to 2.8
>>>>>> * merge «[IEP-35] public Java metric API» to 2.8
>>>>>>
>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>
>>>>>>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk <[hidden email]>
>>>>>> написал(а):
>>>>>>>
>>>>>>> Nikolay,
>>>>>>>
>>>>>>> Should we wait for both of the tickets given that we agreed that we are
>>>>>>> putting an experimental marker on the new APIs? I'm ok to fix only the
>>>>>>> first one and add the experimental marker so that we do not delay 2.8
>>>>>>> release.
>>>>>>>
>>>>>>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков <[hidden email]>:
>>>>>>>
>>>>>>>> Andrey.
>>>>>>>>
>>>>>>>> Let’s move from the long letters to the code.
>>>>>>>> If you want to change API - please, propose this changes.
>>>>>>>> I think everybody wins if we make our API better.
>>>>>>>>
>>>>>>>> Please, describe proposed changes.
>>>>>>>> It would be great if you have some examples or PR for it.
>>>>>>>>
>>>>>>>> As for this release, I have plans to contribute tickets
>>>>>>>> «[IEP-35] Expose MetricRegistry to the public API» [1] and
>>>>>>>> «[IEP-35] public Java metric API» [2] for it.
>>>>>>>>
>>>>>>>> Any objections on it?
>>>>>>>>
>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-12553
>>>>>>>>
>>>>>>>>
>>>>>>>>> 20 янв. 2020 г., в 13:08, Andrey Gura <[hidden email]> написал(а):
>>>>>>>>>
>>>>>>>>> It solves problem.
>>>>>>>>>
>>>>>>>>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
>>>>>>>>> <[hidden email]> wrote:
>>>>>>>>>>
>>>>>>>>>> After giving it some thought, I agree with Denis - there is nothing
>>>>>>>> wrong
>>>>>>>>>> with exposing the new APIs, we just need to make it clear that we are
>>>>>>>> still
>>>>>>>>>> going to change it.
>>>>>>>>>>
>>>>>>>>>> Should we Introduce something like @IgniteExperimental annotation (I
>>>>>>>>>> believe it has been discussed a dozen of times on the dev-list)?
>>>>>>>>>>
>>>>>>>>>> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov <[hidden email]>:
>>>>>>>>>>
>>>>>>>>>>> +1 to mark feature or whole release as EA.
>>>>>>>>>>>
>>>>>>>>>>> пт, 17 янв. 2020 г., 23:00 Denis Magda <[hidden email]>:
>>>>>>>>>>>
>>>>>>>>>>>> Folks, if you don't mind I'll share some thoughts/suggestions as an
>>>>>>>>>>>> observer who was not involved in the feature development.
>>>>>>>>>>>>
>>>>>>>>>>>> It's absolutely 'ok' to deprecate an API that is replaced with a
>>>>>> much
>>>>>>>>>>>> better version. However, we should do this only when the new APIs
>>>>>> are
>>>>>>>>>>>> production-ready. If there are still many limitations or open items
>>>>>>>> then
>>>>>>>>>>>> don't deprecate anything that exists and release the new APIs
>>>>>>>> labeling as
>>>>>>>>>>>> early access. What if release the improvements labeling as EA
>>>>>> instead
>>>>>>>> of
>>>>>>>>>>>> hiding them completely?
>>>>>>>>>>>>
>>>>>>>>>>>> I would also encourage us to put aside emotions, don't blame or
>>>>>> point
>>>>>>>>>>>> fingers. This IEP is a great initiative and you both have already
>>>>>>>> done a
>>>>>>>>>>>> tremendous job by developing, architecting and reviewing changes.
>>>>>>>> Just be
>>>>>>>>>>>> respectful. Nobody is trying to block the feature from being
>>>>>> released.
>>>>>>>>>>>> Everyone would be glad to tap into improvements and start using them
>>>>>>>> in
>>>>>>>>>>>> prod. But if more time is needed for the GA let's reiterate a bit.
>>>>>>>>>>>>
>>>>>>>>>>>> -
>>>>>>>>>>>> Denis
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков <
>>>>>> [hidden email]>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> Also I agree with Alexey about introducing public IgniteMonitoring
>>>>>>>>>>>> facade
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is not an issue with the API.
>>>>>>>>>>>>> Just the new feature that doesn’t affects API.
>>>>>>>>>>>>> Moreover, I create a ticket to fix it, already.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
>>>>>>>>>>> then
>>>>>>>>>>>>> test will fail. It's just not good tests.
>>>>>>>>>>>>>
>>>>>>>>>>>>> My changes doesn’t affect any `staticticsEnabled` property.
>>>>>>>>>>>>> I don’ understand your point here.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It’s not redundant.
>>>>>>>>>>>>> It required for exporters and provide read only access to
>>>>>>>>>>> MetricRegistry
>>>>>>>>>>>>> existing in the node.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
>>>>>> use
>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why this is issue?
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It’s consistent.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Metrics lookups from map instead of using direct reference
>>>>>>>>>>>>>> (performance problem).
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. We(You and I) did this choice together to simplify creation of
>>>>>> the
>>>>>>>>>>> new
>>>>>>>>>>>>> metrics.
>>>>>>>>>>>>> 2. This is not public API issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don’t ignore this flag.
>>>>>>>>>>>>> It just doesn’t exists in new framework(because of scope).
>>>>>>>>>>>>> I don’t think it’s an issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
>>>>>>>>>>>> practices.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please, clarify your statement.
>>>>>>>>>>>>> What is best MBeans practices you are talking about?
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not finished IGNITE-11927
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> How this can be API issue?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 17 янв. 2020 г., в 20:52, Andrey Gura <[hidden email]>
>>>>>>>> написал(а):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
>>>>>>>> PR
>>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
>>>>>>>>>>> release.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As I mentioned already IGNITE-11927 is part of IEP-35 and
>>>>>>>>>>>>>> implementation seriously affects API's. Also I agree with Alexey
>>>>>>>>>>> about
>>>>>>>>>>>>>> introducing public IgniteMonitoring facade. So thiss PR doesn't
>>>>>> fix
>>>>>>>>>>>>>> all issues.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
>>>>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
>>>>>>>>>>>>>> then test will fail. It's just not good tests.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
>>>>>> will
>>>>>>>>>>>> fix
>>>>>>>>>>>>> it ASAP.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I already fix it all in IGNITE-11927
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>>> We should move the product forward and shouldn't hide major
>>>>>>>>>>>>> contribution from the user just because your second guess «I don’t
>>>>>>>> like
>>>>>>>>>>>> the
>>>>>>>>>>>>> API I just reviewed and approved».
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We should move the product forward with with really finished
>>>>>>>>>>> features,
>>>>>>>>>>>>>> not pieces of features.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So I am against this proposal.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is not argument.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
>>>>>> discuss
>>>>>>>>>>>> them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We can prepare it together. But we can't block release.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
>>>>>>>>>>>>>>> What is *ALL* problems?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
>>>>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
>>>>>> use
>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
>>>>>>>>>>>>>> Metrics lookups from map instead of using direct reference
>>>>>>>>>>>>>> (performance problem).
>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
>>>>>>>>>>>> practices.
>>>>>>>>>>>>>> Not finished IGNITE-11927
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It's enough I believe.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:28 PM Николай Ижиков <
>>>>>> [hidden email]
>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Andrey.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
>>>>>> PR
>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
>>>>>>>>>>> release.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
>>>>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
>>>>>> will
>>>>>>>>>>>> fix
>>>>>>>>>>>>> it ASAP.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We should move the product forward and shouldn't hide major
>>>>>>>>>>>>> contribution from the user just because your second guess «I don’t
>>>>>>>> like
>>>>>>>>>>>> the
>>>>>>>>>>>>> API I just reviewed and approved».
>>>>>>>>>>>>>>> So I am against this proposal.
>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
>>>>>> discuss
>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What is *ALL* problems?
>>>>>>>>>>>>>>> Seems, we never be able to solve *ALL* problems.
>>>>>>>>>>>>>>> But, we should move the product forward.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As for your steps [1-6].
>>>>>>>>>>>>>>> I’m always following these steps during my contribution.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 19:08, Andrey Gura <[hidden email]>
>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The discussion is hot and can be endless. So in separate post I
>>>>>>>>>>> want
>>>>>>>>>>>>>>>> propose my solution.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>>>> 2. Create special feature branch B.
>>>>>>>>>>>>>>>> 3. In branch B will be merged IGNITE-11927
>>>>>>>>>>>>>>>> 4. Because IGNITE-11927 doesn't solve all problems we should
>>>>>>>>>>> propose
>>>>>>>>>>>>>>>> solution and implement it in branch B.
>>>>>>>>>>>>>>>> 5. Testing, usability testing, fixing, etc iteratively.
>>>>>>>>>>>>>>>> 6. Merge it to master and in new release branch if needed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Independent step. There are some problem which should be fixed
>>>>>> in
>>>>>>>>>>> 2.8
>>>>>>>>>>>>>>>> before release otherwise we introduce problems with
>>>>>> compatibility
>>>>>>>>>>>>>>>> which will haunt us till next major release. I'll create
>>>>>> tickets.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:03 PM Andrey Gura <[hidden email]>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
>>>>>>>> code.
>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
>>>>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
>>>>>>>> major
>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We don't know anything about development processes our users. I
>>>>>>>>>>> can
>>>>>>>>>>>>>>>>> admit that process could require that deprecated methods/APIs
>>>>>> are
>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> allowed for example.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
>>>>>> don't
>>>>>>>>>>>> give
>>>>>>>>>>>>> me any information about it’s purpose and responsibilities.
>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I understand this. But I'm not Ignite user, I'm Ignite
>>>>>> developer.
>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>> key moment in my message *from user stand point*. From my point
>>>>>>>> of
>>>>>>>>>>>>>>>>> view it is very not intuitive solution and this interface is
>>>>>>>>>>>>>>>>> redundant.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
>>>>>> example.
>>>>>>>>>>>>> There are other entities with such flag.
>>>>>>>>>>>>>>>>>> They still works as expected.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Actually not. I fixed many such issues during IGNITE-11927
>>>>>>>>>>>>> implementation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
>>>>>>>>>>>>>>>>>> Because of the scope.
>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
>>>>>> other
>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I talk not about ability. I talk about ignored existing
>>>>>>>>>>>> functionality.
>>>>>>>>>>>>>>>>> So scope is not case here.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
>>>>>> exporter
>>>>>>>>>>>>> can’t.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Actually list is not metric at all as I already told.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 5:26 PM Николай Ижиков <
>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Andrey.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
>>>>>>>> code.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
>>>>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
>>>>>>>> major
>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
>>>>>> don't
>>>>>>>>>>>> give
>>>>>>>>>>>>> me any information about it’s purpose and responsibilities.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Each SPI would have a `ReadOnlyMetricManager` which provides
>>>>>>>>>>> access
>>>>>>>>>>>>> to collection of `ReadOnlyMetricRegistry`
>>>>>>>>>>>>>>>>>> which has a collection of `Metric`.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So we reflects two-level structure we have in the internal API
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> GridMetricManager -> Collection[MetricRegistry] ->
>>>>>>>>>>>> Collection[Metric]
>>>>>>>>>>>>>>>>>> ReadOnlyMetricManager -> Collection[ReadOnlyMetricRegistry] ->
>>>>>>>>>>>>> Collection[Metric]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
>>>>>> example.
>>>>>>>>>>>>> There are other entities with such flag.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> They still works as expected.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Because of the scope.
>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
>>>>>> other
>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
>>>>>> exporter
>>>>>>>>>>>>> can’t.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>> https://github.com/apache/ignite/pull/7269/files#diff-0ae5657231fc4c1f650493b02190b81bR25
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 16:57, Andrey Gura <[hidden email]>
>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
>>>>>>>>>>>> reviewers
>>>>>>>>>>>>> of the Metric API.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yes. But if I'm not missing some thing you were major
>>>>>> developer
>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>> Metric API :) Shit happens. And it happened.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
>>>>>> that
>>>>>>>>>>>> are
>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> There is such concept - backward compatibility. I understand
>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> deprecation of some interface doesn't break backward
>>>>>>>>>>> compatibility
>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>> it leads to question^ what should I use instead of this. And
>>>>>>>>>>>>>>>>>>> MetricExporterSpi is not answer for this question. Because it
>>>>>>>> is
>>>>>>>>>>>>> brand
>>>>>>>>>>>>>>>>>>> new API and it requires rewrite client code.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
>>>>>> the
>>>>>>>>>>>>> exporters.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No it is not. It's completely artificial thing which allow
>>>>>>>>>>> iterate
>>>>>>>>>>>>> via
>>>>>>>>>>>>>>>>>>> all metric registries. GridMetricManager implements this
>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>> while it is not metric registry. Form user stand point it is
>>>>>>>>>>> very
>>>>>>>>>>>>>>>>>>> strange interface which don't give me any information about
>>>>>>>> it's
>>>>>>>>>>>>>>>>>>> purpose and responsibilities.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
>>>>>> example.
>>>>>>>>>>>>> There
>>>>>>>>>>>>>>>>>>> are other entities with such flag.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Why do you decided do in such way? Why you ignore existing
>>>>>>>>>>>>>>>>>>> functionality? It affects user expectations and experience.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yes? I'm working. Unfortunately we are not synchronized in
>>>>>> this
>>>>>>>>>>>>>>>>>>> context and I should redo all metrics related changes in
>>>>>> order
>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> merge it with my changes. Anyway, my change doesn't solve all
>>>>>>>>>>>>> problems
>>>>>>>>>>>>>>>>>>> (e.g. it doesn't introduce IgniteMonitoring facade).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Unfortunately it will be just fix. In my solution it is
>>>>>>>>>>> redesign.
>>>>>>>>>>>>> Stop
>>>>>>>>>>>>>>>>>>> fixing issues, let's do things. It requires deeper changes.
>>>>>> My
>>>>>>>>>>>>> changes
>>>>>>>>>>>>>>>>>>> blocks AI 2.8 release because it big enough. So it retargeted
>>>>>>>> on
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> next release. And it is one more reason for moving the
>>>>>> changes
>>>>>>>>>>> to
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> internal packages. And it isn't good news for me because I
>>>>>> will
>>>>>>>>>>> go
>>>>>>>>>>>>>>>>>>> throughout pan and tiers of merge. But it is right.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yes, I know. But they should not be exported by
>>>>>>>>>>> MetricExporterSpi
>>>>>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 3:37 PM Николай Ижиков <
>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Andrey, thanks for your opinion and your ownest critisism.
>>>>>>>>>>>>>>>>>>>> I can’t wait for your contribution.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
>>>>>>>>>>>> reviewers
>>>>>>>>>>>>> of the Metric API.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
>>>>>> that
>>>>>>>>>>>> are
>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
>>>>>>>>>>>>> MetricExporterSpi's because it are still not-production ready.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It’s ready.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
>>>>>> doesn't
>>>>>>>>>>>>> solve the problem because this interface exposes internal Metric
>>>>>>>>>>>> interface
>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Not, its’ not.
>>>>>>>>>>>>>>>>>>>> Please, see `org.apache.ignite.spi.metric.LongMetric` and
>>>>>>>> other
>>>>>>>>>>>>> public interface.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> API of MetricRegistry is inconsistent.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> MetricRegistry is the internal API.
>>>>>>>>>>>>>>>>>>>> Feel free to create ticket for an issues with it and I will
>>>>>>>> try
>>>>>>>>>>>> to
>>>>>>>>>>>>> fix it.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
>>>>>> the
>>>>>>>>>>>>> exporters.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 15:09, Andrey Gura <[hidden email]>
>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
>>>>>> that
>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still not-production
>>>>>>>> ready.
>>>>>>>>>>>>> There
>>>>>>>>>>>>>>>>>>>>> are some issues with it and usage of ReadOnlyMetricRegistry
>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>> just one of them.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
>>>>>> doesn't
>>>>>>>>>>>>> solve
>>>>>>>>>>>>>>>>>>>>> the problem because this interface exposes internal Metric
>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>> implementations. So your PR is incomplete.
>>>>>>>>>>>>>>>>>>>>> Moreover, API of MetricRegistry is inconsistent. E.g.
>>>>>>>>>>>>> register(name,
>>>>>>>>>>>>>>>>>>>>> supplier, desc) method returns registered metric for some
>>>>>>>>>>> types
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> doesn't for other. register(metric) method is inconsistent
>>>>>> in
>>>>>>>>>>>>> sense of
>>>>>>>>>>>>>>>>>>>>> metric naming. ReadOnlyMetricRegistry interface is
>>>>>> redundant.
>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi should be revised because it absolutely
>>>>>> not
>>>>>>>>>>>>>>>>>>>>> intuitive because it requires ReadOnlyMetricRegistry and
>>>>>> it's
>>>>>>>>>>>>> purpose
>>>>>>>>>>>>>>>>>>>>> is undefined.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> One more point. IEP-35 is still not fully implemented. Some
>>>>>>>>>>>>> things are
>>>>>>>>>>>>>>>>>>>>> not taken into account. Exporters expose metrics if they
>>>>>> are
>>>>>>>>>>>>> disabled.
>>>>>>>>>>>>>>>>>>>>> JMX beans exposes values that don't confirm to best
>>>>>> practices
>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all. Ubiquitous
>>>>>>>> merics
>>>>>>>>>>>>> lookup
>>>>>>>>>>>>>>>>>>>>> from hash map instead of usage reference for getting
>>>>>> metrics
>>>>>>>>>>>>> values
>>>>>>>>>>>>>>>>>>>>> (it is just performance issue). Also IGNITE-11927 is not
>>>>>>>>>>>>> implemented
>>>>>>>>>>>>>>>>>>>>> which also changes interfaces significantly.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Let's just admit that the implementation is immature and
>>>>>> must
>>>>>>>>>>> be
>>>>>>>>>>>>> moved
>>>>>>>>>>>>>>>>>>>>> to the internal packages.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> And because we already merged partially implemented IEP to
>>>>>>>> the
>>>>>>>>>>>>> master
>>>>>>>>>>>>>>>>>>>>> branch we *must move all currently public APIs to the
>>>>>>>> internal
>>>>>>>>>>>>> API*
>>>>>>>>>>>>>>>>>>>>> while it will not be ready for publication.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> And the last but not least. What is happening indicates a
>>>>>>>>>>>> immature
>>>>>>>>>>>>>>>>>>>>> development process which must be revised. I don't want
>>>>>>>>>>> discuss
>>>>>>>>>>>>> it in
>>>>>>>>>>>>>>>>>>>>> this thread but we must not allow merge of change to the
>>>>>>>>>>> master
>>>>>>>>>>>>> branch
>>>>>>>>>>>>>>>>>>>>> before it will completed, that is we must use feature
>>>>>>>> branches
>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>> full IEP not only for particular tickets. And also we
>>>>>> should
>>>>>>>>>>>>>>>>>>>>> reformulate IEP process in order to avoid things like this.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>> https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:49 PM Николай Ижиков <
>>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Alex.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> OK, I may leverage your experience and create pure Java
>>>>>> API.
>>>>>>>>>>>>>>>>>>>>>> Ticket [1] created.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> But, personally, I don’t agree with you.
>>>>>>>>>>>>>>>>>>>>>> Ignite has dozens of the API that theoretically have a
>>>>>> usage
>>>>>>>>>>>>> scenario, but in real-world have 0 custom implementation and
>>>>>> usages.
>>>>>>>>>>>>>>>>>>>>>> Moreover, many APIs that were created with the intentions
>>>>>>>> you
>>>>>>>>>>>>> mentioned is abandoned now and confuses users.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You can just see count of the tests we just mute on the
>>>>>> TC.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Can you, please, take a look at the fix regarding puck API
>>>>>>>>>>>> issue
>>>>>>>>>>>>> you mentioned in your first letter [2], [3]
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-12553
>>>>>>>>>>>>>>>>>>>>>> [2] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/IGNITE-12552
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 12:12, Alexey Goncharuk <
>>>>>>>>>>>>> [hidden email]> написал(а):
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Nikolay,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Why do you think this is a wrong usage pattern? From the
>>>>>>>> top
>>>>>>>>>>>> of
>>>>>>>>>>>>> my head,
>>>>>>>>>>>>>>>>>>>>>>> here is a few cases of direct metric API usage that I
>>>>>> know
>>>>>>>>>>> are
>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>>>>>> being used in production:
>>>>>>>>>>>>>>>>>>>>>>> * A custom task execution scheduling service with load
>>>>>>>>>>>>> balancing based on
>>>>>>>>>>>>>>>>>>>>>>> utilization metrics readings from Java code
>>>>>>>>>>>>>>>>>>>>>>> * Cleanup task trigger based on metrics readings
>>>>>>>>>>>>>>>>>>>>>>> * A custom health-check endpoint for an application with
>>>>>> an
>>>>>>>>>>>>> embedded
>>>>>>>>>>>>>>>>>>>>>>> Ignite node for Kubernetes/Spring Application/etc
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>

[agura]

> We don’t discuss your changes and your proposals for the Metric API.

You want say didn't discuss? Actually we did it [1] but you told ok
let's see code :)

> So I don’t think we can make the existence of some PR is an argument to introduce(or not introduce) this facade.

You definitely right in case of competition development. But I think
that collaborative development is more effective. Isn't it?

> Moreover, As far as I know, you developing changes for the Metric API for 5 months without public discussion, for now. Let's start it.

Firsty, with discussion. See above.
Secondly, yes it took a lot of time due to a lot of changes. Is it problem?

> Let’s do the following:
> 1. Review `IgniteMetric` facade and introduce it to the users as an experimental API.

It just doesn't make sense. Just commit for commit.

> 2. Discuss your proposal to the Metric API in the separate thread you are referencing.

You a re welcome to thread [1] again. But please, take into account.
because discussion is postponed by you it's late enough to discuss
proposed solution. But of course I'll answer on your questions and
will be glade to your comments and suggestions.

> I think we should start a discussion from the simplified explanation of:
> 1. API intentions - What we want to gain with it? What is our focus?
> 2. Simple, minimal example of API main interfaces and desired usages.

All this already described at [1]. You also can take a look on PR (see
MetricSource implementations, there are complex and simple ones).

[1] http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Metrics-management-in-Ignite-tp43243.html

On Thu, Jan 23, 2020 at 5:42 PM Николай Ижиков <[hidden email]> wrote:

>
> Andrey.
>
> > IGNITE-11927 implementation so your changes are incompatible with my changes
>
> We don’t discuss your changes and your proposals for the Metric API.
> So I don’t think we can make the existence of some PR is an argument to introduce(or not introduce) this facade.
> Moreover, As far as I know, you developing changes for the Metric API for 5 months without public discussion, for now. Let's start it.
>
> Let’s do the following:
>
> 1. Review `IgniteMetric` facade and introduce it to the users as an experimental API.
>
> 2. Discuss your proposal to the Metric API in the separate thread you are referencing.
>
> I think we should start a discussion from the simplified explanation of:
>
> 1. API intentions - What we want to gain with it? What is our focus?
> 2. Simple, minimal example of API main interfaces and desired usages.
>
> This will help to the community and me personally better understand your idea and share feedback.
>
> Thanks.
>
> > 23 янв. 2020 г., в 17:15, Andrey Gura <[hidden email]> написал(а):
> >
> > Nikolay,
> >
> > as I wrote early in this thread API significantly changed during
> > IGNITE-11927 implementation so your changes are incompatible with my
> > changes.
> >
> > ReadOnlyMetricRegistry will be removed at all (still exists in a
> > couple of places where it uses).
> >
> > Also I don't want to introduce IgniteMetric facade in this rush. In
> > current implementation this interface just provides access to the
> > ReadOnlyMetricManager instance (which will be removed) but it is not
> > enough.
> >
> > I agree with Denis. We should mark current API as experimental and
> > continue IEP-35 development. See my process proposal [1] described
> > early this thread. We can release Apache Ignite 2.8.1 specially for
> > this changes.
> > Public APIs require deeper thinking in order to provide comprehensive,
> > consistent and convenient way of metrics management for end users.
> >
> > Let's add IgniteExperimental, release 2.8 and finish metrics related
> > issues after it.
> >
> > [1] http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-tp45146p45185.html
> >
> >
> > On Wed, Jan 22, 2020 at 5:21 PM Николай Ижиков <[hidden email]> wrote:
> >>
> >> Hello, Igniters.
> >>
> >> * IGNITE-12552: Move ReadOnlyMetricRegistry to public API merged to the master and cherry-picked to the 2.8.
> >> So the main issue with the Metric API solved.
> >>
> >> * I raised the PR [1] to fix second issue with the new Metric API: absence of the public Java API to get metrics.
> >> This PR introduces the following changes:
> >>
> >> 1. IgniteMetric interface created: it provides Java API to access Ignite metrics created with the new Metric API.
> >>
> >> ```
> >> public interface IgniteMetric extends Iterable<ReadOnlyMetricRegistry> {
> >>    @Nullable ReadOnlyMetricRegistry registry(String name);
> >> }
> >> ```
> >>
> >> 2. All deprecation javadocs regarding metrics now reference to the public IgniteMetric instead of internal GridMetricManager:
> >>
> >>> @deprecated Use {@link IgniteMetric} instead.
> >>
> >> 3. Tests refactored to use IgniteMetric instead of GridMetricManager when possible.
> >>
> >> Please, review.
> >>
> >> [1]  https://github.com/apache/ignite/pull/7283
> >>
> >>> 21 янв. 2020 г., в 17:51, Николай Ижиков <[hidden email]> написал(а):
> >>>
> >>> Hello, Igniters.
> >>>
> >>> Alexey approved my PR [1] regarding fixing public API for metric exporters.
> >>> I’m waiting for a bot visa and merge this PR.
> >>>
> >>> As we discussed, the metrics API will be marked with IgniteExperimental annotation.
> >>>
> >>> If anyone has any objection to this plan, please provide your feedback.
> >>>
> >>> [1] https://github.com/apache/ignite/pull/7269
> >>>
> >>>> 21 янв. 2020 г., в 13:45, Николай Ижиков <[hidden email]> написал(а):
> >>>>
> >>>> Thanks, for the review Alexey.
> >>>>
> >>>> I will fix your comment and  try to implement Monitoring facade, shortly.
> >>>>
> >>>>> 21 янв. 2020 г., в 13:32, Alexey Goncharuk <[hidden email]> написал(а):
> >>>>>
> >>>>> Nikolay,
> >>>>>
> >>>>> I left a single comment in the PR about the histogram metric. I think the
> >>>>> API looks much cleaner now.
> >>>>>
> >>>>> I will take care of the @IgniteExperimental annotation.
> >>>>>
> >>>>> пн, 20 янв. 2020 г. в 20:55, Николай Ижиков <[hidden email]>:
> >>>>>
> >>>>>> Alexey.
> >>>>>>
> >>>>>> PR [1] is waiting for your review.
> >>>>>> Please, take a look.
> >>>>>>
> >>>>>> I think we should do the following before 2.8 release
> >>>>>>
> >>>>>> * Introduce new @IgniteExperimental annotation as discussed.
> >>>>>> * Mark Monitoring API with it.
> >>>>>> * merge «[IEP-35] Expose MetricRegistry to the public API» to 2.8
> >>>>>> * merge «[IEP-35] public Java metric API» to 2.8
> >>>>>>
> >>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>
> >>>>>>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk <[hidden email]>
> >>>>>> написал(а):
> >>>>>>>
> >>>>>>> Nikolay,
> >>>>>>>
> >>>>>>> Should we wait for both of the tickets given that we agreed that we are
> >>>>>>> putting an experimental marker on the new APIs? I'm ok to fix only the
> >>>>>>> first one and add the experimental marker so that we do not delay 2.8
> >>>>>>> release.
> >>>>>>>
> >>>>>>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков <[hidden email]>:
> >>>>>>>
> >>>>>>>> Andrey.
> >>>>>>>>
> >>>>>>>> Let’s move from the long letters to the code.
> >>>>>>>> If you want to change API - please, propose this changes.
> >>>>>>>> I think everybody wins if we make our API better.
> >>>>>>>>
> >>>>>>>> Please, describe proposed changes.
> >>>>>>>> It would be great if you have some examples or PR for it.
> >>>>>>>>
> >>>>>>>> As for this release, I have plans to contribute tickets
> >>>>>>>> «[IEP-35] Expose MetricRegistry to the public API» [1] and
> >>>>>>>> «[IEP-35] public Java metric API» [2] for it.
> >>>>>>>>
> >>>>>>>> Any objections on it?
> >>>>>>>>
> >>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-12553
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> 20 янв. 2020 г., в 13:08, Andrey Gura <[hidden email]> написал(а):
> >>>>>>>>>
> >>>>>>>>> It solves problem.
> >>>>>>>>>
> >>>>>>>>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
> >>>>>>>>> <[hidden email]> wrote:
> >>>>>>>>>>
> >>>>>>>>>> After giving it some thought, I agree with Denis - there is nothing
> >>>>>>>> wrong
> >>>>>>>>>> with exposing the new APIs, we just need to make it clear that we are
> >>>>>>>> still
> >>>>>>>>>> going to change it.
> >>>>>>>>>>
> >>>>>>>>>> Should we Introduce something like @IgniteExperimental annotation (I
> >>>>>>>>>> believe it has been discussed a dozen of times on the dev-list)?
> >>>>>>>>>>
> >>>>>>>>>> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov <[hidden email]>:
> >>>>>>>>>>
> >>>>>>>>>>> +1 to mark feature or whole release as EA.
> >>>>>>>>>>>
> >>>>>>>>>>> пт, 17 янв. 2020 г., 23:00 Denis Magda <[hidden email]>:
> >>>>>>>>>>>
> >>>>>>>>>>>> Folks, if you don't mind I'll share some thoughts/suggestions as an
> >>>>>>>>>>>> observer who was not involved in the feature development.
> >>>>>>>>>>>>
> >>>>>>>>>>>> It's absolutely 'ok' to deprecate an API that is replaced with a
> >>>>>> much
> >>>>>>>>>>>> better version. However, we should do this only when the new APIs
> >>>>>> are
> >>>>>>>>>>>> production-ready. If there are still many limitations or open items
> >>>>>>>> then
> >>>>>>>>>>>> don't deprecate anything that exists and release the new APIs
> >>>>>>>> labeling as
> >>>>>>>>>>>> early access. What if release the improvements labeling as EA
> >>>>>> instead
> >>>>>>>> of
> >>>>>>>>>>>> hiding them completely?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would also encourage us to put aside emotions, don't blame or
> >>>>>> point
> >>>>>>>>>>>> fingers. This IEP is a great initiative and you both have already
> >>>>>>>> done a
> >>>>>>>>>>>> tremendous job by developing, architecting and reviewing changes.
> >>>>>>>> Just be
> >>>>>>>>>>>> respectful. Nobody is trying to block the feature from being
> >>>>>> released.
> >>>>>>>>>>>> Everyone would be glad to tap into improvements and start using them
> >>>>>>>> in
> >>>>>>>>>>>> prod. But if more time is needed for the GA let's reiterate a bit.
> >>>>>>>>>>>>
> >>>>>>>>>>>> -
> >>>>>>>>>>>> Denis
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков <
> >>>>>> [hidden email]>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> Also I agree with Alexey about introducing public IgniteMonitoring
> >>>>>>>>>>>> facade
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This is not an issue with the API.
> >>>>>>>>>>>>> Just the new feature that doesn’t affects API.
> >>>>>>>>>>>>> Moreover, I create a ticket to fix it, already.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
> >>>>>>>>>>> then
> >>>>>>>>>>>>> test will fail. It's just not good tests.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> My changes doesn’t affect any `staticticsEnabled` property.
> >>>>>>>>>>>>> I don’ understand your point here.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It’s not redundant.
> >>>>>>>>>>>>> It required for exporters and provide read only access to
> >>>>>>>>>>> MetricRegistry
> >>>>>>>>>>>>> existing in the node.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
> >>>>>> use
> >>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Why this is issue?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Inconsistent MetricRegistry API.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It’s consistent.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Metrics lookups from map instead of using direct reference
> >>>>>>>>>>>>>> (performance problem).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 1. We(You and I) did this choice together to simplify creation of
> >>>>>> the
> >>>>>>>>>>> new
> >>>>>>>>>>>>> metrics.
> >>>>>>>>>>>>> 2. This is not public API issue.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I don’t ignore this flag.
> >>>>>>>>>>>>> It just doesn’t exists in new framework(because of scope).
> >>>>>>>>>>>>> I don’t think it’s an issue.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
> >>>>>>>>>>>> practices.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Please, clarify your statement.
> >>>>>>>>>>>>> What is best MBeans practices you are talking about?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Not finished IGNITE-11927
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> How this can be API issue?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> 17 янв. 2020 г., в 20:52, Andrey Gura <[hidden email]>
> >>>>>>>> написал(а):
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
> >>>>>>>> PR
> >>>>>>>>>>>>> [1].
> >>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
> >>>>>>>>>>> release.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> As I mentioned already IGNITE-11927 is part of IEP-35 and
> >>>>>>>>>>>>>> implementation seriously affects API's. Also I agree with Alexey
> >>>>>>>>>>> about
> >>>>>>>>>>>>>> introducing public IgniteMonitoring facade. So thiss PR doesn't
> >>>>>> fix
> >>>>>>>>>>>>>> all issues.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I talk about ignored existing functionality.
> >>>>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
> >>>>>>>>>>>>>> then test will fail. It's just not good tests.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
> >>>>>> will
> >>>>>>>>>>>> fix
> >>>>>>>>>>>>> it ASAP.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I already fix it all in IGNITE-11927
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>>> We should move the product forward and shouldn't hide major
> >>>>>>>>>>>>> contribution from the user just because your second guess «I don’t
> >>>>>>>> like
> >>>>>>>>>>>> the
> >>>>>>>>>>>>> API I just reviewed and approved».
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> We should move the product forward with with really finished
> >>>>>>>>>>> features,
> >>>>>>>>>>>>>> not pieces of features.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> So I am against this proposal.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It is not argument.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
> >>>>>> discuss
> >>>>>>>>>>>> them.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> We can prepare it together. But we can't block release.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> >>>>>>>>>>>>>>> What is *ALL* problems?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
> >>>>>> use
> >>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> >>>>>>>>>>>>>> Inconsistent MetricRegistry API.
> >>>>>>>>>>>>>> Metrics lookups from map instead of using direct reference
> >>>>>>>>>>>>>> (performance problem).
> >>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> >>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
> >>>>>>>>>>>> practices.
> >>>>>>>>>>>>>> Not finished IGNITE-11927
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It's enough I believe.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:28 PM Николай Ижиков <
> >>>>>> [hidden email]
> >>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Andrey.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
> >>>>>> PR
> >>>>>>>>>>>> [1].
> >>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
> >>>>>>>>>>> release.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I talk about ignored existing functionality.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
> >>>>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
> >>>>>> will
> >>>>>>>>>>>> fix
> >>>>>>>>>>>>> it ASAP.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> We should move the product forward and shouldn't hide major
> >>>>>>>>>>>>> contribution from the user just because your second guess «I don’t
> >>>>>>>> like
> >>>>>>>>>>>> the
> >>>>>>>>>>>>> API I just reviewed and approved».
> >>>>>>>>>>>>>>> So I am against this proposal.
> >>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
> >>>>>> discuss
> >>>>>>>>>>>> them.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> What is *ALL* problems?
> >>>>>>>>>>>>>>> Seems, we never be able to solve *ALL* problems.
> >>>>>>>>>>>>>>> But, we should move the product forward.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> As for your steps [1-6].
> >>>>>>>>>>>>>>> I’m always following these steps during my contribution.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 17 янв. 2020 г., в 19:08, Andrey Gura <[hidden email]>
> >>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The discussion is hot and can be endless. So in separate post I
> >>>>>>>>>>> want
> >>>>>>>>>>>>>>>> propose my solution.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>>>> 2. Create special feature branch B.
> >>>>>>>>>>>>>>>> 3. In branch B will be merged IGNITE-11927
> >>>>>>>>>>>>>>>> 4. Because IGNITE-11927 doesn't solve all problems we should
> >>>>>>>>>>> propose
> >>>>>>>>>>>>>>>> solution and implement it in branch B.
> >>>>>>>>>>>>>>>> 5. Testing, usability testing, fixing, etc iteratively.
> >>>>>>>>>>>>>>>> 6. Merge it to master and in new release branch if needed.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Independent step. There are some problem which should be fixed
> >>>>>> in
> >>>>>>>>>>> 2.8
> >>>>>>>>>>>>>>>> before release otherwise we introduce problems with
> >>>>>> compatibility
> >>>>>>>>>>>>>>>> which will haunt us till next major release. I'll create
> >>>>>> tickets.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:03 PM Andrey Gura <[hidden email]>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
> >>>>>>>> code.
> >>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> >>>>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
> >>>>>>>> major
> >>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> We don't know anything about development processes our users. I
> >>>>>>>>>>> can
> >>>>>>>>>>>>>>>>> admit that process could require that deprecated methods/APIs
> >>>>>> are
> >>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>> allowed for example.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
> >>>>>> don't
> >>>>>>>>>>>> give
> >>>>>>>>>>>>> me any information about it’s purpose and responsibilities.
> >>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I understand this. But I'm not Ignite user, I'm Ignite
> >>>>>> developer.
> >>>>>>>>>>>> The
> >>>>>>>>>>>>>>>>> key moment in my message *from user stand point*. From my point
> >>>>>>>> of
> >>>>>>>>>>>>>>>>> view it is very not intuitive solution and this interface is
> >>>>>>>>>>>>>>>>> redundant.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
> >>>>>> example.
> >>>>>>>>>>>>> There are other entities with such flag.
> >>>>>>>>>>>>>>>>>> They still works as expected.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Actually not. I fixed many such issues during IGNITE-11927
> >>>>>>>>>>>>> implementation.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
> >>>>>>>>>>>>>>>>>> Because of the scope.
> >>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
> >>>>>> other
> >>>>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I talk not about ability. I talk about ignored existing
> >>>>>>>>>>>> functionality.
> >>>>>>>>>>>>>>>>> So scope is not case here.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
> >>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
> >>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
> >>>>>> exporter
> >>>>>>>>>>>>> can’t.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Actually list is not metric at all as I already told.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 5:26 PM Николай Ижиков <
> >>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Andrey.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
> >>>>>>>> code.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> >>>>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
> >>>>>>>> major
> >>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
> >>>>>> don't
> >>>>>>>>>>>> give
> >>>>>>>>>>>>> me any information about it’s purpose and responsibilities.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Each SPI would have a `ReadOnlyMetricManager` which provides
> >>>>>>>>>>> access
> >>>>>>>>>>>>> to collection of `ReadOnlyMetricRegistry`
> >>>>>>>>>>>>>>>>>> which has a collection of `Metric`.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> So we reflects two-level structure we have in the internal API
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> GridMetricManager -> Collection[MetricRegistry] ->
> >>>>>>>>>>>> Collection[Metric]
> >>>>>>>>>>>>>>>>>> ReadOnlyMetricManager -> Collection[ReadOnlyMetricRegistry] ->
> >>>>>>>>>>>>> Collection[Metric]
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
> >>>>>> example.
> >>>>>>>>>>>>> There are other entities with such flag.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> They still works as expected.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Because of the scope.
> >>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
> >>>>>> other
> >>>>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
> >>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
> >>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
> >>>>>> exporter
> >>>>>>>>>>>>> can’t.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>> https://github.com/apache/ignite/pull/7269/files#diff-0ae5657231fc4c1f650493b02190b81bR25
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 16:57, Andrey Gura <[hidden email]>
> >>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
> >>>>>>>>>>>> reviewers
> >>>>>>>>>>>>> of the Metric API.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Yes. But if I'm not missing some thing you were major
> >>>>>> developer
> >>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>> Metric API :) Shit happens. And it happened.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
> >>>>>> that
> >>>>>>>>>>>> are
> >>>>>>>>>>>>> still supported and don't offer reasonable substitution.
> >>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> There is such concept - backward compatibility. I understand
> >>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>> deprecation of some interface doesn't break backward
> >>>>>>>>>>> compatibility
> >>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>>>>> it leads to question^ what should I use instead of this. And
> >>>>>>>>>>>>>>>>>>> MetricExporterSpi is not answer for this question. Because it
> >>>>>>>> is
> >>>>>>>>>>>>> brand
> >>>>>>>>>>>>>>>>>>> new API and it requires rewrite client code.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> >>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
> >>>>>> the
> >>>>>>>>>>>>> exporters.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> No it is not. It's completely artificial thing which allow
> >>>>>>>>>>> iterate
> >>>>>>>>>>>>> via
> >>>>>>>>>>>>>>>>>>> all metric registries. GridMetricManager implements this
> >>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>> while it is not metric registry. Form user stand point it is
> >>>>>>>>>>> very
> >>>>>>>>>>>>>>>>>>> strange interface which don't give me any information about
> >>>>>>>> it's
> >>>>>>>>>>>>>>>>>>> purpose and responsibilities.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> >>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
> >>>>>> example.
> >>>>>>>>>>>>> There
> >>>>>>>>>>>>>>>>>>> are other entities with such flag.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> And that done, intentionally.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Why do you decided do in such way? Why you ignore existing
> >>>>>>>>>>>>>>>>>>> functionality? It affects user expectations and experience.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Yes? I'm working. Unfortunately we are not synchronized in
> >>>>>> this
> >>>>>>>>>>>>>>>>>>> context and I should redo all metrics related changes in
> >>>>>> order
> >>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> merge it with my changes. Anyway, my change doesn't solve all
> >>>>>>>>>>>>> problems
> >>>>>>>>>>>>>>>>>>> (e.g. it doesn't introduce IgniteMonitoring facade).
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Unfortunately it will be just fix. In my solution it is
> >>>>>>>>>>> redesign.
> >>>>>>>>>>>>> Stop
> >>>>>>>>>>>>>>>>>>> fixing issues, let's do things. It requires deeper changes.
> >>>>>> My
> >>>>>>>>>>>>> changes
> >>>>>>>>>>>>>>>>>>> blocks AI 2.8 release because it big enough. So it retargeted
> >>>>>>>> on
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> next release. And it is one more reason for moving the
> >>>>>> changes
> >>>>>>>>>>> to
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> internal packages. And it isn't good news for me because I
> >>>>>> will
> >>>>>>>>>>> go
> >>>>>>>>>>>>>>>>>>> throughout pan and tiers of merge. But it is right.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Yes, I know. But they should not be exported by
> >>>>>>>>>>> MetricExporterSpi
> >>>>>>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 3:37 PM Николай Ижиков <
> >>>>>>>>>>>> [hidden email]>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Andrey, thanks for your opinion and your ownest critisism.
> >>>>>>>>>>>>>>>>>>>> I can’t wait for your contribution.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
> >>>>>>>>>>>> reviewers
> >>>>>>>>>>>>> of the Metric API.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
> >>>>>> that
> >>>>>>>>>>>> are
> >>>>>>>>>>>>> still supported and don't offer reasonable substitution.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
> >>>>>>>>>>>>> MetricExporterSpi's because it are still not-production ready.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> It’s ready.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
> >>>>>> doesn't
> >>>>>>>>>>>>> solve the problem because this interface exposes internal Metric
> >>>>>>>>>>>> interface
> >>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Not, its’ not.
> >>>>>>>>>>>>>>>>>>>> Please, see `org.apache.ignite.spi.metric.LongMetric` and
> >>>>>>>> other
> >>>>>>>>>>>>> public interface.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> API of MetricRegistry is inconsistent.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> MetricRegistry is the internal API.
> >>>>>>>>>>>>>>>>>>>> Feel free to create ticket for an issues with it and I will
> >>>>>>>> try
> >>>>>>>>>>>> to
> >>>>>>>>>>>>> fix it.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
> >>>>>> the
> >>>>>>>>>>>>> exporters.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> >>>>>>>>>>>>>>>>>>>> And that done, intentionally.
> >>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> >>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 15:09, Andrey Gura <[hidden email]>
> >>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
> >>>>>> that
> >>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
> >>>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still not-production
> >>>>>>>> ready.
> >>>>>>>>>>>>> There
> >>>>>>>>>>>>>>>>>>>>> are some issues with it and usage of ReadOnlyMetricRegistry
> >>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>> just one of them.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
> >>>>>> doesn't
> >>>>>>>>>>>>> solve
> >>>>>>>>>>>>>>>>>>>>> the problem because this interface exposes internal Metric
> >>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>> implementations. So your PR is incomplete.
> >>>>>>>>>>>>>>>>>>>>> Moreover, API of MetricRegistry is inconsistent. E.g.
> >>>>>>>>>>>>> register(name,
> >>>>>>>>>>>>>>>>>>>>> supplier, desc) method returns registered metric for some
> >>>>>>>>>>> types
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>> doesn't for other. register(metric) method is inconsistent
> >>>>>> in
> >>>>>>>>>>>>> sense of
> >>>>>>>>>>>>>>>>>>>>> metric naming. ReadOnlyMetricRegistry interface is
> >>>>>> redundant.
> >>>>>>>>>>>>>>>>>>>>> MetricExporterSpi should be revised because it absolutely
> >>>>>> not
> >>>>>>>>>>>>>>>>>>>>> intuitive because it requires ReadOnlyMetricRegistry and
> >>>>>> it's
> >>>>>>>>>>>>> purpose
> >>>>>>>>>>>>>>>>>>>>> is undefined.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> One more point. IEP-35 is still not fully implemented. Some
> >>>>>>>>>>>>> things are
> >>>>>>>>>>>>>>>>>>>>> not taken into account. Exporters expose metrics if they
> >>>>>> are
> >>>>>>>>>>>>> disabled.
> >>>>>>>>>>>>>>>>>>>>> JMX beans exposes values that don't confirm to best
> >>>>>> practices
> >>>>>>>>>>>> [1].
> >>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all. Ubiquitous
> >>>>>>>> merics
> >>>>>>>>>>>>> lookup
> >>>>>>>>>>>>>>>>>>>>> from hash map instead of usage reference for getting
> >>>>>> metrics
> >>>>>>>>>>>>> values
> >>>>>>>>>>>>>>>>>>>>> (it is just performance issue). Also IGNITE-11927 is not
> >>>>>>>>>>>>> implemented
> >>>>>>>>>>>>>>>>>>>>> which also changes interfaces significantly.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Let's just admit that the implementation is immature and
> >>>>>> must
> >>>>>>>>>>> be
> >>>>>>>>>>>>> moved
> >>>>>>>>>>>>>>>>>>>>> to the internal packages.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> And because we already merged partially implemented IEP to
> >>>>>>>> the
> >>>>>>>>>>>>> master
> >>>>>>>>>>>>>>>>>>>>> branch we *must move all currently public APIs to the
> >>>>>>>> internal
> >>>>>>>>>>>>> API*
> >>>>>>>>>>>>>>>>>>>>> while it will not be ready for publication.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> And the last but not least. What is happening indicates a
> >>>>>>>>>>>> immature
> >>>>>>>>>>>>>>>>>>>>> development process which must be revised. I don't want
> >>>>>>>>>>> discuss
> >>>>>>>>>>>>> it in
> >>>>>>>>>>>>>>>>>>>>> this thread but we must not allow merge of change to the
> >>>>>>>>>>> master
> >>>>>>>>>>>>> branch
> >>>>>>>>>>>>>>>>>>>>> before it will completed, that is we must use feature
> >>>>>>>> branches
> >>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>> full IEP not only for particular tickets. And also we
> >>>>>> should
> >>>>>>>>>>>>>>>>>>>>> reformulate IEP process in order to avoid things like this.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>> https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:49 PM Николай Ижиков <
> >>>>>>>>>>>>> [hidden email]> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Alex.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> OK, I may leverage your experience and create pure Java
> >>>>>> API.
> >>>>>>>>>>>>>>>>>>>>>> Ticket [1] created.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> But, personally, I don’t agree with you.
> >>>>>>>>>>>>>>>>>>>>>> Ignite has dozens of the API that theoretically have a
> >>>>>> usage
> >>>>>>>>>>>>> scenario, but in real-world have 0 custom implementation and
> >>>>>> usages.
> >>>>>>>>>>>>>>>>>>>>>> Moreover, many APIs that were created with the intentions
> >>>>>>>> you
> >>>>>>>>>>>>> mentioned is abandoned now and confuses users.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> You can just see count of the tests we just mute on the
> >>>>>> TC.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Can you, please, take a look at the fix regarding puck API
> >>>>>>>>>>>> issue
> >>>>>>>>>>>>> you mentioned in your first letter [2], [3]
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-12553
> >>>>>>>>>>>>>>>>>>>>>> [2] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/IGNITE-12552
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 12:12, Alexey Goncharuk <
> >>>>>>>>>>>>> [hidden email]> написал(а):
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Nikolay,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Why do you think this is a wrong usage pattern? From the
> >>>>>>>> top
> >>>>>>>>>>>> of
> >>>>>>>>>>>>> my head,
> >>>>>>>>>>>>>>>>>>>>>>> here is a few cases of direct metric API usage that I
> >>>>>> know
> >>>>>>>>>>> are
> >>>>>>>>>>>>> currently
> >>>>>>>>>>>>>>>>>>>>>>> being used in production:
> >>>>>>>>>>>>>>>>>>>>>>> * A custom task execution scheduling service with load
> >>>>>>>>>>>>> balancing based on
> >>>>>>>>>>>>>>>>>>>>>>> utilization metrics readings from Java code
> >>>>>>>>>>>>>>>>>>>>>>> * Cleanup task trigger based on metrics readings
> >>>>>>>>>>>>>>>>>>>>>>> * A custom health-check endpoint for an application with
> >>>>>> an
> >>>>>>>>>>>>> embedded
> >>>>>>>>>>>>>>>>>>>>>>> Ignite node for Kubernetes/Spring Application/etc
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>
>
>

[Nikolay Izhikov-2]

> You want say didn't discuss?

Yes.

> Secondly, yes it took a lot of time due to a lot of changes. Is it problem?

No, of course.
My point - that your contribution that took a long time, already, can’t be an argument to postpone creation of the API in the current release.

> 23 янв. 2020 г., в 18:11, Andrey Gura <[hidden email]> написал(а):
>
>> We don’t discuss your changes and your proposals for the Metric API.
>
> You want say didn't discuss? Actually we did it [1] but you told ok
> let's see code :)
>
>> So I don’t think we can make the existence of some PR is an argument to introduce(or not introduce) this facade.
>
> You definitely right in case of competition development. But I think
> that collaborative development is more effective. Isn't it?
>
>> Moreover, As far as I know, you developing changes for the Metric API for 5 months without public discussion, for now. Let's start it.
>
> Firsty, with discussion. See above.
> Secondly, yes it took a lot of time due to a lot of changes. Is it problem?
>
>> Let’s do the following:
>> 1. Review `IgniteMetric` facade and introduce it to the users as an experimental API.
>
> It just doesn't make sense. Just commit for commit.
>
>> 2. Discuss your proposal to the Metric API in the separate thread you are referencing.
>
> You a re welcome to thread [1] again. But please, take into account.
> because discussion is postponed by you it's late enough to discuss
> proposed solution. But of course I'll answer on your questions and
> will be glade to your comments and suggestions.
>
>> I think we should start a discussion from the simplified explanation of:
>> 1. API intentions - What we want to gain with it? What is our focus?
>> 2. Simple, minimal example of API main interfaces and desired usages.
>
> All this already described at [1]. You also can take a look on PR (see
> MetricSource implementations, there are complex and simple ones).
>
> [1] http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Metrics-management-in-Ignite-tp43243.html
>
> On Thu, Jan 23, 2020 at 5:42 PM Николай Ижиков <[hidden email]> wrote:
>>
>> Andrey.
>>
>>> IGNITE-11927 implementation so your changes are incompatible with my changes
>>
>> We don’t discuss your changes and your proposals for the Metric API.
>> So I don’t think we can make the existence of some PR is an argument to introduce(or not introduce) this facade.
>> Moreover, As far as I know, you developing changes for the Metric API for 5 months without public discussion, for now. Let's start it.
>>
>> Let’s do the following:
>>
>> 1. Review `IgniteMetric` facade and introduce it to the users as an experimental API.
>>
>> 2. Discuss your proposal to the Metric API in the separate thread you are referencing.
>>
>> I think we should start a discussion from the simplified explanation of:
>>
>> 1. API intentions - What we want to gain with it? What is our focus?
>> 2. Simple, minimal example of API main interfaces and desired usages.
>>
>> This will help to the community and me personally better understand your idea and share feedback.
>>
>> Thanks.
>>
>>> 23 янв. 2020 г., в 17:15, Andrey Gura <[hidden email]> написал(а):
>>>
>>> Nikolay,
>>>
>>> as I wrote early in this thread API significantly changed during
>>> IGNITE-11927 implementation so your changes are incompatible with my
>>> changes.
>>>
>>> ReadOnlyMetricRegistry will be removed at all (still exists in a
>>> couple of places where it uses).
>>>
>>> Also I don't want to introduce IgniteMetric facade in this rush. In
>>> current implementation this interface just provides access to the
>>> ReadOnlyMetricManager instance (which will be removed) but it is not
>>> enough.
>>>
>>> I agree with Denis. We should mark current API as experimental and
>>> continue IEP-35 development. See my process proposal [1] described
>>> early this thread. We can release Apache Ignite 2.8.1 specially for
>>> this changes.
>>> Public APIs require deeper thinking in order to provide comprehensive,
>>> consistent and convenient way of metrics management for end users.
>>>
>>> Let's add IgniteExperimental, release 2.8 and finish metrics related
>>> issues after it.
>>>
>>> [1] http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-tp45146p45185.html
>>>
>>>
>>> On Wed, Jan 22, 2020 at 5:21 PM Николай Ижиков <[hidden email]> wrote:
>>>>
>>>> Hello, Igniters.
>>>>
>>>> * IGNITE-12552: Move ReadOnlyMetricRegistry to public API merged to the master and cherry-picked to the 2.8.
>>>> So the main issue with the Metric API solved.
>>>>
>>>> * I raised the PR [1] to fix second issue with the new Metric API: absence of the public Java API to get metrics.
>>>> This PR introduces the following changes:
>>>>
>>>> 1. IgniteMetric interface created: it provides Java API to access Ignite metrics created with the new Metric API.
>>>>
>>>> ```
>>>> public interface IgniteMetric extends Iterable<ReadOnlyMetricRegistry> {
>>>>   @Nullable ReadOnlyMetricRegistry registry(String name);
>>>> }
>>>> ```
>>>>
>>>> 2. All deprecation javadocs regarding metrics now reference to the public IgniteMetric instead of internal GridMetricManager:
>>>>
>>>>> @deprecated Use {@link IgniteMetric} instead.
>>>>
>>>> 3. Tests refactored to use IgniteMetric instead of GridMetricManager when possible.
>>>>
>>>> Please, review.
>>>>
>>>> [1]  https://github.com/apache/ignite/pull/7283
>>>>
>>>>> 21 янв. 2020 г., в 17:51, Николай Ижиков <[hidden email]> написал(а):
>>>>>
>>>>> Hello, Igniters.
>>>>>
>>>>> Alexey approved my PR [1] regarding fixing public API for metric exporters.
>>>>> I’m waiting for a bot visa and merge this PR.
>>>>>
>>>>> As we discussed, the metrics API will be marked with IgniteExperimental annotation.
>>>>>
>>>>> If anyone has any objection to this plan, please provide your feedback.
>>>>>
>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>
>>>>>> 21 янв. 2020 г., в 13:45, Николай Ижиков <[hidden email]> написал(а):
>>>>>>
>>>>>> Thanks, for the review Alexey.
>>>>>>
>>>>>> I will fix your comment and  try to implement Monitoring facade, shortly.
>>>>>>
>>>>>>> 21 янв. 2020 г., в 13:32, Alexey Goncharuk <[hidden email]> написал(а):
>>>>>>>
>>>>>>> Nikolay,
>>>>>>>
>>>>>>> I left a single comment in the PR about the histogram metric. I think the
>>>>>>> API looks much cleaner now.
>>>>>>>
>>>>>>> I will take care of the @IgniteExperimental annotation.
>>>>>>>
>>>>>>> пн, 20 янв. 2020 г. в 20:55, Николай Ижиков <[hidden email]>:
>>>>>>>
>>>>>>>> Alexey.
>>>>>>>>
>>>>>>>> PR [1] is waiting for your review.
>>>>>>>> Please, take a look.
>>>>>>>>
>>>>>>>> I think we should do the following before 2.8 release
>>>>>>>>
>>>>>>>> * Introduce new @IgniteExperimental annotation as discussed.
>>>>>>>> * Mark Monitoring API with it.
>>>>>>>> * merge «[IEP-35] Expose MetricRegistry to the public API» to 2.8
>>>>>>>> * merge «[IEP-35] public Java metric API» to 2.8
>>>>>>>>
>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>
>>>>>>>>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk <[hidden email]>
>>>>>>>> написал(а):
>>>>>>>>>
>>>>>>>>> Nikolay,
>>>>>>>>>
>>>>>>>>> Should we wait for both of the tickets given that we agreed that we are
>>>>>>>>> putting an experimental marker on the new APIs? I'm ok to fix only the
>>>>>>>>> first one and add the experimental marker so that we do not delay 2.8
>>>>>>>>> release.
>>>>>>>>>
>>>>>>>>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков <[hidden email]>:
>>>>>>>>>
>>>>>>>>>> Andrey.
>>>>>>>>>>
>>>>>>>>>> Let’s move from the long letters to the code.
>>>>>>>>>> If you want to change API - please, propose this changes.
>>>>>>>>>> I think everybody wins if we make our API better.
>>>>>>>>>>
>>>>>>>>>> Please, describe proposed changes.
>>>>>>>>>> It would be great if you have some examples or PR for it.
>>>>>>>>>>
>>>>>>>>>> As for this release, I have plans to contribute tickets
>>>>>>>>>> «[IEP-35] Expose MetricRegistry to the public API» [1] and
>>>>>>>>>> «[IEP-35] public Java metric API» [2] for it.
>>>>>>>>>>
>>>>>>>>>> Any objections on it?
>>>>>>>>>>
>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-12553
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 20 янв. 2020 г., в 13:08, Andrey Gura <[hidden email]> написал(а):
>>>>>>>>>>>
>>>>>>>>>>> It solves problem.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
>>>>>>>>>>> <[hidden email]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> After giving it some thought, I agree with Denis - there is nothing
>>>>>>>>>> wrong
>>>>>>>>>>>> with exposing the new APIs, we just need to make it clear that we are
>>>>>>>>>> still
>>>>>>>>>>>> going to change it.
>>>>>>>>>>>>
>>>>>>>>>>>> Should we Introduce something like @IgniteExperimental annotation (I
>>>>>>>>>>>> believe it has been discussed a dozen of times on the dev-list)?
>>>>>>>>>>>>
>>>>>>>>>>>> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov <[hidden email]>:
>>>>>>>>>>>>
>>>>>>>>>>>>> +1 to mark feature or whole release as EA.
>>>>>>>>>>>>>
>>>>>>>>>>>>> пт, 17 янв. 2020 г., 23:00 Denis Magda <[hidden email]>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Folks, if you don't mind I'll share some thoughts/suggestions as an
>>>>>>>>>>>>>> observer who was not involved in the feature development.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It's absolutely 'ok' to deprecate an API that is replaced with a
>>>>>>>> much
>>>>>>>>>>>>>> better version. However, we should do this only when the new APIs
>>>>>>>> are
>>>>>>>>>>>>>> production-ready. If there are still many limitations or open items
>>>>>>>>>> then
>>>>>>>>>>>>>> don't deprecate anything that exists and release the new APIs
>>>>>>>>>> labeling as
>>>>>>>>>>>>>> early access. What if release the improvements labeling as EA
>>>>>>>> instead
>>>>>>>>>> of
>>>>>>>>>>>>>> hiding them completely?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would also encourage us to put aside emotions, don't blame or
>>>>>>>> point
>>>>>>>>>>>>>> fingers. This IEP is a great initiative and you both have already
>>>>>>>>>> done a
>>>>>>>>>>>>>> tremendous job by developing, architecting and reviewing changes.
>>>>>>>>>> Just be
>>>>>>>>>>>>>> respectful. Nobody is trying to block the feature from being
>>>>>>>> released.
>>>>>>>>>>>>>> Everyone would be glad to tap into improvements and start using them
>>>>>>>>>> in
>>>>>>>>>>>>>> prod. But if more time is needed for the GA let's reiterate a bit.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -
>>>>>>>>>>>>>> Denis
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков <
>>>>>>>> [hidden email]>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Also I agree with Alexey about introducing public IgniteMonitoring
>>>>>>>>>>>>>> facade
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is not an issue with the API.
>>>>>>>>>>>>>>> Just the new feature that doesn’t affects API.
>>>>>>>>>>>>>>> Moreover, I create a ticket to fix it, already.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
>>>>>>>>>>>>> then
>>>>>>>>>>>>>>> test will fail. It's just not good tests.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My changes doesn’t affect any `staticticsEnabled` property.
>>>>>>>>>>>>>>> I don’ understand your point here.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It’s not redundant.
>>>>>>>>>>>>>>> It required for exporters and provide read only access to
>>>>>>>>>>>>> MetricRegistry
>>>>>>>>>>>>>>> existing in the node.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
>>>>>>>> use
>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Why this is issue?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It’s consistent.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct reference
>>>>>>>>>>>>>>>> (performance problem).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. We(You and I) did this choice together to simplify creation of
>>>>>>>> the
>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> metrics.
>>>>>>>>>>>>>>> 2. This is not public API issue.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don’t ignore this flag.
>>>>>>>>>>>>>>> It just doesn’t exists in new framework(because of scope).
>>>>>>>>>>>>>>> I don’t think it’s an issue.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
>>>>>>>>>>>>>> practices.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please, clarify your statement.
>>>>>>>>>>>>>>> What is best MBeans practices you are talking about?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Not finished IGNITE-11927
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> How this can be API issue?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 20:52, Andrey Gura <[hidden email]>
>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
>>>>>>>>>> PR
>>>>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As I mentioned already IGNITE-11927 is part of IEP-35 and
>>>>>>>>>>>>>>>> implementation seriously affects API's. Also I agree with Alexey
>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>> introducing public IgniteMonitoring facade. So thiss PR doesn't
>>>>>>>> fix
>>>>>>>>>>>>>>>> all issues.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
>>>>>>>>>>>>>>>> then test will fail. It's just not good tests.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
>>>>>>>> will
>>>>>>>>>>>>>> fix
>>>>>>>>>>>>>>> it ASAP.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I already fix it all in IGNITE-11927
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't hide major
>>>>>>>>>>>>>>> contribution from the user just because your second guess «I don’t
>>>>>>>>>> like
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> API I just reviewed and approved».
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We should move the product forward with with really finished
>>>>>>>>>>>>> features,
>>>>>>>>>>>>>>>> not pieces of features.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So I am against this proposal.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is not argument.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
>>>>>>>> discuss
>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We can prepare it together. But we can't block release.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
>>>>>>>>>>>>>>>>> What is *ALL* problems?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
>>>>>>>> use
>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct reference
>>>>>>>>>>>>>>>> (performance problem).
>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
>>>>>>>>>>>>>> practices.
>>>>>>>>>>>>>>>> Not finished IGNITE-11927
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It's enough I believe.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:28 PM Николай Ижиков <
>>>>>>>> [hidden email]
>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Andrey.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
>>>>>>>> PR
>>>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
>>>>>>>> will
>>>>>>>>>>>>>> fix
>>>>>>>>>>>>>>> it ASAP.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't hide major
>>>>>>>>>>>>>>> contribution from the user just because your second guess «I don’t
>>>>>>>>>> like
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> API I just reviewed and approved».
>>>>>>>>>>>>>>>>> So I am against this proposal.
>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
>>>>>>>> discuss
>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What is *ALL* problems?
>>>>>>>>>>>>>>>>> Seems, we never be able to solve *ALL* problems.
>>>>>>>>>>>>>>>>> But, we should move the product forward.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> As for your steps [1-6].
>>>>>>>>>>>>>>>>> I’m always following these steps during my contribution.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 19:08, Andrey Gura <[hidden email]>
>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The discussion is hot and can be endless. So in separate post I
>>>>>>>>>>>>> want
>>>>>>>>>>>>>>>>>> propose my solution.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>>>>>> 2. Create special feature branch B.
>>>>>>>>>>>>>>>>>> 3. In branch B will be merged IGNITE-11927
>>>>>>>>>>>>>>>>>> 4. Because IGNITE-11927 doesn't solve all problems we should
>>>>>>>>>>>>> propose
>>>>>>>>>>>>>>>>>> solution and implement it in branch B.
>>>>>>>>>>>>>>>>>> 5. Testing, usability testing, fixing, etc iteratively.
>>>>>>>>>>>>>>>>>> 6. Merge it to master and in new release branch if needed.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Independent step. There are some problem which should be fixed
>>>>>>>> in
>>>>>>>>>>>>> 2.8
>>>>>>>>>>>>>>>>>> before release otherwise we introduce problems with
>>>>>>>> compatibility
>>>>>>>>>>>>>>>>>> which will haunt us till next major release. I'll create
>>>>>>>> tickets.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:03 PM Andrey Gura <[hidden email]>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
>>>>>>>>>> code.
>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
>>>>>>>>>> major
>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> We don't know anything about development processes our users. I
>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>> admit that process could require that deprecated methods/APIs
>>>>>>>> are
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>> allowed for example.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
>>>>>>>> don't
>>>>>>>>>>>>>> give
>>>>>>>>>>>>>>> me any information about it’s purpose and responsibilities.
>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I understand this. But I'm not Ignite user, I'm Ignite
>>>>>>>> developer.
>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>> key moment in my message *from user stand point*. From my point
>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>> view it is very not intuitive solution and this interface is
>>>>>>>>>>>>>>>>>>> redundant.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
>>>>>>>> example.
>>>>>>>>>>>>>>> There are other entities with such flag.
>>>>>>>>>>>>>>>>>>>> They still works as expected.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Actually not. I fixed many such issues during IGNITE-11927
>>>>>>>>>>>>>>> implementation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
>>>>>>>>>>>>>>>>>>>> Because of the scope.
>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
>>>>>>>> other
>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I talk not about ability. I talk about ignored existing
>>>>>>>>>>>>>> functionality.
>>>>>>>>>>>>>>>>>>> So scope is not case here.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
>>>>>>>> exporter
>>>>>>>>>>>>>>> can’t.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Actually list is not metric at all as I already told.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 5:26 PM Николай Ижиков <
>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Andrey.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
>>>>>>>>>> code.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
>>>>>>>>>> major
>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
>>>>>>>> don't
>>>>>>>>>>>>>> give
>>>>>>>>>>>>>>> me any information about it’s purpose and responsibilities.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Each SPI would have a `ReadOnlyMetricManager` which provides
>>>>>>>>>>>>> access
>>>>>>>>>>>>>>> to collection of `ReadOnlyMetricRegistry`
>>>>>>>>>>>>>>>>>>>> which has a collection of `Metric`.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So we reflects two-level structure we have in the internal API
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> GridMetricManager -> Collection[MetricRegistry] ->
>>>>>>>>>>>>>> Collection[Metric]
>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricManager -> Collection[ReadOnlyMetricRegistry] ->
>>>>>>>>>>>>>>> Collection[Metric]
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
>>>>>>>> example.
>>>>>>>>>>>>>>> There are other entities with such flag.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> They still works as expected.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Because of the scope.
>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
>>>>>>>> other
>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
>>>>>>>> exporter
>>>>>>>>>>>>>>> can’t.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> https://github.com/apache/ignite/pull/7269/files#diff-0ae5657231fc4c1f650493b02190b81bR25
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 16:57, Andrey Gura <[hidden email]>
>>>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
>>>>>>>>>>>>>> reviewers
>>>>>>>>>>>>>>> of the Metric API.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Yes. But if I'm not missing some thing you were major
>>>>>>>> developer
>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>> Metric API :) Shit happens. And it happened.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
>>>>>>>> that
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> There is such concept - backward compatibility. I understand
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> deprecation of some interface doesn't break backward
>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>> it leads to question^ what should I use instead of this. And
>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi is not answer for this question. Because it
>>>>>>>>>> is
>>>>>>>>>>>>>>> brand
>>>>>>>>>>>>>>>>>>>>> new API and it requires rewrite client code.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
>>>>>>>> the
>>>>>>>>>>>>>>> exporters.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No it is not. It's completely artificial thing which allow
>>>>>>>>>>>>> iterate
>>>>>>>>>>>>>>> via
>>>>>>>>>>>>>>>>>>>>> all metric registries. GridMetricManager implements this
>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>> while it is not metric registry. Form user stand point it is
>>>>>>>>>>>>> very
>>>>>>>>>>>>>>>>>>>>> strange interface which don't give me any information about
>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>> purpose and responsibilities.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
>>>>>>>> example.
>>>>>>>>>>>>>>> There
>>>>>>>>>>>>>>>>>>>>> are other entities with such flag.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way? Why you ignore existing
>>>>>>>>>>>>>>>>>>>>> functionality? It affects user expectations and experience.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Yes? I'm working. Unfortunately we are not synchronized in
>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>> context and I should redo all metrics related changes in
>>>>>>>> order
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> merge it with my changes. Anyway, my change doesn't solve all
>>>>>>>>>>>>>>> problems
>>>>>>>>>>>>>>>>>>>>> (e.g. it doesn't introduce IgniteMonitoring facade).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Unfortunately it will be just fix. In my solution it is
>>>>>>>>>>>>> redesign.
>>>>>>>>>>>>>>> Stop
>>>>>>>>>>>>>>>>>>>>> fixing issues, let's do things. It requires deeper changes.
>>>>>>>> My
>>>>>>>>>>>>>>> changes
>>>>>>>>>>>>>>>>>>>>> blocks AI 2.8 release because it big enough. So it retargeted
>>>>>>>>>> on
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> next release. And it is one more reason for moving the
>>>>>>>> changes
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> internal packages. And it isn't good news for me because I
>>>>>>>> will
>>>>>>>>>>>>> go
>>>>>>>>>>>>>>>>>>>>> throughout pan and tiers of merge. But it is right.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Yes, I know. But they should not be exported by
>>>>>>>>>>>>> MetricExporterSpi
>>>>>>>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 3:37 PM Николай Ижиков <
>>>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Andrey, thanks for your opinion and your ownest critisism.
>>>>>>>>>>>>>>>>>>>>>> I can’t wait for your contribution.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
>>>>>>>>>>>>>> reviewers
>>>>>>>>>>>>>>> of the Metric API.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
>>>>>>>> that
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
>>>>>>>>>>>>>>> MetricExporterSpi's because it are still not-production ready.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It’s ready.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
>>>>>>>> doesn't
>>>>>>>>>>>>>>> solve the problem because this interface exposes internal Metric
>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Not, its’ not.
>>>>>>>>>>>>>>>>>>>>>> Please, see `org.apache.ignite.spi.metric.LongMetric` and
>>>>>>>>>> other
>>>>>>>>>>>>>>> public interface.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> API of MetricRegistry is inconsistent.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> MetricRegistry is the internal API.
>>>>>>>>>>>>>>>>>>>>>> Feel free to create ticket for an issues with it and I will
>>>>>>>>>> try
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> fix it.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
>>>>>>>> the
>>>>>>>>>>>>>>> exporters.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 15:09, Andrey Gura <[hidden email]>
>>>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
>>>>>>>> that
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still not-production
>>>>>>>>>> ready.
>>>>>>>>>>>>>>> There
>>>>>>>>>>>>>>>>>>>>>>> are some issues with it and usage of ReadOnlyMetricRegistry
>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>>> just one of them.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
>>>>>>>> doesn't
>>>>>>>>>>>>>>> solve
>>>>>>>>>>>>>>>>>>>>>>> the problem because this interface exposes internal Metric
>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>>> implementations. So your PR is incomplete.
>>>>>>>>>>>>>>>>>>>>>>> Moreover, API of MetricRegistry is inconsistent. E.g.
>>>>>>>>>>>>>>> register(name,
>>>>>>>>>>>>>>>>>>>>>>> supplier, desc) method returns registered metric for some
>>>>>>>>>>>>> types
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>> doesn't for other. register(metric) method is inconsistent
>>>>>>>> in
>>>>>>>>>>>>>>> sense of
>>>>>>>>>>>>>>>>>>>>>>> metric naming. ReadOnlyMetricRegistry interface is
>>>>>>>> redundant.
>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi should be revised because it absolutely
>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>> intuitive because it requires ReadOnlyMetricRegistry and
>>>>>>>> it's
>>>>>>>>>>>>>>> purpose
>>>>>>>>>>>>>>>>>>>>>>> is undefined.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> One more point. IEP-35 is still not fully implemented. Some
>>>>>>>>>>>>>>> things are
>>>>>>>>>>>>>>>>>>>>>>> not taken into account. Exporters expose metrics if they
>>>>>>>> are
>>>>>>>>>>>>>>> disabled.
>>>>>>>>>>>>>>>>>>>>>>> JMX beans exposes values that don't confirm to best
>>>>>>>> practices
>>>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all. Ubiquitous
>>>>>>>>>> merics
>>>>>>>>>>>>>>> lookup
>>>>>>>>>>>>>>>>>>>>>>> from hash map instead of usage reference for getting
>>>>>>>> metrics
>>>>>>>>>>>>>>> values
>>>>>>>>>>>>>>>>>>>>>>> (it is just performance issue). Also IGNITE-11927 is not
>>>>>>>>>>>>>>> implemented
>>>>>>>>>>>>>>>>>>>>>>> which also changes interfaces significantly.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Let's just admit that the implementation is immature and
>>>>>>>> must
>>>>>>>>>>>>> be
>>>>>>>>>>>>>>> moved
>>>>>>>>>>>>>>>>>>>>>>> to the internal packages.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> And because we already merged partially implemented IEP to
>>>>>>>>>> the
>>>>>>>>>>>>>>> master
>>>>>>>>>>>>>>>>>>>>>>> branch we *must move all currently public APIs to the
>>>>>>>>>> internal
>>>>>>>>>>>>>>> API*
>>>>>>>>>>>>>>>>>>>>>>> while it will not be ready for publication.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> And the last but not least. What is happening indicates a
>>>>>>>>>>>>>> immature
>>>>>>>>>>>>>>>>>>>>>>> development process which must be revised. I don't want
>>>>>>>>>>>>> discuss
>>>>>>>>>>>>>>> it in
>>>>>>>>>>>>>>>>>>>>>>> this thread but we must not allow merge of change to the
>>>>>>>>>>>>> master
>>>>>>>>>>>>>>> branch
>>>>>>>>>>>>>>>>>>>>>>> before it will completed, that is we must use feature
>>>>>>>>>> branches
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>> full IEP not only for particular tickets. And also we
>>>>>>>> should
>>>>>>>>>>>>>>>>>>>>>>> reformulate IEP process in order to avoid things like this.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:49 PM Николай Ижиков <
>>>>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Alex.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> OK, I may leverage your experience and create pure Java
>>>>>>>> API.
>>>>>>>>>>>>>>>>>>>>>>>> Ticket [1] created.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> But, personally, I don’t agree with you.
>>>>>>>>>>>>>>>>>>>>>>>> Ignite has dozens of the API that theoretically have a
>>>>>>>> usage
>>>>>>>>>>>>>>> scenario, but in real-world have 0 custom implementation and
>>>>>>>> usages.
>>>>>>>>>>>>>>>>>>>>>>>> Moreover, many APIs that were created with the intentions
>>>>>>>>>> you
>>>>>>>>>>>>>>> mentioned is abandoned now and confuses users.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You can just see count of the tests we just mute on the
>>>>>>>> TC.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Can you, please, take a look at the fix regarding puck API
>>>>>>>>>>>>>> issue
>>>>>>>>>>>>>>> you mentioned in your first letter [2], [3]
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-12553
>>>>>>>>>>>>>>>>>>>>>>>> [2] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/IGNITE-12552
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 12:12, Alexey Goncharuk <
>>>>>>>>>>>>>>> [hidden email]> написал(а):
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Nikolay,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Why do you think this is a wrong usage pattern? From the
>>>>>>>>>> top
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> my head,
>>>>>>>>>>>>>>>>>>>>>>>>> here is a few cases of direct metric API usage that I
>>>>>>>> know
>>>>>>>>>>>>> are
>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>>>>>>>> being used in production:
>>>>>>>>>>>>>>>>>>>>>>>>> * A custom task execution scheduling service with load
>>>>>>>>>>>>>>> balancing based on
>>>>>>>>>>>>>>>>>>>>>>>>> utilization metrics readings from Java code
>>>>>>>>>>>>>>>>>>>>>>>>> * Cleanup task trigger based on metrics readings
>>>>>>>>>>>>>>>>>>>>>>>>> * A custom health-check endpoint for an application with
>>>>>>>> an
>>>>>>>>>>>>>>> embedded
>>>>>>>>>>>>>>>>>>>>>>>>> Ignite node for Kubernetes/Spring Application/etc
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>

[agura]

> My point - that your contribution that took a long time, already, can’t be an argument to postpone creation of the API in the current release.

Argument is not about time. But about API which is known will be changed.
Second argument: why we should add this experimental API to the
already existing experimental API? Just to making API more
experimental? As I told already it is commit for commit and doesn't
bring any value but brings some inconvenience to me (e.g. merge
problems).

BTW, does it exist issue about marking IEP-35 API's as experimental?

On Thu, Jan 23, 2020 at 8:33 PM Николай Ижиков <[hidden email]> wrote:

>
> > You want say didn't discuss?
>
> Yes.
>
> > Secondly, yes it took a lot of time due to a lot of changes. Is it problem?
>
> No, of course.
> My point - that your contribution that took a long time, already, can’t be an argument to postpone creation of the API in the current release.
>
>
> > 23 янв. 2020 г., в 18:11, Andrey Gura <[hidden email]> написал(а):
> >
> >> We don’t discuss your changes and your proposals for the Metric API.
> >
> > You want say didn't discuss? Actually we did it [1] but you told ok
> > let's see code :)
> >
> >> So I don’t think we can make the existence of some PR is an argument to introduce(or not introduce) this facade.
> >
> > You definitely right in case of competition development. But I think
> > that collaborative development is more effective. Isn't it?
> >
> >> Moreover, As far as I know, you developing changes for the Metric API for 5 months without public discussion, for now. Let's start it.
> >
> > Firsty, with discussion. See above.
> > Secondly, yes it took a lot of time due to a lot of changes. Is it problem?
> >
> >> Let’s do the following:
> >> 1. Review `IgniteMetric` facade and introduce it to the users as an experimental API.
> >
> > It just doesn't make sense. Just commit for commit.
> >
> >> 2. Discuss your proposal to the Metric API in the separate thread you are referencing.
> >
> > You a re welcome to thread [1] again. But please, take into account.
> > because discussion is postponed by you it's late enough to discuss
> > proposed solution. But of course I'll answer on your questions and
> > will be glade to your comments and suggestions.
> >
> >> I think we should start a discussion from the simplified explanation of:
> >> 1. API intentions - What we want to gain with it? What is our focus?
> >> 2. Simple, minimal example of API main interfaces and desired usages.
> >
> > All this already described at [1]. You also can take a look on PR (see
> > MetricSource implementations, there are complex and simple ones).
> >
> > [1] http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Metrics-management-in-Ignite-tp43243.html
> >
> > On Thu, Jan 23, 2020 at 5:42 PM Николай Ижиков <[hidden email]> wrote:
> >>
> >> Andrey.
> >>
> >>> IGNITE-11927 implementation so your changes are incompatible with my changes
> >>
> >> We don’t discuss your changes and your proposals for the Metric API.
> >> So I don’t think we can make the existence of some PR is an argument to introduce(or not introduce) this facade.
> >> Moreover, As far as I know, you developing changes for the Metric API for 5 months without public discussion, for now. Let's start it.
> >>
> >> Let’s do the following:
> >>
> >> 1. Review `IgniteMetric` facade and introduce it to the users as an experimental API.
> >>
> >> 2. Discuss your proposal to the Metric API in the separate thread you are referencing.
> >>
> >> I think we should start a discussion from the simplified explanation of:
> >>
> >> 1. API intentions - What we want to gain with it? What is our focus?
> >> 2. Simple, minimal example of API main interfaces and desired usages.
> >>
> >> This will help to the community and me personally better understand your idea and share feedback.
> >>
> >> Thanks.
> >>
> >>> 23 янв. 2020 г., в 17:15, Andrey Gura <[hidden email]> написал(а):
> >>>
> >>> Nikolay,
> >>>
> >>> as I wrote early in this thread API significantly changed during
> >>> IGNITE-11927 implementation so your changes are incompatible with my
> >>> changes.
> >>>
> >>> ReadOnlyMetricRegistry will be removed at all (still exists in a
> >>> couple of places where it uses).
> >>>
> >>> Also I don't want to introduce IgniteMetric facade in this rush. In
> >>> current implementation this interface just provides access to the
> >>> ReadOnlyMetricManager instance (which will be removed) but it is not
> >>> enough.
> >>>
> >>> I agree with Denis. We should mark current API as experimental and
> >>> continue IEP-35 development. See my process proposal [1] described
> >>> early this thread. We can release Apache Ignite 2.8.1 specially for
> >>> this changes.
> >>> Public APIs require deeper thinking in order to provide comprehensive,
> >>> consistent and convenient way of metrics management for end users.
> >>>
> >>> Let's add IgniteExperimental, release 2.8 and finish metrics related
> >>> issues after it.
> >>>
> >>> [1] http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-tp45146p45185.html
> >>>
> >>>
> >>> On Wed, Jan 22, 2020 at 5:21 PM Николай Ижиков <[hidden email]> wrote:
> >>>>
> >>>> Hello, Igniters.
> >>>>
> >>>> * IGNITE-12552: Move ReadOnlyMetricRegistry to public API merged to the master and cherry-picked to the 2.8.
> >>>> So the main issue with the Metric API solved.
> >>>>
> >>>> * I raised the PR [1] to fix second issue with the new Metric API: absence of the public Java API to get metrics.
> >>>> This PR introduces the following changes:
> >>>>
> >>>> 1. IgniteMetric interface created: it provides Java API to access Ignite metrics created with the new Metric API.
> >>>>
> >>>> ```
> >>>> public interface IgniteMetric extends Iterable<ReadOnlyMetricRegistry> {
> >>>>   @Nullable ReadOnlyMetricRegistry registry(String name);
> >>>> }
> >>>> ```
> >>>>
> >>>> 2. All deprecation javadocs regarding metrics now reference to the public IgniteMetric instead of internal GridMetricManager:
> >>>>
> >>>>> @deprecated Use {@link IgniteMetric} instead.
> >>>>
> >>>> 3. Tests refactored to use IgniteMetric instead of GridMetricManager when possible.
> >>>>
> >>>> Please, review.
> >>>>
> >>>> [1]  https://github.com/apache/ignite/pull/7283
> >>>>
> >>>>> 21 янв. 2020 г., в 17:51, Николай Ижиков <[hidden email]> написал(а):
> >>>>>
> >>>>> Hello, Igniters.
> >>>>>
> >>>>> Alexey approved my PR [1] regarding fixing public API for metric exporters.
> >>>>> I’m waiting for a bot visa and merge this PR.
> >>>>>
> >>>>> As we discussed, the metrics API will be marked with IgniteExperimental annotation.
> >>>>>
> >>>>> If anyone has any objection to this plan, please provide your feedback.
> >>>>>
> >>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>
> >>>>>> 21 янв. 2020 г., в 13:45, Николай Ижиков <[hidden email]> написал(а):
> >>>>>>
> >>>>>> Thanks, for the review Alexey.
> >>>>>>
> >>>>>> I will fix your comment and  try to implement Monitoring facade, shortly.
> >>>>>>
> >>>>>>> 21 янв. 2020 г., в 13:32, Alexey Goncharuk <[hidden email]> написал(а):
> >>>>>>>
> >>>>>>> Nikolay,
> >>>>>>>
> >>>>>>> I left a single comment in the PR about the histogram metric. I think the
> >>>>>>> API looks much cleaner now.
> >>>>>>>
> >>>>>>> I will take care of the @IgniteExperimental annotation.
> >>>>>>>
> >>>>>>> пн, 20 янв. 2020 г. в 20:55, Николай Ижиков <[hidden email]>:
> >>>>>>>
> >>>>>>>> Alexey.
> >>>>>>>>
> >>>>>>>> PR [1] is waiting for your review.
> >>>>>>>> Please, take a look.
> >>>>>>>>
> >>>>>>>> I think we should do the following before 2.8 release
> >>>>>>>>
> >>>>>>>> * Introduce new @IgniteExperimental annotation as discussed.
> >>>>>>>> * Mark Monitoring API with it.
> >>>>>>>> * merge «[IEP-35] Expose MetricRegistry to the public API» to 2.8
> >>>>>>>> * merge «[IEP-35] public Java metric API» to 2.8
> >>>>>>>>
> >>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>
> >>>>>>>>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk <[hidden email]>
> >>>>>>>> написал(а):
> >>>>>>>>>
> >>>>>>>>> Nikolay,
> >>>>>>>>>
> >>>>>>>>> Should we wait for both of the tickets given that we agreed that we are
> >>>>>>>>> putting an experimental marker on the new APIs? I'm ok to fix only the
> >>>>>>>>> first one and add the experimental marker so that we do not delay 2.8
> >>>>>>>>> release.
> >>>>>>>>>
> >>>>>>>>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков <[hidden email]>:
> >>>>>>>>>
> >>>>>>>>>> Andrey.
> >>>>>>>>>>
> >>>>>>>>>> Let’s move from the long letters to the code.
> >>>>>>>>>> If you want to change API - please, propose this changes.
> >>>>>>>>>> I think everybody wins if we make our API better.
> >>>>>>>>>>
> >>>>>>>>>> Please, describe proposed changes.
> >>>>>>>>>> It would be great if you have some examples or PR for it.
> >>>>>>>>>>
> >>>>>>>>>> As for this release, I have plans to contribute tickets
> >>>>>>>>>> «[IEP-35] Expose MetricRegistry to the public API» [1] and
> >>>>>>>>>> «[IEP-35] public Java metric API» [2] for it.
> >>>>>>>>>>
> >>>>>>>>>> Any objections on it?
> >>>>>>>>>>
> >>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-12553
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> 20 янв. 2020 г., в 13:08, Andrey Gura <[hidden email]> написал(а):
> >>>>>>>>>>>
> >>>>>>>>>>> It solves problem.
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
> >>>>>>>>>>> <[hidden email]> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> After giving it some thought, I agree with Denis - there is nothing
> >>>>>>>>>> wrong
> >>>>>>>>>>>> with exposing the new APIs, we just need to make it clear that we are
> >>>>>>>>>> still
> >>>>>>>>>>>> going to change it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Should we Introduce something like @IgniteExperimental annotation (I
> >>>>>>>>>>>> believe it has been discussed a dozen of times on the dev-list)?
> >>>>>>>>>>>>
> >>>>>>>>>>>> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov <[hidden email]>:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> +1 to mark feature or whole release as EA.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> пт, 17 янв. 2020 г., 23:00 Denis Magda <[hidden email]>:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Folks, if you don't mind I'll share some thoughts/suggestions as an
> >>>>>>>>>>>>>> observer who was not involved in the feature development.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It's absolutely 'ok' to deprecate an API that is replaced with a
> >>>>>>>> much
> >>>>>>>>>>>>>> better version. However, we should do this only when the new APIs
> >>>>>>>> are
> >>>>>>>>>>>>>> production-ready. If there are still many limitations or open items
> >>>>>>>>>> then
> >>>>>>>>>>>>>> don't deprecate anything that exists and release the new APIs
> >>>>>>>>>> labeling as
> >>>>>>>>>>>>>> early access. What if release the improvements labeling as EA
> >>>>>>>> instead
> >>>>>>>>>> of
> >>>>>>>>>>>>>> hiding them completely?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I would also encourage us to put aside emotions, don't blame or
> >>>>>>>> point
> >>>>>>>>>>>>>> fingers. This IEP is a great initiative and you both have already
> >>>>>>>>>> done a
> >>>>>>>>>>>>>> tremendous job by developing, architecting and reviewing changes.
> >>>>>>>>>> Just be
> >>>>>>>>>>>>>> respectful. Nobody is trying to block the feature from being
> >>>>>>>> released.
> >>>>>>>>>>>>>> Everyone would be glad to tap into improvements and start using them
> >>>>>>>>>> in
> >>>>>>>>>>>>>> prod. But if more time is needed for the GA let's reiterate a bit.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> -
> >>>>>>>>>>>>>> Denis
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков <
> >>>>>>>> [hidden email]>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Also I agree with Alexey about introducing public IgniteMonitoring
> >>>>>>>>>>>>>> facade
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This is not an issue with the API.
> >>>>>>>>>>>>>>> Just the new feature that doesn’t affects API.
> >>>>>>>>>>>>>>> Moreover, I create a ticket to fix it, already.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
> >>>>>>>>>>>>> then
> >>>>>>>>>>>>>>> test will fail. It's just not good tests.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> My changes doesn’t affect any `staticticsEnabled` property.
> >>>>>>>>>>>>>>> I don’ understand your point here.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It’s not redundant.
> >>>>>>>>>>>>>>> It required for exporters and provide read only access to
> >>>>>>>>>>>>> MetricRegistry
> >>>>>>>>>>>>>>> existing in the node.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
> >>>>>>>> use
> >>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Why this is issue?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It’s consistent.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct reference
> >>>>>>>>>>>>>>>> (performance problem).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 1. We(You and I) did this choice together to simplify creation of
> >>>>>>>> the
> >>>>>>>>>>>>> new
> >>>>>>>>>>>>>>> metrics.
> >>>>>>>>>>>>>>> 2. This is not public API issue.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I don’t ignore this flag.
> >>>>>>>>>>>>>>> It just doesn’t exists in new framework(because of scope).
> >>>>>>>>>>>>>>> I don’t think it’s an issue.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
> >>>>>>>>>>>>>> practices.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Please, clarify your statement.
> >>>>>>>>>>>>>>> What is best MBeans practices you are talking about?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Not finished IGNITE-11927
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> How this can be API issue?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 17 янв. 2020 г., в 20:52, Andrey Gura <[hidden email]>
> >>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
> >>>>>>>>>> PR
> >>>>>>>>>>>>>>> [1].
> >>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
> >>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> As I mentioned already IGNITE-11927 is part of IEP-35 and
> >>>>>>>>>>>>>>>> implementation seriously affects API's. Also I agree with Alexey
> >>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>> introducing public IgniteMonitoring facade. So thiss PR doesn't
> >>>>>>>> fix
> >>>>>>>>>>>>>>>> all issues.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
> >>>>>>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
> >>>>>>>>>>>>>>>> then test will fail. It's just not good tests.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
> >>>>>>>> will
> >>>>>>>>>>>>>> fix
> >>>>>>>>>>>>>>> it ASAP.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I already fix it all in IGNITE-11927
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>>>>> We should move the product forward and shouldn't hide major
> >>>>>>>>>>>>>>> contribution from the user just because your second guess «I don’t
> >>>>>>>>>> like
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>> API I just reviewed and approved».
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> We should move the product forward with with really finished
> >>>>>>>>>>>>> features,
> >>>>>>>>>>>>>>>> not pieces of features.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> So I am against this proposal.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It is not argument.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
> >>>>>>>> discuss
> >>>>>>>>>>>>>> them.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> We can prepare it together. But we can't block release.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> >>>>>>>>>>>>>>>>> What is *ALL* problems?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
> >>>>>>>> use
> >>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> >>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
> >>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct reference
> >>>>>>>>>>>>>>>> (performance problem).
> >>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> >>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
> >>>>>>>>>>>>>> practices.
> >>>>>>>>>>>>>>>> Not finished IGNITE-11927
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It's enough I believe.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:28 PM Николай Ижиков <
> >>>>>>>> [hidden email]
> >>>>>>>>>>>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Andrey.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
> >>>>>>>> PR
> >>>>>>>>>>>>>> [1].
> >>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
> >>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
> >>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
> >>>>>>>> will
> >>>>>>>>>>>>>> fix
> >>>>>>>>>>>>>>> it ASAP.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> We should move the product forward and shouldn't hide major
> >>>>>>>>>>>>>>> contribution from the user just because your second guess «I don’t
> >>>>>>>>>> like
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>> API I just reviewed and approved».
> >>>>>>>>>>>>>>>>> So I am against this proposal.
> >>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
> >>>>>>>> discuss
> >>>>>>>>>>>>>> them.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> What is *ALL* problems?
> >>>>>>>>>>>>>>>>> Seems, we never be able to solve *ALL* problems.
> >>>>>>>>>>>>>>>>> But, we should move the product forward.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> As for your steps [1-6].
> >>>>>>>>>>>>>>>>> I’m always following these steps during my contribution.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 19:08, Andrey Gura <[hidden email]>
> >>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The discussion is hot and can be endless. So in separate post I
> >>>>>>>>>>>>> want
> >>>>>>>>>>>>>>>>>> propose my solution.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>>>>>> 2. Create special feature branch B.
> >>>>>>>>>>>>>>>>>> 3. In branch B will be merged IGNITE-11927
> >>>>>>>>>>>>>>>>>> 4. Because IGNITE-11927 doesn't solve all problems we should
> >>>>>>>>>>>>> propose
> >>>>>>>>>>>>>>>>>> solution and implement it in branch B.
> >>>>>>>>>>>>>>>>>> 5. Testing, usability testing, fixing, etc iteratively.
> >>>>>>>>>>>>>>>>>> 6. Merge it to master and in new release branch if needed.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Independent step. There are some problem which should be fixed
> >>>>>>>> in
> >>>>>>>>>>>>> 2.8
> >>>>>>>>>>>>>>>>>> before release otherwise we introduce problems with
> >>>>>>>> compatibility
> >>>>>>>>>>>>>>>>>> which will haunt us till next major release. I'll create
> >>>>>>>> tickets.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:03 PM Andrey Gura <[hidden email]>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
> >>>>>>>>>> code.
> >>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> >>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
> >>>>>>>>>> major
> >>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> We don't know anything about development processes our users. I
> >>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>>>>> admit that process could require that deprecated methods/APIs
> >>>>>>>> are
> >>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>> allowed for example.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
> >>>>>>>> don't
> >>>>>>>>>>>>>> give
> >>>>>>>>>>>>>>> me any information about it’s purpose and responsibilities.
> >>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I understand this. But I'm not Ignite user, I'm Ignite
> >>>>>>>> developer.
> >>>>>>>>>>>>>> The
> >>>>>>>>>>>>>>>>>>> key moment in my message *from user stand point*. From my point
> >>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>> view it is very not intuitive solution and this interface is
> >>>>>>>>>>>>>>>>>>> redundant.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
> >>>>>>>> example.
> >>>>>>>>>>>>>>> There are other entities with such flag.
> >>>>>>>>>>>>>>>>>>>> They still works as expected.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Actually not. I fixed many such issues during IGNITE-11927
> >>>>>>>>>>>>>>> implementation.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
> >>>>>>>>>>>>>>>>>>>> Because of the scope.
> >>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
> >>>>>>>> other
> >>>>>>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I talk not about ability. I talk about ignored existing
> >>>>>>>>>>>>>> functionality.
> >>>>>>>>>>>>>>>>>>> So scope is not case here.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
> >>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
> >>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
> >>>>>>>> exporter
> >>>>>>>>>>>>>>> can’t.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Actually list is not metric at all as I already told.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 5:26 PM Николай Ижиков <
> >>>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Andrey.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
> >>>>>>>>>> code.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> >>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
> >>>>>>>>>> major
> >>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
> >>>>>>>> don't
> >>>>>>>>>>>>>> give
> >>>>>>>>>>>>>>> me any information about it’s purpose and responsibilities.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Each SPI would have a `ReadOnlyMetricManager` which provides
> >>>>>>>>>>>>> access
> >>>>>>>>>>>>>>> to collection of `ReadOnlyMetricRegistry`
> >>>>>>>>>>>>>>>>>>>> which has a collection of `Metric`.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> So we reflects two-level structure we have in the internal API
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> GridMetricManager -> Collection[MetricRegistry] ->
> >>>>>>>>>>>>>> Collection[Metric]
> >>>>>>>>>>>>>>>>>>>> ReadOnlyMetricManager -> Collection[ReadOnlyMetricRegistry] ->
> >>>>>>>>>>>>>>> Collection[Metric]
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
> >>>>>>>> example.
> >>>>>>>>>>>>>>> There are other entities with such flag.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> They still works as expected.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Because of the scope.
> >>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
> >>>>>>>> other
> >>>>>>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
> >>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
> >>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
> >>>>>>>> exporter
> >>>>>>>>>>>>>>> can’t.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> https://github.com/apache/ignite/pull/7269/files#diff-0ae5657231fc4c1f650493b02190b81bR25
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 16:57, Andrey Gura <[hidden email]>
> >>>>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
> >>>>>>>>>>>>>> reviewers
> >>>>>>>>>>>>>>> of the Metric API.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Yes. But if I'm not missing some thing you were major
> >>>>>>>> developer
> >>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>> Metric API :) Shit happens. And it happened.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
> >>>>>>>> that
> >>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
> >>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> There is such concept - backward compatibility. I understand
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>> deprecation of some interface doesn't break backward
> >>>>>>>>>>>>> compatibility
> >>>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>>>>>>> it leads to question^ what should I use instead of this. And
> >>>>>>>>>>>>>>>>>>>>> MetricExporterSpi is not answer for this question. Because it
> >>>>>>>>>> is
> >>>>>>>>>>>>>>> brand
> >>>>>>>>>>>>>>>>>>>>> new API and it requires rewrite client code.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> >>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
> >>>>>>>> the
> >>>>>>>>>>>>>>> exporters.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> No it is not. It's completely artificial thing which allow
> >>>>>>>>>>>>> iterate
> >>>>>>>>>>>>>>> via
> >>>>>>>>>>>>>>>>>>>>> all metric registries. GridMetricManager implements this
> >>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>> while it is not metric registry. Form user stand point it is
> >>>>>>>>>>>>> very
> >>>>>>>>>>>>>>>>>>>>> strange interface which don't give me any information about
> >>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>>>> purpose and responsibilities.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> >>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
> >>>>>>>> example.
> >>>>>>>>>>>>>>> There
> >>>>>>>>>>>>>>>>>>>>> are other entities with such flag.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way? Why you ignore existing
> >>>>>>>>>>>>>>>>>>>>> functionality? It affects user expectations and experience.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Yes? I'm working. Unfortunately we are not synchronized in
> >>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>> context and I should redo all metrics related changes in
> >>>>>>>> order
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>> merge it with my changes. Anyway, my change doesn't solve all
> >>>>>>>>>>>>>>> problems
> >>>>>>>>>>>>>>>>>>>>> (e.g. it doesn't introduce IgniteMonitoring facade).
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Unfortunately it will be just fix. In my solution it is
> >>>>>>>>>>>>> redesign.
> >>>>>>>>>>>>>>> Stop
> >>>>>>>>>>>>>>>>>>>>> fixing issues, let's do things. It requires deeper changes.
> >>>>>>>> My
> >>>>>>>>>>>>>>> changes
> >>>>>>>>>>>>>>>>>>>>> blocks AI 2.8 release because it big enough. So it retargeted
> >>>>>>>>>> on
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> next release. And it is one more reason for moving the
> >>>>>>>> changes
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> internal packages. And it isn't good news for me because I
> >>>>>>>> will
> >>>>>>>>>>>>> go
> >>>>>>>>>>>>>>>>>>>>> throughout pan and tiers of merge. But it is right.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Yes, I know. But they should not be exported by
> >>>>>>>>>>>>> MetricExporterSpi
> >>>>>>>>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 3:37 PM Николай Ижиков <
> >>>>>>>>>>>>>> [hidden email]>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Andrey, thanks for your opinion and your ownest critisism.
> >>>>>>>>>>>>>>>>>>>>>> I can’t wait for your contribution.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
> >>>>>>>>>>>>>> reviewers
> >>>>>>>>>>>>>>> of the Metric API.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
> >>>>>>>> that
> >>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
> >>>>>>>>>>>>>>> MetricExporterSpi's because it are still not-production ready.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> It’s ready.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
> >>>>>>>> doesn't
> >>>>>>>>>>>>>>> solve the problem because this interface exposes internal Metric
> >>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Not, its’ not.
> >>>>>>>>>>>>>>>>>>>>>> Please, see `org.apache.ignite.spi.metric.LongMetric` and
> >>>>>>>>>> other
> >>>>>>>>>>>>>>> public interface.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> API of MetricRegistry is inconsistent.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> MetricRegistry is the internal API.
> >>>>>>>>>>>>>>>>>>>>>> Feel free to create ticket for an issues with it and I will
> >>>>>>>>>> try
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>> fix it.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
> >>>>>>>> the
> >>>>>>>>>>>>>>> exporters.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> >>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
> >>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> >>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 15:09, Andrey Gura <[hidden email]>
> >>>>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
> >>>>>>>> that
> >>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
> >>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still not-production
> >>>>>>>>>> ready.
> >>>>>>>>>>>>>>> There
> >>>>>>>>>>>>>>>>>>>>>>> are some issues with it and usage of ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>> just one of them.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
> >>>>>>>> doesn't
> >>>>>>>>>>>>>>> solve
> >>>>>>>>>>>>>>>>>>>>>>> the problem because this interface exposes internal Metric
> >>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>> implementations. So your PR is incomplete.
> >>>>>>>>>>>>>>>>>>>>>>> Moreover, API of MetricRegistry is inconsistent. E.g.
> >>>>>>>>>>>>>>> register(name,
> >>>>>>>>>>>>>>>>>>>>>>> supplier, desc) method returns registered metric for some
> >>>>>>>>>>>>> types
> >>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>> doesn't for other. register(metric) method is inconsistent
> >>>>>>>> in
> >>>>>>>>>>>>>>> sense of
> >>>>>>>>>>>>>>>>>>>>>>> metric naming. ReadOnlyMetricRegistry interface is
> >>>>>>>> redundant.
> >>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi should be revised because it absolutely
> >>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>> intuitive because it requires ReadOnlyMetricRegistry and
> >>>>>>>> it's
> >>>>>>>>>>>>>>> purpose
> >>>>>>>>>>>>>>>>>>>>>>> is undefined.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> One more point. IEP-35 is still not fully implemented. Some
> >>>>>>>>>>>>>>> things are
> >>>>>>>>>>>>>>>>>>>>>>> not taken into account. Exporters expose metrics if they
> >>>>>>>> are
> >>>>>>>>>>>>>>> disabled.
> >>>>>>>>>>>>>>>>>>>>>>> JMX beans exposes values that don't confirm to best
> >>>>>>>> practices
> >>>>>>>>>>>>>> [1].
> >>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all. Ubiquitous
> >>>>>>>>>> merics
> >>>>>>>>>>>>>>> lookup
> >>>>>>>>>>>>>>>>>>>>>>> from hash map instead of usage reference for getting
> >>>>>>>> metrics
> >>>>>>>>>>>>>>> values
> >>>>>>>>>>>>>>>>>>>>>>> (it is just performance issue). Also IGNITE-11927 is not
> >>>>>>>>>>>>>>> implemented
> >>>>>>>>>>>>>>>>>>>>>>> which also changes interfaces significantly.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Let's just admit that the implementation is immature and
> >>>>>>>> must
> >>>>>>>>>>>>> be
> >>>>>>>>>>>>>>> moved
> >>>>>>>>>>>>>>>>>>>>>>> to the internal packages.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> And because we already merged partially implemented IEP to
> >>>>>>>>>> the
> >>>>>>>>>>>>>>> master
> >>>>>>>>>>>>>>>>>>>>>>> branch we *must move all currently public APIs to the
> >>>>>>>>>> internal
> >>>>>>>>>>>>>>> API*
> >>>>>>>>>>>>>>>>>>>>>>> while it will not be ready for publication.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> And the last but not least. What is happening indicates a
> >>>>>>>>>>>>>> immature
> >>>>>>>>>>>>>>>>>>>>>>> development process which must be revised. I don't want
> >>>>>>>>>>>>> discuss
> >>>>>>>>>>>>>>> it in
> >>>>>>>>>>>>>>>>>>>>>>> this thread but we must not allow merge of change to the
> >>>>>>>>>>>>> master
> >>>>>>>>>>>>>>> branch
> >>>>>>>>>>>>>>>>>>>>>>> before it will completed, that is we must use feature
> >>>>>>>>>> branches
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>> full IEP not only for particular tickets. And also we
> >>>>>>>> should
> >>>>>>>>>>>>>>>>>>>>>>> reformulate IEP process in order to avoid things like this.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:49 PM Николай Ижиков <
> >>>>>>>>>>>>>>> [hidden email]> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Alex.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> OK, I may leverage your experience and create pure Java
> >>>>>>>> API.
> >>>>>>>>>>>>>>>>>>>>>>>> Ticket [1] created.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> But, personally, I don’t agree with you.
> >>>>>>>>>>>>>>>>>>>>>>>> Ignite has dozens of the API that theoretically have a
> >>>>>>>> usage
> >>>>>>>>>>>>>>> scenario, but in real-world have 0 custom implementation and
> >>>>>>>> usages.
> >>>>>>>>>>>>>>>>>>>>>>>> Moreover, many APIs that were created with the intentions
> >>>>>>>>>> you
> >>>>>>>>>>>>>>> mentioned is abandoned now and confuses users.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> You can just see count of the tests we just mute on the
> >>>>>>>> TC.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Can you, please, take a look at the fix regarding puck API
> >>>>>>>>>>>>>> issue
> >>>>>>>>>>>>>>> you mentioned in your first letter [2], [3]
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-12553
> >>>>>>>>>>>>>>>>>>>>>>>> [2] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/IGNITE-12552
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 12:12, Alexey Goncharuk <
> >>>>>>>>>>>>>>> [hidden email]> написал(а):
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Nikolay,
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Why do you think this is a wrong usage pattern? From the
> >>>>>>>>>> top
> >>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>> my head,
> >>>>>>>>>>>>>>>>>>>>>>>>> here is a few cases of direct metric API usage that I
> >>>>>>>> know
> >>>>>>>>>>>>> are
> >>>>>>>>>>>>>>> currently
> >>>>>>>>>>>>>>>>>>>>>>>>> being used in production:
> >>>>>>>>>>>>>>>>>>>>>>>>> * A custom task execution scheduling service with load
> >>>>>>>>>>>>>>> balancing based on
> >>>>>>>>>>>>>>>>>>>>>>>>> utilization metrics readings from Java code
> >>>>>>>>>>>>>>>>>>>>>>>>> * Cleanup task trigger based on metrics readings
> >>>>>>>>>>>>>>>>>>>>>>>>> * A custom health-check endpoint for an application with
> >>>>>>>> an
> >>>>>>>>>>>>>>> embedded
> >>>>>>>>>>>>>>>>>>>>>>>>> Ignite node for Kubernetes/Spring Application/etc
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
>

[Nikolay Izhikov-2]

Andrey.

With this API we are trying to fill the GAP Alexey pointed out at the start of this discussion.
I think it worth to be reviewed and merged.

Can we, please, come back to the discussion of the changes itself?
I think API changes should be discussed in the other thread.

> Why do you think this is a wrong usage pattern? From the top of my head, here is a few cases of direct metric API usage that I know are currently being used in production:
> * A custom task execution scheduling service with load balancing based on utilization metrics readings from Java code
> * Cleanup task trigger based on metrics readings
> * A custom health-check endpoint for an application with an embedded Ignite node for Kubernetes/Spring Application/etc

[1] https://github.com/apache/ignite/pull/7283

> 24 янв. 2020 г., в 18:08, Andrey Gura <[hidden email]> написал(а):
>
>> My point - that your contribution that took a long time, already, can’t be an argument to postpone creation of the API in the current release.
>
> Argument is not about time. But about API which is known will be changed.
> Second argument: why we should add this experimental API to the
> already existing experimental API? Just to making API more
> experimental? As I told already it is commit for commit and doesn't
> bring any value but brings some inconvenience to me (e.g. merge
> problems).
>
> BTW, does it exist issue about marking IEP-35 API's as experimental?
>
> On Thu, Jan 23, 2020 at 8:33 PM Николай Ижиков <[hidden email]> wrote:
>>
>>> You want say didn't discuss?
>>
>> Yes.
>>
>>> Secondly, yes it took a lot of time due to a lot of changes. Is it problem?
>>
>> No, of course.
>> My point - that your contribution that took a long time, already, can’t be an argument to postpone creation of the API in the current release.
>>
>>
>>> 23 янв. 2020 г., в 18:11, Andrey Gura <[hidden email]> написал(а):
>>>
>>>> We don’t discuss your changes and your proposals for the Metric API.
>>>
>>> You want say didn't discuss? Actually we did it [1] but you told ok
>>> let's see code :)
>>>
>>>> So I don’t think we can make the existence of some PR is an argument to introduce(or not introduce) this facade.
>>>
>>> You definitely right in case of competition development. But I think
>>> that collaborative development is more effective. Isn't it?
>>>
>>>> Moreover, As far as I know, you developing changes for the Metric API for 5 months without public discussion, for now. Let's start it.
>>>
>>> Firsty, with discussion. See above.
>>> Secondly, yes it took a lot of time due to a lot of changes. Is it problem?
>>>
>>>> Let’s do the following:
>>>> 1. Review `IgniteMetric` facade and introduce it to the users as an experimental API.
>>>
>>> It just doesn't make sense. Just commit for commit.
>>>
>>>> 2. Discuss your proposal to the Metric API in the separate thread you are referencing.
>>>
>>> You a re welcome to thread [1] again. But please, take into account.
>>> because discussion is postponed by you it's late enough to discuss
>>> proposed solution. But of course I'll answer on your questions and
>>> will be glade to your comments and suggestions.
>>>
>>>> I think we should start a discussion from the simplified explanation of:
>>>> 1. API intentions - What we want to gain with it? What is our focus?
>>>> 2. Simple, minimal example of API main interfaces and desired usages.
>>>
>>> All this already described at [1]. You also can take a look on PR (see
>>> MetricSource implementations, there are complex and simple ones).
>>>
>>> [1] http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Metrics-management-in-Ignite-tp43243.html
>>>
>>> On Thu, Jan 23, 2020 at 5:42 PM Николай Ижиков <[hidden email]> wrote:
>>>>
>>>> Andrey.
>>>>
>>>>> IGNITE-11927 implementation so your changes are incompatible with my changes
>>>>
>>>> We don’t discuss your changes and your proposals for the Metric API.
>>>> So I don’t think we can make the existence of some PR is an argument to introduce(or not introduce) this facade.
>>>> Moreover, As far as I know, you developing changes for the Metric API for 5 months without public discussion, for now. Let's start it.
>>>>
>>>> Let’s do the following:
>>>>
>>>> 1. Review `IgniteMetric` facade and introduce it to the users as an experimental API.
>>>>
>>>> 2. Discuss your proposal to the Metric API in the separate thread you are referencing.
>>>>
>>>> I think we should start a discussion from the simplified explanation of:
>>>>
>>>> 1. API intentions - What we want to gain with it? What is our focus?
>>>> 2. Simple, minimal example of API main interfaces and desired usages.
>>>>
>>>> This will help to the community and me personally better understand your idea and share feedback.
>>>>
>>>> Thanks.
>>>>
>>>>> 23 янв. 2020 г., в 17:15, Andrey Gura <[hidden email]> написал(а):
>>>>>
>>>>> Nikolay,
>>>>>
>>>>> as I wrote early in this thread API significantly changed during
>>>>> IGNITE-11927 implementation so your changes are incompatible with my
>>>>> changes.
>>>>>
>>>>> ReadOnlyMetricRegistry will be removed at all (still exists in a
>>>>> couple of places where it uses).
>>>>>
>>>>> Also I don't want to introduce IgniteMetric facade in this rush. In
>>>>> current implementation this interface just provides access to the
>>>>> ReadOnlyMetricManager instance (which will be removed) but it is not
>>>>> enough.
>>>>>
>>>>> I agree with Denis. We should mark current API as experimental and
>>>>> continue IEP-35 development. See my process proposal [1] described
>>>>> early this thread. We can release Apache Ignite 2.8.1 specially for
>>>>> this changes.
>>>>> Public APIs require deeper thinking in order to provide comprehensive,
>>>>> consistent and convenient way of metrics management for end users.
>>>>>
>>>>> Let's add IgniteExperimental, release 2.8 and finish metrics related
>>>>> issues after it.
>>>>>
>>>>> [1] http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-tp45146p45185.html
>>>>>
>>>>>
>>>>> On Wed, Jan 22, 2020 at 5:21 PM Николай Ижиков <[hidden email]> wrote:
>>>>>>
>>>>>> Hello, Igniters.
>>>>>>
>>>>>> * IGNITE-12552: Move ReadOnlyMetricRegistry to public API merged to the master and cherry-picked to the 2.8.
>>>>>> So the main issue with the Metric API solved.
>>>>>>
>>>>>> * I raised the PR [1] to fix second issue with the new Metric API: absence of the public Java API to get metrics.
>>>>>> This PR introduces the following changes:
>>>>>>
>>>>>> 1. IgniteMetric interface created: it provides Java API to access Ignite metrics created with the new Metric API.
>>>>>>
>>>>>> ```
>>>>>> public interface IgniteMetric extends Iterable<ReadOnlyMetricRegistry> {
>>>>>>  @Nullable ReadOnlyMetricRegistry registry(String name);
>>>>>> }
>>>>>> ```
>>>>>>
>>>>>> 2. All deprecation javadocs regarding metrics now reference to the public IgniteMetric instead of internal GridMetricManager:
>>>>>>
>>>>>>> @deprecated Use {@link IgniteMetric} instead.
>>>>>>
>>>>>> 3. Tests refactored to use IgniteMetric instead of GridMetricManager when possible.
>>>>>>
>>>>>> Please, review.
>>>>>>
>>>>>> [1]  https://github.com/apache/ignite/pull/7283
>>>>>>
>>>>>>> 21 янв. 2020 г., в 17:51, Николай Ижиков <[hidden email]> написал(а):
>>>>>>>
>>>>>>> Hello, Igniters.
>>>>>>>
>>>>>>> Alexey approved my PR [1] regarding fixing public API for metric exporters.
>>>>>>> I’m waiting for a bot visa and merge this PR.
>>>>>>>
>>>>>>> As we discussed, the metrics API will be marked with IgniteExperimental annotation.
>>>>>>>
>>>>>>> If anyone has any objection to this plan, please provide your feedback.
>>>>>>>
>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>
>>>>>>>> 21 янв. 2020 г., в 13:45, Николай Ижиков <[hidden email]> написал(а):
>>>>>>>>
>>>>>>>> Thanks, for the review Alexey.
>>>>>>>>
>>>>>>>> I will fix your comment and  try to implement Monitoring facade, shortly.
>>>>>>>>
>>>>>>>>> 21 янв. 2020 г., в 13:32, Alexey Goncharuk <[hidden email]> написал(а):
>>>>>>>>>
>>>>>>>>> Nikolay,
>>>>>>>>>
>>>>>>>>> I left a single comment in the PR about the histogram metric. I think the
>>>>>>>>> API looks much cleaner now.
>>>>>>>>>
>>>>>>>>> I will take care of the @IgniteExperimental annotation.
>>>>>>>>>
>>>>>>>>> пн, 20 янв. 2020 г. в 20:55, Николай Ижиков <[hidden email]>:
>>>>>>>>>
>>>>>>>>>> Alexey.
>>>>>>>>>>
>>>>>>>>>> PR [1] is waiting for your review.
>>>>>>>>>> Please, take a look.
>>>>>>>>>>
>>>>>>>>>> I think we should do the following before 2.8 release
>>>>>>>>>>
>>>>>>>>>> * Introduce new @IgniteExperimental annotation as discussed.
>>>>>>>>>> * Mark Monitoring API with it.
>>>>>>>>>> * merge «[IEP-35] Expose MetricRegistry to the public API» to 2.8
>>>>>>>>>> * merge «[IEP-35] public Java metric API» to 2.8
>>>>>>>>>>
>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>
>>>>>>>>>>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk <[hidden email]>
>>>>>>>>>> написал(а):
>>>>>>>>>>>
>>>>>>>>>>> Nikolay,
>>>>>>>>>>>
>>>>>>>>>>> Should we wait for both of the tickets given that we agreed that we are
>>>>>>>>>>> putting an experimental marker on the new APIs? I'm ok to fix only the
>>>>>>>>>>> first one and add the experimental marker so that we do not delay 2.8
>>>>>>>>>>> release.
>>>>>>>>>>>
>>>>>>>>>>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков <[hidden email]>:
>>>>>>>>>>>
>>>>>>>>>>>> Andrey.
>>>>>>>>>>>>
>>>>>>>>>>>> Let’s move from the long letters to the code.
>>>>>>>>>>>> If you want to change API - please, propose this changes.
>>>>>>>>>>>> I think everybody wins if we make our API better.
>>>>>>>>>>>>
>>>>>>>>>>>> Please, describe proposed changes.
>>>>>>>>>>>> It would be great if you have some examples or PR for it.
>>>>>>>>>>>>
>>>>>>>>>>>> As for this release, I have plans to contribute tickets
>>>>>>>>>>>> «[IEP-35] Expose MetricRegistry to the public API» [1] and
>>>>>>>>>>>> «[IEP-35] public Java metric API» [2] for it.
>>>>>>>>>>>>
>>>>>>>>>>>> Any objections on it?
>>>>>>>>>>>>
>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-12553
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> 20 янв. 2020 г., в 13:08, Andrey Gura <[hidden email]> написал(а):
>>>>>>>>>>>>>
>>>>>>>>>>>>> It solves problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
>>>>>>>>>>>>> <[hidden email]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> After giving it some thought, I agree with Denis - there is nothing
>>>>>>>>>>>> wrong
>>>>>>>>>>>>>> with exposing the new APIs, we just need to make it clear that we are
>>>>>>>>>>>> still
>>>>>>>>>>>>>> going to change it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Should we Introduce something like @IgniteExperimental annotation (I
>>>>>>>>>>>>>> believe it has been discussed a dozen of times on the dev-list)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov <[hidden email]>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> +1 to mark feature or whole release as EA.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> пт, 17 янв. 2020 г., 23:00 Denis Magda <[hidden email]>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Folks, if you don't mind I'll share some thoughts/suggestions as an
>>>>>>>>>>>>>>>> observer who was not involved in the feature development.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It's absolutely 'ok' to deprecate an API that is replaced with a
>>>>>>>>>> much
>>>>>>>>>>>>>>>> better version. However, we should do this only when the new APIs
>>>>>>>>>> are
>>>>>>>>>>>>>>>> production-ready. If there are still many limitations or open items
>>>>>>>>>>>> then
>>>>>>>>>>>>>>>> don't deprecate anything that exists and release the new APIs
>>>>>>>>>>>> labeling as
>>>>>>>>>>>>>>>> early access. What if release the improvements labeling as EA
>>>>>>>>>> instead
>>>>>>>>>>>> of
>>>>>>>>>>>>>>>> hiding them completely?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I would also encourage us to put aside emotions, don't blame or
>>>>>>>>>> point
>>>>>>>>>>>>>>>> fingers. This IEP is a great initiative and you both have already
>>>>>>>>>>>> done a
>>>>>>>>>>>>>>>> tremendous job by developing, architecting and reviewing changes.
>>>>>>>>>>>> Just be
>>>>>>>>>>>>>>>> respectful. Nobody is trying to block the feature from being
>>>>>>>>>> released.
>>>>>>>>>>>>>>>> Everyone would be glad to tap into improvements and start using them
>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> prod. But if more time is needed for the GA let's reiterate a bit.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>> Denis
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков <
>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Also I agree with Alexey about introducing public IgniteMonitoring
>>>>>>>>>>>>>>>> facade
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is not an issue with the API.
>>>>>>>>>>>>>>>>> Just the new feature that doesn’t affects API.
>>>>>>>>>>>>>>>>> Moreover, I create a ticket to fix it, already.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>> test will fail. It's just not good tests.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> My changes doesn’t affect any `staticticsEnabled` property.
>>>>>>>>>>>>>>>>> I don’ understand your point here.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It’s not redundant.
>>>>>>>>>>>>>>>>> It required for exporters and provide read only access to
>>>>>>>>>>>>>>> MetricRegistry
>>>>>>>>>>>>>>>>> existing in the node.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
>>>>>>>>>> use
>>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Why this is issue?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It’s consistent.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct reference
>>>>>>>>>>>>>>>>>> (performance problem).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1. We(You and I) did this choice together to simplify creation of
>>>>>>>>>> the
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>> metrics.
>>>>>>>>>>>>>>>>> 2. This is not public API issue.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don’t ignore this flag.
>>>>>>>>>>>>>>>>> It just doesn’t exists in new framework(because of scope).
>>>>>>>>>>>>>>>>> I don’t think it’s an issue.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
>>>>>>>>>>>>>>>> practices.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Please, clarify your statement.
>>>>>>>>>>>>>>>>> What is best MBeans practices you are talking about?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> How this can be API issue?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 20:52, Andrey Gura <[hidden email]>
>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
>>>>>>>>>>>> PR
>>>>>>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As I mentioned already IGNITE-11927 is part of IEP-35 and
>>>>>>>>>>>>>>>>>> implementation seriously affects API's. Also I agree with Alexey
>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>> introducing public IgniteMonitoring facade. So thiss PR doesn't
>>>>>>>>>> fix
>>>>>>>>>>>>>>>>>> all issues.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
>>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
>>>>>>>>>>>>>>>>>> then test will fail. It's just not good tests.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
>>>>>>>>>> will
>>>>>>>>>>>>>>>> fix
>>>>>>>>>>>>>>>>> it ASAP.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I already fix it all in IGNITE-11927
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't hide major
>>>>>>>>>>>>>>>>> contribution from the user just because your second guess «I don’t
>>>>>>>>>>>> like
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> API I just reviewed and approved».
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We should move the product forward with with really finished
>>>>>>>>>>>>>>> features,
>>>>>>>>>>>>>>>>>> not pieces of features.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So I am against this proposal.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is not argument.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
>>>>>>>>>> discuss
>>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We can prepare it together. But we can't block release.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
>>>>>>>>>>>>>>>>>>> What is *ALL* problems?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
>>>>>>>>>> use
>>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
>>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
>>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct reference
>>>>>>>>>>>>>>>>>> (performance problem).
>>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
>>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
>>>>>>>>>>>>>>>> practices.
>>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It's enough I believe.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:28 PM Николай Ижиков <
>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Andrey.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
>>>>>>>>>> PR
>>>>>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
>>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
>>>>>>>>>> will
>>>>>>>>>>>>>>>> fix
>>>>>>>>>>>>>>>>> it ASAP.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't hide major
>>>>>>>>>>>>>>>>> contribution from the user just because your second guess «I don’t
>>>>>>>>>>>> like
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> API I just reviewed and approved».
>>>>>>>>>>>>>>>>>>> So I am against this proposal.
>>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
>>>>>>>>>> discuss
>>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> What is *ALL* problems?
>>>>>>>>>>>>>>>>>>> Seems, we never be able to solve *ALL* problems.
>>>>>>>>>>>>>>>>>>> But, we should move the product forward.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As for your steps [1-6].
>>>>>>>>>>>>>>>>>>> I’m always following these steps during my contribution.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 19:08, Andrey Gura <[hidden email]>
>>>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The discussion is hot and can be endless. So in separate post I
>>>>>>>>>>>>>>> want
>>>>>>>>>>>>>>>>>>>> propose my solution.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>>>>>>>> 2. Create special feature branch B.
>>>>>>>>>>>>>>>>>>>> 3. In branch B will be merged IGNITE-11927
>>>>>>>>>>>>>>>>>>>> 4. Because IGNITE-11927 doesn't solve all problems we should
>>>>>>>>>>>>>>> propose
>>>>>>>>>>>>>>>>>>>> solution and implement it in branch B.
>>>>>>>>>>>>>>>>>>>> 5. Testing, usability testing, fixing, etc iteratively.
>>>>>>>>>>>>>>>>>>>> 6. Merge it to master and in new release branch if needed.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Independent step. There are some problem which should be fixed
>>>>>>>>>> in
>>>>>>>>>>>>>>> 2.8
>>>>>>>>>>>>>>>>>>>> before release otherwise we introduce problems with
>>>>>>>>>> compatibility
>>>>>>>>>>>>>>>>>>>> which will haunt us till next major release. I'll create
>>>>>>>>>> tickets.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:03 PM Andrey Gura <[hidden email]>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
>>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
>>>>>>>>>>>> major
>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> We don't know anything about development processes our users. I
>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>> admit that process could require that deprecated methods/APIs
>>>>>>>>>> are
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>> allowed for example.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
>>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
>>>>>>>>>> don't
>>>>>>>>>>>>>>>> give
>>>>>>>>>>>>>>>>> me any information about it’s purpose and responsibilities.
>>>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I understand this. But I'm not Ignite user, I'm Ignite
>>>>>>>>>> developer.
>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>>> key moment in my message *from user stand point*. From my point
>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>> view it is very not intuitive solution and this interface is
>>>>>>>>>>>>>>>>>>>>> redundant.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
>>>>>>>>>> example.
>>>>>>>>>>>>>>>>> There are other entities with such flag.
>>>>>>>>>>>>>>>>>>>>>> They still works as expected.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Actually not. I fixed many such issues during IGNITE-11927
>>>>>>>>>>>>>>>>> implementation.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
>>>>>>>>>>>>>>>>>>>>>> Because of the scope.
>>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
>>>>>>>>>> other
>>>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I talk not about ability. I talk about ignored existing
>>>>>>>>>>>>>>>> functionality.
>>>>>>>>>>>>>>>>>>>>> So scope is not case here.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
>>>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
>>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
>>>>>>>>>> exporter
>>>>>>>>>>>>>>>>> can’t.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Actually list is not metric at all as I already told.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 5:26 PM Николай Ижиков <
>>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Andrey.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
>>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
>>>>>>>>>>>> major
>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
>>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
>>>>>>>>>> don't
>>>>>>>>>>>>>>>> give
>>>>>>>>>>>>>>>>> me any information about it’s purpose and responsibilities.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Each SPI would have a `ReadOnlyMetricManager` which provides
>>>>>>>>>>>>>>> access
>>>>>>>>>>>>>>>>> to collection of `ReadOnlyMetricRegistry`
>>>>>>>>>>>>>>>>>>>>>> which has a collection of `Metric`.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> So we reflects two-level structure we have in the internal API
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> GridMetricManager -> Collection[MetricRegistry] ->
>>>>>>>>>>>>>>>> Collection[Metric]
>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricManager -> Collection[ReadOnlyMetricRegistry] ->
>>>>>>>>>>>>>>>>> Collection[Metric]
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
>>>>>>>>>> example.
>>>>>>>>>>>>>>>>> There are other entities with such flag.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> They still works as expected.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Because of the scope.
>>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
>>>>>>>>>> other
>>>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
>>>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
>>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
>>>>>>>>>> exporter
>>>>>>>>>>>>>>>>> can’t.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> https://github.com/apache/ignite/pull/7269/files#diff-0ae5657231fc4c1f650493b02190b81bR25
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 16:57, Andrey Gura <[hidden email]>
>>>>>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
>>>>>>>>>>>>>>>> reviewers
>>>>>>>>>>>>>>>>> of the Metric API.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Yes. But if I'm not missing some thing you were major
>>>>>>>>>> developer
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>> Metric API :) Shit happens. And it happened.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
>>>>>>>>>> that
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
>>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> There is such concept - backward compatibility. I understand
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>> deprecation of some interface doesn't break backward
>>>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>>>> it leads to question^ what should I use instead of this. And
>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi is not answer for this question. Because it
>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> brand
>>>>>>>>>>>>>>>>>>>>>>> new API and it requires rewrite client code.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
>>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
>>>>>>>>>> the
>>>>>>>>>>>>>>>>> exporters.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No it is not. It's completely artificial thing which allow
>>>>>>>>>>>>>>> iterate
>>>>>>>>>>>>>>>>> via
>>>>>>>>>>>>>>>>>>>>>>> all metric registries. GridMetricManager implements this
>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>>> while it is not metric registry. Form user stand point it is
>>>>>>>>>>>>>>> very
>>>>>>>>>>>>>>>>>>>>>>> strange interface which don't give me any information about
>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>>>> purpose and responsibilities.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
>>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
>>>>>>>>>> example.
>>>>>>>>>>>>>>>>> There
>>>>>>>>>>>>>>>>>>>>>>> are other entities with such flag.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way? Why you ignore existing
>>>>>>>>>>>>>>>>>>>>>>> functionality? It affects user expectations and experience.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Yes? I'm working. Unfortunately we are not synchronized in
>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>> context and I should redo all metrics related changes in
>>>>>>>>>> order
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> merge it with my changes. Anyway, my change doesn't solve all
>>>>>>>>>>>>>>>>> problems
>>>>>>>>>>>>>>>>>>>>>>> (e.g. it doesn't introduce IgniteMonitoring facade).
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Unfortunately it will be just fix. In my solution it is
>>>>>>>>>>>>>>> redesign.
>>>>>>>>>>>>>>>>> Stop
>>>>>>>>>>>>>>>>>>>>>>> fixing issues, let's do things. It requires deeper changes.
>>>>>>>>>> My
>>>>>>>>>>>>>>>>> changes
>>>>>>>>>>>>>>>>>>>>>>> blocks AI 2.8 release because it big enough. So it retargeted
>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> next release. And it is one more reason for moving the
>>>>>>>>>> changes
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> internal packages. And it isn't good news for me because I
>>>>>>>>>> will
>>>>>>>>>>>>>>> go
>>>>>>>>>>>>>>>>>>>>>>> throughout pan and tiers of merge. But it is right.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Yes, I know. But they should not be exported by
>>>>>>>>>>>>>>> MetricExporterSpi
>>>>>>>>>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 3:37 PM Николай Ижиков <
>>>>>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Andrey, thanks for your opinion and your ownest critisism.
>>>>>>>>>>>>>>>>>>>>>>>> I can’t wait for your contribution.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
>>>>>>>>>>>>>>>> reviewers
>>>>>>>>>>>>>>>>> of the Metric API.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
>>>>>>>>>> that
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still not-production ready.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It’s ready.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>> solve the problem because this interface exposes internal Metric
>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Not, its’ not.
>>>>>>>>>>>>>>>>>>>>>>>> Please, see `org.apache.ignite.spi.metric.LongMetric` and
>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>> public interface.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> API of MetricRegistry is inconsistent.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> MetricRegistry is the internal API.
>>>>>>>>>>>>>>>>>>>>>>>> Feel free to create ticket for an issues with it and I will
>>>>>>>>>>>> try
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> fix it.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
>>>>>>>>>> the
>>>>>>>>>>>>>>>>> exporters.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
>>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
>>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
>>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 15:09, Andrey Gura <[hidden email]>
>>>>>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
>>>>>>>>>> that
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still not-production
>>>>>>>>>>>> ready.
>>>>>>>>>>>>>>>>> There
>>>>>>>>>>>>>>>>>>>>>>>>> are some issues with it and usage of ReadOnlyMetricRegistry
>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>>>>> just one of them.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>> solve
>>>>>>>>>>>>>>>>>>>>>>>>> the problem because this interface exposes internal Metric
>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>>>>> implementations. So your PR is incomplete.
>>>>>>>>>>>>>>>>>>>>>>>>> Moreover, API of MetricRegistry is inconsistent. E.g.
>>>>>>>>>>>>>>>>> register(name,
>>>>>>>>>>>>>>>>>>>>>>>>> supplier, desc) method returns registered metric for some
>>>>>>>>>>>>>>> types
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> doesn't for other. register(metric) method is inconsistent
>>>>>>>>>> in
>>>>>>>>>>>>>>>>> sense of
>>>>>>>>>>>>>>>>>>>>>>>>> metric naming. ReadOnlyMetricRegistry interface is
>>>>>>>>>> redundant.
>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi should be revised because it absolutely
>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>> intuitive because it requires ReadOnlyMetricRegistry and
>>>>>>>>>> it's
>>>>>>>>>>>>>>>>> purpose
>>>>>>>>>>>>>>>>>>>>>>>>> is undefined.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> One more point. IEP-35 is still not fully implemented. Some
>>>>>>>>>>>>>>>>> things are
>>>>>>>>>>>>>>>>>>>>>>>>> not taken into account. Exporters expose metrics if they
>>>>>>>>>> are
>>>>>>>>>>>>>>>>> disabled.
>>>>>>>>>>>>>>>>>>>>>>>>> JMX beans exposes values that don't confirm to best
>>>>>>>>>> practices
>>>>>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all. Ubiquitous
>>>>>>>>>>>> merics
>>>>>>>>>>>>>>>>> lookup
>>>>>>>>>>>>>>>>>>>>>>>>> from hash map instead of usage reference for getting
>>>>>>>>>> metrics
>>>>>>>>>>>>>>>>> values
>>>>>>>>>>>>>>>>>>>>>>>>> (it is just performance issue). Also IGNITE-11927 is not
>>>>>>>>>>>>>>>>> implemented
>>>>>>>>>>>>>>>>>>>>>>>>> which also changes interfaces significantly.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Let's just admit that the implementation is immature and
>>>>>>>>>> must
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> moved
>>>>>>>>>>>>>>>>>>>>>>>>> to the internal packages.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> And because we already merged partially implemented IEP to
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> master
>>>>>>>>>>>>>>>>>>>>>>>>> branch we *must move all currently public APIs to the
>>>>>>>>>>>> internal
>>>>>>>>>>>>>>>>> API*
>>>>>>>>>>>>>>>>>>>>>>>>> while it will not be ready for publication.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> And the last but not least. What is happening indicates a
>>>>>>>>>>>>>>>> immature
>>>>>>>>>>>>>>>>>>>>>>>>> development process which must be revised. I don't want
>>>>>>>>>>>>>>> discuss
>>>>>>>>>>>>>>>>> it in
>>>>>>>>>>>>>>>>>>>>>>>>> this thread but we must not allow merge of change to the
>>>>>>>>>>>>>>> master
>>>>>>>>>>>>>>>>> branch
>>>>>>>>>>>>>>>>>>>>>>>>> before it will completed, that is we must use feature
>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>> full IEP not only for particular tickets. And also we
>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>>>>>>> reformulate IEP process in order to avoid things like this.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:49 PM Николай Ижиков <
>>>>>>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Alex.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> OK, I may leverage your experience and create pure Java
>>>>>>>>>> API.
>>>>>>>>>>>>>>>>>>>>>>>>>> Ticket [1] created.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> But, personally, I don’t agree with you.
>>>>>>>>>>>>>>>>>>>>>>>>>> Ignite has dozens of the API that theoretically have a
>>>>>>>>>> usage
>>>>>>>>>>>>>>>>> scenario, but in real-world have 0 custom implementation and
>>>>>>>>>> usages.
>>>>>>>>>>>>>>>>>>>>>>>>>> Moreover, many APIs that were created with the intentions
>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>> mentioned is abandoned now and confuses users.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> You can just see count of the tests we just mute on the
>>>>>>>>>> TC.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Can you, please, take a look at the fix regarding puck API
>>>>>>>>>>>>>>>> issue
>>>>>>>>>>>>>>>>> you mentioned in your first letter [2], [3]
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-12553
>>>>>>>>>>>>>>>>>>>>>>>>>> [2] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/IGNITE-12552
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 12:12, Alexey Goncharuk <
>>>>>>>>>>>>>>>>> [hidden email]> написал(а):
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Nikolay,
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Why do you think this is a wrong usage pattern? From the
>>>>>>>>>>>> top
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> my head,
>>>>>>>>>>>>>>>>>>>>>>>>>>> here is a few cases of direct metric API usage that I
>>>>>>>>>> know
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>>>>>>>>>> being used in production:
>>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom task execution scheduling service with load
>>>>>>>>>>>>>>>>> balancing based on
>>>>>>>>>>>>>>>>>>>>>>>>>>> utilization metrics readings from Java code
>>>>>>>>>>>>>>>>>>>>>>>>>>> * Cleanup task trigger based on metrics readings
>>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom health-check endpoint for an application with
>>>>>>>>>> an
>>>>>>>>>>>>>>>>> embedded
>>>>>>>>>>>>>>>>>>>>>>>>>>> Ignite node for Kubernetes/Spring Application/etc
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>

[Maxim Muzafarov]

Folks,


I'm sorry for not being too attentive to the whole thread discussion
and maybe missing some details.

But... who will perform the review of [1] issue?
Will we merge it to 2.8? (hope so)


[1] https://issues.apache.org/jira/browse/IGNITE-12553
[IEP-35] public Java metric API

On Sat, 25 Jan 2020 at 11:43, Николай Ижиков <[hidden email]> wrote:

>
> Andrey.
>
> With this API we are trying to fill the GAP Alexey pointed out at the start of this discussion.
> I think it worth to be reviewed and merged.
>
> Can we, please, come back to the discussion of the changes itself?
> I think API changes should be discussed in the other thread.
>
> > Why do you think this is a wrong usage pattern? From the top of my head, here is a few cases of direct metric API usage that I know are currently being used in production:
> > * A custom task execution scheduling service with load balancing based on utilization metrics readings from Java code
> > * Cleanup task trigger based on metrics readings
> > * A custom health-check endpoint for an application with an embedded Ignite node for Kubernetes/Spring Application/etc
>
> [1] https://github.com/apache/ignite/pull/7283
>
> > 24 янв. 2020 г., в 18:08, Andrey Gura <[hidden email]> написал(а):
> >
> >> My point - that your contribution that took a long time, already, can’t be an argument to postpone creation of the API in the current release.
> >
> > Argument is not about time. But about API which is known will be changed.
> > Second argument: why we should add this experimental API to the
> > already existing experimental API? Just to making API more
> > experimental? As I told already it is commit for commit and doesn't
> > bring any value but brings some inconvenience to me (e.g. merge
> > problems).
> >
> > BTW, does it exist issue about marking IEP-35 API's as experimental?
> >
> > On Thu, Jan 23, 2020 at 8:33 PM Николай Ижиков <[hidden email]> wrote:
> >>
> >>> You want say didn't discuss?
> >>
> >> Yes.
> >>
> >>> Secondly, yes it took a lot of time due to a lot of changes. Is it problem?
> >>
> >> No, of course.
> >> My point - that your contribution that took a long time, already, can’t be an argument to postpone creation of the API in the current release.
> >>
> >>
> >>> 23 янв. 2020 г., в 18:11, Andrey Gura <[hidden email]> написал(а):
> >>>
> >>>> We don’t discuss your changes and your proposals for the Metric API.
> >>>
> >>> You want say didn't discuss? Actually we did it [1] but you told ok
> >>> let's see code :)
> >>>
> >>>> So I don’t think we can make the existence of some PR is an argument to introduce(or not introduce) this facade.
> >>>
> >>> You definitely right in case of competition development. But I think
> >>> that collaborative development is more effective. Isn't it?
> >>>
> >>>> Moreover, As far as I know, you developing changes for the Metric API for 5 months without public discussion, for now. Let's start it.
> >>>
> >>> Firsty, with discussion. See above.
> >>> Secondly, yes it took a lot of time due to a lot of changes. Is it problem?
> >>>
> >>>> Let’s do the following:
> >>>> 1. Review `IgniteMetric` facade and introduce it to the users as an experimental API.
> >>>
> >>> It just doesn't make sense. Just commit for commit.
> >>>
> >>>> 2. Discuss your proposal to the Metric API in the separate thread you are referencing.
> >>>
> >>> You a re welcome to thread [1] again. But please, take into account.
> >>> because discussion is postponed by you it's late enough to discuss
> >>> proposed solution. But of course I'll answer on your questions and
> >>> will be glade to your comments and suggestions.
> >>>
> >>>> I think we should start a discussion from the simplified explanation of:
> >>>> 1. API intentions - What we want to gain with it? What is our focus?
> >>>> 2. Simple, minimal example of API main interfaces and desired usages.
> >>>
> >>> All this already described at [1]. You also can take a look on PR (see
> >>> MetricSource implementations, there are complex and simple ones).
> >>>
> >>> [1] http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Metrics-management-in-Ignite-tp43243.html
> >>>
> >>> On Thu, Jan 23, 2020 at 5:42 PM Николай Ижиков <[hidden email]> wrote:
> >>>>
> >>>> Andrey.
> >>>>
> >>>>> IGNITE-11927 implementation so your changes are incompatible with my changes
> >>>>
> >>>> We don’t discuss your changes and your proposals for the Metric API.
> >>>> So I don’t think we can make the existence of some PR is an argument to introduce(or not introduce) this facade.
> >>>> Moreover, As far as I know, you developing changes for the Metric API for 5 months without public discussion, for now. Let's start it.
> >>>>
> >>>> Let’s do the following:
> >>>>
> >>>> 1. Review `IgniteMetric` facade and introduce it to the users as an experimental API.
> >>>>
> >>>> 2. Discuss your proposal to the Metric API in the separate thread you are referencing.
> >>>>
> >>>> I think we should start a discussion from the simplified explanation of:
> >>>>
> >>>> 1. API intentions - What we want to gain with it? What is our focus?
> >>>> 2. Simple, minimal example of API main interfaces and desired usages.
> >>>>
> >>>> This will help to the community and me personally better understand your idea and share feedback.
> >>>>
> >>>> Thanks.
> >>>>
> >>>>> 23 янв. 2020 г., в 17:15, Andrey Gura <[hidden email]> написал(а):
> >>>>>
> >>>>> Nikolay,
> >>>>>
> >>>>> as I wrote early in this thread API significantly changed during
> >>>>> IGNITE-11927 implementation so your changes are incompatible with my
> >>>>> changes.
> >>>>>
> >>>>> ReadOnlyMetricRegistry will be removed at all (still exists in a
> >>>>> couple of places where it uses).
> >>>>>
> >>>>> Also I don't want to introduce IgniteMetric facade in this rush. In
> >>>>> current implementation this interface just provides access to the
> >>>>> ReadOnlyMetricManager instance (which will be removed) but it is not
> >>>>> enough.
> >>>>>
> >>>>> I agree with Denis. We should mark current API as experimental and
> >>>>> continue IEP-35 development. See my process proposal [1] described
> >>>>> early this thread. We can release Apache Ignite 2.8.1 specially for
> >>>>> this changes.
> >>>>> Public APIs require deeper thinking in order to provide comprehensive,
> >>>>> consistent and convenient way of metrics management for end users.
> >>>>>
> >>>>> Let's add IgniteExperimental, release 2.8 and finish metrics related
> >>>>> issues after it.
> >>>>>
> >>>>> [1] http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-tp45146p45185.html
> >>>>>
> >>>>>
> >>>>> On Wed, Jan 22, 2020 at 5:21 PM Николай Ижиков <[hidden email]> wrote:
> >>>>>>
> >>>>>> Hello, Igniters.
> >>>>>>
> >>>>>> * IGNITE-12552: Move ReadOnlyMetricRegistry to public API merged to the master and cherry-picked to the 2.8.
> >>>>>> So the main issue with the Metric API solved.
> >>>>>>
> >>>>>> * I raised the PR [1] to fix second issue with the new Metric API: absence of the public Java API to get metrics.
> >>>>>> This PR introduces the following changes:
> >>>>>>
> >>>>>> 1. IgniteMetric interface created: it provides Java API to access Ignite metrics created with the new Metric API.
> >>>>>>
> >>>>>> ```
> >>>>>> public interface IgniteMetric extends Iterable<ReadOnlyMetricRegistry> {
> >>>>>>  @Nullable ReadOnlyMetricRegistry registry(String name);
> >>>>>> }
> >>>>>> ```
> >>>>>>
> >>>>>> 2. All deprecation javadocs regarding metrics now reference to the public IgniteMetric instead of internal GridMetricManager:
> >>>>>>
> >>>>>>> @deprecated Use {@link IgniteMetric} instead.
> >>>>>>
> >>>>>> 3. Tests refactored to use IgniteMetric instead of GridMetricManager when possible.
> >>>>>>
> >>>>>> Please, review.
> >>>>>>
> >>>>>> [1]  https://github.com/apache/ignite/pull/7283
> >>>>>>
> >>>>>>> 21 янв. 2020 г., в 17:51, Николай Ижиков <[hidden email]> написал(а):
> >>>>>>>
> >>>>>>> Hello, Igniters.
> >>>>>>>
> >>>>>>> Alexey approved my PR [1] regarding fixing public API for metric exporters.
> >>>>>>> I’m waiting for a bot visa and merge this PR.
> >>>>>>>
> >>>>>>> As we discussed, the metrics API will be marked with IgniteExperimental annotation.
> >>>>>>>
> >>>>>>> If anyone has any objection to this plan, please provide your feedback.
> >>>>>>>
> >>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>
> >>>>>>>> 21 янв. 2020 г., в 13:45, Николай Ижиков <[hidden email]> написал(а):
> >>>>>>>>
> >>>>>>>> Thanks, for the review Alexey.
> >>>>>>>>
> >>>>>>>> I will fix your comment and  try to implement Monitoring facade, shortly.
> >>>>>>>>
> >>>>>>>>> 21 янв. 2020 г., в 13:32, Alexey Goncharuk <[hidden email]> написал(а):
> >>>>>>>>>
> >>>>>>>>> Nikolay,
> >>>>>>>>>
> >>>>>>>>> I left a single comment in the PR about the histogram metric. I think the
> >>>>>>>>> API looks much cleaner now.
> >>>>>>>>>
> >>>>>>>>> I will take care of the @IgniteExperimental annotation.
> >>>>>>>>>
> >>>>>>>>> пн, 20 янв. 2020 г. в 20:55, Николай Ижиков <[hidden email]>:
> >>>>>>>>>
> >>>>>>>>>> Alexey.
> >>>>>>>>>>
> >>>>>>>>>> PR [1] is waiting for your review.
> >>>>>>>>>> Please, take a look.
> >>>>>>>>>>
> >>>>>>>>>> I think we should do the following before 2.8 release
> >>>>>>>>>>
> >>>>>>>>>> * Introduce new @IgniteExperimental annotation as discussed.
> >>>>>>>>>> * Mark Monitoring API with it.
> >>>>>>>>>> * merge «[IEP-35] Expose MetricRegistry to the public API» to 2.8
> >>>>>>>>>> * merge «[IEP-35] public Java metric API» to 2.8
> >>>>>>>>>>
> >>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>
> >>>>>>>>>>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk <[hidden email]>
> >>>>>>>>>> написал(а):
> >>>>>>>>>>>
> >>>>>>>>>>> Nikolay,
> >>>>>>>>>>>
> >>>>>>>>>>> Should we wait for both of the tickets given that we agreed that we are
> >>>>>>>>>>> putting an experimental marker on the new APIs? I'm ok to fix only the
> >>>>>>>>>>> first one and add the experimental marker so that we do not delay 2.8
> >>>>>>>>>>> release.
> >>>>>>>>>>>
> >>>>>>>>>>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков <[hidden email]>:
> >>>>>>>>>>>
> >>>>>>>>>>>> Andrey.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Let’s move from the long letters to the code.
> >>>>>>>>>>>> If you want to change API - please, propose this changes.
> >>>>>>>>>>>> I think everybody wins if we make our API better.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please, describe proposed changes.
> >>>>>>>>>>>> It would be great if you have some examples or PR for it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> As for this release, I have plans to contribute tickets
> >>>>>>>>>>>> «[IEP-35] Expose MetricRegistry to the public API» [1] and
> >>>>>>>>>>>> «[IEP-35] public Java metric API» [2] for it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Any objections on it?
> >>>>>>>>>>>>
> >>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-12553
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 20 янв. 2020 г., в 13:08, Andrey Gura <[hidden email]> написал(а):
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It solves problem.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
> >>>>>>>>>>>>> <[hidden email]> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> After giving it some thought, I agree with Denis - there is nothing
> >>>>>>>>>>>> wrong
> >>>>>>>>>>>>>> with exposing the new APIs, we just need to make it clear that we are
> >>>>>>>>>>>> still
> >>>>>>>>>>>>>> going to change it.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Should we Introduce something like @IgniteExperimental annotation (I
> >>>>>>>>>>>>>> believe it has been discussed a dozen of times on the dev-list)?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov <[hidden email]>:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> +1 to mark feature or whole release as EA.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> пт, 17 янв. 2020 г., 23:00 Denis Magda <[hidden email]>:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Folks, if you don't mind I'll share some thoughts/suggestions as an
> >>>>>>>>>>>>>>>> observer who was not involved in the feature development.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It's absolutely 'ok' to deprecate an API that is replaced with a
> >>>>>>>>>> much
> >>>>>>>>>>>>>>>> better version. However, we should do this only when the new APIs
> >>>>>>>>>> are
> >>>>>>>>>>>>>>>> production-ready. If there are still many limitations or open items
> >>>>>>>>>>>> then
> >>>>>>>>>>>>>>>> don't deprecate anything that exists and release the new APIs
> >>>>>>>>>>>> labeling as
> >>>>>>>>>>>>>>>> early access. What if release the improvements labeling as EA
> >>>>>>>>>> instead
> >>>>>>>>>>>> of
> >>>>>>>>>>>>>>>> hiding them completely?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I would also encourage us to put aside emotions, don't blame or
> >>>>>>>>>> point
> >>>>>>>>>>>>>>>> fingers. This IEP is a great initiative and you both have already
> >>>>>>>>>>>> done a
> >>>>>>>>>>>>>>>> tremendous job by developing, architecting and reviewing changes.
> >>>>>>>>>>>> Just be
> >>>>>>>>>>>>>>>> respectful. Nobody is trying to block the feature from being
> >>>>>>>>>> released.
> >>>>>>>>>>>>>>>> Everyone would be glad to tap into improvements and start using them
> >>>>>>>>>>>> in
> >>>>>>>>>>>>>>>> prod. But if more time is needed for the GA let's reiterate a bit.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>> Denis
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков <
> >>>>>>>>>> [hidden email]>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Also I agree with Alexey about introducing public IgniteMonitoring
> >>>>>>>>>>>>>>>> facade
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> This is not an issue with the API.
> >>>>>>>>>>>>>>>>> Just the new feature that doesn’t affects API.
> >>>>>>>>>>>>>>>>> Moreover, I create a ticket to fix it, already.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
> >>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>> test will fail. It's just not good tests.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> My changes doesn’t affect any `staticticsEnabled` property.
> >>>>>>>>>>>>>>>>> I don’ understand your point here.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> It’s not redundant.
> >>>>>>>>>>>>>>>>> It required for exporters and provide read only access to
> >>>>>>>>>>>>>>> MetricRegistry
> >>>>>>>>>>>>>>>>> existing in the node.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
> >>>>>>>>>> use
> >>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Why this is issue?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> It’s consistent.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct reference
> >>>>>>>>>>>>>>>>>> (performance problem).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 1. We(You and I) did this choice together to simplify creation of
> >>>>>>>>>> the
> >>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>> metrics.
> >>>>>>>>>>>>>>>>> 2. This is not public API issue.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I don’t ignore this flag.
> >>>>>>>>>>>>>>>>> It just doesn’t exists in new framework(because of scope).
> >>>>>>>>>>>>>>>>> I don’t think it’s an issue.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
> >>>>>>>>>>>>>>>> practices.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Please, clarify your statement.
> >>>>>>>>>>>>>>>>> What is best MBeans practices you are talking about?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> How this can be API issue?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 20:52, Andrey Gura <[hidden email]>
> >>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
> >>>>>>>>>>>> PR
> >>>>>>>>>>>>>>>>> [1].
> >>>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
> >>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> As I mentioned already IGNITE-11927 is part of IEP-35 and
> >>>>>>>>>>>>>>>>>> implementation seriously affects API's. Also I agree with Alexey
> >>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>>>> introducing public IgniteMonitoring facade. So thiss PR doesn't
> >>>>>>>>>> fix
> >>>>>>>>>>>>>>>>>> all issues.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
> >>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It's right. But if you add checking of statisticsEnabling property
> >>>>>>>>>>>>>>>>>> then test will fail. It's just not good tests.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
> >>>>>>>>>> will
> >>>>>>>>>>>>>>>> fix
> >>>>>>>>>>>>>>>>> it ASAP.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I already fix it all in IGNITE-11927
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't hide major
> >>>>>>>>>>>>>>>>> contribution from the user just because your second guess «I don’t
> >>>>>>>>>>>> like
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> API I just reviewed and approved».
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> We should move the product forward with with really finished
> >>>>>>>>>>>>>>> features,
> >>>>>>>>>>>>>>>>>> not pieces of features.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> So I am against this proposal.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It is not argument.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
> >>>>>>>>>> discuss
> >>>>>>>>>>>>>>>> them.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> We can prepare it together. But we can't block release.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> >>>>>>>>>>>>>>>>>>> What is *ALL* problems?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>>>> MetricExporterSpi that requires ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that forces user
> >>>>>>>>>> use
> >>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> >>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
> >>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct reference
> >>>>>>>>>>>>>>>>>> (performance problem).
> >>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> >>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy best MBeans
> >>>>>>>>>>>>>>>> practices.
> >>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It's enough I believe.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:28 PM Николай Ижиков <
> >>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Andrey.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are fixed with my
> >>>>>>>>>> PR
> >>>>>>>>>>>>>>>> [1].
> >>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker for the
> >>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this contribution.
> >>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create a ticket I
> >>>>>>>>>> will
> >>>>>>>>>>>>>>>> fix
> >>>>>>>>>>>>>>>>> it ASAP.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't hide major
> >>>>>>>>>>>>>>>>> contribution from the user just because your second guess «I don’t
> >>>>>>>>>>>> like
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> API I just reviewed and approved».
> >>>>>>>>>>>>>>>>>>> So I am against this proposal.
> >>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API change and
> >>>>>>>>>> discuss
> >>>>>>>>>>>>>>>> them.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> What is *ALL* problems?
> >>>>>>>>>>>>>>>>>>> Seems, we never be able to solve *ALL* problems.
> >>>>>>>>>>>>>>>>>>> But, we should move the product forward.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> As for your steps [1-6].
> >>>>>>>>>>>>>>>>>>> I’m always following these steps during my contribution.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 19:08, Andrey Gura <[hidden email]>
> >>>>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> The discussion is hot and can be endless. So in separate post I
> >>>>>>>>>>>>>>> want
> >>>>>>>>>>>>>>>>>>>> propose my solution.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>>>>>>>> 2. Create special feature branch B.
> >>>>>>>>>>>>>>>>>>>> 3. In branch B will be merged IGNITE-11927
> >>>>>>>>>>>>>>>>>>>> 4. Because IGNITE-11927 doesn't solve all problems we should
> >>>>>>>>>>>>>>> propose
> >>>>>>>>>>>>>>>>>>>> solution and implement it in branch B.
> >>>>>>>>>>>>>>>>>>>> 5. Testing, usability testing, fixing, etc iteratively.
> >>>>>>>>>>>>>>>>>>>> 6. Merge it to master and in new release branch if needed.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Independent step. There are some problem which should be fixed
> >>>>>>>>>> in
> >>>>>>>>>>>>>>> 2.8
> >>>>>>>>>>>>>>>>>>>> before release otherwise we introduce problems with
> >>>>>>>>>> compatibility
> >>>>>>>>>>>>>>>>>>>> which will haunt us till next major release. I'll create
> >>>>>>>>>> tickets.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:03 PM Andrey Gura <[hidden email]>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
> >>>>>>>>>>>> code.
> >>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> >>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
> >>>>>>>>>>>> major
> >>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> We don't know anything about development processes our users. I
> >>>>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>>>>>>> admit that process could require that deprecated methods/APIs
> >>>>>>>>>> are
> >>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>> allowed for example.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
> >>>>>>>>>> don't
> >>>>>>>>>>>>>>>> give
> >>>>>>>>>>>>>>>>> me any information about it’s purpose and responsibilities.
> >>>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I understand this. But I'm not Ignite user, I'm Ignite
> >>>>>>>>>> developer.
> >>>>>>>>>>>>>>>> The
> >>>>>>>>>>>>>>>>>>>>> key moment in my message *from user stand point*. From my point
> >>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>> view it is very not intuitive solution and this interface is
> >>>>>>>>>>>>>>>>>>>>> redundant.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
> >>>>>>>>>> example.
> >>>>>>>>>>>>>>>>> There are other entities with such flag.
> >>>>>>>>>>>>>>>>>>>>>> They still works as expected.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Actually not. I fixed many such issues during IGNITE-11927
> >>>>>>>>>>>>>>>>> implementation.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
> >>>>>>>>>>>>>>>>>>>>>> Because of the scope.
> >>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
> >>>>>>>>>> other
> >>>>>>>>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I talk not about ability. I talk about ignored existing
> >>>>>>>>>>>>>>>> functionality.
> >>>>>>>>>>>>>>>>>>>>> So scope is not case here.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
> >>>>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
> >>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
> >>>>>>>>>> exporter
> >>>>>>>>>>>>>>>>> can’t.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Actually list is not metric at all as I already told.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 5:26 PM Николай Ижиков <
> >>>>>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Andrey.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires rewrite client
> >>>>>>>>>>>> code.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> >>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove in the next
> >>>>>>>>>>>> major
> >>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange interface which
> >>>>>>>>>> don't
> >>>>>>>>>>>>>>>> give
> >>>>>>>>>>>>>>>>> me any information about it’s purpose and responsibilities.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more clear:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Each SPI would have a `ReadOnlyMetricManager` which provides
> >>>>>>>>>>>>>>> access
> >>>>>>>>>>>>>>>>> to collection of `ReadOnlyMetricRegistry`
> >>>>>>>>>>>>>>>>>>>>>> which has a collection of `Metric`.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> So we reflects two-level structure we have in the internal API
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> GridMetricManager -> Collection[MetricRegistry] ->
> >>>>>>>>>>>>>>>> Collection[Metric]
> >>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricManager -> Collection[ReadOnlyMetricRegistry] ->
> >>>>>>>>>>>>>>>>> Collection[Metric]
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
> >>>>>>>>>> example.
> >>>>>>>>>>>>>>>>> There are other entities with such flag.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> They still works as expected.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Because of the scope.
> >>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the matter of the
> >>>>>>>>>> other
> >>>>>>>>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by MetricExporterSpi
> >>>>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter to decide.
> >>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while OpenCensus
> >>>>>>>>>> exporter
> >>>>>>>>>>>>>>>>> can’t.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>> https://github.com/apache/ignite/pull/7269/files#diff-0ae5657231fc4c1f650493b02190b81bR25
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 16:57, Andrey Gura <[hidden email]>
> >>>>>>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
> >>>>>>>>>>>>>>>> reviewers
> >>>>>>>>>>>>>>>>> of the Metric API.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Yes. But if I'm not missing some thing you were major
> >>>>>>>>>> developer
> >>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>> Metric API :) Shit happens. And it happened.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
> >>>>>>>>>> that
> >>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
> >>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> There is such concept - backward compatibility. I understand
> >>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>> deprecation of some interface doesn't break backward
> >>>>>>>>>>>>>>> compatibility
> >>>>>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>>>>>>>>> it leads to question^ what should I use instead of this. And
> >>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi is not answer for this question. Because it
> >>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>> brand
> >>>>>>>>>>>>>>>>>>>>>>> new API and it requires rewrite client code.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> >>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
> >>>>>>>>>> the
> >>>>>>>>>>>>>>>>> exporters.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> No it is not. It's completely artificial thing which allow
> >>>>>>>>>>>>>>> iterate
> >>>>>>>>>>>>>>>>> via
> >>>>>>>>>>>>>>>>>>>>>>> all metric registries. GridMetricManager implements this
> >>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>> while it is not metric registry. Form user stand point it is
> >>>>>>>>>>>>>>> very
> >>>>>>>>>>>>>>>>>>>>>>> strange interface which don't give me any information about
> >>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>>>>>> purpose and responsibilities.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> >>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for caches for
> >>>>>>>>>> example.
> >>>>>>>>>>>>>>>>> There
> >>>>>>>>>>>>>>>>>>>>>>> are other entities with such flag.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way? Why you ignore existing
> >>>>>>>>>>>>>>>>>>>>>>> functionality? It affects user expectations and experience.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Yes? I'm working. Unfortunately we are not synchronized in
> >>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>>>> context and I should redo all metrics related changes in
> >>>>>>>>>> order
> >>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>> merge it with my changes. Anyway, my change doesn't solve all
> >>>>>>>>>>>>>>>>> problems
> >>>>>>>>>>>>>>>>>>>>>>> (e.g. it doesn't introduce IgniteMonitoring facade).
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Unfortunately it will be just fix. In my solution it is
> >>>>>>>>>>>>>>> redesign.
> >>>>>>>>>>>>>>>>> Stop
> >>>>>>>>>>>>>>>>>>>>>>> fixing issues, let's do things. It requires deeper changes.
> >>>>>>>>>> My
> >>>>>>>>>>>>>>>>> changes
> >>>>>>>>>>>>>>>>>>>>>>> blocks AI 2.8 release because it big enough. So it retargeted
> >>>>>>>>>>>> on
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> next release. And it is one more reason for moving the
> >>>>>>>>>> changes
> >>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> internal packages. And it isn't good news for me because I
> >>>>>>>>>> will
> >>>>>>>>>>>>>>> go
> >>>>>>>>>>>>>>>>>>>>>>> throughout pan and tiers of merge. But it is right.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Yes, I know. But they should not be exported by
> >>>>>>>>>>>>>>> MetricExporterSpi
> >>>>>>>>>>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 3:37 PM Николай Ижиков <
> >>>>>>>>>>>>>>>> [hidden email]>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Andrey, thanks for your opinion and your ownest critisism.
> >>>>>>>>>>>>>>>>>>>>>>>> I can’t wait for your contribution.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of the active
> >>>>>>>>>>>>>>>> reviewers
> >>>>>>>>>>>>>>>>> of the Metric API.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
> >>>>>>>>>> that
> >>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
> >>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still not-production ready.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> It’s ready.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
> >>>>>>>>>> doesn't
> >>>>>>>>>>>>>>>>> solve the problem because this interface exposes internal Metric
> >>>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Not, its’ not.
> >>>>>>>>>>>>>>>>>>>>>>>> Please, see `org.apache.ignite.spi.metric.LongMetric` and
> >>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>> public interface.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> API of MetricRegistry is inconsistent.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> MetricRegistry is the internal API.
> >>>>>>>>>>>>>>>>>>>>>>>> Feel free to create ticket for an issues with it and I will
> >>>>>>>>>>>> try
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> fix it.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal MetricRegistry  to
> >>>>>>>>>> the
> >>>>>>>>>>>>>>>>> exporters.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> >>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
> >>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> >>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward compatibility.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 15:09, Andrey Gura <[hidden email]>
> >>>>>>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about deprecation of APIs
> >>>>>>>>>> that
> >>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable substitution.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't recommend
> >>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still not-production
> >>>>>>>>>>>> ready.
> >>>>>>>>>>>>>>>>> There
> >>>>>>>>>>>>>>>>>>>>>>>>> are some issues with it and usage of ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>>>> just one of them.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the public API
> >>>>>>>>>> doesn't
> >>>>>>>>>>>>>>>>> solve
> >>>>>>>>>>>>>>>>>>>>>>>>> the problem because this interface exposes internal Metric
> >>>>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>>>> implementations. So your PR is incomplete.
> >>>>>>>>>>>>>>>>>>>>>>>>> Moreover, API of MetricRegistry is inconsistent. E.g.
> >>>>>>>>>>>>>>>>> register(name,
> >>>>>>>>>>>>>>>>>>>>>>>>> supplier, desc) method returns registered metric for some
> >>>>>>>>>>>>>>> types
> >>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>> doesn't for other. register(metric) method is inconsistent
> >>>>>>>>>> in
> >>>>>>>>>>>>>>>>> sense of
> >>>>>>>>>>>>>>>>>>>>>>>>> metric naming. ReadOnlyMetricRegistry interface is
> >>>>>>>>>> redundant.
> >>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi should be revised because it absolutely
> >>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>>> intuitive because it requires ReadOnlyMetricRegistry and
> >>>>>>>>>> it's
> >>>>>>>>>>>>>>>>> purpose
> >>>>>>>>>>>>>>>>>>>>>>>>> is undefined.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> One more point. IEP-35 is still not fully implemented. Some
> >>>>>>>>>>>>>>>>> things are
> >>>>>>>>>>>>>>>>>>>>>>>>> not taken into account. Exporters expose metrics if they
> >>>>>>>>>> are
> >>>>>>>>>>>>>>>>> disabled.
> >>>>>>>>>>>>>>>>>>>>>>>>> JMX beans exposes values that don't confirm to best
> >>>>>>>>>> practices
> >>>>>>>>>>>>>>>> [1].
> >>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all. Ubiquitous
> >>>>>>>>>>>> merics
> >>>>>>>>>>>>>>>>> lookup
> >>>>>>>>>>>>>>>>>>>>>>>>> from hash map instead of usage reference for getting
> >>>>>>>>>> metrics
> >>>>>>>>>>>>>>>>> values
> >>>>>>>>>>>>>>>>>>>>>>>>> (it is just performance issue). Also IGNITE-11927 is not
> >>>>>>>>>>>>>>>>> implemented
> >>>>>>>>>>>>>>>>>>>>>>>>> which also changes interfaces significantly.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Let's just admit that the implementation is immature and
> >>>>>>>>>> must
> >>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>> moved
> >>>>>>>>>>>>>>>>>>>>>>>>> to the internal packages.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> And because we already merged partially implemented IEP to
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> master
> >>>>>>>>>>>>>>>>>>>>>>>>> branch we *must move all currently public APIs to the
> >>>>>>>>>>>> internal
> >>>>>>>>>>>>>>>>> API*
> >>>>>>>>>>>>>>>>>>>>>>>>> while it will not be ready for publication.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> And the last but not least. What is happening indicates a
> >>>>>>>>>>>>>>>> immature
> >>>>>>>>>>>>>>>>>>>>>>>>> development process which must be revised. I don't want
> >>>>>>>>>>>>>>> discuss
> >>>>>>>>>>>>>>>>> it in
> >>>>>>>>>>>>>>>>>>>>>>>>> this thread but we must not allow merge of change to the
> >>>>>>>>>>>>>>> master
> >>>>>>>>>>>>>>>>> branch
> >>>>>>>>>>>>>>>>>>>>>>>>> before it will completed, that is we must use feature
> >>>>>>>>>>>> branches
> >>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>>> full IEP not only for particular tickets. And also we
> >>>>>>>>>> should
> >>>>>>>>>>>>>>>>>>>>>>>>> reformulate IEP process in order to avoid things like this.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>> https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:49 PM Николай Ижиков <
> >>>>>>>>>>>>>>>>> [hidden email]> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Alex.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, I may leverage your experience and create pure Java
> >>>>>>>>>> API.
> >>>>>>>>>>>>>>>>>>>>>>>>>> Ticket [1] created.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> But, personally, I don’t agree with you.
> >>>>>>>>>>>>>>>>>>>>>>>>>> Ignite has dozens of the API that theoretically have a
> >>>>>>>>>> usage
> >>>>>>>>>>>>>>>>> scenario, but in real-world have 0 custom implementation and
> >>>>>>>>>> usages.
> >>>>>>>>>>>>>>>>>>>>>>>>>> Moreover, many APIs that were created with the intentions
> >>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>> mentioned is abandoned now and confuses users.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> You can just see count of the tests we just mute on the
> >>>>>>>>>> TC.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Can you, please, take a look at the fix regarding puck API
> >>>>>>>>>>>>>>>> issue
> >>>>>>>>>>>>>>>>> you mentioned in your first letter [2], [3]
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-12553
> >>>>>>>>>>>>>>>>>>>>>>>>>> [2] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/IGNITE-12552
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 12:12, Alexey Goncharuk <
> >>>>>>>>>>>>>>>>> [hidden email]> написал(а):
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Nikolay,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Why do you think this is a wrong usage pattern? From the
> >>>>>>>>>>>> top
> >>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>> my head,
> >>>>>>>>>>>>>>>>>>>>>>>>>>> here is a few cases of direct metric API usage that I
> >>>>>>>>>> know
> >>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>> currently
> >>>>>>>>>>>>>>>>>>>>>>>>>>> being used in production:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom task execution scheduling service with load
> >>>>>>>>>>>>>>>>> balancing based on
> >>>>>>>>>>>>>>>>>>>>>>>>>>> utilization metrics readings from Java code
> >>>>>>>>>>>>>>>>>>>>>>>>>>> * Cleanup task trigger based on metrics readings
> >>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom health-check endpoint for an application with
> >>>>>>>>>> an
> >>>>>>>>>>>>>>>>> embedded
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Ignite node for Kubernetes/Spring Application/etc
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
>

[Alexey Goncharuk]

Nikolay,

I've reviewed your changes and I tend to agree with Andrey, it's better to
remove deprecation for the old APIs in AI 2.8 and discuss and merge the new
facade (IGNITE-12553) in a more calm and structured way. My observations on
the changes:

   - I am not sure if Iterable would suffice both for the exporter and
   public APIs. Should we provide a way to know the number of metrics and
   registries in advance? Let's say I am writing a custom exporter in binary
   format and I need to write the number of exported metrics in a packet
   beforehand.
   - There is no separation on public and internal metrics, when public
   metrics preserve their name and semantics, and internal metrics may change.
   I remember we discussed this, but it's not reflected in the APIs in any way.
   - Will we allow users to register their own metrics? Again I remember we
   discussed a possibility for this. If so, why the registry is called
   'ReadyOnly'?
   - It's still not clear how a user will map old interfaces and methods to
   the new metric names.

As you can see in the original message, I am not pushing for the new APIs
in the nearest release, I just want to remove the deprecations on the
classes for which there is no a well-defined replacement.

пн, 27 янв. 2020 г. в 15:56, Maxim Muzafarov <[hidden email]>:

> Folks,
>
>
> I'm sorry for not being too attentive to the whole thread discussion
> and maybe missing some details.
>
> But... who will perform the review of [1] issue?
> Will we merge it to 2.8? (hope so)
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12553
> [IEP-35] public Java metric API
>
> On Sat, 25 Jan 2020 at 11:43, Николай Ижиков <[hidden email]> wrote:
> >
> > Andrey.
> >
> > With this API we are trying to fill the GAP Alexey pointed out at the
> start of this discussion.
> > I think it worth to be reviewed and merged.
> >
> > Can we, please, come back to the discussion of the changes itself?
> > I think API changes should be discussed in the other thread.
> >
> > > Why do you think this is a wrong usage pattern? From the top of my
> head, here is a few cases of direct metric API usage that I know are
> currently being used in production:
> > > * A custom task execution scheduling service with load balancing based
> on utilization metrics readings from Java code
> > > * Cleanup task trigger based on metrics readings
> > > * A custom health-check endpoint for an application with an embedded
> Ignite node for Kubernetes/Spring Application/etc
> >
> > [1] https://github.com/apache/ignite/pull/7283
> >
> > > 24 янв. 2020 г., в 18:08, Andrey Gura <[hidden email]> написал(а):
> > >
> > >> My point - that your contribution that took a long time, already,
> can’t be an argument to postpone creation of the API in the current release.
> > >
> > > Argument is not about time. But about API which is known will be
> changed.
> > > Second argument: why we should add this experimental API to the
> > > already existing experimental API? Just to making API more
> > > experimental? As I told already it is commit for commit and doesn't
> > > bring any value but brings some inconvenience to me (e.g. merge
> > > problems).
> > >
> > > BTW, does it exist issue about marking IEP-35 API's as experimental?
> > >
> > > On Thu, Jan 23, 2020 at 8:33 PM Николай Ижиков <[hidden email]>
> wrote:
> > >>
> > >>> You want say didn't discuss?
> > >>
> > >> Yes.
> > >>
> > >>> Secondly, yes it took a lot of time due to a lot of changes. Is it
> problem?
> > >>
> > >> No, of course.
> > >> My point - that your contribution that took a long time, already,
> can’t be an argument to postpone creation of the API in the current release.
> > >>
> > >>
> > >>> 23 янв. 2020 г., в 18:11, Andrey Gura <[hidden email]> написал(а):
> > >>>
> > >>>> We don’t discuss your changes and your proposals for the Metric API.
> > >>>
> > >>> You want say didn't discuss? Actually we did it [1] but you told ok
> > >>> let's see code :)
> > >>>
> > >>>> So I don’t think we can make the existence of some PR is an
> argument to introduce(or not introduce) this facade.
> > >>>
> > >>> You definitely right in case of competition development. But I think
> > >>> that collaborative development is more effective. Isn't it?
> > >>>
> > >>>> Moreover, As far as I know, you developing changes for the Metric
> API for 5 months without public discussion, for now. Let's start it.
> > >>>
> > >>> Firsty, with discussion. See above.
> > >>> Secondly, yes it took a lot of time due to a lot of changes. Is it
> problem?
> > >>>
> > >>>> Let’s do the following:
> > >>>> 1. Review `IgniteMetric` facade and introduce it to the users as an
> experimental API.
> > >>>
> > >>> It just doesn't make sense. Just commit for commit.
> > >>>
> > >>>> 2. Discuss your proposal to the Metric API in the separate thread
> you are referencing.
> > >>>
> > >>> You a re welcome to thread [1] again. But please, take into account.
> > >>> because discussion is postponed by you it's late enough to discuss
> > >>> proposed solution. But of course I'll answer on your questions and
> > >>> will be glade to your comments and suggestions.
> > >>>
> > >>>> I think we should start a discussion from the simplified
> explanation of:
> > >>>> 1. API intentions - What we want to gain with it? What is our focus?
> > >>>> 2. Simple, minimal example of API main interfaces and desired
> usages.
> > >>>
> > >>> All this already described at [1]. You also can take a look on PR
> (see
> > >>> MetricSource implementations, there are complex and simple ones).
> > >>>
> > >>> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Metrics-management-in-Ignite-tp43243.html
> > >>>
> > >>> On Thu, Jan 23, 2020 at 5:42 PM Николай Ижиков <[hidden email]>
> wrote:
> > >>>>
> > >>>> Andrey.
> > >>>>
> > >>>>> IGNITE-11927 implementation so your changes are incompatible with
> my changes
> > >>>>
> > >>>> We don’t discuss your changes and your proposals for the Metric API.
> > >>>> So I don’t think we can make the existence of some PR is an
> argument to introduce(or not introduce) this facade.
> > >>>> Moreover, As far as I know, you developing changes for the Metric
> API for 5 months without public discussion, for now. Let's start it.
> > >>>>
> > >>>> Let’s do the following:
> > >>>>
> > >>>> 1. Review `IgniteMetric` facade and introduce it to the users as an
> experimental API.
> > >>>>
> > >>>> 2. Discuss your proposal to the Metric API in the separate thread
> you are referencing.
> > >>>>
> > >>>> I think we should start a discussion from the simplified
> explanation of:
> > >>>>
> > >>>> 1. API intentions - What we want to gain with it? What is our focus?
> > >>>> 2. Simple, minimal example of API main interfaces and desired
> usages.
> > >>>>
> > >>>> This will help to the community and me personally better understand
> your idea and share feedback.
> > >>>>
> > >>>> Thanks.
> > >>>>
> > >>>>> 23 янв. 2020 г., в 17:15, Andrey Gura <[hidden email]>
> написал(а):
> > >>>>>
> > >>>>> Nikolay,
> > >>>>>
> > >>>>> as I wrote early in this thread API significantly changed during
> > >>>>> IGNITE-11927 implementation so your changes are incompatible with
> my
> > >>>>> changes.
> > >>>>>
> > >>>>> ReadOnlyMetricRegistry will be removed at all (still exists in a
> > >>>>> couple of places where it uses).
> > >>>>>
> > >>>>> Also I don't want to introduce IgniteMetric facade in this rush. In
> > >>>>> current implementation this interface just provides access to the
> > >>>>> ReadOnlyMetricManager instance (which will be removed) but it is
> not
> > >>>>> enough.
> > >>>>>
> > >>>>> I agree with Denis. We should mark current API as experimental and
> > >>>>> continue IEP-35 development. See my process proposal [1] described
> > >>>>> early this thread. We can release Apache Ignite 2.8.1 specially for
> > >>>>> this changes.
> > >>>>> Public APIs require deeper thinking in order to provide
> comprehensive,
> > >>>>> consistent and convenient way of metrics management for end users.
> > >>>>>
> > >>>>> Let's add IgniteExperimental, release 2.8 and finish metrics
> related
> > >>>>> issues after it.
> > >>>>>
> > >>>>> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-tp45146p45185.html
> > >>>>>
> > >>>>>
> > >>>>> On Wed, Jan 22, 2020 at 5:21 PM Николай Ижиков <
> [hidden email]> wrote:
> > >>>>>>
> > >>>>>> Hello, Igniters.
> > >>>>>>
> > >>>>>> * IGNITE-12552: Move ReadOnlyMetricRegistry to public API merged
> to the master and cherry-picked to the 2.8.
> > >>>>>> So the main issue with the Metric API solved.
> > >>>>>>
> > >>>>>> * I raised the PR [1] to fix second issue with the new Metric
> API: absence of the public Java API to get metrics.
> > >>>>>> This PR introduces the following changes:
> > >>>>>>
> > >>>>>> 1. IgniteMetric interface created: it provides Java API to access
> Ignite metrics created with the new Metric API.
> > >>>>>>
> > >>>>>> ```
> > >>>>>> public interface IgniteMetric extends
> Iterable<ReadOnlyMetricRegistry> {
> > >>>>>>  @Nullable ReadOnlyMetricRegistry registry(String name);
> > >>>>>> }
> > >>>>>> ```
> > >>>>>>
> > >>>>>> 2. All deprecation javadocs regarding metrics now reference to
> the public IgniteMetric instead of internal GridMetricManager:
> > >>>>>>
> > >>>>>>> @deprecated Use {@link IgniteMetric} instead.
> > >>>>>>
> > >>>>>> 3. Tests refactored to use IgniteMetric instead of
> GridMetricManager when possible.
> > >>>>>>
> > >>>>>> Please, review.
> > >>>>>>
> > >>>>>> [1]  https://github.com/apache/ignite/pull/7283
> > >>>>>>
> > >>>>>>> 21 янв. 2020 г., в 17:51, Николай Ижиков <[hidden email]>
> написал(а):
> > >>>>>>>
> > >>>>>>> Hello, Igniters.
> > >>>>>>>
> > >>>>>>> Alexey approved my PR [1] regarding fixing public API for metric
> exporters.
> > >>>>>>> I’m waiting for a bot visa and merge this PR.
> > >>>>>>>
> > >>>>>>> As we discussed, the metrics API will be marked with
> IgniteExperimental annotation.
> > >>>>>>>
> > >>>>>>> If anyone has any objection to this plan, please provide your
> feedback.
> > >>>>>>>
> > >>>>>>> [1] https://github.com/apache/ignite/pull/7269
> > >>>>>>>
> > >>>>>>>> 21 янв. 2020 г., в 13:45, Николай Ижиков <
> [hidden email]> написал(а):
> > >>>>>>>>
> > >>>>>>>> Thanks, for the review Alexey.
> > >>>>>>>>
> > >>>>>>>> I will fix your comment and  try to implement Monitoring
> facade, shortly.
> > >>>>>>>>
> > >>>>>>>>> 21 янв. 2020 г., в 13:32, Alexey Goncharuk <
> [hidden email]> написал(а):
> > >>>>>>>>>
> > >>>>>>>>> Nikolay,
> > >>>>>>>>>
> > >>>>>>>>> I left a single comment in the PR about the histogram metric.
> I think the
> > >>>>>>>>> API looks much cleaner now.
> > >>>>>>>>>
> > >>>>>>>>> I will take care of the @IgniteExperimental annotation.
> > >>>>>>>>>
> > >>>>>>>>> пн, 20 янв. 2020 г. в 20:55, Николай Ижиков <
> [hidden email]>:
> > >>>>>>>>>
> > >>>>>>>>>> Alexey.
> > >>>>>>>>>>
> > >>>>>>>>>> PR [1] is waiting for your review.
> > >>>>>>>>>> Please, take a look.
> > >>>>>>>>>>
> > >>>>>>>>>> I think we should do the following before 2.8 release
> > >>>>>>>>>>
> > >>>>>>>>>> * Introduce new @IgniteExperimental annotation as discussed.
> > >>>>>>>>>> * Mark Monitoring API with it.
> > >>>>>>>>>> * merge «[IEP-35] Expose MetricRegistry to the public API» to
> 2.8
> > >>>>>>>>>> * merge «[IEP-35] public Java metric API» to 2.8
> > >>>>>>>>>>
> > >>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> > >>>>>>>>>>
> > >>>>>>>>>>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk <
> [hidden email]>
> > >>>>>>>>>> написал(а):
> > >>>>>>>>>>>
> > >>>>>>>>>>> Nikolay,
> > >>>>>>>>>>>
> > >>>>>>>>>>> Should we wait for both of the tickets given that we agreed
> that we are
> > >>>>>>>>>>> putting an experimental marker on the new APIs? I'm ok to
> fix only the
> > >>>>>>>>>>> first one and add the experimental marker so that we do not
> delay 2.8
> > >>>>>>>>>>> release.
> > >>>>>>>>>>>
> > >>>>>>>>>>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков <
> [hidden email]>:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Andrey.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Let’s move from the long letters to the code.
> > >>>>>>>>>>>> If you want to change API - please, propose this changes.
> > >>>>>>>>>>>> I think everybody wins if we make our API better.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Please, describe proposed changes.
> > >>>>>>>>>>>> It would be great if you have some examples or PR for it.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> As for this release, I have plans to contribute tickets
> > >>>>>>>>>>>> «[IEP-35] Expose MetricRegistry to the public API» [1] and
> > >>>>>>>>>>>> «[IEP-35] public Java metric API» [2] for it.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Any objections on it?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> > >>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-12553
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> 20 янв. 2020 г., в 13:08, Andrey Gura <[hidden email]>
> написал(а):
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> It solves problem.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
> > >>>>>>>>>>>>> <[hidden email]> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> After giving it some thought, I agree with Denis - there
> is nothing
> > >>>>>>>>>>>> wrong
> > >>>>>>>>>>>>>> with exposing the new APIs, we just need to make it clear
> that we are
> > >>>>>>>>>>>> still
> > >>>>>>>>>>>>>> going to change it.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Should we Introduce something like @IgniteExperimental
> annotation (I
> > >>>>>>>>>>>>>> believe it has been discussed a dozen of times on the
> dev-list)?
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov <
> [hidden email]>:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> +1 to mark feature or whole release as EA.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> пт, 17 янв. 2020 г., 23:00 Denis Magda <
> [hidden email]>:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Folks, if you don't mind I'll share some
> thoughts/suggestions as an
> > >>>>>>>>>>>>>>>> observer who was not involved in the feature
> development.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> It's absolutely 'ok' to deprecate an API that is
> replaced with a
> > >>>>>>>>>> much
> > >>>>>>>>>>>>>>>> better version. However, we should do this only when
> the new APIs
> > >>>>>>>>>> are
> > >>>>>>>>>>>>>>>> production-ready. If there are still many limitations
> or open items
> > >>>>>>>>>>>> then
> > >>>>>>>>>>>>>>>> don't deprecate anything that exists and release the
> new APIs
> > >>>>>>>>>>>> labeling as
> > >>>>>>>>>>>>>>>> early access. What if release the improvements labeling
> as EA
> > >>>>>>>>>> instead
> > >>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>> hiding them completely?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> I would also encourage us to put aside emotions, don't
> blame or
> > >>>>>>>>>> point
> > >>>>>>>>>>>>>>>> fingers. This IEP is a great initiative and you both
> have already
> > >>>>>>>>>>>> done a
> > >>>>>>>>>>>>>>>> tremendous job by developing, architecting and
> reviewing changes.
> > >>>>>>>>>>>> Just be
> > >>>>>>>>>>>>>>>> respectful. Nobody is trying to block the feature from
> being
> > >>>>>>>>>> released.
> > >>>>>>>>>>>>>>>> Everyone would be glad to tap into improvements and
> start using them
> > >>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>> prod. But if more time is needed for the GA let's
> reiterate a bit.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> -
> > >>>>>>>>>>>>>>>> Denis
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков <
> > >>>>>>>>>> [hidden email]>
> > >>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Also I agree with Alexey about introducing public
> IgniteMonitoring
> > >>>>>>>>>>>>>>>> facade
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> This is not an issue with the API.
> > >>>>>>>>>>>>>>>>> Just the new feature that doesn’t affects API.
> > >>>>>>>>>>>>>>>>> Moreover, I create a ticket to fix it, already.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> It's right. But if you add checking of
> statisticsEnabling property
> > >>>>>>>>>>>>>>> then
> > >>>>>>>>>>>>>>>>> test will fail. It's just not good tests.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> My changes doesn’t affect any `staticticsEnabled`
> property.
> > >>>>>>>>>>>>>>>>> I don’ understand your point here.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> It’s not redundant.
> > >>>>>>>>>>>>>>>>> It required for exporters and provide read only access
> to
> > >>>>>>>>>>>>>>> MetricRegistry
> > >>>>>>>>>>>>>>>>> existing in the node.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> MetricExporterSpi that requires
> ReadOnlyMetricRegistry.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that
> forces user
> > >>>>>>>>>> use
> > >>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Why this is issue?
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> It’s consistent.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct
> reference
> > >>>>>>>>>>>>>>>>>> (performance problem).
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> 1. We(You and I) did this choice together to simplify
> creation of
> > >>>>>>>>>> the
> > >>>>>>>>>>>>>>> new
> > >>>>>>>>>>>>>>>>> metrics.
> > >>>>>>>>>>>>>>>>> 2. This is not public API issue.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> I don’t ignore this flag.
> > >>>>>>>>>>>>>>>>> It just doesn’t exists in new framework(because of
> scope).
> > >>>>>>>>>>>>>>>>> I don’t think it’s an issue.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy
> best MBeans
> > >>>>>>>>>>>>>>>> practices.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Please, clarify your statement.
> > >>>>>>>>>>>>>>>>> What is best MBeans practices you are talking about?
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> How this can be API issue?
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 20:52, Andrey Gura <
> [hidden email]>
> > >>>>>>>>>>>> написал(а):
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are
> fixed with my
> > >>>>>>>>>>>> PR
> > >>>>>>>>>>>>>>>>> [1].
> > >>>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are
> blocker for the
> > >>>>>>>>>>>>>>> release.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> As I mentioned already IGNITE-11927 is part of IEP-35
> and
> > >>>>>>>>>>>>>>>>>> implementation seriously affects API's. Also I agree
> with Alexey
> > >>>>>>>>>>>>>>> about
> > >>>>>>>>>>>>>>>>>> introducing public IgniteMonitoring facade. So thiss
> PR doesn't
> > >>>>>>>>>> fix
> > >>>>>>>>>>>>>>>>>> all issues.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
> > >>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this
> contribution.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> It's right. But if you add checking of
> statisticsEnabling property
> > >>>>>>>>>>>>>>>>>> then test will fail. It's just not good tests.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create
> a ticket I
> > >>>>>>>>>> will
> > >>>>>>>>>>>>>>>> fix
> > >>>>>>>>>>>>>>>>> it ASAP.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> I already fix it all in IGNITE-11927
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> > >>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't
> hide major
> > >>>>>>>>>>>>>>>>> contribution from the user just because your second
> guess «I don’t
> > >>>>>>>>>>>> like
> > >>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>> API I just reviewed and approved».
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> We should move the product forward with with really
> finished
> > >>>>>>>>>>>>>>> features,
> > >>>>>>>>>>>>>>>>>> not pieces of features.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> So I am against this proposal.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> It is not argument.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API
> change and
> > >>>>>>>>>> discuss
> > >>>>>>>>>>>>>>>> them.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> We can prepare it together. But we can't block
> release.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> > >>>>>>>>>>>>>>>>>>> What is *ALL* problems?
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> > >>>>>>>>>>>>>>>>>> MetricExporterSpi that requires
> ReadOnlyMetricRegistry.
> > >>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that
> forces user
> > >>>>>>>>>> use
> > >>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> > >>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
> > >>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct
> reference
> > >>>>>>>>>>>>>>>>>> (performance problem).
> > >>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> > >>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy
> best MBeans
> > >>>>>>>>>>>>>>>> practices.
> > >>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> It's enough I believe.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:28 PM Николай Ижиков <
> > >>>>>>>>>> [hidden email]
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Andrey.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are
> fixed with my
> > >>>>>>>>>> PR
> > >>>>>>>>>>>>>>>> [1].
> > >>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker
> for the
> > >>>>>>>>>>>>>>> release.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this
> contribution.
> > >>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create
> a ticket I
> > >>>>>>>>>> will
> > >>>>>>>>>>>>>>>> fix
> > >>>>>>>>>>>>>>>>> it ASAP.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't
> hide major
> > >>>>>>>>>>>>>>>>> contribution from the user just because your second
> guess «I don’t
> > >>>>>>>>>>>> like
> > >>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>> API I just reviewed and approved».
> > >>>>>>>>>>>>>>>>>>> So I am against this proposal.
> > >>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API
> change and
> > >>>>>>>>>> discuss
> > >>>>>>>>>>>>>>>> them.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> What is *ALL* problems?
> > >>>>>>>>>>>>>>>>>>> Seems, we never be able to solve *ALL* problems.
> > >>>>>>>>>>>>>>>>>>> But, we should move the product forward.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> As for your steps [1-6].
> > >>>>>>>>>>>>>>>>>>> I’m always following these steps during my
> contribution.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 19:08, Andrey Gura <
> [hidden email]>
> > >>>>>>>>>>>>>>> написал(а):
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> The discussion is hot and can be endless. So in
> separate post I
> > >>>>>>>>>>>>>>> want
> > >>>>>>>>>>>>>>>>>>>> propose my solution.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> > >>>>>>>>>>>>>>>>>>>> 2. Create special feature branch B.
> > >>>>>>>>>>>>>>>>>>>> 3. In branch B will be merged IGNITE-11927
> > >>>>>>>>>>>>>>>>>>>> 4. Because IGNITE-11927 doesn't solve all problems
> we should
> > >>>>>>>>>>>>>>> propose
> > >>>>>>>>>>>>>>>>>>>> solution and implement it in branch B.
> > >>>>>>>>>>>>>>>>>>>> 5. Testing, usability testing, fixing, etc
> iteratively.
> > >>>>>>>>>>>>>>>>>>>> 6. Merge it to master and in new release branch if
> needed.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Independent step. There are some problem which
> should be fixed
> > >>>>>>>>>> in
> > >>>>>>>>>>>>>>> 2.8
> > >>>>>>>>>>>>>>>>>>>> before release otherwise we introduce problems with
> > >>>>>>>>>> compatibility
> > >>>>>>>>>>>>>>>>>>>> which will haunt us till next major release. I'll
> create
> > >>>>>>>>>> tickets.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:03 PM Andrey Gura <
> [hidden email]>
> > >>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires
> rewrite client
> > >>>>>>>>>>>> code.
> > >>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> > >>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove
> in the next
> > >>>>>>>>>>>> major
> > >>>>>>>>>>>>>>>>> release.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> We don't know anything about development processes
> our users. I
> > >>>>>>>>>>>>>>> can
> > >>>>>>>>>>>>>>>>>>>>> admit that process could require that deprecated
> methods/APIs
> > >>>>>>>>>> are
> > >>>>>>>>>>>>>>>> not
> > >>>>>>>>>>>>>>>>>>>>> allowed for example.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> > >>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange
> interface which
> > >>>>>>>>>> don't
> > >>>>>>>>>>>>>>>> give
> > >>>>>>>>>>>>>>>>> me any information about it’s purpose and
> responsibilities.
> > >>>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1]
> more clear:
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> I understand this. But I'm not Ignite user, I'm
> Ignite
> > >>>>>>>>>> developer.
> > >>>>>>>>>>>>>>>> The
> > >>>>>>>>>>>>>>>>>>>>> key moment in my message *from user stand point*.
> From my point
> > >>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>>> view it is very not intuitive solution and this
> interface is
> > >>>>>>>>>>>>>>>>>>>>> redundant.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
> caches for
> > >>>>>>>>>> example.
> > >>>>>>>>>>>>>>>>> There are other entities with such flag.
> > >>>>>>>>>>>>>>>>>>>>>> They still works as expected.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Actually not. I fixed many such issues during
> IGNITE-11927
> > >>>>>>>>>>>>>>>>> implementation.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
> > >>>>>>>>>>>>>>>>>>>>>> Because of the scope.
> > >>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the
> matter of the
> > >>>>>>>>>> other
> > >>>>>>>>>>>>>>>>> ticket.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> I talk not about ability. I talk about ignored
> existing
> > >>>>>>>>>>>>>>>> functionality.
> > >>>>>>>>>>>>>>>>>>>>> So scope is not case here.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by
> MetricExporterSpi
> > >>>>>>>>>>>>>>>>> implementations.
> > >>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter
> to decide.
> > >>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while
> OpenCensus
> > >>>>>>>>>> exporter
> > >>>>>>>>>>>>>>>>> can’t.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Actually list is not metric at all as I already
> told.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 5:26 PM Николай Ижиков <
> > >>>>>>>>>>>>>>> [hidden email]
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Andrey.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires
> rewrite client
> > >>>>>>>>>>>> code.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> > >>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove
> in the next
> > >>>>>>>>>>>> major
> > >>>>>>>>>>>>>>>>> release.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> > >>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange
> interface which
> > >>>>>>>>>> don't
> > >>>>>>>>>>>>>>>> give
> > >>>>>>>>>>>>>>>>> me any information about it’s purpose and
> responsibilities.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more
> clear:
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Each SPI would have a `ReadOnlyMetricManager`
> which provides
> > >>>>>>>>>>>>>>> access
> > >>>>>>>>>>>>>>>>> to collection of `ReadOnlyMetricRegistry`
> > >>>>>>>>>>>>>>>>>>>>>> which has a collection of `Metric`.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> So we reflects two-level structure we have in the
> internal API
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> GridMetricManager -> Collection[MetricRegistry] ->
> > >>>>>>>>>>>>>>>> Collection[Metric]
> > >>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricManager ->
> Collection[ReadOnlyMetricRegistry] ->
> > >>>>>>>>>>>>>>>>> Collection[Metric]
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
> caches for
> > >>>>>>>>>> example.
> > >>>>>>>>>>>>>>>>> There are other entities with such flag.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> They still works as expected.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Because of the scope.
> > >>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the
> matter of the
> > >>>>>>>>>> other
> > >>>>>>>>>>>>>>>>> ticket.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by
> MetricExporterSpi
> > >>>>>>>>>>>>>>>>> implementations.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter
> to decide.
> > >>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while
> OpenCensus
> > >>>>>>>>>> exporter
> > >>>>>>>>>>>>>>>>> can’t.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> [1]
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>
> https://github.com/apache/ignite/pull/7269/files#diff-0ae5657231fc4c1f650493b02190b81bR25
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 16:57, Andrey Gura <
> [hidden email]>
> > >>>>>>>>>>>>>>>>> написал(а):
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of
> the active
> > >>>>>>>>>>>>>>>> reviewers
> > >>>>>>>>>>>>>>>>> of the Metric API.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Yes. But if I'm not missing some thing you were
> major
> > >>>>>>>>>> developer
> > >>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>>>>> Metric API :) Shit happens. And it happened.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
> deprecation of APIs
> > >>>>>>>>>> that
> > >>>>>>>>>>>>>>>> are
> > >>>>>>>>>>>>>>>>> still supported and don't offer reasonable
> substitution.
> > >>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> There is such concept - backward compatibility.
> I understand
> > >>>>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>>>>>>> deprecation of some interface doesn't break
> backward
> > >>>>>>>>>>>>>>> compatibility
> > >>>>>>>>>>>>>>>>> but
> > >>>>>>>>>>>>>>>>>>>>>>> it leads to question^ what should I use instead
> of this. And
> > >>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi is not answer for this
> question. Because it
> > >>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>>> brand
> > >>>>>>>>>>>>>>>>>>>>>>> new API and it requires rewrite client code.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> > >>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal
> MetricRegistry  to
> > >>>>>>>>>> the
> > >>>>>>>>>>>>>>>>> exporters.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> No it is not. It's completely artificial thing
> which allow
> > >>>>>>>>>>>>>>> iterate
> > >>>>>>>>>>>>>>>>> via
> > >>>>>>>>>>>>>>>>>>>>>>> all metric registries. GridMetricManager
> implements this
> > >>>>>>>>>>>>>>> interface
> > >>>>>>>>>>>>>>>>>>>>>>> while it is not metric registry. Form user stand
> point it is
> > >>>>>>>>>>>>>>> very
> > >>>>>>>>>>>>>>>>>>>>>>> strange interface which don't give me any
> information about
> > >>>>>>>>>>>> it's
> > >>>>>>>>>>>>>>>>>>>>>>> purpose and responsibilities.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> > >>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
> caches for
> > >>>>>>>>>> example.
> > >>>>>>>>>>>>>>>>> There
> > >>>>>>>>>>>>>>>>>>>>>>> are other entities with such flag.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way? Why you
> ignore existing
> > >>>>>>>>>>>>>>>>>>>>>>> functionality? It affects user expectations and
> experience.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Yes? I'm working. Unfortunately we are not
> synchronized in
> > >>>>>>>>>> this
> > >>>>>>>>>>>>>>>>>>>>>>> context and I should redo all metrics related
> changes in
> > >>>>>>>>>> order
> > >>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>>>>> merge it with my changes. Anyway, my change
> doesn't solve all
> > >>>>>>>>>>>>>>>>> problems
> > >>>>>>>>>>>>>>>>>>>>>>> (e.g. it doesn't introduce IgniteMonitoring
> facade).
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Unfortunately it will be just fix. In my
> solution it is
> > >>>>>>>>>>>>>>> redesign.
> > >>>>>>>>>>>>>>>>> Stop
> > >>>>>>>>>>>>>>>>>>>>>>> fixing issues, let's do things. It requires
> deeper changes.
> > >>>>>>>>>> My
> > >>>>>>>>>>>>>>>>> changes
> > >>>>>>>>>>>>>>>>>>>>>>> blocks AI 2.8 release because it big enough. So
> it retargeted
> > >>>>>>>>>>>> on
> > >>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>> next release. And it is one more reason for
> moving the
> > >>>>>>>>>> changes
> > >>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>> internal packages. And it isn't good news for me
> because I
> > >>>>>>>>>> will
> > >>>>>>>>>>>>>>> go
> > >>>>>>>>>>>>>>>>>>>>>>> throughout pan and tiers of merge. But it is
> right.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
> compatibility.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> > >>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
> compatibility.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Yes, I know. But they should not be exported by
> > >>>>>>>>>>>>>>> MetricExporterSpi
> > >>>>>>>>>>>>>>>>>>>>>>> implementations.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 3:37 PM Николай Ижиков <
> > >>>>>>>>>>>>>>>> [hidden email]>
> > >>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> Andrey, thanks for your opinion and your ownest
> critisism.
> > >>>>>>>>>>>>>>>>>>>>>>>> I can’t wait for your contribution.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of
> the active
> > >>>>>>>>>>>>>>>> reviewers
> > >>>>>>>>>>>>>>>>> of the Metric API.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
> deprecation of APIs
> > >>>>>>>>>> that
> > >>>>>>>>>>>>>>>> are
> > >>>>>>>>>>>>>>>>> still supported and don't offer reasonable
> substitution.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't
> recommend
> > >>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still
> not-production ready.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> It’s ready.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the
> public API
> > >>>>>>>>>> doesn't
> > >>>>>>>>>>>>>>>>> solve the problem because this interface exposes
> internal Metric
> > >>>>>>>>>>>>>>>> interface
> > >>>>>>>>>>>>>>>>> implementations.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> Not, its’ not.
> > >>>>>>>>>>>>>>>>>>>>>>>> Please, see
> `org.apache.ignite.spi.metric.LongMetric` and
> > >>>>>>>>>>>> other
> > >>>>>>>>>>>>>>>>> public interface.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> API of MetricRegistry is inconsistent.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> MetricRegistry is the internal API.
> > >>>>>>>>>>>>>>>>>>>>>>>> Feel free to create ticket for an issues with
> it and I will
> > >>>>>>>>>>>> try
> > >>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>> fix it.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal
> MetricRegistry  to
> > >>>>>>>>>> the
> > >>>>>>>>>>>>>>>>> exporters.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> > >>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
> > >>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> > >>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
> compatibility.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 15:09, Andrey Gura <
> [hidden email]>
> > >>>>>>>>>>>>>>>>> написал(а):
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
> deprecation of APIs
> > >>>>>>>>>> that
> > >>>>>>>>>>>>>>>> are
> > >>>>>>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
> substitution.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't
> recommend
> > >>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still
> not-production
> > >>>>>>>>>>>> ready.
> > >>>>>>>>>>>>>>>>> There
> > >>>>>>>>>>>>>>>>>>>>>>>>> are some issues with it and usage of
> ReadOnlyMetricRegistry
> > >>>>>>>>>>>>>>>>> interface
> > >>>>>>>>>>>>>>>>>>>>>>>>> just one of them.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the
> public API
> > >>>>>>>>>> doesn't
> > >>>>>>>>>>>>>>>>> solve
> > >>>>>>>>>>>>>>>>>>>>>>>>> the problem because this interface exposes
> internal Metric
> > >>>>>>>>>>>>>>>>> interface
> > >>>>>>>>>>>>>>>>>>>>>>>>> implementations. So your PR is incomplete.
> > >>>>>>>>>>>>>>>>>>>>>>>>> Moreover, API of MetricRegistry is
> inconsistent. E.g.
> > >>>>>>>>>>>>>>>>> register(name,
> > >>>>>>>>>>>>>>>>>>>>>>>>> supplier, desc) method returns registered
> metric for some
> > >>>>>>>>>>>>>>> types
> > >>>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>>>>>>>> doesn't for other. register(metric) method is
> inconsistent
> > >>>>>>>>>> in
> > >>>>>>>>>>>>>>>>> sense of
> > >>>>>>>>>>>>>>>>>>>>>>>>> metric naming. ReadOnlyMetricRegistry
> interface is
> > >>>>>>>>>> redundant.
> > >>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi should be revised because it
> absolutely
> > >>>>>>>>>> not
> > >>>>>>>>>>>>>>>>>>>>>>>>> intuitive because it requires
> ReadOnlyMetricRegistry and
> > >>>>>>>>>> it's
> > >>>>>>>>>>>>>>>>> purpose
> > >>>>>>>>>>>>>>>>>>>>>>>>> is undefined.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> One more point. IEP-35 is still not fully
> implemented. Some
> > >>>>>>>>>>>>>>>>> things are
> > >>>>>>>>>>>>>>>>>>>>>>>>> not taken into account. Exporters expose
> metrics if they
> > >>>>>>>>>> are
> > >>>>>>>>>>>>>>>>> disabled.
> > >>>>>>>>>>>>>>>>>>>>>>>>> JMX beans exposes values that don't confirm to
> best
> > >>>>>>>>>> practices
> > >>>>>>>>>>>>>>>> [1].
> > >>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> Ubiquitous
> > >>>>>>>>>>>> merics
> > >>>>>>>>>>>>>>>>> lookup
> > >>>>>>>>>>>>>>>>>>>>>>>>> from hash map instead of usage reference for
> getting
> > >>>>>>>>>> metrics
> > >>>>>>>>>>>>>>>>> values
> > >>>>>>>>>>>>>>>>>>>>>>>>> (it is just performance issue). Also
> IGNITE-11927 is not
> > >>>>>>>>>>>>>>>>> implemented
> > >>>>>>>>>>>>>>>>>>>>>>>>> which also changes interfaces significantly.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> Let's just admit that the implementation is
> immature and
> > >>>>>>>>>> must
> > >>>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>> moved
> > >>>>>>>>>>>>>>>>>>>>>>>>> to the internal packages.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> And because we already merged partially
> implemented IEP to
> > >>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>> master
> > >>>>>>>>>>>>>>>>>>>>>>>>> branch we *must move all currently public APIs
> to the
> > >>>>>>>>>>>> internal
> > >>>>>>>>>>>>>>>>> API*
> > >>>>>>>>>>>>>>>>>>>>>>>>> while it will not be ready for publication.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> And the last but not least. What is happening
> indicates a
> > >>>>>>>>>>>>>>>> immature
> > >>>>>>>>>>>>>>>>>>>>>>>>> development process which must be revised. I
> don't want
> > >>>>>>>>>>>>>>> discuss
> > >>>>>>>>>>>>>>>>> it in
> > >>>>>>>>>>>>>>>>>>>>>>>>> this thread but we must not allow merge of
> change to the
> > >>>>>>>>>>>>>>> master
> > >>>>>>>>>>>>>>>>> branch
> > >>>>>>>>>>>>>>>>>>>>>>>>> before it will completed, that is we must use
> feature
> > >>>>>>>>>>>> branches
> > >>>>>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>>>>>>>>> full IEP not only for particular tickets. And
> also we
> > >>>>>>>>>> should
> > >>>>>>>>>>>>>>>>>>>>>>>>> reformulate IEP process in order to avoid
> things like this.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> [1]
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>
> https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:49 PM Николай
> Ижиков <
> > >>>>>>>>>>>>>>>>> [hidden email]> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Alex.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> OK, I may leverage your experience and create
> pure Java
> > >>>>>>>>>> API.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Ticket [1] created.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> But, personally, I don’t agree with you.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Ignite has dozens of the API that
> theoretically have a
> > >>>>>>>>>> usage
> > >>>>>>>>>>>>>>>>> scenario, but in real-world have 0 custom
> implementation and
> > >>>>>>>>>> usages.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Moreover, many APIs that were created with
> the intentions
> > >>>>>>>>>>>> you
> > >>>>>>>>>>>>>>>>> mentioned is abandoned now and confuses users.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> You can just see count of the tests we just
> mute on the
> > >>>>>>>>>> TC.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Can you, please, take a look at the fix
> regarding puck API
> > >>>>>>>>>>>>>>>> issue
> > >>>>>>>>>>>>>>>>> you mentioned in your first letter [2], [3]
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> [1]
> https://issues.apache.org/jira/browse/IGNITE-12553
> > >>>>>>>>>>>>>>>>>>>>>>>>>> [2]
> https://github.com/apache/ignite/pull/7269
> > >>>>>>>>>>>>>>>>>>>>>>>>>> [3]
> https://issues.apache.org/jira/browse/IGNITE-12552
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 12:12, Alexey Goncharuk <
> > >>>>>>>>>>>>>>>>> [hidden email]> написал(а):
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Nikolay,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Why do you think this is a wrong usage
> pattern? From the
> > >>>>>>>>>>>> top
> > >>>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>> my head,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> here is a few cases of direct metric API
> usage that I
> > >>>>>>>>>> know
> > >>>>>>>>>>>>>>> are
> > >>>>>>>>>>>>>>>>> currently
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> being used in production:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom task execution scheduling service
> with load
> > >>>>>>>>>>>>>>>>> balancing based on
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> utilization metrics readings from Java code
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> * Cleanup task trigger based on metrics
> readings
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom health-check endpoint for an
> application with
> > >>>>>>>>>> an
> > >>>>>>>>>>>>>>>>> embedded
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Ignite node for Kubernetes/Spring
> Application/etc
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>
> > >>>>
> > >>
> >
>

[Nikolay Izhikov-2]

> it's better to remove deprecation for the old APIs in AI 2.8

Are you suggest to have 2 concurrent metrics implementations(both not deprecated)?

> Let's say I am writing a custom exporter in binary format and I need to write the number of exported metrics in a packet beforehand.

This an `MetricExporterSPI` implementation task.
Exporter has the listeners that can be used to track all registry events - creation, removal

> There is no separation on public and internal metrics

I think we should write in the documentation that ANY metric can be changed.
We will try to keep them, but if we found that some metric doesn’t required any more or implemented in the wrong way - we can remove it.

> Will we allow users to register their own metrics?

No. Why we should considering this feature?

> It's still not clear how a user will map old interfaces and methods to the new metric names.

With the documentation.
We can write separate deprecation comment for each metric providing method.

> I just want to remove the deprecations on the classes for which there is no a well-defined replacement.

Well-defined replacement for these classes exists.

> 27 янв. 2020 г., в 16:21, Alexey Goncharuk <[hidden email]> написал(а):
>
> Nikolay,
>
> I've reviewed your changes and I tend to agree with Andrey, it's better to
> remove deprecation for the old APIs in AI 2.8 and discuss and merge the new
> facade (IGNITE-12553) in a more calm and structured way. My observations on
> the changes:
>
>   - I am not sure if Iterable would suffice both for the exporter and
>   public APIs. Should we provide a way to know the number of metrics and
>   registries in advance? Let's say I am writing a custom exporter in binary
>   format and I need to write the number of exported metrics in a packet
>   beforehand.
>   - There is no separation on public and internal metrics, when public
>   metrics preserve their name and semantics, and internal metrics may change.
>   I remember we discussed this, but it's not reflected in the APIs in any way.
>   - Will we allow users to register their own metrics? Again I remember we
>   discussed a possibility for this. If so, why the registry is called
>   'ReadyOnly'?
>   - It's still not clear how a user will map old interfaces and methods to
>   the new metric names.
>
> As you can see in the original message, I am not pushing for the new APIs
> in the nearest release, I just want to remove the deprecations on the
> classes for which there is no a well-defined replacement.
>
> пн, 27 янв. 2020 г. в 15:56, Maxim Muzafarov <[hidden email]>:
>
>> Folks,
>>
>>
>> I'm sorry for not being too attentive to the whole thread discussion
>> and maybe missing some details.
>>
>> But... who will perform the review of [1] issue?
>> Will we merge it to 2.8? (hope so)
>>
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-12553
>> [IEP-35] public Java metric API
>>
>> On Sat, 25 Jan 2020 at 11:43, Николай Ижиков <[hidden email]> wrote:
>>>
>>> Andrey.
>>>
>>> With this API we are trying to fill the GAP Alexey pointed out at the
>> start of this discussion.
>>> I think it worth to be reviewed and merged.
>>>
>>> Can we, please, come back to the discussion of the changes itself?
>>> I think API changes should be discussed in the other thread.
>>>
>>>> Why do you think this is a wrong usage pattern? From the top of my
>> head, here is a few cases of direct metric API usage that I know are
>> currently being used in production:
>>>> * A custom task execution scheduling service with load balancing based
>> on utilization metrics readings from Java code
>>>> * Cleanup task trigger based on metrics readings
>>>> * A custom health-check endpoint for an application with an embedded
>> Ignite node for Kubernetes/Spring Application/etc
>>>
>>> [1] https://github.com/apache/ignite/pull/7283
>>>
>>>> 24 янв. 2020 г., в 18:08, Andrey Gura <[hidden email]> написал(а):
>>>>
>>>>> My point - that your contribution that took a long time, already,
>> can’t be an argument to postpone creation of the API in the current release.
>>>>
>>>> Argument is not about time. But about API which is known will be
>> changed.
>>>> Second argument: why we should add this experimental API to the
>>>> already existing experimental API? Just to making API more
>>>> experimental? As I told already it is commit for commit and doesn't
>>>> bring any value but brings some inconvenience to me (e.g. merge
>>>> problems).
>>>>
>>>> BTW, does it exist issue about marking IEP-35 API's as experimental?
>>>>
>>>> On Thu, Jan 23, 2020 at 8:33 PM Николай Ижиков <[hidden email]>
>> wrote:
>>>>>
>>>>>> You want say didn't discuss?
>>>>>
>>>>> Yes.
>>>>>
>>>>>> Secondly, yes it took a lot of time due to a lot of changes. Is it
>> problem?
>>>>>
>>>>> No, of course.
>>>>> My point - that your contribution that took a long time, already,
>> can’t be an argument to postpone creation of the API in the current release.
>>>>>
>>>>>
>>>>>> 23 янв. 2020 г., в 18:11, Andrey Gura <[hidden email]> написал(а):
>>>>>>
>>>>>>> We don’t discuss your changes and your proposals for the Metric API.
>>>>>>
>>>>>> You want say didn't discuss? Actually we did it [1] but you told ok
>>>>>> let's see code :)
>>>>>>
>>>>>>> So I don’t think we can make the existence of some PR is an
>> argument to introduce(or not introduce) this facade.
>>>>>>
>>>>>> You definitely right in case of competition development. But I think
>>>>>> that collaborative development is more effective. Isn't it?
>>>>>>
>>>>>>> Moreover, As far as I know, you developing changes for the Metric
>> API for 5 months without public discussion, for now. Let's start it.
>>>>>>
>>>>>> Firsty, with discussion. See above.
>>>>>> Secondly, yes it took a lot of time due to a lot of changes. Is it
>> problem?
>>>>>>
>>>>>>> Let’s do the following:
>>>>>>> 1. Review `IgniteMetric` facade and introduce it to the users as an
>> experimental API.
>>>>>>
>>>>>> It just doesn't make sense. Just commit for commit.
>>>>>>
>>>>>>> 2. Discuss your proposal to the Metric API in the separate thread
>> you are referencing.
>>>>>>
>>>>>> You a re welcome to thread [1] again. But please, take into account.
>>>>>> because discussion is postponed by you it's late enough to discuss
>>>>>> proposed solution. But of course I'll answer on your questions and
>>>>>> will be glade to your comments and suggestions.
>>>>>>
>>>>>>> I think we should start a discussion from the simplified
>> explanation of:
>>>>>>> 1. API intentions - What we want to gain with it? What is our focus?
>>>>>>> 2. Simple, minimal example of API main interfaces and desired
>> usages.
>>>>>>
>>>>>> All this already described at [1]. You also can take a look on PR
>> (see
>>>>>> MetricSource implementations, there are complex and simple ones).
>>>>>>
>>>>>> [1]
>> http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Metrics-management-in-Ignite-tp43243.html
>>>>>>
>>>>>> On Thu, Jan 23, 2020 at 5:42 PM Николай Ижиков <[hidden email]>
>> wrote:
>>>>>>>
>>>>>>> Andrey.
>>>>>>>
>>>>>>>> IGNITE-11927 implementation so your changes are incompatible with
>> my changes
>>>>>>>
>>>>>>> We don’t discuss your changes and your proposals for the Metric API.
>>>>>>> So I don’t think we can make the existence of some PR is an
>> argument to introduce(or not introduce) this facade.
>>>>>>> Moreover, As far as I know, you developing changes for the Metric
>> API for 5 months without public discussion, for now. Let's start it.
>>>>>>>
>>>>>>> Let’s do the following:
>>>>>>>
>>>>>>> 1. Review `IgniteMetric` facade and introduce it to the users as an
>> experimental API.
>>>>>>>
>>>>>>> 2. Discuss your proposal to the Metric API in the separate thread
>> you are referencing.
>>>>>>>
>>>>>>> I think we should start a discussion from the simplified
>> explanation of:
>>>>>>>
>>>>>>> 1. API intentions - What we want to gain with it? What is our focus?
>>>>>>> 2. Simple, minimal example of API main interfaces and desired
>> usages.
>>>>>>>
>>>>>>> This will help to the community and me personally better understand
>> your idea and share feedback.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>>> 23 янв. 2020 г., в 17:15, Andrey Gura <[hidden email]>
>> написал(а):
>>>>>>>>
>>>>>>>> Nikolay,
>>>>>>>>
>>>>>>>> as I wrote early in this thread API significantly changed during
>>>>>>>> IGNITE-11927 implementation so your changes are incompatible with
>> my
>>>>>>>> changes.
>>>>>>>>
>>>>>>>> ReadOnlyMetricRegistry will be removed at all (still exists in a
>>>>>>>> couple of places where it uses).
>>>>>>>>
>>>>>>>> Also I don't want to introduce IgniteMetric facade in this rush. In
>>>>>>>> current implementation this interface just provides access to the
>>>>>>>> ReadOnlyMetricManager instance (which will be removed) but it is
>> not
>>>>>>>> enough.
>>>>>>>>
>>>>>>>> I agree with Denis. We should mark current API as experimental and
>>>>>>>> continue IEP-35 development. See my process proposal [1] described
>>>>>>>> early this thread. We can release Apache Ignite 2.8.1 specially for
>>>>>>>> this changes.
>>>>>>>> Public APIs require deeper thinking in order to provide
>> comprehensive,
>>>>>>>> consistent and convenient way of metrics management for end users.
>>>>>>>>
>>>>>>>> Let's add IgniteExperimental, release 2.8 and finish metrics
>> related
>>>>>>>> issues after it.
>>>>>>>>
>>>>>>>> [1]
>> http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-tp45146p45185.html
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jan 22, 2020 at 5:21 PM Николай Ижиков <
>> [hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> Hello, Igniters.
>>>>>>>>>
>>>>>>>>> * IGNITE-12552: Move ReadOnlyMetricRegistry to public API merged
>> to the master and cherry-picked to the 2.8.
>>>>>>>>> So the main issue with the Metric API solved.
>>>>>>>>>
>>>>>>>>> * I raised the PR [1] to fix second issue with the new Metric
>> API: absence of the public Java API to get metrics.
>>>>>>>>> This PR introduces the following changes:
>>>>>>>>>
>>>>>>>>> 1. IgniteMetric interface created: it provides Java API to access
>> Ignite metrics created with the new Metric API.
>>>>>>>>>
>>>>>>>>> ```
>>>>>>>>> public interface IgniteMetric extends
>> Iterable<ReadOnlyMetricRegistry> {
>>>>>>>>> @Nullable ReadOnlyMetricRegistry registry(String name);
>>>>>>>>> }
>>>>>>>>> ```
>>>>>>>>>
>>>>>>>>> 2. All deprecation javadocs regarding metrics now reference to
>> the public IgniteMetric instead of internal GridMetricManager:
>>>>>>>>>
>>>>>>>>>> @deprecated Use {@link IgniteMetric} instead.
>>>>>>>>>
>>>>>>>>> 3. Tests refactored to use IgniteMetric instead of
>> GridMetricManager when possible.
>>>>>>>>>
>>>>>>>>> Please, review.
>>>>>>>>>
>>>>>>>>> [1]  https://github.com/apache/ignite/pull/7283
>>>>>>>>>
>>>>>>>>>> 21 янв. 2020 г., в 17:51, Николай Ижиков <[hidden email]>
>> написал(а):
>>>>>>>>>>
>>>>>>>>>> Hello, Igniters.
>>>>>>>>>>
>>>>>>>>>> Alexey approved my PR [1] regarding fixing public API for metric
>> exporters.
>>>>>>>>>> I’m waiting for a bot visa and merge this PR.
>>>>>>>>>>
>>>>>>>>>> As we discussed, the metrics API will be marked with
>> IgniteExperimental annotation.
>>>>>>>>>>
>>>>>>>>>> If anyone has any objection to this plan, please provide your
>> feedback.
>>>>>>>>>>
>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>
>>>>>>>>>>> 21 янв. 2020 г., в 13:45, Николай Ижиков <
>> [hidden email]> написал(а):
>>>>>>>>>>>
>>>>>>>>>>> Thanks, for the review Alexey.
>>>>>>>>>>>
>>>>>>>>>>> I will fix your comment and  try to implement Monitoring
>> facade, shortly.
>>>>>>>>>>>
>>>>>>>>>>>> 21 янв. 2020 г., в 13:32, Alexey Goncharuk <
>> [hidden email]> написал(а):
>>>>>>>>>>>>
>>>>>>>>>>>> Nikolay,
>>>>>>>>>>>>
>>>>>>>>>>>> I left a single comment in the PR about the histogram metric.
>> I think the
>>>>>>>>>>>> API looks much cleaner now.
>>>>>>>>>>>>
>>>>>>>>>>>> I will take care of the @IgniteExperimental annotation.
>>>>>>>>>>>>
>>>>>>>>>>>> пн, 20 янв. 2020 г. в 20:55, Николай Ижиков <
>> [hidden email]>:
>>>>>>>>>>>>
>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>
>>>>>>>>>>>>> PR [1] is waiting for your review.
>>>>>>>>>>>>> Please, take a look.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think we should do the following before 2.8 release
>>>>>>>>>>>>>
>>>>>>>>>>>>> * Introduce new @IgniteExperimental annotation as discussed.
>>>>>>>>>>>>> * Mark Monitoring API with it.
>>>>>>>>>>>>> * merge «[IEP-35] Expose MetricRegistry to the public API» to
>> 2.8
>>>>>>>>>>>>> * merge «[IEP-35] public Java metric API» to 2.8
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk <
>> [hidden email]>
>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nikolay,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Should we wait for both of the tickets given that we agreed
>> that we are
>>>>>>>>>>>>>> putting an experimental marker on the new APIs? I'm ok to
>> fix only the
>>>>>>>>>>>>>> first one and add the experimental marker so that we do not
>> delay 2.8
>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков <
>> [hidden email]>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Andrey.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Let’s move from the long letters to the code.
>>>>>>>>>>>>>>> If you want to change API - please, propose this changes.
>>>>>>>>>>>>>>> I think everybody wins if we make our API better.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please, describe proposed changes.
>>>>>>>>>>>>>>> It would be great if you have some examples or PR for it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As for this release, I have plans to contribute tickets
>>>>>>>>>>>>>>> «[IEP-35] Expose MetricRegistry to the public API» [1] and
>>>>>>>>>>>>>>> «[IEP-35] public Java metric API» [2] for it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any objections on it?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-12553
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 20 янв. 2020 г., в 13:08, Andrey Gura <[hidden email]>
>> написал(а):
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It solves problem.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
>>>>>>>>>>>>>>>> <[hidden email]> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> After giving it some thought, I agree with Denis - there
>> is nothing
>>>>>>>>>>>>>>> wrong
>>>>>>>>>>>>>>>>> with exposing the new APIs, we just need to make it clear
>> that we are
>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>> going to change it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Should we Introduce something like @IgniteExperimental
>> annotation (I
>>>>>>>>>>>>>>>>> believe it has been discussed a dozen of times on the
>> dev-list)?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov <
>> [hidden email]>:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> +1 to mark feature or whole release as EA.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> пт, 17 янв. 2020 г., 23:00 Denis Magda <
>> [hidden email]>:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Folks, if you don't mind I'll share some
>> thoughts/suggestions as an
>>>>>>>>>>>>>>>>>>> observer who was not involved in the feature
>> development.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It's absolutely 'ok' to deprecate an API that is
>> replaced with a
>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>>>> better version. However, we should do this only when
>> the new APIs
>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>> production-ready. If there are still many limitations
>> or open items
>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>> don't deprecate anything that exists and release the
>> new APIs
>>>>>>>>>>>>>>> labeling as
>>>>>>>>>>>>>>>>>>> early access. What if release the improvements labeling
>> as EA
>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>> hiding them completely?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I would also encourage us to put aside emotions, don't
>> blame or
>>>>>>>>>>>>> point
>>>>>>>>>>>>>>>>>>> fingers. This IEP is a great initiative and you both
>> have already
>>>>>>>>>>>>>>> done a
>>>>>>>>>>>>>>>>>>> tremendous job by developing, architecting and
>> reviewing changes.
>>>>>>>>>>>>>>> Just be
>>>>>>>>>>>>>>>>>>> respectful. Nobody is trying to block the feature from
>> being
>>>>>>>>>>>>> released.
>>>>>>>>>>>>>>>>>>> Everyone would be glad to tap into improvements and
>> start using them
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> prod. But if more time is needed for the GA let's
>> reiterate a bit.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>> Denis
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков <
>>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Also I agree with Alexey about introducing public
>> IgniteMonitoring
>>>>>>>>>>>>>>>>>>> facade
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This is not an issue with the API.
>>>>>>>>>>>>>>>>>>>> Just the new feature that doesn’t affects API.
>>>>>>>>>>>>>>>>>>>> Moreover, I create a ticket to fix it, already.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It's right. But if you add checking of
>> statisticsEnabling property
>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>> test will fail. It's just not good tests.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> My changes doesn’t affect any `staticticsEnabled`
>> property.
>>>>>>>>>>>>>>>>>>>> I don’ understand your point here.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It’s not redundant.
>>>>>>>>>>>>>>>>>>>> It required for exporters and provide read only access
>> to
>>>>>>>>>>>>>>>>>> MetricRegistry
>>>>>>>>>>>>>>>>>>>> existing in the node.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi that requires
>> ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that
>> forces user
>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Why this is issue?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It’s consistent.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct
>> reference
>>>>>>>>>>>>>>>>>>>>> (performance problem).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1. We(You and I) did this choice together to simplify
>> creation of
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>>> metrics.
>>>>>>>>>>>>>>>>>>>> 2. This is not public API issue.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I don’t ignore this flag.
>>>>>>>>>>>>>>>>>>>> It just doesn’t exists in new framework(because of
>> scope).
>>>>>>>>>>>>>>>>>>>> I don’t think it’s an issue.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy
>> best MBeans
>>>>>>>>>>>>>>>>>>> practices.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Please, clarify your statement.
>>>>>>>>>>>>>>>>>>>> What is best MBeans practices you are talking about?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> How this can be API issue?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 20:52, Andrey Gura <
>> [hidden email]>
>>>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are
>> fixed with my
>>>>>>>>>>>>>>> PR
>>>>>>>>>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are
>> blocker for the
>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> As I mentioned already IGNITE-11927 is part of IEP-35
>> and
>>>>>>>>>>>>>>>>>>>>> implementation seriously affects API's. Also I agree
>> with Alexey
>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>>> introducing public IgniteMonitoring facade. So thiss
>> PR doesn't
>>>>>>>>>>>>> fix
>>>>>>>>>>>>>>>>>>>>> all issues.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
>>>>>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this
>> contribution.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It's right. But if you add checking of
>> statisticsEnabling property
>>>>>>>>>>>>>>>>>>>>> then test will fail. It's just not good tests.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create
>> a ticket I
>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>> fix
>>>>>>>>>>>>>>>>>>>> it ASAP.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I already fix it all in IGNITE-11927
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't
>> hide major
>>>>>>>>>>>>>>>>>>>> contribution from the user just because your second
>> guess «I don’t
>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> API I just reviewed and approved».
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> We should move the product forward with with really
>> finished
>>>>>>>>>>>>>>>>>> features,
>>>>>>>>>>>>>>>>>>>>> not pieces of features.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> So I am against this proposal.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It is not argument.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API
>> change and
>>>>>>>>>>>>> discuss
>>>>>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> We can prepare it together. But we can't block
>> release.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
>>>>>>>>>>>>>>>>>>>>>> What is *ALL* problems?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi that requires
>> ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that
>> forces user
>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
>>>>>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
>>>>>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct
>> reference
>>>>>>>>>>>>>>>>>>>>> (performance problem).
>>>>>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
>>>>>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy
>> best MBeans
>>>>>>>>>>>>>>>>>>> practices.
>>>>>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It's enough I believe.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:28 PM Николай Ижиков <
>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Andrey.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are
>> fixed with my
>>>>>>>>>>>>> PR
>>>>>>>>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker
>> for the
>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this
>> contribution.
>>>>>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create
>> a ticket I
>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>> fix
>>>>>>>>>>>>>>>>>>>> it ASAP.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't
>> hide major
>>>>>>>>>>>>>>>>>>>> contribution from the user just because your second
>> guess «I don’t
>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> API I just reviewed and approved».
>>>>>>>>>>>>>>>>>>>>>> So I am against this proposal.
>>>>>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API
>> change and
>>>>>>>>>>>>> discuss
>>>>>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> What is *ALL* problems?
>>>>>>>>>>>>>>>>>>>>>> Seems, we never be able to solve *ALL* problems.
>>>>>>>>>>>>>>>>>>>>>> But, we should move the product forward.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> As for your steps [1-6].
>>>>>>>>>>>>>>>>>>>>>> I’m always following these steps during my
>> contribution.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 19:08, Andrey Gura <
>> [hidden email]>
>>>>>>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The discussion is hot and can be endless. So in
>> separate post I
>>>>>>>>>>>>>>>>>> want
>>>>>>>>>>>>>>>>>>>>>>> propose my solution.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>>>>>>>>>>> 2. Create special feature branch B.
>>>>>>>>>>>>>>>>>>>>>>> 3. In branch B will be merged IGNITE-11927
>>>>>>>>>>>>>>>>>>>>>>> 4. Because IGNITE-11927 doesn't solve all problems
>> we should
>>>>>>>>>>>>>>>>>> propose
>>>>>>>>>>>>>>>>>>>>>>> solution and implement it in branch B.
>>>>>>>>>>>>>>>>>>>>>>> 5. Testing, usability testing, fixing, etc
>> iteratively.
>>>>>>>>>>>>>>>>>>>>>>> 6. Merge it to master and in new release branch if
>> needed.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Independent step. There are some problem which
>> should be fixed
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> 2.8
>>>>>>>>>>>>>>>>>>>>>>> before release otherwise we introduce problems with
>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>>>>>>>>>>> which will haunt us till next major release. I'll
>> create
>>>>>>>>>>>>> tickets.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:03 PM Andrey Gura <
>> [hidden email]>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires
>> rewrite client
>>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
>>>>>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove
>> in the next
>>>>>>>>>>>>>>> major
>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> We don't know anything about development processes
>> our users. I
>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>>>>> admit that process could require that deprecated
>> methods/APIs
>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>> allowed for example.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
>>>>>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange
>> interface which
>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>> give
>>>>>>>>>>>>>>>>>>>> me any information about it’s purpose and
>> responsibilities.
>>>>>>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1]
>> more clear:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I understand this. But I'm not Ignite user, I'm
>> Ignite
>>>>>>>>>>>>> developer.
>>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>>>>>> key moment in my message *from user stand point*.
>> From my point
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>> view it is very not intuitive solution and this
>> interface is
>>>>>>>>>>>>>>>>>>>>>>>> redundant.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
>> caches for
>>>>>>>>>>>>> example.
>>>>>>>>>>>>>>>>>>>> There are other entities with such flag.
>>>>>>>>>>>>>>>>>>>>>>>>> They still works as expected.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Actually not. I fixed many such issues during
>> IGNITE-11927
>>>>>>>>>>>>>>>>>>>> implementation.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
>>>>>>>>>>>>>>>>>>>>>>>>> Because of the scope.
>>>>>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the
>> matter of the
>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I talk not about ability. I talk about ignored
>> existing
>>>>>>>>>>>>>>>>>>> functionality.
>>>>>>>>>>>>>>>>>>>>>>>> So scope is not case here.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by
>> MetricExporterSpi
>>>>>>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter
>> to decide.
>>>>>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while
>> OpenCensus
>>>>>>>>>>>>> exporter
>>>>>>>>>>>>>>>>>>>> can’t.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Actually list is not metric at all as I already
>> told.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 5:26 PM Николай Ижиков <
>>>>>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Andrey.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires
>> rewrite client
>>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
>>>>>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove
>> in the next
>>>>>>>>>>>>>>> major
>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
>>>>>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange
>> interface which
>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>> give
>>>>>>>>>>>>>>>>>>>> me any information about it’s purpose and
>> responsibilities.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more
>> clear:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Each SPI would have a `ReadOnlyMetricManager`
>> which provides
>>>>>>>>>>>>>>>>>> access
>>>>>>>>>>>>>>>>>>>> to collection of `ReadOnlyMetricRegistry`
>>>>>>>>>>>>>>>>>>>>>>>>> which has a collection of `Metric`.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> So we reflects two-level structure we have in the
>> internal API
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> GridMetricManager -> Collection[MetricRegistry] ->
>>>>>>>>>>>>>>>>>>> Collection[Metric]
>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricManager ->
>> Collection[ReadOnlyMetricRegistry] ->
>>>>>>>>>>>>>>>>>>>> Collection[Metric]
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
>> caches for
>>>>>>>>>>>>> example.
>>>>>>>>>>>>>>>>>>>> There are other entities with such flag.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> They still works as expected.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Because of the scope.
>>>>>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the
>> matter of the
>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by
>> MetricExporterSpi
>>>>>>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter
>> to decide.
>>>>>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while
>> OpenCensus
>>>>>>>>>>>>> exporter
>>>>>>>>>>>>>>>>>>>> can’t.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>> https://github.com/apache/ignite/pull/7269/files#diff-0ae5657231fc4c1f650493b02190b81bR25
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 16:57, Andrey Gura <
>> [hidden email]>
>>>>>>>>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of
>> the active
>>>>>>>>>>>>>>>>>>> reviewers
>>>>>>>>>>>>>>>>>>>> of the Metric API.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Yes. But if I'm not missing some thing you were
>> major
>>>>>>>>>>>>> developer
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>>>> Metric API :) Shit happens. And it happened.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
>> deprecation of APIs
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
>> substitution.
>>>>>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> There is such concept - backward compatibility.
>> I understand
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>> deprecation of some interface doesn't break
>> backward
>>>>>>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>>>>>>> it leads to question^ what should I use instead
>> of this. And
>>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi is not answer for this
>> question. Because it
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>> brand
>>>>>>>>>>>>>>>>>>>>>>>>>> new API and it requires rewrite client code.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
>>>>>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal
>> MetricRegistry  to
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> exporters.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> No it is not. It's completely artificial thing
>> which allow
>>>>>>>>>>>>>>>>>> iterate
>>>>>>>>>>>>>>>>>>>> via
>>>>>>>>>>>>>>>>>>>>>>>>>> all metric registries. GridMetricManager
>> implements this
>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>>>>>> while it is not metric registry. Form user stand
>> point it is
>>>>>>>>>>>>>>>>>> very
>>>>>>>>>>>>>>>>>>>>>>>>>> strange interface which don't give me any
>> information about
>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>>>>>>> purpose and responsibilities.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
>>>>>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
>> caches for
>>>>>>>>>>>>> example.
>>>>>>>>>>>>>>>>>>>> There
>>>>>>>>>>>>>>>>>>>>>>>>>> are other entities with such flag.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way? Why you
>> ignore existing
>>>>>>>>>>>>>>>>>>>>>>>>>> functionality? It affects user expectations and
>> experience.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Yes? I'm working. Unfortunately we are not
>> synchronized in
>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>>>> context and I should redo all metrics related
>> changes in
>>>>>>>>>>>>> order
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>> merge it with my changes. Anyway, my change
>> doesn't solve all
>>>>>>>>>>>>>>>>>>>> problems
>>>>>>>>>>>>>>>>>>>>>>>>>> (e.g. it doesn't introduce IgniteMonitoring
>> facade).
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Unfortunately it will be just fix. In my
>> solution it is
>>>>>>>>>>>>>>>>>> redesign.
>>>>>>>>>>>>>>>>>>>> Stop
>>>>>>>>>>>>>>>>>>>>>>>>>> fixing issues, let's do things. It requires
>> deeper changes.
>>>>>>>>>>>>> My
>>>>>>>>>>>>>>>>>>>> changes
>>>>>>>>>>>>>>>>>>>>>>>>>> blocks AI 2.8 release because it big enough. So
>> it retargeted
>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> next release. And it is one more reason for
>> moving the
>>>>>>>>>>>>> changes
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> internal packages. And it isn't good news for me
>> because I
>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>> go
>>>>>>>>>>>>>>>>>>>>>>>>>> throughout pan and tiers of merge. But it is
>> right.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
>> compatibility.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
>> compatibility.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, I know. But they should not be exported by
>>>>>>>>>>>>>>>>>> MetricExporterSpi
>>>>>>>>>>>>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 3:37 PM Николай Ижиков <
>>>>>>>>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey, thanks for your opinion and your ownest
>> critisism.
>>>>>>>>>>>>>>>>>>>>>>>>>>> I can’t wait for your contribution.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of
>> the active
>>>>>>>>>>>>>>>>>>> reviewers
>>>>>>>>>>>>>>>>>>>> of the Metric API.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
>> deprecation of APIs
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
>> substitution.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't
>> recommend
>>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still
>> not-production ready.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> It’s ready.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the
>> public API
>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>>>>> solve the problem because this interface exposes
>> internal Metric
>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Not, its’ not.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Please, see
>> `org.apache.ignite.spi.metric.LongMetric` and
>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>> public interface.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> API of MetricRegistry is inconsistent.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> MetricRegistry is the internal API.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Feel free to create ticket for an issues with
>> it and I will
>>>>>>>>>>>>>>> try
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> fix it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal
>> MetricRegistry  to
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> exporters.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
>>>>>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
>>>>>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
>>>>>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
>> compatibility.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 15:09, Andrey Gura <
>> [hidden email]>
>>>>>>>>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
>> deprecation of APIs
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
>> substitution.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't
>> recommend
>>>>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still
>> not-production
>>>>>>>>>>>>>>> ready.
>>>>>>>>>>>>>>>>>>>> There
>>>>>>>>>>>>>>>>>>>>>>>>>>>> are some issues with it and usage of
>> ReadOnlyMetricRegistry
>>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>>>>>>>> just one of them.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the
>> public API
>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>>>>> solve
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the problem because this interface exposes
>> internal Metric
>>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementations. So your PR is incomplete.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Moreover, API of MetricRegistry is
>> inconsistent. E.g.
>>>>>>>>>>>>>>>>>>>> register(name,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> supplier, desc) method returns registered
>> metric for some
>>>>>>>>>>>>>>>>>> types
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> doesn't for other. register(metric) method is
>> inconsistent
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> sense of
>>>>>>>>>>>>>>>>>>>>>>>>>>>> metric naming. ReadOnlyMetricRegistry
>> interface is
>>>>>>>>>>>>> redundant.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi should be revised because it
>> absolutely
>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>>>> intuitive because it requires
>> ReadOnlyMetricRegistry and
>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>> purpose
>>>>>>>>>>>>>>>>>>>>>>>>>>>> is undefined.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> One more point. IEP-35 is still not fully
>> implemented. Some
>>>>>>>>>>>>>>>>>>>> things are
>>>>>>>>>>>>>>>>>>>>>>>>>>>> not taken into account. Exporters expose
>> metrics if they
>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>> disabled.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> JMX beans exposes values that don't confirm to
>> best
>>>>>>>>>>>>> practices
>>>>>>>>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>> Ubiquitous
>>>>>>>>>>>>>>> merics
>>>>>>>>>>>>>>>>>>>> lookup
>>>>>>>>>>>>>>>>>>>>>>>>>>>> from hash map instead of usage reference for
>> getting
>>>>>>>>>>>>> metrics
>>>>>>>>>>>>>>>>>>>> values
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (it is just performance issue). Also
>> IGNITE-11927 is not
>>>>>>>>>>>>>>>>>>>> implemented
>>>>>>>>>>>>>>>>>>>>>>>>>>>> which also changes interfaces significantly.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Let's just admit that the implementation is
>> immature and
>>>>>>>>>>>>> must
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> moved
>>>>>>>>>>>>>>>>>>>>>>>>>>>> to the internal packages.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> And because we already merged partially
>> implemented IEP to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> master
>>>>>>>>>>>>>>>>>>>>>>>>>>>> branch we *must move all currently public APIs
>> to the
>>>>>>>>>>>>>>> internal
>>>>>>>>>>>>>>>>>>>> API*
>>>>>>>>>>>>>>>>>>>>>>>>>>>> while it will not be ready for publication.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> And the last but not least. What is happening
>> indicates a
>>>>>>>>>>>>>>>>>>> immature
>>>>>>>>>>>>>>>>>>>>>>>>>>>> development process which must be revised. I
>> don't want
>>>>>>>>>>>>>>>>>> discuss
>>>>>>>>>>>>>>>>>>>> it in
>>>>>>>>>>>>>>>>>>>>>>>>>>>> this thread but we must not allow merge of
>> change to the
>>>>>>>>>>>>>>>>>> master
>>>>>>>>>>>>>>>>>>>> branch
>>>>>>>>>>>>>>>>>>>>>>>>>>>> before it will completed, that is we must use
>> feature
>>>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>>>> full IEP not only for particular tickets. And
>> also we
>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>>>>>>>>>> reformulate IEP process in order to avoid
>> things like this.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>> https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:49 PM Николай
>> Ижиков <
>>>>>>>>>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alex.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK, I may leverage your experience and create
>> pure Java
>>>>>>>>>>>>> API.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ticket [1] created.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But, personally, I don’t agree with you.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ignite has dozens of the API that
>> theoretically have a
>>>>>>>>>>>>> usage
>>>>>>>>>>>>>>>>>>>> scenario, but in real-world have 0 custom
>> implementation and
>>>>>>>>>>>>> usages.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Moreover, many APIs that were created with
>> the intentions
>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>> mentioned is abandoned now and confuses users.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can just see count of the tests we just
>> mute on the
>>>>>>>>>>>>> TC.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Can you, please, take a look at the fix
>> regarding puck API
>>>>>>>>>>>>>>>>>>> issue
>>>>>>>>>>>>>>>>>>>> you mentioned in your first letter [2], [3]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
>> https://issues.apache.org/jira/browse/IGNITE-12553
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [2]
>> https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [3]
>> https://issues.apache.org/jira/browse/IGNITE-12552
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 12:12, Alexey Goncharuk <
>>>>>>>>>>>>>>>>>>>> [hidden email]> написал(а):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nikolay,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why do you think this is a wrong usage
>> pattern? From the
>>>>>>>>>>>>>>> top
>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>> my head,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here is a few cases of direct metric API
>> usage that I
>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> being used in production:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom task execution scheduling service
>> with load
>>>>>>>>>>>>>>>>>>>> balancing based on
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> utilization metrics readings from Java code
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * Cleanup task trigger based on metrics
>> readings
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom health-check endpoint for an
>> application with
>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>> embedded
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ignite node for Kubernetes/Spring
>> Application/etc
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>>

[Maxim Muzafarov]

Folks,


Will it be better to schedule an ASF Slack call to choose the best
option which we have? Since this discussion thread is valuable for 2.8
release and we do not have a strong consensus here.

How about 30-th January 16-00 MSK time?

On Mon, 27 Jan 2020 at 16:37, Nikolay Izhikov <[hidden email]> wrote:

>
> > it's better to remove deprecation for the old APIs in AI 2.8
>
> Are you suggest to have 2 concurrent metrics implementations(both not deprecated)?
>
> > Let's say I am writing a custom exporter in binary format and I need to write the number of exported metrics in a packet beforehand.
>
> This an `MetricExporterSPI` implementation task.
> Exporter has the listeners that can be used to track all registry events - creation, removal
>
> > There is no separation on public and internal metrics
>
> I think we should write in the documentation that ANY metric can be changed.
> We will try to keep them, but if we found that some metric doesn’t required any more or implemented in the wrong way - we can remove it.
>
> > Will we allow users to register their own metrics?
>
> No. Why we should considering this feature?
>
> > It's still not clear how a user will map old interfaces and methods to the new metric names.
>
> With the documentation.
> We can write separate deprecation comment for each metric providing method.
>
> > I just want to remove the deprecations on the classes for which there is no a well-defined replacement.
>
> Well-defined replacement for these classes exists.
>
> > 27 янв. 2020 г., в 16:21, Alexey Goncharuk <[hidden email]> написал(а):
> >
> > Nikolay,
> >
> > I've reviewed your changes and I tend to agree with Andrey, it's better to
> > remove deprecation for the old APIs in AI 2.8 and discuss and merge the new
> > facade (IGNITE-12553) in a more calm and structured way. My observations on
> > the changes:
> >
> >   - I am not sure if Iterable would suffice both for the exporter and
> >   public APIs. Should we provide a way to know the number of metrics and
> >   registries in advance? Let's say I am writing a custom exporter in binary
> >   format and I need to write the number of exported metrics in a packet
> >   beforehand.
> >   - There is no separation on public and internal metrics, when public
> >   metrics preserve their name and semantics, and internal metrics may change.
> >   I remember we discussed this, but it's not reflected in the APIs in any way.
> >   - Will we allow users to register their own metrics? Again I remember we
> >   discussed a possibility for this. If so, why the registry is called
> >   'ReadyOnly'?
> >   - It's still not clear how a user will map old interfaces and methods to
> >   the new metric names.
> >
> > As you can see in the original message, I am not pushing for the new APIs
> > in the nearest release, I just want to remove the deprecations on the
> > classes for which there is no a well-defined replacement.
> >
> > пн, 27 янв. 2020 г. в 15:56, Maxim Muzafarov <[hidden email]>:
> >
> >> Folks,
> >>
> >>
> >> I'm sorry for not being too attentive to the whole thread discussion
> >> and maybe missing some details.
> >>
> >> But... who will perform the review of [1] issue?
> >> Will we merge it to 2.8? (hope so)
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-12553
> >> [IEP-35] public Java metric API
> >>
> >> On Sat, 25 Jan 2020 at 11:43, Николай Ижиков <[hidden email]> wrote:
> >>>
> >>> Andrey.
> >>>
> >>> With this API we are trying to fill the GAP Alexey pointed out at the
> >> start of this discussion.
> >>> I think it worth to be reviewed and merged.
> >>>
> >>> Can we, please, come back to the discussion of the changes itself?
> >>> I think API changes should be discussed in the other thread.
> >>>
> >>>> Why do you think this is a wrong usage pattern? From the top of my
> >> head, here is a few cases of direct metric API usage that I know are
> >> currently being used in production:
> >>>> * A custom task execution scheduling service with load balancing based
> >> on utilization metrics readings from Java code
> >>>> * Cleanup task trigger based on metrics readings
> >>>> * A custom health-check endpoint for an application with an embedded
> >> Ignite node for Kubernetes/Spring Application/etc
> >>>
> >>> [1] https://github.com/apache/ignite/pull/7283
> >>>
> >>>> 24 янв. 2020 г., в 18:08, Andrey Gura <[hidden email]> написал(а):
> >>>>
> >>>>> My point - that your contribution that took a long time, already,
> >> can’t be an argument to postpone creation of the API in the current release.
> >>>>
> >>>> Argument is not about time. But about API which is known will be
> >> changed.
> >>>> Second argument: why we should add this experimental API to the
> >>>> already existing experimental API? Just to making API more
> >>>> experimental? As I told already it is commit for commit and doesn't
> >>>> bring any value but brings some inconvenience to me (e.g. merge
> >>>> problems).
> >>>>
> >>>> BTW, does it exist issue about marking IEP-35 API's as experimental?
> >>>>
> >>>> On Thu, Jan 23, 2020 at 8:33 PM Николай Ижиков <[hidden email]>
> >> wrote:
> >>>>>
> >>>>>> You want say didn't discuss?
> >>>>>
> >>>>> Yes.
> >>>>>
> >>>>>> Secondly, yes it took a lot of time due to a lot of changes. Is it
> >> problem?
> >>>>>
> >>>>> No, of course.
> >>>>> My point - that your contribution that took a long time, already,
> >> can’t be an argument to postpone creation of the API in the current release.
> >>>>>
> >>>>>
> >>>>>> 23 янв. 2020 г., в 18:11, Andrey Gura <[hidden email]> написал(а):
> >>>>>>
> >>>>>>> We don’t discuss your changes and your proposals for the Metric API.
> >>>>>>
> >>>>>> You want say didn't discuss? Actually we did it [1] but you told ok
> >>>>>> let's see code :)
> >>>>>>
> >>>>>>> So I don’t think we can make the existence of some PR is an
> >> argument to introduce(or not introduce) this facade.
> >>>>>>
> >>>>>> You definitely right in case of competition development. But I think
> >>>>>> that collaborative development is more effective. Isn't it?
> >>>>>>
> >>>>>>> Moreover, As far as I know, you developing changes for the Metric
> >> API for 5 months without public discussion, for now. Let's start it.
> >>>>>>
> >>>>>> Firsty, with discussion. See above.
> >>>>>> Secondly, yes it took a lot of time due to a lot of changes. Is it
> >> problem?
> >>>>>>
> >>>>>>> Let’s do the following:
> >>>>>>> 1. Review `IgniteMetric` facade and introduce it to the users as an
> >> experimental API.
> >>>>>>
> >>>>>> It just doesn't make sense. Just commit for commit.
> >>>>>>
> >>>>>>> 2. Discuss your proposal to the Metric API in the separate thread
> >> you are referencing.
> >>>>>>
> >>>>>> You a re welcome to thread [1] again. But please, take into account.
> >>>>>> because discussion is postponed by you it's late enough to discuss
> >>>>>> proposed solution. But of course I'll answer on your questions and
> >>>>>> will be glade to your comments and suggestions.
> >>>>>>
> >>>>>>> I think we should start a discussion from the simplified
> >> explanation of:
> >>>>>>> 1. API intentions - What we want to gain with it? What is our focus?
> >>>>>>> 2. Simple, minimal example of API main interfaces and desired
> >> usages.
> >>>>>>
> >>>>>> All this already described at [1]. You also can take a look on PR
> >> (see
> >>>>>> MetricSource implementations, there are complex and simple ones).
> >>>>>>
> >>>>>> [1]
> >> http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Metrics-management-in-Ignite-tp43243.html
> >>>>>>
> >>>>>> On Thu, Jan 23, 2020 at 5:42 PM Николай Ижиков <[hidden email]>
> >> wrote:
> >>>>>>>
> >>>>>>> Andrey.
> >>>>>>>
> >>>>>>>> IGNITE-11927 implementation so your changes are incompatible with
> >> my changes
> >>>>>>>
> >>>>>>> We don’t discuss your changes and your proposals for the Metric API.
> >>>>>>> So I don’t think we can make the existence of some PR is an
> >> argument to introduce(or not introduce) this facade.
> >>>>>>> Moreover, As far as I know, you developing changes for the Metric
> >> API for 5 months without public discussion, for now. Let's start it.
> >>>>>>>
> >>>>>>> Let’s do the following:
> >>>>>>>
> >>>>>>> 1. Review `IgniteMetric` facade and introduce it to the users as an
> >> experimental API.
> >>>>>>>
> >>>>>>> 2. Discuss your proposal to the Metric API in the separate thread
> >> you are referencing.
> >>>>>>>
> >>>>>>> I think we should start a discussion from the simplified
> >> explanation of:
> >>>>>>>
> >>>>>>> 1. API intentions - What we want to gain with it? What is our focus?
> >>>>>>> 2. Simple, minimal example of API main interfaces and desired
> >> usages.
> >>>>>>>
> >>>>>>> This will help to the community and me personally better understand
> >> your idea and share feedback.
> >>>>>>>
> >>>>>>> Thanks.
> >>>>>>>
> >>>>>>>> 23 янв. 2020 г., в 17:15, Andrey Gura <[hidden email]>
> >> написал(а):
> >>>>>>>>
> >>>>>>>> Nikolay,
> >>>>>>>>
> >>>>>>>> as I wrote early in this thread API significantly changed during
> >>>>>>>> IGNITE-11927 implementation so your changes are incompatible with
> >> my
> >>>>>>>> changes.
> >>>>>>>>
> >>>>>>>> ReadOnlyMetricRegistry will be removed at all (still exists in a
> >>>>>>>> couple of places where it uses).
> >>>>>>>>
> >>>>>>>> Also I don't want to introduce IgniteMetric facade in this rush. In
> >>>>>>>> current implementation this interface just provides access to the
> >>>>>>>> ReadOnlyMetricManager instance (which will be removed) but it is
> >> not
> >>>>>>>> enough.
> >>>>>>>>
> >>>>>>>> I agree with Denis. We should mark current API as experimental and
> >>>>>>>> continue IEP-35 development. See my process proposal [1] described
> >>>>>>>> early this thread. We can release Apache Ignite 2.8.1 specially for
> >>>>>>>> this changes.
> >>>>>>>> Public APIs require deeper thinking in order to provide
> >> comprehensive,
> >>>>>>>> consistent and convenient way of metrics management for end users.
> >>>>>>>>
> >>>>>>>> Let's add IgniteExperimental, release 2.8 and finish metrics
> >> related
> >>>>>>>> issues after it.
> >>>>>>>>
> >>>>>>>> [1]
> >> http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-tp45146p45185.html
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Jan 22, 2020 at 5:21 PM Николай Ижиков <
> >> [hidden email]> wrote:
> >>>>>>>>>
> >>>>>>>>> Hello, Igniters.
> >>>>>>>>>
> >>>>>>>>> * IGNITE-12552: Move ReadOnlyMetricRegistry to public API merged
> >> to the master and cherry-picked to the 2.8.
> >>>>>>>>> So the main issue with the Metric API solved.
> >>>>>>>>>
> >>>>>>>>> * I raised the PR [1] to fix second issue with the new Metric
> >> API: absence of the public Java API to get metrics.
> >>>>>>>>> This PR introduces the following changes:
> >>>>>>>>>
> >>>>>>>>> 1. IgniteMetric interface created: it provides Java API to access
> >> Ignite metrics created with the new Metric API.
> >>>>>>>>>
> >>>>>>>>> ```
> >>>>>>>>> public interface IgniteMetric extends
> >> Iterable<ReadOnlyMetricRegistry> {
> >>>>>>>>> @Nullable ReadOnlyMetricRegistry registry(String name);
> >>>>>>>>> }
> >>>>>>>>> ```
> >>>>>>>>>
> >>>>>>>>> 2. All deprecation javadocs regarding metrics now reference to
> >> the public IgniteMetric instead of internal GridMetricManager:
> >>>>>>>>>
> >>>>>>>>>> @deprecated Use {@link IgniteMetric} instead.
> >>>>>>>>>
> >>>>>>>>> 3. Tests refactored to use IgniteMetric instead of
> >> GridMetricManager when possible.
> >>>>>>>>>
> >>>>>>>>> Please, review.
> >>>>>>>>>
> >>>>>>>>> [1]  https://github.com/apache/ignite/pull/7283
> >>>>>>>>>
> >>>>>>>>>> 21 янв. 2020 г., в 17:51, Николай Ижиков <[hidden email]>
> >> написал(а):
> >>>>>>>>>>
> >>>>>>>>>> Hello, Igniters.
> >>>>>>>>>>
> >>>>>>>>>> Alexey approved my PR [1] regarding fixing public API for metric
> >> exporters.
> >>>>>>>>>> I’m waiting for a bot visa and merge this PR.
> >>>>>>>>>>
> >>>>>>>>>> As we discussed, the metrics API will be marked with
> >> IgniteExperimental annotation.
> >>>>>>>>>>
> >>>>>>>>>> If anyone has any objection to this plan, please provide your
> >> feedback.
> >>>>>>>>>>
> >>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>
> >>>>>>>>>>> 21 янв. 2020 г., в 13:45, Николай Ижиков <
> >> [hidden email]> написал(а):
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks, for the review Alexey.
> >>>>>>>>>>>
> >>>>>>>>>>> I will fix your comment and  try to implement Monitoring
> >> facade, shortly.
> >>>>>>>>>>>
> >>>>>>>>>>>> 21 янв. 2020 г., в 13:32, Alexey Goncharuk <
> >> [hidden email]> написал(а):
> >>>>>>>>>>>>
> >>>>>>>>>>>> Nikolay,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I left a single comment in the PR about the histogram metric.
> >> I think the
> >>>>>>>>>>>> API looks much cleaner now.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I will take care of the @IgniteExperimental annotation.
> >>>>>>>>>>>>
> >>>>>>>>>>>> пн, 20 янв. 2020 г. в 20:55, Николай Ижиков <
> >> [hidden email]>:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Alexey.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> PR [1] is waiting for your review.
> >>>>>>>>>>>>> Please, take a look.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I think we should do the following before 2.8 release
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> * Introduce new @IgniteExperimental annotation as discussed.
> >>>>>>>>>>>>> * Mark Monitoring API with it.
> >>>>>>>>>>>>> * merge «[IEP-35] Expose MetricRegistry to the public API» to
> >> 2.8
> >>>>>>>>>>>>> * merge «[IEP-35] public Java metric API» to 2.8
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk <
> >> [hidden email]>
> >>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Nikolay,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Should we wait for both of the tickets given that we agreed
> >> that we are
> >>>>>>>>>>>>>> putting an experimental marker on the new APIs? I'm ok to
> >> fix only the
> >>>>>>>>>>>>>> first one and add the experimental marker so that we do not
> >> delay 2.8
> >>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков <
> >> [hidden email]>:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Andrey.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Let’s move from the long letters to the code.
> >>>>>>>>>>>>>>> If you want to change API - please, propose this changes.
> >>>>>>>>>>>>>>> I think everybody wins if we make our API better.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Please, describe proposed changes.
> >>>>>>>>>>>>>>> It would be great if you have some examples or PR for it.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> As for this release, I have plans to contribute tickets
> >>>>>>>>>>>>>>> «[IEP-35] Expose MetricRegistry to the public API» [1] and
> >>>>>>>>>>>>>>> «[IEP-35] public Java metric API» [2] for it.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Any objections on it?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-12553
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 20 янв. 2020 г., в 13:08, Andrey Gura <[hidden email]>
> >> написал(а):
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It solves problem.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
> >>>>>>>>>>>>>>>> <[hidden email]> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> After giving it some thought, I agree with Denis - there
> >> is nothing
> >>>>>>>>>>>>>>> wrong
> >>>>>>>>>>>>>>>>> with exposing the new APIs, we just need to make it clear
> >> that we are
> >>>>>>>>>>>>>>> still
> >>>>>>>>>>>>>>>>> going to change it.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Should we Introduce something like @IgniteExperimental
> >> annotation (I
> >>>>>>>>>>>>>>>>> believe it has been discussed a dozen of times on the
> >> dev-list)?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov <
> >> [hidden email]>:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> +1 to mark feature or whole release as EA.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> пт, 17 янв. 2020 г., 23:00 Denis Magda <
> >> [hidden email]>:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Folks, if you don't mind I'll share some
> >> thoughts/suggestions as an
> >>>>>>>>>>>>>>>>>>> observer who was not involved in the feature
> >> development.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> It's absolutely 'ok' to deprecate an API that is
> >> replaced with a
> >>>>>>>>>>>>> much
> >>>>>>>>>>>>>>>>>>> better version. However, we should do this only when
> >> the new APIs
> >>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>> production-ready. If there are still many limitations
> >> or open items
> >>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>>> don't deprecate anything that exists and release the
> >> new APIs
> >>>>>>>>>>>>>>> labeling as
> >>>>>>>>>>>>>>>>>>> early access. What if release the improvements labeling
> >> as EA
> >>>>>>>>>>>>> instead
> >>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>> hiding them completely?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I would also encourage us to put aside emotions, don't
> >> blame or
> >>>>>>>>>>>>> point
> >>>>>>>>>>>>>>>>>>> fingers. This IEP is a great initiative and you both
> >> have already
> >>>>>>>>>>>>>>> done a
> >>>>>>>>>>>>>>>>>>> tremendous job by developing, architecting and
> >> reviewing changes.
> >>>>>>>>>>>>>>> Just be
> >>>>>>>>>>>>>>>>>>> respectful. Nobody is trying to block the feature from
> >> being
> >>>>>>>>>>>>> released.
> >>>>>>>>>>>>>>>>>>> Everyone would be glad to tap into improvements and
> >> start using them
> >>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>> prod. But if more time is needed for the GA let's
> >> reiterate a bit.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>> Denis
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков <
> >>>>>>>>>>>>> [hidden email]>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Also I agree with Alexey about introducing public
> >> IgniteMonitoring
> >>>>>>>>>>>>>>>>>>> facade
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> This is not an issue with the API.
> >>>>>>>>>>>>>>>>>>>> Just the new feature that doesn’t affects API.
> >>>>>>>>>>>>>>>>>>>> Moreover, I create a ticket to fix it, already.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> It's right. But if you add checking of
> >> statisticsEnabling property
> >>>>>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>>>> test will fail. It's just not good tests.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> My changes doesn’t affect any `staticticsEnabled`
> >> property.
> >>>>>>>>>>>>>>>>>>>> I don’ understand your point here.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> It’s not redundant.
> >>>>>>>>>>>>>>>>>>>> It required for exporters and provide read only access
> >> to
> >>>>>>>>>>>>>>>>>> MetricRegistry
> >>>>>>>>>>>>>>>>>>>> existing in the node.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> MetricExporterSpi that requires
> >> ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that
> >> forces user
> >>>>>>>>>>>>> use
> >>>>>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Why this is issue?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> It’s consistent.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct
> >> reference
> >>>>>>>>>>>>>>>>>>>>> (performance problem).
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 1. We(You and I) did this choice together to simplify
> >> creation of
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>> metrics.
> >>>>>>>>>>>>>>>>>>>> 2. This is not public API issue.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I don’t ignore this flag.
> >>>>>>>>>>>>>>>>>>>> It just doesn’t exists in new framework(because of
> >> scope).
> >>>>>>>>>>>>>>>>>>>> I don’t think it’s an issue.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy
> >> best MBeans
> >>>>>>>>>>>>>>>>>>> practices.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Please, clarify your statement.
> >>>>>>>>>>>>>>>>>>>> What is best MBeans practices you are talking about?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> How this can be API issue?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 20:52, Andrey Gura <
> >> [hidden email]>
> >>>>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are
> >> fixed with my
> >>>>>>>>>>>>>>> PR
> >>>>>>>>>>>>>>>>>>>> [1].
> >>>>>>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are
> >> blocker for the
> >>>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> As I mentioned already IGNITE-11927 is part of IEP-35
> >> and
> >>>>>>>>>>>>>>>>>>>>> implementation seriously affects API's. Also I agree
> >> with Alexey
> >>>>>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>>>>>>> introducing public IgniteMonitoring facade. So thiss
> >> PR doesn't
> >>>>>>>>>>>>> fix
> >>>>>>>>>>>>>>>>>>>>> all issues.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
> >>>>>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this
> >> contribution.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> It's right. But if you add checking of
> >> statisticsEnabling property
> >>>>>>>>>>>>>>>>>>>>> then test will fail. It's just not good tests.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create
> >> a ticket I
> >>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>>>> fix
> >>>>>>>>>>>>>>>>>>>> it ASAP.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I already fix it all in IGNITE-11927
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't
> >> hide major
> >>>>>>>>>>>>>>>>>>>> contribution from the user just because your second
> >> guess «I don’t
> >>>>>>>>>>>>>>> like
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> API I just reviewed and approved».
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> We should move the product forward with with really
> >> finished
> >>>>>>>>>>>>>>>>>> features,
> >>>>>>>>>>>>>>>>>>>>> not pieces of features.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> So I am against this proposal.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> It is not argument.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API
> >> change and
> >>>>>>>>>>>>> discuss
> >>>>>>>>>>>>>>>>>>> them.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> We can prepare it together. But we can't block
> >> release.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> >>>>>>>>>>>>>>>>>>>>>> What is *ALL* problems?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>>>>>>> MetricExporterSpi that requires
> >> ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that
> >> forces user
> >>>>>>>>>>>>> use
> >>>>>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> >>>>>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
> >>>>>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct
> >> reference
> >>>>>>>>>>>>>>>>>>>>> (performance problem).
> >>>>>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> >>>>>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy
> >> best MBeans
> >>>>>>>>>>>>>>>>>>> practices.
> >>>>>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> It's enough I believe.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:28 PM Николай Ижиков <
> >>>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Andrey.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are
> >> fixed with my
> >>>>>>>>>>>>> PR
> >>>>>>>>>>>>>>>>>>> [1].
> >>>>>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker
> >> for the
> >>>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this
> >> contribution.
> >>>>>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create
> >> a ticket I
> >>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>>>> fix
> >>>>>>>>>>>>>>>>>>>> it ASAP.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't
> >> hide major
> >>>>>>>>>>>>>>>>>>>> contribution from the user just because your second
> >> guess «I don’t
> >>>>>>>>>>>>>>> like
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> API I just reviewed and approved».
> >>>>>>>>>>>>>>>>>>>>>> So I am against this proposal.
> >>>>>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API
> >> change and
> >>>>>>>>>>>>> discuss
> >>>>>>>>>>>>>>>>>>> them.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> What is *ALL* problems?
> >>>>>>>>>>>>>>>>>>>>>> Seems, we never be able to solve *ALL* problems.
> >>>>>>>>>>>>>>>>>>>>>> But, we should move the product forward.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> As for your steps [1-6].
> >>>>>>>>>>>>>>>>>>>>>> I’m always following these steps during my
> >> contribution.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 19:08, Andrey Gura <
> >> [hidden email]>
> >>>>>>>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The discussion is hot and can be endless. So in
> >> separate post I
> >>>>>>>>>>>>>>>>>> want
> >>>>>>>>>>>>>>>>>>>>>>> propose my solution.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>>>>>>>>>>> 2. Create special feature branch B.
> >>>>>>>>>>>>>>>>>>>>>>> 3. In branch B will be merged IGNITE-11927
> >>>>>>>>>>>>>>>>>>>>>>> 4. Because IGNITE-11927 doesn't solve all problems
> >> we should
> >>>>>>>>>>>>>>>>>> propose
> >>>>>>>>>>>>>>>>>>>>>>> solution and implement it in branch B.
> >>>>>>>>>>>>>>>>>>>>>>> 5. Testing, usability testing, fixing, etc
> >> iteratively.
> >>>>>>>>>>>>>>>>>>>>>>> 6. Merge it to master and in new release branch if
> >> needed.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Independent step. There are some problem which
> >> should be fixed
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>> 2.8
> >>>>>>>>>>>>>>>>>>>>>>> before release otherwise we introduce problems with
> >>>>>>>>>>>>> compatibility
> >>>>>>>>>>>>>>>>>>>>>>> which will haunt us till next major release. I'll
> >> create
> >>>>>>>>>>>>> tickets.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:03 PM Andrey Gura <
> >> [hidden email]>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires
> >> rewrite client
> >>>>>>>>>>>>>>> code.
> >>>>>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> >>>>>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove
> >> in the next
> >>>>>>>>>>>>>>> major
> >>>>>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> We don't know anything about development processes
> >> our users. I
> >>>>>>>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>>>>>>>>>> admit that process could require that deprecated
> >> methods/APIs
> >>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>> allowed for example.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange
> >> interface which
> >>>>>>>>>>>>> don't
> >>>>>>>>>>>>>>>>>>> give
> >>>>>>>>>>>>>>>>>>>> me any information about it’s purpose and
> >> responsibilities.
> >>>>>>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1]
> >> more clear:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I understand this. But I'm not Ignite user, I'm
> >> Ignite
> >>>>>>>>>>>>> developer.
> >>>>>>>>>>>>>>>>>>> The
> >>>>>>>>>>>>>>>>>>>>>>>> key moment in my message *from user stand point*.
> >> From my point
> >>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>> view it is very not intuitive solution and this
> >> interface is
> >>>>>>>>>>>>>>>>>>>>>>>> redundant.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
> >> caches for
> >>>>>>>>>>>>> example.
> >>>>>>>>>>>>>>>>>>>> There are other entities with such flag.
> >>>>>>>>>>>>>>>>>>>>>>>>> They still works as expected.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Actually not. I fixed many such issues during
> >> IGNITE-11927
> >>>>>>>>>>>>>>>>>>>> implementation.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
> >>>>>>>>>>>>>>>>>>>>>>>>> Because of the scope.
> >>>>>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the
> >> matter of the
> >>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I talk not about ability. I talk about ignored
> >> existing
> >>>>>>>>>>>>>>>>>>> functionality.
> >>>>>>>>>>>>>>>>>>>>>>>> So scope is not case here.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by
> >> MetricExporterSpi
> >>>>>>>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter
> >> to decide.
> >>>>>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while
> >> OpenCensus
> >>>>>>>>>>>>> exporter
> >>>>>>>>>>>>>>>>>>>> can’t.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Actually list is not metric at all as I already
> >> told.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 5:26 PM Николай Ижиков <
> >>>>>>>>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Andrey.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires
> >> rewrite client
> >>>>>>>>>>>>>>> code.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> >>>>>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove
> >> in the next
> >>>>>>>>>>>>>>> major
> >>>>>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange
> >> interface which
> >>>>>>>>>>>>> don't
> >>>>>>>>>>>>>>>>>>> give
> >>>>>>>>>>>>>>>>>>>> me any information about it’s purpose and
> >> responsibilities.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more
> >> clear:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Each SPI would have a `ReadOnlyMetricManager`
> >> which provides
> >>>>>>>>>>>>>>>>>> access
> >>>>>>>>>>>>>>>>>>>> to collection of `ReadOnlyMetricRegistry`
> >>>>>>>>>>>>>>>>>>>>>>>>> which has a collection of `Metric`.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> So we reflects two-level structure we have in the
> >> internal API
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> GridMetricManager -> Collection[MetricRegistry] ->
> >>>>>>>>>>>>>>>>>>> Collection[Metric]
> >>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricManager ->
> >> Collection[ReadOnlyMetricRegistry] ->
> >>>>>>>>>>>>>>>>>>>> Collection[Metric]
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
> >> caches for
> >>>>>>>>>>>>> example.
> >>>>>>>>>>>>>>>>>>>> There are other entities with such flag.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> They still works as expected.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Because of the scope.
> >>>>>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the
> >> matter of the
> >>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by
> >> MetricExporterSpi
> >>>>>>>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter
> >> to decide.
> >>>>>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while
> >> OpenCensus
> >>>>>>>>>>>>> exporter
> >>>>>>>>>>>>>>>>>>>> can’t.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >> https://github.com/apache/ignite/pull/7269/files#diff-0ae5657231fc4c1f650493b02190b81bR25
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 16:57, Andrey Gura <
> >> [hidden email]>
> >>>>>>>>>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of
> >> the active
> >>>>>>>>>>>>>>>>>>> reviewers
> >>>>>>>>>>>>>>>>>>>> of the Metric API.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Yes. But if I'm not missing some thing you were
> >> major
> >>>>>>>>>>>>> developer
> >>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>>>> Metric API :) Shit happens. And it happened.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
> >> deprecation of APIs
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
> >> substitution.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> There is such concept - backward compatibility.
> >> I understand
> >>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>>>>> deprecation of some interface doesn't break
> >> backward
> >>>>>>>>>>>>>>>>>> compatibility
> >>>>>>>>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>>>>>>>>>>>> it leads to question^ what should I use instead
> >> of this. And
> >>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi is not answer for this
> >> question. Because it
> >>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>> brand
> >>>>>>>>>>>>>>>>>>>>>>>>>> new API and it requires rewrite client code.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal
> >> MetricRegistry  to
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> exporters.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> No it is not. It's completely artificial thing
> >> which allow
> >>>>>>>>>>>>>>>>>> iterate
> >>>>>>>>>>>>>>>>>>>> via
> >>>>>>>>>>>>>>>>>>>>>>>>>> all metric registries. GridMetricManager
> >> implements this
> >>>>>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>>>>> while it is not metric registry. Form user stand
> >> point it is
> >>>>>>>>>>>>>>>>>> very
> >>>>>>>>>>>>>>>>>>>>>>>>>> strange interface which don't give me any
> >> information about
> >>>>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>>>>>>>>> purpose and responsibilities.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
> >> caches for
> >>>>>>>>>>>>> example.
> >>>>>>>>>>>>>>>>>>>> There
> >>>>>>>>>>>>>>>>>>>>>>>>>> are other entities with such flag.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way? Why you
> >> ignore existing
> >>>>>>>>>>>>>>>>>>>>>>>>>> functionality? It affects user expectations and
> >> experience.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Yes? I'm working. Unfortunately we are not
> >> synchronized in
> >>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>>>>>>> context and I should redo all metrics related
> >> changes in
> >>>>>>>>>>>>> order
> >>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>> merge it with my changes. Anyway, my change
> >> doesn't solve all
> >>>>>>>>>>>>>>>>>>>> problems
> >>>>>>>>>>>>>>>>>>>>>>>>>> (e.g. it doesn't introduce IgniteMonitoring
> >> facade).
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Unfortunately it will be just fix. In my
> >> solution it is
> >>>>>>>>>>>>>>>>>> redesign.
> >>>>>>>>>>>>>>>>>>>> Stop
> >>>>>>>>>>>>>>>>>>>>>>>>>> fixing issues, let's do things. It requires
> >> deeper changes.
> >>>>>>>>>>>>> My
> >>>>>>>>>>>>>>>>>>>> changes
> >>>>>>>>>>>>>>>>>>>>>>>>>> blocks AI 2.8 release because it big enough. So
> >> it retargeted
> >>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>> next release. And it is one more reason for
> >> moving the
> >>>>>>>>>>>>> changes
> >>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>> internal packages. And it isn't good news for me
> >> because I
> >>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>>> go
> >>>>>>>>>>>>>>>>>>>>>>>>>> throughout pan and tiers of merge. But it is
> >> right.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
> >> compatibility.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
> >> compatibility.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Yes, I know. But they should not be exported by
> >>>>>>>>>>>>>>>>>> MetricExporterSpi
> >>>>>>>>>>>>>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 3:37 PM Николай Ижиков <
> >>>>>>>>>>>>>>>>>>> [hidden email]>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey, thanks for your opinion and your ownest
> >> critisism.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> I can’t wait for your contribution.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of
> >> the active
> >>>>>>>>>>>>>>>>>>> reviewers
> >>>>>>>>>>>>>>>>>>>> of the Metric API.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
> >> deprecation of APIs
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
> >> substitution.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't
> >> recommend
> >>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still
> >> not-production ready.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> It’s ready.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the
> >> public API
> >>>>>>>>>>>>> doesn't
> >>>>>>>>>>>>>>>>>>>> solve the problem because this interface exposes
> >> internal Metric
> >>>>>>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Not, its’ not.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Please, see
> >> `org.apache.ignite.spi.metric.LongMetric` and
> >>>>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>>>>> public interface.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> API of MetricRegistry is inconsistent.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> MetricRegistry is the internal API.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Feel free to create ticket for an issues with
> >> it and I will
> >>>>>>>>>>>>>>> try
> >>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> fix it.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal
> >> MetricRegistry  to
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> exporters.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> >>>>>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
> >> compatibility.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 15:09, Andrey Gura <
> >> [hidden email]>
> >>>>>>>>>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
> >> deprecation of APIs
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
> >> substitution.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't
> >> recommend
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still
> >> not-production
> >>>>>>>>>>>>>>> ready.
> >>>>>>>>>>>>>>>>>>>> There
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> are some issues with it and usage of
> >> ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> just one of them.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the
> >> public API
> >>>>>>>>>>>>> doesn't
> >>>>>>>>>>>>>>>>>>>> solve
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the problem because this interface exposes
> >> internal Metric
> >>>>>>>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> implementations. So your PR is incomplete.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Moreover, API of MetricRegistry is
> >> inconsistent. E.g.
> >>>>>>>>>>>>>>>>>>>> register(name,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> supplier, desc) method returns registered
> >> metric for some
> >>>>>>>>>>>>>>>>>> types
> >>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> doesn't for other. register(metric) method is
> >> inconsistent
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>> sense of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> metric naming. ReadOnlyMetricRegistry
> >> interface is
> >>>>>>>>>>>>> redundant.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi should be revised because it
> >> absolutely
> >>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> intuitive because it requires
> >> ReadOnlyMetricRegistry and
> >>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>>> purpose
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> is undefined.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> One more point. IEP-35 is still not fully
> >> implemented. Some
> >>>>>>>>>>>>>>>>>>>> things are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> not taken into account. Exporters expose
> >> metrics if they
> >>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>> disabled.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> JMX beans exposes values that don't confirm to
> >> best
> >>>>>>>>>>>>> practices
> >>>>>>>>>>>>>>>>>>> [1].
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >> Ubiquitous
> >>>>>>>>>>>>>>> merics
> >>>>>>>>>>>>>>>>>>>> lookup
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> from hash map instead of usage reference for
> >> getting
> >>>>>>>>>>>>> metrics
> >>>>>>>>>>>>>>>>>>>> values
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> (it is just performance issue). Also
> >> IGNITE-11927 is not
> >>>>>>>>>>>>>>>>>>>> implemented
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> which also changes interfaces significantly.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Let's just admit that the implementation is
> >> immature and
> >>>>>>>>>>>>> must
> >>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>> moved
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> to the internal packages.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> And because we already merged partially
> >> implemented IEP to
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> master
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> branch we *must move all currently public APIs
> >> to the
> >>>>>>>>>>>>>>> internal
> >>>>>>>>>>>>>>>>>>>> API*
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> while it will not be ready for publication.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> And the last but not least. What is happening
> >> indicates a
> >>>>>>>>>>>>>>>>>>> immature
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> development process which must be revised. I
> >> don't want
> >>>>>>>>>>>>>>>>>> discuss
> >>>>>>>>>>>>>>>>>>>> it in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> this thread but we must not allow merge of
> >> change to the
> >>>>>>>>>>>>>>>>>> master
> >>>>>>>>>>>>>>>>>>>> branch
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> before it will completed, that is we must use
> >> feature
> >>>>>>>>>>>>>>> branches
> >>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> full IEP not only for particular tickets. And
> >> also we
> >>>>>>>>>>>>> should
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> reformulate IEP process in order to avoid
> >> things like this.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >> https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:49 PM Николай
> >> Ижиков <
> >>>>>>>>>>>>>>>>>>>> [hidden email]> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alex.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK, I may leverage your experience and create
> >> pure Java
> >>>>>>>>>>>>> API.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ticket [1] created.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> But, personally, I don’t agree with you.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ignite has dozens of the API that
> >> theoretically have a
> >>>>>>>>>>>>> usage
> >>>>>>>>>>>>>>>>>>>> scenario, but in real-world have 0 custom
> >> implementation and
> >>>>>>>>>>>>> usages.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Moreover, many APIs that were created with
> >> the intentions
> >>>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>>> mentioned is abandoned now and confuses users.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can just see count of the tests we just
> >> mute on the
> >>>>>>>>>>>>> TC.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Can you, please, take a look at the fix
> >> regarding puck API
> >>>>>>>>>>>>>>>>>>> issue
> >>>>>>>>>>>>>>>>>>>> you mentioned in your first letter [2], [3]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
> >> https://issues.apache.org/jira/browse/IGNITE-12553
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [2]
> >> https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [3]
> >> https://issues.apache.org/jira/browse/IGNITE-12552
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 12:12, Alexey Goncharuk <
> >>>>>>>>>>>>>>>>>>>> [hidden email]> написал(а):
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nikolay,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why do you think this is a wrong usage
> >> pattern? From the
> >>>>>>>>>>>>>>> top
> >>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>> my head,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here is a few cases of direct metric API
> >> usage that I
> >>>>>>>>>>>>> know
> >>>>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>> currently
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> being used in production:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom task execution scheduling service
> >> with load
> >>>>>>>>>>>>>>>>>>>> balancing based on
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> utilization metrics readings from Java code
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * Cleanup task trigger based on metrics
> >> readings
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom health-check endpoint for an
> >> application with
> >>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>> embedded
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ignite node for Kubernetes/Spring
> >> Application/etc
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>
>

[agura]

>> I just want to remove the deprecations on the classes for which there is no a well-defined replacement.
> Well-defined replacement for these classes exists.

Nikolay, statements like this are not arguments. At least because
there are people who disagree with this.

Current implementation is not well-defined due to API is not
well-defined enough. Also there are lack of functionality
(enabling/disabling metrics, requirement for end user to configure new
exporter in order to get a couple of new metrics while it is still
possible to use old MBeans but without this metrics) and potential
performance problems (that couldn't be solved because metrics couldn't
be switched off).

We are walking in a circle instead of moving forward. On comments
about API you provide new PRs that change API while denying problems
with the API. This is illogical and process doesn't converge because
it is attempt to close gaps in a hurry.

The best we can do now is stop, take a deep breath and follow the
offers of Alexey about deprecation, my proposal and Denis' idea about
one additional iteration.

On Mon, Jan 27, 2020 at 4:37 PM Nikolay Izhikov <[hidden email]> wrote:

>
> > it's better to remove deprecation for the old APIs in AI 2.8
>
> Are you suggest to have 2 concurrent metrics implementations(both not deprecated)?
>
> > Let's say I am writing a custom exporter in binary format and I need to write the number of exported metrics in a packet beforehand.
>
> This an `MetricExporterSPI` implementation task.
> Exporter has the listeners that can be used to track all registry events - creation, removal
>
> > There is no separation on public and internal metrics
>
> I think we should write in the documentation that ANY metric can be changed.
> We will try to keep them, but if we found that some metric doesn’t required any more or implemented in the wrong way - we can remove it.
>
> > Will we allow users to register their own metrics?
>
> No. Why we should considering this feature?
>
> > It's still not clear how a user will map old interfaces and methods to the new metric names.
>
> With the documentation.
> We can write separate deprecation comment for each metric providing method.
>
> > I just want to remove the deprecations on the classes for which there is no a well-defined replacement.
>
> Well-defined replacement for these classes exists.
>
> > 27 янв. 2020 г., в 16:21, Alexey Goncharuk <[hidden email]> написал(а):
> >
> > Nikolay,
> >
> > I've reviewed your changes and I tend to agree with Andrey, it's better to
> > remove deprecation for the old APIs in AI 2.8 and discuss and merge the new
> > facade (IGNITE-12553) in a more calm and structured way. My observations on
> > the changes:
> >
> >   - I am not sure if Iterable would suffice both for the exporter and
> >   public APIs. Should we provide a way to know the number of metrics and
> >   registries in advance? Let's say I am writing a custom exporter in binary
> >   format and I need to write the number of exported metrics in a packet
> >   beforehand.
> >   - There is no separation on public and internal metrics, when public
> >   metrics preserve their name and semantics, and internal metrics may change.
> >   I remember we discussed this, but it's not reflected in the APIs in any way.
> >   - Will we allow users to register their own metrics? Again I remember we
> >   discussed a possibility for this. If so, why the registry is called
> >   'ReadyOnly'?
> >   - It's still not clear how a user will map old interfaces and methods to
> >   the new metric names.
> >
> > As you can see in the original message, I am not pushing for the new APIs
> > in the nearest release, I just want to remove the deprecations on the
> > classes for which there is no a well-defined replacement.
> >
> > пн, 27 янв. 2020 г. в 15:56, Maxim Muzafarov <[hidden email]>:
> >
> >> Folks,
> >>
> >>
> >> I'm sorry for not being too attentive to the whole thread discussion
> >> and maybe missing some details.
> >>
> >> But... who will perform the review of [1] issue?
> >> Will we merge it to 2.8? (hope so)
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-12553
> >> [IEP-35] public Java metric API
> >>
> >> On Sat, 25 Jan 2020 at 11:43, Николай Ижиков <[hidden email]> wrote:
> >>>
> >>> Andrey.
> >>>
> >>> With this API we are trying to fill the GAP Alexey pointed out at the
> >> start of this discussion.
> >>> I think it worth to be reviewed and merged.
> >>>
> >>> Can we, please, come back to the discussion of the changes itself?
> >>> I think API changes should be discussed in the other thread.
> >>>
> >>>> Why do you think this is a wrong usage pattern? From the top of my
> >> head, here is a few cases of direct metric API usage that I know are
> >> currently being used in production:
> >>>> * A custom task execution scheduling service with load balancing based
> >> on utilization metrics readings from Java code
> >>>> * Cleanup task trigger based on metrics readings
> >>>> * A custom health-check endpoint for an application with an embedded
> >> Ignite node for Kubernetes/Spring Application/etc
> >>>
> >>> [1] https://github.com/apache/ignite/pull/7283
> >>>
> >>>> 24 янв. 2020 г., в 18:08, Andrey Gura <[hidden email]> написал(а):
> >>>>
> >>>>> My point - that your contribution that took a long time, already,
> >> can’t be an argument to postpone creation of the API in the current release.
> >>>>
> >>>> Argument is not about time. But about API which is known will be
> >> changed.
> >>>> Second argument: why we should add this experimental API to the
> >>>> already existing experimental API? Just to making API more
> >>>> experimental? As I told already it is commit for commit and doesn't
> >>>> bring any value but brings some inconvenience to me (e.g. merge
> >>>> problems).
> >>>>
> >>>> BTW, does it exist issue about marking IEP-35 API's as experimental?
> >>>>
> >>>> On Thu, Jan 23, 2020 at 8:33 PM Николай Ижиков <[hidden email]>
> >> wrote:
> >>>>>
> >>>>>> You want say didn't discuss?
> >>>>>
> >>>>> Yes.
> >>>>>
> >>>>>> Secondly, yes it took a lot of time due to a lot of changes. Is it
> >> problem?
> >>>>>
> >>>>> No, of course.
> >>>>> My point - that your contribution that took a long time, already,
> >> can’t be an argument to postpone creation of the API in the current release.
> >>>>>
> >>>>>
> >>>>>> 23 янв. 2020 г., в 18:11, Andrey Gura <[hidden email]> написал(а):
> >>>>>>
> >>>>>>> We don’t discuss your changes and your proposals for the Metric API.
> >>>>>>
> >>>>>> You want say didn't discuss? Actually we did it [1] but you told ok
> >>>>>> let's see code :)
> >>>>>>
> >>>>>>> So I don’t think we can make the existence of some PR is an
> >> argument to introduce(or not introduce) this facade.
> >>>>>>
> >>>>>> You definitely right in case of competition development. But I think
> >>>>>> that collaborative development is more effective. Isn't it?
> >>>>>>
> >>>>>>> Moreover, As far as I know, you developing changes for the Metric
> >> API for 5 months without public discussion, for now. Let's start it.
> >>>>>>
> >>>>>> Firsty, with discussion. See above.
> >>>>>> Secondly, yes it took a lot of time due to a lot of changes. Is it
> >> problem?
> >>>>>>
> >>>>>>> Let’s do the following:
> >>>>>>> 1. Review `IgniteMetric` facade and introduce it to the users as an
> >> experimental API.
> >>>>>>
> >>>>>> It just doesn't make sense. Just commit for commit.
> >>>>>>
> >>>>>>> 2. Discuss your proposal to the Metric API in the separate thread
> >> you are referencing.
> >>>>>>
> >>>>>> You a re welcome to thread [1] again. But please, take into account.
> >>>>>> because discussion is postponed by you it's late enough to discuss
> >>>>>> proposed solution. But of course I'll answer on your questions and
> >>>>>> will be glade to your comments and suggestions.
> >>>>>>
> >>>>>>> I think we should start a discussion from the simplified
> >> explanation of:
> >>>>>>> 1. API intentions - What we want to gain with it? What is our focus?
> >>>>>>> 2. Simple, minimal example of API main interfaces and desired
> >> usages.
> >>>>>>
> >>>>>> All this already described at [1]. You also can take a look on PR
> >> (see
> >>>>>> MetricSource implementations, there are complex and simple ones).
> >>>>>>
> >>>>>> [1]
> >> http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Metrics-management-in-Ignite-tp43243.html
> >>>>>>
> >>>>>> On Thu, Jan 23, 2020 at 5:42 PM Николай Ижиков <[hidden email]>
> >> wrote:
> >>>>>>>
> >>>>>>> Andrey.
> >>>>>>>
> >>>>>>>> IGNITE-11927 implementation so your changes are incompatible with
> >> my changes
> >>>>>>>
> >>>>>>> We don’t discuss your changes and your proposals for the Metric API.
> >>>>>>> So I don’t think we can make the existence of some PR is an
> >> argument to introduce(or not introduce) this facade.
> >>>>>>> Moreover, As far as I know, you developing changes for the Metric
> >> API for 5 months without public discussion, for now. Let's start it.
> >>>>>>>
> >>>>>>> Let’s do the following:
> >>>>>>>
> >>>>>>> 1. Review `IgniteMetric` facade and introduce it to the users as an
> >> experimental API.
> >>>>>>>
> >>>>>>> 2. Discuss your proposal to the Metric API in the separate thread
> >> you are referencing.
> >>>>>>>
> >>>>>>> I think we should start a discussion from the simplified
> >> explanation of:
> >>>>>>>
> >>>>>>> 1. API intentions - What we want to gain with it? What is our focus?
> >>>>>>> 2. Simple, minimal example of API main interfaces and desired
> >> usages.
> >>>>>>>
> >>>>>>> This will help to the community and me personally better understand
> >> your idea and share feedback.
> >>>>>>>
> >>>>>>> Thanks.
> >>>>>>>
> >>>>>>>> 23 янв. 2020 г., в 17:15, Andrey Gura <[hidden email]>
> >> написал(а):
> >>>>>>>>
> >>>>>>>> Nikolay,
> >>>>>>>>
> >>>>>>>> as I wrote early in this thread API significantly changed during
> >>>>>>>> IGNITE-11927 implementation so your changes are incompatible with
> >> my
> >>>>>>>> changes.
> >>>>>>>>
> >>>>>>>> ReadOnlyMetricRegistry will be removed at all (still exists in a
> >>>>>>>> couple of places where it uses).
> >>>>>>>>
> >>>>>>>> Also I don't want to introduce IgniteMetric facade in this rush. In
> >>>>>>>> current implementation this interface just provides access to the
> >>>>>>>> ReadOnlyMetricManager instance (which will be removed) but it is
> >> not
> >>>>>>>> enough.
> >>>>>>>>
> >>>>>>>> I agree with Denis. We should mark current API as experimental and
> >>>>>>>> continue IEP-35 development. See my process proposal [1] described
> >>>>>>>> early this thread. We can release Apache Ignite 2.8.1 specially for
> >>>>>>>> this changes.
> >>>>>>>> Public APIs require deeper thinking in order to provide
> >> comprehensive,
> >>>>>>>> consistent and convenient way of metrics management for end users.
> >>>>>>>>
> >>>>>>>> Let's add IgniteExperimental, release 2.8 and finish metrics
> >> related
> >>>>>>>> issues after it.
> >>>>>>>>
> >>>>>>>> [1]
> >> http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-tp45146p45185.html
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Jan 22, 2020 at 5:21 PM Николай Ижиков <
> >> [hidden email]> wrote:
> >>>>>>>>>
> >>>>>>>>> Hello, Igniters.
> >>>>>>>>>
> >>>>>>>>> * IGNITE-12552: Move ReadOnlyMetricRegistry to public API merged
> >> to the master and cherry-picked to the 2.8.
> >>>>>>>>> So the main issue with the Metric API solved.
> >>>>>>>>>
> >>>>>>>>> * I raised the PR [1] to fix second issue with the new Metric
> >> API: absence of the public Java API to get metrics.
> >>>>>>>>> This PR introduces the following changes:
> >>>>>>>>>
> >>>>>>>>> 1. IgniteMetric interface created: it provides Java API to access
> >> Ignite metrics created with the new Metric API.
> >>>>>>>>>
> >>>>>>>>> ```
> >>>>>>>>> public interface IgniteMetric extends
> >> Iterable<ReadOnlyMetricRegistry> {
> >>>>>>>>> @Nullable ReadOnlyMetricRegistry registry(String name);
> >>>>>>>>> }
> >>>>>>>>> ```
> >>>>>>>>>
> >>>>>>>>> 2. All deprecation javadocs regarding metrics now reference to
> >> the public IgniteMetric instead of internal GridMetricManager:
> >>>>>>>>>
> >>>>>>>>>> @deprecated Use {@link IgniteMetric} instead.
> >>>>>>>>>
> >>>>>>>>> 3. Tests refactored to use IgniteMetric instead of
> >> GridMetricManager when possible.
> >>>>>>>>>
> >>>>>>>>> Please, review.
> >>>>>>>>>
> >>>>>>>>> [1]  https://github.com/apache/ignite/pull/7283
> >>>>>>>>>
> >>>>>>>>>> 21 янв. 2020 г., в 17:51, Николай Ижиков <[hidden email]>
> >> написал(а):
> >>>>>>>>>>
> >>>>>>>>>> Hello, Igniters.
> >>>>>>>>>>
> >>>>>>>>>> Alexey approved my PR [1] regarding fixing public API for metric
> >> exporters.
> >>>>>>>>>> I’m waiting for a bot visa and merge this PR.
> >>>>>>>>>>
> >>>>>>>>>> As we discussed, the metrics API will be marked with
> >> IgniteExperimental annotation.
> >>>>>>>>>>
> >>>>>>>>>> If anyone has any objection to this plan, please provide your
> >> feedback.
> >>>>>>>>>>
> >>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>
> >>>>>>>>>>> 21 янв. 2020 г., в 13:45, Николай Ижиков <
> >> [hidden email]> написал(а):
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks, for the review Alexey.
> >>>>>>>>>>>
> >>>>>>>>>>> I will fix your comment and  try to implement Monitoring
> >> facade, shortly.
> >>>>>>>>>>>
> >>>>>>>>>>>> 21 янв. 2020 г., в 13:32, Alexey Goncharuk <
> >> [hidden email]> написал(а):
> >>>>>>>>>>>>
> >>>>>>>>>>>> Nikolay,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I left a single comment in the PR about the histogram metric.
> >> I think the
> >>>>>>>>>>>> API looks much cleaner now.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I will take care of the @IgniteExperimental annotation.
> >>>>>>>>>>>>
> >>>>>>>>>>>> пн, 20 янв. 2020 г. в 20:55, Николай Ижиков <
> >> [hidden email]>:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Alexey.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> PR [1] is waiting for your review.
> >>>>>>>>>>>>> Please, take a look.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I think we should do the following before 2.8 release
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> * Introduce new @IgniteExperimental annotation as discussed.
> >>>>>>>>>>>>> * Mark Monitoring API with it.
> >>>>>>>>>>>>> * merge «[IEP-35] Expose MetricRegistry to the public API» to
> >> 2.8
> >>>>>>>>>>>>> * merge «[IEP-35] public Java metric API» to 2.8
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk <
> >> [hidden email]>
> >>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Nikolay,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Should we wait for both of the tickets given that we agreed
> >> that we are
> >>>>>>>>>>>>>> putting an experimental marker on the new APIs? I'm ok to
> >> fix only the
> >>>>>>>>>>>>>> first one and add the experimental marker so that we do not
> >> delay 2.8
> >>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков <
> >> [hidden email]>:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Andrey.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Let’s move from the long letters to the code.
> >>>>>>>>>>>>>>> If you want to change API - please, propose this changes.
> >>>>>>>>>>>>>>> I think everybody wins if we make our API better.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Please, describe proposed changes.
> >>>>>>>>>>>>>>> It would be great if you have some examples or PR for it.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> As for this release, I have plans to contribute tickets
> >>>>>>>>>>>>>>> «[IEP-35] Expose MetricRegistry to the public API» [1] and
> >>>>>>>>>>>>>>> «[IEP-35] public Java metric API» [2] for it.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Any objections on it?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-12553
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 20 янв. 2020 г., в 13:08, Andrey Gura <[hidden email]>
> >> написал(а):
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It solves problem.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
> >>>>>>>>>>>>>>>> <[hidden email]> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> After giving it some thought, I agree with Denis - there
> >> is nothing
> >>>>>>>>>>>>>>> wrong
> >>>>>>>>>>>>>>>>> with exposing the new APIs, we just need to make it clear
> >> that we are
> >>>>>>>>>>>>>>> still
> >>>>>>>>>>>>>>>>> going to change it.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Should we Introduce something like @IgniteExperimental
> >> annotation (I
> >>>>>>>>>>>>>>>>> believe it has been discussed a dozen of times on the
> >> dev-list)?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov <
> >> [hidden email]>:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> +1 to mark feature or whole release as EA.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> пт, 17 янв. 2020 г., 23:00 Denis Magda <
> >> [hidden email]>:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Folks, if you don't mind I'll share some
> >> thoughts/suggestions as an
> >>>>>>>>>>>>>>>>>>> observer who was not involved in the feature
> >> development.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> It's absolutely 'ok' to deprecate an API that is
> >> replaced with a
> >>>>>>>>>>>>> much
> >>>>>>>>>>>>>>>>>>> better version. However, we should do this only when
> >> the new APIs
> >>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>> production-ready. If there are still many limitations
> >> or open items
> >>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>>> don't deprecate anything that exists and release the
> >> new APIs
> >>>>>>>>>>>>>>> labeling as
> >>>>>>>>>>>>>>>>>>> early access. What if release the improvements labeling
> >> as EA
> >>>>>>>>>>>>> instead
> >>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>> hiding them completely?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I would also encourage us to put aside emotions, don't
> >> blame or
> >>>>>>>>>>>>> point
> >>>>>>>>>>>>>>>>>>> fingers. This IEP is a great initiative and you both
> >> have already
> >>>>>>>>>>>>>>> done a
> >>>>>>>>>>>>>>>>>>> tremendous job by developing, architecting and
> >> reviewing changes.
> >>>>>>>>>>>>>>> Just be
> >>>>>>>>>>>>>>>>>>> respectful. Nobody is trying to block the feature from
> >> being
> >>>>>>>>>>>>> released.
> >>>>>>>>>>>>>>>>>>> Everyone would be glad to tap into improvements and
> >> start using them
> >>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>> prod. But if more time is needed for the GA let's
> >> reiterate a bit.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>> Denis
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков <
> >>>>>>>>>>>>> [hidden email]>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Also I agree with Alexey about introducing public
> >> IgniteMonitoring
> >>>>>>>>>>>>>>>>>>> facade
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> This is not an issue with the API.
> >>>>>>>>>>>>>>>>>>>> Just the new feature that doesn’t affects API.
> >>>>>>>>>>>>>>>>>>>> Moreover, I create a ticket to fix it, already.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> It's right. But if you add checking of
> >> statisticsEnabling property
> >>>>>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>>>> test will fail. It's just not good tests.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> My changes doesn’t affect any `staticticsEnabled`
> >> property.
> >>>>>>>>>>>>>>>>>>>> I don’ understand your point here.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> It’s not redundant.
> >>>>>>>>>>>>>>>>>>>> It required for exporters and provide read only access
> >> to
> >>>>>>>>>>>>>>>>>> MetricRegistry
> >>>>>>>>>>>>>>>>>>>> existing in the node.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> MetricExporterSpi that requires
> >> ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that
> >> forces user
> >>>>>>>>>>>>> use
> >>>>>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Why this is issue?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> It’s consistent.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct
> >> reference
> >>>>>>>>>>>>>>>>>>>>> (performance problem).
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 1. We(You and I) did this choice together to simplify
> >> creation of
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>> metrics.
> >>>>>>>>>>>>>>>>>>>> 2. This is not public API issue.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I don’t ignore this flag.
> >>>>>>>>>>>>>>>>>>>> It just doesn’t exists in new framework(because of
> >> scope).
> >>>>>>>>>>>>>>>>>>>> I don’t think it’s an issue.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy
> >> best MBeans
> >>>>>>>>>>>>>>>>>>> practices.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Please, clarify your statement.
> >>>>>>>>>>>>>>>>>>>> What is best MBeans practices you are talking about?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> How this can be API issue?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 20:52, Andrey Gura <
> >> [hidden email]>
> >>>>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are
> >> fixed with my
> >>>>>>>>>>>>>>> PR
> >>>>>>>>>>>>>>>>>>>> [1].
> >>>>>>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are
> >> blocker for the
> >>>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> As I mentioned already IGNITE-11927 is part of IEP-35
> >> and
> >>>>>>>>>>>>>>>>>>>>> implementation seriously affects API's. Also I agree
> >> with Alexey
> >>>>>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>>>>>>> introducing public IgniteMonitoring facade. So thiss
> >> PR doesn't
> >>>>>>>>>>>>> fix
> >>>>>>>>>>>>>>>>>>>>> all issues.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
> >>>>>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this
> >> contribution.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> It's right. But if you add checking of
> >> statisticsEnabling property
> >>>>>>>>>>>>>>>>>>>>> then test will fail. It's just not good tests.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create
> >> a ticket I
> >>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>>>> fix
> >>>>>>>>>>>>>>>>>>>> it ASAP.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I already fix it all in IGNITE-11927
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't
> >> hide major
> >>>>>>>>>>>>>>>>>>>> contribution from the user just because your second
> >> guess «I don’t
> >>>>>>>>>>>>>>> like
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> API I just reviewed and approved».
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> We should move the product forward with with really
> >> finished
> >>>>>>>>>>>>>>>>>> features,
> >>>>>>>>>>>>>>>>>>>>> not pieces of features.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> So I am against this proposal.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> It is not argument.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API
> >> change and
> >>>>>>>>>>>>> discuss
> >>>>>>>>>>>>>>>>>>> them.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> We can prepare it together. But we can't block
> >> release.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> >>>>>>>>>>>>>>>>>>>>>> What is *ALL* problems?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>>>>>>> MetricExporterSpi that requires
> >> ReadOnlyMetricRegistry.
> >>>>>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that
> >> forces user
> >>>>>>>>>>>>> use
> >>>>>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> >>>>>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
> >>>>>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct
> >> reference
> >>>>>>>>>>>>>>>>>>>>> (performance problem).
> >>>>>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> >>>>>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy
> >> best MBeans
> >>>>>>>>>>>>>>>>>>> practices.
> >>>>>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> It's enough I believe.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:28 PM Николай Ижиков <
> >>>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Andrey.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are
> >> fixed with my
> >>>>>>>>>>>>> PR
> >>>>>>>>>>>>>>>>>>> [1].
> >>>>>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker
> >> for the
> >>>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this
> >> contribution.
> >>>>>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create
> >> a ticket I
> >>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>>>> fix
> >>>>>>>>>>>>>>>>>>>> it ASAP.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't
> >> hide major
> >>>>>>>>>>>>>>>>>>>> contribution from the user just because your second
> >> guess «I don’t
> >>>>>>>>>>>>>>> like
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> API I just reviewed and approved».
> >>>>>>>>>>>>>>>>>>>>>> So I am against this proposal.
> >>>>>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API
> >> change and
> >>>>>>>>>>>>> discuss
> >>>>>>>>>>>>>>>>>>> them.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> What is *ALL* problems?
> >>>>>>>>>>>>>>>>>>>>>> Seems, we never be able to solve *ALL* problems.
> >>>>>>>>>>>>>>>>>>>>>> But, we should move the product forward.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> As for your steps [1-6].
> >>>>>>>>>>>>>>>>>>>>>> I’m always following these steps during my
> >> contribution.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 19:08, Andrey Gura <
> >> [hidden email]>
> >>>>>>>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The discussion is hot and can be endless. So in
> >> separate post I
> >>>>>>>>>>>>>>>>>> want
> >>>>>>>>>>>>>>>>>>>>>>> propose my solution.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> >>>>>>>>>>>>>>>>>>>>>>> 2. Create special feature branch B.
> >>>>>>>>>>>>>>>>>>>>>>> 3. In branch B will be merged IGNITE-11927
> >>>>>>>>>>>>>>>>>>>>>>> 4. Because IGNITE-11927 doesn't solve all problems
> >> we should
> >>>>>>>>>>>>>>>>>> propose
> >>>>>>>>>>>>>>>>>>>>>>> solution and implement it in branch B.
> >>>>>>>>>>>>>>>>>>>>>>> 5. Testing, usability testing, fixing, etc
> >> iteratively.
> >>>>>>>>>>>>>>>>>>>>>>> 6. Merge it to master and in new release branch if
> >> needed.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Independent step. There are some problem which
> >> should be fixed
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>> 2.8
> >>>>>>>>>>>>>>>>>>>>>>> before release otherwise we introduce problems with
> >>>>>>>>>>>>> compatibility
> >>>>>>>>>>>>>>>>>>>>>>> which will haunt us till next major release. I'll
> >> create
> >>>>>>>>>>>>> tickets.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:03 PM Andrey Gura <
> >> [hidden email]>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires
> >> rewrite client
> >>>>>>>>>>>>>>> code.
> >>>>>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> >>>>>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove
> >> in the next
> >>>>>>>>>>>>>>> major
> >>>>>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> We don't know anything about development processes
> >> our users. I
> >>>>>>>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>>>>>>>>>> admit that process could require that deprecated
> >> methods/APIs
> >>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>> allowed for example.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange
> >> interface which
> >>>>>>>>>>>>> don't
> >>>>>>>>>>>>>>>>>>> give
> >>>>>>>>>>>>>>>>>>>> me any information about it’s purpose and
> >> responsibilities.
> >>>>>>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1]
> >> more clear:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I understand this. But I'm not Ignite user, I'm
> >> Ignite
> >>>>>>>>>>>>> developer.
> >>>>>>>>>>>>>>>>>>> The
> >>>>>>>>>>>>>>>>>>>>>>>> key moment in my message *from user stand point*.
> >> From my point
> >>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>> view it is very not intuitive solution and this
> >> interface is
> >>>>>>>>>>>>>>>>>>>>>>>> redundant.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
> >> caches for
> >>>>>>>>>>>>> example.
> >>>>>>>>>>>>>>>>>>>> There are other entities with such flag.
> >>>>>>>>>>>>>>>>>>>>>>>>> They still works as expected.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Actually not. I fixed many such issues during
> >> IGNITE-11927
> >>>>>>>>>>>>>>>>>>>> implementation.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
> >>>>>>>>>>>>>>>>>>>>>>>>> Because of the scope.
> >>>>>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the
> >> matter of the
> >>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I talk not about ability. I talk about ignored
> >> existing
> >>>>>>>>>>>>>>>>>>> functionality.
> >>>>>>>>>>>>>>>>>>>>>>>> So scope is not case here.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by
> >> MetricExporterSpi
> >>>>>>>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter
> >> to decide.
> >>>>>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while
> >> OpenCensus
> >>>>>>>>>>>>> exporter
> >>>>>>>>>>>>>>>>>>>> can’t.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Actually list is not metric at all as I already
> >> told.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 5:26 PM Николай Ижиков <
> >>>>>>>>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Andrey.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires
> >> rewrite client
> >>>>>>>>>>>>>>> code.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> >>>>>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove
> >> in the next
> >>>>>>>>>>>>>>> major
> >>>>>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange
> >> interface which
> >>>>>>>>>>>>> don't
> >>>>>>>>>>>>>>>>>>> give
> >>>>>>>>>>>>>>>>>>>> me any information about it’s purpose and
> >> responsibilities.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more
> >> clear:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Each SPI would have a `ReadOnlyMetricManager`
> >> which provides
> >>>>>>>>>>>>>>>>>> access
> >>>>>>>>>>>>>>>>>>>> to collection of `ReadOnlyMetricRegistry`
> >>>>>>>>>>>>>>>>>>>>>>>>> which has a collection of `Metric`.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> So we reflects two-level structure we have in the
> >> internal API
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> GridMetricManager -> Collection[MetricRegistry] ->
> >>>>>>>>>>>>>>>>>>> Collection[Metric]
> >>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricManager ->
> >> Collection[ReadOnlyMetricRegistry] ->
> >>>>>>>>>>>>>>>>>>>> Collection[Metric]
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
> >> caches for
> >>>>>>>>>>>>> example.
> >>>>>>>>>>>>>>>>>>>> There are other entities with such flag.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> They still works as expected.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Because of the scope.
> >>>>>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the
> >> matter of the
> >>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by
> >> MetricExporterSpi
> >>>>>>>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter
> >> to decide.
> >>>>>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while
> >> OpenCensus
> >>>>>>>>>>>>> exporter
> >>>>>>>>>>>>>>>>>>>> can’t.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >> https://github.com/apache/ignite/pull/7269/files#diff-0ae5657231fc4c1f650493b02190b81bR25
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 16:57, Andrey Gura <
> >> [hidden email]>
> >>>>>>>>>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of
> >> the active
> >>>>>>>>>>>>>>>>>>> reviewers
> >>>>>>>>>>>>>>>>>>>> of the Metric API.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Yes. But if I'm not missing some thing you were
> >> major
> >>>>>>>>>>>>> developer
> >>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>>>> Metric API :) Shit happens. And it happened.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
> >> deprecation of APIs
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
> >> substitution.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> There is such concept - backward compatibility.
> >> I understand
> >>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>>>>> deprecation of some interface doesn't break
> >> backward
> >>>>>>>>>>>>>>>>>> compatibility
> >>>>>>>>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>>>>>>>>>>>> it leads to question^ what should I use instead
> >> of this. And
> >>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi is not answer for this
> >> question. Because it
> >>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>> brand
> >>>>>>>>>>>>>>>>>>>>>>>>>> new API and it requires rewrite client code.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal
> >> MetricRegistry  to
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> exporters.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> No it is not. It's completely artificial thing
> >> which allow
> >>>>>>>>>>>>>>>>>> iterate
> >>>>>>>>>>>>>>>>>>>> via
> >>>>>>>>>>>>>>>>>>>>>>>>>> all metric registries. GridMetricManager
> >> implements this
> >>>>>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>>>>> while it is not metric registry. Form user stand
> >> point it is
> >>>>>>>>>>>>>>>>>> very
> >>>>>>>>>>>>>>>>>>>>>>>>>> strange interface which don't give me any
> >> information about
> >>>>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>>>>>>>>> purpose and responsibilities.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
> >> caches for
> >>>>>>>>>>>>> example.
> >>>>>>>>>>>>>>>>>>>> There
> >>>>>>>>>>>>>>>>>>>>>>>>>> are other entities with such flag.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way? Why you
> >> ignore existing
> >>>>>>>>>>>>>>>>>>>>>>>>>> functionality? It affects user expectations and
> >> experience.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Yes? I'm working. Unfortunately we are not
> >> synchronized in
> >>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>>>>>>> context and I should redo all metrics related
> >> changes in
> >>>>>>>>>>>>> order
> >>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>> merge it with my changes. Anyway, my change
> >> doesn't solve all
> >>>>>>>>>>>>>>>>>>>> problems
> >>>>>>>>>>>>>>>>>>>>>>>>>> (e.g. it doesn't introduce IgniteMonitoring
> >> facade).
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Unfortunately it will be just fix. In my
> >> solution it is
> >>>>>>>>>>>>>>>>>> redesign.
> >>>>>>>>>>>>>>>>>>>> Stop
> >>>>>>>>>>>>>>>>>>>>>>>>>> fixing issues, let's do things. It requires
> >> deeper changes.
> >>>>>>>>>>>>> My
> >>>>>>>>>>>>>>>>>>>> changes
> >>>>>>>>>>>>>>>>>>>>>>>>>> blocks AI 2.8 release because it big enough. So
> >> it retargeted
> >>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>> next release. And it is one more reason for
> >> moving the
> >>>>>>>>>>>>> changes
> >>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>> internal packages. And it isn't good news for me
> >> because I
> >>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>>> go
> >>>>>>>>>>>>>>>>>>>>>>>>>> throughout pan and tiers of merge. But it is
> >> right.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
> >> compatibility.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
> >> compatibility.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Yes, I know. But they should not be exported by
> >>>>>>>>>>>>>>>>>> MetricExporterSpi
> >>>>>>>>>>>>>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 3:37 PM Николай Ижиков <
> >>>>>>>>>>>>>>>>>>> [hidden email]>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey, thanks for your opinion and your ownest
> >> critisism.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> I can’t wait for your contribution.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of
> >> the active
> >>>>>>>>>>>>>>>>>>> reviewers
> >>>>>>>>>>>>>>>>>>>> of the Metric API.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
> >> deprecation of APIs
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
> >> substitution.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't
> >> recommend
> >>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still
> >> not-production ready.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> It’s ready.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the
> >> public API
> >>>>>>>>>>>>> doesn't
> >>>>>>>>>>>>>>>>>>>> solve the problem because this interface exposes
> >> internal Metric
> >>>>>>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>> implementations.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Not, its’ not.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Please, see
> >> `org.apache.ignite.spi.metric.LongMetric` and
> >>>>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>>>>> public interface.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> API of MetricRegistry is inconsistent.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> MetricRegistry is the internal API.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Feel free to create ticket for an issues with
> >> it and I will
> >>>>>>>>>>>>>>> try
> >>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> fix it.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal
> >> MetricRegistry  to
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> exporters.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> >>>>>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
> >> compatibility.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 15:09, Andrey Gura <
> >> [hidden email]>
> >>>>>>>>>>>>>>>>>>>> написал(а):
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
> >> deprecation of APIs
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
> >> substitution.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't
> >> recommend
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still
> >> not-production
> >>>>>>>>>>>>>>> ready.
> >>>>>>>>>>>>>>>>>>>> There
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> are some issues with it and usage of
> >> ReadOnlyMetricRegistry
> >>>>>>>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> just one of them.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the
> >> public API
> >>>>>>>>>>>>> doesn't
> >>>>>>>>>>>>>>>>>>>> solve
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the problem because this interface exposes
> >> internal Metric
> >>>>>>>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> implementations. So your PR is incomplete.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Moreover, API of MetricRegistry is
> >> inconsistent. E.g.
> >>>>>>>>>>>>>>>>>>>> register(name,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> supplier, desc) method returns registered
> >> metric for some
> >>>>>>>>>>>>>>>>>> types
> >>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> doesn't for other. register(metric) method is
> >> inconsistent
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>> sense of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> metric naming. ReadOnlyMetricRegistry
> >> interface is
> >>>>>>>>>>>>> redundant.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi should be revised because it
> >> absolutely
> >>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> intuitive because it requires
> >> ReadOnlyMetricRegistry and
> >>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>>> purpose
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> is undefined.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> One more point. IEP-35 is still not fully
> >> implemented. Some
> >>>>>>>>>>>>>>>>>>>> things are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> not taken into account. Exporters expose
> >> metrics if they
> >>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>> disabled.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> JMX beans exposes values that don't confirm to
> >> best
> >>>>>>>>>>>>> practices
> >>>>>>>>>>>>>>>>>>> [1].
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> >> Ubiquitous
> >>>>>>>>>>>>>>> merics
> >>>>>>>>>>>>>>>>>>>> lookup
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> from hash map instead of usage reference for
> >> getting
> >>>>>>>>>>>>> metrics
> >>>>>>>>>>>>>>>>>>>> values
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> (it is just performance issue). Also
> >> IGNITE-11927 is not
> >>>>>>>>>>>>>>>>>>>> implemented
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> which also changes interfaces significantly.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Let's just admit that the implementation is
> >> immature and
> >>>>>>>>>>>>> must
> >>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>> moved
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> to the internal packages.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> And because we already merged partially
> >> implemented IEP to
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> master
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> branch we *must move all currently public APIs
> >> to the
> >>>>>>>>>>>>>>> internal
> >>>>>>>>>>>>>>>>>>>> API*
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> while it will not be ready for publication.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> And the last but not least. What is happening
> >> indicates a
> >>>>>>>>>>>>>>>>>>> immature
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> development process which must be revised. I
> >> don't want
> >>>>>>>>>>>>>>>>>> discuss
> >>>>>>>>>>>>>>>>>>>> it in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> this thread but we must not allow merge of
> >> change to the
> >>>>>>>>>>>>>>>>>> master
> >>>>>>>>>>>>>>>>>>>> branch
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> before it will completed, that is we must use
> >> feature
> >>>>>>>>>>>>>>> branches
> >>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> full IEP not only for particular tickets. And
> >> also we
> >>>>>>>>>>>>> should
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> reformulate IEP process in order to avoid
> >> things like this.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >> https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:49 PM Николай
> >> Ижиков <
> >>>>>>>>>>>>>>>>>>>> [hidden email]> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alex.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK, I may leverage your experience and create
> >> pure Java
> >>>>>>>>>>>>> API.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ticket [1] created.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> But, personally, I don’t agree with you.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ignite has dozens of the API that
> >> theoretically have a
> >>>>>>>>>>>>> usage
> >>>>>>>>>>>>>>>>>>>> scenario, but in real-world have 0 custom
> >> implementation and
> >>>>>>>>>>>>> usages.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Moreover, many APIs that were created with
> >> the intentions
> >>>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>>> mentioned is abandoned now and confuses users.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can just see count of the tests we just
> >> mute on the
> >>>>>>>>>>>>> TC.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Can you, please, take a look at the fix
> >> regarding puck API
> >>>>>>>>>>>>>>>>>>> issue
> >>>>>>>>>>>>>>>>>>>> you mentioned in your first letter [2], [3]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
> >> https://issues.apache.org/jira/browse/IGNITE-12553
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [2]
> >> https://github.com/apache/ignite/pull/7269
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [3]
> >> https://issues.apache.org/jira/browse/IGNITE-12552
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 12:12, Alexey Goncharuk <
> >>>>>>>>>>>>>>>>>>>> [hidden email]> написал(а):
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nikolay,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why do you think this is a wrong usage
> >> pattern? From the
> >>>>>>>>>>>>>>> top
> >>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>> my head,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here is a few cases of direct metric API
> >> usage that I
> >>>>>>>>>>>>> know
> >>>>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>> currently
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> being used in production:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom task execution scheduling service
> >> with load
> >>>>>>>>>>>>>>>>>>>> balancing based on
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> utilization metrics readings from Java code
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * Cleanup task trigger based on metrics
> >> readings
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom health-check endpoint for an
> >> application with
> >>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>> embedded
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ignite node for Kubernetes/Spring
> >> Application/etc
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>
>

[Maxim Muzafarov]

Folks,


Let me share my humble opinion over this thread. The first priority
here is making Ignite better and taking the next step with releasing
Ignite's 2.8 version for our users (we've already done a great job
with metrics).

According to this point of view and from the user perspective I'd like
to be notified about changing Ignite's architecture and concepts of
using metrics as early as possible not only through the public
documentation but through the code I write also.

So, I see nothing strange by keeping @deprecated annotation (Javadoc
comments must be fixed, true):
1. it's just a hint for users (we will notify them as earlier as
possible but they can still write a code using deprecated methods)
2. users will be notified about new JmxMetricExporterSpi through the
code and documentation.
3. it's a recommendation for developers that they should not add new
methods to the old facade.

I also see nothing strange by removing @deprecated annotation
currently added to DataRegionMetrics interface. It's also OK if we are
still developing new facade and do not want to share some public API
changes with users because all the 2.8 release looks for me like an
experimental.


So, summarizing:
1. Let's keep @deprecated annotation to notify users earlier.
2. Let's fix javadoc comments for this annotation (remove internal references).
3. Let's do not too much debate here. This question isn't too
important compared to 23 critical release issues [1].


Alexey, Andrey, Nikolay,

Can we proceed this way?


P.S.
From the release managers view, it's sad to see such a discussions
about API changes and compatibility because we've discussed API at
July 2019 [3] and all issues with monitoring activities at October
2019 [2].


[1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolvedissues(notrelatedtodocumentation)
[2] http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-tp43616p43807.html
[3] https://issues.apache.org/jira/browse/IGNITE-11848

On Mon, 27 Jan 2020 at 22:23, Andrey Gura <[hidden email]> wrote:

>
> >> I just want to remove the deprecations on the classes for which there is no a well-defined replacement.
> > Well-defined replacement for these classes exists.
>
> Nikolay, statements like this are not arguments. At least because
> there are people who disagree with this.
>
> Current implementation is not well-defined due to API is not
> well-defined enough. Also there are lack of functionality
> (enabling/disabling metrics, requirement for end user to configure new
> exporter in order to get a couple of new metrics while it is still
> possible to use old MBeans but without this metrics) and potential
> performance problems (that couldn't be solved because metrics couldn't
> be switched off).
>
> We are walking in a circle instead of moving forward. On comments
> about API you provide new PRs that change API while denying problems
> with the API. This is illogical and process doesn't converge because
> it is attempt to close gaps in a hurry.
>
> The best we can do now is stop, take a deep breath and follow the
> offers of Alexey about deprecation, my proposal and Denis' idea about
> one additional iteration.
>
> On Mon, Jan 27, 2020 at 4:37 PM Nikolay Izhikov <[hidden email]> wrote:
> >
> > > it's better to remove deprecation for the old APIs in AI 2.8
> >
> > Are you suggest to have 2 concurrent metrics implementations(both not deprecated)?
> >
> > > Let's say I am writing a custom exporter in binary format and I need to write the number of exported metrics in a packet beforehand.
> >
> > This an `MetricExporterSPI` implementation task.
> > Exporter has the listeners that can be used to track all registry events - creation, removal
> >
> > > There is no separation on public and internal metrics
> >
> > I think we should write in the documentation that ANY metric can be changed.
> > We will try to keep them, but if we found that some metric doesn’t required any more or implemented in the wrong way - we can remove it.
> >
> > > Will we allow users to register their own metrics?
> >
> > No. Why we should considering this feature?
> >
> > > It's still not clear how a user will map old interfaces and methods to the new metric names.
> >
> > With the documentation.
> > We can write separate deprecation comment for each metric providing method.
> >
> > > I just want to remove the deprecations on the classes for which there is no a well-defined replacement.
> >
> > Well-defined replacement for these classes exists.
> >
> > > 27 янв. 2020 г., в 16:21, Alexey Goncharuk <[hidden email]> написал(а):
> > >
> > > Nikolay,
> > >
> > > I've reviewed your changes and I tend to agree with Andrey, it's better to
> > > remove deprecation for the old APIs in AI 2.8 and discuss and merge the new
> > > facade (IGNITE-12553) in a more calm and structured way. My observations on
> > > the changes:
> > >
> > >   - I am not sure if Iterable would suffice both for the exporter and
> > >   public APIs. Should we provide a way to know the number of metrics and
> > >   registries in advance? Let's say I am writing a custom exporter in binary
> > >   format and I need to write the number of exported metrics in a packet
> > >   beforehand.
> > >   - There is no separation on public and internal metrics, when public
> > >   metrics preserve their name and semantics, and internal metrics may change.
> > >   I remember we discussed this, but it's not reflected in the APIs in any way.
> > >   - Will we allow users to register their own metrics? Again I remember we
> > >   discussed a possibility for this. If so, why the registry is called
> > >   'ReadyOnly'?
> > >   - It's still not clear how a user will map old interfaces and methods to
> > >   the new metric names.
> > >
> > > As you can see in the original message, I am not pushing for the new APIs
> > > in the nearest release, I just want to remove the deprecations on the
> > > classes for which there is no a well-defined replacement.
> > >
> > > пн, 27 янв. 2020 г. в 15:56, Maxim Muzafarov <[hidden email]>:
> > >
> > >> Folks,
> > >>
> > >>
> > >> I'm sorry for not being too attentive to the whole thread discussion
> > >> and maybe missing some details.
> > >>
> > >> But... who will perform the review of [1] issue?
> > >> Will we merge it to 2.8? (hope so)
> > >>
> > >>
> > >> [1] https://issues.apache.org/jira/browse/IGNITE-12553
> > >> [IEP-35] public Java metric API
> > >>
> > >> On Sat, 25 Jan 2020 at 11:43, Николай Ижиков <[hidden email]> wrote:
> > >>>
> > >>> Andrey.
> > >>>
> > >>> With this API we are trying to fill the GAP Alexey pointed out at the
> > >> start of this discussion.
> > >>> I think it worth to be reviewed and merged.
> > >>>
> > >>> Can we, please, come back to the discussion of the changes itself?
> > >>> I think API changes should be discussed in the other thread.
> > >>>
> > >>>> Why do you think this is a wrong usage pattern? From the top of my
> > >> head, here is a few cases of direct metric API usage that I know are
> > >> currently being used in production:
> > >>>> * A custom task execution scheduling service with load balancing based
> > >> on utilization metrics readings from Java code
> > >>>> * Cleanup task trigger based on metrics readings
> > >>>> * A custom health-check endpoint for an application with an embedded
> > >> Ignite node for Kubernetes/Spring Application/etc
> > >>>
> > >>> [1] https://github.com/apache/ignite/pull/7283
> > >>>
> > >>>> 24 янв. 2020 г., в 18:08, Andrey Gura <[hidden email]> написал(а):
> > >>>>
> > >>>>> My point - that your contribution that took a long time, already,
> > >> can’t be an argument to postpone creation of the API in the current release.
> > >>>>
> > >>>> Argument is not about time. But about API which is known will be
> > >> changed.
> > >>>> Second argument: why we should add this experimental API to the
> > >>>> already existing experimental API? Just to making API more
> > >>>> experimental? As I told already it is commit for commit and doesn't
> > >>>> bring any value but brings some inconvenience to me (e.g. merge
> > >>>> problems).
> > >>>>
> > >>>> BTW, does it exist issue about marking IEP-35 API's as experimental?
> > >>>>
> > >>>> On Thu, Jan 23, 2020 at 8:33 PM Николай Ижиков <[hidden email]>
> > >> wrote:
> > >>>>>
> > >>>>>> You want say didn't discuss?
> > >>>>>
> > >>>>> Yes.
> > >>>>>
> > >>>>>> Secondly, yes it took a lot of time due to a lot of changes. Is it
> > >> problem?
> > >>>>>
> > >>>>> No, of course.
> > >>>>> My point - that your contribution that took a long time, already,
> > >> can’t be an argument to postpone creation of the API in the current release.
> > >>>>>
> > >>>>>
> > >>>>>> 23 янв. 2020 г., в 18:11, Andrey Gura <[hidden email]> написал(а):
> > >>>>>>
> > >>>>>>> We don’t discuss your changes and your proposals for the Metric API.
> > >>>>>>
> > >>>>>> You want say didn't discuss? Actually we did it [1] but you told ok
> > >>>>>> let's see code :)
> > >>>>>>
> > >>>>>>> So I don’t think we can make the existence of some PR is an
> > >> argument to introduce(or not introduce) this facade.
> > >>>>>>
> > >>>>>> You definitely right in case of competition development. But I think
> > >>>>>> that collaborative development is more effective. Isn't it?
> > >>>>>>
> > >>>>>>> Moreover, As far as I know, you developing changes for the Metric
> > >> API for 5 months without public discussion, for now. Let's start it.
> > >>>>>>
> > >>>>>> Firsty, with discussion. See above.
> > >>>>>> Secondly, yes it took a lot of time due to a lot of changes. Is it
> > >> problem?
> > >>>>>>
> > >>>>>>> Let’s do the following:
> > >>>>>>> 1. Review `IgniteMetric` facade and introduce it to the users as an
> > >> experimental API.
> > >>>>>>
> > >>>>>> It just doesn't make sense. Just commit for commit.
> > >>>>>>
> > >>>>>>> 2. Discuss your proposal to the Metric API in the separate thread
> > >> you are referencing.
> > >>>>>>
> > >>>>>> You a re welcome to thread [1] again. But please, take into account.
> > >>>>>> because discussion is postponed by you it's late enough to discuss
> > >>>>>> proposed solution. But of course I'll answer on your questions and
> > >>>>>> will be glade to your comments and suggestions.
> > >>>>>>
> > >>>>>>> I think we should start a discussion from the simplified
> > >> explanation of:
> > >>>>>>> 1. API intentions - What we want to gain with it? What is our focus?
> > >>>>>>> 2. Simple, minimal example of API main interfaces and desired
> > >> usages.
> > >>>>>>
> > >>>>>> All this already described at [1]. You also can take a look on PR
> > >> (see
> > >>>>>> MetricSource implementations, there are complex and simple ones).
> > >>>>>>
> > >>>>>> [1]
> > >> http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Metrics-management-in-Ignite-tp43243.html
> > >>>>>>
> > >>>>>> On Thu, Jan 23, 2020 at 5:42 PM Николай Ижиков <[hidden email]>
> > >> wrote:
> > >>>>>>>
> > >>>>>>> Andrey.
> > >>>>>>>
> > >>>>>>>> IGNITE-11927 implementation so your changes are incompatible with
> > >> my changes
> > >>>>>>>
> > >>>>>>> We don’t discuss your changes and your proposals for the Metric API.
> > >>>>>>> So I don’t think we can make the existence of some PR is an
> > >> argument to introduce(or not introduce) this facade.
> > >>>>>>> Moreover, As far as I know, you developing changes for the Metric
> > >> API for 5 months without public discussion, for now. Let's start it.
> > >>>>>>>
> > >>>>>>> Let’s do the following:
> > >>>>>>>
> > >>>>>>> 1. Review `IgniteMetric` facade and introduce it to the users as an
> > >> experimental API.
> > >>>>>>>
> > >>>>>>> 2. Discuss your proposal to the Metric API in the separate thread
> > >> you are referencing.
> > >>>>>>>
> > >>>>>>> I think we should start a discussion from the simplified
> > >> explanation of:
> > >>>>>>>
> > >>>>>>> 1. API intentions - What we want to gain with it? What is our focus?
> > >>>>>>> 2. Simple, minimal example of API main interfaces and desired
> > >> usages.
> > >>>>>>>
> > >>>>>>> This will help to the community and me personally better understand
> > >> your idea and share feedback.
> > >>>>>>>
> > >>>>>>> Thanks.
> > >>>>>>>
> > >>>>>>>> 23 янв. 2020 г., в 17:15, Andrey Gura <[hidden email]>
> > >> написал(а):
> > >>>>>>>>
> > >>>>>>>> Nikolay,
> > >>>>>>>>
> > >>>>>>>> as I wrote early in this thread API significantly changed during
> > >>>>>>>> IGNITE-11927 implementation so your changes are incompatible with
> > >> my
> > >>>>>>>> changes.
> > >>>>>>>>
> > >>>>>>>> ReadOnlyMetricRegistry will be removed at all (still exists in a
> > >>>>>>>> couple of places where it uses).
> > >>>>>>>>
> > >>>>>>>> Also I don't want to introduce IgniteMetric facade in this rush. In
> > >>>>>>>> current implementation this interface just provides access to the
> > >>>>>>>> ReadOnlyMetricManager instance (which will be removed) but it is
> > >> not
> > >>>>>>>> enough.
> > >>>>>>>>
> > >>>>>>>> I agree with Denis. We should mark current API as experimental and
> > >>>>>>>> continue IEP-35 development. See my process proposal [1] described
> > >>>>>>>> early this thread. We can release Apache Ignite 2.8.1 specially for
> > >>>>>>>> this changes.
> > >>>>>>>> Public APIs require deeper thinking in order to provide
> > >> comprehensive,
> > >>>>>>>> consistent and convenient way of metrics management for end users.
> > >>>>>>>>
> > >>>>>>>> Let's add IgniteExperimental, release 2.8 and finish metrics
> > >> related
> > >>>>>>>> issues after it.
> > >>>>>>>>
> > >>>>>>>> [1]
> > >> http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-tp45146p45185.html
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Wed, Jan 22, 2020 at 5:21 PM Николай Ижиков <
> > >> [hidden email]> wrote:
> > >>>>>>>>>
> > >>>>>>>>> Hello, Igniters.
> > >>>>>>>>>
> > >>>>>>>>> * IGNITE-12552: Move ReadOnlyMetricRegistry to public API merged
> > >> to the master and cherry-picked to the 2.8.
> > >>>>>>>>> So the main issue with the Metric API solved.
> > >>>>>>>>>
> > >>>>>>>>> * I raised the PR [1] to fix second issue with the new Metric
> > >> API: absence of the public Java API to get metrics.
> > >>>>>>>>> This PR introduces the following changes:
> > >>>>>>>>>
> > >>>>>>>>> 1. IgniteMetric interface created: it provides Java API to access
> > >> Ignite metrics created with the new Metric API.
> > >>>>>>>>>
> > >>>>>>>>> ```
> > >>>>>>>>> public interface IgniteMetric extends
> > >> Iterable<ReadOnlyMetricRegistry> {
> > >>>>>>>>> @Nullable ReadOnlyMetricRegistry registry(String name);
> > >>>>>>>>> }
> > >>>>>>>>> ```
> > >>>>>>>>>
> > >>>>>>>>> 2. All deprecation javadocs regarding metrics now reference to
> > >> the public IgniteMetric instead of internal GridMetricManager:
> > >>>>>>>>>
> > >>>>>>>>>> @deprecated Use {@link IgniteMetric} instead.
> > >>>>>>>>>
> > >>>>>>>>> 3. Tests refactored to use IgniteMetric instead of
> > >> GridMetricManager when possible.
> > >>>>>>>>>
> > >>>>>>>>> Please, review.
> > >>>>>>>>>
> > >>>>>>>>> [1]  https://github.com/apache/ignite/pull/7283
> > >>>>>>>>>
> > >>>>>>>>>> 21 янв. 2020 г., в 17:51, Николай Ижиков <[hidden email]>
> > >> написал(а):
> > >>>>>>>>>>
> > >>>>>>>>>> Hello, Igniters.
> > >>>>>>>>>>
> > >>>>>>>>>> Alexey approved my PR [1] regarding fixing public API for metric
> > >> exporters.
> > >>>>>>>>>> I’m waiting for a bot visa and merge this PR.
> > >>>>>>>>>>
> > >>>>>>>>>> As we discussed, the metrics API will be marked with
> > >> IgniteExperimental annotation.
> > >>>>>>>>>>
> > >>>>>>>>>> If anyone has any objection to this plan, please provide your
> > >> feedback.
> > >>>>>>>>>>
> > >>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> > >>>>>>>>>>
> > >>>>>>>>>>> 21 янв. 2020 г., в 13:45, Николай Ижиков <
> > >> [hidden email]> написал(а):
> > >>>>>>>>>>>
> > >>>>>>>>>>> Thanks, for the review Alexey.
> > >>>>>>>>>>>
> > >>>>>>>>>>> I will fix your comment and  try to implement Monitoring
> > >> facade, shortly.
> > >>>>>>>>>>>
> > >>>>>>>>>>>> 21 янв. 2020 г., в 13:32, Alexey Goncharuk <
> > >> [hidden email]> написал(а):
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Nikolay,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I left a single comment in the PR about the histogram metric.
> > >> I think the
> > >>>>>>>>>>>> API looks much cleaner now.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I will take care of the @IgniteExperimental annotation.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> пн, 20 янв. 2020 г. в 20:55, Николай Ижиков <
> > >> [hidden email]>:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Alexey.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> PR [1] is waiting for your review.
> > >>>>>>>>>>>>> Please, take a look.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I think we should do the following before 2.8 release
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> * Introduce new @IgniteExperimental annotation as discussed.
> > >>>>>>>>>>>>> * Mark Monitoring API with it.
> > >>>>>>>>>>>>> * merge «[IEP-35] Expose MetricRegistry to the public API» to
> > >> 2.8
> > >>>>>>>>>>>>> * merge «[IEP-35] public Java metric API» to 2.8
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk <
> > >> [hidden email]>
> > >>>>>>>>>>>>> написал(а):
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Nikolay,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Should we wait for both of the tickets given that we agreed
> > >> that we are
> > >>>>>>>>>>>>>> putting an experimental marker on the new APIs? I'm ok to
> > >> fix only the
> > >>>>>>>>>>>>>> first one and add the experimental marker so that we do not
> > >> delay 2.8
> > >>>>>>>>>>>>>> release.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков <
> > >> [hidden email]>:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Andrey.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Let’s move from the long letters to the code.
> > >>>>>>>>>>>>>>> If you want to change API - please, propose this changes.
> > >>>>>>>>>>>>>>> I think everybody wins if we make our API better.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Please, describe proposed changes.
> > >>>>>>>>>>>>>>> It would be great if you have some examples or PR for it.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> As for this release, I have plans to contribute tickets
> > >>>>>>>>>>>>>>> «[IEP-35] Expose MetricRegistry to the public API» [1] and
> > >>>>>>>>>>>>>>> «[IEP-35] public Java metric API» [2] for it.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Any objections on it?
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> > >>>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-12553
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 20 янв. 2020 г., в 13:08, Andrey Gura <[hidden email]>
> > >> написал(а):
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> It solves problem.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
> > >>>>>>>>>>>>>>>> <[hidden email]> wrote:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> After giving it some thought, I agree with Denis - there
> > >> is nothing
> > >>>>>>>>>>>>>>> wrong
> > >>>>>>>>>>>>>>>>> with exposing the new APIs, we just need to make it clear
> > >> that we are
> > >>>>>>>>>>>>>>> still
> > >>>>>>>>>>>>>>>>> going to change it.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Should we Introduce something like @IgniteExperimental
> > >> annotation (I
> > >>>>>>>>>>>>>>>>> believe it has been discussed a dozen of times on the
> > >> dev-list)?
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov <
> > >> [hidden email]>:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> +1 to mark feature or whole release as EA.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> пт, 17 янв. 2020 г., 23:00 Denis Magda <
> > >> [hidden email]>:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Folks, if you don't mind I'll share some
> > >> thoughts/suggestions as an
> > >>>>>>>>>>>>>>>>>>> observer who was not involved in the feature
> > >> development.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> It's absolutely 'ok' to deprecate an API that is
> > >> replaced with a
> > >>>>>>>>>>>>> much
> > >>>>>>>>>>>>>>>>>>> better version. However, we should do this only when
> > >> the new APIs
> > >>>>>>>>>>>>> are
> > >>>>>>>>>>>>>>>>>>> production-ready. If there are still many limitations
> > >> or open items
> > >>>>>>>>>>>>>>> then
> > >>>>>>>>>>>>>>>>>>> don't deprecate anything that exists and release the
> > >> new APIs
> > >>>>>>>>>>>>>>> labeling as
> > >>>>>>>>>>>>>>>>>>> early access. What if release the improvements labeling
> > >> as EA
> > >>>>>>>>>>>>> instead
> > >>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>> hiding them completely?
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> I would also encourage us to put aside emotions, don't
> > >> blame or
> > >>>>>>>>>>>>> point
> > >>>>>>>>>>>>>>>>>>> fingers. This IEP is a great initiative and you both
> > >> have already
> > >>>>>>>>>>>>>>> done a
> > >>>>>>>>>>>>>>>>>>> tremendous job by developing, architecting and
> > >> reviewing changes.
> > >>>>>>>>>>>>>>> Just be
> > >>>>>>>>>>>>>>>>>>> respectful. Nobody is trying to block the feature from
> > >> being
> > >>>>>>>>>>>>> released.
> > >>>>>>>>>>>>>>>>>>> Everyone would be glad to tap into improvements and
> > >> start using them
> > >>>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>>>> prod. But if more time is needed for the GA let's
> > >> reiterate a bit.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> -
> > >>>>>>>>>>>>>>>>>>> Denis
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков <
> > >>>>>>>>>>>>> [hidden email]>
> > >>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Also I agree with Alexey about introducing public
> > >> IgniteMonitoring
> > >>>>>>>>>>>>>>>>>>> facade
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> This is not an issue with the API.
> > >>>>>>>>>>>>>>>>>>>> Just the new feature that doesn’t affects API.
> > >>>>>>>>>>>>>>>>>>>> Moreover, I create a ticket to fix it, already.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> It's right. But if you add checking of
> > >> statisticsEnabling property
> > >>>>>>>>>>>>>>>>>> then
> > >>>>>>>>>>>>>>>>>>>> test will fail. It's just not good tests.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> My changes doesn’t affect any `staticticsEnabled`
> > >> property.
> > >>>>>>>>>>>>>>>>>>>> I don’ understand your point here.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> It’s not redundant.
> > >>>>>>>>>>>>>>>>>>>> It required for exporters and provide read only access
> > >> to
> > >>>>>>>>>>>>>>>>>> MetricRegistry
> > >>>>>>>>>>>>>>>>>>>> existing in the node.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> MetricExporterSpi that requires
> > >> ReadOnlyMetricRegistry.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that
> > >> forces user
> > >>>>>>>>>>>>> use
> > >>>>>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Why this is issue?
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> It’s consistent.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct
> > >> reference
> > >>>>>>>>>>>>>>>>>>>>> (performance problem).
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> 1. We(You and I) did this choice together to simplify
> > >> creation of
> > >>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>> new
> > >>>>>>>>>>>>>>>>>>>> metrics.
> > >>>>>>>>>>>>>>>>>>>> 2. This is not public API issue.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> I don’t ignore this flag.
> > >>>>>>>>>>>>>>>>>>>> It just doesn’t exists in new framework(because of
> > >> scope).
> > >>>>>>>>>>>>>>>>>>>> I don’t think it’s an issue.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy
> > >> best MBeans
> > >>>>>>>>>>>>>>>>>>> practices.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Please, clarify your statement.
> > >>>>>>>>>>>>>>>>>>>> What is best MBeans practices you are talking about?
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> How this can be API issue?
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 20:52, Andrey Gura <
> > >> [hidden email]>
> > >>>>>>>>>>>>>>> написал(а):
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are
> > >> fixed with my
> > >>>>>>>>>>>>>>> PR
> > >>>>>>>>>>>>>>>>>>>> [1].
> > >>>>>>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are
> > >> blocker for the
> > >>>>>>>>>>>>>>>>>> release.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> As I mentioned already IGNITE-11927 is part of IEP-35
> > >> and
> > >>>>>>>>>>>>>>>>>>>>> implementation seriously affects API's. Also I agree
> > >> with Alexey
> > >>>>>>>>>>>>>>>>>> about
> > >>>>>>>>>>>>>>>>>>>>> introducing public IgniteMonitoring facade. So thiss
> > >> PR doesn't
> > >>>>>>>>>>>>> fix
> > >>>>>>>>>>>>>>>>>>>>> all issues.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
> > >>>>>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this
> > >> contribution.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> It's right. But if you add checking of
> > >> statisticsEnabling property
> > >>>>>>>>>>>>>>>>>>>>> then test will fail. It's just not good tests.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create
> > >> a ticket I
> > >>>>>>>>>>>>> will
> > >>>>>>>>>>>>>>>>>>> fix
> > >>>>>>>>>>>>>>>>>>>> it ASAP.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> I already fix it all in IGNITE-11927
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> > >>>>>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't
> > >> hide major
> > >>>>>>>>>>>>>>>>>>>> contribution from the user just because your second
> > >> guess «I don’t
> > >>>>>>>>>>>>>>> like
> > >>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> API I just reviewed and approved».
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> We should move the product forward with with really
> > >> finished
> > >>>>>>>>>>>>>>>>>> features,
> > >>>>>>>>>>>>>>>>>>>>> not pieces of features.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> So I am against this proposal.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> It is not argument.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API
> > >> change and
> > >>>>>>>>>>>>> discuss
> > >>>>>>>>>>>>>>>>>>> them.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> We can prepare it together. But we can't block
> > >> release.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> > >>>>>>>>>>>>>>>>>>>>>> What is *ALL* problems?
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
> > >>>>>>>>>>>>>>>>>>>>> MetricExporterSpi that requires
> > >> ReadOnlyMetricRegistry.
> > >>>>>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that
> > >> forces user
> > >>>>>>>>>>>>> use
> > >>>>>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
> > >>>>>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
> > >>>>>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct
> > >> reference
> > >>>>>>>>>>>>>>>>>>>>> (performance problem).
> > >>>>>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
> > >>>>>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy
> > >> best MBeans
> > >>>>>>>>>>>>>>>>>>> practices.
> > >>>>>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> It's enough I believe.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:28 PM Николай Ижиков <
> > >>>>>>>>>>>>> [hidden email]
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Andrey.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are
> > >> fixed with my
> > >>>>>>>>>>>>> PR
> > >>>>>>>>>>>>>>>>>>> [1].
> > >>>>>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker
> > >> for the
> > >>>>>>>>>>>>>>>>>> release.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this
> > >> contribution.
> > >>>>>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create
> > >> a ticket I
> > >>>>>>>>>>>>> will
> > >>>>>>>>>>>>>>>>>>> fix
> > >>>>>>>>>>>>>>>>>>>> it ASAP.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't
> > >> hide major
> > >>>>>>>>>>>>>>>>>>>> contribution from the user just because your second
> > >> guess «I don’t
> > >>>>>>>>>>>>>>> like
> > >>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> API I just reviewed and approved».
> > >>>>>>>>>>>>>>>>>>>>>> So I am against this proposal.
> > >>>>>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API
> > >> change and
> > >>>>>>>>>>>>> discuss
> > >>>>>>>>>>>>>>>>>>> them.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> What is *ALL* problems?
> > >>>>>>>>>>>>>>>>>>>>>> Seems, we never be able to solve *ALL* problems.
> > >>>>>>>>>>>>>>>>>>>>>> But, we should move the product forward.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> As for your steps [1-6].
> > >>>>>>>>>>>>>>>>>>>>>> I’m always following these steps during my
> > >> contribution.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 19:08, Andrey Gura <
> > >> [hidden email]>
> > >>>>>>>>>>>>>>>>>> написал(а):
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> The discussion is hot and can be endless. So in
> > >> separate post I
> > >>>>>>>>>>>>>>>>>> want
> > >>>>>>>>>>>>>>>>>>>>>>> propose my solution.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
> > >>>>>>>>>>>>>>>>>>>>>>> 2. Create special feature branch B.
> > >>>>>>>>>>>>>>>>>>>>>>> 3. In branch B will be merged IGNITE-11927
> > >>>>>>>>>>>>>>>>>>>>>>> 4. Because IGNITE-11927 doesn't solve all problems
> > >> we should
> > >>>>>>>>>>>>>>>>>> propose
> > >>>>>>>>>>>>>>>>>>>>>>> solution and implement it in branch B.
> > >>>>>>>>>>>>>>>>>>>>>>> 5. Testing, usability testing, fixing, etc
> > >> iteratively.
> > >>>>>>>>>>>>>>>>>>>>>>> 6. Merge it to master and in new release branch if
> > >> needed.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Independent step. There are some problem which
> > >> should be fixed
> > >>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>>> 2.8
> > >>>>>>>>>>>>>>>>>>>>>>> before release otherwise we introduce problems with
> > >>>>>>>>>>>>> compatibility
> > >>>>>>>>>>>>>>>>>>>>>>> which will haunt us till next major release. I'll
> > >> create
> > >>>>>>>>>>>>> tickets.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:03 PM Andrey Gura <
> > >> [hidden email]>
> > >>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires
> > >> rewrite client
> > >>>>>>>>>>>>>>> code.
> > >>>>>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> > >>>>>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove
> > >> in the next
> > >>>>>>>>>>>>>>> major
> > >>>>>>>>>>>>>>>>>>>> release.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> We don't know anything about development processes
> > >> our users. I
> > >>>>>>>>>>>>>>>>>> can
> > >>>>>>>>>>>>>>>>>>>>>>>> admit that process could require that deprecated
> > >> methods/APIs
> > >>>>>>>>>>>>> are
> > >>>>>>>>>>>>>>>>>>> not
> > >>>>>>>>>>>>>>>>>>>>>>>> allowed for example.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange
> > >> interface which
> > >>>>>>>>>>>>> don't
> > >>>>>>>>>>>>>>>>>>> give
> > >>>>>>>>>>>>>>>>>>>> me any information about it’s purpose and
> > >> responsibilities.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1]
> > >> more clear:
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> I understand this. But I'm not Ignite user, I'm
> > >> Ignite
> > >>>>>>>>>>>>> developer.
> > >>>>>>>>>>>>>>>>>>> The
> > >>>>>>>>>>>>>>>>>>>>>>>> key moment in my message *from user stand point*.
> > >> From my point
> > >>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>>>>>> view it is very not intuitive solution and this
> > >> interface is
> > >>>>>>>>>>>>>>>>>>>>>>>> redundant.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
> > >> caches for
> > >>>>>>>>>>>>> example.
> > >>>>>>>>>>>>>>>>>>>> There are other entities with such flag.
> > >>>>>>>>>>>>>>>>>>>>>>>>> They still works as expected.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> Actually not. I fixed many such issues during
> > >> IGNITE-11927
> > >>>>>>>>>>>>>>>>>>>> implementation.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
> > >>>>>>>>>>>>>>>>>>>>>>>>> Because of the scope.
> > >>>>>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the
> > >> matter of the
> > >>>>>>>>>>>>> other
> > >>>>>>>>>>>>>>>>>>>> ticket.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> I talk not about ability. I talk about ignored
> > >> existing
> > >>>>>>>>>>>>>>>>>>> functionality.
> > >>>>>>>>>>>>>>>>>>>>>>>> So scope is not case here.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by
> > >> MetricExporterSpi
> > >>>>>>>>>>>>>>>>>>>> implementations.
> > >>>>>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter
> > >> to decide.
> > >>>>>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while
> > >> OpenCensus
> > >>>>>>>>>>>>> exporter
> > >>>>>>>>>>>>>>>>>>>> can’t.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> Actually list is not metric at all as I already
> > >> told.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 5:26 PM Николай Ижиков <
> > >>>>>>>>>>>>>>>>>> [hidden email]
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> Andrey.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires
> > >> rewrite client
> > >>>>>>>>>>>>>>> code.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
> > >>>>>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove
> > >> in the next
> > >>>>>>>>>>>>>>> major
> > >>>>>>>>>>>>>>>>>>>> release.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange
> > >> interface which
> > >>>>>>>>>>>>> don't
> > >>>>>>>>>>>>>>>>>>> give
> > >>>>>>>>>>>>>>>>>>>> me any information about it’s purpose and
> > >> responsibilities.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more
> > >> clear:
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> Each SPI would have a `ReadOnlyMetricManager`
> > >> which provides
> > >>>>>>>>>>>>>>>>>> access
> > >>>>>>>>>>>>>>>>>>>> to collection of `ReadOnlyMetricRegistry`
> > >>>>>>>>>>>>>>>>>>>>>>>>> which has a collection of `Metric`.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> So we reflects two-level structure we have in the
> > >> internal API
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> GridMetricManager -> Collection[MetricRegistry] ->
> > >>>>>>>>>>>>>>>>>>> Collection[Metric]
> > >>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricManager ->
> > >> Collection[ReadOnlyMetricRegistry] ->
> > >>>>>>>>>>>>>>>>>>>> Collection[Metric]
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
> > >> caches for
> > >>>>>>>>>>>>> example.
> > >>>>>>>>>>>>>>>>>>>> There are other entities with such flag.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> They still works as expected.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> Because of the scope.
> > >>>>>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the
> > >> matter of the
> > >>>>>>>>>>>>> other
> > >>>>>>>>>>>>>>>>>>>> ticket.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by
> > >> MetricExporterSpi
> > >>>>>>>>>>>>>>>>>>>> implementations.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter
> > >> to decide.
> > >>>>>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while
> > >> OpenCensus
> > >>>>>>>>>>>>> exporter
> > >>>>>>>>>>>>>>>>>>>> can’t.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> [1]
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >> https://github.com/apache/ignite/pull/7269/files#diff-0ae5657231fc4c1f650493b02190b81bR25
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 16:57, Andrey Gura <
> > >> [hidden email]>
> > >>>>>>>>>>>>>>>>>>>> написал(а):
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of
> > >> the active
> > >>>>>>>>>>>>>>>>>>> reviewers
> > >>>>>>>>>>>>>>>>>>>> of the Metric API.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Yes. But if I'm not missing some thing you were
> > >> major
> > >>>>>>>>>>>>> developer
> > >>>>>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Metric API :) Shit happens. And it happened.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
> > >> deprecation of APIs
> > >>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>>> are
> > >>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
> > >> substitution.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> There is such concept - backward compatibility.
> > >> I understand
> > >>>>>>>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>>>>>>>>>> deprecation of some interface doesn't break
> > >> backward
> > >>>>>>>>>>>>>>>>>> compatibility
> > >>>>>>>>>>>>>>>>>>>> but
> > >>>>>>>>>>>>>>>>>>>>>>>>>> it leads to question^ what should I use instead
> > >> of this. And
> > >>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi is not answer for this
> > >> question. Because it
> > >>>>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>>>>>> brand
> > >>>>>>>>>>>>>>>>>>>>>>>>>> new API and it requires rewrite client code.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal
> > >> MetricRegistry  to
> > >>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> exporters.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> No it is not. It's completely artificial thing
> > >> which allow
> > >>>>>>>>>>>>>>>>>> iterate
> > >>>>>>>>>>>>>>>>>>>> via
> > >>>>>>>>>>>>>>>>>>>>>>>>>> all metric registries. GridMetricManager
> > >> implements this
> > >>>>>>>>>>>>>>>>>> interface
> > >>>>>>>>>>>>>>>>>>>>>>>>>> while it is not metric registry. Form user stand
> > >> point it is
> > >>>>>>>>>>>>>>>>>> very
> > >>>>>>>>>>>>>>>>>>>>>>>>>> strange interface which don't give me any
> > >> information about
> > >>>>>>>>>>>>>>> it's
> > >>>>>>>>>>>>>>>>>>>>>>>>>> purpose and responsibilities.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
> > >> caches for
> > >>>>>>>>>>>>> example.
> > >>>>>>>>>>>>>>>>>>>> There
> > >>>>>>>>>>>>>>>>>>>>>>>>>> are other entities with such flag.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way? Why you
> > >> ignore existing
> > >>>>>>>>>>>>>>>>>>>>>>>>>> functionality? It affects user expectations and
> > >> experience.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Yes? I'm working. Unfortunately we are not
> > >> synchronized in
> > >>>>>>>>>>>>> this
> > >>>>>>>>>>>>>>>>>>>>>>>>>> context and I should redo all metrics related
> > >> changes in
> > >>>>>>>>>>>>> order
> > >>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>>>>>>>> merge it with my changes. Anyway, my change
> > >> doesn't solve all
> > >>>>>>>>>>>>>>>>>>>> problems
> > >>>>>>>>>>>>>>>>>>>>>>>>>> (e.g. it doesn't introduce IgniteMonitoring
> > >> facade).
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Unfortunately it will be just fix. In my
> > >> solution it is
> > >>>>>>>>>>>>>>>>>> redesign.
> > >>>>>>>>>>>>>>>>>>>> Stop
> > >>>>>>>>>>>>>>>>>>>>>>>>>> fixing issues, let's do things. It requires
> > >> deeper changes.
> > >>>>>>>>>>>>> My
> > >>>>>>>>>>>>>>>>>>>> changes
> > >>>>>>>>>>>>>>>>>>>>>>>>>> blocks AI 2.8 release because it big enough. So
> > >> it retargeted
> > >>>>>>>>>>>>>>> on
> > >>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>>>>> next release. And it is one more reason for
> > >> moving the
> > >>>>>>>>>>>>> changes
> > >>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>>>>> internal packages. And it isn't good news for me
> > >> because I
> > >>>>>>>>>>>>> will
> > >>>>>>>>>>>>>>>>>> go
> > >>>>>>>>>>>>>>>>>>>>>>>>>> throughout pan and tiers of merge. But it is
> > >> right.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
> > >> compatibility.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
> > >> compatibility.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Yes, I know. But they should not be exported by
> > >>>>>>>>>>>>>>>>>> MetricExporterSpi
> > >>>>>>>>>>>>>>>>>>>>>>>>>> implementations.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 3:37 PM Николай Ижиков <
> > >>>>>>>>>>>>>>>>>>> [hidden email]>
> > >>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey, thanks for your opinion and your ownest
> > >> critisism.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> I can’t wait for your contribution.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of
> > >> the active
> > >>>>>>>>>>>>>>>>>>> reviewers
> > >>>>>>>>>>>>>>>>>>>> of the Metric API.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
> > >> deprecation of APIs
> > >>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>>> are
> > >>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
> > >> substitution.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't
> > >> recommend
> > >>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still
> > >> not-production ready.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> It’s ready.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the
> > >> public API
> > >>>>>>>>>>>>> doesn't
> > >>>>>>>>>>>>>>>>>>>> solve the problem because this interface exposes
> > >> internal Metric
> > >>>>>>>>>>>>>>>>>>> interface
> > >>>>>>>>>>>>>>>>>>>> implementations.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Not, its’ not.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Please, see
> > >> `org.apache.ignite.spi.metric.LongMetric` and
> > >>>>>>>>>>>>>>> other
> > >>>>>>>>>>>>>>>>>>>> public interface.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> API of MetricRegistry is inconsistent.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> MetricRegistry is the internal API.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Feel free to create ticket for an issues with
> > >> it and I will
> > >>>>>>>>>>>>>>> try
> > >>>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>> fix it.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal
> > >> MetricRegistry  to
> > >>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> exporters.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
> > >> compatibility.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 15:09, Andrey Gura <
> > >> [hidden email]>
> > >>>>>>>>>>>>>>>>>>>> написал(а):
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
> > >> deprecation of APIs
> > >>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>>> are
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
> > >> substitution.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't
> > >> recommend
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still
> > >> not-production
> > >>>>>>>>>>>>>>> ready.
> > >>>>>>>>>>>>>>>>>>>> There
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> are some issues with it and usage of
> > >> ReadOnlyMetricRegistry
> > >>>>>>>>>>>>>>>>>>>> interface
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> just one of them.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the
> > >> public API
> > >>>>>>>>>>>>> doesn't
> > >>>>>>>>>>>>>>>>>>>> solve
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> the problem because this interface exposes
> > >> internal Metric
> > >>>>>>>>>>>>>>>>>>>> interface
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> implementations. So your PR is incomplete.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Moreover, API of MetricRegistry is
> > >> inconsistent. E.g.
> > >>>>>>>>>>>>>>>>>>>> register(name,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> supplier, desc) method returns registered
> > >> metric for some
> > >>>>>>>>>>>>>>>>>> types
> > >>>>>>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> doesn't for other. register(metric) method is
> > >> inconsistent
> > >>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>>>>> sense of
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> metric naming. ReadOnlyMetricRegistry
> > >> interface is
> > >>>>>>>>>>>>> redundant.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi should be revised because it
> > >> absolutely
> > >>>>>>>>>>>>> not
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> intuitive because it requires
> > >> ReadOnlyMetricRegistry and
> > >>>>>>>>>>>>> it's
> > >>>>>>>>>>>>>>>>>>>> purpose
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> is undefined.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> One more point. IEP-35 is still not fully
> > >> implemented. Some
> > >>>>>>>>>>>>>>>>>>>> things are
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> not taken into account. Exporters expose
> > >> metrics if they
> > >>>>>>>>>>>>> are
> > >>>>>>>>>>>>>>>>>>>> disabled.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> JMX beans exposes values that don't confirm to
> > >> best
> > >>>>>>>>>>>>> practices
> > >>>>>>>>>>>>>>>>>>> [1].
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
> > >> Ubiquitous
> > >>>>>>>>>>>>>>> merics
> > >>>>>>>>>>>>>>>>>>>> lookup
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> from hash map instead of usage reference for
> > >> getting
> > >>>>>>>>>>>>> metrics
> > >>>>>>>>>>>>>>>>>>>> values
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> (it is just performance issue). Also
> > >> IGNITE-11927 is not
> > >>>>>>>>>>>>>>>>>>>> implemented
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> which also changes interfaces significantly.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Let's just admit that the implementation is
> > >> immature and
> > >>>>>>>>>>>>> must
> > >>>>>>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>>>>> moved
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> to the internal packages.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> And because we already merged partially
> > >> implemented IEP to
> > >>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> master
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> branch we *must move all currently public APIs
> > >> to the
> > >>>>>>>>>>>>>>> internal
> > >>>>>>>>>>>>>>>>>>>> API*
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> while it will not be ready for publication.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> And the last but not least. What is happening
> > >> indicates a
> > >>>>>>>>>>>>>>>>>>> immature
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> development process which must be revised. I
> > >> don't want
> > >>>>>>>>>>>>>>>>>> discuss
> > >>>>>>>>>>>>>>>>>>>> it in
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> this thread but we must not allow merge of
> > >> change to the
> > >>>>>>>>>>>>>>>>>> master
> > >>>>>>>>>>>>>>>>>>>> branch
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> before it will completed, that is we must use
> > >> feature
> > >>>>>>>>>>>>>>> branches
> > >>>>>>>>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> full IEP not only for particular tickets. And
> > >> also we
> > >>>>>>>>>>>>> should
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> reformulate IEP process in order to avoid
> > >> things like this.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >> https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:49 PM Николай
> > >> Ижиков <
> > >>>>>>>>>>>>>>>>>>>> [hidden email]> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alex.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK, I may leverage your experience and create
> > >> pure Java
> > >>>>>>>>>>>>> API.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ticket [1] created.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> But, personally, I don’t agree with you.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ignite has dozens of the API that
> > >> theoretically have a
> > >>>>>>>>>>>>> usage
> > >>>>>>>>>>>>>>>>>>>> scenario, but in real-world have 0 custom
> > >> implementation and
> > >>>>>>>>>>>>> usages.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Moreover, many APIs that were created with
> > >> the intentions
> > >>>>>>>>>>>>>>> you
> > >>>>>>>>>>>>>>>>>>>> mentioned is abandoned now and confuses users.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can just see count of the tests we just
> > >> mute on the
> > >>>>>>>>>>>>> TC.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Can you, please, take a look at the fix
> > >> regarding puck API
> > >>>>>>>>>>>>>>>>>>> issue
> > >>>>>>>>>>>>>>>>>>>> you mentioned in your first letter [2], [3]
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
> > >> https://issues.apache.org/jira/browse/IGNITE-12553
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [2]
> > >> https://github.com/apache/ignite/pull/7269
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [3]
> > >> https://issues.apache.org/jira/browse/IGNITE-12552
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 12:12, Alexey Goncharuk <
> > >>>>>>>>>>>>>>>>>>>> [hidden email]> написал(а):
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nikolay,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why do you think this is a wrong usage
> > >> pattern? From the
> > >>>>>>>>>>>>>>> top
> > >>>>>>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>> my head,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here is a few cases of direct metric API
> > >> usage that I
> > >>>>>>>>>>>>> know
> > >>>>>>>>>>>>>>>>>> are
> > >>>>>>>>>>>>>>>>>>>> currently
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> being used in production:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom task execution scheduling service
> > >> with load
> > >>>>>>>>>>>>>>>>>>>> balancing based on
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> utilization metrics readings from Java code
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * Cleanup task trigger based on metrics
> > >> readings
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom health-check endpoint for an
> > >> application with
> > >>>>>>>>>>>>> an
> > >>>>>>>>>>>>>>>>>>>> embedded
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ignite node for Kubernetes/Spring
> > >> Application/etc
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> > >>
> >

[Nikolay Izhikov-2]

Maxim.

I’m +1 to do it.

> 1. Let's keep @deprecated annotation to notify users earlier.
> 2. Let's fix javadoc comments for this annotation (remove internal references).

We also have a consensus to add IgniteExperimental annotation to the new metrics API.

> 28 янв. 2020 г., в 19:05, Maxim Muzafarov <[hidden email]> написал(а):
>
> Folks,
>
>
> Let me share my humble opinion over this thread. The first priority
> here is making Ignite better and taking the next step with releasing
> Ignite's 2.8 version for our users (we've already done a great job
> with metrics).
>
> According to this point of view and from the user perspective I'd like
> to be notified about changing Ignite's architecture and concepts of
> using metrics as early as possible not only through the public
> documentation but through the code I write also.
>
> So, I see nothing strange by keeping @deprecated annotation (Javadoc
> comments must be fixed, true):
> 1. it's just a hint for users (we will notify them as earlier as
> possible but they can still write a code using deprecated methods)
> 2. users will be notified about new JmxMetricExporterSpi through the
> code and documentation.
> 3. it's a recommendation for developers that they should not add new
> methods to the old facade.
>
> I also see nothing strange by removing @deprecated annotation
> currently added to DataRegionMetrics interface. It's also OK if we are
> still developing new facade and do not want to share some public API
> changes with users because all the 2.8 release looks for me like an
> experimental.
>
>
> So, summarizing:
> 1. Let's keep @deprecated annotation to notify users earlier.
> 2. Let's fix javadoc comments for this annotation (remove internal references).
> 3. Let's do not too much debate here. This question isn't too
> important compared to 23 critical release issues [1].
>
>
> Alexey, Andrey, Nikolay,
>
> Can we proceed this way?
>
>
> P.S.
> From the release managers view, it's sad to see such a discussions
> about API changes and compatibility because we've discussed API at
> July 2019 [3] and all issues with monitoring activities at October
> 2019 [2].
>
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolvedissues(notrelatedtodocumentation)
> [2] http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-tp43616p43807.html
> [3] https://issues.apache.org/jira/browse/IGNITE-11848
>
> On Mon, 27 Jan 2020 at 22:23, Andrey Gura <[hidden email]> wrote:
>>
>>>> I just want to remove the deprecations on the classes for which there is no a well-defined replacement.
>>> Well-defined replacement for these classes exists.
>>
>> Nikolay, statements like this are not arguments. At least because
>> there are people who disagree with this.
>>
>> Current implementation is not well-defined due to API is not
>> well-defined enough. Also there are lack of functionality
>> (enabling/disabling metrics, requirement for end user to configure new
>> exporter in order to get a couple of new metrics while it is still
>> possible to use old MBeans but without this metrics) and potential
>> performance problems (that couldn't be solved because metrics couldn't
>> be switched off).
>>
>> We are walking in a circle instead of moving forward. On comments
>> about API you provide new PRs that change API while denying problems
>> with the API. This is illogical and process doesn't converge because
>> it is attempt to close gaps in a hurry.
>>
>> The best we can do now is stop, take a deep breath and follow the
>> offers of Alexey about deprecation, my proposal and Denis' idea about
>> one additional iteration.
>>
>> On Mon, Jan 27, 2020 at 4:37 PM Nikolay Izhikov <[hidden email]> wrote:
>>>
>>>> it's better to remove deprecation for the old APIs in AI 2.8
>>>
>>> Are you suggest to have 2 concurrent metrics implementations(both not deprecated)?
>>>
>>>> Let's say I am writing a custom exporter in binary format and I need to write the number of exported metrics in a packet beforehand.
>>>
>>> This an `MetricExporterSPI` implementation task.
>>> Exporter has the listeners that can be used to track all registry events - creation, removal
>>>
>>>> There is no separation on public and internal metrics
>>>
>>> I think we should write in the documentation that ANY metric can be changed.
>>> We will try to keep them, but if we found that some metric doesn’t required any more or implemented in the wrong way - we can remove it.
>>>
>>>> Will we allow users to register their own metrics?
>>>
>>> No. Why we should considering this feature?
>>>
>>>> It's still not clear how a user will map old interfaces and methods to the new metric names.
>>>
>>> With the documentation.
>>> We can write separate deprecation comment for each metric providing method.
>>>
>>>> I just want to remove the deprecations on the classes for which there is no a well-defined replacement.
>>>
>>> Well-defined replacement for these classes exists.
>>>
>>>> 27 янв. 2020 г., в 16:21, Alexey Goncharuk <[hidden email]> написал(а):
>>>>
>>>> Nikolay,
>>>>
>>>> I've reviewed your changes and I tend to agree with Andrey, it's better to
>>>> remove deprecation for the old APIs in AI 2.8 and discuss and merge the new
>>>> facade (IGNITE-12553) in a more calm and structured way. My observations on
>>>> the changes:
>>>>
>>>>  - I am not sure if Iterable would suffice both for the exporter and
>>>>  public APIs. Should we provide a way to know the number of metrics and
>>>>  registries in advance? Let's say I am writing a custom exporter in binary
>>>>  format and I need to write the number of exported metrics in a packet
>>>>  beforehand.
>>>>  - There is no separation on public and internal metrics, when public
>>>>  metrics preserve their name and semantics, and internal metrics may change.
>>>>  I remember we discussed this, but it's not reflected in the APIs in any way.
>>>>  - Will we allow users to register their own metrics? Again I remember we
>>>>  discussed a possibility for this. If so, why the registry is called
>>>>  'ReadyOnly'?
>>>>  - It's still not clear how a user will map old interfaces and methods to
>>>>  the new metric names.
>>>>
>>>> As you can see in the original message, I am not pushing for the new APIs
>>>> in the nearest release, I just want to remove the deprecations on the
>>>> classes for which there is no a well-defined replacement.
>>>>
>>>> пн, 27 янв. 2020 г. в 15:56, Maxim Muzafarov <[hidden email]>:
>>>>
>>>>> Folks,
>>>>>
>>>>>
>>>>> I'm sorry for not being too attentive to the whole thread discussion
>>>>> and maybe missing some details.
>>>>>
>>>>> But... who will perform the review of [1] issue?
>>>>> Will we merge it to 2.8? (hope so)
>>>>>
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-12553
>>>>> [IEP-35] public Java metric API
>>>>>
>>>>> On Sat, 25 Jan 2020 at 11:43, Николай Ижиков <[hidden email]> wrote:
>>>>>>
>>>>>> Andrey.
>>>>>>
>>>>>> With this API we are trying to fill the GAP Alexey pointed out at the
>>>>> start of this discussion.
>>>>>> I think it worth to be reviewed and merged.
>>>>>>
>>>>>> Can we, please, come back to the discussion of the changes itself?
>>>>>> I think API changes should be discussed in the other thread.
>>>>>>
>>>>>>> Why do you think this is a wrong usage pattern? From the top of my
>>>>> head, here is a few cases of direct metric API usage that I know are
>>>>> currently being used in production:
>>>>>>> * A custom task execution scheduling service with load balancing based
>>>>> on utilization metrics readings from Java code
>>>>>>> * Cleanup task trigger based on metrics readings
>>>>>>> * A custom health-check endpoint for an application with an embedded
>>>>> Ignite node for Kubernetes/Spring Application/etc
>>>>>>
>>>>>> [1] https://github.com/apache/ignite/pull/7283
>>>>>>
>>>>>>> 24 янв. 2020 г., в 18:08, Andrey Gura <[hidden email]> написал(а):
>>>>>>>
>>>>>>>> My point - that your contribution that took a long time, already,
>>>>> can’t be an argument to postpone creation of the API in the current release.
>>>>>>>
>>>>>>> Argument is not about time. But about API which is known will be
>>>>> changed.
>>>>>>> Second argument: why we should add this experimental API to the
>>>>>>> already existing experimental API? Just to making API more
>>>>>>> experimental? As I told already it is commit for commit and doesn't
>>>>>>> bring any value but brings some inconvenience to me (e.g. merge
>>>>>>> problems).
>>>>>>>
>>>>>>> BTW, does it exist issue about marking IEP-35 API's as experimental?
>>>>>>>
>>>>>>> On Thu, Jan 23, 2020 at 8:33 PM Николай Ижиков <[hidden email]>
>>>>> wrote:
>>>>>>>>
>>>>>>>>> You want say didn't discuss?
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>>> Secondly, yes it took a lot of time due to a lot of changes. Is it
>>>>> problem?
>>>>>>>>
>>>>>>>> No, of course.
>>>>>>>> My point - that your contribution that took a long time, already,
>>>>> can’t be an argument to postpone creation of the API in the current release.
>>>>>>>>
>>>>>>>>
>>>>>>>>> 23 янв. 2020 г., в 18:11, Andrey Gura <[hidden email]> написал(а):
>>>>>>>>>
>>>>>>>>>> We don’t discuss your changes and your proposals for the Metric API.
>>>>>>>>>
>>>>>>>>> You want say didn't discuss? Actually we did it [1] but you told ok
>>>>>>>>> let's see code :)
>>>>>>>>>
>>>>>>>>>> So I don’t think we can make the existence of some PR is an
>>>>> argument to introduce(or not introduce) this facade.
>>>>>>>>>
>>>>>>>>> You definitely right in case of competition development. But I think
>>>>>>>>> that collaborative development is more effective. Isn't it?
>>>>>>>>>
>>>>>>>>>> Moreover, As far as I know, you developing changes for the Metric
>>>>> API for 5 months without public discussion, for now. Let's start it.
>>>>>>>>>
>>>>>>>>> Firsty, with discussion. See above.
>>>>>>>>> Secondly, yes it took a lot of time due to a lot of changes. Is it
>>>>> problem?
>>>>>>>>>
>>>>>>>>>> Let’s do the following:
>>>>>>>>>> 1. Review `IgniteMetric` facade and introduce it to the users as an
>>>>> experimental API.
>>>>>>>>>
>>>>>>>>> It just doesn't make sense. Just commit for commit.
>>>>>>>>>
>>>>>>>>>> 2. Discuss your proposal to the Metric API in the separate thread
>>>>> you are referencing.
>>>>>>>>>
>>>>>>>>> You a re welcome to thread [1] again. But please, take into account.
>>>>>>>>> because discussion is postponed by you it's late enough to discuss
>>>>>>>>> proposed solution. But of course I'll answer on your questions and
>>>>>>>>> will be glade to your comments and suggestions.
>>>>>>>>>
>>>>>>>>>> I think we should start a discussion from the simplified
>>>>> explanation of:
>>>>>>>>>> 1. API intentions - What we want to gain with it? What is our focus?
>>>>>>>>>> 2. Simple, minimal example of API main interfaces and desired
>>>>> usages.
>>>>>>>>>
>>>>>>>>> All this already described at [1]. You also can take a look on PR
>>>>> (see
>>>>>>>>> MetricSource implementations, there are complex and simple ones).
>>>>>>>>>
>>>>>>>>> [1]
>>>>> http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Metrics-management-in-Ignite-tp43243.html
>>>>>>>>>
>>>>>>>>> On Thu, Jan 23, 2020 at 5:42 PM Николай Ижиков <[hidden email]>
>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Andrey.
>>>>>>>>>>
>>>>>>>>>>> IGNITE-11927 implementation so your changes are incompatible with
>>>>> my changes
>>>>>>>>>>
>>>>>>>>>> We don’t discuss your changes and your proposals for the Metric API.
>>>>>>>>>> So I don’t think we can make the existence of some PR is an
>>>>> argument to introduce(or not introduce) this facade.
>>>>>>>>>> Moreover, As far as I know, you developing changes for the Metric
>>>>> API for 5 months without public discussion, for now. Let's start it.
>>>>>>>>>>
>>>>>>>>>> Let’s do the following:
>>>>>>>>>>
>>>>>>>>>> 1. Review `IgniteMetric` facade and introduce it to the users as an
>>>>> experimental API.
>>>>>>>>>>
>>>>>>>>>> 2. Discuss your proposal to the Metric API in the separate thread
>>>>> you are referencing.
>>>>>>>>>>
>>>>>>>>>> I think we should start a discussion from the simplified
>>>>> explanation of:
>>>>>>>>>>
>>>>>>>>>> 1. API intentions - What we want to gain with it? What is our focus?
>>>>>>>>>> 2. Simple, minimal example of API main interfaces and desired
>>>>> usages.
>>>>>>>>>>
>>>>>>>>>> This will help to the community and me personally better understand
>>>>> your idea and share feedback.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>>> 23 янв. 2020 г., в 17:15, Andrey Gura <[hidden email]>
>>>>> написал(а):
>>>>>>>>>>>
>>>>>>>>>>> Nikolay,
>>>>>>>>>>>
>>>>>>>>>>> as I wrote early in this thread API significantly changed during
>>>>>>>>>>> IGNITE-11927 implementation so your changes are incompatible with
>>>>> my
>>>>>>>>>>> changes.
>>>>>>>>>>>
>>>>>>>>>>> ReadOnlyMetricRegistry will be removed at all (still exists in a
>>>>>>>>>>> couple of places where it uses).
>>>>>>>>>>>
>>>>>>>>>>> Also I don't want to introduce IgniteMetric facade in this rush. In
>>>>>>>>>>> current implementation this interface just provides access to the
>>>>>>>>>>> ReadOnlyMetricManager instance (which will be removed) but it is
>>>>> not
>>>>>>>>>>> enough.
>>>>>>>>>>>
>>>>>>>>>>> I agree with Denis. We should mark current API as experimental and
>>>>>>>>>>> continue IEP-35 development. See my process proposal [1] described
>>>>>>>>>>> early this thread. We can release Apache Ignite 2.8.1 specially for
>>>>>>>>>>> this changes.
>>>>>>>>>>> Public APIs require deeper thinking in order to provide
>>>>> comprehensive,
>>>>>>>>>>> consistent and convenient way of metrics management for end users.
>>>>>>>>>>>
>>>>>>>>>>> Let's add IgniteExperimental, release 2.8 and finish metrics
>>>>> related
>>>>>>>>>>> issues after it.
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>> http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-tp45146p45185.html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jan 22, 2020 at 5:21 PM Николай Ижиков <
>>>>> [hidden email]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hello, Igniters.
>>>>>>>>>>>>
>>>>>>>>>>>> * IGNITE-12552: Move ReadOnlyMetricRegistry to public API merged
>>>>> to the master and cherry-picked to the 2.8.
>>>>>>>>>>>> So the main issue with the Metric API solved.
>>>>>>>>>>>>
>>>>>>>>>>>> * I raised the PR [1] to fix second issue with the new Metric
>>>>> API: absence of the public Java API to get metrics.
>>>>>>>>>>>> This PR introduces the following changes:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. IgniteMetric interface created: it provides Java API to access
>>>>> Ignite metrics created with the new Metric API.
>>>>>>>>>>>>
>>>>>>>>>>>> ```
>>>>>>>>>>>> public interface IgniteMetric extends
>>>>> Iterable<ReadOnlyMetricRegistry> {
>>>>>>>>>>>> @Nullable ReadOnlyMetricRegistry registry(String name);
>>>>>>>>>>>> }
>>>>>>>>>>>> ```
>>>>>>>>>>>>
>>>>>>>>>>>> 2. All deprecation javadocs regarding metrics now reference to
>>>>> the public IgniteMetric instead of internal GridMetricManager:
>>>>>>>>>>>>
>>>>>>>>>>>>> @deprecated Use {@link IgniteMetric} instead.
>>>>>>>>>>>>
>>>>>>>>>>>> 3. Tests refactored to use IgniteMetric instead of
>>>>> GridMetricManager when possible.
>>>>>>>>>>>>
>>>>>>>>>>>> Please, review.
>>>>>>>>>>>>
>>>>>>>>>>>> [1]  https://github.com/apache/ignite/pull/7283
>>>>>>>>>>>>
>>>>>>>>>>>>> 21 янв. 2020 г., в 17:51, Николай Ижиков <[hidden email]>
>>>>> написал(а):
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello, Igniters.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Alexey approved my PR [1] regarding fixing public API for metric
>>>>> exporters.
>>>>>>>>>>>>> I’m waiting for a bot visa and merge this PR.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As we discussed, the metrics API will be marked with
>>>>> IgniteExperimental annotation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If anyone has any objection to this plan, please provide your
>>>>> feedback.
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 21 янв. 2020 г., в 13:45, Николай Ижиков <
>>>>> [hidden email]> написал(а):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks, for the review Alexey.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I will fix your comment and  try to implement Monitoring
>>>>> facade, shortly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 21 янв. 2020 г., в 13:32, Alexey Goncharuk <
>>>>> [hidden email]> написал(а):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nikolay,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I left a single comment in the PR about the histogram metric.
>>>>> I think the
>>>>>>>>>>>>>>> API looks much cleaner now.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I will take care of the @IgniteExperimental annotation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> пн, 20 янв. 2020 г. в 20:55, Николай Ижиков <
>>>>> [hidden email]>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> PR [1] is waiting for your review.
>>>>>>>>>>>>>>>> Please, take a look.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think we should do the following before 2.8 release
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * Introduce new @IgniteExperimental annotation as discussed.
>>>>>>>>>>>>>>>> * Mark Monitoring API with it.
>>>>>>>>>>>>>>>> * merge «[IEP-35] Expose MetricRegistry to the public API» to
>>>>> 2.8
>>>>>>>>>>>>>>>> * merge «[IEP-35] public Java metric API» to 2.8
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk <
>>>>> [hidden email]>
>>>>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nikolay,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Should we wait for both of the tickets given that we agreed
>>>>> that we are
>>>>>>>>>>>>>>>>> putting an experimental marker on the new APIs? I'm ok to
>>>>> fix only the
>>>>>>>>>>>>>>>>> first one and add the experimental marker so that we do not
>>>>> delay 2.8
>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков <
>>>>> [hidden email]>:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Andrey.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Let’s move from the long letters to the code.
>>>>>>>>>>>>>>>>>> If you want to change API - please, propose this changes.
>>>>>>>>>>>>>>>>>> I think everybody wins if we make our API better.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Please, describe proposed changes.
>>>>>>>>>>>>>>>>>> It would be great if you have some examples or PR for it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As for this release, I have plans to contribute tickets
>>>>>>>>>>>>>>>>>> «[IEP-35] Expose MetricRegistry to the public API» [1] and
>>>>>>>>>>>>>>>>>> «[IEP-35] public Java metric API» [2] for it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Any objections on it?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-12553
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 20 янв. 2020 г., в 13:08, Andrey Gura <[hidden email]>
>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It solves problem.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
>>>>>>>>>>>>>>>>>>> <[hidden email]> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> After giving it some thought, I agree with Denis - there
>>>>> is nothing
>>>>>>>>>>>>>>>>>> wrong
>>>>>>>>>>>>>>>>>>>> with exposing the new APIs, we just need to make it clear
>>>>> that we are
>>>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>>>>> going to change it.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Should we Introduce something like @IgniteExperimental
>>>>> annotation (I
>>>>>>>>>>>>>>>>>>>> believe it has been discussed a dozen of times on the
>>>>> dev-list)?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov <
>>>>> [hidden email]>:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> +1 to mark feature or whole release as EA.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> пт, 17 янв. 2020 г., 23:00 Denis Magda <
>>>>> [hidden email]>:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Folks, if you don't mind I'll share some
>>>>> thoughts/suggestions as an
>>>>>>>>>>>>>>>>>>>>>> observer who was not involved in the feature
>>>>> development.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It's absolutely 'ok' to deprecate an API that is
>>>>> replaced with a
>>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>>>>>>> better version. However, we should do this only when
>>>>> the new APIs
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>> production-ready. If there are still many limitations
>>>>> or open items
>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>>>> don't deprecate anything that exists and release the
>>>>> new APIs
>>>>>>>>>>>>>>>>>> labeling as
>>>>>>>>>>>>>>>>>>>>>> early access. What if release the improvements labeling
>>>>> as EA
>>>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>> hiding them completely?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I would also encourage us to put aside emotions, don't
>>>>> blame or
>>>>>>>>>>>>>>>> point
>>>>>>>>>>>>>>>>>>>>>> fingers. This IEP is a great initiative and you both
>>>>> have already
>>>>>>>>>>>>>>>>>> done a
>>>>>>>>>>>>>>>>>>>>>> tremendous job by developing, architecting and
>>>>> reviewing changes.
>>>>>>>>>>>>>>>>>> Just be
>>>>>>>>>>>>>>>>>>>>>> respectful. Nobody is trying to block the feature from
>>>>> being
>>>>>>>>>>>>>>>> released.
>>>>>>>>>>>>>>>>>>>>>> Everyone would be glad to tap into improvements and
>>>>> start using them
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>> prod. But if more time is needed for the GA let's
>>>>> reiterate a bit.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>>>> Denis
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков <
>>>>>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Also I agree with Alexey about introducing public
>>>>> IgniteMonitoring
>>>>>>>>>>>>>>>>>>>>>> facade
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> This is not an issue with the API.
>>>>>>>>>>>>>>>>>>>>>>> Just the new feature that doesn’t affects API.
>>>>>>>>>>>>>>>>>>>>>>> Moreover, I create a ticket to fix it, already.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It's right. But if you add checking of
>>>>> statisticsEnabling property
>>>>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>>>>> test will fail. It's just not good tests.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> My changes doesn’t affect any `staticticsEnabled`
>>>>> property.
>>>>>>>>>>>>>>>>>>>>>>> I don’ understand your point here.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It’s not redundant.
>>>>>>>>>>>>>>>>>>>>>>> It required for exporters and provide read only access
>>>>> to
>>>>>>>>>>>>>>>>>>>>> MetricRegistry
>>>>>>>>>>>>>>>>>>>>>>> existing in the node.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi that requires
>>>>> ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that
>>>>> forces user
>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Why this is issue?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It’s consistent.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct
>>>>> reference
>>>>>>>>>>>>>>>>>>>>>>>> (performance problem).
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 1. We(You and I) did this choice together to simplify
>>>>> creation of
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>>>>>> metrics.
>>>>>>>>>>>>>>>>>>>>>>> 2. This is not public API issue.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I don’t ignore this flag.
>>>>>>>>>>>>>>>>>>>>>>> It just doesn’t exists in new framework(because of
>>>>> scope).
>>>>>>>>>>>>>>>>>>>>>>> I don’t think it’s an issue.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy
>>>>> best MBeans
>>>>>>>>>>>>>>>>>>>>>> practices.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Please, clarify your statement.
>>>>>>>>>>>>>>>>>>>>>>> What is best MBeans practices you are talking about?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> How this can be API issue?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 20:52, Andrey Gura <
>>>>> [hidden email]>
>>>>>>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are
>>>>> fixed with my
>>>>>>>>>>>>>>>>>> PR
>>>>>>>>>>>>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are
>>>>> blocker for the
>>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> As I mentioned already IGNITE-11927 is part of IEP-35
>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>> implementation seriously affects API's. Also I agree
>>>>> with Alexey
>>>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>>>>>> introducing public IgniteMonitoring facade. So thiss
>>>>> PR doesn't
>>>>>>>>>>>>>>>> fix
>>>>>>>>>>>>>>>>>>>>>>>> all issues.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
>>>>>>>>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this
>>>>> contribution.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It's right. But if you add checking of
>>>>> statisticsEnabling property
>>>>>>>>>>>>>>>>>>>>>>>> then test will fail. It's just not good tests.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create
>>>>> a ticket I
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>> fix
>>>>>>>>>>>>>>>>>>>>>>> it ASAP.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I already fix it all in IGNITE-11927
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't
>>>>> hide major
>>>>>>>>>>>>>>>>>>>>>>> contribution from the user just because your second
>>>>> guess «I don’t
>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> API I just reviewed and approved».
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> We should move the product forward with with really
>>>>> finished
>>>>>>>>>>>>>>>>>>>>> features,
>>>>>>>>>>>>>>>>>>>>>>>> not pieces of features.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> So I am against this proposal.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It is not argument.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API
>>>>> change and
>>>>>>>>>>>>>>>> discuss
>>>>>>>>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> We can prepare it together. But we can't block
>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
>>>>>>>>>>>>>>>>>>>>>>>>> What is *ALL* problems?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Redundant ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi that requires
>>>>> ReadOnlyMetricRegistry.
>>>>>>>>>>>>>>>>>>>>>>>> Absence of newly created metrics in old MBeans that
>>>>> forces user
>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>> exporter SPI while his code base uses old MBeans.
>>>>>>>>>>>>>>>>>>>>>>>> Inconsistent MetricRegistry API.
>>>>>>>>>>>>>>>>>>>>>>>> Metrics lookups from map instead of using direct
>>>>> reference
>>>>>>>>>>>>>>>>>>>>>>>> (performance problem).
>>>>>>>>>>>>>>>>>>>>>>>> Ignoring of statisticsEnabled flag.
>>>>>>>>>>>>>>>>>>>>>>>> JmxExporterSpi creates beans that doesn't satisfy
>>>>> best MBeans
>>>>>>>>>>>>>>>>>>>>>> practices.
>>>>>>>>>>>>>>>>>>>>>>>> Not finished IGNITE-11927
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It's enough I believe.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:28 PM Николай Ижиков <
>>>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Andrey.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> All issues Alexey mentioned in starting letter are
>>>>> fixed with my
>>>>>>>>>>>>>>>> PR
>>>>>>>>>>>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>>>>>>>>>>>> I don’t think other issues you mentioned are blocker
>>>>> for the
>>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I talk about ignored existing functionality.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> There is no existing tests that was broken by this
>>>>> contribution.
>>>>>>>>>>>>>>>>>>>>>>>>> If you know the issues with it, feel free to create
>>>>> a ticket I
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>> fix
>>>>>>>>>>>>>>>>>>>>>>> it ASAP.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> We should move the product forward and shouldn't
>>>>> hide major
>>>>>>>>>>>>>>>>>>>>>>> contribution from the user just because your second
>>>>> guess «I don’t
>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> API I just reviewed and approved».
>>>>>>>>>>>>>>>>>>>>>>>>> So I am against this proposal.
>>>>>>>>>>>>>>>>>>>>>>>>> But, I’m ready to see your proposal for the API
>>>>> change and
>>>>>>>>>>>>>>>> discuss
>>>>>>>>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Because IGNITE-11927 doesn't solve all problems
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> What is *ALL* problems?
>>>>>>>>>>>>>>>>>>>>>>>>> Seems, we never be able to solve *ALL* problems.
>>>>>>>>>>>>>>>>>>>>>>>>> But, we should move the product forward.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> As for your steps [1-6].
>>>>>>>>>>>>>>>>>>>>>>>>> I’m always following these steps during my
>>>>> contribution.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 19:08, Andrey Gura <
>>>>> [hidden email]>
>>>>>>>>>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> The discussion is hot and can be endless. So in
>>>>> separate post I
>>>>>>>>>>>>>>>>>>>>> want
>>>>>>>>>>>>>>>>>>>>>>>>>> propose my solution.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 1. Moving IEP-35 API's to the internal package.
>>>>>>>>>>>>>>>>>>>>>>>>>> 2. Create special feature branch B.
>>>>>>>>>>>>>>>>>>>>>>>>>> 3. In branch B will be merged IGNITE-11927
>>>>>>>>>>>>>>>>>>>>>>>>>> 4. Because IGNITE-11927 doesn't solve all problems
>>>>> we should
>>>>>>>>>>>>>>>>>>>>> propose
>>>>>>>>>>>>>>>>>>>>>>>>>> solution and implement it in branch B.
>>>>>>>>>>>>>>>>>>>>>>>>>> 5. Testing, usability testing, fixing, etc
>>>>> iteratively.
>>>>>>>>>>>>>>>>>>>>>>>>>> 6. Merge it to master and in new release branch if
>>>>> needed.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Independent step. There are some problem which
>>>>> should be fixed
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> 2.8
>>>>>>>>>>>>>>>>>>>>>>>>>> before release otherwise we introduce problems with
>>>>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>>>>>>>>>>>>>> which will haunt us till next major release. I'll
>>>>> create
>>>>>>>>>>>>>>>> tickets.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 7:03 PM Andrey Gura <
>>>>> [hidden email]>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires
>>>>> rewrite client
>>>>>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove
>>>>> in the next
>>>>>>>>>>>>>>>>>> major
>>>>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> We don't know anything about development processes
>>>>> our users. I
>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>>>>>>>> admit that process could require that deprecated
>>>>> methods/APIs
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>>> allowed for example.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange
>>>>> interface which
>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>>>> give
>>>>>>>>>>>>>>>>>>>>>>> me any information about it’s purpose and
>>>>> responsibilities.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1]
>>>>> more clear:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I understand this. But I'm not Ignite user, I'm
>>>>> Ignite
>>>>>>>>>>>>>>>> developer.
>>>>>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>>>>>>>>> key moment in my message *from user stand point*.
>>>>> From my point
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>>>>> view it is very not intuitive solution and this
>>>>> interface is
>>>>>>>>>>>>>>>>>>>>>>>>>>> redundant.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
>>>>> caches for
>>>>>>>>>>>>>>>> example.
>>>>>>>>>>>>>>>>>>>>>>> There are other entities with such flag.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> They still works as expected.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. I fixed many such issues during
>>>>> IGNITE-11927
>>>>>>>>>>>>>>>>>>>>>>> implementation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Because of the scope.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the
>>>>> matter of the
>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I talk not about ability. I talk about ignored
>>>>> existing
>>>>>>>>>>>>>>>>>>>>>> functionality.
>>>>>>>>>>>>>>>>>>>>>>>>>>> So scope is not case here.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by
>>>>> MetricExporterSpi
>>>>>>>>>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter
>>>>> to decide.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while
>>>>> OpenCensus
>>>>>>>>>>>>>>>> exporter
>>>>>>>>>>>>>>>>>>>>>>> can’t.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually list is not metric at all as I already
>>>>> told.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 5:26 PM Николай Ижиков <
>>>>>>>>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Because it is brand new API and it requires
>>>>> rewrite client
>>>>>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> We doesn’t break backward compatibility.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The message is - this interface would be remove
>>>>> in the next
>>>>>>>>>>>>>>>>>> major
>>>>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Form user stand point it is very strange
>>>>> interface which
>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>>>> give
>>>>>>>>>>>>>>>>>>>>>>> me any information about it’s purpose and
>>>>> responsibilities.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Seems, I should explain proposed changes [1] more
>>>>> clear:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Each SPI would have a `ReadOnlyMetricManager`
>>>>> which provides
>>>>>>>>>>>>>>>>>>>>> access
>>>>>>>>>>>>>>>>>>>>>>> to collection of `ReadOnlyMetricRegistry`
>>>>>>>>>>>>>>>>>>>>>>>>>>>> which has a collection of `Metric`.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> So we reflects two-level structure we have in the
>>>>> internal API
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> GridMetricManager -> Collection[MetricRegistry] ->
>>>>>>>>>>>>>>>>>>>>>> Collection[Metric]
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricManager ->
>>>>> Collection[ReadOnlyMetricRegistry] ->
>>>>>>>>>>>>>>>>>>>>>>> Collection[Metric]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
>>>>> caches for
>>>>>>>>>>>>>>>> example.
>>>>>>>>>>>>>>>>>>>>>>> There are other entities with such flag.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> They still works as expected.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Because of the scope.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The ability to disable/enable metrics is the
>>>>> matter of the
>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But they should not be exported by
>>>>> MetricExporterSpi
>>>>>>>>>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually, it’s a responsibility of the exporter
>>>>> to decide.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> JMX exporter can exports ObjectMetric while
>>>>> OpenCensus
>>>>>>>>>>>>>>>> exporter
>>>>>>>>>>>>>>>>>>>>>>> can’t.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>> https://github.com/apache/ignite/pull/7269/files#diff-0ae5657231fc4c1f650493b02190b81bR25
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 16:57, Andrey Gura <
>>>>> [hidden email]>
>>>>>>>>>>>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of
>>>>> the active
>>>>>>>>>>>>>>>>>>>>>> reviewers
>>>>>>>>>>>>>>>>>>>>>>> of the Metric API.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes. But if I'm not missing some thing you were
>>>>> major
>>>>>>>>>>>>>>>> developer
>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Metric API :) Shit happens. And it happened.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
>>>>> deprecation of APIs
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
>>>>> substitution.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is such concept - backward compatibility.
>>>>> I understand
>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deprecation of some interface doesn't break
>>>>> backward
>>>>>>>>>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it leads to question^ what should I use instead
>>>>> of this. And
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi is not answer for this
>>>>> question. Because it
>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>> brand
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> new API and it requires rewrite client code.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal
>>>>> MetricRegistry  to
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> exporters.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No it is not. It's completely artificial thing
>>>>> which allow
>>>>>>>>>>>>>>>>>>>>> iterate
>>>>>>>>>>>>>>>>>>>>>>> via
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> all metric registries. GridMetricManager
>>>>> implements this
>>>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> while it is not metric registry. Form user stand
>>>>> point it is
>>>>>>>>>>>>>>>>>>>>> very
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strange interface which don't give me any
>>>>> information about
>>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> purpose and responsibilities.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually not. We have statisticsEnabled for
>>>>> caches for
>>>>>>>>>>>>>>>> example.
>>>>>>>>>>>>>>>>>>>>>>> There
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are other entities with such flag.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why do you decided do in such way? Why you
>>>>> ignore existing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> functionality? It affects user expectations and
>>>>> experience.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes? I'm working. Unfortunately we are not
>>>>> synchronized in
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> context and I should redo all metrics related
>>>>> changes in
>>>>>>>>>>>>>>>> order
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merge it with my changes. Anyway, my change
>>>>> doesn't solve all
>>>>>>>>>>>>>>>>>>>>>>> problems
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (e.g. it doesn't introduce IgniteMonitoring
>>>>> facade).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unfortunately it will be just fix. In my
>>>>> solution it is
>>>>>>>>>>>>>>>>>>>>> redesign.
>>>>>>>>>>>>>>>>>>>>>>> Stop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fixing issues, let's do things. It requires
>>>>> deeper changes.
>>>>>>>>>>>>>>>> My
>>>>>>>>>>>>>>>>>>>>>>> changes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> blocks AI 2.8 release because it big enough. So
>>>>> it retargeted
>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> next release. And it is one more reason for
>>>>> moving the
>>>>>>>>>>>>>>>> changes
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> internal packages. And it isn't good news for me
>>>>> because I
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>> go
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> throughout pan and tiers of merge. But it is
>>>>> right.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
>>>>> compatibility.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
>>>>> compatibility.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, I know. But they should not be exported by
>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 3:37 PM Николай Ижиков <
>>>>>>>>>>>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey, thanks for your opinion and your ownest
>>>>> critisism.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I can’t wait for your contribution.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If I’m not missing something, you were one of
>>>>> the active
>>>>>>>>>>>>>>>>>>>>>> reviewers
>>>>>>>>>>>>>>>>>>>>>>> of the Metric API.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
>>>>> deprecation of APIs
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
>>>>> substitution.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It has - MetricExporterSPI.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't
>>>>> recommend
>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still
>>>>> not-production ready.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It’s ready.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the
>>>>> public API
>>>>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>>>>>>>> solve the problem because this interface exposes
>>>>> internal Metric
>>>>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>>> implementations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Not, its’ not.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please, see
>>>>> `org.apache.ignite.spi.metric.LongMetric` and
>>>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>>>>> public interface.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> API of MetricRegistry is inconsistent.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MetricRegistry is the internal API.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Feel free to create ticket for an issues with
>>>>> it and I will
>>>>>>>>>>>>>>>>>> try
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> fix it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ReadOnlyMetricRegistry interface is redundant.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It’s an interface that exposes internal
>>>>> MetricRegistry  to
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> exporters.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Exporters expose metrics if they are disabled.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We don’t have an ability to disable metrics.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And that done, intentionally.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You are working on this issue, aren’t you?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I can fix this issue, by myself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> They are created to deal with backward
>>>>> compatibility.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 15:09, Andrey Gura <
>>>>> [hidden email]>
>>>>>>>>>>>>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The first, I agree with Alexey about
>>>>> deprecation of APIs
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> still supported and don't offer reasonable
>>>>> substitution.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The second, from my point of view, we can't
>>>>> recommend
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi's because it are still
>>>>> not-production
>>>>>>>>>>>>>>>>>> ready.
>>>>>>>>>>>>>>>>>>>>>>> There
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are some issues with it and usage of
>>>>> ReadOnlyMetricRegistry
>>>>>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> just one of them.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The third, moving of MetricRegistry to the
>>>>> public API
>>>>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>>>>>>>> solve
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the problem because this interface exposes
>>>>> internal Metric
>>>>>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementations. So your PR is incomplete.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Moreover, API of MetricRegistry is
>>>>> inconsistent. E.g.
>>>>>>>>>>>>>>>>>>>>>>> register(name,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> supplier, desc) method returns registered
>>>>> metric for some
>>>>>>>>>>>>>>>>>>>>> types
>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> doesn't for other. register(metric) method is
>>>>> inconsistent
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>> sense of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> metric naming. ReadOnlyMetricRegistry
>>>>> interface is
>>>>>>>>>>>>>>>> redundant.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MetricExporterSpi should be revised because it
>>>>> absolutely
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> intuitive because it requires
>>>>> ReadOnlyMetricRegistry and
>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>>>> purpose
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is undefined.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> One more point. IEP-35 is still not fully
>>>>> implemented. Some
>>>>>>>>>>>>>>>>>>>>>>> things are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not taken into account. Exporters expose
>>>>> metrics if they
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>> disabled.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JMX beans exposes values that don't confirm to
>>>>> best
>>>>>>>>>>>>>>>> practices
>>>>>>>>>>>>>>>>>>>>>> [1].
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Metrics of type lists are not metric at all.
>>>>> Ubiquitous
>>>>>>>>>>>>>>>>>> merics
>>>>>>>>>>>>>>>>>>>>>>> lookup
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from hash map instead of usage reference for
>>>>> getting
>>>>>>>>>>>>>>>> metrics
>>>>>>>>>>>>>>>>>>>>>>> values
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (it is just performance issue). Also
>>>>> IGNITE-11927 is not
>>>>>>>>>>>>>>>>>>>>>>> implemented
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which also changes interfaces significantly.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Let's just admit that the implementation is
>>>>> immature and
>>>>>>>>>>>>>>>> must
>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>> moved
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to the internal packages.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And because we already merged partially
>>>>> implemented IEP to
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> master
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> branch we *must move all currently public APIs
>>>>> to the
>>>>>>>>>>>>>>>>>> internal
>>>>>>>>>>>>>>>>>>>>>>> API*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> while it will not be ready for publication.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And the last but not least. What is happening
>>>>> indicates a
>>>>>>>>>>>>>>>>>>>>>> immature
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> development process which must be revised. I
>>>>> don't want
>>>>>>>>>>>>>>>>>>>>> discuss
>>>>>>>>>>>>>>>>>>>>>>> it in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this thread but we must not allow merge of
>>>>> change to the
>>>>>>>>>>>>>>>>>>>>> master
>>>>>>>>>>>>>>>>>>>>>>> branch
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> before it will completed, that is we must use
>>>>> feature
>>>>>>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> full IEP not only for particular tickets. And
>>>>> also we
>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reformulate IEP process in order to avoid
>>>>> things like this.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>> https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 17, 2020 at 12:49 PM Николай
>>>>> Ижиков <
>>>>>>>>>>>>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alex.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK, I may leverage your experience and create
>>>>> pure Java
>>>>>>>>>>>>>>>> API.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ticket [1] created.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But, personally, I don’t agree with you.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ignite has dozens of the API that
>>>>> theoretically have a
>>>>>>>>>>>>>>>> usage
>>>>>>>>>>>>>>>>>>>>>>> scenario, but in real-world have 0 custom
>>>>> implementation and
>>>>>>>>>>>>>>>> usages.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Moreover, many APIs that were created with
>>>>> the intentions
>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>>> mentioned is abandoned now and confuses users.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can just see count of the tests we just
>>>>> mute on the
>>>>>>>>>>>>>>>> TC.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Can you, please, take a look at the fix
>>>>> regarding puck API
>>>>>>>>>>>>>>>>>>>>>> issue
>>>>>>>>>>>>>>>>>>>>>>> you mentioned in your first letter [2], [3]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>> https://issues.apache.org/jira/browse/IGNITE-12553
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [2]
>>>>> https://github.com/apache/ignite/pull/7269
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [3]
>>>>> https://issues.apache.org/jira/browse/IGNITE-12552
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 17 янв. 2020 г., в 12:12, Alexey Goncharuk <
>>>>>>>>>>>>>>>>>>>>>>> [hidden email]> написал(а):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nikolay,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why do you think this is a wrong usage
>>>>> pattern? From the
>>>>>>>>>>>>>>>>>> top
>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>> my head,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here is a few cases of direct metric API
>>>>> usage that I
>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> being used in production:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom task execution scheduling service
>>>>> with load
>>>>>>>>>>>>>>>>>>>>>>> balancing based on
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> utilization metrics readings from Java code
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * Cleanup task trigger based on metrics
>>>>> readings
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * A custom health-check endpoint for an
>>>>> application with
>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>> embedded
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ignite node for Kubernetes/Spring
>>>>> Application/etc
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>

[Alexey Goncharuk]

Folks,

I tried to re-read the whole thread and honestly got lost at the end :) Do
we have a consensus (if yes, what are the steps?) or should we have a call
as Maxim suggested?

I think it is in our best interest to get this agreed upon fast to release
AI 2.8 soon.

[agura]

From my point of view we still don't have consensus.

I think we should do at least the following:

1. Remove @Deprecated from old API (because it strange to have one
deprecated API and second experimental API)
2. Add @IgniteExperimetnal to new API (because... see item. 1)
3. Do not merge IGNITE-12553 (because it adds new public interface
that 100% will be changed)

ideally we should also:

4. Add metrics that available only via new API to the old API (because
otherwise we force user interact with both API's)

On Thu, Jan 30, 2020 at 12:35 PM Alexey Goncharuk
<[hidden email]> wrote:
>
> Folks,
>
> I tried to re-read the whole thread and honestly got lost at the end :) Do
> we have a consensus (if yes, what are the steps?) or should we have a call
> as Maxim suggested?
>
> I think it is in our best interest to get this agreed upon fast to release
> AI 2.8 soon.

[Nikolay Izhikov-2]

Hello.

> 2. Add @IgniteExperimetnal to new API (because... see item. 1

+1

> 1. Remove @Deprecated from old API (because it strange to have one deprecated API and second experimental API)

-1

I propose to update deprecation message and provide metric name for each deprecated method.

> @deprecated Use {@link JmxMetricExporterSPI} instead. Name of the metric «io.dataregion.pageCount»

Andrey.

We doesn’t come to an agreement that API should be changed.
We should discuss the design of the Metric API and your proposals for it in another thread.

Please, avoid arguments like «this API will be 100% changed» in this discussion.

> 30 янв. 2020 г., в 14:21, Andrey Gura <[hidden email]> написал(а):
>
> From my point of view we still don't have consensus.
>
> I think we should do at least the following:
>
> 1. Remove @Deprecated from old API (because it strange to have one
> deprecated API and second experimental API)
> 2. Add @IgniteExperimetnal to new API (because... see item. 1)
> 3. Do not merge IGNITE-12553 (because it adds new public interface
> that 100% will be changed)
>
> ideally we should also:
>
> 4. Add metrics that available only via new API to the old API (because
> otherwise we force user interact with both API's)
>
> On Thu, Jan 30, 2020 at 12:35 PM Alexey Goncharuk
> <[hidden email]> wrote:
>>
>> Folks,
>>
>> I tried to re-read the whole thread and honestly got lost at the end :) Do
>> we have a consensus (if yes, what are the steps?) or should we have a call
>> as Maxim suggested?
>>
>> I think it is in our best interest to get this agreed upon fast to release
>> AI 2.8 soon.

[Maxim Muzafarov]

Igniters,


How about to start a vote (formal) over the whole community to choose
between these two options we have? With one caveat that veto votes are not
applicable to this discussion. Let the whole community decide what
direction we should move on.

On Thu, 30 Jan 2020 at 14:34, Nikolay Izhikov <[hidden email]> wrote:

> Hello.
>
> > 2. Add @IgniteExperimetnal to new API (because... see item. 1
>
> +1
>
> > 1. Remove @Deprecated from old API (because it strange to have one
> deprecated API and second experimental API)
>
> -1
>
> I propose to update deprecation message and provide metric name for each
> deprecated method.
>
> > @deprecated Use {@link JmxMetricExporterSPI} instead. Name of the metric
> «io.dataregion.pageCount»
>
> Andrey.
>
> We doesn’t come to an agreement that API should be changed.
> We should discuss the design of the Metric API and your proposals for it
> in another thread.
>
> Please, avoid arguments like «this API will be 100% changed» in this
> discussion.
>
> > 30 янв. 2020 г., в 14:21, Andrey Gura <[hidden email]> написал(а):
> >
> > From my point of view we still don't have consensus.
> >
> > I think we should do at least the following:
> >
> > 1. Remove @Deprecated from old API (because it strange to have one
> > deprecated API and second experimental API)
> > 2. Add @IgniteExperimetnal to new API (because... see item. 1)
> > 3. Do not merge IGNITE-12553 (because it adds new public interface
> > that 100% will be changed)
> >
> > ideally we should also:
> >
> > 4. Add metrics that available only via new API to the old API (because
> > otherwise we force user interact with both API's)
> >
> > On Thu, Jan 30, 2020 at 12:35 PM Alexey Goncharuk
> > <[hidden email]> wrote:
> >>
> >> Folks,
> >>
> >> I tried to re-read the whole thread and honestly got lost at the end :)
> Do
> >> we have a consensus (if yes, what are the steps?) or should we have a
> call
> >> as Maxim suggested?
> >>
> >> I think it is in our best interest to get this agreed upon fast to
> release
> >> AI 2.8 soon.
>
>

[Anton Vinogradov-2]

>> . Remove @Deprecated from old API (because it strange to have one
>> deprecated API and second experimental API)
>> 2. Add @IgniteExperimetnal to new API (because... see item. 1)
-1

We should have all the options.

Deprecated -> will be removed at major release (because this way is slow or
overcomplicated) but still be used now,
Annotation is absent -> just a stable (proper) API,
Experimental -> not stable yet or partially implemented or in fact an
experimental

On Thu, Jan 30, 2020 at 2:47 PM Maxim Muzafarov <[hidden email]> wrote:

> Igniters,
>
>
> How about to start a vote (formal) over the whole community to choose
> between these two options we have? With one caveat that veto votes are not
> applicable to this discussion. Let the whole community decide what
> direction we should move on.
>
> On Thu, 30 Jan 2020 at 14:34, Nikolay Izhikov <[hidden email]> wrote:
>
> > Hello.
> >
> > > 2. Add @IgniteExperimetnal to new API (because... see item. 1
> >
> > +1
> >
> > > 1. Remove @Deprecated from old API (because it strange to have one
> > deprecated API and second experimental API)
> >
> > -1
> >
> > I propose to update deprecation message and provide metric name for each
> > deprecated method.
> >
> > > @deprecated Use {@link JmxMetricExporterSPI} instead. Name of the
> metric
> > «io.dataregion.pageCount»
> >
> > Andrey.
> >
> > We doesn’t come to an agreement that API should be changed.
> > We should discuss the design of the Metric API and your proposals for it
> > in another thread.
> >
> > Please, avoid arguments like «this API will be 100% changed» in this
> > discussion.
> >
> > > 30 янв. 2020 г., в 14:21, Andrey Gura <[hidden email]> написал(а):
> > >
> > > From my point of view we still don't have consensus.
> > >
> > > I think we should do at least the following:
> > >
> > > 1. Remove @Deprecated from old API (because it strange to have one
> > > deprecated API and second experimental API)
> > > 2. Add @IgniteExperimetnal to new API (because... see item. 1)
> > > 3. Do not merge IGNITE-12553 (because it adds new public interface
> > > that 100% will be changed)
> > >
> > > ideally we should also:
> > >
> > > 4. Add metrics that available only via new API to the old API (because
> > > otherwise we force user interact with both API's)
> > >
> > > On Thu, Jan 30, 2020 at 12:35 PM Alexey Goncharuk
> > > <[hidden email]> wrote:
> > >>
> > >> Folks,
> > >>
> > >> I tried to re-read the whole thread and honestly got lost at the end
> :)
> > Do
> > >> we have a consensus (if yes, what are the steps?) or should we have a
> > call
> > >> as Maxim suggested?
> > >>
> > >> I think it is in our best interest to get this agreed upon fast to
> > release
> > >> AI 2.8 soon.
> >
> >
>

[Alexey Goncharuk]

чт, 30 янв. 2020 г. в 15:18, Anton Vinogradov <[hidden email]>:

> We should have all the options.
>
> Deprecated -> will be removed at major release (because this way is slow or
> overcomplicated) but still be used now,
>

Not only does it mean that the API should be removed in a major release,
but there is a stable counterpart that can be used instead.


> Annotation is absent -> just a stable (proper) API,
> Experimental -> not stable yet or partially implemented or in fact an
> experimental
>

Looks like the formal vote is the only way to go now.