Thread: [Quickfix-developers] Request resend
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers
|
From: Fad <s.f...@gm...> - 2006-04-10 13:26:28
|
In the Fix specification there is written: Upon receipt of a Resend Request, the resender can respond in one of three ways: 1. retransmit the requested messages (in order) with the original sequence numbers and PossDupFlag set to "Y" 2. issue a SeqReset-GapFill with PossDupFlag set to "Y" message to replace the retransmission of administrative and application messages 3. issue a SeqReset-Reset with PossDupFlag set to "Y" to force sequence number synchronization With QuickFix is not possible implement the first point. Infact, the engine doesn't allow to send message with MsgSeqNum small as regards the last sent message. Thanks. |
|
From: Fad <s.f...@gm...> - 2006-04-10 19:12:20
|
I try to be more explicit. I am developing a clien and a server both includes QuickFix engine. For many reasons the client side could require old messages, from one MsgSeqNum to another MsgSeqNum with a "ResendRequest". The QuickFix engine do this only for his session operation and not every time I ask this "service". How can I do? Thanks, Facchetti Stefano |
|
From: Caleb E. <cal...@gm...> - 2006-04-10 20:10:12
|
On 4/10/06, Fad <s.f...@gm...> wrote: > > I am developing a clien and a server both includes QuickFix engine. > For many reasons the client side could require old messages, from one > MsgSeqNum to another MsgSeqNum with a "ResendRequest". The QuickFix engi= ne > do this only for his session operation and not every time I ask this > "service". > How can I do? > QuickFIX will respond to each and every ResendRequest it receives. Are you not seeing this behavior? Do you have any sample code and logfiles? -- Caleb Epstein caleb dot epstein at gmail dot com |
|
From: Caleb E. <cal...@gm...> - 2006-04-11 13:04:46
|
On 4/11/06, Fad <s.f...@gm...> wrote: > > For example, in the server's message log there are: > 8=3D > FIX.4.2=019=3D160=0135=3DUY=0134=3D81768=0149=3DSPHERA_ALL=0152=3D2006041= 0-16:01:34.267=0156=3DCLIENT_ALL1=0155=3DTXT=01207=3DAFF=01262=3DInfo94=011= 0074=3DVCH=0110076=3D0=0110077=3D0=0110080=3D0=0110081=3D00:00:00=0110082= =3DS=0110083=3D0=0110=3D180=01 > 8=3D > FIX.4.2=019=3D159=0135=3DUY=0134=3D81769=0149=3DSPHERA_ALL=0152=3D2006041= 0-16:01:34.283=0156=3DCLIENT_ALL1=0155=3DMS=01207=3DAFF=01262=3DInfo95=0110= 074=3DVCH=0110076=3D0=0110077=3D0=0110080=3D0=0110081=3D00:00:00=0110082=3D= S=0110083=3D0=0110=3D092=01 > 8=3D > FIX.4.2=019=3D160=0135=3DUY=0134=3D81770=0149=3DSPHERA_ALL=0152=3D2006041= 0-16:01:34.298=0156=3DCLIENT_ALL1=0155=3DOLI=01207=3DAFF=01262=3DInfo96=011= 0074=3DVCH=0110076=3D0=0110077=3D0=0110080=3D0=0110081=3D00:00:00=0110082= =3DS=0110083=3D0=0110=3D151=01 > > If the client send a ResendRequest to server like this: > 8=3D > FIX.4.2=019=3D82=0135=3D2=0134=3D10=0149=3DCLIENT_ALL1=0152=3D20060411-06= :52:07.507=0156=3DSPHERA_ALL=017=3D81768=0116=3D81770=0110=3D086=01 > > The QuickFix engine on server side doesn't send nothing.. Why..? > Is the server using a persistent type of MessageStore, like the FileStore o= r one of the database-backed Stores? What is MsgType "UY"? The prsesence of the field MDReqID screams market data to me, which makes me wonder if these messages would even be candidates for resending. Additionally, the timestamp on the ResendRequest appears to be 14 hours after those messages were sent. Is it possible that the session has reset itself during that time? The session log should give some more detail about what is happening on the server side (e.g received resend request, resending message, sending sequence reset, etc). PS. You are sending double emails. Please use "Reply to All" and send onl= y one message. -- Caleb Epstein caleb dot epstein at gmail dot com |
|
From: Fad <s.f...@gm...> - 2006-04-11 19:23:43
|
Server uses FileStore and "UY" is my custom type message. The difference in the timestamp is not a problem, the Fix messages that I had post are only for example. However in the tests that I have done, I have found that: *** In syncronized session *** if the client send a "ResendRequest", the QuickFix engine on server side answers with SeqReset-GapFill with PossDupFlag set to "Y". It is perfect for me. *** In not syncronized session *** If the client send a "ResendRequest", the QuickFix engine on server side instead of resend the message that are stored in message's log, it send SeqReset-GapFill with PossDupFlag set to "Y". It is not all right for me. Stefano. P.S. Sorry for double emails. -- View this message in context: http://www.nabble.com/Request-resend-t1427100.html#a3868722 Sent from the QuickFIX - Dev forum at Nabble.com. |
|
From: Fad <s.f...@gm...> - 2006-04-11 08:01:12
|
For example, in the server's message log there are: 8=3DFIX.4.2=019=3D160=0135=3DUY=0134=3D81768=0149=3DSPHERA_ALL=0152=3D20060= 410-16:01: 34.267=0156=3DCLIENT_ALL1=0155=3DTXT=01207=3DAFF=01262=3DInfo94=0110074=3DV= CH=0110076=3D0=0110077=3D0=0110080=3D0=0110081=3D00:00:00=0110082=3DS=01100= 83=3D0=0110=3D180=01 8=3D FIX.4.2=019=3D159=0135=3DUY=0134=3D81769=0149=3DSPHERA_ALL=0152=3D20060410-= 16:01:34.283=0156=3DCLIENT_ALL1=0155=3DMS=01207=3DAFF=01262=3DInfo95=011007= 4=3DVCH=0110076=3D0=0110077=3D0=0110080=3D0=0110081=3D00:00:00=0110082=3DS= =0110083=3D0=0110=3D092=01 8=3D FIX.4.2=019=3D160=0135=3DUY=0134=3D81770=0149=3DSPHERA_ALL=0152=3D20060410-= 16:01:34.298=0156=3DCLIENT_ALL1=0155=3DOLI=01207=3DAFF=01262=3DInfo96=01100= 74=3DVCH=0110076=3D0=0110077=3D0=0110080=3D0=0110081=3D00:00:00=0110082=3DS= =0110083=3D0=0110=3D151=01 If the client send a ResendRequest to server like this: 8=3D FIX.4.2=019=3D82=0135=3D2=0134=3D10=0149=3DCLIENT_ALL1=0152=3D20060411-06:5= 2:07.507=0156=3DSPHERA_ALL=017=3D81768=0116=3D81770=0110=3D086=01 The QuickFix engine on server side doesn't send nothing.. Why..? Stefano. |
|
From: Dave L. <dav...@ma...> - 2006-04-11 08:58:26
|
[20060411-09:43:20.896][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.= 2=019=3D196=0135=3D8=0134=3D1058=0149=3DFixGateway=0152=3D20060411-08:43:= 20.896=0156=3DFixClient2=016=3D0=0111=3D1=0114=3D0=0117=3D20060411exe0000= 0001=0120=3D0=0122=3D1=0137=3D20060411ord00000001=0138=3D1000=0139=3D0=01= 40=3D2=0144=3D76.5=0148=3DABC=0154=3D1=0155=3DABC=01150=3D0=01151=3D1000=01= 10=3D034=01 [20060411-09:43:20.976][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.= 2=019=3D197=0135=3D8=0134=3D1059=0149=3DFixGateway=0152=3D20060411-08:43:= 20.976=0156=3DFixClient2=016=3D0=0111=3D2=0114=3D0=0117=3D20060411exe0000= 0002=0120=3D0=0122=3D1=0137=3D20060411ord00000002=0138=3D1000=0139=3D0=01= 40=3D2=0144=3D23.25=0148=3DDEF=0154=3D1=0155=3DDEF=01150=3D0=01151=3D1000= =0110=3D098=01 [20060411-09:43:21.036][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.= 2=019=3D197=0135=3D8=0134=3D1060=0149=3DFixGateway=0152=3D20060411-08:43:= 21.036=0156=3DFixClient2=016=3D0=0111=3D3=0114=3D0=0117=3D20060411exe0000= 0003=0120=3D0=0122=3D1=0137=3D20060411ord00000003=0138=3D1000=0139=3D0=01= 40=3D2=0144=3D12.32=0148=3DGHI=0154=3D1=0155=3DGHI=01150=3D0=01151=3D1000= =0110=3D095=01 [20060411-09:43:50.899][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.= 2=019=3D66=0135=3D0=0149=3DFixClient2=0156=3DFixGateway=0134=3D1057=0152=3D= 20060411-08:43:50.899=0110=3D047=01 [20060411-09:43:51.019][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.= 2=019=3D66=0135=3D0=0134=3D1061=0149=3DFixGateway=0152=3D20060411-08:43:5= 1.019=0156=3DFixClient2=0110=3D027=01 [20060411-09:44:20.942][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.= 2=019=3D66=0135=3D0=0149=3DFixClient2=0156=3DFixGateway=0134=3D1058=0152=3D= 20060411-08:44:20.942=0110=3D035=01 [20060411-09:44:21.072][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.= 2=019=3D66=0135=3D0=0134=3D1062=0149=3DFixGateway=0152=3D20060411-08:44:2= 1.072=0156=3DFixClient2=0110=3D025=01 [20060411-09:44:23.676][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.= 2=019=3D81=0135=3D2=0149=3DFixClient2=0156=3DFixGateway=0134=3D1059=0152=3D= 20060411-08:44:23.676=017=3D1058=0116=3D1060=0110=3D217=01 [20060411-09:44:23.686][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.= 2=019=3D227=0135=3D8=0134=3D1058=0143=3DY=0149=3DFixGateway=0152=3D200604= 11-08:44:23.686=0156=3DFixClient2=01122=3D20060411-08:43:20.896=016=3D0=01= 11=3D1=0114=3D0=0117=3D20060411exe00000001=0120=3D0=0122=3D1=0137=3D20060= 411ord00000001=0138=3D1000=0139=3D0=0140=3D2=0144=3D76.5=0148=3DABC=0154=3D= 1=0155=3DABC=01150=3D0=01151=3D1000=0110=3D036=01 [20060411-09:44:23.686][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.= 2=019=3D228=0135=3D8=0134=3D1059=0143=3DY=0149=3DFixGateway=0152=3D200604= 11-08:44:23.686=0156=3DFixClient2=01122=3D20060411-08:43:20.976=016=3D0=01= 11=3D2=0114=3D0=0117=3D20060411exe00000002=0120=3D0=0122=3D1=0137=3D20060= 411ord00000002=0138=3D1000=0139=3D0=0140=3D2=0144=3D23.25=0148=3DDEF=0154= =3D1=0155=3DDEF=01150=3D0=01151=3D1000=0110=3D100=01 [20060411-09:44:23.686][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.= 2=019=3D228=0135=3D8=0134=3D1060=0143=3DY=0149=3DFixGateway=0152=3D200604= 11-08:44:23.686=0156=3DFixClient2=01122=3D20060411-08:43:21.036=016=3D0=01= 11=3D3=0114=3D0=0117=3D20060411exe00000003=0120=3D0=0122=3D1=0137=3D20060= 411ord00000003=0138=3D1000=0139=3D0=0140=3D2=0144=3D12.32=0148=3DGHI=0154= =3D1=0155=3DGHI=01150=3D0=01151=3D1000=0110=3D097=01 |
|
From: Fad <s.f...@gm...> - 2006-04-11 19:35:46
|
Dave Linaker wrote: > > > 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) > > It is not true, infact the client after send "ResendRequest" recive a SeqReset-GapFill with PossDupFlag set to "Y". It's ok, because the client-server session are syncronized. But if the client-server session are not syncronized, the quickFix engine instead of resend the 'lost message' sends however the SeqReset-GapFill message with PossDupFlag set to "Y" (in the logs file thera are the message that the server should resend). Stefano. -- View this message in context: http://www.nabble.com/Request-resend-t1430121.html#a3868937 Sent from the QuickFIX - Dev forum at Nabble.com. |
|
From: Oren M. <or...@qu...> - 2006-04-11 20:25:34
|
Are you sure those "lost" messages are not administrative messages? QuickFIX will not resend administrative messages (it is not necessary and in fact harmful). --oren Fad wrote: >QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html >QuickFIX Support: http://www.quickfixengine.org/services.html > > > > > >Dave Linaker wrote: > > >> >>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) >> >> >> >> > >It is not true, infact the client after send "ResendRequest" recive a >SeqReset-GapFill with PossDupFlag set to "Y". It's ok, because the >client-server session are syncronized. > >But if the client-server session are not syncronized, the quickFix engine >instead of resend the 'lost message' sends however the SeqReset-GapFill >message with PossDupFlag set to "Y" (in the logs file thera are the message >that the server should resend). > >Stefano. > >-- >View this message in context: http://www.nabble.com/Request-resend-t1430121.html#a3868937 >Sent from the QuickFIX - Dev forum at Nabble.com. > > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >_______________________________________________ >Quickfix-developers mailing list >Qui...@li... >https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > > |
|
From: Fad <s.f...@gm...> - 2006-04-12 07:46:32
|
Yes, I'm sure.. The messages ara Application messages. Stefano. -- View this message in context: http://www.nabble.com/Request-resend-t1430121.html#a3877148 Sent from the QuickFIX - Dev forum at Nabble.com. |
|
From: Andrew M. <an...@nm...> - 2006-04-11 20:26:19
|
When I build QF using VS2005 (8.x) I get the error below when I run it.
It runs on machines that have VS2005 installed but I would like to be able
to distribute my app on machines w/out installing VS2005 or the .NET
framework. Can anyone tell me specifically what files need to be
included to avoid that?
Thanks,
Andrew
Exception in thread "main" java.lang.UnsatisfiedLinkError:
Z:\javaclasses\quickfix\quickfix_jni.dll: This application has failed to start because the
application configuration is incorrect. Reinstalling the application may fix this
problem
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:992)
at multifix.mfix.<clinit>(mfix.java:75)
|
|
From: Caleb E. <cal...@gm...> - 2006-04-11 20:39:49
|
On 4/11/06, Fad <s.f...@gm...> wrote: But if the client-server session are not syncronized, the quickFix engine > instead of resend the 'lost message' sends however the SeqReset-GapFill > message with PossDupFlag set to "Y" (in the logs file thera are the > message > that the server should resend). The engine will do this only if: - The messages do not exist in the MessageStore - The messages are considered to be admin-type messages The presence of the messages in the server's outgoing log files does not mean that they can be resent or have been persisted in the MessageStore, only that they were sent on the connection at some time. Only messages which have been persisted to a MessageStore can be resent. The logs don't play any part in this. What kind of MessageStore is your application using? Have you possibly customized the "Message::isAdmin" method to return true for this custom MsgType "UY"? -- Caleb Epstein caleb dot epstein at gmail dot com |
|
From: Fad <s.f...@gm...> - 2006-04-12 07:44:10
|
I have checked and the messages are present in the MessageStore. The messages that I expect to receive are of type: "ExecutionReport" (Application message) My application uses FileStore. The message aren't resend by QuickFix engine.. Why? -- View this message in context: http://www.nabble.com/Request-resend-t1430121.html#a3877118 Sent from the QuickFIX - Dev forum at Nabble.com. |
|
From: Oren M. <or...@qu...> - 2006-04-12 08:03:40
|
Because you have already received those messages. ResendRequests are designed for use by the protocol to ensure message delivery. They are *not* designed for you to repopulate your data structures. When you send a query out for messages, QuickFIX knows it has already processed and passed them on to you, it will not pass them to you again. An engine must guarantee that all messages are delivered in order. If you have already processed message 100, and you ask for messages 90-99, QuickFIX would be breaking that guarantee by passing you messages out of order, and messages you have already processed to boot. If you really really must do this (do you? really?), then you will need to lower the clients expected sequence number in order to trick QuickFIX into passing those messages to you again. So if you want to get message 90-current, lower your expected sequence number to 90, then send your ResendRequest. Please keep in mind that QuickFIX is a messaging protocol, not an OMS. You must take responsibility to persist any data you want to keep around. --oren Fad wrote: >QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html >QuickFIX Support: http://www.quickfixengine.org/services.html > > >I have checked and the messages are present in the MessageStore. >The messages that I expect to receive are of type: "ExecutionReport" >(Application message) >My application uses FileStore. > >The message aren't resend by QuickFix engine.. Why? > > > >-- >View this message in context: http://www.nabble.com/Request-resend-t1430121.html#a3877118 >Sent from the QuickFIX - Dev forum at Nabble.com. > > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >_______________________________________________ >Quickfix-developers mailing list >Qui...@li... >https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > > |
|
From: Fad <s.f...@gm...> - 2006-04-12 08:17:50
|
Oren Miller wrote: > > If you really really must do this (do you? really?), then you will need > to lower the clients expected sequence number in order to trick QuickFIX > into passing those messages to you again. So if you want to get message > 90-current, lower your expected sequence number to 90, then send your > ResendRequest. > > Please keep in mind that QuickFIX is a messaging protocol, not an OMS. > You must take responsibility to persist any data you want to keep around. > Ok, I have understood that QuickFix is a messaging protocol, but I try to decrease the clients expected sequence number. When client has started, automatically send to server a ResendRequest but the server send a sequenceReset-GapFill instead all the 'lost messagges'. It is correct..? Thanks, Stefano -- View this message in context: http://www.nabble.com/Request-resend-t1430121.html#a3877509 Sent from the QuickFIX - Dev forum at Nabble.com. |
|
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. |
|
From: Fad <s.f...@gm...> - 2006-04-12 13:04:34
|
The problem has resolved.
In toApp method of my Application I worte code like that present in the
QuickFix examples :
void KCApplication::toApp( FIX::Message& message, const FIX::SessionID&
sessionID )
throw( FIX::DoNotSend )
{
try
{
FIX::PossDupFlag possDupFlag;
message.getHeader().getField( possDupFlag );
if ( possDupFlag )
{
throw FIX::DoNotSend();
}
}
catch ( FIX::FieldNotFound& ) {}
if (m_ApptoApp)
m_ApptoApp(appdata,(void *)&message,(void *)&sessionID);
}
this code don't work properly, I replace that code with this and all is ok:
void KCApplication::toApp( FIX::Message& message, const FIX::SessionID&
sessionID )
throw( FIX::DoNotSend )
{
if (m_ApptoApp)
m_ApptoApp(appdata,(void *)&message,(void *)&sessionID);
}
Thank you to all for the help that you have given me.
Stefano.
--
View this message in context: http://www.nabble.com/Request-resend-t1430121.html#a3881004
Sent from the QuickFIX - Dev forum at Nabble.com.
|
|
From: Caleb E. <cal...@gm...> - 2006-04-12 13:42:17
|
On 4/12/06, Fad <s.f...@gm...> wrote:
>
> The problem has resolved.
> In toApp method of my Application I worte code like that present in the
> QuickFix examples :
>
> void KCApplication::toApp( FIX::Message& message, const FIX::SessionID&
> sessionID )
> throw( FIX::DoNotSend )
> {
> try
> {
> FIX::PossDupFlag possDupFlag;
> message.getHeader().getField( possDupFlag );
> if ( possDupFlag )
> {
> throw FIX::DoNotSend();
> }
> }
This is at least the second time I can recall someone has been bitten by
copying this example code. I'm going to remove that check for possDupFlag.
I've removed this section of Application::toApp from the example program to
hopefully prevent future misunderstandings like this.
> this code don't work properly, I replace that code with this and all is
> ok:
The code works exactly as it should. It doesn't process messages with the
PossDup flag set. This is arguably dumb, but it works exactly as designed.
--
Caleb Epstein
caleb dot epstein at gmail dot com
|
|
From: Fad <s.f...@gm...> - 2006-04-10 13:47:58
|
In the Fix specification there is written: Upon receipt of a Resend Request, the resender can respond in one of three ways: 1. retransmit the requested messages (in order) with the original sequence numbers and PossDupFlag set to "Y" 2. issue a SeqReset-GapFill with PossDupFlag set to "Y" message to replace the retransmission of administrative and application messages 3. issue a SeqReset-Reset with PossDupFlag set to "Y" to force sequence number synchronization With QuickFix is not possible implement the first point. Infact, the engine doesn't allow to send message with MsgSeqNum small as regards the last sent message. Thanks. |
|
From: Caleb E. <cal...@gm...> - 2006-04-10 15:03:47
|
On 4/10/06, Fad <s.f...@gm...> wrote: > Upon receipt of a Resend Request, the resender can respond in one of > three ways: > > 1. retransmit the requested messages (in order) with the original > sequence numbers and PossDupFlag set to "Y" > 2. issue a SeqReset-GapFill with PossDupFlag set to "Y" message to > replace the retransmission of administrative and application messages > 3. issue a SeqReset-Reset with PossDupFlag set to "Y" to force sequence > number synchronization > > With QuickFix is not possible implement the first point. Infact, the engi= ne > doesn't allow to send message with MsgSeqNum small as regards the last se= nt > message. QuickFIX implements this logic for you automatically in the Session layer. Are you trying to handle this yourself in your Application?=20 It is not necessary. -- Caleb Epstein caleb dot epstein at gmail dot com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X