cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

dynaTrace 6.x thread dump no Owned by

paul_sterl
Contributor

Hello Guys,

any idea why the owned by might be missing if I create a thread dump? Problem is that we created this as we had an issue, bounced the server and issue is gone. We know that something was blocked but now we cannot find what, or better to say by what.

I read this article: http://apmblog.dynatrace.com/2012/10/25/3-steps-to-diagnose-stuck-transactions-in-minutes/

Thanks in advance,

Paul

 

7 REPLIES 7

andreas_grabner
Dynatrace Guru
Dynatrace Guru

Hi Paul

Any chance you can export such as Thread Dump?

paul_sterl
Contributor

Done, here is the dump:

<-- deleted was wrong -->

Is where a way to convert it to a normal java thread dump?

paul_sterl
Contributor

Sorry attached the wrong dump (sad)

Here the correct one: Blocked iSoft Jan 26, 2015.dts

 

andreas_grabner
Dynatrace Guru
Dynatrace Guru

Thanks. Well - I dont see a whole lot unusual here. It just means that none of these threads in waiting state are actually waiting on one of these monitors.

You can click on each thread and look at the stack trace to see where these threads are waiting. It just seems they are not waiting on one of these monitors owned by other threads

paul_sterl
Contributor

I am confused as they are in the state "blocked" and ~1000 of them, which is very unusual as usually every 5 mins we have just 4 of them running for around 200ms. The status blocked somehow indicates to me that they are waiting for something, not sure what they are waiting for ...

Does this make sense to you?

andreas_grabner
Dynatrace Guru
Dynatrace Guru

Well - it seems that most of your blocked threads are stuck in this call stack:

# Class Method Line Source File
0 java.util.Arrays copyOf(char[], int) 2367 Arrays.java
1 java.lang.AbstractStringBuilder expandCapacity(int) 130 AbstractStringBuilder.java
2 java.lang.AbstractStringBuilder ensureCapacityInternal(int) 114 AbstractStringBuilder.java
3 java.lang.AbstractStringBuilder append(java.lang.String) 415 AbstractStringBuilder.java
4 java.lang.StringBuilder append(java.lang.String) 132 StringBuilder.java
5 java.lang.StringBuilder append(java.lang.Object) 128 StringBuilder.java
6 javax.management.ObjectInstance toString() 152 ObjectInstance.java
7 ORG.oclc.infra.util.SortedVector compareTo(java.lang.Object, java.lang.Object) 148 SortedVector.java
8 ORG.oclc.infra.util.SortedVector sort() 136 SortedVector.java
9 ORG.oclc.infra.util.SortedVector sortVector(java.lang.Object[]) 83 SortedVector.java
10 ORG.oclc.infra.util.SortedVector <init>(java.lang.Object[]) 69 SortedVector.java
11 ORG.oclc.infra.ops.api.OpsMBeanClient getAllObjectInstances(java.lang.String) 1189 OpsMBeanClient.java

These are all threads that handle MBean Requests. I dont see these threads waiting on monitors though 

 

paul_sterl
Contributor

Same here. I build an unit test for this code (some old stuff where I don't even know then it was written nor by whom to ask).

In the end it sorts, thats it and calls compare, also not that hard. In the unit test it is fine for more then 200 elements and 50 threads. No block. But in the environment for some reason the code code stuck and I have no clue why.

I wonder if the thread dump could be converted to a normal one, maybe here we could see more. As more then 1000 of these threads is quite un-usual. Sorting Strings / well here javax.management.ObjectInstance.ObjectInstance(String, String) should not be an issue. Even if the code is old.