API Support Forum
User Profile

Viewing User Profile for: SRuscak


Aug 24, 2017 12:52 PM

Oct 14, 2020 09:00 AM

Oct 14, 2020 11:46 AM

Post Statistics
SRuscak has contributed to 30 posts out of 4906 total posts (0.61%) in 1157 days (0.00 posts per day).

20 most recent posts:

Market Data » LastDateTime is old Oct 14, 2020 @ 09:00 AM (Total replies: 3)

The DateTime is UTC, it's just that the DateTime.Kind is set to DateTimeKind.Unspecified when the message from the server is deserialized. But you are right, it would be more correct as DateTimeKind.Utc, and we plan to address this in a future release.

Market Data » LastDateTime is old Oct 13, 2020 @ 12:28 PM (Total replies: 3)

The time is already in UTC, so I suspect you just need to remove the ToUniversalTime call.

API Support » GAIN API COM Example problem Aug 05, 2020 @ 01:51 PM (Total replies: 2)

An update has been pushed to the comapisamples repo to fix x64 event argument references. Please try again.

API Support » GAIN API COM Example problem Jul 24, 2020 @ 11:46 AM (Total replies: 2)


We have reproduced your issue. It looks like in x64, COM is not sending event arguments pointers correctly. We will investigate a fix.

Regarding 4b -- I suspect this is happening when you are debugging long enough that the API fails the heartbeat and disconnects.

API Support » Getting the "ConnectionError" when connecting to the Gain Futures server Jul 08, 2020 @ 07:41 AM (Total replies: 9)

Reusing a connection for multiple requests from the same user sounds like a good idea. You won't have to log in and initialize every time.

>This will avoid the bottleneck when I have to process requests sequentially per user as you mentioned above
The requests must be made on the GFAPI thread, therefore they will be sequential. But there is no need to wait for the response before sending another request.

>the callback event only processes one request at a time
Well, it processes one *response* at a time. When Advance is called by the GFAPI thread, it processes all requests and responses, including raising events if need be. If you make two requests, the server will return two responses and GFAPI will raise an event for each, when it arrives. The callback event args will contain enough information to identify the request that initiated it.

>I'm not sure that GF API works properly in case there are multiple requests made in the same login session and the subscribed callback events must handle all of them.
This is normal. Consider an application like Gain Trader https://gainfutures.com/gain-trader/. It uses a single GFAPI login session and executes many many requests.

API Support » Getting the "ConnectionError" when connecting to the Gain Futures server Jun 30, 2020 @ 01:20 PM (Total replies: 9)

The connection operates as a state machine. If it's already disconnected, there should be no need to disconnect again.

As for the client runner, I don't think there's any benefit in running it while the client is disconnected.

API Support » Getting the "ConnectionError" when connecting to the Gain Futures server Jun 29, 2020 @ 10:16 AM (Total replies: 9)

Internally, we use a client-per-application model, but I believe we do have clients that use a client-per-user model. As for a client-per-request model, one downside is that there is a significant chunk of initialization data that gets downloaded on every login. But more importantly, only one simultaneous login per user is allowed, so you would have to make requests sequential per-user.

Looking at your server logs, I see that there are some 'user already connected' errors. This could be because of the above issue, or because you aren't disconnecting after the request, or because you aren't using 'force login' in the connection context.

Connection can't be perfectly reliable, so maybe you should use a reconnection attempt strategy. I posted one here (https://apisupport.gainfutures.com/Topic/Index/1336), if you want to adapt it.

API Support » Getting the "ConnectionError" when connecting to the Gain Futures server Jun 26, 2020 @ 08:45 AM (Total replies: 9)

Creating a client per-request is not a use case we've designed for. Typically we expect a single instance that runs for the life of the application, which may connect and disconnect many times, even for different users. Your use case might work, but I can't be sure.

It looks to me that, in your code, after calling Aggregate.Connect the code does not wait for LoginComplete to fire before calling CreateSignal. Aggregate.Connect is not synchronous.

As for a side effect involving async/await... it may be possible. We will investigate and release a patch if something turns up.

API Support » Getting the "ConnectionError" when connecting to the Gain Futures server Jun 25, 2020 @ 02:52 PM (Total replies: 9)


No, connection is working fine on our end.

>call the GF request inside a complex process
Do you mean the login request?

>inside a complex process
The problem may be thread timing. If you're not on the GFAPI thread, you should call Connect inside GF.Threading.Invoke. On the other hand, if the GFAPI thread is being hogged by a complex process, then Advance won't be called frequently enough to successfully log in.

API Support » IGFClient auto-reconnect problem Jun 25, 2020 @ 02:50 PM (Total replies: 1)

Hello, sorry to hear you're having difficulties with the connection code.

Solution #1

>await Task.Delay(5000);
This fails because the subsequent connection call is on some unknown thread, not the GFAPI thread.

Solution #2

It looks like in the last connection attempt from your screenshot, OnDisconnected wasn't called, so the reconnect code didn't run. Probably only OnLoginFailed was called. OnLoginFailed is another scenario where you may want to reconnect.

