Dear Support Desk,

I've recently encountered problems in setting the historical testing mechanism (ITesterClient) of the standalone API. After making dozens of attempts with different method signatures and different set of parameters, I've found the following method signatures partly or fully inoperable.

1. setInitialDeposit: neither the recommended nor the obsolete signature works. Not even when the default deposit parameters are passed (JFCurrency.getInstance("USD"), 50_000d)
2. setDataInterval(Period,OfferSide,InterpolationMethod,long,long): it works only with Period.TICKS
3. setDataInterval(DataLoadingMethod,long,long): it works only with DataLoadingMethod.ALL_TICKS

setInitialDeposit simply throws a NullPointerException with no message.
As far as setDataInterval is concerned, after applying one of the mentioned problematic settings and invoking startStrategy, the test formally starts but tons of exceptions block the operation. A tipical log trace of such an exception begins as follows:

2014-11-04 10:46:59,313 ERROR AbstractHTFlowDataCreator - to(2013-01-18 23:59:59:999) > last tick time (-9223372036854775808)
java.lang.IllegalArgumentException: to(2013-01-18 23:59:59:999) > last tick time (-9223372036854775808)
at com.dukascopy.charts.data.datacache.customticks.AbstractLoadCustomTicksFromTicksAction.validateFromTo(AbstractLoadCustomTicksFromTicksAction.java:53)
at com.dukascopy.charts.data.datacache.customticks.AbstractLoadCustomTicksFromTicksAction.<init>(AbstractLoadCustomTicksFromTicksAction.java:47)

The indicated signatures used to work some weeks ago. I also checked setCacheDirectory and getInitialDeposit now. They work (the latter one returns the default deposit). I didn't check the remaining setter methods of ITesterClient.

Could you please check those settings.
Thanks, regards,
Argiris

PS:
I use Windows 7 64-bit machine with the latest JDK 8 (1.8.0_25) 64-bit, the latest Dukascopy API (DDS2-jClient-JForex-2.39, JForex-API-2.10.1) and NetBeans 8.0.1 with Maven. I used EUR/USD as traded pair and test interval of 2013-01-01 - 2013-03-01 (yyyy-MM-dd 00:00 CET). History.getTicks and getBars did work within that interval. I am ready to share more details with you should you need it.

We will investigate this.

It would be really helpful if you could provide application + strategy pair that reproduces the issues.

I used EUR/USD and test interval from 2013-01-01 to 2013-03-01 (yyyy-MM-dd 00:00 CET). Should you have difficulties in reproducing the bugs, I am ready to put together a short application that can make them visible. (However, this could take some time for me as I use a larger customised GUI based system with many classes.)
Thanks for your efforts in advance.

Guys,

I've put together a strategy class and two runners. One of the runners is a historical tester, the other one is a realtime runner - only the former one is relevant for the bug report. You can find attached 5 files - don't be afraid, the code is quite straightforward to follow.

By the help of the files, you can reproduce the bugs listed in the original post. Before using them, overwrite the lines containing comments "//SET..." at your will (traded instrument, period, test interval, etc.). You can find 1 such line in Account and 8 lines in Strategy. In HistoricalTester class, scroll down to setupClient() method and make attempts with the two signatures of ITesterClient.setDataInterval() and pass different parameters.

I've just discovered that, if you change the order of setupClient(); and login(); within HistoricalTester.run() method, the first bug doesn't come up. In other words, ITesterClient.setInitialDeposit() should be invoked after login, otherwise it throws a NullPointerException. (This was not the case some week ago, in the last API version, I believe.)

Regards,
Argiris

1. The reason you get NullPointerException is because you are trying to set up the deposit before you have been authorized. You need to connect first and set up the deposit only after that. We will add this to documentation to make it clear.
2. and 3. It's a bug we are going to fix.

Looks like we managed to fix all three problems (including setInitialDeposit before authorized). The fix will be available in next API release. The release is scheduled next week.