Ends in:
7 DAYS
11 HRS
27 MIN
48 SEC
Ends in:
7 D
11 H
27 M
48 S

Activities of "raif"

Thanks for the information. It's really easy to override. Thanks for abp modularization.

What I want to understand is whether this change will cause a problem in the operation of template engines (razor, scribian).

Do i need to consider to check AbpTextTemplatingScribanModule or AbpTextTemplatingRazorModule as well ?

Doh, at least i'm not the only guy who waiting that fix

I recommend you to use the second database for Hangfire server.

Yeah, you are right using separate database for Hangfire most effective solution.

BTW, I recommend that you install Volo.Abp.BackgroundWorkers.HangFire package in the startup project(.MVC, .HttpApi.Host etc..). this way it does not affect the DbMigrator project

Noted.

Cheers

Hi,

I think you should create a database first, hangfire will not create a database for you.

See: https://github.com/HangfireIO/Hangfire/blob/master/src/Hangfire.SqlServer/Install.sql

Hi, Of course we need to create DB first in place. Dbmigrator console application already exists to facilitate this database create operation, right ?

   public async Task StartAsync(CancellationToken cancellationToken)
    {
        using (var application = await AbpApplicationFactory.CreateAsync<hangfireDbMigratorModule>(options =>
        {
           options.Services.ReplaceConfiguration(_configuration);
           options.UseAutofac();
           options.Services.AddLogging(c => c.AddSerilog());
        }))
        {
            **await application.InitializeAsync();**

            await application
                .ServiceProvider
                .GetRequiredService<hangfireDbMigrationService>()
                .MigrateAsync();

            await application.ShutdownAsync();

            _hostApplicationLifetime.StopApplication();
        }
    }

So let me go step by step. Console application is going to initialize modules. Right ?

That means whenever you use Volo.Abp.BackgroundWorkers.HangFire and/or Volo.Abp.BackgroundJobs.HangFire you will also run OnPreApplicationInitialization method. Right ?

public async override Task OnPreApplicationInitializationAsync(ApplicationInitializationContext context)
{
    var options = context.ServiceProvider.GetRequiredService<IOptions<AbpBackgroundWorkerOptions>>().Value;
    if (!options.IsEnabled)
    {
        var hangfireOptions = context.ServiceProvider.GetRequiredService<IOptions<AbpHangfireOptions>>().Value;
        hangfireOptions.BackgroundJobServerFactory = CreateOnlyEnqueueJobServer;
    }
    
    await context.ServiceProvider
        .GetRequiredService<IBackgroundWorkerManager>()
        .StartAsync(); 
}

public override void OnPreApplicationInitialization(ApplicationInitializationContext context)
{
    AsyncHelper.RunSync(() => OnPreApplicationInitializationAsync(context));
}

More or less whenever you start BackgroundWorkerManager you will also going to try to create **BackgroundJobServer **

await context.ServiceProvider
    .GetRequiredService<IBackgroundWorkerManager>()
    .StartAsync();

And **BackgroundJobServer **ceration requires JobStorage .Btw BackgroundJobServer constructor used in the abp package is the obsolete one

private BackgroundJobServer CreateJobServer(IServiceProvider serviceProvider)
{
    Storage = Storage ?? serviceProvider.GetRequiredService<JobStorage>();
    ServerOptions = ServerOptions ?? serviceProvider.GetService<BackgroundJobServerOptions>() ?? new BackgroundJobServerOptions();
    AdditionalProcesses = AdditionalProcesses ?? serviceProvider.GetServices<IBackgroundProcess>();

    return new BackgroundJobServer(ServerOptions, Storage, AdditionalProcesses,
        ServerOptions.FilterProvider ?? serviceProvider.GetRequiredService<IJobFilterProvider>(),
        ServerOptions.Activator ?? serviceProvider.GetRequiredService<JobActivator>(),
        serviceProvider.GetService<IBackgroundJobFactory>(),
        serviceProvider.GetService<IBackgroundJobPerformer>(),
        serviceProvider.GetService<IBackgroundJobStateChanger>()
    );
}

If you don't define any JobStorage that will cause exception about JobStorage can't be null exception

GlobalConfiguration.Configuration
    .UseSqlServerStorage(configuration.GetConnectionString("Default"));

If you define JobStorage then it will going to execute https://github.com/HangfireIO/Hangfire/blob/master/src/Hangfire.SqlServer/Install.sql scripts.

And as you already aware of that, scripts requires database in first place.

And if you remember we are about create DB :)

Long of short: Your Volo.Abp.BackgroundWorkers.HangFire and/or Volo.Abp.BackgroundJobs.HangFire are killing DbMigrator functionality by their nature of design.

Steps to reproduce the issue :

  1. Create new application by using application template
  2. Add Hangfire.SqlServer package for job persistence
  3. Add Volo.Abp.HangFire (this should enough to force convert existing background jobs into the hangfire one like tokencleanup etc)
  4. Define connection string for job storage
  5. Run Db Migrator

Ok, thx for the fix and update, i will look forward 5.0 release

/bump

Could you wait for a few seconds when you click the PreRelease checkbox and see if it makes any difference ?

Nope, at least for me

It may also not related with marking package with "preview". Nuget server endpoint delivers un expected results Or Package marking is wrong and endpoint delivering miss information

Is there any possibility to get try count in the job code ?

Can you explain why do you want to do this?

According to following explanation https://docs.abp.io/en/abp/4.3/Background-Jobs#exception-handling Background job is automatically re-tried after certain period of time. However i would like to control it with re-try count.

In a very simple way:

  • Enqueue job after certain act (e.g. entity creation, any certain logic)
  • Try do some operation
  • If you get exception re-try again
  • If everything went well set "some value" to the "A"
  • If you tried X times and if you still get exception then set "some value" to the "B"

@gterdem Should i create new topic for my question or is it ok keep at here ? Any feedback about "multi-tenant usage of background jobs' is welcome

Thx in advance

Hi @raif, can you solved this problem ? i have a problem like this.

Yes, with help of best practice documentation i'm fine. See : https://docs.abp.io/en/abp/latest/Best-Practices/Entity-Framework-Core-Integration#repository-implementation

Showing 11 to 20 of 34 entries
Made with ❤️ on ABP v9.1.0-preview. Updated on November 20, 2024, 13:06