SendingTime accuracy problem

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

SendingTime accuracy problem

Nikita Nemade
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Hi,

I have a quickfix client running on one server and quickfix server running on another server.
When there are lot of messages exchange between them, quickfix client gets disconnected from quickfix server with following error:
Reject sent for Message 25: SendingTime accuracy problem
Already disconnected: Verifying message failed: quickfix.SessionException: Logon state is not valid for message (MsgType=8)
quickfix.SessionException Logon state is not valid for message (MsgType=8)

Can anyone please throw some light on this.
Also any idea about how to fix this?

Regards,

Nikita Nemade
Senior Software Engineer


-----------------------------------------------------------------------------------------------------------------------------------------
Indus Valley Partners | Unit- 153/154 | 2nd Floor | SDF- 5 | SEEPZ SEZ | Andheri (E) | Mumbai 400096.
Email ID: nnemade@ivp.in  Websitewww.ivp.in | Sype: ivp.nnemade

Disclaimer: 
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individuals or entities addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Indus Valley Partners (India) Pvt. Ltd. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this mail is strictly prohibited.

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SendingTime accuracy problem

Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

I take it that the time on both machines is in sync? If yes, then it seems that your application
takes too long processing the messages. Could you maybe send the log output when the first message
is processed and when the session disconnects?

In general you should aim to do as little processing in the application callbacks as possible.
Ideally, put the received message on a queue and process them on a separate thread.

Regards,
Chris.


On 25/10/16 12:23, Nikita Nemade wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
> Hi,
>
> I have a quickfix client running on one server and quickfix server running on another server.
> When there are lot of messages exchange between them, quickfix client gets disconnected from
> quickfix server with following error:
> Reject sent for Message 25: SendingTime accuracy problem
> Already disconnected: Verifying message failed: quickfix.SessionException: Logon state is not
> valid for message (MsgType=8)
> quickfix.SessionException Logon state is not valid for message (MsgType=8)
>
> Can anyone please throw some light on this.
> Also any idea about how to fix this?
>
> *Regards,*
> *Nikita Nemade*
> *Senior Software Engineer
>
> **
> *
> *-----------------------------------------------------------------------------------------------------------------------------------------*
> Indus Valley Partners | Unit- 153/154 | 2nd Floor | SDF- 5 | SEEPZ SEZ | Andheri (E) | Mumbai 400096.
> Email ID: nnemade <http://goog_188482322>@ivp.in <http://@ivp.in> | Website: www.ivp.in
> <http://www.ivp.in> | Sype: ivp.nnemade
>
> Disclaimer:
> This e-mail and any files transmitted with it are confidential and intended solely for the use of
> the individuals or entities addressed. Any views or opinions presented are solely those of the
> author and do not necessarily represent those of Indus Valley Partners (India) Pvt. Ltd. If you
> are not the intended recipient, be advised that you have received this email in error and that any
> use, dissemination, forwarding, printing or copying of this mail is strictly prohibited.
>
>
> ------------------------------------------------------------------------------
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
>
>
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:[hidden email]
       


http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SendingTime accuracy problem

Robert Engels-2
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Just be aware that if you do that, you need to add all sorts of logic to ensure transactional consistency, because when you add to a queue and return the fix session layer is going to advance the sequence number.

> On Oct 25, 2016, at 7:12 AM, Christoph John <[hidden email]> wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> I take it that the time on both machines is in sync? If yes, then it seems that your application
> takes too long processing the messages. Could you maybe send the log output when the first message
> is processed and when the session disconnects?
>
> In general you should aim to do as little processing in the application callbacks as possible.
> Ideally, put the received message on a queue and process them on a separate thread.
>
> Regards,
> Chris.
>
>
>> On 25/10/16 12:23, Nikita Nemade wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>>
>>
>> Hi,
>>
>> I have a quickfix client running on one server and quickfix server running on another server.
>> When there are lot of messages exchange between them, quickfix client gets disconnected from
>> quickfix server with following error:
>> Reject sent for Message 25: SendingTime accuracy problem
>> Already disconnected: Verifying message failed: quickfix.SessionException: Logon state is not
>> valid for message (MsgType=8)
>> quickfix.SessionException Logon state is not valid for message (MsgType=8)
>>
>> Can anyone please throw some light on this.
>> Also any idea about how to fix this?
>>
>> *Regards,*
>> *Nikita Nemade*
>> *Senior Software Engineer
>>
>> **
>> *
>> *-----------------------------------------------------------------------------------------------------------------------------------------*
>> Indus Valley Partners | Unit- 153/154 | 2nd Floor | SDF- 5 | SEEPZ SEZ | Andheri (E) | Mumbai 400096.
>> Email ID: nnemade <http://goog_188482322>@ivp.in <http://@ivp.in> | Website: www.ivp.in
>> <http://www.ivp.in> | Sype: ivp.nnemade
>>
>> Disclaimer:
>> This e-mail and any files transmitted with it are confidential and intended solely for the use of
>> the individuals or entities addressed. Any views or opinions presented are solely those of the
>> author and do not necessarily represent those of Indus Valley Partners (India) Pvt. Ltd. If you
>> are not the intended recipient, be advised that you have received this email in error and that any
>> use, dissemination, forwarding, printing or copying of this mail is strictly prohibited.
>>
>>
>> ------------------------------------------------------------------------------
>> The Command Line: Reinvented for Modern Developers
>> Did the resurgence of CLI tooling catch you by surprise?
>> Reconnect with the command line and become more productive.
>> Learn the new .NET and ASP.NET CLI. Get your free copy!
>> http://sdm.link/telerik
>>
>>
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
> --
> Christoph John
> Development & Support
> Direct: +49 241 557080-28
> Mailto:[hidden email]
>    
>
>
> http://www.macd.com <http://www.macd.com/>
> ----------------------------------------------------------------------------------------------------
>    
> ----------------------------------------------------------------------------------------------------
> MACD GmbH
> Oppenhoffallee 103
> D-52066 Aachen
> Tel: +49 241 557080-0 | Fax: +49 241 557080-10
>     Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
>
> Geschäftsführer: George Macdonald
> ----------------------------------------------------------------------------------------------------
>    
> ----------------------------------------------------------------------------------------------------
>
> take care of the environment - print only if necessary
>
> ------------------------------------------------------------------------------
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SendingTime accuracy problem

Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Of course it needs some additional thought.
But IMHO when the message reaches the application callback then validation on session level was successful. So I see no drawback in handling the message on the application level and answer with a specific rejection message. E.g. ExecReport.REJECTED or BusinessMessageReject as last resort.

