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
|