AI Java Agent: NullpointerException occurs if Http requests are sent asynchronously

[ghost]

Hello,

we use Application Insights in a Spring-Boot application. When using version 1.0.x we noticed the following log messages:

AI: ERROR 26-02-2018 13:21, 42: WebApp name is not found, unable to register WebApp
AI: INFO 26-02-2018 13:21, 42: Successfully registered the filter 'ApplicationInsightsWebFilter'

With version 2.0.0-BETA it is now possible to explicitly set the application name in the constructor of the WebRequestTrackingFilter class. However, this leads to the following logs:

AI: INFO 26-02-2018 13:25, 43: Registering WebApp with name 'general-payment'
AI: ERROR 26-02-2018 13:25, 43: Could not find Agent: 'com/microsoft/applicationinsights/agent/internal/coresync/AgentNotificationsHandler'
AI: ERROR 26-02-2018 13:25, 43: Failed to register 'ApplicationInsightsWebFilter', exception: 'com/microsoft/applicationinsights/internal/agent/CoreAgentNotificationsHandler'

So it seems that AI 2.0.0 additionally requires the Java Agent to be configured. Configuring the Java Agent seems to satisfy AI (no more error logs):
AI: INFO 26-02-2018 13:27, 43: Registering WebApp with name 'general-payment'
AI: INFO 26-02-2018 13:27, 43: Registered WebApp 'general-payment' key='general-payment'
AI: INFO 26-02-2018 13:27, 43: Successfully registered the filter 'ApplicationInsightsWebFilter'

However, our application asynchrounously calls a REST API on remote services in a scheduler. Whenever such an asynchronous HTTP request is issued, the following NullpointerException occurrs:

java.lang.NullPointerException: null
at com.microsoft.applicationinsights.web.internal.correlation.TelemetryCorrelationUtils.retrieveCorrelationContext(TelemetryCorrelationUtils.java:140)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)

This NPE occurrs as there is no correlation context set by the WebRequestTrackingFilter, because the request was issued by a scheduler (and is not the result of an HTTP request received by our application).

The NPE basically prevents our application from working.

So I see two issues here:

1. AI should not make it mandatory to use the Java agent (not sure if this is possible)
2. The Java Agent should never throw Exceptions that basically stop the application from working

Does this sound reasonable?

Thanks,

Jürgen
=> AI should never throw exceptions that influence the business application.

Thanks.

[dhaval24]

@julandw regarding this two errors :

AI: ERROR 26-02-2018 13:25, 43: Could not find Agent: 'com/microsoft/applicationinsights/agent/internal/coresync/AgentNotificationsHandler'
AI: ERROR 26-02-2018 13:25, 43: Failed to register 'ApplicationInsightsWebFilter', exception: 'com/microsoft/applicationinsights/internal/agent/CoreAgentNotificationsHandler'

They are fine and expected to show up when you don't use the Agent. May be we should turn them to Warning. This should not blow of your application.

Note: Agent is only needed when you want to automatically track dependency calls (SQL, Redis, HTTP via Apache HTTP Client)

You need to only add web dependencies inside the pom file to get automatic request tracking, get performance counters, pump your logs etc. You do not need to have agent for this.

Regarding Null Pointer Exception : Yes this was a bug which we came to know because of missing null check and has been fixed with #541 This issue would no longer be there in the upcoming stable release of version 2.0.0 of our SDK.

If you are interested in trying this out immediately, you are free to pull down 2.0.0-STABLE branch and build it locally. That should be able to provide you a flavor of how experience would look like (Just if you are very enthusiastic :-) )

And yes I agree, Agent should never throw which would stop production apps And regarding your first point I already mentioned Agent is not a mandatory part.

[ghost]

They are fine and expected to show up when you don't use the Agent. May be we should turn them to >Warning. This should not blow of your application.

OK. I guess the first message (Could not find Agent) should be a warning. But the second message (Failed to register...) should not show up at all, because the WebFilter could be registered, right? Basically this message caused my confusion.

Regarding Null Pointer Exception : Yes this was a bug which we came to know because of missing null >check and has been fixed with #541 This issue would no longer be there in the upcoming stable release >of version 2.0.0 of our SDK.

OK, cool. Do you have any idea when the stable 2.0.0 release is shipped (roughly)

Thanks for you quick answers.

[dhaval24]

@julandw yes the Agent message should be taken as warning and the second message - Failed to register...should not come up. That is confusing. I will open an issue for it.

Regarding the stable release, you can expect it to be out by no later than end of first week of March, if everything goes smoothly :)

[dhaval24]

@julandw we have release the Application Insights Java SDK version 2.0.0. Here is the link to release notes : https://github.com/Microsoft/ApplicationInsights-Java/releases/latest
You should be able to pull these dependencies from maven too :) Let us know your experience using this.

[ghost]

@dhaval24 I get the following error trying to download the SDK using gradle:

Could not resolve com.microsoft.azure:applicationinsights-web:2.0.0.
> inconsistent module metadata found. Descriptor: com.microsoft.azure:web:2.0.0 Errors: bad module name: expected='applicationinsights-web' found='web'

Looking at the POM in maven central shows that the artifactId is actually "web" and not "applicationinsights-web":

4.0.0 com.microsoft.azure web 2.0.0

So I guess gradle is right to complain :(

[dhaval24]

@julandw I did not tried this with gradle but I tried the same with maven and it worked fine. Not sure how this affects :( If it really does then it's bad and needs to be amended some how which I am not aware of how it would be possible as artifacts are now already on maven central.

[ghost]

@dhaval24 The problem with gradle persists:

If you have a look at the [POM file] (http://search.maven.org/#artifactdetails%7Ccom.microsoft.azure%7Capplicationinsights-web%7C2.0.0%7Cjar) you can see that the artifactId is "web" and not "applicationinsights-web" as it should be:

web

The of 2.0.0-BETA (and all the older versions) is "applicationinsights-web".

Maybe maven is more tolerant than gradle?

[dhaval24]

@julandw yes you are true, gradle blows up :( we need to get this rectified soon. Btw any idea if we can modify the pom in nexus repo? Or else we might have to push the same version back if it allows to do so with updated pom. Totally mystical how the artifact name got changed!

[dhaval24]

@julandw we have released a patch(2.0.1) to fix this issue. Please take a look at it. You should be able to pull it down from gradle/maven. I apologize for all the inconvenience in the time being.

[ghost]

@dhaval24 Everything works as expected. Thanks

[dhaval24]

@julandw thank you very much and glad to know that everything works as expected. I will close this issue then. Hoping to hear your experience with Application Insights for monitoring. Please feel free to continuously open issues on GH and provide feedback for us to improve :)

[dhaval24]

Opps, reopened this. Just remembered that this had to also do with faulty log message. Sorry for that!

[grlima]

For the confusing logs, we have created #579

[dhaval24]

@julandw by the way just wanted to ask, as of today what pieces of Application Insights are you using for monitoring your Java Applications? Is AI your primary monitoring source? If not, what is currently missing that you would love to see / is must have for Java monitoring story at your place.

[ghost]

Actually we have the requirement to collect the logs of all our microservices in a central OMS instance (instead of having individual AI instances). Because the AI-OMS connector does not transfer logs (Traces) we need to write our own Logback Appender for OMS similar to the one you already provide for AI.

[dhaval24]

@julandw thank you for the information.