Function ReplayMerge#pollForResponse is called whenever the ReplayMerge awaits a control response from the archive, namely when it tries to start the replay or when it requests the current recording position. It returns true if a response to the currently active request has been received, false otherwise.

To do so, it polls the archive.controlResponsePoller() and, once that has received a full control response, checks the correlationId of that response. If the correlationId is not the expected activeCorrelationId, it simply moves on and returns false.

This prevents using several ReplayMerges in an interleaved fashion in a single duty cycle, because control responses intended for one ReplayMerge might be discarded by another when it calls pollForResponse. As a consequence, only one of the ReplayMerges will ever finish the ReplayMerges often will never finish. Please do tell me if I've misunderstood anything so far.

It seems to me that this very issue is why the more "naïve" parts of the AeronArchive's interface use a global lock, making the operations slower because synchronous but correct. For a ReplayMerge which could be a long operation however that is not possible.

I have circumvented this issue of stolen control responses by modifying ReplayMerge to instead use a ControlResponseDispatcher that I wrote that stores Runnable callbacks associated to correlation IDs, wraps the original ControlResponsePoller and calls the appropriate callback (if any) when a control response is received. However I think this mechanism should be natively integrated to the ControlResponsePoller. Eager to read your thoughts on this.