Github user dayzzz commented on the pull request:
https://github.com/apache/helix/pull/6#issuecomment-57728028
* About the interface change, IMHO, this is a nature part of the task
interface. If the existing customers want to update, adding the support is
encouraged. We can have another interface for monitoring the progress, but
doesn't seem to be a nice design.
* The task framework should call the progress interface and expose the
status somehow, discussed below.
* Persistency story, ZK is a good place if we only want to record the final
result. If we want to expose the progress as a task runs, putting these
periodical status updates in ZK is not a choice due to the large traffic,
generally ZK is not a good place for reporting and monitoring service status. I
also discussed this with Jason, we thought about inGraph (which is not an
option for open source), Kafka or Riemann. (Greg, JMX sounds a good idea.)
Without a conclusion of where to put these status stats, I agree that the
progress interface is not of much value. For the first step, it would be good
enough if we can monitor the progress. What do you guys think?
* For the bogus progress number, it's the customer themselves who need to
track the progress, if they want to see the bogus value, I'm fine with that :).
The controller should be set not to act on the bogus value by the customers.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
