API Support Forum
User Profile

Viewing User Profile for: RWare2020


About

Feb 11, 2020 03:38 PM

Aug 17, 2021 11:36 AM

Aug 17, 2021 11:36 AM



Post Statistics
RWare2020 has contributed to 118 posts out of 5221 total posts (2.26%) in 621 days (0.00 posts per day).

20 most recent posts:

API Support » December Corn ZCZ21 Options Appear Incorrect Aug 17, 2021 @ 11:36 AM (Total replies: 1)

It looks like is an issue with the December corn options contracts.

A couple things I see:
1. There is an OZC5Q21 August(Q) 2021 contract. August doesn't have 5 weeks if it is going off Fridays.
2. Gain Trader is showing it as a September contract, but it is an August contract
3. Gain Trader is not showing any values for OZC5Q21 for the strikes available

This also happens for a September contract OZC5U21 and an October contract OZC5V21.

Will you please look into this?

Thanks.

API Support » Issue pulling in most recent historical daily bar for Grains Jul 15, 2021 @ 12:15 PM (Total replies: 10)

The grain bar is coming in correctly now, but the open time is still incorrect.

I'm not sure how it got fixed, but thanks for taking care of that, we will keep our eyes open for the open time change.

Thanks.

API Support » Issue pulling in most recent historical daily bar for Grains Jul 13, 2021 @ 02:03 PM (Total replies: 10)

How did it just break COM OEC API if you have not been doing work on it lately? Further, then how are you not fixing the COM OEC API to fix the problem?

We haven't officially moved over to the GF API due to items that are needed in the COM GF API (such as prioritizing orders/positions coming back rather than a contract load that will cost clients time delay on order fills). We have been waiting on before moving to the COM GF API and this has broken our current clients in the COM OEC API?

API Support » Issue pulling in most recent historical daily bar for Grains Jul 08, 2021 @ 04:49 PM (Total replies: 10)

Yes it is

API Support » Issue pulling in most recent historical daily bar for Grains Jul 08, 2021 @ 02:44 PM (Total replies: 10)

And now that I know what I'm looking for, the COM API sample shows ZCZ21 Start time: 6:00, stop time: 12:20 when it should be Start time:18:00, stop time: 12:20

API Support » Issue pulling in most recent historical daily bar for Grains Jul 08, 2021 @ 02:13 PM (Total replies: 10)

It appears the grain contract start time is coming back incorrectly. The contract start time is coming back as 6 AM MST and close time of 12:20 PM MST when it should be a contract start time of 6 PM MST and close time of 12:20 PM MST.

Will you please double check this to see if my findings are correct?

API Support » Issue pulling in most recent historical daily bar for Grains Jul 08, 2021 @ 01:38 PM (Total replies: 10)

I am seeing a historical bar come back, but it seems like there is something that is being sent back in a different order or something. I can't quite put my finger on it.

We have a data tab that we show all of the historical data and we have duplicate records for all grains, not for any other contracts.

We are only seeing the issue with daily historical requests, intraday seems to work correctly.

The GF COM sample code only seems to pull hourly historical data.

Both OEC Trader and Gain Trader are showing the daily bar correctly for grains.

I have tried the OEC API COM and the GF API COM and I am seeing the issue on both in our developer environment.

This seemed to happen over the holiday weekend, maybe there is something wrong there.

API Support » Issue pulling in most recent historical daily bar for Grains Jul 07, 2021 @ 01:50 PM (Total replies: 10)

Did something change with the way grains history is sent back?

We are having an issue where we are not getting the most recent historical daily bar for all grain contracts (plus soybeans/soymeal). All other contracts are pulling in the most recent daily bar fine, but it seems all grains are having issues.

We have had 3 reporters of this issue starting from the start of todays trading period (yesterday open).

Will you please look into this for me?

Thanks.

API Support » GF COM API Prioritize Requests May 28, 2021 @ 10:59 AM (Total replies: 8)

Thanks.

API Support » GF COM API Prioritize Requests May 27, 2021 @ 11:41 AM (Total replies: 8)

I am already doing this. As my post above states:

