I am not sure where this was discussed before, but I see the same thing
happen when using a threaded Acceptor with a Synchronized Application.
Oren Miller wrote:
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Actually I wasn't aware of this. The threaded initiator/acceptor has a
> thread per session, so I'm not sure how one can cause the other to
> block. I'd be interested in looking into it. Do you know about when
> this was being discussed?
>
> --oren
>
>> -------- Original Message --------
>> Subject: [Quickfix-developers] Gap Fills blocking?
>> From: John Haldi <jh...@ca...>
>> Date: Mon, March 22, 2010 9:56 am
>> To: "qui...@li..."
>> <qui...@li...>
>>
>>
>> QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html<hr>Oren,
>>
>> A long time ago a thread went around this mailing list discussing the
>> Gap Fill process as it relates to the threaded socket initiators and
>> acceptors. The issue was essentially that QF would block other
>> threads during a Gap Fill request on a session managed by the threaded
>> acceptor. I believe that at the time somebody had submitted a fix to
>> this issue -- but I can't say with certainty.
>>
>> Do you happen to know if the 1.13.x build(s) have addressed this
>> issue, or if I should still expect 1.13.x to behave the same way?
>>
>> [If the above makes sense, please read no further. If I've lost you,
>> please read on for an example of what I've been seeing...]
>>
>> Suppose I have a FIX message gateway app (using QF 1.12.4
>> out-of-the-box, pre-built DLLs in .NET) which creates a threaded
>> initiator with a session out to ARCA, and which creates a threaded
>> acceptor with three sessions from Client #1, Client #2 and Client #3.
>> When my gateway gets a message from ARCA, it sends a copy to each
>> Client so that all three clients see each other's order acks+fills.
>>
>> Now suppose Client #1 and Client #2 connect to their session in the
>> morning, while Client #3 is disconnected. A message queue builds up
>> in QF (because of the traffic from Clients #1 and #2) waiting for
>> Client #3 to connect. After lunch Client #3 connects and there are
>> 100,000+ messages waiting to flow from the gateway down to Client #3.
>> While QF performs the Gap Fill of these 100,000+ messages, all message
>> traffic from ARCA is blocked -- sessions for Clients #1 and #2 do not
>> receive messages coming from ARCA, and QF won't respond to ARCA's Test
>> Requests - while the queue'd message are passed down to Client #3.
>>
>> I'm curious if this was addressed in the latest build(s) or if I
>> should expect the same behavior if I migrate up from 1.12.4.
>>
>> Many thanks,
>>
>>
>> John<hr>------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev<hr>_______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
--
View this message in context: http://old.nabble.com/Gap-Fills-blocking--tp27987754p28588981.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.
|
