Thanks for the snippet.
The snippet does seem to help reduce the number of queries being made, but those queries still create sessions that remain idle in the connection pool until they’re removed 4–8 minutes later, as described here: https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/sql-server-connection-pooling#remove-connections
I reran my load test 3–4 times both with and without includeDetails: false
, and the results were almost always the same. Without includeDetails: false
, I consistently see about twice as many sessions being opened and then idled in the pool compared to when I use includeDetails: false
.
I also ran the load tests on other endpoints not directly related to Identity, and I observed the same behavior.
Do you have any idea if there might be connections that aren’t being properly disposed somewhere?
Thanks
[maliming] said: hi
Can you try setting
includeDetails
tofalse
duringResetPasswordAsync
and then try again?
var user = await IdentityUserRepository.GetAsync(input.UserId, includeDetails: false);
using System.Threading.Tasks; using Microsoft.AspNetCore.Identity; using Microsoft.Extensions.Options; using Volo.Abp; using Volo.Abp.Account; using Volo.Abp.Account.Emailing; using Volo.Abp.Account.PhoneNumber; using Volo.Abp.BlobStoring; using Volo.Abp.Caching; using Volo.Abp.DependencyInjection; using Volo.Abp.Identity; using Volo.Abp.Imaging; using Volo.Abp.SettingManagement; namespace MyCompanyName.MyProjectName; [Dependency(ReplaceServices = true)] [ExposeServices(typeof(AccountAppService), typeof(IAccountAppService))] public class MyAccountAppService : AccountAppService { protected IIdentityUserRepository IdentityUserRepository { get; set; } public MyAccountAppService( IdentityUserManager userManager, IAccountEmailer accountEmailer, IAccountPhoneService phoneService, IIdentityRoleRepository roleRepository, IdentitySecurityLogManager identitySecurityLogManager, IBlobContainer<AccountProfilePictureContainer> accountProfilePictureContainer, ISettingManager settingManager, IOptions<IdentityOptions> identityOptions, IIdentitySecurityLogRepository securityLogRepository, IImageCompressor imageCompressor, IOptions<AbpProfilePictureOptions> profilePictureOptions, IApplicationInfoAccessor applicationInfoAccessor, IdentityUserTwoFactorChecker identityUserTwoFactorChecker, IDistributedCache<EmailConfirmationCodeCacheItem> emailConfirmationCodeCache, IdentityErrorDescriber identityErrorDescriber, IOptions<AbpRegisterEmailConfirmationCodeOptions> registerEmailConfirmationCodeOptions, IIdentityUserRepository identityUserRepository) : base(userManager, accountEmailer, phoneService, roleRepository, identitySecurityLogManager, accountProfilePictureContainer, settingManager, identityOptions, securityLogRepository, imageCompressor, profilePictureOptions, applicationInfoAccessor, identityUserTwoFactorChecker, emailConfirmationCodeCache, identityErrorDescriber, registerEmailConfirmationCodeOptions) { IdentityUserRepository = identityUserRepository; } public override async Task ResetPasswordAsync(ResetPasswordDto input) { await IdentityOptions.SetAsync(); var user = await IdentityUserRepository.GetAsync(input.UserId, includeDetails: false); (await UserManager.ResetPasswordAsync(user, input.ResetToken, input.Password)).CheckErrors(); await IdentitySecurityLogManager.SaveAsync(new IdentitySecurityLogContext { Identity = IdentitySecurityLogIdentityConsts.Identity, Action = IdentitySecurityLogActionConsts.ChangePassword }); } }
Thanks
Hello,
The ResetPasswordAsync method is called when POSTing the password. In my case, the issue I have can be reproduced only by loading the /Account/ResetPassword
page which will only call the AccountAppService.VerifyPasswordResetTokenAsync
. The AccountAppService.ResetPasswordAsync
won't be called in that flow
Hello,
The code has been sent to your email.
Thanks
Log traces sent to your mail address,
Thanks
That query seems to be initiated within the ABP codebase so we don't have an easy control over it
We ran into an issue in our hosted environment where multiple users calling /Account/ResetPassword
caused SQL connections to stay idle in the connection pool instead of being released.
During user onboarding, we require all users of a tenant to reset their password. After a recent onboarding, we saw a spike in usage of the Identity and Authentication server. Both share the Identity database connection string (from the ABP microservice template).
Over a period of time, the session count on the Identity database kept increasing without ever going down. This build-up eventually exhausted the connection pool and broke our app until we restarted it.
What we saw:
Every call to /Account/ResetPassword
runs a query that gets translated to SQL like this:
Even under low usage, sessions used by this query remain idle for extended periods instead of being released back to the pool.
Impact:
/Account/ResetPassword
cause sessions to accumulate.Repro steps: I was able to reproduce this locally on SQL Server by:
Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool.
This may have occurred because all pooled connections were in use and max pool size was reached.
Is there a way to prevent this issue without having to raise our database limits?
thanks
I created a new solution on 9.2.0 and the issue is not there anymore. I will need to investigate a bit more to see what could potentially be the difference between 9.1.0 and 9.2.0 that make it works.
that does not seem to fix the issue. I have included the the css file manually in the bundle and I still have the issue.
Hello,
We’re attempting to use isolated CSS files for our Blazor components, but it appears not to work correctly when the WASM loads.
Steps to reproduce:
Is there something missing in the startup configuration?
Thanks in advance!
Hello I did create a new boilerplate and found out that it was working in the boilerplate.
I found out that the redis cache was not configured properly in my custom service and now it's working fine
Thanks for the help !!