Re: [Quickfix-developers] Re quest resend
Brought to you by:
orenmnero
Menu
▾
▴
Re: [Quickfix-developers] Re quest resend
|
From: vije <vi...@ya...> - 2008-09-22 15:32:25
|
Hi Dave, I have a similar issue with QUICK FIX running as a client. I use Quick Fix to collect messages and then pass it on to the my order management system. If my order management system needs to request a resend, even thought we have already received it correctly, I send request resend messages using Quick FIX. It looks like since Quick fix has received it already , even the server sends the messages , wuick fix ignore it. Can I change this behaviour. Can I make Quick fix to accept the duplicate messages and then I can capture them in the fromApp or FromAdmin events. Appreciate your advice. Thanks Vije Dave Linaker wrote: > > Hi Stefano, > > As already mentioned, the use of the ResendRequest is managed by > QuickFIX automatically when a gap is detected, e.g. > > - QF receives MsgSeqNum 10 (Next expected seq num changes to 11) > - QF receives MsgSeqNum 12 (can't process, it's out of sequence!) > - QF automatically sends ResendRequest 7=11, 16=0 (i.e. give me > everything from MsgSeqNum 11) > > I'm assuming that you are manually attempting to send a ResendRequest > using sendToTarget() during an already synchronised connection? If so, > why? It would be useful to know what you are trying to acheive. > > If you are doing this then I would expect you to see the following from > CLIENT_ALL1's perspective: > > - CLIENT_ALL1 receives MsgSeqNum 81768 (Next expected seq num changes to > 81769) > - CLIENT_ALL1 receives MsgSeqNum 81769 (Next expected seq num changes to > 81770) > - CLIENT_ALL1 receives MsgSeqNum 81770 (Next expected seq num changes to > 81771) > - CLIENT_ALL1 manually sends ResendRequest 7=81768|16=81770 > - CLIENT_ALL1 receives MsgSeqNum 81768 (igored because Next expected seq > num changes to 81771) > - CLIENT_ALL1 receives MsgSeqNum 81769 (igored because Next expected seq > num changes to 81771) > - CLIENT_ALL1 receives MsgSeqNum 81770 (igored because Next expected seq > num changes to 81771) > > i.e. SPHERE_ALL probably is responding to the ResendRequest, but because > CLIENT_ALL1 has already processed these and is expecting 81771, they are > not passed to the application, they've already been processed. I think > they should be visible in the logs (see attached example). Are you using > the LogFactory? > > ...but I really don't know why you would want to do this. > > Kind regards > > Dave > > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On Behalf Of > Fad > Sent: 11 April 2006 09:01 > To: qui...@li... > Subject: [Quickfix-developers] Request resend > > > For example, in the server's message log there are: > 8=FIX.4.29=16035=UY34=81768 > 49=SPHERA_ALL52=20060410-16:01:34.26756=CLIENT_ALL155=TXT207=AFF26 > 2=Info9410074=VCH10076=010077=010080=010081=00:00:0010082=S10083= > 010=180 > 8=FIX.4.29=15935=UY34=8176949=SPHERA_ALL52=20060410-16:01:34.28356 > =CLIENT_ALL155=MS207=AFF262=Info9510074=VCH10076=010077=010080=0 > 10081=00:00:0010082=S10083=010=092 > 8=FIX.4.29=16035=UY34=8177049=SPHERA_ALL52=20060410-16:01:34.29856 > =CLIENT_ALL155=OLI207=AFF262=Info9610074=VCH10076=010077=010080=0 > 10081=00:00:0010082=S10083=010=151 > > If the client send a ResendRequest to server like this: > 8=FIX.4.29=8235=234=1049=CLIENT_ALL152=20060411-06:52:07.50756=SPH > ERA_ALL7=8176816=8177010=086 > > The QuickFix engine on server side doesn't send nothing.. Why..? > > Stefano. > > > [20060411-09:43:20.896][DETAIL][FIX.4.2:FixClient2->FixGateway]8=FIX.4.29=19635=834=105849=FixGateway52=20060411-08:43:20.89656=FixClient26=011=114=017=20060411exe0000000120=022=137=20060411ord0000000138=100039=040=244=76.548=ABC54=155=ABC150=0151=100010=034 > [20060411-09:43:20.976][DETAIL][FIX.4.2:FixClient2->FixGateway]8=FIX.4.29=19735=834=105949=FixGateway52=20060411-08:43:20.97656=FixClient26=011=214=017=20060411exe0000000220=022=137=20060411ord0000000238=100039=040=244=23.2548=DEF54=155=DEF150=0151=100010=098 > [20060411-09:43:21.036][DETAIL][FIX.4.2:FixClient2->FixGateway]8=FIX.4.29=19735=834=106049=FixGateway52=20060411-08:43:21.03656=FixClient26=011=314=017=20060411exe0000000320=022=137=20060411ord0000000338=100039=040=244=12.3248=GHI54=155=GHI150=0151=100010=095 > [20060411-09:43:50.899][DETAIL][FIX.4.2:FixClient2->FixGateway]8=FIX.4.29=6635=049=FixClient256=FixGateway34=105752=20060411-08:43:50.89910=047 > [20060411-09:43:51.019][DETAIL][FIX.4.2:FixClient2->FixGateway]8=FIX.4.29=6635=034=106149=FixGateway52=20060411-08:43:51.01956=FixClient210=027 > [20060411-09:44:20.942][DETAIL][FIX.4.2:FixClient2->FixGateway]8=FIX.4.29=6635=049=FixClient256=FixGateway34=105852=20060411-08:44:20.94210=035 > [20060411-09:44:21.072][DETAIL][FIX.4.2:FixClient2->FixGateway]8=FIX.4.29=6635=034=106249=FixGateway52=20060411-08:44:21.07256=FixClient210=025 > [20060411-09:44:23.676][DETAIL][FIX.4.2:FixClient2->FixGateway]8=FIX.4.29=8135=249=FixClient256=FixGateway34=105952=20060411-08:44:23.6767=105816=106010=217 > [20060411-09:44:23.686][DETAIL][FIX.4.2:FixClient2->FixGateway]8=FIX.4.29=22735=834=105843=Y49=FixGateway52=20060411-08:44:23.68656=FixClient2122=20060411-08:43:20.8966=011=114=017=20060411exe0000000120=022=137=20060411ord0000000138=100039=040=244=76.548=ABC54=155=ABC150=0151=100010=036 > [20060411-09:44:23.686][DETAIL][FIX.4.2:FixClient2->FixGateway]8=FIX.4.29=22835=834=105943=Y49=FixGateway52=20060411-08:44:23.68656=FixClient2122=20060411-08:43:20.9766=011=214=017=20060411exe0000000220=022=137=20060411ord0000000238=100039=040=244=23.2548=DEF54=155=DEF150=0151=100010=100 > [20060411-09:44:23.686][DETAIL][FIX.4.2:FixClient2->FixGateway]8=FIX.4.29=22835=834=106043=Y49=FixGateway52=20060411-08:44:23.68656=FixClient2122=20060411-08:43:21.0366=011=314=017=20060411exe0000000320=022=137=20060411ord0000000338=100039=040=244=12.3248=GHI54=155=GHI150=0151=100010=097 > > -- View this message in context: http://www.nabble.com/Request-resend-tp3856953p19610467.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
