cryptoe opened a new pull request, #18300: URL: https://github.com/apache/druid/pull/18300
SegmentLoadDropHandler has a race that causes dropSegmentDelayMillis to not be respected. It happens in this sequence of events: - removeSegment is called, which adds the segment to segmentsToDelete and schedules a future drop. - addSegment is called, which removes the segment from segmentsToDelete and proceeds to load it. - removeSegment is called again, which adds the segment back to segmentsToDelete, before the originally-scheduled drop executes. - The originally-scheduled drop executes, sees the segment is in segmentsToDelete, and removes it. This could happen immediately after the second call to removeSegment, defeating dropSegmentDelayMillis. This can occur in practice when the coordinator period is less than the dropSegmentDelayMillis. By default, it's not (default is 1m Coordinator period and 30s dropSegmentDelayMillis). This patch addresses it by ensuring that delayed drops only happen if the entry in segmentDropLatches corresponds to the removeSegment call that scheduled the drop. (cherry picked from commit d5bdb7384af3bce609b98f5e0b70d9e041a250df) <!-- Thanks for trying to help us make Apache Druid be the best it can be! Please fill out as much of the following information as is possible (where relevant, and remove it when irrelevant) to help make the intention and scope of this PR clear in order to ease review. --> -- 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]
