> Let’s move from the long letters to the code. Let's thinking before coding. Development is not only coding. Why such a rush? Measure thrice and cut once.
"Long letters" is way of discussion before writing code. And it's ok. On Mon, Jan 20, 2020 at 1:32 PM Николай Ижиков <nizhi...@apache.org> wrote: > > 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 <ag...@apache.org> написал(а): > > > > It solves problem. > > > > On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk > > <alexey.goncha...@gmail.com> 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 <nizhi...@apache.org>: > >> > >>> +1 to mark feature or whole release as EA. > >>> > >>> пт, 17 янв. 2020 г., 23:00 Denis Magda <dma...@apache.org>: > >>> > >>>> 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 Николай Ижиков <nizhi...@apache.org> > >>>> 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 <ag...@apache.org> написал(а): > >>>>>> > >>>>>>>> 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 Николай Ижиков <nizhi...@apache.org> > >>>>> 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 <ag...@apache.org> > >>> написал(а): > >>>>>>>> > >>>>>>>> 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 <ag...@apache.org> > >>>> 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 Николай Ижиков < > >>> nizhi...@apache.org > >>>>> > >>>>> 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 <ag...@apache.org> > >>>>> написал(а): > >>>>>>>>>>> > >>>>>>>>>>>> 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 Николай Ижиков < > >>>> nizhi...@apache.org> > >>>>> 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 <ag...@apache.org> > >>>>> написал(а): > >>>>>>>>>>>>> > >>>>>>>>>>>>> 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 Николай Ижиков < > >>>>> nizhi...@apache.org> 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 < > >>>>> alexey.goncha...@gmail.com> написал(а): > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>> > >>> >
