Activities of "ajayak"

Updated the config as below:

https://app.primepenguin.com,https://app-eu.primepenguin.com,https://app-fr.primepenguin.com,http://app.primepenguin.com,http://app-eu.primepenguin.com,http://app-fr.primepenguin.com,https://*.primepenguin.com,http://primepenguinapp.trafficmanager.net,http://primepenguinservice.trafficmanager.net

And our app finally works correct now.

Error:

`app.primepenguin.com/:1 Access to XMLHttpRequest at 'https://service.primepenguin.com/AbpUserConfiguration/GetAll?d=1633500363976' from origin 'http://app.primepenguin.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
polyfills-es2015.f6c3bd581483604c3304.js:1 GET https://service.primepenguin.com/AbpUserConfiguration/GetAll?d=1633500363976 net::ERR_FAILED 503

@ismcagdas, I have reverted the changes that were made to cors. Can you help me in fixing my CORS origin? Our frontend app is not able to access backend. Current config:

"CorsOrigins": "https://primepenguin.com,https://*.primepenguin.com,http://primepenguinapp.trafficmanager.net,http://primepenguinservice.trafficmanager.net,https://app-eu.primepenguin.com,https://app-fr.primepenguin.com,https://localhost:4200",

@ismcagdas, I cannot find anything useful in logs. It is only related to CORS.

@musa.demir can you also check the first query?

(@UpperBound uniqueidentifier)SELECT   [Id],
         [CreationTime],
         [CreatorUserId],
         DATALENGTH([Data]),
         [Data],
         [DataTypeName],
         [EntityId],
         [EntityTypeAssemblyQualifiedName],
         [EntityTypeName],
         [NotificationName],
         [Severity],
         [TenantId]
FROM     [dbo].[AbpTenantNotifications]
WHERE    [Id] < @UpperBound
ORDER BY [Id] ASC

2 executions of this query took almost 13 minutes as shown by Azure graph. May be this query is fetching a huge chunk of data. We have 31384 records in AbpTenantNotifications table.

Query 1:

(@UpperBound uniqueidentifier)SELECT   [Id],
         [CreationTime],
         [CreatorUserId],
         DATALENGTH([Data]),
         [Data],
         [DataTypeName],
         [EntityId],
         [EntityTypeAssemblyQualifiedName],
         [EntityTypeName],
         [NotificationName],
         [Severity],
         [TenantId]
FROM     [dbo].[AbpTenantNotifications]
WHERE    [Id] < @UpperBound
ORDER BY [Id] ASC

Query 2:

(@p0 uniqueidentifier)DELETE FROM [AbpNotifications]
WHERE [Id] = @p0

Query 3:

(@__ef_filter__p_0 bit,@__ef_filter__CurrentTenantId_1 int,@__utcNow_0 datetime2(7))SELECT [a].[Id], [a].[ExpireDate], [a].[LoginProvider], [a].[Name], [a].[TenantId], [a].[UserId], [a].[Value]
FROM [AbpUserTokens] AS [a]
WHERE ((@__ef_filter__p_0 = CAST(1 AS bit)) OR ([a].[TenantId] = @__ef_filter__CurrentTenantId_1)) AND ([a].[ExpireDate] <= @__utcNow_0)

Hi @ismcagdas,

Yes, it is the PK but in our case, we are probably sending a lot of notifications. And deleting hundreds of notifications by sending a seperate query for each delete operation is the problem. Instead of sending 100 queries, this can be optimized to send 1 query

Hi @ismcagdas,

Is it ok if I delete records from AbpTenantNotifications table directly?

Hi @ismcagdas,

We use Hangfire for all our background jobs and Hangfire handles the concurrency very well :) But these background jobs use framework's job processing. Where can I configure this? Which file? :)

Hi @ismcagdas,

I found the problem. Our redis cache configuration was not configured correctly and was not in use. The issue was file was requested from different server where file was not cached. Completely my fault