"Currently, we just send off another contract load request inside of the callback to request more if the number of contracts returned was not 0. From the last post about the disconnection, it sounds like that could potentially cause issues since the callback function has not finished so I tried using PostMessage to process our contract load request queue. That is not working."

API Support » GF COM API Prioritize Requests May 26, 2021 @ 12:16 PM (Total replies: 8)

How do you suggest I handle my issue? Waiting 8 seconds for a response for an order is not acceptable and we need to load options.

API Support » GF COM API Prioritize Requests May 24, 2021 @ 02:11 PM (Total replies: 8)

I feel orders need to be prioritized before a contract load request.

I'm having an issue because of how contract load requests have been changed since the previous OEC API. We now are required to only load 1000 at a time and continuously request them until we get 0 back. Before we were able to just load a contract and everything was just instantly available to us. We load all options for a given contract symbol and have to request them continuously in the background until we get 0 back, but if a user tries to place an order in that time we are requesting the options contracts, they have to sit there and wait until all the options come back. There are times when an order doesn't happen for about 5 seconds or more and that is not okay. 5 seconds can potentially be a massive price change and if the order was not handled immediately, then they could be filled at a completely different price. Even not getting feedback for 5 seconds is not okay with an order.

Currently, we just send off another contract load request inside of the callback to request more if the number of contracts returned was not 0. From the last post about the disconnection, it sounds like that could potentially cause issues since the callback function has not finished so I tried using PostMessage to process our contract load request queue. That is not working.

How does the server handle getting multiple requests at the same time if there is no queue or something to handle those requests?

How do you propose I handle placing an order in between contract load requests so that the order takes priority over the contract load requests?

It seems like once all the options are done loading, response back from the server is quick for orders, but during the contract load request, it is slow.

Here is some logging all times in MST where the order took 8 seconds to come back as confirmed.

Timestamp: 5/24/2021 1:02:53 PM - Category: 2 - Message: OrderConnection Outgoing: ContractLoadRequestMsg RequestID=10 ResultCount=1000 SkipCount=1000>
Expression>
BaseContractIDCriterionMsg BaseContractID=108396
/Expression>
/ContractLoadRequestMsg>
Starting new order at 5/24/2021 1:02:53 PM
Timestamp: 5/24/2021 1:02:53 PM - Category: 4 - Message: Sending order: Buy 1 NQM21 MKT
Timestamp: 5/24/2021 1:02:53 PM - Category: 2 - Message: OrderConnection Outgoing: CreateSingleOrderMsg>
Single>
Order ID=-1 AccountID=41673 ContractID=277384921 Comments=0$0 Timestamp=5/24/2021 7:02:53 PM
Command ID=-1 OrderID=-1
Version OrderID=-1 Quantity=1 Comments=0$0 BidPrice=13681.5 AskPrice=13682
/Single>
/CreateSingleOrderMsg>
Timestamp: 5/24/2021 1:02:54 PM - Category: 2 - Message: OrderConnection Outgoing: ContractLoadRequestMsg RequestID=11 ResultCount=1000 SkipCount=1000>
Expression>
BaseContractIDCriterionMsg BaseContractID=108398
/Expression>
/ContractLoadRequestMsg>
Timestamp: 5/24/2021 1:02:56 PM - Category: 2 - Message: OrderConnection Outgoing: ContractLoadRequestMsg RequestID=12 ResultCount=1000 SkipCount=1000>
Expression>
BaseContractIDCriterionMsg BaseContractID=108397
/Expression>
/ContractLoadRequestMsg>
Timestamp: 5/24/2021 1:02:57 PM - Category: 2 - Message: OrderConnection Outgoing: ContractLoadRequestMsg RequestID=13 ResultCount=1000 SkipCount=1000>
Expression>
BaseContractIDCriterionMsg BaseContractID=108963
/Expression>
/ContractLoadRequestMsg>
Timestamp: 5/24/2021 1:02:59 PM - Category: 2 - Message: OrderConnection Outgoing: ContractLoadRequestMsg RequestID=14 ResultCount=1000 SkipCount=1000>
Expression>
BaseContractIDCriterionMsg BaseContractID=108564
/Expression>
/ContractLoadRequestMsg>
Timestamp: 5/24/2021 1:03:00 PM - Category: 2 - Message: OrderConnection Outgoing: ContractLoadRequestMsg RequestID=15 ResultCount=1000 SkipCount=1000>
Expression>
BaseContractIDCriterionMsg BaseContractID=2102
/Expression>
/ContractLoadRequestMsg>
Timestamp: 5/24/2021 1:03:01 PM - Category: 0 - Message: 1 NQM21: 2 Bars BarsMsg SubscriptionID=1 Bars=[2]
Timestamp: 5/24/2021 1:03:01 PM - Category: 2 - Message: OrderConnection Outgoing: ContractLoadRequestMsg RequestID=16 ResultCount=1000 SkipCount=2000>
Expression>
BaseContractIDCriterionMsg BaseContractID=108396
/Expression>
/ContractLoadRequestMsg>
Order confirmed at 5/24/2021 1:03:01 PM
Edited by RWare2020 on May 24, 2021 02:12 PM

