Re: [Quickfix-users] Session resync problem
Brought to you by:
orenmnero
From: Oren M. <or...@qu...> - 2006-03-08 02:05:11
|
Although Ajay's analysis is correct, and under other circumstances moving to a threaded model might be appropriate, it is actually a red herring in this case. I know you guys are running an older version of the engine, and it is the resend logic in there where the fault really lies. Older versions of QuickFIX did not handle this sort of resend scenario very gracefully. The old implementation wasn't technically incorrect, but it wasn't especially smart either. Newer versions of the engine can detect these sort of recursive resend request scenarios and avoid them so you would only send 125 instead of 125! messages. The relevant code (in newer versions) that protects against this scenario is implemented with a resendRange in the session class. --oren Sean Kirkpatrick wrote: > Thanks Ajay, I appreciate the response. > > 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? > > --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. > > - Ajay > > -----Original Message----- > *From:* Sean Kirkpatrick > [mailto:sea...@pi...] > *Sent:* Tuesday, March 07, 2006 9:05 AM > *To:* qui...@li... > *Subject:* [Quickfix-users] Session resync problem > > Hello All, > > We had an issue in our production environment that boiled down > to the following: > > 1. Client has hard disconnect > 2. We send some messages prior to detecting the session is down > 3. Client logs back in with higher than expected seq num and > immediately starts sending some messages > 4. We send resend reqs for each message we receive until they > are handled, which the client does by > sending us seq reset messages. > 5. The client heartbeats. > 6. At this point, we do some message resending. > -- this is where the trouble began -- > 7. Since the client did not sync its seq nums after the logon, > when we start sending these messages they > have higher than expected seq nums. > 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 > here is that the resend requests took approx. 5 minutes to get > through and all other connections were > starved. > > Has anyone come across this problem, or have a suggestion for > dealing with it gracefully? > > Regards, > > Sean Kirkpatrick > |