[Quickfix-users] Incorrect Data Format aka possDupFlag issue

[aupadras <ani...@ya...>]

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.