Best regards,
Chris.


On 25/10/16 14:55, Robert Engels wrote:
Just be aware that if you do that, you need to add all sorts of logic to ensure transactional consistency, because when you add to a queue and return the fix session layer is going to advance the sequence number.

On Oct 25, 2016, at 7:12 AM, Christoph John [hidden email] wrote:

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

I take it that the time on both machines is in sync? If yes, then it seems that your application 
takes too long processing the messages. Could you maybe send the log output when the first message 
is processed and when the session disconnects?

In general you should aim to do as little processing in the application callbacks as possible. 
Ideally, put the received message on a queue and process them on a separate thread.

Regards,
Chris.


On 25/10/16 12:23, Nikita Nemade wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




Hi,

I have a quickfix client running on one server and quickfix server running on another server.
When there are lot of messages exchange between them, quickfix client gets disconnected from 
quickfix server with following error:
Reject sent for Message 25: SendingTime accuracy problem
Already disconnected: Verifying message failed: quickfix.SessionException: Logon state is not 
valid for message (MsgType=8)
quickfix.SessionException Logon state is not valid for message (MsgType=8)

Can anyone please throw some light on this.
Also any idea about how to fix this?

*Regards,*
*Nikita Nemade*
*Senior Software Engineer

**
*
*-----------------------------------------------------------------------------------------------------------------------------------------*
Indus Valley Partners | Unit- 153/154 | 2nd Floor | SDF- 5 | SEEPZ SEZ | Andheri (E) | Mumbai 400096.
Email ID: nnemade <http://goog_188482322>@ivp.in <http://@ivp.in> | Website: www.ivp.in 
<http://www.ivp.in> | Sype: ivp.nnemade

Disclaimer:
This e-mail and any files transmitted with it are confidential and intended solely for the use of 
the individuals or entities addressed. Any views or opinions presented are solely those of the 
author and do not necessarily represent those of Indus Valley Partners (India) Pvt. Ltd. If you 
are not the intended recipient, be advised that you have received this email in error and that any 
use, dissemination, forwarding, printing or copying of this mail is strictly prohibited.


------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik


_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
-- 
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:Christoph.John@...
   


http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
   
----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
    Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
   
----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:Christoph.John@...



http://www.macd.com


MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
 Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald


take care of the environment - print only if necessary

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SendingTime accuracy problem

Robert Engels-2
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



I was only pointing it out because the party is clearly new to quickfix/fix and I've seen a lot of systems that break down, or become very complex because the designer doesn't understand the implications of the sequence number. 

On Oct 25, 2016, at 8:06 AM, Christoph John <[hidden email]> wrote:

Of course it needs some additional thought.
But IMHO when the message reaches the application callback then validation on session level was successful. So I see no drawback in handling the message on the application level and answer with a specific rejection message. E.g. ExecReport.REJECTED or BusinessMessageReject as last resort.

Best regards,
Chris.


On 25/10/16 14:55, Robert Engels wrote:
Just be aware that if you do that, you need to add all sorts of logic to ensure transactional consistency, because when you add to a queue and return the fix session layer is going to advance the sequence number.

On Oct 25, 2016, at 7:12 AM, Christoph John [hidden email] wrote:

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

I take it that the time on both machines is in sync? If yes, then it seems that your application 
takes too long processing the messages. Could you maybe send the log output when the first message 
is processed and when the session disconnects?

