Details
Description
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:
{code}
ConnectionType=acceptor
FileStorePath=output/data/server
HeartBtInt=30
StartTime=00:00:00
EndTime=00:00:00
ReconnectInterval=15
ResetOnLogout=Y
ResetOnDisconnect=Y
SendResetSeqNumFlag=Y
SocketAcceptPort=7001
UseDynamicSessions=Y
{code}
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.
{code}
MessageFactory messageFactory = new DefaultMessageFactory();
MessageStoreFactory messageStoreFactory = new MemoryStoreFactory();
Application application = new MyApplication();
SessionSettings settings = getSettings();
LogFactory logFactory = new ScreenLogFactory();
SessionFactory sessionFactory = new MySessionFactory(settings, application, messageStoreFactory, messageFactory);
SocketAcceptor acceptor = new SocketAcceptor(sessionFactory, settings);
acceptor.start();
{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.
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:
{code}
ConnectionType=acceptor
FileStorePath=output/data/server
HeartBtInt=30
StartTime=00:00:00
EndTime=00:00:00
ReconnectInterval=15
ResetOnLogout=Y
ResetOnDisconnect=Y
SendResetSeqNumFlag=Y
SocketAcceptPort=7001
UseDynamicSessions=Y
{code}
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.
{code}
MessageFactory messageFactory = new DefaultMessageFactory();
MessageStoreFactory messageStoreFactory = new MemoryStoreFactory();
Application application = new MyApplication();
SessionSettings settings = getSettings();
LogFactory logFactory = new ScreenLogFactory();
SessionFactory sessionFactory = new MySessionFactory(settings, application, messageStoreFactory, messageFactory);
SocketAcceptor acceptor = new SocketAcceptor(sessionFactory, settings);
acceptor.start();
{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.
125 was actually never implemented