purepath timeout due to long running background thread
We have a situation where a background thread is created using the java Timer API that waits 30 minutes then wakes up and clears a cache.
Purepaths that trigger creation of that thread are timing out.
We're looking for a way to tell Dynatrace to ignore this particular background thread.
We have tried putting exclude & global exclude method sensors on the method that creates the timer but that doesn't fix the problem.
What is the appropriate way of deal with this situation?
I assume that you are interested in certain background threads but just not in those particulare ones - correct?
Right now you can only disable our Thread Tagging Sensor but that would mean that you do not get any threads tagged at all.
In your case I would rather suggest to not capture these PurePaths that start these backgroudn threads. If these threads are always triggered by specific web requests, e.g: "/someurl/urlthatstartsthread" - then you could modify your Servlet Sensor and exclude this URL from starting a PurePath.
In case your application is a non-web application you can exclude the "Entry Point" method of these PurePaths with a global exclude so that they dont start a PurePath anymore
Let me know if this works. otherwise - feel free to export some of these PurePAths and attach it to this post
We are working through this with support.
I will post the results when we (hopefully) find a resolution.
any update on this ?
I'm having this exact same case where a Timer.run() is invoked and the purepath times out on wait()...
Thanks
--
Laurent
could you show us a PurePath or give an exact example of the behavior you see, please?
in most cases this can be solved by an exclusion rule in the threading sensors.
best, Christian
Yes, I believe we got rid of this problem by excluding that method from the Threading sensor.
Lucky for us, we only had that one usage of Timer.run() so it didn't affect anything else.
Hi Christian,
you'll find attached a couple of pp exhibiting the aforementionned behaviour.
Thanks for your insight.
NB: we'll try to exclude, as proposed by Jason, the "Timer.$TimerImpl.run()" method, but this will reduce further our visibility on this code execution...
Regards
--
Laurent
hi Laurent,
right, you should do this exclusion of java.util.Timer$TimerImpl.run().
however, I'm wondering: I could not see this class in Sun/Oracle JVM 1.4-7 source code. and based on your session, you're working with IBM Java 6 VMs, right? so I guess this is something we should add to the default exclusions.
in the thread start tagging sensor you will see, that there is already a similar exclusion for java.util.Timer.run(). so this exclusion should basically be added here (you could just switch from "equals" to "starts").
please let me know if this worked for you, so we can discuss taking this into the product.
thx, Christian
EMEA Community Member of the Month - November 2018
Announcing Dynatrace's EMEA Community Member of the Month for November 2018, Mathieu C.! Click here to read more! LATAM Community Member of the Month - November 2018
Announcing Dynatrace's LATAM Community Member of the Month for November 2018, Rene S.! Click here to read more! 
