Hello Support,

today I encountered a strange problem regarding the handling of the IOrder close method.
Here are my questions:
1) Is it possible that after sending a close command, the order gets in state CANCELED? If so, does this mean that the order was closed or is it still filled?
2) Is the closing always independent of the slippage parameter which was sent with IEngine submitOrder? Or can the closing be rejected when the negative slippage is too high?
3) Gives a succesful closing command always a non empty IMessage back?
4) Can you please provide a short example on how to do three retries for closing an order correctly?

My current approach is not sufficient to handle all possibilities:

public boolean closeOrderWithRetries(IOrder order) {
        for (int i = 0; i < 3; ++i) {
            IMessage messageResult = null;
            try {
                messageResult = order.waitForUpdate(2000, IOrder.State.CLOSED);
            } catch (JFException e) {
                logger.error("An error occured while waiting for order to close!");
                continue;
            }
            if (order.getState() == IOrder.State.CLOSED) {
                return true;
            }
            else {
                logger.warn("Waiting for order " + order.getInstrument() + " to get in state " + IOrder.State.CLOSED + " failed!");
                if (messageResult == null || messageResult.getContent().isEmpty())
                    logger.warn("No message provided!");
                else
                    logger.warn("Message for order is: " + messageResult.getContent());
            }  
        }
        return false;
    }

Thank you for help,
Juergen

Locate in the diagram the OPENED state and see the blue ractangle on the right of it:
https://www.dukascopy.com/wiki/#Order_st ... es_diagram
Also see the following example which shows all possible close types:
https://www.dukascopy.com/wiki/#Close_Orders/Order_close_and_cancel_workflow
See:
https://www.dukascopy.com/wiki/#Close_Orders
See our reply to 1).
See retries of order submit:
https://www.dukascopy.com/wiki/#Manage_Order_State/Resubmit_order_
https://www.dukascopy.com/wiki/#Manage_Order_State/Resubmit_order

Hello Support,

thanks for the state machine diagram.
I have another question in this conext; consider the following scenario:
1) User wants to BUY an instrument and submits the order
2) Server does not confirm within 10 seconds, i.e. order state is not filled yet.
3) User wants to cancel this BUY order with order.close() command.

Is it possible to close/cancel orders in state CREATED/OPENED after a specific waiting time?
What does now happen on server side? Can it happen that the order is filled right before the close/cancel command arrives or the other way round?
So my guess is that this is not deterministic.
The parameter

goodTillTime 

is not applicable for BUY or SELL commands.
Is there any way the user can tell the server to drop a BUY/SELL order after a specific timeout if the order is not in FILLED state?

Thanks,
Juergen

To be precise, at first there is OPENED and only then the FILLED state (which for market orders arrives shortly after OPENED), thus in your scenario the server has not accepted the order.
You can't cancel a request that has not arrived to/confirmed by server yet.
For CREATED see the previous point. For OPENED - Market orders workflow does not permit you to cancel the order before the fill, you can do this only with conditional orders. However, if you will try to do this, it is very possible that the order already will have been filled on the server side, thus your cancel request will get rejected. In fact it is quite straightforward to check this:

    public void onStart(IContext context) throws JFException {
        context.setSubscribedInstruments(java.util.Collections.singleton(Instrument.EURUSD), true);        
        IOrder order = context.getEngine().submitOrder("MarketOrder", Instrument.EURUSD, OrderCommand.BUY, 0.1);
        order.waitForUpdate(2000, IOrder.State.OPENED);
        order.close(); //Note: against the market order workflow
    }

See above.
It is deterministic if you write your code according to the given workflow.

So, in short this means that once a market order is in OPENED state the only thing one can do is for example to repeatedly wait for an order update message and to inform the user that the respsonse from the server is still pending?

First of all, you don't need to "repeatedly wait" - you can use onMessage for such purpose - you inform the user as soon as you get the message. And second, the transition between OPENED and FILLED for market orders is almost instant, hence, regarding market orders it is FILLED state that you are only interested in.

Ok, tanks for the explanation.
One last thing regarding the state diagram:
My strategy waits for the combination FILLED/ORDER_FILL_OK, but I only get FILLED/ORDER_SUBMIT_OK which cannot be true for the given diagram.
I work with 2.9.10.1.

If you are doing a lot of "really fast stuff" then you can consider
building a "pacing controller". This would keep the timestamp
of the last operation performed on EACH outstanding order, and would
help you to enforce the 1 second mandatory minimum delay
for multiple operations on a SINGLE order.

For example, to "bump" the price of a limit order, you cannot
do this for a GIVEN order, more often than once per second.
This restriction applies only on a per-order basis, not globally.

If you have a dozen orders, you can shift all of them in price
instantly, but need to make sure that for a PARTICULAR order,
that you respect the "pacing" requirement, and just wait
precisely >1000 msecs before the prior order operation
before attempting the next one.

HyperScalper

Could you please provide a trivial example strategy which replicates this?

I think the answer is that orderUpdateWait on a DEMO account immediately returns.
This somehow confuses my strategy, since on my LIVE account everything works as depicted in the state diagram.

Thanks,
Juergen

If your strategy correctly uses our API there should be no such fundamental difference. If you would post your example strategy here, we could advise you how to improve it.