davidfrigola / poc-java-dump-analysis Goto Github PK

Both doStore and doThread should be extended to

• doStore - parameter for number of items of the map to store
• doThread - parameters for number of threads to generate and sleep time

Complete README with some samples and HOWTOs
Probably worth a wiki page with heap and thread dump explanations

Remove sleep, make and ls from ci build and use a proper cucumber test approach.

• Use wait-for-it instead of sleep
• Define steps to execute make commands
• Define expectations instead of ls (can actually use the same implementation or implement a file_exists function)

🥇 Extra - step to check valid dump file? Needs investigation

https://blog.takipi.com/jvm-architecture-101-get-to-know-your-virtual-machine/

Add CI to:

• build app
• start it (probably within a container)
• generate heap dump
• generate thread dump

Blog entry/wiki with explanation and enough detail

Check it https://github.com/patric-r/jvmtop

Provide a mix of thread + heap analysis

New endpoint that

• Generates N threads
• Each thread is calculating and storing a big amount of data, stored locally in the controller

Refactor current code so can reuse the big thing calculation.

Add some noise to app execution so dumps are more realistic

New endpoints that

• Temporarily store some medium-size amount of heap
• Generare some random/parametrised number of threads
• Do both things at the same time

(ATs improvement issue #18 should be in sync with this task, so the endpoints and dump generation are tested)

Provide explained analysis

Up ver

Include javamelody agent
Docs : Show how heap/theads look like

Add travis-ci badge in the README file