hi Support,

I want to merge order A and order B

order A and B has a stop loss just before the merge operation.

according to the documentation I'm required to cancel the stop loss on order A/B before the merge operation.

do I have to wait for confirmation on the stop loss cancellation (ORDER_CHANGE_OK) before performing the merge:

originalStopLoss = orderA.getStopLossPrice();
orderA.setStopLossPrice(0);
orderB.setStopLossPrice(0);
//wait for ORDER_CHANGE_OK on both order A and order B
//once we got confirmation let's do the merge:
orderC = engine.mergeOrders("mergedOrder", orderA, orderB);
orderC.setStopLoss(originalStopLoss);


or - can I send the instructions in serial mode without the "wait" part - without the server rejecting the merge:

originalStopLoss = orderA.getStopLossPrice();
orderA.setStopLossPrice(0);
orderB.setStopLossPrice(0);
orderC = engine.mergeOrders("mergedOrder", orderA, orderB);
orderC.setStopLoss(originalStopLoss);

You should await a positive server response (i.e. ORDER_CHANGED_OK) and only then proceed, read more here:
https://www.dukascopy.com/wiki/#Manage_Order_State

There is no documentation / state diagram that shows ORDER_CHANGED_OK - please provide a state diagram that include merge operations

Basically - implementing a merge operation is kind of a distributed long running transaction. Can be very tricky/complex to handle all conditions. Things can go wrong/ rejected along the way. Dealing with roll back etc.

Please provide full example of how to deal with:

position A with stop loss and take profit
position B with stop loss and take profit
cancel stop loss on A and B
cancel take profit on A and B
merge A and B
if Flat --> do nothing
if not flat --> update stop loss and take profit of merged position

please do not use waitForUpdate in the example --> please use onMessage to handle position state management.

10x

There is a diagram for this - under Get Started/Diagrams/Merge Order States, also there is link from Merge positions article:
https://www.dukascopy.com/wiki/#Merge_Positions
Also in the same article find examples how to deal with SL and TP in case of order merge.

thank you for updating the links in the Wiki and adding more examples!

Using waitForUpdate is not acceptable in my case.

In the example - you might wait max 4 seconds just to remove take profits and stop loss.

After that - you wait additional max 2 seconds for merge.

Finally you wait additional max 2 seconds for merge order SL/TP update.

Total of max 8 seconds of unstable state --> very risky

For example - what happen if one of the waitForUpdates is timed out - how do you deal with roll back?

The dangerous thing about this entire procedure is that you might find your self in a scenario where the two original orders are left naked without any stop loss protection.

You must treat this as a distributed long running transaction and handle roll back.

Please provide the same example using IStrategy.onMessage handling without any IOrder.waitForUpdate

Please provide code for dealing with roll back --> when something goes wrong in the middle of the merge process. How to do that?

See javadocs of IOrder.waitForUpdate:
https://www.dukascopy.com/client/javadoc/com/dukascopy/api/IOrder.html#waitForUpdate(long)
- the method Blocks until order changes it's state, values or until timeout is elapsed (unblocks when system receives any message related to this order).
IOrder.waitForUpdate with two parameters returns an IMessage and depending on its Type you can vary your strategy logic. Also you can do without checking the IMessage with just checking the order data after the execution of IOrder.waitForUpdate - whether the order has been filled, order has been closed, stop loss has changed, etc.

It is possible to be blocked for many seconds according to your suggested implementation (serial workflow)

As an example - Why can't we cancel the stop loss and take profit in parallel?

During the waitForUpdate, strategy thread is blocked --> processing of new ticks is not done. Loosing data which is critical for other open positions.

Please provide the same implementation without the usage of waitForUpdate.

Please refer to the documentation.
Because in the current implementation the server does not support that.
IOrder.waitForUpdate time choice is up to you. Mind that the last tick always "survives", for more on this, see: https://www.dukascopy.com/wiki/#onTick_execution_policy
We don't deliberately provide anti-pattern API solutions unless they serve as workarounds. If you find this crucial, consider applying similar approach to this:
https://www.dukascopy.com/wiki/#Manage_Order_State/Stop_loss_update_on_fill_with_queue

