Can anyone have an Idea where to look for the reason that some purepaths are ended after calling to ThreadStart while there are different purepaths that continue to collect data after ThreadStart?
Where purepaths are ended after calling to ThreadStart those are complete PurePaths but where you are referring continue to collect data after ThreadStart (cont.jpg) PurePaths are corrupted.
Did you observer or I am just escalating the issue?
Thanks for your quick response yes we know its corrupted there is a long sleep there that cause it, but the issue is on the other purepath why its ends and not continue.
I think this is just the nature of your application. I am not sure what it is exactly doing - but - I assume it is an app that checks for certain async work items. In some of your PurePaths it doesnt have to wait for the next work item and therefore completes. In some cases it waits until a next workitem is ready.
I ran into a similar issue with a Spring Boot App recently where certain requests launch a background thread for working on backgroudn jobs. The problem is that these PurePaths for these requests will follow these threads and eventually time out. This is not a PurePath issue but it is the nature of the app
The timeout pp is understandable and we will deal with it
Our main question is about the pp which stops after calling ThreadStart , we are trying to understand way we can't see any more methods there.
It can just mean that there was simply nothing executed on that thread that dynatrace picked up. Dynatrace will capture Auto Sensor Data in case the Thread executes long enough for us to pick up auto sensors.But in your case these threads execute really fast.
If you would have custom sensors for methods that are executed on these threads they would show up. If you KNOW of certain methods that you expect you can create a custom sensor to proof that dynatrace picks up things on that thread.
Right now to me it just seems that these "short PurePaths" simply dont execute anything on these threads
From what the customer says and from the cpu sampling it's look like there are more methods down the line which some of them are instrumented but not showing up on the purepath.
Try to instrument that method and set it to "active and start PurePath". You should then definitely get a PurePath. If you get a separate PurePath it means that they are using a Thread Pool Implementation that we currently dont support out-of-the-box. That would then be something our support team can look into. The first thing though is trying to capture these PurePaths.
We have tried the instrumentation already before ....
I will update the ticket (SUPDT-30055) with your remark.
Thanks for your help