Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Default
-
Resolution: Duplicate
-
Affects Version/s: 1.4.0
-
Fix Version/s: 1.5.0
-
Component/s: None
-
Labels:None
-
Environment:Windows XP sp3, Java 6
Description
If I create a ThreadedSocketInitiator with a FileStoreFactory, start, stop and re-start it, I get the following in stderr:
File delete failed: ...\FIX.4.2-xxx.header
File delete failed: ...\FIX.4.2-xxx.body
File delete failed: ...\FIX.4.2-xxx.seqnums
This seems to be because ThreadedSocketInitiator gets a new FileStore from FileStoreFactory which then locks files (for example - initializeMessageIndex opens a FileOutputStream for the header file).
When I stop the initiator this FileStore is never closed - the FileStore doesn't actually have any kind of close or dispose method.
When I restart the initiator it gets a new FileStore which barfs with the above errors when it can't delete the files.
I'm happy to work up a patch for this but would appreciate some guidance as to what the commiters think should close the FileStore.
Attachments
Issue Links
- duplicates
-
-
- Closed
-
Activity
One approach is to create an interface for objects to listen to Connector start/stop events. The Connector implementations could automatically register stores or logs as listeners if they implement that interface.
Hi Steve,
unfortunately the Connector does have access to, for example, message stores. It passes a MessageStoreFactory to the Session which creates a MessageStore when invoking the SessionState constructor, which keeps a handle to the message store.
The way I've implemented this initially is to add a close method to Session, SessionState, and MessageStore (and impls.) and modified SessionConnector.logoutAllSessions to call Session.close, which calls SessionState.close which calls MessageStore.close. I could add a close method to Log and all impls. too and call this in the same place? (as I use SLF4JLog I haven't noticed any issues with logs remaining open).
This solution solves my problem but I'm happy for suggestions or changes to the code to be made.
Cheers, Jerry
Guys, is there any chance we could get this change assigned to 1.4.1 release? Let me know if there's anything else I can do to help this along
This will be worked under the original QFJ-224 issue.
In reply to
QFJ-406:> I'm happy to work up a patch for this but would appreciate some guidance as to
> what the commiters think should close the FileStore.
Would be great if you could suggest patches. Looking at the FileStore, there are already internal methods to close the files.
But these methods are called on initialize, since there is no MessageStore API method to close it.
Could you also suggest how to extend the MessageStore API to provide a close() method and more important where in the QF/J code you would call this method?
Thanks, Jörg