hi Support,

Please consider the below words in a positive and constructive manner. I do not mean to offense, I think that Dukascopy SDK support team is one of the best out there in the retail business. I'm just looking for answers and solutions which are acceptable on both parties.

From the waitForUpdate documentation:



So in theory - I could be blocked for the max timeout period. In your example code 2 seconds per waitForUpdate. So in theory - I could be blocked for total 8 seconds. Things can go wrong. Network, Server or other issues might delay the response.

I don't see in your code example how you deal with such issues. For example - one order SL reset is OK, the other order SL reset fails. --> Merge fails. Now what? We have one order with no SL. How to protect from such scenario? We should always design for failure - as Werner Vogels (CTO @Amazon) said "...Everything fails, all the time"

How do I deal with other open positions during that time?


From the documentation:



I cannot afford to implement a system which by design looses ticks, bars and messages. Maybe it is ok with other clients but not for my purpose. Please provide a more robust solution without data loss inherent by design.

In extreme conditions - the documentation even state that the strategy might stop working all together:



That is not acceptable. I need a non blocking solution.

You said:


I can only say that the biggest ani-pattern when working in a single threaded model is using blocking code. Since the architecture of JForex is based on a single processing thread (Strategy thread) - the usage of methods such as waitForUpdate should be completely avoided .

Finally you said in regards to sending parallel SL updates on OrderA and orderB:



Please provide more info - I know that for the same order there couldn't be SL consecutive updates in less than 1 second and that is ok. But why do you say that I cannot send parallel SL updates for two separate orders? what would happen in that case?

Yes, but on the other hand, in the most of the technical issues you mentioned there would also be problems with data feed - you would not receive bars, tick in either case.
Because the main goal of the examples is not to exhaustively cover the possible execution branches, rather be as simple and comprehensible as possible.
Check the message type you receive and if it is *_REJECTED then repeat the particular action, as it is done in (see onMessage examples in the same article to apply similar logic by using onMessage):
https://www.dukascopy.com/wiki/#Manage_O ... bmit_order
Did you take a look at the example we posted in the previous reply?
https://www.dukascopy.com/wiki/#Manage_O ... with_queue
It becomes blocking if misused or there are some technical problems - thus you just have to use it judiciously.
We did not say that - we said that there is no method that updates TP and SL in the same request. You can send two requests one right after another.

hi Support,

providing simple examples is OK but you must include more advanced examples that show other more advanced aspects. At least a disclaimers would be required so that users will not tempt to run this code in LIVE accounts.

Like I said before - the simple merge example as provided might result in a "naked" order with no SL. This is a very bad scenario for a trader to be in.

I think that if the API for merge method would do the following on the server side as a single atomic transaction:

1. cancel any order attached to the list of source positions
2. Set a new SL (given by client) for the merged order
3. Set a new TP (given by client) for the merged order

Our strategy implementation would have been much simpler and there was no distributed long running transaction involved in the merge process.

For now - I'm opting out of merge operations as it increases the complexity of the strategy by order of magnitude.

We already suggested how to deal with this.
The problem with adding such function is that before merge the user would need to figure out if the merged order will be long or short - otherwise it might be that the merged order gets closed by SL or TP right after its creation.
It is rather the objective not to miss any tick under any circumstances that sophisticates the strategy logic, not the provided API functionality. If you don't reject the application of IOrder.waitForUpdate, then it can be done within the same method. Within the method you can make multiple attempts of each order change if you receive *_REJECTED messages. And it does not take that long time - for instance for:
https://www.dukascopy.com/wiki/#Merge_Po ... _TP_update
TP, SL removals of three orders, merge and SL application takes less than 2 seconds.
https://www.dukascopy.com/wiki/#Merge_Po ... _TP_update