Activities of "ahmetfarukulu"

Hi,

Running SQL Server in the same Kubernetes cluster as your microservices is fine for development or testing because it’s easy to set up. But for production, it’s usually better to host it outside the cluster, like on an Azure VM or a managed service.

Similarly, for the login process performance test, retrieving a token from the /connect/token endpoint with 5 concurrent users and 25 requests took approximately 750-1000 ms.

Any ideas here? Or regarding my original question what are the recommended specs for a server so that the auth server responds withing 50ms-75ms for token validation and logins.

Hi @christian,

If a microservice responds slowly to each request, the issue might be different from the authentication server's token validation process. This is because, on the first request to the microservice, it retrieves the public key from the authentication server's JWKS endpoint. After that, it caches the public key and uses it for subsequent requests. However, if the problem occurs intermittently and you are sure it's related to the authentication app, you can perform some performance tests with k6 or other tools. I am adding my test result to the report for further analysis and review.

When I send a request to the authentication server JWKS endpoint with a CPU limit of 500m (3GHz base speed) and a memory limit of 512Mi.

50 concurrent users with a total of 500 requests, and it responded in approximately 65 ms after the warm-up period.

No need, I created a sample application that you can check out in abp-samples. Before testing it, make sure to build the entire solution using the dotnet build command. Afterward, you can debug the SampleRepositoryTests in the EntityFrameworkCore.Tests project.

Hi @IbrahimSarigoz,

Did you use the same interface in your EfCoreIletisimRepository? It should like;

public class EfCoreIletisimRepository : EfCoreRepository<IModuleADbContext, Iletisim, Guid>, IIletisimRepository
{
    public EfCoreIletisimRepository(
        IDbContextProvider<IModuleADbContext> dbContextProvider) 
        : base(dbContextProvider)
    {
    }
}

Lastly don't forget the add repository to your ModuleNameEntityFrameworkCoreModule class.

public class ModuleAEntityFrameworkCoreModule : AbpModule 
{
    public override void ConfigureServices(ServiceConfigurationContext context)
    {
        context.Services.AddAbpDbContext<ModuleADbContext>(options =>
        {
            options.AddRepository<Iletisim, EfCoreIletisimRepository>();
        });
    }
}

Hi @castcrewit, @sgarad,

First of all, if there is a CORS origin error, it isn't related to a data seeding problem. You should add the requested URLs to the App/CorsOrigins section for the relevant microservice, gateway, or auth server applications. CORS origin errors are only caused by browser requests, which means if you don't (and shouldn't, by the way) access the microservice applications directly, you don't need to edit the CORS settings for the microservices.

Microservice applications have a different nature than monolithic or tiered applications, which means there might be race condition problems during the startup process of each microservice.
The Administration microservice provides infrastructural tables such as AbpPermissionGrants, AbpSettings, AbpFeatureValues, etc.
We can separate infrastructural tables into two groups:

1. Storing definitions for microservices: When you define a permission, setting, or feature in development process, it stores the definition in the related table (AbpFeatureGroups, AbpFeatures, AbpPermissionGroups, AbpPermissions, AbpSettingDefinitions).
2. Storing data for users, tenants, etc.: For example, when you create a role and edit its permissions, this data is stored in AbpPermissionGrants (AbpFeatures, AbpPermissionGrants, AbpSettings).

When you deploy microservices to a cluster, each microservice starts separately and tries to insert its definitions (for Permission, Feature, Setting) into the related table. However, if the Administration microservice hasn't migrated its database yet, there may be some errors in the logs for other microservices because they can't find the Administration database at that moment. This isn't a problem because there is a retry mechanism for this process. For example, you can refer to the AbpPermissionManagementDomainModule.

Storing definitions process not using DistributedEventBus system so if there is a error it shouldn't related with the RabbitMQ. If AbpPermissionGroups and AbpPermissions tables are empty there might be following problems;

1. The distributed lock is not configured properly or couldn't connect to Redis. When the StaticPermissionSaver tries to save, it locks the saving process for other microservices. The microservice template already configures the distributed lock; you can search for the ConfigureDistributedLock method.
2. PermissionManagementOptions.SaveStaticPermissionsToDatabase was set to false manually. Since the default is true, it already saves automatically.

Last but not least, if you define a permission for a microservice and the administration microservice is already running, you will need to manually assign the related permission to the admin role. This is because only the AdministrationServiceDataSeeder seeds permissions for admin roles. However, when the Administration microservice starts, the permission for the related microservice may not be defined yet.

Latest version now gives this error (assuming it is trying to use mkcert without installing it)

Some pre-requirements are missing. If you want the application to work as expected, you need to install the following tool(s):

- mkcert. (Installation link: https://github.com/FiloSottile/mkcert)     
 
 
 

If you have already installed the tool(s), please check the PATH environment variable.

As seen in the error message, we're using the mkcert command during the solution creation process. So you should download mkcert by following the installation guide.

Is this a new feature as it has not been needed before from what I can remember?

No, it's not. If you create a microservice or app project with Kubernetes Configuration checked in the Additional Options step, then it uses the mkcert command to create the certificate.

That might be true but I get this error message now as soon as I start the ABP Studio which I have not gotten before. If it is only required for Kubernetes it perhaps should not be required?

Because we implemented the error message in the latest version.

@lizhaofeng, @Navneet@aol.com.au

You can create a new module with abp new-module Acme.BookStore -t module:ddd. For more information, visit the CLI documentation. You can also watch this tutorial.

To create a project using an open-source template, you should add the --use-open-source-template argument. For example: abp new Acme.Bookstore -csf --use-open-source-template. For more information, visit the CLI documentation.

Thanks, the command 'abp new-module Acme.BookStore -t module:ddd -u:mvc,angular' does create module project however, it does not create Host project to run, is there any command can i use to add host project to Module template

Thanks, Navneet

Unfortunately, no. However, it's in our backlog, and we're going to add it in future releases. As a workaround, you can create an app-nolayers project and import the created module.

Latest version now gives this error (assuming it is trying to use mkcert without installing it)

Some pre-requirements are missing. If you want the application to work as expected, you need to install the following tool(s):

- mkcert. (Installation link: https://github.com/FiloSottile/mkcert)   

If you have already installed the tool(s), please check the PATH environment variable.

As seen in the error message, we're using the mkcert command during the solution creation process. So you should download mkcert by following the installation guide.

Is this a new feature as it has not been needed before from what I can remember?

No, it's not. If you create a microservice or app project with Kubernetes Configuration checked in the Additional Options step, then it uses the mkcert command to create the certificate.

Latest version now gives this error (assuming it is trying to use mkcert without installing it)

Some pre-requirements are missing. If you want the application to work as expected, you need to install the following tool(s):

- mkcert. (Installation link: https://github.com/FiloSottile/mkcert)   

If you have already installed the tool(s), please check the PATH environment variable.

As seen in the error message, we're using the mkcert command during the solution creation process. So you should download mkcert by following the installation guide.

@ahmetfarukulu Why don't you use the dotnet tool? https://learn.microsoft.com/en-us/dotnet/core/additional-tools/self-signed-certificates-guide

Because it doesn't support custom domain names. https://github.com/dotnet/aspnetcore/issues/29988#issuecomment-775208189