Thanks Alexander +1
This is a case of cleaning up first and completing a refactoring fully before chasing a new improvement. Maintenance and maintainability are key values for projects that succeed over time. On Tue, Apr 14, 2026 at 10:25 AM Aleksandar Vidakovic < [email protected]> wrote: > ... 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 >> >>>
