Thread: [Quickfix-users] Incorrect Data Format aka possDupFlag issue
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-users
|
From: aupadras <ani...@ya...> - 2013-07-08 01:13:51
|
Hi,
I am having following problem.., I sort of figured out where the problem is
and not able to figure of the best solution to it...
My Config Settings:
[DEFAULT]
ConnectionType=initiator
StartTime=00:01:00
EndTime=23:55:00
MsgSeqNum=1
UseLocalTime=Y
ResetOnDisconnect=N
CheckLatency=N
PossDupFlag=N
ResetOnLogon=N
ResetOnLogout=N
SendResetSeqNumFlag=N
RefreshOnLogon=Y
PersistMessages=Y
MillisecondsInTimeStamp=Y
UseDataDictionary=Y
HeartBtInt=30
<field name='PossDupFlag' required='N' />
Problem: I am able to STAGE the order, however the operations of staging is
not smooth i.e.., STAGING the order is followed by following issues (even
though tag 15 is not missing (Currency = 'USD')) the message is getting
rejected) :
20130707-20:34:45.664 : Created session
20130707-20:34:47.227 : Connecting to 63.75.63.250 on port 1838
20130707-20:34:47.274 : Initiated logon request
20130707-20:34:47.289 : Received logon response
20130707-20:34:47.446 : Message 2 Rejected: Required tag missing:15
20130707-20:34:49.164 : Initiated logout request
20130707-20:34:49.164 : Received logout response
20130707-20:34:49.164 : Disconnecting
20130707-20:34:47.258 :
8=FIX.4.29=6435=A34=149=alpha52=20130707-20:34:47.24356=beta98=0108=3010=191
20130707-20:34:47.274 :
8=FIX.4.29=6035=A49=beta56=alpha34=152=20130707-20:34:4798=0108=3010=244
20130707-20:34:47.321 :
8=FIX.4.29=23535=D34=249=alpha52=20130707-20:34:47.27456=beta57=STAGE1=NEUTRAL11=alphaA5187315=USD21=138=1540=144=1624.554=155=/ESU359=060=20130707-20:34:4776=Neutral107=E-mini
S&P500114=Y167=FUT200=201309205=30207=CME231=5010=086
20130707-20:34:47.430 :
8=FIX.4.29=26235=849=beta56=alpha34=250=STAGE52=20130707-20:34:4737=d9351954-d1-07sp11=alphaA5187317=d9351954-d1-07sp-220=0150=039=01=NEUTRAL55=/ESU354=138=1540=159=0167=FUT200=201309205=3047=I32=031=0.000000151=1514=06=0.00000060=20130707-20:34:4710=151
20130707-20:34:47.446 :
8=FIX.4.29=10035=334=349=alpha52=20130707-20:34:47.44656=beta45=258=Required
tag missing371=15372=8373=110=094
20130707-20:34:49.164 :
8=FIX.4.29=5235=534=449=alpha52=20130707-20:34:49.16456=beta10=158
20130707-20:34:49.164 :
8=FIX.4.29=4835=549=beta56=alpha34=352=20130707-20:34:4810=216
The problem is kicking from toAPP:
void Application::toApp( FIX::Message& NewOrderSingle, const FIX::SessionID&
sessionID )
throw( FIX::DoNotSend )
{
std::cout << "\n" << std::endl << "To App" << "\n" << std::endl;
try
{
FIX::PossDupFlag possDupFlag;
std::cout << std::endl << "Currency" << std::endl <<
NewOrderSingle.getField(FIX::Currency()) << "\n" << std::endl;
std::cout << std::endl << "Complete Message to XML" << std::endl <<
NewOrderSingle.toXML() << "\n" << std::endl;
NewOrderSingle.getHeader().getField( possDupFlag );
if ( possDupFlag ) throw FIX::DoNotSend();
}
catch ( FIX::FieldNotFound& FieldNotFound) {
std::cout << std::endl << " Field Not Found " << FieldNotFound.what()
<< "\n" << std::endl;
std::cout << std::endl << "Field Not Found: " << FieldNotFound.field <<
"\n" << std::endl;
std::cout << std::endl << "Field Not Found Type: " << FieldNotFound.type
<< "\n" << std::endl;
}
catch ( FIX::IncorrectTagValue& IncorrectTagValue) {
std::cout << std::endl << "Incorrect Tag detail: " <<
IncorrectTagValue.what() << "\n" << std::endl;
std::cout << std::endl << "Incorrect Tag Value: " <<
IncorrectTagValue.field << "\n" << std::endl;
}
catch ( FIX::IncorrectDataFormat& IncorrectDataFormat) {
std::cout << std::endl << "Incorrect Data Format Field: " <<
IncorrectDataFormat.what() << "\n" << std::endl;
std::cout << std::endl << "Incorrect Data Format Type: " <<
IncorrectDataFormat.type << "\n" << std::endl;
}
}
The problem is due to possDupFlag in toAPP and after this reject message I
am getting logged out not able to enter into fromAPP logic (to retrieve
execution report info)
If I delete the possDupFlag from toAPP logic then I am having following
issue.., message sequence resetting or socket initiator error by resetting
possDupFlag to Y (initial setting was "N"):
20130707-23:52:54.518 : Connecting to 63.75.63.250 on port 1838
20130707-23:54:11.411 : Created session
20130707-23:54:17.865 : Connecting to 63.75.63.250 on port 1838
20130707-23:54:17.880 : Initiated logon request
20130707-23:54:17.912 : Received logon response
20130707-23:54:17.912 : MsgSeqNum too high, expecting 30 but received 46
20130707-23:54:38.115 : Sent ResendRequest FROM: 30 TO: 0
20130707-23:54:38.131 : Received ResendRequest FROM: 34 TO: 0
20130707-23:54:48.694 : Resending Message: 34
20130707-23:54:53.491 : Sent SequenceReset TO: 36
20130707-23:54:53.491 : Resending Message: 36
20130707-23:54:55.288 : Sent SequenceReset TO: 39
20130707-23:54:55.288 : Resending Message: 39
20130707-23:54:56.085 : Sent SequenceReset TO: 42
20130707-23:54:56.085 : Resending Message: 42
20130707-23:54:56.100 : Sent SequenceReset TO: 44
20130707-23:54:56.100 : Initiated logout request
20130707-23:54:56.100 : Received ResendRequest FROM: 34 TO: 0
20130707-23:54:56.460 : Resending Message: 34
20130707-23:54:56.819 : Sent SequenceReset TO: 36
20130707-23:54:56.819 : Resending Message: 36
20130707-23:54:57.194 : Sent SequenceReset TO: 39
20130707-23:54:57.194 : Resending Message: 39
20130707-23:54:57.569 : Sent SequenceReset TO: 42
20130707-23:54:57.569 : Resending Message: 42
20130707-23:54:57.585 : Sent SequenceReset TO: 45
20130707-23:54:57.585 : Received SequenceReset FROM: 30 TO: 49
20130707-23:54:57.585 : Received logout response
20130707-23:54:57.585 : Disconnecting
20130707-23:43:41.907 :
8=FIX.4.29=6535=A34=3349=alpha52=20130707-23:43:41.89156=beta98=0108=3010=251
20130707-23:43:41.907 :
8=FIX.4.29=6135=A49=beta56=alpha34=2952=20130707-23:43:4198=0108=3010=044
20130707-23:46:20.193 :
8=FIX.4.29=23635=D34=3449=alpha52=20130707-23:43:41.95456=beta57=STAGE1=NEUTRAL11=alphaA1004315=USD21=138=2540=144=1624.554=155=/ESU359=060=20130707-23:43:4176=Neutral107=E-mini
S&P500114=Y167=FUT200=201309205=30207=CME231=5010=124
20130707-23:48:28.900 :
8=FIX.4.29=6535=A34=3549=alpha52=20130707-23:48:28.86956=beta98=0108=3010=012
20130707-23:48:28.932 :
8=FIX.4.29=6135=A49=beta56=alpha34=3452=20130707-23:48:2898=0108=3010=050
20130707-23:49:51.028 :
8=FIX.4.29=23635=D34=3649=alpha52=20130707-23:48:28.90056=beta57=STAGE1=NEUTRAL11=alphaA1003315=USD21=138=2540=144=1624.554=155=/ESU359=060=20130707-23:48:2876=Neutral107=E-mini
S&P500114=Y167=FUT200=201309205=30207=CME231=5010=136
20130707-23:49:51.028 :
8=FIX.4.29=6335=234=3749=alpha52=20130707-23:49:51.02856=beta7=3016=010=129
20130707-23:51:22.094 :
8=FIX.4.29=6535=A34=3849=alpha52=20130707-23:51:22.06256=beta98=0108=3010=244
20130707-23:51:22.109 :
8=FIX.4.29=6135=A49=beta56=alpha34=4052=20130707-23:51:2198=0108=3010=034
20130707-23:52:53.518 :
8=FIX.4.29=23635=D34=3949=alpha52=20130707-23:51:22.09456=beta57=STAGE1=NEUTRAL11=alphaA1002315=USD21=138=2540=144=1624.554=155=/ESU359=060=20130707-23:51:2276=Neutral107=E-mini
S&P500114=Y167=FUT200=201309205=30207=CME231=5010=118
20130707-23:52:53.518 :
8=FIX.4.29=6335=234=4049=alpha52=20130707-23:52:53.51856=beta7=3016=010=123
20130707-23:54:17.880 :
8=FIX.4.29=6535=A34=4149=alpha52=20130707-23:54:17.86556=beta98=0108=5010=002
20130707-23:54:17.880 :
8=FIX.4.29=6135=A49=beta56=alpha34=4652=20130707-23:54:1798=0108=5010=050
20130707-23:54:38.115 :
8=FIX.4.29=23635=D34=4249=alpha52=20130707-23:54:17.91256=beta57=STAGE1=NEUTRAL11=alphaA1002315=USD21=138=2540=144=1624.554=155=/ESU359=060=20130707-23:54:1776=Neutral107=E-mini
S&P500114=Y167=FUT200=201309205=30207=CME231=5010=125
20130707-23:54:38.115 :
8=FIX.4.29=6335=234=4349=alpha52=20130707-23:54:38.11556=beta7=3016=010=124
20130707-23:54:38.131 :
8=FIX.4.29=5935=249=beta56=alpha34=4752=20130707-23:54:177=3416=010=193
20130707-23:54:48.694 :
8=FIX.4.29=26735=D34=3443=Y49=alpha52=20130707-23:54:38.13156=beta57=STAGE122=20130707-23:43:41.9541=NEUTRAL11=alphaA1004315=USD21=138=2540=144=1624.554=155=/ESU359=060=20130707-23:43:4176=Neutral107=E-mini
S&P500114=Y167=FUT200=201309205=30207=CME231=5010=130
20130707-23:54:53.491 :
8=FIX.4.29=9635=434=3543=Y49=alpha52=20130707-23:54:53.49156=beta122=20130707-23:54:53.49136=36123=Y10=033
20130707-23:54:53.491 :
8=FIX.4.29=26735=D34=3643=Y49=alpha52=20130707-23:54:48.69456=beta57=STAGE122=20130707-23:48:28.9001=NEUTRAL11=alphaA1003315=USD21=138=2540=144=1624.554=155=/ESU359=060=20130707-23:48:2876=Neutral107=E-mini
S&P500114=Y167=FUT200=201309205=30207=CME231=5010=157
20130707-23:54:55.288 :
8=FIX.4.29=9635=434=3743=Y49=alpha52=20130707-23:54:55.27256=beta122=20130707-23:54:55.27236=39123=Y10=036
20130707-23:54:55.288 :
8=FIX.4.29=26735=D34=3943=Y49=alpha52=20130707-23:54:53.50756=beta57=STAGE122=20130707-23:51:22.0941=NEUTRAL11=alphaA1002315=USD21=138=2540=144=1624.554=155=/ESU359=060=20130707-23:51:2276=Neutral107=E-mini
S&P500114=Y167=FUT200=201309205=30207=CME231=5010=128
20130707-23:54:56.085 :
8=FIX.4.29=9635=434=4043=Y49=alpha52=20130707-23:54:56.08556=beta122=20130707-23:54:56.08536=42123=Y10=030
20130707-23:54:56.085 :
8=FIX.4.29=26735=D34=4243=Y49=alpha52=20130707-23:54:55.28856=beta57=STAGE122=20130707-23:54:17.9121=NEUTRAL11=alphaA1002315=USD21=138=2540=144=1624.554=155=/ESU359=060=20130707-23:54:1776=Neutral107=E-mini
S&P500114=Y167=FUT200=201309205=30207=CME231=5010=143
20130707-23:54:56.100 :
8=FIX.4.29=9635=434=4343=Y49=alpha52=20130707-23:54:56.08556=beta122=20130707-23:54:56.08536=44123=Y10=035
20130707-23:54:56.100 :
8=FIX.4.29=5335=534=4449=alpha52=20130707-23:54:56.10056=beta10=204
20130707-23:54:56.100 :
8=FIX.4.29=5935=249=beta56=alpha34=4852=20130707-23:54:387=3416=010=197
20130707-23:54:56.460 :
8=FIX.4.29=26735=D34=3443=Y49=alpha52=20130707-23:54:56.10056=beta57=STAGE122=20130707-23:43:41.9541=NEUTRAL11=alphaA1004315=USD21=138=2540=144=1624.554=155=/ESU359=060=20130707-23:43:4176=Neutral107=E-mini
S&P500114=Y167=FUT200=201309205=30207=CME231=5010=126
20130707-23:54:56.819 :
8=FIX.4.29=9635=434=3543=Y49=alpha52=20130707-23:54:56.81956=beta122=20130707-23:54:56.81936=36123=Y10=047
20130707-23:54:56.819 :
8=FIX.4.29=26735=D34=3643=Y49=alpha52=20130707-23:54:56.46056=beta57=STAGE122=20130707-23:48:28.9001=NEUTRAL11=alphaA1003315=USD21=138=2540=144=1624.554=155=/ESU359=060=20130707-23:48:2876=Neutral107=E-mini
S&P500114=Y167=FUT200=201309205=30207=CME231=5010=147
20130707-23:54:57.194 :
8=FIX.4.29=9635=434=3743=Y49=alpha52=20130707-23:54:57.19456=beta122=20130707-23:54:57.19436=39123=Y10=046
20130707-23:54:57.194 :
8=FIX.4.29=26735=D34=3943=Y49=alpha52=20130707-23:54:56.83556=beta57=STAGE122=20130707-23:51:22.0941=NEUTRAL11=alphaA1002315=USD21=138=2540=144=1624.554=155=/ESU359=060=20130707-23:51:2276=Neutral107=E-mini
S&P500114=Y167=FUT200=201309205=30207=CME231=5010=135
20130707-23:54:57.569 :
8=FIX.4.29=9635=434=4043=Y49=alpha52=20130707-23:54:57.56956=beta122=20130707-23:54:57.56936=42123=Y10=046
20130707-23:54:57.569 :
8=FIX.4.29=26735=D34=4243=Y49=alpha52=20130707-23:54:57.21056=beta57=STAGE122=20130707-23:54:17.9121=NEUTRAL11=alphaA1002315=USD21=138=2540=144=1624.554=155=/ESU359=060=20130707-23:54:1776=Neutral107=E-mini
S&P500114=Y167=FUT200=201309205=30207=CME231=5010=130
20130707-23:54:57.585 :
8=FIX.4.29=9635=434=4343=Y49=alpha52=20130707-23:54:57.58556=beta122=20130707-23:54:57.58536=45123=Y10=048
20130707-23:54:57.585 :
8=FIX.4.29=6635=449=beta56=alpha34=3043=Y52=20130707-23:54:38123=Y36=4910=074
20130707-23:54:57.585 :
8=FIX.4.29=4935=549=beta56=alpha34=4952=20130707-23:54:5610=023
Also, in the first case the possDupFlag (m_string and m_data values) are ""
and in the later case both are set to "Y" as seen in the message logs.
Please suggest how to fix the message seq issues or reset issues that are
arising ? Am I using the wrong implementation of possDupFlag in toAPP ? What
is the best and safest way of implementing the toAPP ? What are the issues
that are creating the problem ? Can we get rid of the possDupFlag altogather
?
Thanks,
aupadras.
--
View this message in context: http://quickfix.13857.n7.nabble.com/Incorrect-Data-Format-aka-possDupFlag-issue-tp6518.html
Sent from the QuickFIX - User mailing list archive at Nabble.com.
|
|
From: Mike G. <mg...@co...> - 2013-07-08 03:32:53
|
On Sun, Jul 7, 2013 at 8:13 PM, aupadras <ani...@ya...> wrote: > MsgSeqNum=1 > Note: this has no effect, and you should never set tag 34 yourself. > PossDupFlag=N > Note: this also has no effect, and you should never remove PossDupFlag from a message yourself. The presence of PossDupFlag means that quickfix is re-sending a message you sent previously to honor a resend request made by your counterpary. If you don't want the message to be resent, throw DoNotSend, but do not ever set/unset this field yourself. > Problem: I am able to STAGE the order, however the operations of staging is > not smooth i.e.., STAGING the order is followed by following issues (even > though tag 15 is not missing (Currency = 'USD')) the message is getting > rejected) : > Your new order single is not being rejected due to a missing tag 15. Rather, you are rejecting the execution report you are receiving in response to the new order single because the execution report does not contain tag 15. You need to set required="N" for tag 15 for execution report messages in your data dictionary, and don't try to get() that field unless you catch FieldNotFound. > 20130707-20:34:49.164 : Initiated logout request > 20130707-20:34:49.164 : Received logout response > The problem is due to possDupFlag in toAPP and after this reject message I > am getting logged out not able to enter into fromAPP logic (to retrieve > execution report info) > It looks like you are the one initiating the logout. If I delete the possDupFlag from toAPP logic then I am having following > Don't do that :) See above. > Please suggest how to fix the message seq issues or reset issues that are > arising ? Am I using the wrong implementation of possDupFlag in toAPP ? > What > is the best and safest way of implementing the toAPP ? What are the issues > that are creating the problem ? Can we get rid of the possDupFlag > altogather > ? > Start by fixing the tag 15 reject, then figure out why you are initiating that logout. Then make sure you aren't messing with PossDupFlag or MsgSeqNum directly. -- Mike Gatny Connamara Systems, LLC |
|
From: aupadras <ani...@ya...> - 2013-07-10 13:18:17
|
Hi Mike, Please address the following: I am using following piece of code and worried that initiator.stop() is initiating the log -out. I have StartTime=00:01:00 and EndTime=23:55:00 in the config file. How can my application continuously communicate with my counter-party without logging out i..,e Do I need to delete initiator.stop or is there any safe mechanism to handle this like initiator to be stopped when clock Time == EndTime? Or Am I completely out of whack. initiator.start(); application.run(); initiator.stop(); Please give me insight, when an initiator should be stopped after a new single order is being placed ? Is initiator stopped automatically when the FIX messages are not exchanged between me and counter-party after I complete the execution of the order that I placed ? In addition to the above, sometimes I under-go fatal problems like... socket initiator error,resend request issues and msgseqno mis-match (msg seq no is too low or too high) etc.., with my counter-party. In those cases, I am asking my counter-party to reset the seqno. However, once we go live and real time this is not the best option. Please suggest the best ways to design the robust system. My Config settings are : ResetOnDisconnect=N CheckLatency=N ResetOnLogon=N ResetOnLogout=N SendResetSeqNumFlag=N RefreshOnLogon=Y PersistMessages=Y MillisecondsInTimeStamp=Y UseDataDictionary=Y Also, I am implementing try-catch mechanism in setting and getting the field information defined in data-dictionary. Currently, I see sendtoTarget ---> toApp() --- > fromAPP() ---> onMessage() is the flow I am expecting. I assume, as I throw the reject message the flow is stopping after toAPP(). Is this correct ? Finally, We would like to create a DC session (Only for listening purposes). I am using the trade-client example and I am not sending the message to the target, but I re-created the message that has been staged and trying to listen the fill backs using onMessage(ExecutionReport, SessionID) in application.run(). Is this a proper way to implement (DC session) just for listening ? Please Advise. Thanks, Anil. ________________________________ From: Mike Gatny [via QuickFIX] <ml-...@n7...> To: aupadras <ani...@ya...> Sent: Sunday, July 7, 2013 10:35 PM Subject: Re: Incorrect Data Format aka possDupFlag issue QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html On Sun, Jul 7, 2013 at 8:13 PM, aupadras <[hidden email]> wrote: MsgSeqNum=1 > Note: this has no effect, and you should never set tag 34 yourself. PossDupFlag=N > Note: this also has no effect, and you should never remove PossDupFlag from a message yourself. The presence of PossDupFlag means that quickfix is re-sending a message you sent previously to honor a resend request made by your counterpary. If you don't want the message to be resent, throw DoNotSend, but do not ever set/unset this field yourself. Problem: I am able to STAGE the order, however the operations of staging is >not smooth i.e.., STAGING the order is followed by following issues (even >though tag 15 is not missing (Currency = 'USD')) the message is getting >rejected) : > Your new order single is not being rejected due to a missing tag 15. Rather, you are rejecting the execution report you are receiving in response to the new order single because the execution report does not contain tag 15. You need to set required="N" for tag 15 for execution report messages in your data dictionary, and don't try to get() that field unless you catch FieldNotFound. 20130707-20:34:49.164 : Initiated logout request >20130707-20:34:49.164 : Received logout response >The problem is due to possDupFlag in toAPP and after this reject message I >am getting logged out not able to enter into fromAPP logic (to retrieve >execution report info) > It looks like you are the one initiating the logout. If I delete the possDupFlag from toAPP logic then I am having following > Don't do that :) See above. Please suggest how to fix the message seq issues or reset issues that are >arising ? Am I using the wrong implementation of possDupFlag in toAPP ? What >is the best and safest way of implementing the toAPP ? What are the issues >that are creating the problem ? Can we get rid of the possDupFlag altogather >? > Start by fixing the tag 15 reject, then figure out why you are initiating that logout. Then make sure you aren't messing with PossDupFlag or MsgSeqNum directly. -- Mike Gatny Connamara Systems, LLC ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Quickfix-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quickfix-users ________________________________ If you reply to this email, your message will be added to the discussion below:http://quickfix.13857.n7.nabble.com/Incorrect-Data-Format-aka-possDupFlag-issue-tp6518p6519.html To unsubscribe from Incorrect Data Format aka possDupFlag issue, click here. NAML -- View this message in context: http://quickfix.13857.n7.nabble.com/Incorrect-Data-Format-aka-possDupFlag-issue-tp6518p6521.html Sent from the QuickFIX - User mailing list archive at Nabble.com. |
|
From: aupadras <ani...@ya...> - 2013-07-09 07:45:30
|
Hi,
I contacted my counter-party to match my msg type '8' data dictionary
settings.., so hopefully I will not reject their messages. I assume this
will fix the problem.
I am using following piece of code and worried that initiator.stop() is
initiating the log -out. I have StartTime=00:01:00 and EndTime=23:55:00 in
the config file. How can my application continuously communicate with my
counter-party without logging out i..,e Do I need to delete initiator.stop
or is there any safe mechanism to handle this like initiator to be stopped
when clock Time == EndTime? Or Am I completely out of whack.
initiator.start();
application.run();
initiator.stop();
return 0;
In addition to the above, sometimes I under-go fatal problems like... socket
initiator error,resend request issues and msgseqno mis-match (msg seq no is
too low or too high) etc.., with my counter-party. In those cases, I am
asking my counter-party to reset the seqno. However, once we go live and
real time this is not the best option. Please suggest the best ways to
design the robust system.
My Config settings are :
ResetOnDisconnect=N
CheckLatency=N
ResetOnLogon=N
ResetOnLogout=N
SendResetSeqNumFlag=N
RefreshOnLogon=Y
PersistMessages=Y
MillisecondsInTimeStamp=Y
UseDataDictionary=Y
Also, I am implementing try-catch mechanism in setting and getting the field
information defined in data-dictionary.
Finally, I don't recall of seeing the print statement outputs in onMessage
or fromAPP block. I do see some action from toAPP (when message is sent to
target), but never seen from fromAPP or onMessages. Do I need to call
fromAPP and onMessages(Execution Reports) in my application whereas toAPP is
called by default by QF when message is being sent to target ???
Please Advise.
Thanks,
aupadras.
--
View this message in context: http://quickfix.13857.n7.nabble.com/Incorrect-Data-Format-aka-possDupFlag-issue-tp6518p6520.html
Sent from the QuickFIX - User mailing list archive at Nabble.com.
|
|
From: Mike G. <mg...@co...> - 2013-07-10 16:32:49
|
On Tue, Jul 9, 2013 at 2:45 AM, aupadras <ani...@ya...> wrote: > initiator.start(); > application.run(); > initiator.stop(); > As soon as application.run() returns, initiator.stop() is going to be called. Does application.run() loop forever? It probably should if you want this to work correctly. Finally, I don't recall of seeing the print statement outputs in onMessage > or fromAPP block. I do see some action from toAPP (when message is sent to > target), but never seen from fromAPP or onMessages. Do I need to call > fromAPP and onMessages(Execution Reports) in my application whereas toAPP > is > called by default by QF when message is being sent to target ??? > Quickfix invokes fromApp, toApp, toAdmin, and fromAdmin. You should not call those yourself. Quickfix does not call the onMessage() callbacks -- those are there for convenience, and if you want to use them you have to call crack() during fromApp(). If you have not done so, please look at the example applications that are included with the Quickfix source code. They demonstrate the correct way to do most of what you are asking about. And if you haven't read the docs on the site yet, they also address this: http://quickfixengine.org/quickfix/doc/html/application.html http://quickfixengine.org/quickfix/doc/html/receiving_messages.html -- Mike Gatny Connamara Systems, LLC |
|
From: aupadras <ani...@ya...> - 2013-07-10 18:03:23
|
Hi Mike, Ok.., I didn't loop through the application.run(). The code I was using simply: initiator.start(); application.run(); initiator.stop(); and the application.run() has all the elements that you suggested me to follow using the examples (toApp, fromApp, toAdmin, fromAdmin with message cracker) and I also ensured that getting and setting fields using the type safe ways. My other question..., is how to create a DC (execution reports) without staging the order using Quick FIX ? i.e.., how to use Quick FIX for only listening purposes (without sending the actual message to Target) ? Is this possible, if so how ? Thanks, aupadras. -- View this message in context: http://quickfix.13857.n7.nabble.com/Incorrect-Data-Format-aka-possDupFlag-issue-tp6518p6523.html Sent from the QuickFIX - User mailing list archive at Nabble.com. |
|
From: Mike G. <mg...@co...> - 2013-07-10 18:22:16
|
> > On Wed, Jul 10, 2013 at 1:03 PM, aupadras <ani...@ya...> wrote: > My other question..., is how to create a DC (execution reports) without > staging the order using Quick FIX ? i.e.., how to use Quick FIX for only > listening purposes (without sending the actual message to Target) ? Is this > possible, if so how ? If your counterparty supports sending drop copies in the form of ExecutionReports, your drop copy client will be essentially the same as your app that sends NewOrderSingles. I.e. you will implement the onMessage() callback for ExecutionReports and process them when they arrive. But first you need to find out if your counterparty supports drop copy. If they do, they will set up a separate Session for this purpose. You cannot simply connect another Initiator app to the same FIX Session. -- Mike Gatny Connamara Systems, LLC |
|
From: aupadras <ani...@ya...> - 2013-07-10 18:51:37
|
Hi, Yes, they did provided me a drop copy session and AFT session. I am using an AFT session for staging the order. Now my question is regarding the Drop Copy Session what would be the flow look like ? generate new single order message() --> send to Target (toApp()) --> fromApp() ---> onMessage(Execution Report) or generate new single order message() --> fromApp() ---> onMessage(Execution Report). Question is does fromApp() is called if I skip the toApp() or (SendToTarget()) ? Please suggest the better flow using QF for Drop Copy Session (just for listening). Thanks, aupadras. -- View this message in context: http://quickfix.13857.n7.nabble.com/Incorrect-Data-Format-aka-possDupFlag-issue-tp6518p6525.html Sent from the QuickFIX - User mailing list archive at Nabble.com. |
|
From: Mike G. <mg...@co...> - 2013-07-10 19:25:25
|
On Wed, Jul 10, 2013 at 1:51 PM, aupadras <ani...@ya...> wrote: > Now my question is regarding the Drop Copy Session what would be the flow > look like ? > > generate new single order message() --> send to Target (toApp()) --> > fromApp() ---> onMessage(Execution Report) > The flow you have described here is what the flow will look like in the app that actually sends the order. In the drop copy app, the perceived flow is just: fromApp() -> onMessage(Execution Report) -- Mike Gatny Connamara Systems, LLC |
|
From: aupadras <ani...@ya...> - 2013-07-13 15:01:43
|
Hi Mike, Thanks for your responses. I accomplished the DC session, i.e., send and respond to the administrative messages and listening drop copies from counter party. Initially, the problem sounded like DC session should be re-created as NewOrderSingle without sending the messages. But actually I just need to worry about the session and heart-beats (administrative stuff), Quick FIX inherently takes care of receiving the execution report and fills from the counter-party via fromApp() - > onMessage(ExecutionReport). Thanks, aupadras. -- View this message in context: http://quickfix.13857.n7.nabble.com/Incorrect-Data-Format-aka-possDupFlag-issue-tp6518p6530.html Sent from the QuickFIX - User mailing list archive at Nabble.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