API Support » GF COM API Prioritize Requests May 21, 2021 @ 02:42 PM (Total replies: 8)

Is there a way to prioritize a request so that it is the first thing that comes back?

For example I am doing a contract load request to load options for a particular symbol. That takes some time for some symbols.

If I try to place an order, it waits for all of the contract load requests to be done before it will process the order request.

This doesn't happen when I am requesting history though, I assume it is because history requests use the PriceConnection and orders/contract load uses OrderConnection.

Is there a way I can send something through the api to prioritize my order request over my contract load requests?

Hope this makes sense.

Thanks.

API Support » GF COM API - Suspended Order State May 19, 2021 @ 04:36 PM (Total replies: 1)

There is a suspended order state in the GF API documentation but there is no order state for suspended within the GF COM API. Will you please add it in there so that we can show orders that are suspended?

Thanks.

Market Data » ZSK21 Stops Receiving Intraday History after First OnBarsReceived Callback May 12, 2021 @ 05:09 PM (Total replies: 42)

We have had 5 reports since Monday with this same issue. Is there a timeframe as to when this will be released to sim/prod?

API Support » GF COM API Reconnecting on Socket Error Disconnection May 11, 2021 @ 12:30 PM (Total replies: 4)

That worked. Thank you very much.

API Support » GF COM API Reconnecting on Socket Error Disconnection May 06, 2021 @ 12:02 PM (Total replies: 4)

When logging into the API I use this code:

I am wondering the correct steps to reconnect to the API when being disconnected.

I am currently just trying to attempt to login the same way I do when initially logging in like this:

IConnectionContextBuilderPtr builder;
builder.CreateInstance(__uuidof(ConnectionContextBuilder));
builder->WithUserName(TNT2);
builder->WithPassword(pass);
builder->WithHost("sim.gainfutures.com");
builder->WithUUID(uuid);
builder->WithPort(9210);
builder->WithForceLogin();
GFApi()->Connection->Aggregate->Connect(builder->Build());

When I get disconnected from the API from a socket error. I get a callback into OnDisconnected in which I run this code again:

IConnectionContextBuilderPtr builder;
builder.CreateInstance(__uuidof(ConnectionContextBuilder));
builder->WithUserName(TNT2);
builder->WithPassword(pass);
builder->WithHost("sim.gainfutures.com");
builder->WithUUID(uuid);
builder->WithPort(9210);
builder->WithForceLogin();
GFApi()->Connection->Aggregate->Connect(builder->Build());

I then get a callback to OnLoginFailed for the fail reason of FailReason_InvalidUserOrPassword.

I use the exact same username and password as I use when I initially login.

Here is the log from OnNewMessageLogged callback when I reconnect with all timestamps in MST:

