|High Throughput Best Practices||Table of Content||Glossary|
|Frequently Asked Questions|
Q: Why do I receive the "Cannot load assembly FixForge.dll or one of its dependency" error when I run my application?
A: The reason of this error is the Visual C++ Runtime Libraries missing, please see Deployment.
Q: Why I cannot use AnyCpu solution platform in my Visual Studio project with your library?
A: In order to achieve the best performance and minimize latency, our FIX Engine library contains the native unmanaged code, which is platform depended, so there is need to compile the library specifying the concrete platform - x86 or x64.
Q: Why I cannot open Windows Form or Controls in the Visual Studio designer for x64 sample projects?
A: Visual Studio is a 32-bit process and therefore can only execute 32-bit modules. While Visual Studio allows you to add a reference to a 64-bit assembly, it cannot actually JIT compile it to 64-bit and execute it in process. The workaround is to use the 32-bit DLL for form designer and change to the 64-bit DLL when the design is finished.
Q: I'm now getting the following error:
Cannot logon: after sending the initial Logon message the telecommunication link error is detected (An existing connection was forcibly closed by the remote host. System error code = 10054). Could this be related to my setup?
A: It looks like a configuration-related issue indeed (either on yours or counterpart side). The error message means that the TCP connection was established and the initial Logon (MsgType=A) FIX message was sent, but after that, the TCP connection was closed by the counterparty. So we would recommend to contact your counterparty FIX Support Team and provide them with your FIX message log file (*.summary) and ask them what you need to change (if anything) in your initial Logon (MsgType=A), in order to establish the FIX Session successfully. Perhaps they need to update the configuration settings on their side, in order to accept your FIX connection (e.g. update login/password settings or the expected source IP address).
Q: How can I configure FIX Engine to send a Logout message before terminating the FIX connection when the incoming message sequence number is less than expected?
A: Please set the SendLogoutOnException configuration option to true. For example:
EngineSettings settings = new EngineSettings(); settings.SendLogoutOnException = true; Engine.Init(settings);
Q: Is the OnixS .NET FIX Engine 100% managed code (MSIL-only, no native code)?
A: No. OnixS .NET FIX Engine represents a mixed code assembly. To achieve the best performance and minimize latency we use the unmanaged code in some mission-critical subsystems of OnixS .NET FIX Engine.
Q: I need to continue the FIX Session starting from the specific message sequence number, but I have deleted the log files from the previous runs. How can I do this?
A: You can use InSeqNum and OutSeqNum properties to set the start sequence numbers before establishing the session.
See also:Message Sequence Numbers.
Q: Why does my GUI application hang when I try to handle the Engine events?
A: The most probable reason is that you are trying to update GUI controls directly from the event handler. It is necessary to use Control.Invoke instead.
See also:Updating GUI Controls on Session event.
Q:How can I customize OnixS .NET FIX Engine to work with non-standard FIX counterparties that employ user-defined fields and messages (use modifications of the FIX Protocol)?
A: You need to define and use the corresponding XML-based FIX Dialect description.
See also:FIX Dialects.
Q: What is the default behavior of OnixS .NET FIX Engine in the case where a Test Request (1) message was sent to the counterparty and the counterparty does not respond?
A: When the response on the Test Request (1) message is not received during HeartBeatInt, the FIX Connection is considered as lost. FIX Session-Acceptor changes its state to LOGON_IN_PROGRESS. FIX Session-Initiator changes its state to RECONNECTING and tries to restore the FIX Connection pre-configured number of times in pre-configured interval (using the binary exponential backoff algorithm). Please note that OnixS .NET FIX Engine automatically handles sending of Test Request messages (when needed).
See also:Reconnect.Attempts and Reconnect.Interval configuration settings.
Q: How can I set SenderSubID and OnBehalfOfSubID fields in the Logon message?
A: Take a look at Connecting using Custom Logon Message topic.
Q: Why do I receive the "Invalid FIX Engine settings: Cannot open the persistent storage folder ('MsgStorage')" error when I'm trying to run my FIX application as a Windows service? When I run my application as a standalone one, all work perfectly OK.
A: The reason of this error is the different default current folder for Windows Service and Windows application. By default, the current directory for your Windows service is the System32 folder. To solve this issue, specify the full path to the persistent storage folder using the Log.Directory setting.
Q: How can I set SenderSubID, TargetSubID, SenderLocationID, TargetLocationID, for all outgoing messages including session-level ones?
A: You can use a corresponding property exposed by Session class like SenderSubID and TargetSubID.
Q: How will I know if I do not have the valid license file? What is a failure scenario/message for the Engine?
A: When the license expires EngineException is thrown during the call of the Init() method. See also:Licensing the Engine.
Q:Is there any way to check whether Logon and/or Logout messages are received?
A: Yes. Subscribe to the InboundSessionMsgEvent event and you'll be able to check all session-level messages including Logon and Logout.
Q: How can I tell what the latency from the last byte on the wire to when I get the InboundApplicationMsgEvent?
A: We would suggest the following approach:
Q: Why do I see large delays between timestamps of FIX messages captured by Wireshark and corresponding timestamps of records in FIX .summary file?
A: We have detected that it is not correct to compare Wireshark timestamps with FIX .summary file timestamps. They are computed using different timers and as we know there is no way on Windows to get precise microsecond timestamp.
Q: Why do I receive the "Garbled message received. Invalid number of repeating group instances" warning through even if I see that this number is correct?
A: The reason of this warning is the following: Due to the design of the FIX protocol, the FIX repeating group cannot be parsed properly without the additional information that describes its structure. This is a well-known feature/flaw of the FIX protocol - and is applicable to any software that parses FIX repeating groups. If the FIX destination you work with uses non-standard (custom) fields in the repeating group then the FIX Engine needs the corresponding XML-based FIX Dialect description file. So you would need to specify the FIX Dialect description file to use during the FIX Engine initialization and use the Dialect Id instead of FIX Protocol version in your code. FIX Dialect also helps to validate FIX messages. More information could be found in the Dialect Description topic.
Q: How could I activate the automatic failover (backup session) functionality?
A: Please use the Scheduler class, there is the SessionConnectionSettings class which provides the Counterparties property to specify a backup server. More information could be found in the Scheduling Sessions for Automatic Connection topic.
Q: How to create multiple sessions with the same SenderCompID and TargetCompID?
A: You can specify different keys for the sessions with the same SenderCompID and TargetCompID. Please see the parameter customSessionKey of the Session class constructor.
Q: How to control the order of the tags?
A: To control tags order you need to create a custom dialect and describe all tags in a Message or Repeating group in the necessary order with the override mode. More information could be found in the Dialect Description topic.
Q: Why can I see that my sent application messages are logged before the received application message?
A: This is the expected behavior. In order to decrease the receiving latency (exclude the logging latency from the receiving latency), incoming application FIX messages are logged after the InboundApplicationMsgEvent callback.
Q: How can I configure the FIX Engine to create the maximum amount of FIX sessions?
A: Each session occupies system resources (Threads, File descriptors, etc.). Each operation system has a limit of system resources, so if you achieve this limit then you cannot create more FIX sessions. In order to create the maximum amount of FIX sessions, you can use the ThreadPool mode, and MemoryBasedStorage type.
Q: Why do I receive the "Connection closing process is not finished after the internal timeout" internal warning when the Logout() method is called?
A: When the Logout() method is called and the FIX connection is closed by the Logouts exchange the FIX Engine waits for closing the TCP connection and internal network components during the internal timeout (30 sec). If the closing process is not finished during the timeout then the mentioned internal warning is reported to the log. This can be when InboundApplicationMsgEvent or InboundSessionMsgEvent handler is blocked for some reasons. Session event handling is a synchronous operation. For this reason, it is recommended not to perform time-consuming tasks inside event handlers, please see the Subscribing to Session Events topic.
Q: How can I measure the Tick-To-Trade latency?
A: Tick-To-Trade latency includes the following:
Q: Why can I see a delay between Wireshark and FIX Engine *.summary log timestamps?
A: The reason of this can be the following:
Q: Why do garbled messages not rise inbound events? Do I miss such messages?
A: In accordance with the FIX protocol, an application should disregard any message that is garbled, cannot be parsed or fails a data integrity check. Processing of the next valid FIX message will cause detection of a sequence gap and a Resend Request will be generated. Therefore, such garbled messages should cause the sequence gap and the counterparty should resend messages afterwards.
Q: Why do I see a significant memory consumption when I receive large messages with many repeating groups? Why is this memory not released during the FIX connection lifetime?
A: When a large message with many repeating groups is received, for example, SecurityList (y), the session allocates the memory for this message and each repeating group instance. This can increase memory consumption, especially when there are many such sessions. For performance reasons, this memory is not deallocated during the FIX connection lifetime because the deallocation and further allocation of new memory are expensive, so it cannot be performed after receiving each message. This memory is deallocated only after the Session.Logout() call. However, in some cases, it makes sense to have the ability to shrink this memory after receiving large messages. In such cases, ScheduleShrinkToFit() method can be used. This method will schedule the memory usage optimization. The session will perform the actual memory usage optimization after receiving and processing the next incoming message.