As requested previously (http://www.quickfixj.org/jira/browse/QFJ-125), we have a few compelling use cases where we would like our QuickFIX/J-based server application to be able to update session descriptions on the fly.
I have attached patches to the current SVN HEAD (621), that provide the basic facilities for dynamic session definition in QuickFIX.
- Replaced the singleton "sessions" map in Session.java with an instance of the new interface ISessionDB
- Created two implementations of ISessionDB, StaticSessionDB (which provides the same semantics as the original map singleton) and CachingSessionDB which creates a local cache of any session created by a SessionFactory (not sure how useful this is, but it is useful during prototyping and testing)
- Added a "UseDynamicSessions" boolean configuration variable that can be used in the global scope of the configuration file.
- Added a "useDynamicSessions" boolean constructor argument to AbstractSocketAcceptor and AbstractIoHandler to correspond to the configuration variable
- AbstractSocketAcceptor now creates one socket descriptor for 0.0.0.0/0.0.0.0:<port> if there otherwise are none, and UseDynamicSessions is "Y", this makes it possible to have a configuration file with no explicit session sections, only a defaults.
- If the AcceptorIOHandler does not have a Session in it's local map, it now calls Session.lookupSession() to find it, if useDynamicSessions is true
And some potentially controversial changes:
- Made the constructors of the Session object public, so that I could provide my own subclass of SessionFactory in my own package.
- Made the class and constructor of SessionSchedule public, so that I could provide my own subclass of SessionFactory in my own package.
- Made the DEFAULT_SESSION_ID in SessionSettings.java public, so that I could reuse some code in AbstractSocketAcceptor (see the diffs for AbstractSocketAcceptor.java)
With all of these changes, it is now possible to start up a QuickFIX/J socket acceptor with a .properties file with only a global section, like this:
In order to make real use of it, you will need to implement your own SessionFactory: in the example below it is called MySessionFactory. I have an implementation of a SessionFactory that accepts all incoming session requests, I don't think it's useful in production, but we could maybe add it to the test code.
Ultimately it would be nice to have a couple of standard implementations of SessionFactory that read session configuration data out of a DB, or an LDAP server.