API Support Forum
User Profile

Viewing User Profile for: JSmith5611


About

Aug 11, 2015 02:10 PM

Apr 15, 2021 12:35 PM

Apr 15, 2021 12:35 PM



Post Statistics
JSmith5611 has contributed to 101 posts out of 5095 total posts (1.98%) in 2075 days (0.00 posts per day).

20 most recent posts:

Market Data » ZSK21 Stops Receiving Intraday History after First OnBarsReceived Callback Apr 15, 2021 @ 12:35 PM (Total replies: 7)

I just loaded up a GF COM example code, and ran:

GF_Api_COM::IContractPtr contract = GFAPI()->Contracts->Get_2((LPCSTR)dlg.m_SelectedSymbol);
GFAPI()->Subscriptions->Bars->Subscribe(
contract->id,
GFAPI()->Subscriptions->Bars->Duration->Create_3(8000, GF_Api_COM::Continuity_OneTime),
GFAPI()->Subscriptions->Bars->Description->CreateMinutes(1)
);

for ZSK21 on API and SIM, and both worked fine (one message of 4096 bars, one of 3905)
Jason Smith


API Support » Trail Stop Order issue Feb 09, 2021 @ 11:17 AM (Total replies: 2)

I'm starting to implement this feature, and I have a few questions..
1) how did you achieve this in the old API?
2) Do you want the reference price or delta in ticks?
Jason Smith


API Support » Wrong platform linked to new COM API release? Feb 05, 2021 @ 06:41 AM (Total replies: 2)

Website is fixed now.
Jason Smith


API Support » Wrong platform linked to new COM API release? Feb 04, 2021 @ 02:38 PM (Total replies: 2)

you right, both links are 32bit version..
Here's a link to the 64bit until we get the website fixed:

https://prod.gainfutures.com/WebAPI/api/Files/DownloadClientUpdateLast?brandId=0&clientTypeId=5005&branchId=2
Jason Smith


API Support » Connection error/Socket error Feb 04, 2021 @ 02:19 PM (Total replies: 2)

a price connection requires an order connection.

so the simplest fix would be to replace
gfClient.Connection.Price.Connect()
with
gfClient.Connection.Aggregate.Connect()
Jason Smith


API Support » GF COM API Order Modification Response Taking Long Jan 25, 2021 @ 12:21 PM (Total replies: 32)

Sorry for the delay in my response, I was pulled onto a high priority task.
I looked at the two modifies you were referencing.. from the server logs, for once I see no delay.

The modify for 211848548 took 74ms, and 211848423 was ever so slightly slower at 121ms.

I'm still digging for a cause of the delay on your end, but from these logs, it definitely looks like the server-side slowdown that I was seeing in logs previously is fixed.
Jason Smith


API Support » GF COM API Order Modification Response Taking Long Jan 19, 2021 @ 10:41 AM (Total replies: 32)

The fix was server-side only, no COM update is needed. (and was only released to API)

I did see something odd in the logs for API.. were you doing multiple contract load requests during the order modification? (I can see that there were multiple 1000-result requests from the same user, but not which user)
Jason Smith


API Support » GF COM API Order Modification Response Taking Long Jan 11, 2021 @ 11:29 AM (Total replies: 32)

Fix is done, but was based on two other fixes/improvements that hadn't gotten through review process yet.
Definitively will be tested on API for at least a week.
Jason Smith


API Support » GF COM API Order Modification Response Taking Long Jan 11, 2021 @ 06:43 AM (Total replies: 32)

Unfortunately, due to change dependencies, this fix did not get released this past weekend.
Jason Smith


API Support » GF COM API Orders Intermittently Remain in Sent State Jan 06, 2021 @ 01:08 PM (Total replies: 4)

I'm fairly certain that the issue here is the same as the issue we've been dealing with in the other thread.
Jason Smith


