If you have designed a multiple concurrent order management system within a Strategy module, please help !!

My system will have a number of Queued order operations to perform, but there is a minimum delay time between operations.

I'm not going to use waitForUpdate and hold up the event handlers, so I'll Queue up operations and execute them using the Call task interface when they are eligible to be executed, taking into consideration required time delays. I am a threads expert, so it's no problem to management synchronization, if only I know the rules we have to respect.

Looking through Wiki and the forum, I was unable to get any clarity on just exactly how fast is too fast?

In designing my system I'd like to know the Rules for Order Operation required delays.

Is it any order operation which must be at least 1 second later than a prior operation?
If I pick from a Queue of Pending Operations, then must I wait 1.5 seconds in every case between Operations?

Is it Global (any order operation)? Or is it "per Order" that the minimum delay restrictions apply?

When does the Required Delay clock start? On acknowledgement of the operation?

So, let's say I have 2 orders Live. I want to add Take Profit to both of them. How much time must I wait before I can do this?

Must I Submit Order 1 --> Delay 1 sec --> Submit Order 2 --> Delay 1 sec --> Add TP to Order 1 --> Delay 1 sec --> Add TP to Order 2

If I try an order operation and it's been 0.9 seconds (not long enough), and so I get a minimum delay violation, do I have to wait >1 second before trying again? After all, I was only 0.1 seconds too fast...

Please clarify what the rules are, and how "Order Operation Delays" should be reliably managed for multiple order operations?

Since I don't want to block IStrategy event callback threads, since that will block incoming market data events, etc., how about using a separate thread to determine whether an order is available for the next operation?

In thinking about this, is it possible to use IOrder.waitForUpdate(...) to determine whether a given order is ready for another operation, but to do it in another separate order-specific thread? Let's say iorderInstance.waitForUpdate(2000) but if that does not time out (e.g. returns in maybe 300 msecs), then it means the iorderInstance is "ready for another order operation" ?

It would be nice to have a boolean IOrder.readyForUpdate() call which would guarantee the order was ready.

But if there is a Global Throttle on the rate of order operations per second, regardless of which order, then this approach would probably not work.

Order execution time is not deterministic.
You don't need here any delays, waiting for update is necessary only if you need to use the modified TP price (i.e. call IOrder.getTakeProfitPrice) right away after setting it.
The minimum delay only applies to setting TP/SL to the same order. Such limit is designed not to flood the server with order change requests.
Read:
https://www.dukascopy.com/wiki/#Manage_Order_State
https://www.dukascopy.com/client/javadoc/com/dukascopy/api/IOrder.html#waitForUpdate(long)
https://www.dukascopy.com/wiki/#Threading/Scheduled_asynchronous_execution

Thanks so much.

So, my understanding is that the required delays are on a "per order" basis. For a given order, I would not want to send order change requests faster than a couple of seconds, to respect the minimum delays and avoid "flooding".

Just to confirm whether I understand this correctly, let's say that I have submitted and opened 10 orders which do not have Take Profit.

(10 seconds goes by...)

Then I want to add a Take Profit to each of these 10 orders.

Let's say I loop quickly (no pause) through the 10 orders, and set a take profit price for each one. I don't pause in the loop.

Will this cause a problem? They are 10 individual orders.

It should not, and it is easy to test that.

So I'm going to implement an Order Actions queue design, and make sure that for each getOrderId() key, that there is a minimum delay of at least 1 second between order operations ENFORCED automatically. Let's say 1.5 seconds just to be safe.

This assumes that the minimum delay time is on a PER ORDER basis. So a timestamp of the LAST OPERATION will be maintained for each active Order, which is used to ensure the Order Actions queue, for each individual order, cannot request another Order operation too quickly, and will also do a limited retry on failure.

I am hoping these pacing restrictions are REALLY on a per-order basis, using the primary getOrderId() as the identifier.

Is this a valid DESIGN assumption? Anyone's experience welcome.
Thanks!

I was surprised to find that there is no "getOrderModifiedTime" method in the IOrder interface. This would be ideal to avoid infringing the order modification constraint. Is there any reason it cannot be added?