I wrote a reconnection solution for you, similar to what we use.

public class GFApiReconnecter
private IGFClient _client;
private CancellationTokenSource _cts;
private ConnectionContext _connectionContext;
private GF.Api.Utils.GFApiEventHandler _loginFailed;

public void Register(IGFClient client, GF.Api.Utils.GFApiEventHandler loginFailed)
_client = client;
_loginFailed = loginFailed;
client.Connection.Aggregate.LoginCompleted += (gfClient, args) => EndReconnect();
client.Connection.Aggregate.LoginFailed += (gfClient, args) =>
if (args.FailReason != GF.Api.Values.Users.FailReason.ConnectionError || _cts?.IsCancellationRequested != false)
_loginFailed(gfClient, args);

client.Connection.Aggregate.Disconnected += (gfClient, args) =>
if (args.Reason != DisconnectionReason.SocketError || _cts?.IsCancellationRequested == false)

_cts = new CancellationTokenSource();

public void Connect(ConnectionContext context)
_connectionContext = context;

private void Reconnect()
if (_client.Connection.Aggregate.IsClosed)
() => _client.Connection.Aggregate.Connect(_connectionContext),

private void EndReconnect()
if (_client.Connection.Aggregate.IsConnecting)

API Support » Trailing Stop and Trailing Stop Limit order - version issue Jun 09, 2020 @ 08:53 AM (Total replies: 2)

Yes, you are correct, thank you. It's a server side issue. We're working on it and will get it fixed soon.

FIX Support » RequestForPositions SubscriptionRequestType Apr 06, 2020 @ 07:57 AM (Total replies: 2)

Yes, that is correct.

API Support » GFAPI Socket Error after 2 minutes Mar 06, 2020 @ 10:06 AM (Total replies: 13)

The example code you gave is not recommended because you are disconnecting and then reconnecting on what is nearly the next line of code. I don't see any use case for doing that. You can just stay connected instead.

In the case of wanting to reconnect after an unexpected disconnection, yes, it is recommended to wait for the client to raise the disconnection event before reconnecting. The 'race condition' will disappear if you do this. Probably your other issue here is that you are trying to call Connect from the Disconnected event handler, which is on the API thread. To quote the help file: "GF API is not a multithreaded library. Advance() will raise API events on the calling thread. Other threads MUST NOT operate on the IGFClient object graph before the Advance() method call returns."

You can use client.Threading.BeginInvoke for this:

Private Shared Sub GFClient_OnDisconnected(ByVal client As IGFClient, ByVal e As DisconnectedEventArgs)
client.Threading.BeginInvoke(Sub() Connect(client))
End Sub

API Support » GFAPI Socket Error after 2 minutes Mar 06, 2020 @ 08:59 AM (Total replies: 13)

Well... I think you're just doing it too fast? I can reproduce your issue in about 1 in 3 attempts, but if I put a Thread.Sleep(10) between the disconnect and the reconnect, I can't reproduce it at all.

API Support » GFAPI Socket Error after 2 minutes Mar 05, 2020 @ 12:54 PM (Total replies: 13)

It looks ok from my side. I can connect and disconnect and connect again. I can do the same symbol lookup as you did, but without an error.

Perhaps there is an error in your SymbolLookupReceived handler? Or some further issue with your threading model?

API Support » GFAPI Socket Error after 2 minutes Mar 05, 2020 @ 12:35 PM (Total replies: 13)

My bad, is the latest released right now. I'm going to try to replicate your issue.

API Support » GFAPI Socket Error after 2 minutes Mar 05, 2020 @ 12:29 PM (Total replies: 13)

3. No, the client is responsible for reconnection.
4. Just connect like you did the first time. There shouldn't be any concerns to worry about here.
5. I don't know why it would do that.
8. Not much to say here. It looks like you successfully log on, you get a symbol lookup response, and then your host terminates the connection.

I notice that you are using an old version of the API. While it is supposed to be backwards compatible, you could try updating.

API Support » GFAPI Socket Error after 2 minutes Mar 05, 2020 @ 09:46 AM (Total replies: 13)

To be precise, there isn't really any 're-connection'. There is only connection. Every time you connect, the API is initialized from the server in the same way and ends up in the same state. There's nothing different about connecting for the first time versus the second or nth time. So it sounds like the issue is that the connection was dropped at all.

GFClientRunner is responsible for calling Advance, so if you're using it you shouldn't have to call Advance yourself.

Is your 2-minute process happening in the login event handler? API events are raised on the API thread, so you'll miss the heartbeat window if the handler doesn't return soon enough.

Are you signed up for gfClient.Logging.ErrorOccurred? Just in case there's something revealing there.

API Support » GFAPI Socket Error after 2 minutes Mar 05, 2020 @ 08:14 AM (Total replies: 13)


The API maintains connection to the servers with a heartbeat. To keep the connection alive, you need to call gfClient.Threading.Advance() regularly, so if you need to do a 2 minute operation it will have to be on a different thread. There is more information about it here:

API Support » Location Mar 02, 2020 @ 12:01 PM (Total replies: 2)

It looks something like this:

new OrderDraftBuilder()