API Support » GF COM API Order Modification Response Taking Long Jan 06, 2021 @ 01:07 PM (Total replies: 32)

Fix has a high probability of getting in this weekend's API release.
Jason Smith


API Support » GF COM API Order Modification Response Taking Long Jan 05, 2021 @ 12:23 PM (Total replies: 32)

I've been able to confirm the source of the problem and I am working hard to get it fixed as soon as possible.
Jason Smith


API Support » GF COM API Order Modification Response Taking Long Jan 04, 2021 @ 07:33 AM (Total replies: 32)

Sorry, I was on vacation between Christmas and New Years. Back at it today.

Before I left I did see one possibility of the source, but no confirmation.

a few questions:
Does this issue happen any time of the day on API? I'd like to know if it still happens after ~1pm CST
Does this issue occur on SIM environment.. if so, can you send me a order ID example?
Jason Smith


API Support » GF COM API Order Modification Response Taking Long Dec 23, 2020 @ 02:41 PM (Total replies: 32)

It may be something on our end. I'll hopefully have some answers soon.
Jason Smith


API Support » GF COM API Order Modification Response Taking Long Dec 23, 2020 @ 02:01 PM (Total replies: 32)

Ok, this is really weird..

On the server that users log into for orders, the first modify (to 12703.75) took ~4 seconds from being received from your app to being fully modified.

But if i look at the logs for where the order is actually processed... it received the modify command, checked risk, and had the order fully modified (and responses transmitted) in.. 84ms.

There must be something off with the API environment, as we haven't had complaints of order delays this bad anywhere else.
Jason Smith


API Support » GF COM API Order Modification Response Taking Long Dec 23, 2020 @ 12:19 PM (Total replies: 32)

The aggregate connection is just an abstraction around a order + price connection for ease of use.
A second runner really wouldn't do anything, as it just calls GFApi.Threading.Advance in a loop ever 10 ms.

The COM version of both the old OEC and current GF apis were just wrappers around the .NET api. I'm digging into differences in implementation of the wrappers but I'm not really seeing much.

I'll look through the server logs for that order ID now, and let you know what i've found.
Jason Smith


API Support » GF COM API Order Modification Response Taking Long Dec 23, 2020 @ 10:07 AM (Total replies: 32)

And I also want to confirm that you are creating an instance to the API just once, and creating a runner just once.

i.e: (c++)

GF_Api_COM::IGFComClientPtr _GFAPI;
GF_Api_COM::IGFComClientRunnerPtr _GFClientRunner;

_GFAPI.CreateInstance(__uuidof(GF_Api_COM::GFComClient));
_GFClientRunner = _GFAPI->Threading->CreateRunnerFor(_GFAPI);
_GFClientRunner->Start();
Jason Smith


API Support » GF COM API Order Modification Response Taking Long Dec 23, 2020 @ 06:36 AM (Total replies: 32)

Can I have the order ID(s) so I can dig through our logs?
Jason Smith


API Support » GF COM API Order Modification Response Taking Long Dec 22, 2020 @ 03:07 PM (Total replies: 32)

I've yet to be able to find anything in particular That should cause order commands to get processed slowly through the COM version of the api.

The COM version of the GF api is just a wrapper around the .NET api, so the speed should be about the same. The only known performance-related issue with the GF API was when dealing with large (100+ account) allocation blocks. A fix has been released for that this weekend (but I need to double check that the fix was pushed to the COM version and nuget)

Please let me know if your testing/development is involving large block orders.

Other than that.. The only thing I can think of that would be causing slow events is something wrong with your event handlers. You mentioned in another thread that you were not getting login-related events at all, did you find what was causing that?
Jason Smith


API Support » GF COM API Orders Intermittently Remain in Sent State Dec 16, 2020 @ 02:01 PM (Total replies: 4)

I don't see how this could be happening.
If when you think your orders are stuck in 'sent' what state are they in if you log into trader?
Jason Smith