I’ve been itching to mess around with fix engines again so I started to pry open Quickfix/J and see if I could implement using some updated tech. I quickly noticed the MessageStore implementation could possibly be backed by a distributed IMDG, so I broke out my favorite – Hazelcast.
This was quickly implemented on the bus ride home and could stand some additional features to endure load. The next step would be to back the caches with a more persistent, write-behind data store. This would allow data to move to a more persistent place but still keep the latest messages in cache for quick failover of fix sessions.
The only caveat to this code is that you must run in a cluster with at least 3 members, to allow for the CP Subsystem to initialize for supporting the distributed data structures such as AtomicLong.
It’s on the backlog to create a fully hazelcast backed cluster of fix engines, which can serve incoming fix connections much like a load balanced web server cluster could manage.
With the associated factory.
Would you use FileStore to persist the member state?
The FileStore is an implementation of MessageStore, using the filesystem to save the state. This is also an implementation of MessageStore, but uses an in-memory data grid to store state. Of course, with this implementation you’d need a cluster available.