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 :
Ok, thx for the fix and update, i will look forward 5.0 release
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:
@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