aspnetboilerplate: Intermittant blocked calls
- Abp package version: NuGet 4.1.0
- Base framework: targetting .Net Framework 4.7.2 / .Net Core 2.2.1
- Exception message: N/A
- Stack trace: I only have a screenshot, I’m not able to reliably repro but I’ll get a text stack trace next time.
- Steps needed to reproduce the problem: The problem is intermittent and has only been reproduced (randomly) in a development environment a handful of times. In our Test Environment, the issue occurs ~3 times a day (24 hrs).
- Issue definition:
- Seemingly randomly calls that are made to
AbpUserConfiguration.GetAll()
will never complete, it appears that the request never completes possibly due to a thread/table lock. - I copied the
AbpUserConfigurationBuilder class
to our code-base to better try and debug the issue. Luckily I was able to replicate the issue locally I got to a point where I found calls tovar languages = LanguageManager.GetLanguages();
became blocked (see screenshot). - Once the code-base gets itself into this state ALL calls to the UserConfiguration will block and never complete. It’s as though a mutex/lock has occurred. At first, I thought the issue would be limited to a single user but this is not the case, all calls to this endpoint whether logged in or not will fail.
- It appears that somewhere within the
GetLanguage
call theAsyncEx.Run
call becomes blocked forever. - There’s no exception raised at runtime or in the log file.
- The threads never appear to end, as I make subsequent calls to the endpoint I can see the existing threads in the Threads panel.
The issue has been seen in development environment (Windows 10, VS2017), Azure AppService, self-hosted (Windows server 2016).
Please, I’m seeking assistance/help/guidance at the possible root cause here? Without a reliable way to repro the issue I understand it’s a tough issue to crack - please let me know if there’s any other info I can attempt o retrive. The only workaround we have at the moment is recycling the IIS Application pool.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 15 (6 by maintainers)
AspNet RAD tool shows as
1.8.0.2
in VS2017 Zero version6.6.0
as shown in Zero download page.L
usage was our very first service written in late Sep-2018, at the time we were using ObjectMapper but later switched to manually returning a DTO bypassing ObjectMapper.L("")
was introduced by a developer to solve a problem, we didn’t know the potential impact. Moving forward we’ll be sure not to reuse this pattern.I’m quite confident that the
L("")
within the EF query causes our random lockups. We’re now in day 4.5 and Dev-env and QA-env have not had a single lockup. We used to see at least 3 app-pool recycles a day.I’m still wary that it may manifest in some other way such as @jmhinnen is seeing. I will close this ticket for now.