Timestamp: 5/4/2021 4:07:10 PM - Category: 2 - Message: OrderConnection Connecting to sim.gainfutures.com:9210
Timestamp: 5/4/2021 4:07:10 PM - Category: 2 - Message: OrderConnection Outgoing: Timestamp: 5/4/2021 4:07:10 PM - Category: 2 - Message: OrderConnection Connected to 64.94.37.238
Timestamp: 5/4/2021 4:07:10 PM - Category: 2 - Message: PriceConnection Connecting to sim.gainfutures.com:9211
Timestamp: 5/4/2021 4:07:10 PM - Category: 2 - Message: PriceConnection Outgoing: Timestamp: 5/4/2021 4:07:10 PM - Category: 2 - Message: PriceConnection Connected to 64.94.37.238
Timestamp: 5/4/2021 4:07:22 PM - Category: 0 - Message: OrderConnection Disconnected: System.Exception: by request
Timestamp: 5/4/2021 4:08:54 PM - Category: 0 - Message: PriceConnection Disconnected: System.Exception: by request
Timestamp: 5/4/2021 4:08:54 PM - Category: 0 - Message: Received AuthChallenge from Gain Futures Price Server v4.1.0.0
Timestamp: 5/4/2021 4:08:54 PM - Category: 0 - Message: Received AuthChallenge from Gain Futures Order Server v4.1.0.0

Market Data » ZSK21 Stops Receiving Intraday History after First OnBarsReceived Callback May 06, 2021 @ 11:42 AM (Total replies: 42)

Thank you.

Market Data » ZSK21 Stops Receiving Intraday History after First OnBarsReceived Callback May 05, 2021 @ 05:27 PM (Total replies: 42)

This seemed to start happening around the same time the email was sent out for GAIN Trader and saying that you might be prompted for .NET Framework 4.6.2. Could that have anything to do with this?

Market Data » ZSK21 Stops Receiving Intraday History after First OnBarsReceived Callback May 05, 2021 @ 05:17 PM (Total replies: 42)

I can't quite tell if this is just a coincidence, but if I request interval of 5 minute before 1 minute, it has worked every time to pull in the 1 minute data.

Timestamp: 5/5/2021 4:11:22 PM - Category: 2 - Message: PriceConnection Outgoing: SubscribeMsg Subscribe=Load Type=Bar StartDate=12/31/1899 11:55:00 PM EndDate=5/5/2021 10:20:00 PM Interval=5 SubscriptionID=4 ContractID=276049534

Timestamp: 5/5/2021 4:11:26 PM - Category: 0 - Message: 4 ZSK21: 4096 Bars BarsMsg SubscriptionID=4 Bars=[4096]

Timestamp: 5/5/2021 4:11:26 PM - Category: 0 - Message: 4 ZSK21: 4096 Bars BarsMsg SubscriptionID=4 Bars=[4096]

Timestamp: 5/5/2021 4:11:26 PM - Category: 0 - Message: 4 ZSK21: 0 Bars BarsMsg SubscriptionID=4

Then since we didn't get all of the data, we request again starting with the last date we received:

Timestamp: 5/5/2021 4:11:26 PM - Category: 2 - Message: PriceConnection Outgoing: SubscribeMsg Subscribe=Load Type=Bar StartDate=3/5/2021 12:10:00 PM EndDate=5/5/2021 10:20:00 PM Interval=5 SubscriptionID=5 ContractID=276049534

Timestamp: 5/5/2021 4:11:27 PM - Category: 0 - Message: 5 ZSK21: 4096 Bars BarsMsg SubscriptionID=5 Bars=[4096]

Timestamp: 5/5/2021 4:11:27 PM - Category: 0 - Message: 5 ZSK21: 4096 Bars BarsMsg SubscriptionID=5 Bars=[4096]

Timestamp: 5/5/2021 4:11:27 PM - Category: 0 - Message: 5 ZSK21: 0 Bars BarsMsg SubscriptionID=5


Why does the 5 minute stop early and the 1 minute keep going? Why can't the 1 minute stop sending back data when some memory limit gets hit and then I can request again like I did the 5 minute?

Just so you know, this re-request thing has been in our code for 10 + years so I think this is something that happens often where not all of the data completely gets sent back.

Why does it not send back all the data and can't that happen with the 1 minute data where we can just re-request?
It still doesn't explain why sometimes it works and sometimes does not, but could be a potential fix.
Edited by RWare2020 on May 05, 2021 05:20 PM
Edited by RWare2020 on May 05, 2021 05:20 PM