Make ANALYZE_TIMEOUT_MILLIS in rocks.inspectit.agent.java.analyzer.impl.ByteCodeAnalyzer configurable

Description

Hi guys,

I have recently encountered an issue that the InspectIT instrumentation didn't work for some key transactions due to a timeout in the ByteCodeAnalyzer:

1 2 3 4 5 6 7 2018-03-03 12:19:35,129: 146689 [lt-threads - 10] WARN analyzer.impl.ByteCodeAnalyzer - Error occurred instrumenting the byte code of class ..... Sending the class structure to the CMR resulted in a time-out. java.util.concurrent.TimeoutException: null at java.util.concurrent.FutureTask.get(FutureTask.java:205) at rocks.inspectit.agent.java.analyzer.impl.ByteCodeAnalyzer.analyzeAndInstrumentInternal(ByteCodeAnalyzer.java:205) at rocks.inspectit.agent.java.analyzer.impl.ByteCodeAnalyzer.analyzeAndInstrument(ByteCodeAnalyzer.java:141) at rocks.inspectit.agent.java.SpringAgent.inspectByteCode(SpringAgent.java:233) at rocks.inspectit.agent.java.javaagent.JavaAgent.transform(JavaAgent.java:161)

I was only able to work around the issue by patching the following line to increase the timeout:

https://github.com/inspectIT/inspectIT/blob/master/inspectit.agent.java/src/main/java/rocks/inspectit/agent/java/analyzer/impl/ByteCodeAnalyzer.java#L68

It would be helpful if you would provide a system property that can be used to configure this value to avoid any code patches for such value changes. What I envision is something like:

1 private static final int ANALYZE_TIMEOUT_MILLIS = Integer.valueOf(System.getProperty("rocks.inspectit.bytecodeanalyzer.analyzer.timeout", "2000"));

This way nobody will be impacted by the change as you will always fall back to 2000 if nothing is configured.

Thanks for your consideration
Andreas

Environment

None

Status

Assignee

Unassigned

Reporter

Andreas Brunnert

Labels

None

Pull Request

None

Integrator

None

Affects versions

1.8.5

Priority

Medium
Configure