In general you should aim to do as little processing in the application callbacks as possible. 
Ideally, put the received message on a queue and process them on a separate thread.

Regards,
Chris.


On 25/10/16 12:23, Nikita Nemade wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




Hi,

I have a quickfix client running on one server and quickfix server running on another server.
When there are lot of messages exchange between them, quickfix client gets disconnected from 
quickfix server with following error:
Reject sent for Message 25: SendingTime accuracy problem
Already disconnected: Verifying message failed: quickfix.SessionException: Logon state is not 
valid for message (MsgType=8)
quickfix.SessionException Logon state is not valid for message (MsgType=8)

Can anyone please throw some light on this.
Also any idea about how to fix this?

*Regards,*
*Nikita Nemade*
*Senior Software Engineer

**
*
*-----------------------------------------------------------------------------------------------------------------------------------------*
Indus Valley Partners | Unit- 153/154 | 2nd Floor | SDF- 5 | SEEPZ SEZ | Andheri (E) | Mumbai 400096.
Email ID: nnemade <http://goog_188482322>@ivp.in <http://@ivp.in> | Website: www.ivp.in 
<http://www.ivp.in> | Sype: ivp.nnemade

Disclaimer:
This e-mail and any files transmitted with it are confidential and intended solely for the use of 
the individuals or entities addressed. Any views or opinions presented are solely those of the 
author and do not necessarily represent those of Indus Valley Partners (India) Pvt. Ltd. If you 
are not the intended recipient, be advised that you have received this email in error and that any 
use, dissemination, forwarding, printing or copying of this mail is strictly prohibited.


------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik


_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
-- 
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:Christoph.John@...
   


http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
   
----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
    Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
   
----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:Christoph.John@...



http://www.macd.com


MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
 Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald


take care of the environment - print only if necessary

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SendingTime accuracy problem

Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



OK, understood. :) Thanks for the pointer.


On 25/10/16 15:18, Robert Engels wrote:
I was only pointing it out because the party is clearly new to quickfix/fix and I've seen a lot of systems that break down, or become very complex because the designer doesn't understand the implications of the sequence number. 

On Oct 25, 2016, at 8:06 AM, Christoph John <[hidden email]> wrote:

Of course it needs some additional thought.
But IMHO when the message reaches the application callback then validation on session level was successful. So I see no drawback in handling the message on the application level and answer with a specific rejection message. E.g. ExecReport.REJECTED or BusinessMessageReject as last resort.

Best regards,
Chris.


On 25/10/16 14:55, Robert Engels wrote:
Just be aware that if you do that, you need to add all sorts of logic to ensure transactional consistency, because when you add to a queue and return the fix session layer is going to advance the sequence number.

On Oct 25, 2016, at 7:12 AM, Christoph John [hidden email] wrote:

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

I take it that the time on both machines is in sync? If yes, then it seems that your application 
takes too long processing the messages. Could you maybe send the log output when the first message 
is processed and when the session disconnects?

In general you should aim to do as little processing in the application callbacks as possible. 
Ideally, put the received message on a queue and process them on a separate thread.

Regards,
Chris.


On 25/10/16 12:23, Nikita Nemade wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




Hi,

I have a quickfix client running on one server and quickfix server running on another server.
When there are lot of messages exchange between them, quickfix client gets disconnected from 
quickfix server with following error:
Reject sent for Message 25: SendingTime accuracy problem
Already disconnected: Verifying message failed: quickfix.SessionException: Logon state is not 
valid for message (MsgType=8)
quickfix.SessionException Logon state is not valid for message (MsgType=8)

Can anyone please throw some light on this.
Also any idea about how to fix this?

*Regards,*
*Nikita Nemade*
*Senior Software Engineer

**
*
*-----------------------------------------------------------------------------------------------------------------------------------------*
Indus Valley Partners | Unit- 153/154 | 2nd Floor | SDF- 5 | SEEPZ SEZ | Andheri (E) | Mumbai 400096.
Email ID: nnemade <http://goog_188482322>@ivp.in <http://@ivp.in> | Website: www.ivp.in 
<http://www.ivp.in> | Sype: ivp.nnemade

Disclaimer:
This e-mail and any files transmitted with it are confidential and intended solely for the use of 
the individuals or entities addressed. Any views or opinions presented are solely those of the 
author and do not necessarily represent those of Indus Valley Partners (India) Pvt. Ltd. If you 
are not the intended recipient, be advised that you have received this email in error and that any 
use, dissemination, forwarding, printing or copying of this mail is strictly prohibited.


------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik


_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
-- 
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:Christoph.John@...
   


http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
   
----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
    Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
   
----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:Christoph.John@...



http://www.macd.com


MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
 Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald


take care of the environment - print only if necessary

--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:Christoph.John@...



http://www.macd.com


MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
 Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald


take care of the environment - print only if necessary

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

InvalidMessage exception

