The trade context is busy error causes nightmares for scalpers and high frequency traders. MetaTrader chokes when they open up too many charts or place too many order. The problems stem from how MT4 processes and receives information from the broker server.
The OrderSend() command, which MQL programmers use to open a trade, also tells the MT4 client terminal to await a server response. Everything locks up. The code cannot do anything until the server permits the client terminal to continue. More importantly, the trading terminal does not allow any additional trades to open.
Consider a scenario where you trade EURUSD, AUDUSD and USDJPY currency pairs on H1 charts. MT4 must await an incoming tick before MQL allows it to make a trading decision. I discussed this issue several months ago with time based orders.
The ticks of multiple currencies often group together during liquid hours. If the terminal receives the incoming ticks within a few hundred milliseconds of each other, MetaTrader creates its own bottleneck.
The AUDUSD tick comes in first. The Expert Advisor sees a trading opportunity and decides to open an AUDUSD trade with OrderSend(). 150 ms later a EURUSD tick comes in and creates another trading opportunity. The EURUSD EA, which runs on a completely different chart, is not allowed to trade.
Retry delay for Trade Context is Busy
Our Expert Advisor programmers check for “Trade Context is Busy” errors before sending orders to the broker. When the situation exits, the EA checks the trade context every 50 ms up to 50 times.
It is not uncommon for MetaTrader orders to take a second or more to execute. The original AUDUSD trade from our example is still hanging out there. The EURUSD EA enters a 50 ms cycle where it constantly asks, “Did the trade context open up?”
Then the USDJPY tick comes in 70 ms after the EURUSD tick. USDJPY encounters the same trade context issue, kicking it into a separate, “Is the trade context busy” loop.
When the AUDUSD trade finally executes, it leaves the EURUSD and USDJPY expert advisors in a frantic race to discover the newly opened trading window. The first EA that discovers that the trading context busy error disappeared will send its request first. The second EA, unfortunately, cannot communicate with the first. Although the second EA will discover that the trade context opened up, it will receive a trade conext is busy error when it attempts to trade; the firs EA already sent a trading request. The second expert advisor allots itself a maximum of 10 failures before it gives up on the trade.
Assuming that the EURUSD discovers the new trading window first, then the USDJPY receives its first failed order attempt. The USDJPY once again inquires about the trading context every 50 ms. The EURUSD trade eventually executes, allowing the USDJPY to finally enter the market.
Most of our customers never notice this delay, which means that we did our job. There is, however, a breaking point where MetaTrader simply cannot issue enough orders at the speed the trader desires. Any combination of charts where 10 or more orders go off near-simultaneously will result in missed trading opportunities.
MetaQuotes designed MT4 with the trade context error in order to limit the processing requirements of the brokers. As I’ve stated repeatedly, the brokers get MetaQuotes’ preferential treatment because they are the ones paying MetaQuotes’ fee. MetaTrader is not a high frequency trading platform. It’s not in the broker’s interest to support high speed trading. It usually opens them up to too many traders taking advantage of arbitrage opportunities.
The “Trade context is busy” error will only occure depending on which broker you use. And this is even using the same EA’s working together completing the same trades. The Trade Context is Busy can wipe out your money, because it causes the draw down to get larger. You should choose a broker that will allow trading.
dMM() Michal says
let me drop a few words on MT4 multi-thread design.
The Hi-Frequency & Scalping startegists and all manual Traders altogether shall be aware, that MT4 shares only one common-logic thread for trading OPS. This simplified the MT4 core-design at MetaQuotes (forgive me to point at the very source of real-world problems noticed below ), but complicates our lives as we all strive to live in a near-real-time execution loops to crawl the FOREX market events.
So, once a Trader moves past a landmark of a few manual trades per week, the near-real-time issues grow and become more painfull.
As a rule of thumb, one shall continuously monitor the QoS of the Brokerage Service she/he has contracted to use.
The End-To-End nature of the Trading Ops introduces the following bottlenecks / single-point-of-failure(s):
a) a MT4_Terminal thread contention — ref. MQL4 IsTradeContextBusy() test. I personally prefer to continuously monitor / measure / log this, to map the ability of my Brokers ( the Vendors of the access to the FOREX Market ) to accept + transact + execute my orders in near-RealTime mode. ( ask for detailed statistics in LDF()/GDF() graphs & RT-measurement tools )
b) a to MT4-Server comms path — ref. IP networking / E2E latency / first-mile UpStream congestion / traffic-concentrator ( aggregator ) grooming factor / FUP policies etc ( for non-DataCentre hosted MT4-Terminal )
c) a MT4-Server work-load / load-balancing — ref. GetLastError() / ERR_TRADE_TIMEOUT / ERR_SERVER_BUSY / ERR_TOO_MANY_REQUESTS / ERR_TOO_FREQUENT_REQUESTS
d) a to MT4_Terminal comms path — ref. IP networking / E2E latency / last-mile DownStream congestion ( for non-DataCentre hosted MT4-Terminal )
For any near-RealTime scenarios, it is wise to measure and collect RT-data about communication with the Broker .
Statistics about these E2E transactions are vital to know beforehand,
whether one may rely on a Broker Data-processing capabilities and execute Trading OPS within a few tens of [msec], or have to wait hundreds of [msec] or ( believe it or not ) whether you have to expect more than 2 – 6 seconds, to get your MT4-Terminal Trading thread ready ( released free from aTradingContextBUSY.state back again ready to study and serve another Trading Operation “in-the-queue”.
Supposing one may imagine, how painfull this can be once you manage some 10, 20, 50 Orders under some tight conditions under your intensive order-management technique and how thrilling under that condition would be to have to wait for 20 – 60 seconds for each of them to get modified / closed at the side at your under-performing Broker machine(s).
Think – Measure – Log – Evaluate – Act
Change your connectivity provider / your hosting provider / your broker — it is all about money
The only one, who risks money is You,
You do risk
( but need not to risk so much )
Upon implementing a correct set of wise and preventive measures that allow you to put in place those necessary improvements in due time you can avoid a risk to lose just due to a blind belief, while an underperforming End2End Transaction Processing chain threatens your Trading Ops not only during fundamental Market events, but systematically 24/5/365
dMM() Michal / msLIB.*
dMM() Michal says
( oops, the text has lost some words due to embedded pseudo-HTML formatter & thus some hints have got lost the point … sorry for the inconvenience, no option to preview / re-edit the post. My fault not to realize that — if interested, use my email to get it fixed )
The Trade context is busy” will not allow you to close a profit trade by hand.