Gld Development: Difference between revisions
No edit summary |
|||
| Line 17: | Line 17: | ||
In order to develop a load content generator extension, appropriate for a specific use case, and with a specific set of concrete dependencies, the will only need to depend on gld-api. | In order to develop a load content generator extension, appropriate for a specific use case, and with a specific set of concrete dependencies, the will only need to depend on gld-api. | ||
</font> | </font> | ||
=Core Development= | |||
The core (including API and load-driver) is developed independently of extensions. Once a new core version has been released, the extensions that wish to use it should update the | |||
To get to the work area: | |||
<pre> | |||
cdgldc | |||
</pre> | |||
=Extension Development= | =Extension Development= | ||
Revision as of 15:09, 11 January 2017
Internal
GitHub
Overview
From a project perspective, gld consists of a core and extensions.
The core contains the load driver multi-threaded load engine, logic to coordinate multiple load driver instances and other logic required by the load driver. Al these are packaged as "gld-load-driver" The load driver runtime is not aware of any specific load content generator, it only interacts with a generic set of interfaces, packaged as "gld-api".
In order to develop a load content generator extension, appropriate for a specific use case, and with a specific set of concrete dependencies, the will only need to depend on gld-api.
Core Development
The core (including API and load-driver) is developed independently of extensions. Once a new core version has been released, the extensions that wish to use it should update the
To get to the work area:
cdgldc
Extension Development
Building
TODO
Release Procedure
gld Runtime Release Procedure
TODO
Extension Release Procedure
TODO
Creating a new Extension
TODO
TODO
- Tactical GLD.docx on Desktop. Start from there or transfer from there.
- 10/20/16 Attempt to use with JDG 7: API problems, JDG 6 does not work anymore - break out the JDG (Infinispan) piece as an external plug in and get rid of the dependency problem once for all.
- Outcome of JDG testing
- Make sure I can run two gld instances in parallel without interference. Currently there's just one log file ($(pwd)/gld.log) and this gets overwritten.
- Make sure the java memory can be configured individually per instance - on the command line. --memory 1024m that should override the value hardcoed in the wrapper.
- Possibility to configure gc logging from command line --gc-logging /a/b/c-gc.log.
- Memory leak analysis.