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
>
>

Reply via email to