[QFJ-302] Changing SocketConnectPort or SocketConnectHost does not create new set of FileStorePath temp files Created: 13/Mar/08 Updated: 15/Nov/12 Resolved: 25/Mar/08 |
|
Status: | Closed |
Project: | QuickFIX/J |
Component/s: | Engine |
Affects Version/s: | 1.3.1 |
Fix Version/s: | None |
Type: | Bug | Priority: | Default |
Reporter: | Emil Crumhorn | Assignee: | Unassigned |
Resolution: | Not a bug | Votes: | 0 |
Labels: | None | ||
Environment: |
Windows XP, Eclipse RCP application |
Description |
We have two FIX servers living on the same remote machine (however, this test will work if you have two different machines on different IP's as well). One is on listening port 8811, the other is on 8911. Assuming I have no files in my FileStorePath and I connect with our client to 8811 and do things everything is fine and works as it should. After a while, I decide that now I want to connect to 8911 to test that machine, so I change my quickfix configuration file and update the port number to reflect this and then I restart the client and connect. However, when I then try to log on to the server I now get the following error and the server disconnects me: MsgSeqNum too low, expecting 173 but received 32 Basically, the "temp" files do not reflect either the server or the port in them, so as it's the same files being used but now a completely different connection, it becomes rather confused and I can no longer connect until I remove the files in the FileStorePath directory and connect again. The files seem to have the following format: FIX.4.4-XXXX-YYYY.session where the first part is obviously the FIX version, the second is the SenderCompID and the other the TargetCompID.. It seems this problem could easily be fixed by including the host and port in the naming of those files as well. |
Comments |
Comment by Steve Bate [ 25/Mar/08 ] |
This is expected behavior. The sequence numbers are associated with a session ID, not a specific host or port. This is consistent with the logical notion of a FIX session as defined in the spec. The physical connection might change (e.g., during failover) but the session state continues. The failover mechanism must ensure that the session sequence numbers continue as expected when failing over to the new host. |