We have a rich java frontend application talking fix to our OMS, both are
using Quickfix/J. Under heavy performance testing of our system we
experience the following behavior
Our client seem to get disconnected because of heartbeat notifications
messages not getting sent to our fix gateway in the interval we have
specified (30secs). I'm guessing heartbeat notification isn't being sent
while our client is being bombarded with updates ie. orders comming into our
limit book.
We have implemented a lot of logic in the onLogout function and It seems
onLogout() is never called so our client tries to relogin with the same
session and does a full resend request of all messages.
The way our ATS work is to always hand out a new dynamic FIX session to
clients who connect and disconnect. It seems when the client lags for what
ever reason and our fix gateway does not recieve a heart beat onLogout isnt
getting called however FIX is dropping our client and our client tries to
reconnect with the same session.
Can anyone confrim this behavoir and know of a possible work around?
20080806-00:48:43: Session
FIX.4.4:FRZ->CLI/test1_1454906197547361963schedule is daily, 00:00:00
UTC - 23:59:59 UTC (daily, 00:00:00 UTC -
23:59:59 UTC)
20080806-00:48:43: Created session:
FIX.4.4:FRZ->CLI/test1_1454906197547361963
20080806-00:48:43: Accepting session
FIX.4.4:FRZ->CLI/test1_1454906197547361963 from /192.168.149.71:3256
20080806-00:48:43: Acceptor heartbeat set to 45 seconds
20080806-00:48:43: Logon contains ResetSeqNumFlag=Y, resetting sequence
numbers to 1
20080806-00:48:43: Received logon request
20080806-00:48:43: Responding to logon request
20080806-00:51:40: Received ResendRequest FROM: 5797 TO: infinity
....
....
20080806-00:53:11: Resending Message: 16349
20080806-00:53:11: Resending Message: 16350
20080806-00:53:11: Resending Message: 16351
20080806-00:54:59: Disconnecting
20080806-00:55:02: Accepting session
FIX.4.4:FRZ->CLI/test1_1454906197547361963 from /192.168.149.71:3276
20080806-00:55:02: Acceptor heartbeat set to 45 seconds
20080806-00:55:02: Logon contains ResetSeqNumFlag=Y, resetting sequence
numbers to 1
20080806-00:55:02: Received logon request
20080806-00:55:02: Responding to logon request
20080806-00:55:02: MsgSeqNum too high, expecting 2 but received 5
20080806-00:55:02: Sent ResendRequest FROM: 2 TO: 0
20080806-00:55:02: MsgSeqNum too high, expecting 2 but received 6
20080806-00:55:02: Already sent ResendRequest FROM: 2 TO: 4. Not sending
another.
20080806-00:55:02: MsgSeqNum too high, expecting 2 but received 7
20080806-00:55:02: Already sent ResendRequest FROM: 2 TO: 4. Not sending
another.
20080806-00:55:02: MsgSeqNum too high, expecting 2 but received 8
20080806-00:55:02: Already sent ResendRequest FROM: 2 TO: 4. Not sending
another.
20080806-00:55:02: MsgSeqNum too high, expecting 2 but received 9
20080806-00:55:02: Already sent ResendRequest FROM: 2 TO: 4. Not sending
another.
20080806-00:55:02: ResendRequest for messages FROM 2 TO 4 has been
satisfied.
20080806-00:55:02: Processing queued message: 5, pending: [6, 7, 8, 9]
20080806-00:55:02: Processing queued message: 6, pending: [7, 8, 9]
20080806-00:55:02: Processing queued message: 7, pending: [8, 9]
20080806-00:55:02: Processing queued message: 8, pending: [9]
20080806-00:55:02: Processing queued message: 9, pending: []
20080806-00:55:02: MsgSeqNum too high, expecting 10 but received 12
20080806-00:55:02: Sent ResendRequest FROM: 10 TO: 0
20080806-00:55:02: ResendRequest for messages FROM 10 TO 11 has been
satisfied.
20080806-00:55:02: Processing queued message: 12, pending: []
20080806-00:57:07: Disconnecting
--
[ Rodrick R. Brown ]
http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown
|
