Okada Haruki

This PR is supposed to introduce no any new lock contention, because (potentially blocking) lazy timeIndex materialization has already exclusive control by lock in LazyIndex#get

Hi, the change looks make sense. For `ConcurrentOpenHashSet`, how about replacing type declarations with `Set` and use `ConcurrentHashMap.newKeySet()` ? To express the `Set` type, it's more straightforward than `ConcurrentHashMap` and...

Sorry for the delay of the reaction. The motivation makes sense. Why we don't expose partition directly is because we want to make Decaton agnostic to Kafka as much as...

Thank you for the feedback. > the likelihood of developers overlooking completion leaks also rises 100% agree, and that's the exact reason we introduced deferred-completion timeout (https://github.com/line/decaton/issues/96#issuecomment-792505107, https://github.com/line/decaton/pull/99). > Eventually,...

Thank you for reporting. Nice catching. Definitely this is unintentional. As you suggested, measuring the duration in ProcessorUnit might be good, however we don't want to expose metric on VirtualThreadSubPartitions...