Versions Compared

Key

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

...

  • Message cannot be sent

    Code Block
    languagebash
    <Timestamp>    ERROR    [CC_Layer]  LayerImpl::sendMessage2ClientId() has failed: Message cannot be sent: client TestSMTPClient is not logged in.

    Description: This message occurs when there is an attempt to send a message to a not initialized ("logged in") Client of Transport Adapter (TA). The disclosed in log record "client" name represents the name of TA Client in FIXEdge.properties.

    Info

    Depending on TA type, the Client may be also referred to as "Session". For example, Clients of SMTP TA are listed under TransportLayer.SmtpTA.SMTPSessions parameter.

    The reason for this is that specific TA, to which the Client belongs, is not added to the list of enabled adapters TransportLayer.TransportAdapters in FIXEdge.properties. Once added, you will see in log (after FIXEdge restart) record records like:

    Code Block
    languagebash
    <Timestamp>   INFO    [CC_Layer]  Client TestSMTPClient has logged in

    Troubleshooting steps: 1. First of all, review BL_Config.xml file for the Rule, that routes messages to mentioned Client, and check if it is correct and does what is required by your system. Remove the Rule if there is no need in for it.
    For instance, the ERROR in this specific example was caused by the default BL Rule which was left unintentionally in place:

    Code Block
    languagebash
    <Rule>
    	<Source>
    		<FixSession SenderCompID=".*" TargetCompID=".*"/>
    	</Source>
    	<Condition>
    		<EqualField Field="35" Value="C"/>
    	</Condition>
    	<Action>
    		<Send>
    			<Client Name="TestSMTPClient"/>
    		</Send>
    	</Action>
    </Rule>

    2. Check that the corresponding TA client was successfully started and connected. Check FIXEdge.properties for correctness, especially that TA is added to TransportLayer.TransportAdapters list.

...

  • The connection association got dropped by a network device (NAT/router/switch)

    Code Block
    languagebash
    <Timestamp>    ERROR    [Engine] <Thread ID> New incoming connection from :0 was rejected because of the error during processing: getpeername. Transport endpoint is not connected. (Error code = 107)

    Description: The record means that there had been a connection attempt from a counterparty, and when FIX Engine was trying to detect its source ipIP/port with getpeername function, the connection association got dropped by a network device (NAT/router/switch).

    Troubleshooting steps: reconnect the session.

...

  • New incoming connection was rejected

    Code Block
    languagebash
    <Timestamp>    ERROR    [Engine]  New incoming connection from xxx.xxx.xxx.x:xxxxx was rejected because of the error during processing: Connection::receive(), EOF from xxx.xxx.xxx.x:xxxxx

    DescriptionThis error occurs when a network device drops connection association, or there is a code issue resulting in FIX connection to be being terminated unexpectedly without Logouts exchange.

    Troubleshooting steps: Contact your counter-party for an explanation from their side and related events that make bring more light on the root cause.

...

  • Error during processing Logon message

    Code Block
    languagebash
    <Timestamp>    ERROR    [Engine]  Session <Session_Name> : Error during processing Logon message from xx.xxx.x.xx:xxxxx: Incoming connection is rejected by application: Cannot create session. Reason: Authentication is failed or session is not configured to accept connection

    Description: This is related to setup with LDAP authentication. Authentication is performed against Session identifier  (SenderCompID and TrargetCompID) and LDAP using the Username (tag 553) and Password (tag 554) from FIX Logon message.

    Troubleshooting steps:
    1. Work with the counterparty to make sure that that those supplied in Logon credentials are correct.
    2. Check if credentials are correct in LDAP and any other issues with LDAP itself.
    3. Review and check the LDAPAuthenticate section in the BL_Config.xml file.

...

  • Unable to establish connection (Error code = 10060)

    Code Block
    languagebash
    <Timestamp>    ERROR    [Engine]  Session <Session_Name> : Unable to establish connection: connect() to (xxx.xxx.xxx.x:xxxxx) failed. A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (Error code = 10060)

    Description: This is related to an address or a port of destination are that is not available from the host machine.

    Troubleshooting steps

    1. Use telnet to check the connection. Fix network issues.
    2. Make sure that the counterparty sees the connect attempts.
    3. Once the network has been configured and the node has become available, try to connecting againconnect again.

DEBUG

  • No OnActionFail is specified for the rule

    Code Block
    languagebash
    <Timestamp>    DEBUG    [BL_RoutingTable]  No OnActionFail is specified for rule for 'Rule_Name'.

    Description: These messages usually indicate that you have a routing Rulerule, but haven’t specified what will happen if the Rule fails.

    Troubleshooting steps: These are not errors, just indications that <OnActionFail> condition might be also set up.

...

  • The telecommunication link error was detected

    Code Block
    languagebash
    <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 the counter-party, without Logouts exchange.

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

...

  • "MessageStorageType storageType" parameter is deprecated

    Code Block
    languagebash
    <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

    The session was created in danger mode

    Code Block
    languagebash
    <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 FIXEdge.properties 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 engine.properties file) accordingly, but we don’t recommend to do doing this for Admin Session - there will be quite a lot of messages.

...

  • Garbled message

    Code Block
    languagebash
    <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 retransmitted 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.

  • Parse Error: Incorrect size of a repeating group.

    Code Block
    Parse Error : Incorrect size of repeating group. Expected: 1. In fact: 2. Parsing stopped at column: 228 in tag N/A in message E with sequence number 979.

    Description: This error will occur if the validation option 'verifyRepeatingGroupBounds' is enabled and FIX Engine receives a message with an incorrect repeating group size. In this case, the FIX message will be rejected.

    Before FIX Engine version 2.28.1 (and FIXEdge version 6.11.0), this parameter was always enabled.
    Troubleshooting steps: To revert this parameter after updating to the versions stated above, this parameter should be set to false. Additionally, for FIX Engine, the field Engine::SessionExtraParameters::ValidationParameters::verifyRepeatingGroupBounds_should be set to false.


  • Authentification service doesn't send a response in time

    Code Block
    languagebash
    <timestamp>   WARN    [LogonHandler]  <thread>  Session <SenderCompId, TargetCompId> : process logon failed  - request is timed out

    Description: This WARN record occurs in the FixEdge.log file if FIXEdge doesn't receive a response in time.

INFO

  • Active

    Troubleshooting steps: Check the incoming FIX session logs and if there are no messages User Response (BF) then the issue is on the Authentification Service side.

INFO

  • The active session was closed non-gracefully

    Code Block
    languagebash
    <Timestamp>    INFO    [Engine]  Session <Session_Name> : Change state: old state=Established new state=NonGracefullyTerminated
    <Timestamp>    INFO    [Engine]  Session <Session_Name> : active session was closed non-gracefully (The confirming Logout message was received from the counterparty.).

    Description: This message appears when the session was terminated by Logout and IntradayLogoutTolerance mode is enabled. This mode means that during the next session start the same set of logs will be used and the next Logon will be sent with sequence number previous+1 (unless you use ForceSeqNumReset=ALWAYS. See matrix of possible IntradayLogoutTolerance+ForceSeqNumReset combinations).

    Troubleshooting steps: This doesn't indicate an issue, just informs that session was disconnected correctly and sequence numbers were preserved.

...