The tooltips look good on Firefox, but they are aligned wrong on Safari and Chrome.

Possible solutions:

• fix CSS,
• create some JS-only tooltips,
• use some external library (tooltips from Atlaskit didn't work properly).

Some options:

• parse real files and treat the parser as a black-box
• refactor some code and test particular methods

Support zips now contain an output from JFR but currently Watson has only a very limited support for it, i.e. one additional version of CPU consumers page that offers a subset of features of the old view.

Since JFR data contains some cpu utilisation stuff the support can be much better

https://ecosystem.atlassian.net/jira/software/projects/WATSON/boards/501?selectedIssue=WATSON-73

Instead of this:

Make it look like this:

(just the first stack, I was too lazy to do it for the following ones)

Add a flame graph page, filterable (e.g. by thread name, contains in stack + "Show only starting from...")

https://ecosystem.atlassian.net/jira/software/projects/WATSON/boards/501?selectedIssue=WATSON-81

Add some analysis of the problems we often see, e.g. many threads stuck waiting for the DB, full code cache, crashed reindex thread, ...

Currently, Watson recognizes either uploading a single file with multiple thread dumps inside, or uploading multiple files with a single thread dump.

When a user tries to upload a set of files with multiple thread dumps in each, the app doesn't do anything.

It's unnecessarily long, I was too excited with screenshots from visual regression tests that I added too many. :)

One screenshot is enough for most pages, there should be at most two per page.

The navbar should always float on top of the page, to make it easy to switch tabs after scrolling down

Nice to have: shorten titles of pages, add an icon to the "load another", replace "Issue tracker" and "Source code" with a single link to GitHub

On pages that have some settings as labels, de-selecting and then re-selecting an option breaks the page:

• a different set of data is showed (most notably - new columns are added on the threads overview page)
• some functionality gets broken, e.g. opening thread details in a new window

Opening the page again fixes the issue. The problem reproduces 100% of the time

I've identified issues in watson's memory usage chart regarding the handling of memory data in different formats:

1. Handling MiB unit: The chart inaccurately represents MiB data from top. The top tool in Linux systems uses MiB or KiB based on the version and configuration. Older versions typically use KiB, while newer ones may use MiB. Users can also toggle between MiB and KiB in top settings. This variation affects the chart's accuracy. Sample MiB data for reproduction:
   MiB Mem : 386945.3 total, 254444.5 free, 92777.0 used, 39723.8 buff/cache

2. Data with '+' sign: The + sign in used memory data leads to inaccurate chart representation. The chart shows that all memory is used. Used memory is not rendered.
   KiB Mem : 65171004 total, 3210764 free, 21277416+used, 40682824 buff/cache

3. Inaccurate KiB memory conversion: The current method simplifies conversion, assuming 1 GB equals 1 000 000 KiB and 1 MB equals 1000 KiB, which is inaccurate. The correct conversion should be 1 GB equals 1024 * 1024 KiB, and 1 MB equals 1024 KiB.

This will require adjusting the parser, and maybe some components. Thankfully all required changes should result in typescript compile-time errors

When hovering over a point on the “Running processes” chart, Watson should display a list of those processes

The rule was disabled in #50, to quickly bump eslint

It should be re-enabled, and resulting errors should be fixed

Currently, Watson supports a few predefined filters.
It would be nice if users could create their own and modify existing ones.

JS applies local timezone when formatting strings, which effectively means Watson displays wrong hours

https://ecosystem.atlassian.net/jira/software/projects/WATSON/boards/501?selectedIssue=WATSON-82

Potential solution:

• hide threads not maching the regexp
• slightly change the background color (or add a border?) of a thread matching the regexp

https://ecosystem.atlassian.net/jira/software/projects/WATSON/boards/501?selectedIssue=WATSON-77

It should save a lot of time, especially if it can be made to run on different browsers

It will probably require anonymizing and uploading some thread dumps

Possibly https://storybook.js.org/docs/react/get-started/install

Use the same mechanism from thread details to render stack traces on other pages, e.g. similar stacks.

Add an option to filter threads based on CPU usage from the TOP output.

This will help to focus only on hot/CPU active threads and remove the noise.

https://ecosystem.atlassian.net/jira/software/projects/WATSON/boards/501?selectedIssue=WATSON-67

If there are top outputs loaded without a corresponding thread dumps, some pages are cluttered with useless columns.

To be precise:

• the threads overview page shows empty columns,
• stuck threads page incorrectly sets the default value for "Minimal similar stacks to consider a thread stuck" (it's bigger than the number of thread dumps loaded, so it will always be false),
• CPU consumers page shows columns filled only with "--".

The summary page shows some "unknown time" entries on the X-axis which could be improved too.

Similar threads page works without any issues.

Discovered when fixing #10

Achieve something similar to the regexp below:

grep -E -h '^"http.*-exec-[0-9]+' jira_threads.* | sed 's/"//g' | sort -k1,1 -s | grep -E " runnable | Object.wait\(\) | monitor " | awk '{print $1, $2, $3}' | uniq -c | awk '($1 >= 2) {print}' | sort -nr

Basically, only display threads that are running for 2+ consecutive windows. The filter can be useful especially for thread dumps with hundreds+ of threads or a huge number of dumps where it's not easy to visually scan everything.

It's the pop-up that opens when you e.g. click on a CPU usage or the line from the stack in Threads Overview. It's just ugly at the moment.

I don't have any vision about how it should look.

It would be helpful if we were able to navigate the same thread between different thread dumps - for example, if you open a thread on the thread monitor, you can use the arrow keys to move between the same thread on the other thread dumps that were loaded.

https://ecosystem.atlassian.net/jira/software/projects/WATSON/boards/501?selectedIssue=WATSON-79

Collapsable branches
Ability to filter threads/select a subset

As an example, have separate colors for JDBC, ActiveObjects/OfBiz/QueryDSL, Spring, Jira, Servlet lines.

See an example for logback: https://dzone.com/articles/filtering-stack-trace-hell

With #53 done we can get rid of the manual deployments and just trigger them when all builds pass on main