What the logbook entry means - page 4

New comment
 
And I haven't checked OrderModify yet :(
And pending orders:((
 
So it's been quite a long time, a few days. During this time, several experts have managed to work. Here are the logs (the code generating these logs is above). Still waiting for at least some response from developers. At least on the level of "we acknowledge the problem, let's fix it".

Log 1:
Trying to buy, attempt 0 failed, error 6
Trying to buy, attempt 1 failed, error 129
Trying to buy, attempt 2 failed, error 129
Trying to buy, attempt 3 failed, error 129
Trying to buy, attempt 4 failed, error 129
Zigzag buy error: 4050
2.28000000, 0.02700000, 0.00000000
Trying to buy, attempt 0 failed, error 6
Trying to buy, attempt 1 successfull

Order was opened at the 7th attempt. Several error messages were received along the way and had nothing to do with reality.

Log 2.
7.9.2005 11:0:15, Signal: sell7.9.2005 11:0:15 Trying to sell, attempt 0.
Ask: 1.24820000, StopLoss: 0.00600000, TakeProfit: 0.00000000
failed, error 6
7.9.2005 11:0:15 Trying to sell, attempt 1.
Ask: 1.24820000, StopLoss: 0.00600000, TakeProfit: 0.00000000
successfull

On the second try. Mistake number six was the subject of a whole branch, more than one hundred posts. Following advice of the developers, Rosh and Composter, the error frequency was reduced from "once in a while" to "about once in five". But it's still there.

Log 3.
Attempting to close long position, ticket: 1784257
6.9.2005 12:0:13 Order with this ticket still present, trying again
6.9.2005 12:0:13 Order with this ticket still present, trying again
6.9.2005 12:0:13 Order with this ticket still present, trying again
6.9.2005 12:0:13 Order with this ticket still present, trying again
6.9.2005 12:0:13 Order with this ticket still present, trying again

Five failures, there was NO error code. Program thought that position was closed. I was catching the ticket in the loop, if I didn't, the problem wouldn't be detected.

And so on.
 
Make it like this
<br / translate="no"> void CloseBuy(string strExpertName)
{
int nTicket = OrderTicket();
SaveComment("\r\n\tAttempting to close long position, ticket: " + nTicket);

int nResult = OrderClose(OrderTicket(), OrderLots(), Bid, nSlip, Aqua);

Sleep(10000);

if(nResult == -1)
{
int nError = GetLastError();
Alert(strExpertName + ", error: " + nError);
}

}


I had to use a quote to make the text bold.
 
If this is done, it is likely to mask the error. And the goal is to help developers find it, so that everything works without loops at all.

The point of Sleep is just to wait until the condition causing the failure is gone (you know, pings start going through). Because - taking into account that trade operations "take" control and don't let it go until they come back, then if there is an error, it should show up immediately. If not - it's a bug.

The only possible exception is my loop checking for a ticket of a just closed position. But even here we can argue how the system should ideally behave.

Again, the problem is not only that the errors RETURNED, but also that the error codes are taken from the ceiling, and sometimes there are no codes at all - the operation's success code is returned.

If I don't understand something, please explain.
 
Explanation. Under the terms of one Expert Advisor, if the current Ask price exceeds the stop loss of a pending sell order, a series of actions are performed:
1. An SMS is sent informing of the intention to remove such an order.
2. An attempt to cancel the order is made
3. The result of the OrderDelete() function is analysed and if it is negative (the order has not been removed), then
4. It sends a SMS confirming failure.

Yesterday we got 2 SMS, everything according to the rules but the order was canceled at the same second, according to the logs.
So the EA was trying to get the result of the order cancellation operation some fraction of a second earlier than it got the result. It's like in the joke about the Chinese who planted potatoes and then dug them up the next day. When asked "Is it ripening that fast", they'd say "No, but it's biting" :)
 
Understood, BUT:
1. I made this whole fuss about the actual orders. And if they behave like that, it needs to be fixed.
2) The idea is that MT EAs should be able to trade WITHOUT a delayed cycle. This is how it should be.
I will put a delay, but, as they say, "without pleasure" :)
 
I've been thinking to myself. If I suggest using a pause between the order modification operation and check results of this operation, it means that I am assuming asynchronous working of the EA. It means that we send a request to the server trying to modify the order and then, without waiting for the reply, the Expert Advisor continues its work according to the algorithm. By default, a negative reply is given to the Expert Advisor until it gets a reply from the server. If the reply is received, the reply is real, but if it is not, the reply is virtual.

I don't believe it myself, can the developers explain how wrong I am?
 
A consensus has been reached. But I have put in a pause - just to be sure. At least, before checking the availability of the ticket of a just closed order, the database on the server may be accessed, we should give it time to refresh. Although it is wrong :)

Somewhat embarrassing is the fact that for 37 posts in this thread there is only one from the developers...
 
It's a bit disconcerting that there's only one developer post in 37 in this thread...

why interfere with an already productive discussion
 
why interfere with an already productive discussion

and here are the products =)

Did some testing. One Expert Advisor opens and closes a position (alternately buy and sell). Minimum pause between all trades - 10 sec.

Testing time (by Alpari): 02:00 - 09:30 (i.e. 7.5 hours)
OrderSend attempts: 996
Successful*: 888
Errors**: 108

* - By "successful" attempt I mean the following: orderSend returned ticket no., GetLastError returned 0, open position successfully selected orderselect.
** - All errors #148 "trade context is busy" - that's what Slava asked about in a neighbouring thread - "what if we disable isTradeAllowed check?". The errors started at 07:16:46 and are still piling up)

-----------------------------------------------------------------------------------------------------------------------

OrderClose attempts: 890
Successful*: 736
Errors**: 154

* - by "successful" close attempt I mean the following: orderclose returned true, GetLastError returned 0, closed position successfully selected orderselect in mod_history.
** - 152 error #1 "no error", one #6 and one #138(requotes)


The situation that was caught didn't happen. I.e. all closed positions were indeed closed.
1234567
New comment