Fwd: Structured Concurrency - Stacktrace in tree hierarchical structure

[Volkan Yazıcı]

Hey Abdul,

*[Disclaimer: I am just a Loom user like you.]*

I don't know if the JSON-formatted output is intended to be human-readable.
Yet it certainly should be easy to decode by a machine, and the current
flat structure fits the bill perfectly well, IMHO.

As a matter of fact, several frameworks, *cough* Log4j *cough*, initially
implemented JSON layouts where the stack trace is dumped in a nested
fashion. This was mostly due to the irresistible convenience of
`objectMapper.convertToString(exception)` offered by Jackson and similar
POJO-to-JSON encoders. Later on it was figured that such a nested
representation introduces other challenges to persist and query; either
programmatically, using an RDBMS, or a document store (e.g.,
Elasticsearch). Today many major players I know of (JSON Template Layout of
Log4j
<https://logging.apache.org/log4j/2.x/manual/json-template-layout.html>,
`/threaddump`
endpoint of Spring Boot Actuator
<https://docs.spring.io/spring-boot/api/rest/actuator/threaddump.html>)
switched to a flat stack trace representation.

I get the sense that the serviceability improvements for Loom are still
underway, and eventually, users will be equipped with better tools,
eliminating the need to manually interpret JSON.

Cheers!

On Thu, Nov 28, 2024 at 12:49 PM Abdul Muneer K <abdul.kolarkunnu at gmail.com>
wrote:

> I attached the test program and corresponding thread dump.
> In this json tree structure, if tids 29 and 30 come under its owner tid 20
> in a tree structure, we can understand thread hierarchy easily from the
> thread dump json file.
> Similarly 31 and 32 under 29, 33 and 34 under 32, 26 and 28 under 23
> respectively.
> Now all pairs of threads are coming under a single node
> "threadContainers", it's not easy to understand the tree hierarchy from
> that. It's possible to track the hierarchy based on the owner/parent
> fields, but it's hard to follow if the hierarchy is long.
>
> Also another comment, now all the virtual thread's name is coming as an
> empty string in the thread dump. If the fork API can accept a name also as
> an argument and pass that name as the thread name interanlly, we can track
> the threads or tasks based on its name in the thread dump.
>
> Thanks and Regards,
> Muneer
>
> On Thu, Nov 28, 2024 at 12:17 AM Alan Bateman <alan.bateman at oracle.com>
> wrote:
>
>>
>>
>> On 27/11/2024 18:14, Abdul Muneer K wrote:
>>
>> Hi,
>> I prepared a StructuredTaskScope in a tree hierarchical structure as
>> below:
>>                         TaskA
>>                            __|__
>>                  TaskB             Tasks
>>                ___|__.               __|___
>>            TaskD.  TaskE.   TaskF .     TaskG
>>
>> [Not sure it will show as a tree while sending email because of
>> formatting, basically it's a three level full tree.]
>>
>> I captured the stack trace using the below command while running this
>> sample code with some delays on each task, so that I can capture thread
>> dumps with all of these tasks in the running state.
>> I ran below command to get thread dumps in json format:
>> jcmd <pid> Thread.dump_to_file -format=json <file>
>>
>> I got the thread dump, my expectation was, threads will follow the same
>> tree structure in thread dump also. We can track it based on the fields
>> "owner" and "parent". But, it will be difficult to follow based on these
>> fields if we have too many threads.
>> Is it designed like that because of any limitations? Or am I missing an
>>
>> I don't think I understand your question. Are you asking about the
>> traversal order used when streaming it to a file or are you asking if the
>> owner and parent keys are the right way to reconstitute the tree?
>>
>> -Alan
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20241128/5a627509/attachment.htm>