RE: [Quickfix-users] Session resync problem
Brought to you by:
orenmnero
From: Sean K. <sea...@pi...> - 2006-03-07 16:41:45
|
Thanks Ajay, I appreciate the response. =20 We had considered that as an option, but I believe the ThreadedSocket = classes spawn a thread per session. Having hundreds of threads wasn't a = desirable approach for us. A thread pool would probably work, but I = don't think that is implemented...perhaps I am mistaken? =20 --Sean -----Original Message----- From: Ajay Kamdar [mailto:Aja...@tr...] Sent: Tuesday, March 07, 2006 11:29 AM To: Sean Kirkpatrick; qui...@li... Subject: RE: [Quickfix-users] Session resync problem You might want to consider using the = ThreadedSocketAcceptor/ThreadedSocketInitiator classes that will place = each Session on its own thread, which I expect should prevent the other = sessions getting starved while the engine is busy servicing the resend = requests in a tight loop. Obviously your application would need to be = thread safe to go this route. Caveat emptor: Not having actually used = these classes myself yet, this suggestion is based upon theoritical = analysis. YMMV. =20 - Ajay -----Original Message----- From: Sean Kirkpatrick [mailto:sea...@pi...]=20 Sent: Tuesday, March 07, 2006 9:05 AM To: qui...@li... Subject: [Quickfix-users] Session resync problem Hello All,=20 We had an issue in our production environment that boiled down to the = following:=20 1. Client has hard disconnect=20 2. We send some messages prior to detecting the session is down=20 3. Client logs back in with higher than expected seq num and immediately = starts sending some messages=20 4. We send resend reqs for each message we receive until they are = handled, which the client does by=20 sending us seq reset messages.=20 5. The client heartbeats.=20 6. At this point, we do some message resending.=20 -- this is where the trouble began --=20 7. Since the client did not sync its seq nums after the logon, when we = start sending these messages they=20 have higher than expected seq nums.=20 8. Client sends a resend request for each of the messages we sent (125). = When processing the resend requests, the engine sits in a tight loop = processing its queue. The trouble=20 here is that the resend requests took approx. 5 minutes to get through = and all other connections were=20 starved.=20 Has anyone come across this problem, or have a suggestion for dealing = with it gracefully?=20 Regards,=20 Sean Kirkpatrick=20 |