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

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

Is Hot sensor placement automatically will lead to agent disconnect in dT 6.5


Hi All,

After upgrade from dT 6.3 to 6.5 we can see agent connected successfully after couple of restarts bcoz in single restart we faced partial instrumentation issue, after couple of restarts agents connected successfully. Once users starts accessing the application then we noticed suddenly few agents disconnection happened in app servers(Jboss + JVM) where we placed agents.

In all agent logs both connected as well as not connected we can see below lines

2017-02-19 22:31:00 [000004c4] info [native] Found high autosensor overhead, might hint to time drift problem, tsCounter: 7766

2017-02-20 13:24:46 [000004d0] info [java ] Logging Properties changed

2017-02-20 13:25:26 [000004d0] info [native] Hot sensor placement request for 1 class(es) (2 KiB) took 193ms.

2017-02-20 13:25:26 [000004d0] info [native] redefineClasses took 190ms.

2017-02-20 13:25:26 [000004d0] info [native] 0 error(s) occurred, 1/1 class(es) redefined in 1 step(s).

2017-03-02 07:44:05 [00422798] warning [java ] [jdbc ] JBoss transformConnection 1: java.lang.NullPointerException

Also gone through the below Forum discussion,

Can any one help me to understand the what is time drift problem..Also i am guessing that may be Hot sensor placement might cause after read the above URL.

Kindly share your view about this issue and possible soltuion


Soorya Mohan


DynaMight Leader
DynaMight Leader

Hello Soorya,

If you have a virtual environment then read the following information provided by the dynatrace support team:

The autosensor overhead measurement is to verify how long it takes getting a thread dump of all threads with sensors on it. So if it measures high overhead, it is reducing the interval to not cause overhead issues and additionally slow down a maybe already busy server.
This measurement can be unreliable in case the application server is virtualized and the VM is moved to different physical CPU cores by the hypervisor. Then the timers are most likely jumping ahead or back in time and if so, we might also detect "high overhead" even if there is no problem. 'Low-Res System Clock' should always work, but you can also try others. The change gets active on the next agent restart.

Also check the following post:




Hi Babar,

Thanks for your prompt reply. Yes its a VMWare.

We will try out 'Low-Res System Clock' and other options. (system profile -> Agent Group -> Agent Mapping -> Advanced). Usually the "Low Res System Clock" resolves such timing issues (on the agent side)


Soorya Mohan