Nikolay, thanks! I am not insisting we must implement IGNITE-12553 right away nor am I saying it's mandatory. I just want to make sure we do not deprecate existing APIs unless we as a community are certain that they will be dropped and there is no need for the replacement.
Will take a look at the PR shortly. пт, 17 янв. 2020 г. в 12:49, Николай Ижиков <nizhi...@apache.org>: > 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 > >