I have been testing MC to IB trade automation for the past month. Approximately, once per week for the past three weeks I have encountered a problem where IB did not return the final status of an order in a timely fashion. Because of this, MC thinks the order is lost so it resubmits the order. This is repeated 5 - 10 times. So, I am left with position sizes that are 10 times what they should be and am plunged into such a deep margin position that all subsequent orders are rejected. Thankfully, I have been working in a demo account.
I would like to hear from anyone else that has experienced this problem. This is not a MC problem, it is an IB problem. Apparently, IB has only recently confirmed and acknowledge that this problem exists. I don't see how they could say otherwise anyway as I was able to capture the problem happening while recording detailed logs through TWS.
When I asked them when they expected to have a solution for this they gave me a very uncommitted, I dunno. To me this is an unacceptable response for a problem that can create such a dangerous series of events.
So, if you have been experiencing anything like this as well, please let me know as the more people that report it, the more likely we are to effect a timely fix.
Serious Order Status Problem with IB's API
Re: Serious Order Status Problem with IB's API
I had similar experience once while using ib gateway and mc64bit and MC keeps on firing orders and failed to pick up trades until I turn off autotrading. The issue probably arises from the latency of ib gateway because I didn't install java64bit in my computer. However, using ib tws seems to be OK so far.
Re: Serious Order Status Problem with IB's API
We experience the same problem.
And contacting both MC and IB, we have the same discussions you have detailed here.
It seems like a Chicken and Egg problem.
IB does have a reporting delay problem, but MC resubmits the order.
Our recommendation to MC was for MC to allow us to control the timeout of when orders are considered lost. Therefore, we can set that at a very high number of seconds to effectively turn off this resubmission of the order. We were told that this is being considered and may get on a list of improvements for a future release.
But we haven't found a better way in the interim to handle this problem, yet. Other than using a synchronizer to correct the problem immediately if the position grows beyond an acceptable threshold.
And contacting both MC and IB, we have the same discussions you have detailed here.
It seems like a Chicken and Egg problem.
IB does have a reporting delay problem, but MC resubmits the order.
Our recommendation to MC was for MC to allow us to control the timeout of when orders are considered lost. Therefore, we can set that at a very high number of seconds to effectively turn off this resubmission of the order. We were told that this is being considered and may get on a list of improvements for a future release.
But we haven't found a better way in the interim to handle this problem, yet. Other than using a synchronizer to correct the problem immediately if the position grows beyond an acceptable threshold.
I have been testing MC to IB trade automation for the past month. Approximately, once per week for the past three weeks I have encountered a problem where IB did not return the final status of an order in a timely fashion. Because of this, MC thinks the order is lost so it resubmits the order. This is repeated 5 - 10 times. So, I am left with position sizes that are 10 times what they should be and am plunged into such a deep margin position that all subsequent orders are rejected. Thankfully, I have been working in a demo account.
I would like to hear from anyone else that has experienced this problem. This is not a MC problem, it is an IB problem. Apparently, IB has only recently confirmed and acknowledge that this problem exists. I don't see how they could say otherwise anyway as I was able to capture the problem happening while recording detailed logs through TWS.
When I asked them when they expected to have a solution for this they gave me a very uncommitted, I dunno. To me this is an unacceptable response for a problem that can create such a dangerous series of events.
So, if you have been experiencing anything like this as well, please let me know as the more people that report it, the more likely we are to effect a timely fix.
Re: Serious Order Status Problem with IB's API
The way MC currently deals with this issue quite frankly is irresponsible. This problem will lead to serious losses for traders if it is not fixed.
It's encouraging though to hear that MC has acknowledged the issue and has committed to dealing with it with a timeout. The resubmission of orders when order status is delayed is just downright dangerous.
Let's hope they keep to their word and include a timeout session for us to set.
MC, please add this ad this is a really crucial feature that will save traders from potentially serious losses.
It's encouraging though to hear that MC has acknowledged the issue and has committed to dealing with it with a timeout. The resubmission of orders when order status is delayed is just downright dangerous.
Let's hope they keep to their word and include a timeout session for us to set.
MC, please add this ad this is a really crucial feature that will save traders from potentially serious losses.
Re: Serious Order Status Problem with IB's API
This should be a good compromise type of solution. I think this allows traders to decide what's best for them.
It's the least invasive way because some other traders may depend on the resubmitting of "lost" orders in their configurations or synchronous trading. And even then, it would be good for those traders to decide what is a reasonable timeout for lost orders in their individual cases.
This one issue has caused some grief for us with some projects. Hopefully this is good news, and if implemented by MultiCharts in the next releases, it's a really good response to solving this problem.
It's the least invasive way because some other traders may depend on the resubmitting of "lost" orders in their configurations or synchronous trading. And even then, it would be good for those traders to decide what is a reasonable timeout for lost orders in their individual cases.
This one issue has caused some grief for us with some projects. Hopefully this is good news, and if implemented by MultiCharts in the next releases, it's a really good response to solving this problem.
The way MC currently deals with this issue quite frankly is irresponsible. This problem will lead to serious losses for traders if it is not fixed.
It's encouraging though to hear that MC has acknowledged the issue and has committed to dealing with it with a timeout. The resubmission of orders when order status is delayed is just downright dangerous.
Let's hope they keep to their word and include a timeout session for us to set.
MC, please add this ad this is a really crucial feature that will save traders from potentially serious losses.
- Henry MultiСharts
- Posts: 9165
- Joined: 25 Aug 2011
- Has thanked: 1264 times
- Been thanked: 2957 times
Re: Serious Order Status Problem with IB's API
Indeed, the problem does not come from our end, the problem is on the broker end.This is not a MC problem, it is an IB problem.
Your statements are unclear to me. We have reported this problem to IB and received the same feedback as you have received-no reaction. Though we are still trying to make IB to react to this issue.The way MC currently deals with this issue quite frankly is irresponsible.
In the meantime, (working closely with you on the issue) we have added the registry key to increase the timeout for waiting final status of the order. So please do not spread false information.
The solution you would be provided for testing will go public in MultiCharts 8.1