ERR_ORDER_LOCKED 139 - что за чудовище такое?? - страница 2

Новый комментарий
 
Integer писал(а) >>

Затрудняюсь здесь. Ордер в обработке, а торговый поток не занят. Если один советник работает только со своими ордерами, то не может быть такой ошибки, функции типа OrderSend(), OrderModify() ждут завершения обработки ордера.

Надо будет поэкспериментировать в понедельник, попытаться получить 139.

Держите нас в курсе. Мне тоже интересно знать, как такая ошибка может получится, как ее нужно обрабатывать (хотя рекомендации уже есть) и как этого избежать.

 
Swan >>:

ордера в цикле модифицируются?

возможно тогда поможет

bool Rez=OrderModify(...

и далее в зависимости от возвращенного Rezультата:)


перед торговыми функциями таки желательно проверить IsTradeContextBusy() или IsTradeAllowed().

в зависимости от возвращенного Rezультата:)

... вызываю GetLastError() и печатаю её, либо не вызываю и не печатаю.


Насчёт проверок контекста и разрешения торговли - это конечно полезно но для предотвращения других ошибок (133 и 146).

 
api >>:

[skip]


Я так понимаю, что то, что Вы делаете делать нельзя и Вам советуют перестать это делать. Это Вам советует разработчик и это же Вам советует Ваш брокер.

Правильно понимаете. А именно: если такая ошибка возникла то НЕЛЬЗЯ больше НИЧЕГО делать с этим приказом. К этому должны, как я понимаю, сводиться изменения в логике работы эксперта, которые имел в виду разработчик. Это, конечно, ещё терпимо если речь (как в моём случае) идёт об отложенных приказах. А что делать если приказ уже открылся? Только вручную с ним заканчивать ..:( Ваще конечно было бы очень интересно услышать мнение разработчиков, а то пока мы только то и делаем что гадаем. А ведь кто-то запрограммил это и знает наверняка.


Процессы на сервере происходят независимо от модели поведения Вашего советника и могут растягиваться во времени в зависимости от активности клиентов.

Есть у меня подозрение что именно в этом (в стервере ихнем) и дело.


Еще хотелось бы увидеть исходники Вашего советника. Если жалко - то хотя бы в личку. Если ОЧЕНЬ жалко, то хотя бы места работы с ордерами.

Приведу текст модифицированной функции изменения приказа, который собираюсь тестировать на реале со следующей недели. (На демке как я уже писал этой ошибки никогда не случается по словам моего брокера) Здесь SendMail используется для отправки почты на SMS Gateway, так что если что я должен буду получать пинок на мобилу. Это нужно потому что ЕА крутится на VPSe для пущей надёжности, и звукового сигнала мне никак не услышать :)


Может кому будет полезно.

bool safe_order_modify(int ticket, double price, double stoploss, double takeprofit, datetime expiration, color arrow_color=CLR_NONE)
{

if (!OrderModify(ticket, price, stoploss, takeprofit, expiration, arrow_color)){

int err = GetLastError();


Print("ERROR: Can not OrderModify(",ticket,",",price,",", stoploss,",",takeprofit,"...); Reason: ", err_description(err));


if (err == 139) { //ERR_ORDER_LOCKED

eject = true;

if (ticket == active_ticket)

SendMail("SMS Gateway", "DANGER! IMMEDIATE ATTENTION REQUIRED.");

else
SendMail("SMS Gateway", "Attention required.");
}
return (false);
}
return (true);

}



 
Integer >>:

Сколько советников на счете? Параллельно руками что-нибудь делали?

Советник один. Руками параллельно с советником торговых операций не делалось. Правда, доступ к графику и счёту осуществлялся с двух компьютеров одновременно: на одном (VPS) работал советник а с другого (обычного десктопа) просматривался счёт, выбирались разные пары, таймфреймы, и т.д. Но главное то что параллельных операций со счётом небыло.

 
rdim >>:

в зависимости от возвращенного Rezультата:)

... вызываю GetLastError() и печатаю её, либо не вызываю и не печатаю.


Насчёт проверок контекста и разрешения торговли - это конечно полезно но для предотвращения других ошибок (133 и 146).

GetLastError() это констатация ошибки, действия советника должны менятся.

приведенный код ни о чем. Поздно пить боржоми, когда почки отвалились.

ERR_ORDER_LOCKED 139 Ордер заблокирован и уже обрабатывается. Необходимо прекратить все попытки торговых операций и изменить логику программы.

таки проверка IsTradeContextBusy есть и не спасает?

 
rdim писал(а) >>

Советник один. Руками параллельно с советником торговых операций не делалось. Правда, доступ к графику и счёту осуществлялся с двух компьютеров одновременно: на одном (VPS) работал советник а с другого (обычного десктопа) просматривался счёт, выбирались разные пары, таймфреймы, и т.д. Но главное то что параллельных операций со счётом небыло.

Если на втором компьютере советник точно не торгует, поищите, может быть на VPS терминал два раза запущен.

 
rdim писал(а) >>

.

Этого кода для анализа не достаточно. Можно посмотреть тот участок кода, который вызывает функцию safe_order_modify?

 

Про уровень фриза не забывайте тож...

Он порой сравним со стопами, и даже более.

т.е. по условию стопов ордер и проскочил, открылся, а тут раз и нате -спред, и он уже в "зоне" фриза.

 
kombat писал(а) >>

Про уровень фриза не забывайте тож...

Он порой сравним со стопами, и даже более.

т.е. по условию стопов ордер и проскочил, открылся, а тут раз и нате -спред, и он уже в "зоне" фриза.

Там другая ошибка вроде бы:

ERR_TRADE_MODIFY_DENIED 145 Модификация запрещена, так как ордер слишком близок к рынку и заблокирован из-за возможного скорого исполнения. Можно не ранее, чем через 15 секунд, обновить данные при помощи функции RefreshRates и повторить попытку.

 

Вообще, хотелось бы от разработчиков пояснений по ошибке 139.

Если ордер обрабатывается по торговому приказу от терминала, то терминал занят, и ничего мы получить не можем, пока обработка не кончится.

Следовательно он обрабатывается по хотелке не от терминала. Так? Т.е. сервер чего-то решил с ним сделать. Что? Ну предположим, что положено. Но тогда обращение по торговому приказу опять же не должно быть завершено, пока не получен ясный ответ: или ордер не найден, или там цена близко и т.д.

Тогда что же это такое, 139?

123456
Новый комментарий