kfaraz commented on PR #16691: URL: https://github.com/apache/druid/pull/16691#issuecomment-2223408463
> Does this mean that the simpler logic now only accounts for the default case of a single loading thread (druid.segmentCache.numLoadingThreads)? Yes, @abhishekrb19 . > Instead of including potentially incorrect values, I think we can skip reporting the metric and including expectedLoadTimeMillis in the API for the multiple threads case until we have proper support for it. Currently, there is no way for the coordinator to know the number of loading threads being used by a historical. Also, I think it is fine to report somewhat incorrect values as this is an experimental feature now anyway. It would be interesting to see how off the values turn out to be when using multiple loading threads. Moreover, we would be over-estimating the expected time, never under-estimating it. It's always a good feeling when downloads take less time than originally expected! 😛 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
