-1

We are getting the Caused by: java.io.InterruptedIOException: timeout exception in the logs from the server. However, the server is not giving the response code to us.

I am looking for the standard practice for the timeout monitoring to be followed in Splunk or Appdynamics to plot the graph for number of timeouts being received per second.

Shall we add the error code like 408 in the exception at client side or we should plot the graph for on basis of text "timeout" count with over the time.

Exception Logs

java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at lambdainternal.LambdaRTEntry.main(LambdaRTEntry.java:150)
Caused by: java.io.InterruptedIOException: timeout
at okhttp3.internal.connection.Transmitter.timeoutExit(Transmitter.kt:104)
at okhttp3.internal.connection.Transmitter.maybeReleaseConnection(Transmitter.kt:293)
at okhttp3.internal.connection.Transmitter.noMoreExchanges(Transmitter.kt:257)
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:192)
at okhttp3.RealCall.execute(RealCall.kt:66)
  • What is giving you `Caused by: java.io.InterruptedIOException: timeout exception`? What "logs" are you inspecting? What are you *expecting*? – warren Feb 03 '22 at 13:57
  • We are making use of Retrofit client to call the REST API . If the REST API does not responds back in time , Retrofit is throwing the java.io.InterruptedException:timeout exception. We want to monitor these exceptions in Splunk as of now by plotting the graph. I just need to understand the standard practice followed in the case when no http status code is returned ? Shall I map the http status code like myself or not ? or need to plot the graph on basis of text like "timeout". – jatin mahajan Feb 03 '22 at 15:12
  • If you "know" what a certain response "means", you can build a lookup (or other similar enrichment technique) to go from `this is an error message that should have been a code` to `error code `. The *better* way to do this, though, is to get the 'actual' error code(s) (especially when more than one response can cause a given error message) in your logs so you can differentiate *without* any special knowledge of the stack trace – warren Feb 03 '22 at 18:45

1 Answers1

0

For AppDynamics the ideal solution would be for a "bad error code" to be returned from the server - this would cause an error to be detected (and mark any associated Business Transaction as being in error) - see https://docs.appdynamics.com/22.2/en/application-monitoring/troubleshooting-applications/errors-and-exceptions#ErrorsandExceptions-BusinessTransactionError

Else you can use Custom Error Configuration to set a logger which signals errors - see https://docs.appdynamics.com/22.2/en/application-monitoring/configure-instrumentation/error-detection#ErrorDetection-ErrorDetectionConfiguration

Else you can capture values using a Data Collector and then use these in Analytics to break out errors - see https://docs.appdynamics.com/22.2/en/application-monitoring/configure-instrumentation/data-collectors + https://docs.appdynamics.com/22.2/en/analytics/configure-analytics/collect-transaction-analytics-data

Ingmar Boddington
  • 3,440
  • 19
  • 38