1) I've moved the core loop logic and behavior into two classes: the classic behavior is located in LegacyLoopTask.java while a new set of work is located in FlatLoopTask.java. Separating the logic helps clean up the LoopController a bit. The results of a task are now stored in a class called LoopResult.java
2) Instead of using Threads we're using an ExecutorService. This is a new construct from Java 5 and refined over the last several releases. It allows you to work with higher level constructs than the Thread model. This allows you to create a list of tasks and submit them to an executor which will pull tasks from the list as items complete. In looper, we were specifying a number of threads to use and a number of iterations to execute. Here, we create a fixed threadpol of the specified size, creating tasks to execute, and then submitting them to the thread pool. As work completes, tasks are pulled off the list and executed until all work is complete. It's then possible to retrieve the results of the execution and manipulate the results. We could extend this so that instead of a fixed thread pool size we could use a [variable sized executor](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/Executors.html#newCachedThreadPool()) or a [work stealing pool](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/Executors.html#newWorkStealingPool()) or a scheduled executor to periodically run tasks (one task ever 200ms or some such).
3) The amount of logging to system out is reduced. Only basic statistics about each run are printed as looper runs. However, at the end of the run looper displays how many tasks were successful, then displays the failure information about each of the failed tasks (the REST calls, the Exceptions, etc) and then some basic stats about the run including min/avg/max time for a task to execute.
4) There is a new, flat, looper. In the classic looper when you run loopctl.sh 10 15 you're saying "Looper, create 15 threads and each thread should iterate 15 times to create portfolios, buy stocks, sell stocks, then delete the portfolio". This, in essence, creates/updates/deletes 150 portfolios in the various backends. The new flat looper says "Let's create all 150 portfolios of these as individual tasks to be executed, then submit them to the thread pool, and when a thread pulls a task off the list it creates a single portfolio, updates it, then deletes it. " Tasks are not guaranteed to run in order. It could be a way to submit a bunch of work at once. You run this flat looper by running loopctl.sh 10 10 flatLoop The classic mechanism is called via the regular loopctl.sh 10 10
This PR gives a small revamp to looper.
1) I've moved the core loop logic and behavior into two classes: the classic behavior is located in LegacyLoopTask.java while a new set of work is located in FlatLoopTask.java. Separating the logic helps clean up the LoopController a bit. The results of a task are now stored in a class called LoopResult.java
2) Instead of using Threads we're using an ExecutorService. This is a new construct from Java 5 and refined over the last several releases. It allows you to work with higher level constructs than the
Threadmodel. This allows you to create a list of tasks and submit them to an executor which will pull tasks from the list as items complete. In looper, we were specifying a number of threads to use and a number of iterations to execute. Here, we create a fixed threadpol of the specified size, creating tasks to execute, and then submitting them to the thread pool. As work completes, tasks are pulled off the list and executed until all work is complete. It's then possible to retrieve the results of the execution and manipulate the results. We could extend this so that instead of a fixed thread pool size we could use a [variable sized executor](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/Executors.html#newCachedThreadPool()) or a [work stealing pool](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/Executors.html#newWorkStealingPool()) or a scheduled executor to periodically run tasks (one task ever 200ms or some such).3) The amount of logging to system out is reduced. Only basic statistics about each run are printed as looper runs. However, at the end of the run looper displays how many tasks were successful, then displays the failure information about each of the failed tasks (the REST calls, the Exceptions, etc) and then some basic stats about the run including min/avg/max time for a task to execute.
4) There is a new, flat, looper. In the classic looper when you run
loopctl.sh 10 15you're saying "Looper, create 15 threads and each thread should iterate 15 times to create portfolios, buy stocks, sell stocks, then delete the portfolio". This, in essence, creates/updates/deletes 150 portfolios in the various backends. The new flat looper says "Let's create all 150 portfolios of these as individual tasks to be executed, then submit them to the thread pool, and when a thread pulls a task off the list it creates a single portfolio, updates it, then deletes it. " Tasks are not guaranteed to run in order. It could be a way to submit a bunch of work at once. You run this flat looper by runningloopctl.sh 10 10 flatLoopThe classic mechanism is called via the regularloopctl.sh 10 10