Activities of "rickfrankel"

In fact I remember now that the IOnlineClientStore has had its generic implementations removed and to upgrade from 13.1.0 to 13.4.0 we had to make changes to the code to make it work with the new implementations.

I suspect there has been some performance impacts introduced here that is causing our problems.

We have the chat hub disabled as we don't use chat, however we have our own application specific hub as well as the abpcommonhub.

Typically we'd have a lot of clients online as well (up to 2000).

The one thing we do use is the Redis backplane for SignalR. Has something changed in that space?

We're seeing issues when we deploy as well with redis timeouts? We've never had this problem before.

Hi @oguzhanagir,

The only login we have enabled in the appsettings.json is the JwtBearer login.

AllowSocialLoginSettingsPerTenant is also set to false.

Thanks

Hi,

As can be seen in this screenshot. We deployed v13.4.0 today after upgrading from v13.1.0 and have noticed a significant increase in Redis server usage.

Is there something new in v13.4.0 that could explain the difference to v13.1.0. Is there something we should be looking at optimising.

We have a massive spike at deployment time which was around 1pm in the graph. We managed to get that stablised but are still seeing quite a lot more usage of Reids that we previously did.

Thanks Rick

Narrowing the problem some more.

changeTimeZone is still changing the date IF your localtimezone is before the timezone you are converting to.

This is because the below code converts to a DateTime object which is in the correct timezone and at the start of the day in that timezone, into your local machines time with toJSDate() which puts it to the previous day. In this case the date-range-picker-luxon-modifer then says the date has changed again and away you go endless loop.

return DateTime.fromObject({ year: year, month: month, day: day, hour: hour, minute: minute, second: second }, { zone: ianaTimezoneId }).toJSDate();

Looking at this further it is still related to this change I believe

https://github.com/aspnetzero/aspnet-zero-core/pull/4723/files

The date-range-picker-luxon-modifier.directive.ts is still changing the dates when it's changing the timezones. I think. It then causes it to endlessly fire and go back in time.

Hi @ismcagdas

Has this been resolved at all. We are still seeing this issue in version 13.

The issue happens for us in this situation.

ClockProviders.UTC is set.

In a particular tenant the timezone is set to a value that is greater than my local timezone.

Eg: I'm in Australia, so my timezone is UTC+10. My tenant is in New Zealand they are UTC+12.

If I login to the tenant that is NZ and go to the audit logs and change the date range, I get this endless looping issue.

If I login to a tenant that is in Singapore (UTC+8). The issue doesn't occur.

Hi,

We run in a load balanced environment for our app servers in production. PeriodicBackgroundWorkers don't appear to play nicely in this environment.

As they are in memory scheduled jobs they clash with each other quite often.

For example we get this error in our production logs a lot. We also re-wrote the ExpiredAuditLogDeleterWorker to be a hangfirejob.

Is there any recommendation or plans on how we can easily remove/convert these background jobs into hangfire jobs which will only run on one server and not have concurrency issues like most of the non hangfire run periodic workers do?

Thanks Rick

