Hi Alex, Thank you for the prompt feedback. Yes, I am actively tracking the progress on FINERACT-2169. My proposal was specifically aimed at exploring the implementation details for the third performance tier you outlined: the optional "non-blocking: high performance LMAX Disruptor" implementation.
Regarding your critical questions on backward compatibility and migration, my intent is absolutely not to break current contracts. I view this integration strictly through the lens of the "drop-in replacement" requirement defined in 2169. Here is my initial thinking on tackling those challenges: 1. Backward Compatibility: The LMAX Ring Buffer must be entirely encapsulated within the new CommandProcessingService boundary. The abstract Command class and the newly defined DTO payloads (being migrated under 2169) would serve as the events placed onto the Ring Buffer. The legacy SynchronousCommandProcessingService remains untouched and handles any modules not yet migrated to the new infrastructure. 2. Migration Strategy (Opt-in Routing): We cannot flip a global switch. Migration must happen command handler by command handler. The router would need configuration (via application.properties or database flags) to determine which handlers are safe to execute via the Disruptor path versus the synchronous path. 3. The Thread Local Risk: The biggest hurdle I see in migrating existing handlers to a lock-free/Disruptor model is hidden assumptions about ThreadLocals (e.g., security contexts or tenant context) and database transaction boundaries (which are typically thread-bound in Spring). Handlers executed by the Disruptor's worker pool must have these contexts explicitly passed as part of the event payload rather than relying on thread confinement. While I am very interested in the LMAX implementation, I also want to be fully transparent regarding my bandwidth. I recently submitted my GSoC 2026 proposal focused on FINERACT-2485 (Standardizing Transaction Idempotency), which is a critical piece of this same puzzle. I drafted the LMAX blueprint to map out the long-term concurrency model, but I recognize that the idempotency refactoring (2485) and the foundational DTO/routing work of 2169 must stabilize first. I’m happy to share my initial PoC notes on the Disruptor integration if it helps inform the 2169 roadmap, but my primary execution focus for the near term remains on hardening idempotency as proposed for GSoC. Regards, Mohammed Saifulhuq >
