Hi James, Aleks, I completely agree with both of you. Foundational stability and maintainability must always precede new execution engines.
I am archiving the LMAX exploration for now. My focus remains strictly locked on executing the $O(1)$ Idempotency Filter (FINERACT-2485) to ensure the core command pipeline is fully hardened first. Thanks for the guidance. Regards, Mohammed Saifulhuq On Wed, Apr 15, 2026 at 4:13 AM James Dailey <[email protected]> wrote: > 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 >>> >>>>
