Agent initialisation error due to Lazy logic in Full Framework Elastic APM module
See original GitHub issueUsing the current version (1.1.2) of Elastic.Apm.AspNetFullFramework
and following the configuration instructions here, I get following exception on startup:
The singleton APM agent has already been instantiated and can no longer be configured
I’ve stepped into the Elastic APM code, and it appears that ElasticApmModule.Init
calls Agent.Instance
which has the effect of causing Lazy.IsValueCreated
to always return true thereafter. ElasticApmModule.Init
then continues on the next line to indirectly call Agent.Setup
which throws an exception if Lazy.IsValueCreated
returns true (which it does because of the previous line). Therefore, this is a showstopping bug as the Full Framework Elastic APM module simply cannot be used for ASP.NET with this initialisation logic.
It appears @chrisvanderpennen experienced a similar problem on #244, and also @OlegUfaev here on #441, but that relates to ASP.NET Core and can easily be circumvented with a try-catch as @pburrows suggested here. But in my case, I’m using ASP.NET with .NET Framework, so I don’t have that option as config is done through Web.config.
Please can this be fixed, and a workaround provided in the meantime?
Stack trace:
[Exception: The singleton APM agent has already been instantiated and can no longer be configured] Elastic.Apm.Agent.Setup(AgentComponents agentComponents) +139 Elastic.Apm.AspNetFullFramework.<>c__DisplayClass24_0.<InitOnceForAllInstancesUnderLock>b__0() +88 Elastic.Apm.Helpers.<>c__DisplayClass6_0.<Init>b__0() +78 System.Threading.LazyInitializer.EnsureInitializedCore(T& target, Boolean& initialized, Object& syncLock, Func`1 valueFactory) +139 Elastic.Apm.Helpers.LazyContextualInit.Init(Action initAction) +300 Elastic.Apm.Helpers.IfNotInitedHelper.Init(Action initAction) +56 Elastic.Apm.AspNetFullFramework.ElasticApmModule.InitOnceForAllInstancesUnderLock(String dbgInstanceName) +277 Elastic.Apm.AspNetFullFramework.ElasticApmModule.Init(HttpApplication context) +180 System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +587 System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +173 System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +255 System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +347
[HttpException (0x80004005): The singleton APM agent has already been instantiated and can no longer be configured] System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +552 System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +122 System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +737
Issue Analytics
- State:
- Created 4 years ago
- Comments:11 (11 by maintainers)
Thanks for letting us know @NeoXtreem.
Quick info on how/what I’d release:
We wanted to quickly push a patch to address this with the
try-catch
added in #597 (PR already open), but given that this was specific to your fork and probably won’t happen with the released package, we will skip that patch and just release #597 with the next minor release (which will be very soon).I leave the issue open to discuss the rest.
Thanks for all the feedback here.
The initialization problem is solved here - changes on the API are not planned at this point, so we’d prefer to keep those.