Quantcast

Valid resend requests rejected by QuickFIX library

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Valid resend requests rejected by QuickFIX library

Gunnar Harms
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/

Hello,

We have some problems where our FIX server (an acceptor) sometimes
rejects perfectly valid resend request messages from our clients.
In the event log we then see for example:

20140225-08:04:51.589 : Received ResendRequest FROM: 3356 TO: 3374
20140225-08:04:51.589 : Invalid message: Header fields out of order

(or it can complain about no SOH at the end. In any way QuickFIX is
wrong because the messages that we receive are valid 35=2 messages)

We use the C++ QuickFIX library.
The issue is not easily reproducible and happens rarely, twice a month
or so. If it happens we restart our FIX server and from then it accepts
the exact same resend requests again.
I know I have not provided much information in this email, but am just
hoping someone recognizes the issue.


Regards,
Gunnar



------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Quickfix-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Valid resend requests rejected by QuickFIX library

Gunnar Harms
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/


Hi Eugene,

Thank you for responding! Indeed the clients always logon with sequence reset false. For example this day:

--
20141219-05:51:27.298 : Received logon request
20141219-05:51:27.298 : info: HiQExchangeHandler::reset seqReset=false
20141219-05:51:27.298 : Responding to logon request
20141219-05:51:29.057 : Received ResendRequest FROM: 1 TO: 3
20141219-05:51:29.057 : Invalid message: Header fields out of order
--

And the "offending" message was:

20141219-05:51:29.057 : 8=FIX.4.2|9=58|35=2|49=HIQ1|56=HIQFIX|52=20141219-05:51:29|34=3|7=1|16=3|10=113


I  have some more info. This client always tries to logon a first time much earlier and then we send them a logout message and disconnect their session. Perhaps we don't that the correct way and the session is not in a healthy state after this.
The bold lines below illustrate how we disconnect them. Maybe someone knows if this is the correct way to disconnect a client. Perhaps the call to disconnect() is not needed and sending a logout message is enough? Or perhaps we need to call yet another method on their session (MFIXSession) after calling disconnect().

bool HiQExchangeHandler::logoutAndDisconnectFIX(const FIX::Text& text) {
    try {
        if (MFIXSession != NULL) {
            if (MFIXSession->receivedLogon()) {
                FIX42::Logout message;

                message.set(text);
                FIX::Session::sendToTarget(message, MFIXSessionID);
            }
            MFIXSession->disconnect();
            return true;
        }
        else {
            logError("HiQSession::logoutAndDisconnectFIX: MFIXSession == NULL");
        }
    }
    catch (...) {
        logError("HiQSession::logoutAndDisconnectFIX caught unidentified exception");
    }
    return false;
}


Strange thing is of course that it happens so rarely.


Thanks a lot!
Gunnar
Gunnar Harms

T +31 (0)20 53 53 487
F +31 (0)20 42 08 852
I www.hiqinvest.nl

HiQ Invest
Herengracht 442 
1017 BZ Amsterdam
On 12/19/2014 04:39 PM, Eugene Krel wrote:
Hi Gunnar,

I have seen this issue as well. It commonly happens when we reset sequence numbers for the day and an incoming session comes in with sequence numbers from the previous day. The two sessions logn on/off and then the incoming session logs off. They later log on for the new day with reset sequence numbers and eventually leads to the exact resend request scenario.

I have not had time to look for a solution in the code, but having both sides reset the sequence numbers at appropriate times and logon as 1-1 for the new day addresses it.

Hope this helps.

Regards,

-
Eugene Krel - 646-293-1805 - Quantitative Brokers

On Fri, Dec 19, 2014 at 10:02 AM, gunnar <[hidden email]> wrote:
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/

Hello,

We have some problems where our FIX server (an acceptor) sometimes
rejects perfectly valid resend request messages from our clients.
In the event log we then see for example:

<a moz-do-not-send="true" href="tel:20140225-08" value="+12014022508">20140225-08:04:51.589 : Received ResendRequest FROM: 3356 TO: 3374
<a moz-do-not-send="true" href="tel:20140225-08" value="+12014022508">20140225-08:04:51.589 : Invalid message: Header fields out of order

(or it can complain about no SOH at the end. In any way QuickFIX is
wrong because the messages that we receive are valid 35=2 messages)

We use the C++ QuickFIX library.
The issue is not easily reproducible and happens rarely, twice a month
or so. If it happens we restart our FIX server and from then it accepts
the exact same resend requests again.
I know I have not provided much information in this email, but am just
hoping someone recognizes the issue.


Regards,
Gunnar



------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Quickfix-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

CONFIDENTIALITY NOTICE: This e-mail and any attachments are for the exclusive 
and confidential use of the recipient(s) who we intend for institutional 
customers as opposed to retail customers and may constitute non-public information.
If you received this e-mail in error, disclosing, copying, distributing or taking 
any action in reliance of this e-mail is strictly prohibited and may be unlawful.
Instead, please notify us immediately by return e-mail and promptly delete this 
message and its attachments from your computer system as we do not waive any work 
product or other applicable legal privilege(s) by the transmission of this message. 
NOTE: The information in this e-mail does not constitute trading advice.


      


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Quickfix-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
Loading...