Hi, the new tester API is great to have, however there are a few issues I would like to raise:

- ITesterClient,startStragey() takes a loadingProgressListener as parameter which has a stopJob() method to allow stopping the strategy. So this method is called repeatedly (polled). This is a waste of resources... (as polling always is)

- ITesterClient.startStartStrategy() runs asynchronously, so it would be much more useful to return a Future (like downloadData() does ). This would allow control (stop/cancel) of the task, and without waste of resources.

- ITesterClient requires to be connected to dukascopy server for a run... this is entirely unnecessary and a waste of resources again. If the client is not connected, and the data is already in cache, the tester should be able to run. If the tester is not connected and the data is not all in cache, the tester should raise an exception.

Consider the case were one wants to optimize parameters of a strategy. This might require many thousands of runs of the tester. Allowing true connectionless tester runs will save dukascopy thousands of connection attempts, clearly an unnecessary drain on dukascopy servers and bandwidth (as well as the client's bandwidth).
It will also improve multiple tester runs speed and reliability as the time wasted attempting connections will be saved. A lack of connection on the client or server side, will also not influence the tester runs.

Please kindly consider the above as potentially very important improvements to JForex, Thank you.

I have a workaround for the necessity to re-run your strategy over and over. The StrategyRunner thread calls System.exit() when everything is finished. If you intercept it (see https://www.securecoding.cert.org/confluence/display/java/EXC09-J.+Prevent+inadvertent+calls+to+System.exit%28%29+or+forced+shutdown), you can run multiple strategies from the same process. You can only run them in series, not in parallel, but that's better than having the delay connecting to the servers, etc.

-Brian

that is really good to know. nonetheless, I think JForex has a huge limitation by enforcing connection to the server even when the data is already cached. That issue you found that ITesterClient is a singleton is another massive bug (or design error)

I certainly hope The dukascopy dev team is working to remove this silly limitation, it will save tons of bandwidth too.

I believe their original intent was to allow you to register multiple strategies with a single ITesterClient instance and it'd run them all in parallel, then call System.exit() when the number of running strategies hit zero. I believe the ITesterClient or TestClientFactory (or whatever) javadocs said something about "when the number of running strategies goes to zero, it exits", and that's where I got this idea.

As far as needing to connect to the servers, it's an annoyance but I have a suspicion it'll be nothing more than that. My group is ramping up to starting a few hundred instances (on EC2) of a strategy tester I wrote, and this is a concern for us. If they don't let you login with multiple accounts simultaneously, my bet is that'll just mean each instance will need to connect, verify its cache is in-tact, then some time thereafter my connection will timeout while the strategy is running.

So I might have a 2-5 minute delay between each instance starting, but once they're all started I can just keep them all running, and start new tests as is necessary. I haven't tested that yet, still putting the finishing touches on other things.

-Brian

actually it is stated on dukascopy website (somewhere... I read it) that the client can be started multiple times for a given account. So I don't think it is any problem to create multiple tester processes running on the same account.

I suspect you are working on strategy parameter optimization... I am working on that too, using genetic algorithms and a concurrent client/server architecture to speed things up. Maybe we can share some ideas ? Message me if you think so.

I don't see a feature in this system for sending private messages. You can reach me at the following: phantall~gmail.com; replace ~ with @.

-Brian

ITesterClient.startStartStrategy() runs asynchronously, so it would be much more useful to return a Future (like downloadData() does ). This would allow control (stop/cancel) of the task, and without waste of resources.

It returns a process id. Listener is used to control the testing process.

ITesterClient requires to be connected to dukascopy server for a run... this is entirely unnecessary and a waste of resources again. If the client is not connected, and the data is already in cache, the tester should be able to run. If the tester is not connected and the data is not all in cache, the tester should raise an exception.

Current cache implementation denies it. For example, 10min candles are saved in month folders, if we run tester on period that includes current month, then we save those data in intraperiod folder which is flushed on every JForex start.

Consider the case were one wants to optimize parameters of a strategy. This might require many thousands of runs of the tester. Allowing true connectionless tester runs will save dukascopy thousands of connection attempts, clearly an unnecessary drain on dukascopy servers and bandwidth (as well as the client's bandwidth).
>It will also improve multiple tester runs speed and reliability as the time wasted attempting connections will be saved. A lack of connection on the client or server side, will also not influence the tester runs.

In a next next version, the tester will be able to run multiple strategies with one ITesterClient instance. You can run in parallel one after another, etc.

NICE! Thank you!

Will each parallel instance have its own bankroll? That is, will they be independent?

-Brian

Yes

great, can't wait to have that documented, as it is currently possible in an undocumented way, obviously.

In the JForex client, I can open multiple testers from Tools->Historical tester, and run them in parallel with various strategies. So, clearly, the API is already there...

Also, each having it's own bankroll is one thing, it will also be very useful to be able to setup different start and stop dates for each test run and strategy.

yes, we get a process ID, but there is nothing tying the process ID to the actual thread or strategy when it is started. We don't know the process ID initially. A future would still be much much better, to return values, cancel etc. the task.

My workaround for that was populate a public, non-static variable in my strategy with the current thread ID, then use that from 'main'. Hackish, but functional.

-Brian