... alright... then maybe let's circle back on this later. Before we do anything with LMAX Disruptor we should actually migrate as many modules/packages as possible to the new command processing. A first LMAX implementation is already available (but disabled). Once we have a significant amount of modules/packages migrated we can start drawing up a strategy on how to test any other execution mode for commands.
On Tue, Apr 14, 2026 at 5:42 PM Mohammed Saifulhuq < [email protected]> wrote: > 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 > >>