Daniil Sosonkin-2
In reply to this post by Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi -

I've encountered an interesting problem today. A message was received
with invalid checksum (that resulted from special character in Text
field, but that's internal problem). QFJ being correct has validated the
checksum, concluded it to be wrong and threw an exception:

[NioProcessor-47] ERROR quickfix.mina.initiator.InitiatorIoHandler -
Invalid message: Expected CheckSum=52, Received CheckSum=19 in
8=FIX.4.2.......

Up to this, behavior is as expected. However, QFJ has stopped processing
any subsequent FIX messages it received. This behavior is not something
I've expected. Is this done by design? If so, what are the steps to be
taken in order to continue processing messages after such error. If not
by design, please let me know so we can patch this.

Thank you,
Daniil

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: InvalidMessage exception

Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Hi,
which version of QFJ are you using?
What were the subsequent messages? Maybe there was an endless resend loop, i.e. your side rejected the messages because of the checksum error (this means that the incoming seq num is not incremented), on the next incoming msg there was a seq num mismatch and a resend which redelivered the faulty message again and so on and so on...
Do you have some log output?

Regards,
Chris.

Am 25. Oktober 2016 16:52:38 MESZ, schrieb Daniil Sosonkin <[hidden email]>:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi -

I've encountered an interesting problem today. A message was received
with invalid checksum (that resulted from special character in Text
field, but that's internal problem). QFJ being correct has validated the
checksum, concluded it to be wrong and threw an exception:

[NioProcessor-47] ERROR quickfix.mina.initiator.InitiatorIoHandler -
Invalid message: Expected CheckSum=52, Received CheckSum=19 in
8=FIX.4.2.......

Up to this, behavior is as expected. However, QFJ has stopped processing
any subsequent FIX messages it received. This behavior is not something
I've expected. Is this done by design? If so, what are the steps to be
taken in order to continue processing messages after such error. If not
by design, please let me know so we can patch this.

Thank you,
Daniil



The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik


Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: InvalidMessage exception

Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Actually, by default QFJ does not reject msgs with invalid checksum but just does not increment the incoming seq num.

Am 25. Oktober 2016 22:07:06 MESZ, schrieb Christoph John <[hidden email]>:
Hi,
which version of QFJ are you using?
What were the subsequent messages? Maybe there was an endless resend loop, i.e. your side rejected the messages because of the checksum error (this means that the incoming seq num is not incremented), on the next incoming msg there was a seq num mismatch and a resend which redelivered the faulty message again and so on and so on...
Do you have some log output?

Regards,
Chris.

Am 25. Oktober 2016 16:52:38 MESZ, schrieb Daniil Sosonkin <[hidden email]>:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi -

I've encountered an interesting problem today. A message was received
with invalid checksum (that resulted from special character in Text
field, but that's internal problem). QFJ being correct has validated the
checksum, concluded it to be wrong and threw an exception:

[NioProcessor-47] ERROR quickfix.mina.initiator.InitiatorIoHandler -
Invalid message: Expected CheckSum=52, Received CheckSum=19 in
8=FIX.4.2.......

Up to this, behavior is as expected. However, QFJ has stopped processing
any subsequent FIX messages it received. This behavior is not something
I've expected. Is this done by design? If so, what are the steps to be
taken in order to continue processing messages after such error. If not
by design, please let me know so we can patch this.

Thank you,
Daniil



The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik


Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: InvalidMessage exception

Daniil Sosonkin-2
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Chris -

There was no rejection from the receiving end. The log entry below was the only indication of the problem. QFJ continued to receive execution reports, writing them to the logs, but none we received by the Application. I didn't pay attention to sequence numbers at the time (it was a bit stressful as you can guess).

We've restarted client side several times. Upon each restart, it performed a resend request from message that caused the problem.

Let me know which logs would be helpful. I'm trying to dig into the code to see how QFJ is handling such exception exactly (no luck yet). It seems I'm using QFJ 1.7.0-SNAPSHOT (I've forked on GitHub, but so far haven't figured out whole versioning yet).

Thank you for your help!

On 10/25/2016 4:10 PM, Christoph John wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




Actually, by default QFJ does not reject msgs with invalid checksum but just does not increment the incoming seq num.

Am 25. Oktober 2016 22:07:06 MESZ, schrieb Christoph John [hidden email]:
Hi,
which version of QFJ are you using?
What were the subsequent messages? Maybe there was an endless resend loop, i.e. your side rejected the messages because of the checksum error (this means that the incoming seq num is not incremented), on the next incoming msg there was a seq num mismatch and a resend which redelivered the faulty message again and so on and so on...
Do you have some log output?

Regards,
Chris.

Am 25. Oktober 2016 16:52:38 MESZ, schrieb Daniil Sosonkin [hidden email]:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi -

I've encountered an interesting problem today. A message was received 
with invalid checksum (that resulted from special character in Text 
field, but that's internal problem). QFJ being correct has validated the 
checksum, concluded it to be wrong and threw an exception:

[NioProcessor-47] ERROR quickfix.mina.initiator.InitiatorIoHandler - 
Invalid message: Expected CheckSum=52, Received CheckSum=19 in 
8=FIX.4.2.......

Up to this, behavior is as expected. However, QFJ has stopped processing 
any subsequent FIX messages it received. This behavior is not something 
I've expected. Is this done by design? If so, what are the steps to be 
taken in order
to continue processing messages after such error. If not 
by design, please let me know so we can patch this.

Thank you,
Daniil


The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik
Quickfixj-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: InvalidMessage exception

Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi Daniil,

yes, that sounds like the scenario I was describing in my first mail. QFJ does not increment the
sequence number on checksum errors. This is in line with the FIX protocol which takes an optimistic
approach and considers the checksum error a transient transmission error that corrects itself with
the next transmission. But the problem did not correct itself since the same erroneous message got
retransmitted over and over.

One way out of this is to set the incoming sequence number on your side and the outgoing seqnum of
the counterparty to be one higher than the problematic message. Maybe the counterparty has other
means to skip the problematic message, e.g. sending a gap fill instead or removing the problematic
message from its message store.

To temporarily get around this you could also check if setting ValidateIncomingMessage and
UseDataDictionary to N will correct it.

Cheers,
Chris.


On 25/10/16 22:25, Daniil Sosonkin wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
> Chris -
>
> There was no rejection from the receiving end. The log entry below was the only indication of the
> problem. QFJ continued to receive execution reports, writing them to the logs, but none we
> received by the Application. I didn't pay attention to sequence numbers at the time (it was a bit
> stressful as you can guess).
>
> We've restarted client side several times. Upon each restart, it performed a resend request from
> message that caused the problem.
>
> Let me know which logs would be helpful. I'm trying to dig into the code to see how QFJ is
> handling such exception exactly (no luck yet). It seems I'm using QFJ 1.7.0-SNAPSHOT (I've forked
> on GitHub, but so far haven't figured out whole versioning yet).
>
> Thank you for your help!
>
> On 10/25/2016 4:10 PM, Christoph John wrote:
>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>>
>> Actually, by default QFJ does not reject msgs with invalid checksum but just does not increment
>> the incoming seq num.
>>
>> Am 25. Oktober 2016 22:07:06 MESZ, schrieb Christoph John <[hidden email]>:
>>
>>     Hi,
>>     which version of QFJ are you using?
>>     What were the subsequent messages? Maybe there was an endless resend loop, i.e. your side
>>     rejected the messages because of the checksum error (this means that the incoming seq num is
>>     not incremented), on the next incoming msg there was a seq num mismatch and a resend which
>>     redelivered the faulty message again and so on and so on...
>>     Do you have some log output?
>>
>>     Regards,
>>     Chris.
>>
>>     Am 25. Oktober 2016 16:52:38 MESZ, schrieb Daniil Sosonkin <[hidden email]>:
>>
>>         QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>         QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>         Hi -
>>
>>         I've encountered an interesting problem today. A message was received
>>         with invalid checksum (that resulted from special character in Text
>>         field, but that's internal problem). QFJ being correct has validated the
>>         checksum, concluded it to be wrong and threw an exception:
>>
>>         [NioProcessor-47] ERROR quickfix.mina.initiator.InitiatorIoHandler -
>>         Invalid message: Expected CheckSum=52, Received CheckSum=19 in
>>         8=FIX.4.2.......
>>
>>         Up to this, behavior is as expected. However, QFJ has stopped processing
>>         any subsequent FIX messages it received. This behavior is not something
>>         I've expected. Is this done by design? If so, what are the steps to be
>>         taken in order
>>         to continue processing messages after such error. If not
>>         by design, please let me know so we can patch this.
>>
>>         Thank you,
>>         Daniil
>>
>>         ----------------------------------------------------------------------------------------------------
>>
>>         The Command Line: Reinvented for Modern Developers
>>         Did the resurgence of CLI tooling catch you by surprise?
>>         Reconnect with the command line and become more productive.
>>         Learn the new .NET and ASP.NET CLI. Get your free copy!
>>         http://sdm.link/telerik
>>         ----------------------------------------------------------------------------------------------------
>>
>>         Quickfixj-users mailing list
>>         [hidden email]
>>         https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>> ------------------------------------------------------------------------------
>> The Command Line: Reinvented for Modern Developers
>> Did the resurgence of CLI tooling catch you by surprise?
>> Reconnect with the command line and become more productive.
>> Learn the new .NET and ASP.NET CLI. Get your free copy!
>> http://sdm.link/telerik
>>
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
> ------------------------------------------------------------------------------
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
>
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
--
Christoph John Development & Support Direct: +49 241 557080-28 Mailto:[hidden email]
http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------
MACD GmbH Oppenhoffallee 103 D-52066 Aachen Tel: +49 241 557080-0 | Fax: +49 241 557080-10
  Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: InvalidMessage exception

Daniil Sosonkin-2
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Chris -

Thank you for details. Cannot argue with the standards. We did resolve
this issue by literally deleting the message from the store on the
sending side. Perhaps that was a bit rash, we should've payed attention
to sequence numbers instead. The main problem for us was that we simply
didn't see the log message. Is there a way to have a callback similar to
Application which can receive those kinds of errors? In our particular
case we could've sent out an email alerting of the problem.

Daniil

On 10/26/2016 3:01 AM, Christoph John wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi Daniil,
>
> yes, that sounds like the scenario I was describing in my first mail. QFJ does not increment the
> sequence number on checksum errors. This is in line with the FIX protocol which takes an optimistic
> approach and considers the checksum error a transient transmission error that corrects itself with
> the next transmission. But the problem did not correct itself since the same erroneous message got
> retransmitted over and over.
>
> One way out of this is to set the incoming sequence number on your side and the outgoing seqnum of
> the counterparty to be one higher than the problematic message. Maybe the counterparty has other
> means to skip the problematic message, e.g. sending a gap fill instead or removing the problematic
> message from its message store.
>
> To temporarily get around this you could also check if setting ValidateIncomingMessage and
> UseDataDictionary to N will correct it.
>
> Cheers,
> Chris.
>
>
> On 25/10/16 22:25, Daniil Sosonkin wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>>
>>
>> Chris -
>>
>> There was no rejection from the receiving end. The log entry below was the only indication of the
>> problem. QFJ continued to receive execution reports, writing them to the logs, but none we
>> received by the Application. I didn't pay attention to sequence numbers at the time (it was a bit
>> stressful as you can guess).
>>
>> We've restarted client side several times. Upon each restart, it performed a resend request from
>> message that caused the problem.
>>
>> Let me know which logs would be helpful. I'm trying to dig into the code to see how QFJ is
>> handling such exception exactly (no luck yet). It seems I'm using QFJ 1.7.0-SNAPSHOT (I've forked
>> on GitHub, but so far haven't figured out whole versioning yet).
>>
>> Thank you for your help!
>>
>> On 10/25/2016 4:10 PM, Christoph John wrote:
>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>>
>>>
>>>
>>>
>>> Actually, by default QFJ does not reject msgs with invalid checksum but just does not increment
>>> the incoming seq num.
>>>
>>> Am 25. Oktober 2016 22:07:06 MESZ, schrieb Christoph John <[hidden email]>:
>>>
>>>      Hi,
>>>      which version of QFJ are you using?
>>>      What were the subsequent messages? Maybe there was an endless resend loop, i.e. your side
>>>      rejected the messages because of the checksum error (this means that the incoming seq num is
>>>      not incremented), on the next incoming msg there was a seq num mismatch and a resend which
>>>      redelivered the faulty message again and so on and so on...
>>>      Do you have some log output?
>>>
>>>      Regards,
>>>      Chris.
>>>
>>>      Am 25. Oktober 2016 16:52:38 MESZ, schrieb Daniil Sosonkin <[hidden email]>:
>>>
>>>          QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>          QuickFIX/J Support:http://www.quickfixj.org/support/
>>>
>>>
>>>          Hi -
>>>
>>>          I've encountered an interesting problem today. A message was received
>>>          with invalid checksum (that resulted from special character in Text
>>>          field, but that's internal problem). QFJ being correct has validated the
>>>          checksum, concluded it to be wrong and threw an exception:
>>>
>>>          [NioProcessor-47] ERROR quickfix.mina.initiator.InitiatorIoHandler -
>>>          Invalid message: Expected CheckSum=52, Received CheckSum=19 in
>>>          8=FIX.4.2.......
>>>
>>>          Up to this, behavior is as expected. However, QFJ has stopped processing
>>>          any subsequent FIX messages it received. This behavior is not something
>>>          I've expected. Is this done by design? If so, what are the steps to be
>>>          taken in order
>>>          to continue processing messages after such error. If not
>>>          by design, please let me know so we can patch this.
>>>
>>>          Thank you,
>>>          Daniil
>>>
>>>          ----------------------------------------------------------------------------------------------------
>>>
>>>          The Command Line: Reinvented for Modern Developers
>>>          Did the resurgence of CLI tooling catch you by surprise?
>>>          Reconnect with the command line and become more productive.
>>>          Learn the new .NET and ASP.NET CLI. Get your free copy!
>>>          http://sdm.link/telerik
>>>          ----------------------------------------------------------------------------------------------------
>>>
>>>          Quickfixj-users mailing list
>>>          [hidden email]
>>>          https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>
>>> ------------------------------------------------------------------------------
>>> The Command Line: Reinvented for Modern Developers
>>> Did the resurgence of CLI tooling catch you by surprise?
>>> Reconnect with the command line and become more productive.
>>> Learn the new .NET and ASP.NET CLI. Get your free copy!
>>> http://sdm.link/telerik
>>>
>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> ------------------------------------------------------------------------------
>> The Command Line: Reinvented for Modern Developers
>> Did the resurgence of CLI tooling catch you by surprise?
>> Reconnect with the command line and become more productive.
>> Learn the new .NET and ASP.NET CLI. Get your free copy!
>> http://sdm.link/telerik
>>
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: InvalidMessage exception

Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi Daniil,

from the output you sent it looks like the method onErrorEvent() of your quickfix.Log implementation
was called (since ERROR is logged before the message). If yes, you could put some logic into the
onErrorEvent() method.

Cheers,
Chris.


On 26/10/16 15:28, Daniil Sosonkin wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Chris -
>
> Thank you for details. Cannot argue with the standards. We did resolve
> this issue by literally deleting the message from the store on the
> sending side. Perhaps that was a bit rash, we should've payed attention
> to sequence numbers instead. The main problem for us was that we simply
> didn't see the log message. Is there a way to have a callback similar to
> Application which can receive those kinds of errors? In our particular
> case we could've sent out an email alerting of the problem.
>
> Daniil
>
> On 10/26/2016 3:01 AM, Christoph John wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Hi Daniil,
>>
>> yes, that sounds like the scenario I was describing in my first mail. QFJ does not increment the
>> sequence number on checksum errors. This is in line with the FIX protocol which takes an optimistic
>> approach and considers the checksum error a transient transmission error that corrects itself with
>> the next transmission. But the problem did not correct itself since the same erroneous message got
>> retransmitted over and over.
>>
>> One way out of this is to set the incoming sequence number on your side and the outgoing seqnum of
>> the counterparty to be one higher than the problematic message. Maybe the counterparty has other
>> means to skip the problematic message, e.g. sending a gap fill instead or removing the problematic
>> message from its message store.
>>
>> To temporarily get around this you could also check if setting ValidateIncomingMessage and
>> UseDataDictionary to N will correct it.
>>
>> Cheers,
>> Chris.
>>
>>
>> On 25/10/16 22:25, Daniil Sosonkin wrote:
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>>
>>>
>>> Chris -
>>>
>>> There was no rejection from the receiving end. The log entry below was the only indication of the
>>> problem. QFJ continued to receive execution reports, writing them to the logs, but none we
>>> received by the Application. I didn't pay attention to sequence numbers at the time (it was a bit
>>> stressful as you can guess).
>>>
>>> We've restarted client side several times. Upon each restart, it performed a resend request from
>>> message that caused the problem.
>>>
>>> Let me know which logs would be helpful. I'm trying to dig into the code to see how QFJ is
>>> handling such exception exactly (no luck yet). It seems I'm using QFJ 1.7.0-SNAPSHOT (I've forked
>>> on GitHub, but so far haven't figured out whole versioning yet).
>>>
>>> Thank you for your help!
>>>
>>> On 10/25/2016 4:10 PM, Christoph John wrote:
>>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>>>
>>>>
>>>>
>>>>
>>>> Actually, by default QFJ does not reject msgs with invalid checksum but just does not increment
>>>> the incoming seq num.
>>>>
>>>> Am 25. Oktober 2016 22:07:06 MESZ, schrieb Christoph John <[hidden email]>:
>>>>
>>>>       Hi,
>>>>       which version of QFJ are you using?
>>>>       What were the subsequent messages? Maybe there was an endless resend loop, i.e. your side
>>>>       rejected the messages because of the checksum error (this means that the incoming seq num is
>>>>       not incremented), on the next incoming msg there was a seq num mismatch and a resend which
>>>>       redelivered the faulty message again and so on and so on...
>>>>       Do you have some log output?
>>>>
>>>>       Regards,
>>>>       Chris.
>>>>
>>>>       Am 25. Oktober 2016 16:52:38 MESZ, schrieb Daniil Sosonkin <[hidden email]>:
>>>>
>>>>           QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>>           QuickFIX/J Support:http://www.quickfixj.org/support/
>>>>
>>>>
>>>>           Hi -
>>>>
>>>>           I've encountered an interesting problem today. A message was received
>>>>           with invalid checksum (that resulted from special character in Text
>>>>           field, but that's internal problem). QFJ being correct has validated the
>>>>           checksum, concluded it to be wrong and threw an exception:
>>>>
>>>>           [NioProcessor-47] ERROR quickfix.mina.initiator.InitiatorIoHandler -
>>>>           Invalid message: Expected CheckSum=52, Received CheckSum=19 in
>>>>           8=FIX.4.2.......
>>>>
>>>>           Up to this, behavior is as expected. However, QFJ has stopped processing
>>>>           any subsequent FIX messages it received. This behavior is not something
>>>>           I've expected. Is this done by design? If so, what are the steps to be
>>>>           taken in order
>>>>           to continue processing messages after such error. If not
>>>>           by design, please let me know so we can patch this.
>>>>
>>>>           Thank you,
>>>>           Daniil
>>>>

--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:[hidden email]
       


http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: InvalidMessage exception

Daniil Sosonkin-2
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Great suggestion, Chris! We'll do just that

On 10/26/2016 9:55 AM, Christoph John wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi Daniil,
>
> from the output you sent it looks like the method onErrorEvent() of your quickfix.Log implementation
> was called (since ERROR is logged before the message). If yes, you could put some logic into the
> onErrorEvent() method.
>
> Cheers,
> Chris.
>
>
> On 26/10/16 15:28, Daniil Sosonkin wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Chris -
>>
>> Thank you for details. Cannot argue with the standards. We did resolve
>> this issue by literally deleting the message from the store on the
>> sending side. Perhaps that was a bit rash, we should've payed attention
>> to sequence numbers instead. The main problem for us was that we simply
>> didn't see the log message. Is there a way to have a callback similar to
>> Application which can receive those kinds of errors? In our particular
>> case we could've sent out an email alerting of the problem.
>>
>> Daniil
>>
>> On 10/26/2016 3:01 AM, Christoph John wrote:
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> Hi Daniil,
>>>
>>> yes, that sounds like the scenario I was describing in my first mail. QFJ does not increment the
>>> sequence number on checksum errors. This is in line with the FIX protocol which takes an optimistic
>>> approach and considers the checksum error a transient transmission error that corrects itself with
>>> the next transmission. But the problem did not correct itself since the same erroneous message got
>>> retransmitted over and over.
>>>
>>> One way out of this is to set the incoming sequence number on your side and the outgoing seqnum of
>>> the counterparty to be one higher than the problematic message. Maybe the counterparty has other
>>> means to skip the problematic message, e.g. sending a gap fill instead or removing the problematic
>>> message from its message store.
>>>
>>> To temporarily get around this you could also check if setting ValidateIncomingMessage and
>>> UseDataDictionary to N will correct it.
>>>
>>> Cheers,
>>> Chris.
>>>
>>>
>>> On 25/10/16 22:25, Daniil Sosonkin wrote:
>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>
>>>>
>>>>
>>>>
>>>> Chris -
>>>>
>>>> There was no rejection from the receiving end. The log entry below was the only indication of the
>>>> problem. QFJ continued to receive execution reports, writing them to the logs, but none we
>>>> received by the Application. I didn't pay attention to sequence numbers at the time (it was a bit
>>>> stressful as you can guess).
>>>>
>>>> We've restarted client side several times. Upon each restart, it performed a resend request from
>>>> message that caused the problem.
>>>>
>>>> Let me know which logs would be helpful. I'm trying to dig into the code to see how QFJ is
>>>> handling such exception exactly (no luck yet). It seems I'm using QFJ 1.7.0-SNAPSHOT (I've forked
>>>> on GitHub, but so far haven't figured out whole versioning yet).
>>>>
>>>> Thank you for your help!
>>>>
>>>> On 10/25/2016 4:10 PM, Christoph John wrote:
>>>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Actually, by default QFJ does not reject msgs with invalid checksum but just does not increment
>>>>> the incoming seq num.
>>>>>
>>>>> Am 25. Oktober 2016 22:07:06 MESZ, schrieb Christoph John <[hidden email]>:
>>>>>
>>>>>        Hi,
>>>>>        which version of QFJ are you using?
>>>>>        What were the subsequent messages? Maybe there was an endless resend loop, i.e. your side
>>>>>        rejected the messages because of the checksum error (this means that the incoming seq num is
>>>>>        not incremented), on the next incoming msg there was a seq num mismatch and a resend which
>>>>>        redelivered the faulty message again and so on and so on...
>>>>>        Do you have some log output?
>>>>>
>>>>>        Regards,
>>>>>        Chris.
>>>>>
>>>>>        Am 25. Oktober 2016 16:52:38 MESZ, schrieb Daniil Sosonkin <[hidden email]>:
>>>>>
>>>>>            QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>>>            QuickFIX/J Support:http://www.quickfixj.org/support/
>>>>>
>>>>>
>>>>>            Hi -
>>>>>
>>>>>            I've encountered an interesting problem today. A message was received
>>>>>            with invalid checksum (that resulted from special character in Text
>>>>>            field, but that's internal problem). QFJ being correct has validated the
>>>>>            checksum, concluded it to be wrong and threw an exception:
>>>>>
>>>>>            [NioProcessor-47] ERROR quickfix.mina.initiator.InitiatorIoHandler -
>>>>>            Invalid message: Expected CheckSum=52, Received CheckSum=19 in
>>>>>            8=FIX.4.2.......
>>>>>
>>>>>            Up to this, behavior is as expected. However, QFJ has stopped processing
>>>>>            any subsequent FIX messages it received. This behavior is not something
>>>>>            I've expected. Is this done by design? If so, what are the steps to be
>>>>>            taken in order
>>>>>            to continue processing messages after such error. If not
>>>>>            by design, please let me know so we can patch this.
>>>>>
>>>>>            Thank you,
>>>>>            Daniil
>>>>>


------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Loading...