API Support Forum
OEC API > API Support > GF COM API Prioritize Requests
Author Topic: GF COM API Prioritize Requests
(9 messages, Page 1 of 1)
Moderators: VPfau
RWare2020
Posts: 118
Joined: Feb 11, 2020


Posted: May 21, 2021 @ 02:42 PM             Msg. 1 of 9
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.
SPikalov
Posts: 14
Joined:


Posted: May 24, 2021 @ 05:02 AM             Msg. 2 of 9
There is no direct connection between when you sent a request and when you received a response.
Our servers process your requests and return the result as soon as they are ready.
For example, there is no direct relationship between the processing speed of requests for contracts and orders.
So,
“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.”
It doesn't make sense.

Regards,
Sergey
RWare2020
Posts: 118
Joined: Feb 11, 2020


Posted: May 24, 2021 @ 02:11 PM             Msg. 3 of 9
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
SPikalov
Posts: 14
Joined:


Posted: May 26, 2021 @ 09:29 AM             Msg. 4 of 9
You are right, in some cases, the subsequent request is waiting for the processing of the previous ones.
Loading contracts is just such a case.
We do not currently support a prioritization mechanism for requests.
But we will consider the possibility of improving our system.

Regards,
Sergey.
RWare2020
Posts: 118
Joined: Feb 11, 2020


Posted: May 26, 2021 @ 12:16 PM             Msg. 5 of 9
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.
SPikalov
Posts: 14
Joined:


Posted: May 27, 2021 @ 01:58 AM             Msg. 6 of 9
I can advise you the following:
Send a subsequent request to contract load only after you have received a response to the previous one.
RWare2020
Posts: 118
Joined: Feb 11, 2020


Posted: May 27, 2021 @ 11:41 AM             Msg. 7 of 9
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."
CMicciche902
Posts: 318
Joined:


Posted: May 27, 2021 @ 04:45 PM             Msg. 8 of 9
I have requested our developers add a prioritization feature in a future API release.
Chris M
RWare2020
Posts: 118
Joined: Feb 11, 2020


Posted: May 28, 2021 @ 10:59 AM             Msg. 9 of 9
Thanks.