2024-05-15T08:35:27.585+10:00 - (null) - (null) - b1c4f22152a4 - Abp.Authorization.Users.UserTokenExpirationWorker2[[XXXX.MultiTenancy.Tenant, XXXX.Core, Version=13.1.0.1574, Culture=neutral, PublicKeyToken=null],[XXXX.Authorization.Users.User, XXXX.Core, Version=13.1.0.1574, Culture=neutral, PublicKeyToken=null]] - Abp.Domain.Uow.AbpDbConcurrencyException: The database operation was expected to affect 1 row(s), but actually affected 0 row(s); data may have been modified or deleted since entities were loaded. See https://go.microsoft.com/fwlink/?LinkId=527962 for information on understanding and handling optimistic concurrency exceptions. ---> Microsoft.EntityFrameworkCore.DbUpdateConcurrencyException: The database operation was expected to affect 1 row(s), but actually affected 0 row(s); data may have been modified or deleted since entities were loaded. See https://go.microsoft.com/fwlink/?LinkId=527962 for information on understanding and handling optimistic concurrency exceptions. at Microsoft.EntityFrameworkCore.Update.AffectedCountModificationCommandBatch.ThrowAggregateUpdateConcurrencyException(RelationalDataReader reader, Int32 commandIndex, Int32 expectedRowsAffected, Int32 rowsAffected) at Microsoft.EntityFrameworkCore.Update.AffectedCountModificationCommandBatch.Consume(RelationalDataReader reader) at Microsoft.EntityFrameworkCore.Update.ReaderModificationCommandBatch.Execute(IRelationalConnection connection) at Microsoft.EntityFrameworkCore.Update.Internal.BatchExecutor.Execute(IEnumerable1 commandBatches, IRelationalConnection connection) at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChanges(IList1 entriesToSave) at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChanges(StateManager stateManager, Boolean acceptAllChangesOnSuccess) at Pomelo.EntityFrameworkCore.MySql.Storage.Internal.MySqlExecutionStrategy.Execute[TState,TResult](TState state, Func3 operation, Func3 verifySucceeded) at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChanges(Boolean acceptAllChangesOnSuccess) at Microsoft.EntityFrameworkCore.DbContext.SaveChanges(Boolean acceptAllChangesOnSuccess) at Abp.EntityFrameworkCore.AbpDbContext.SaveChanges() --- End of inner exception stack trace --- at Abp.EntityFrameworkCore.AbpDbContext.SaveChanges() at Abp.EntityFrameworkCore.Uow.EfCoreUnitOfWork.SaveChanges() at Abp.Domain.Uow.UnitOfWorkBase.Complete() at Abp.Authorization.Users.UserTokenExpirationWorker2.DoWork() at Abp.Threading.BackgroundWorkers.PeriodicBackgroundWorkerBase.Timer_Elapsed(Object sender, EventArgs e) Abp.Domain.Uow.AbpDbConcurrencyException: The database operation was expected to affect 1 row(s), but actually affected 0 row(s); data may have been modified or deleted since entities were loaded. See https://go.microsoft.com/fwlink/?LinkId=527962 for information on understanding and handling optimistic concurrency exceptions. ---> Microsoft.EntityFrameworkCore.DbUpdateConcurrencyException: The database operation was expected to affect 1 row(s), but actually affected 0 row(s); data may have been modified or deleted since entities were loaded. See https://go.microsoft.com/fwlink/?LinkId=527962 for information on understanding and handling optimistic concurrency exceptions. at Microsoft.EntityFrameworkCore.Update.AffectedCountModificationCommandBatch.ThrowAggregateUpdateConcurrencyException(RelationalDataReader reader, Int32 commandIndex, Int32 expectedRowsAffected, Int32 rowsAffected) at Microsoft.EntityFrameworkCore.Update.AffectedCountModificationCommandBatch.Consume(RelationalDataReader reader) at Microsoft.EntityFrameworkCore.Update.ReaderModificationCommandBatch.Execute(IRelationalConnection connection) at Microsoft.EntityFrameworkCore.Update.Internal.BatchExecutor.Execute(IEnumerable1 commandBatches, IRelationalConnection connection) at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChanges(IList1 entriesToSave) at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChanges(StateManager stateManager, Boolean acceptAllChangesOnSuccess) at Pomelo.EntityFrameworkCore.MySql.Storage.Internal.MySqlExecutionStrategy.Execute[TState,TResult](TState state, Func3 operation, Func3 verifySucceeded) at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChanges(Boolean acceptAllChangesOnSuccess) at Microsoft.EntityFrameworkCore.DbContext.SaveChanges(Boolean acceptAllChangesOnSuccess) at Abp.EntityFrameworkCore.AbpDbContext.SaveChanges() --- End of inner exception stack trace --- at Abp.EntityFrameworkCore.AbpDbContext.SaveChanges() at Abp.EntityFrameworkCore.Uow.EfCoreUnitOfWork.SaveChanges() at Abp.Domain.Uow.UnitOfWorkBase.Complete() at Abp.Authorization.Users.UserTokenExpirationWorker`2.DoWork() at Abp.Threading.BackgroundWorkers.PeriodicBackgroundWorkerBase.Timer_Elapsed(Object sender, EventArgs e)

I have confirmed that 13.1.0 and the latest preview VS works again.

Thank you :) We're still going through our full round of testing and updates to our project to 13.1.0. Will let you know if we find anything else. I'm watching that github issue now.