Gld Development: Difference between revisions
Jump to navigation
Jump to search
(→GitHub) |
No edit summary |
||
Line 20: | Line 20: | ||
<font color=red>TODO</font> | <font color=red>TODO</font> | ||
=Release Procedure= | |||
==gld Runtime Release Procedure== | |||
==Extension Release Procedure== | |||
==Creating a new Extension== | |||
=TODO= | =TODO= |
Revision as of 23:14, 14 December 2016
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.
Building
TODO
Release Procedure
gld Runtime Release Procedure
Extension Release Procedure
Creating a new Extension
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.