Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Sun, 05 May 2024 06:16:25 +0000
Post From: Flatten and cancel
| [2014-03-14 01:11:13] |
| User35525 - Posts: 180 |
|
Dear SC, Thanks for taking a look. I understand that you don't have time to investigate everybody's trade activity log extensively. I do have a couple specific questions now, after doing some more research. You said: The only thing unusual we saw was an order with internal order ID 797, when canceled went to a "pending open" status and then to a "filled" status but did not seem to generate an actual fill.
What do you mean by "did not seem to generate an actual fill"? From what I can tell looking at earlier log entries (for example the above T4 stop trigger (8:18:14.000, 8:18:14.001, 8:18:14.003), it is normal for T4 order updates, on a stoploss, to first show as "Pending Open", then "Open", then finally "Filled". Order ID 797 is doing the same (goes from "Pending Open" to "Filled" at 9:09:18.002 and 9:09:18.003). The problem that I see is my "flatten and cancel" first happens. Sierra Chart sees that at 9:09:18.000 and 9:09:18.001 and logs "Cancelling all orders" (this works on ID 797) then "Auto-Trade: ....Flatten&Cancel" (this starts a new internal order ID 798). And then immediately afterwards, T4 stops me out at 9:09:18:003, while Sierra Chart continues working on the flatten and close (order ID 798) by submitting three T4 updates (market Buy 3). I'm sure T4 will concur after I show them the ServiceOrderID's for internal order ID 798 (I still need to check my official "fills" as you said). Next steps: I will follow-up with T4 just so I have done all the due diligence possible, then I'll update SC to the latest version that uses FIX. But, I'm still perplexed why you say the flatten&cancel had nothing to do with the problem. When I asked about a race condition you wrote: We do not see a problem with that. It's clear from the log that order ID 798 originated with the flatten&cancel action at 9:09:18.001, and it's clear that there is some sort of "race condition" that caused SC to attempt to close a position that T4 had already closed a few millisecond earlier at 9:09:18:003. So T4 closes the position, THEN Sierra Chart tries to close it again.And now I know why some users must disable server-managed OCO's. If I let SC completely manage the OCO's, I guess this issue cannot happen because SC won't have any race condition to monitor (SC will be handling ALL the entries and exits and won't have to watch for broker-initiated attached orders). This looks to me like a serious problem with CTS server-side OCO's and Sierra Chart, but maybe it only pertains to SC 997. From your earlier response I understand that this is probably a rare event, and from the fixes on the "what's new page" I'm guessing the problem may have been fixed. Best Regards, Ted Date Time Of Last Edit: 2014-03-14 01:14:27
|