Due to yet unknown reasons, this started influencing DNS lookups for localhost which now started to take 30+ seconds instead of milliseconds as before.
#JAVA FOR MAC OS SIERRA MAC OS X#
The confusion increased when discovering the issue was not reproducing in our test matrix – throughout the dozens of machines in the matrix, everything seemed to work well.Īnd then it struck – over the weekend, the good old Mac OS X in my laptop had upgraded itself to MacOS Sierra. The Logback library stuck at () has been performing the lookups for localhost for ages. "main" prio=5 tid=0x00007f97f8003000 nid=0x1c03 runnable Īt (Native Method)Īt $1.lookupAllHostAddr(InetAddress.java:901)Īt (InetAddress.java:1293)Īt (InetAddress.java:1469)Īt eu.ContextUtil.getLocalHostName(Plumbr:38) locked (a $Lock)Īt .remove(ReferenceQueue.java:151)Īt $n(Finalizer.java:209) waiting on (a $Lock)Īt .remove(ReferenceQueue.java:135) This “something else” started revealing itself when looking at thread dumps taken from the lagging JVM process via kill -3 PID: "Signal Dispatcher" daemon prio=5 tid=0x00007f97f885b000 nid=0x4103 waiting on condition
This guess was quickly dismissed as deployments of previous Agent versions resulted in the very same behavior, which was definitely not present during the previous weeks. My first guess in the hunt for the root cause of the issue was suspecting any of the recent changes in Agent.
The problem was reproducible – attaching our Java Agent even to a tiny test application increased its startup from two seconds to 30 seconds. Until the moment I found myself waiting for our Java Agent startup for minutes instead of seconds. It had been tailwinds towards the release for weeks – everything was progressing nicely. It was another Monday in the office, testing the next release of our user experience monitoring software.
0 kommentar(er)
