Linux

The acceptor does no management of the message stores.

To implement this feature, we'd need to create some type of new or extended interface that some of the message stores could implement that would allow them to clean up their resources based on specific session events.

As a workaround, you could access the session's state in the Application onLogout callback, cast it to a FileStore and then call deleteFiles() on it.

The above workaround works for me, as long I have the following vars setup:
ResetOnLogin=Y
ResetOnDisconnect=N
ResetOnLogout=N

Since Session.disconnect() calls into application.onLogout() before it does the check/reinitalization on disconnect, i had to set ResetOnDisconnect=N.

My quickfix.Application.onLogout() code:
public void onLogout(SessionID sessionId) {
FileStore store = (FileStore) Session.lookupSession(sessionId).getStore();
try {
store.closeFiles();
store.deleteFiles();
if(LoggerAdapter.isDebugEnabled(this))

} catch (IOException e)

}

We have the listener interface to implement this feature now. I think it should be configurable (default to off) since the FileStore loads all sent messages when it initializes. This could cause a significant delay during counterparty login. However, closing the files and clearing the caches makes a lot of sense for other applications, like simulators.

The same applies to the quickfix.Log class but the workaround cannot be used since the close() method is protected.

Sorry, It is atually package scope.

Sorry fro the multiple comments in a row...

To be more precise, I don't talk specifically about deleting the files. This can be a nice developement feature but you definitely don't want that in a prod environment. What is most important is that the store AND the logger close their files if the initiatior or acceptor is stopped. This way, if a web application gracefully responds to a stop event from the container, it can stop all connections opened in quickfixj and expect the files to be unlocked.

And B.T.W. (sorry again) to close the files on logout is not enough because the session may not be logged on at all at the time the initiator or acceptor is closed. This should be done also or at least on close.

I split this into a separate issue for 1.3.1 to expose hooks for manually closing FileLog files. See the related issue.

Added support to Session for disposable message stores and logs. However, we need to think more about how to support these in the current file-based implementations. There are still potential issues with the FileStore if it's required to load it's caches on every session connect event. FileLogs might be a little easier to handle.

Modified the title to more accurately reflect the feature request. One approach for this is to check in the session connector (initiator or acceptor) whether the message log and/or store implements the java.io.Closeable interface. If so, the connector will call close on the log or store.

This issue has become confusing over the last four years. I'm think that we want to close the file-based resources when a connector is stopped. When a connector is stopped, the Sessions are unregistered. If we "close" the sessions at this point then we can release resources if the plugins (store, log) support it. Let me know if anyone else has a different interpretation.

If a MessageStore or Log implementation implements the java.io.Closeable interface then the Session will close them (the connector tells the session to close them after unregistering the session). The FileLog and FileStore have been modified to implement the Closeable interface.

Am I right thinking that (initiator means SocketInitiator in the following)

• an initiator creates the sessions in start() -> initialize() -> createSessionInitiators()
• if an initiator is stopped, then the sessions will be unregistered
• if an initialized initiator is started, then it only re-registers the sessions, and does not recreate them (see initialize())
• a Session closes it's Log if it's closeable (see Session -> unregisterSessions() -> close() -> closeIfCloseable(getLog())
• a FileLog only opens it's streams in clear() and in it's constructor

— therefore, if SocketInitiator using a FileLog is stopped, then next time it gets started it will throw exceptions as the underlying file handle is closed.

Opinions?

By the way, this is in 1.5.2.