Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • The telecommunication link error was detected

    Code Block
    <Timestamp>    WARN    [Engine]  Session <Session_Name> : the telecommunication link error was detected (Connection::receive(), EOF).

    Description: It means that the TCP connection was terminated unexpectedly by counter-party, without Logouts exchange.

    Troubleshooting steps: Contact counter-party and query them for sanity of their FIX adaptor/engine.

  • "MessageStorageType storageType" parameter is deprecated

    Code Block
    <Timestamp>    WARN    [Engine]  Session <Session_Name> : FixEngine::CreateSession(...) "MessageStorageType storageType" parameter is deprecated. Please use SessionExtraParameters::storageType instead.

    DescriptionWe improve the API of our products continuously and some parameters were left for backward compatibility. Such a message can appear in the log file in case of using non-default values for such parameters but if the value passes all checks then there is just such a record in the log file and it doesn’t affect anything.

    Troubleshooting steps: You can ignore these messages.

  • Session was created in danger mode

    Code Block
    <Timestamp>    WARN    [Engine]  Session <Session_Name> : session was created in danger mode - it does not use persistent message storage.

    DescriptionIt means that a session uses the transient storage, i.e. no log files with FIX messages will be created.

    Troubleshooting steps: In file you can turn on logging for a session by setting 'FixLayer.FixEngine.Session.<SessionName>.StorageType = persistentMM' (or persistent). For Admin Session (a session between FIXEdge and FIXICC Agent) you need to change the property Monitoring.AdminSession.AdminClient.StorageType (which is in file) accordingly, but we don’t recommend to do this for Admin Session - there will be quite a lot of messages.

  • Garbled message

    Code Block
    <Timestamp>    WARN    [Engine]  Garbled message: <FIX_Message>

    Description: The FIX Protocol takes the optimistic view; it presumes that a garbled message is received due to a transmission error rather than a FIX system problem. Therefore, if a Resend Request is sent the garbled message will be re-transmitted correctly. If a message is not considered garbled then it is recommended that a session level Reject message be sent.

    What constitutes a garbled message:
    • BeginString (tag #8) is not the first tag in a message or is not of the format 8=FIX.n.m.
    • BodyLength (tag #9) is not the second tag in a message or does not contain the correct byte count.

    Troubleshooting steps: Make sure that the FIX message was re-transmitted correctly. If not, contact your counter-party regarding malformed messages from their side.