"chris.tune@gmail.com" की गतिविधियाँ

Thanks @yekalkan

So If I'm creating a module which can be used across all types of project(angular MVC etc) I would add a migration to each type of host?

Can I double-check the route as well. At the moment the commercial template uses the following in the route module:

{ path: 'identity', loadChildren: () => import('@volo/abp.ng.identity').then(m => m.IdentityModule.forLazy()), },

Does this need to be changed to @abp/ng.identity ?

Great thanks for the clarification :)

Hi All

Just a bit of an update.

We were originally using version 3 then 4, where the error occurred.

We have upgraded to 5.1.3 **and we haven't had the problem since. **

But we did make other changes too... mainly due to differences in the microservices templates from version 3 to 5. We had also missed something from the upgrade guide from 3 to 4.

I would recommend upgrading if possible. If that does not work then a template comparison of the microservices template/template with your current one may help.

I think even the order of our middleware may have been a contributor.

It is time-consuming but we did resolve a lot of small issues.

I don't think this is a 'reproduce' problem as such as it will happen on any install. I've just looked at the source code there is a TODO to optimize/cache.

Just wondering if there is a way to improve this speed

Awesome thanks so much!

hi

Can you share a project that reproduces the problem with me? liming.ma@volosoft.com

Hi, I've invited you to a git hub repo. Let me know if this was the right email address. It's a basic starter template MVC style, non-tiered.

I've noticed that the token **does **come through on the initial authentication request - e.g. when registering. After that, it does not seem to come through. I think it might be associated with the external cookie, which then gets wiped out?

The above was for a POC, but - We are using the microservices solution in our production environment, so I'm guessing we would need to take a different approach to this as well as the token would need to be handled by the identity server and then potentially stored in a cache?

Cheers :)

Can you watch the webserver memory and check it when it occurs?

Will do.

Hi,

ICurrentTenant.Change is the only way to operate on a specific tenant in a background worker. I can recommend to create a separate console application for the background workers and run only a single instance of that application. Otherwise, if you make it a part of a service, you should care when you run multiple instances of that service - the worker may work on the same data which may cause duplications.

Disabling the tenancy filter is needed if you want to query from all tenants. It can only work for "shared database" approach. It can't work if a tenant has a seperate database. However, if you want to query a list of tenants (from the AbpTenants table), no need to disable the tenancy filter, because the Tenant entity is not multi-tenant.

In your background worker app, you can add a reference to the Volo.SaaS.EntityFrameworkCore and set the connection string for the saas database. Alternatively, you can perform a call to the SaaS service if you don't want to access the SaaS db from the worker app. But, I suggest to use the db.

Thanks for the info, that makes a lot of sense!

Hi

I just tried to upgrade to business, but when the payment redirected back there was a 403 error(10005) on the abp.io site. I'm not sure if the payment went through or it stopped.

Is there anyway of finding out?

Chris