Support for bulk add/update/cancel orders

Hi folks,

i would like to create a PR and introduce additional methods in the interface org.knowm.xchange.service.trade.TradeService to support bulk operations for order management. The new methods could look like this:

  default List<Try<Boolean>> bulkCancelOrders(List<CancelOrderParams> orderParams) throws IOException {
    throw new NotYetImplementedForExchangeException();
  }
  default List<Try<String>> bulkPlaceLimitOrders(List<LimitOrder> limitOrder) throws IOException {
    throw new NotYetImplementedForExchangeException();
  }
  default List<Try<String>> bulkUpdateLimitOrders(List<LimitOrder> limitOrder) throws IOException {
    throw new NotYetImplementedForExchangeException();
  }

there are multiple exchanges, which do support bulk operations, like bitmex and finex. in my proposal i used the Try pattern, the Try interface can have two concrete classes: Failure and Success. The pattern is well implemented in the vavr library http://www.vavr.io/

@timmolter what do you think? i would add the additional dependency for vavr and implement the methods for BitMEX and Finex. One need to check than, which other platforms do support the bulk operations.

There are good reasons to use the bulk operations. First thing: you can submit your orders much faster, the second one: youo will not get issues with too frequent requests, which is unfortunatelly very often the case. Here for example one passage from the BitMEX doc:

Due to how BitMEX does real-time auditing, risk checks, and margining, orders submitted, amended, and canceled in bulk are faster to execute. For this reason, bulk actions are ratelimited at 1/10 the normal rate! Bulk cancels, regardless of count, always only count as one request.

cheers andre

[walec51]

all the same, generic interfaces are for generic features if only few exchanges implement a feature then it is not generic and if you cannot even simulate it by using existing generic features then it should not go to generic interfaces

[cymp]

What about declaring the methods common to several exchanges but not all (@andre77 case) in the interface with something like “throws NotSupportedByExchange” instead of a default implementation throwing a NotYetImplementedForExchangeException? This way the development is protected at compilation time as we would have to take care of a possible unsupported feature, a bit better than having NotYetImplementedForExchangeException thrown at runtime.