Article - CS247546
How to handle thread safety issues in Windchill
Modified: 09-May-2023
Applies To
- Windchill PDMLink 6.2 to 12.1
Description
- What are Thread Safety issues (also known as concurrency issues or race conditions )
- High and constant CPU usage is observed on a Windchill system
- One or more threads are observed using endlessly 100% CPU while accessing an object that is not thread safe (eg. HashMap,
- Looking at a a thread dump captured from Windchill, the hung threads can be spotted with below rules
- Stack trace shows the code is currently accessing a non thread safe object (eg. HashMap, HashSet, ArrayList)
- CPU user time is increasing by the amount of time spent since last state (ie. 100% of 1 CPU or less if this amount of CPU resource is not available)
- Byte allocation value is not evolving over time
- The operation never completes
- Below is an exemple showing the evolution for one typical occurrence of the issue as visible through the capture of 2 subsequent thread dumps
- Extract of first thread dump showing problematic thread in HashMap.getEntry:
"ajp-bio-8011-exec-6" Id=129 daemon prio=5 RUNNABLE
Blocked (cnt): 35714; Waited (cnt): 32780
CPU nanos: 256245725053586; User nanos: 254639820000000; Bytes allocated: 558960941120
Servlet request: 10gd6vh;ihca5tzc;16546;ov2qsw;3024310; Method context: 10gd6vh;ihca5tzc;16546;ov2qsw;3024313
at java.util.HashMap.getEntry(HashMap.java:469)
at java.util.HashMap.containsKey(HashMap.java:453)
at com.ptc.wvs.server.loader.PartGenericStructure.getNextSiblingNumber(PartGenericStructure.java:2138)
Blocked (cnt): 35714; Waited (cnt): 32780
CPU nanos: 256245725053586; User nanos: 254639820000000; Bytes allocated: 558960941120
Servlet request: 10gd6vh;ihca5tzc;16546;ov2qsw;3024310; Method context: 10gd6vh;ihca5tzc;16546;ov2qsw;3024313
at java.util.HashMap.getEntry(HashMap.java:469)
at java.util.HashMap.containsKey(HashMap.java:453)
at com.ptc.wvs.server.loader.PartGenericStructure.getNextSiblingNumber(PartGenericStructure.java:2138)
- Extract of 2nd thread dump showing the problematic thread still in the call to HashMap.getEntry. Observe only the CPU nanos / User nanos is increasing. no change in Byte allocated. As it is using 100% CPU, the time will typically increase by the amount of time elapsed between the 2 thread dumps.
"ajp-bio-8011-exec-6" Id=129 daemon prio=5 RUNNABLE
Blocked (cnt): 35714; Waited (cnt): 32780
CPU nanos: 256257725053586; User nanos: 254651820000000; Bytes allocated: 558960941120
Servlet request: 10gd6vh;ihca5tzc;16546;ov2qsw;3024310; Method context: 10gd6vh;ihca5tzc;16546;ov2qsw;3024313
at java.util.HashMap.getEntry(HashMap.java:469)
at java.util.HashMap.containsKey(HashMap.java:453)
at com.ptc.wvs.server.loader.PartGenericStructure.getNextSiblingNumber(PartGenericStructure.java:2138)
Blocked (cnt): 35714; Waited (cnt): 32780
CPU nanos: 256257725053586; User nanos: 254651820000000; Bytes allocated: 558960941120
Servlet request: 10gd6vh;ihca5tzc;16546;ov2qsw;3024310; Method context: 10gd6vh;ihca5tzc;16546;ov2qsw;3024313
at java.util.HashMap.getEntry(HashMap.java:469)
at java.util.HashMap.containsKey(HashMap.java:453)
at com.ptc.wvs.server.loader.PartGenericStructure.getNextSiblingNumber(PartGenericStructure.java:2138)
This is a printer-friendly version of Article 247546 and may be out of date. For the latest version click CS247546