Correlating threads
Hi everyone from Spain.
Could Someone tell me how follow one request through several threads? I mean, we've got an kind of web request that start a secondary thread.
Exists any way to view both threads into the same purepath? Or any other way to correlate these threads?
Regards
Hi everyone from Spain.
Could Someone tell me how follow one request through several threads? I mean, we've got an kind of web request that start a secondary thread.
Exists any way to view both threads into the same purepath? Or any other way to correlate these threads?
Regards
Hi
We're absolutely sure we're making to place Executor Tagging and Thread Start Tagging.
Instrumented code exists into secondary thread. We're starting purepaths from one method of this code. (That's our workaround).
The application is deployed in Websphere Applications Server 6.1. We think the ThreadPool Implementation used is "com.ibm.ws.util.ThreadPool"
Juan
(Excuse my poor english)
I see "com.ibm.ws.util.ThreadPool" defined into "Executor Tagging" but only with the "execute" method included.
My decompiled code show:
class ThreadSecundario extends Thread{
[ ...]
public void run() {
Maybe is needed instrumenting run() method? How could I do it?
thanks for the information. The execute method is fine as this is used by the "Exectuor Tagging" Sensor Pack which is responsible that we can tag a PurePath into a Thread that is taken out from the com.ibm.ws.util.ThreadPool.
The Sensor Pack "Thread Start Tagging" has a rule for the "run" method on every class that implements java.lang.Runnable
Based on what you tell me we should be able to track calls across your Thread Boundaries.
Lets do one more check.
a) Open your Agents Overview Dashlet
b) Click on your Agent and then switch to the Deployed Sensors Tab in the Pane on the bottom of the dashlet
c) Check if you can find the run method of your ThreadSecundario class as well as the execute method of your com.ibm.ws.util.ThreadPool
Andi
Thanks Andi.
The check results:
the execute method of your com.ibm.ws.util.ThreadPool appears deployed
the run method from atae.apli.gestordocumental.base.AtaeSvGestorDocumental$ThreadSecundario doesn't appear deployed, but from this method are starting purepaths.
Can you remove your custom sensor for run? It shouldnt be necessary as our Thread Tagging Sensor shoudl automatically pick it up and should show you the execution of this thread as part of your "initial" PurePath.
Sorry Andreas. I was wrong, both methods appear deployed (run and execute). I was looking in a wrong agent.
However, in order to remove our custom sensor, this sensor is new. I configured the sensor this morning, before that, any secondary thread wasn't showed. It's just a workaround.
Okay - thanks for the clarification.
It is good that you have a workaround but I also suggest to open a support ticket so that our engineering team can investigate further why our out-of-the-box support doesnt trace the PurePaths across the tiers.
When you open a ticket please also paste a link to this forum post.
Andi
Hi,
I encounter the exact same issue. I use 4.1 with february patch.
This happens because the application does not start threads but reuses already started threads.
Thus it's not entering "start method"...
I created the issue : https://support.dynatrace.com/supportportal/browse/SUP-8203
Plus, the application is using EDU.oswego package : http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/PooledExecutor.html
Hi Juan
Thread Tagging
dynaTrace supports Thread Tagging for both Java and .NET. That means that you will get one PurePath that starts in your "main" thread and will also see those methods invoked on separate threads
How to enable
In order for this to work you have to make sure to place the following Sensor Packs for Java: Executor Tagging and Thread Start Tagging
For .NET it would be the Sensor Pack: .NET Thread Tagging
How to troubleshoot
If these Sensor Packs are placed but you still dont see methods invoked on your other threads you either
a) do not have code instrumented on these threads -> make sure you actually have Sensors placed for methods that get executed. In case your threads execute rather fast Auto-Sensors wouldnt pick up any execution.
b) We may not support your ThreadPool -> do you know which ThreadPool Implementation your application uses?
Andi
