Not publicly unless I do a new similar but generic project.
ArgumentNullException: Value cannot be null. Arg_ParamName_Name (ConnectionString)
I created a new console application with the cli generator. After that I created a module that depends on the settings module. Apparently this brings a dependency to SettingManagementDbContext. My intend was to create a unit test module to test the module and I mimiced the Domain.test -project initilaziation from another application. However this time the initilization wants to use the real database instead of the in memory -database for SettingManagementDbContext.
What should I do in the test base initialization to make a generic module to use in memory-database?
OK, I have done that. How can I share this with you?
ABP Framework version: 4.4.0
UI type: Angular
DB provider: EF Core
Tiered (MVC) or Identity Server Separated (Angular): yes
**Exception message and stack trace olo.Abp.AbpInitializationException : An error occurred during the initialize Volo.Abp.Modularity.OnApplicationInitializationModuleLifecycleContributor phase of the module Volo.Abp.Quartz.AbpQuartzModule, Volo.Abp.Quartz, Version=4.4.0.0, Culture=neutral, PublicKeyToken=null: An exception was thrown while activating λ:Quartz.IScheduler.. See the inner exception for details. ---- Autofac.Core.DependencyResolutionException : An exception was thrown while activating λ:Quartz.IScheduler. -------- Quartz.SchedulerException : Scheduler with name 'QuartzScheduler' already exists.
Stack Trace:
ModuleManager.InitializeModules(ApplicationInitializationContext context)
AbpApplicationBase.InitializeModules()
AbpApplicationWithExternalServiceProvider.Initialize(IServiceProvider serviceProvider)
AbpIntegratedTest1.ctor() BackgroundProcessesTestBase1.ctor()
SchedulerCreationFailingTestExample.ctor()
----- Inner Stack Trace -----
ActivatorErrorHandlingMiddleware.Execute(ResolveRequestContext context, Action1 next) <>c__DisplayClass14_0.<BuildPipeline>b__1(ResolveRequestContext ctxt) ResolvePipeline.Invoke(ResolveRequestContext ctxt) <42 more frames...> AsyncHelper.RunSync[TResult](Func1 func)
<>c.<ConfigureServices>b__1_1(IServiceProvider serviceProvider)
<>c__DisplayClass3_0.<Register>b__0(IComponentContext context, IEnumerable1 parameters) DelegateActivator.ActivateInstance(IComponentContext context, IEnumerable1 parameters)
DelegateActivator.<ConfigurePipeline>b__2_0(ResolveRequestContext ctxt, Action1 next) DelegateMiddleware.Execute(ResolveRequestContext context, Action1 next)
<>c__DisplayClass14_0.<BuildPipeline>b__1(ResolveRequestContext ctxt)
DisposalTrackingMiddleware.Execute(ResolveRequestContext context, Action1 next) <>c__DisplayClass14_0.<BuildPipeline>b__1(ResolveRequestContext ctxt) ActivatorErrorHandlingMiddleware.Execute(ResolveRequestContext context, Action1 next)
**Steps to reproduce the issue:
I'm tring to unit test my Quarz background workers. Whenever I run multiple tests where I initialize a backround worker the tests fail because the IScheduler is already created with another test. My tests are integration tests since I need some registered services in my workers. I dosen't make a difference if I use a new scheduler for the actual scheduling in my tests like this:
IScheduler scheduler = await GetNewScheduler();
// Act
ISchedulerListener listener = Substitute.For<ISchedulerListener>();
scheduler.ListenerManager.AddSchedulerListener(listener);
await worker.ScheduleJob.Invoke(scheduler);
My test module depend on a module that depends on AbpBackgroundWorkersQuartzModule and through that the Quartz gets initialized. It seems to me that AbpIntegratedTest initialization doesn't take into account that the Quartz cannot be initialized multiple times. I realize that this is possibly a Quarz problem but is there a some way to change the Quarz initialization so that IScheduler implementation will be initialized only once.
Hello, thank you for your answer. I wasn't quite clear on what I was testing. I'm not trying to test the Quarz library, I'm just using it as a tool in my test to assert my logic.
public Ctor(Guid tenantId, string tenantName, string scheduleDefinition)
{
Check.NotNullOrEmpty(tenantName, nameof(tenantName));
Check.NotNullOrEmpty(scheduleDefinition, nameof(scheduleDefinition));
JobDataMap jobDataMap = new()
{
{ "TenantId", tenantId }
};
JobDetail = JobBuilder.Create<ScheduledControlValueCalculationBackgroundWorker>()
.WithIdentity(TenantSpesificBackgoundProcessNameFormat.GetFormattedName(this, tenantName))
.SetJobData(jobDataMap)
.Build();
Trigger = TriggerBuilder.Create()
.WithIdentity(TenantSpesificBackgoundProcessNameFormat.GetFormattedName(this, tenantName))
/*
* Put the schedule to the definition and do the rescheduling based on that info. No other easy way to check
* if the triggers are really the same.
*/
.WithDescription(scheduleDefinition)
.WithCronSchedule(scheduleDefinition, options => options.WithMisfireHandlingInstructionFireAndProceed() )
.Build();
ScheduleJob = async scheduler =>
{
if (!await scheduler.CheckExists(JobDetail.Key))
{
await scheduler.ScheduleJob(JobDetail, Trigger);
}
else
{
// If the job already exists there might be changes to the schedule so reschedule the job if so
IJobDetail jobDetail = await scheduler.GetJobDetail(JobDetail.Key);
var trigger = await scheduler.GetTrigger(Trigger.Key);
if(trigger.Description != Trigger.Description)
{
await scheduler.RescheduleJob(trigger.Key, Trigger);
}
}
};
}
Hi, that won't matter. For some reason the module initalization tries to initialize the scheduler twice if I have two tests. The problem is in the initalization, not in how I get the scheduler in my tests.
Hello,
this https://docs.abp.io/en/abp/latest/Multi-Tenancy#imultitenant is not very clear on how should we do multitenancy in "Database per tenant" environment.
If we know that we are not going to share our data accross tenants, can we disable multitenancy all together? If not, should only the aggregates be multitenant or entities under aggregates as well?
This came up in a situation where we had both an aggregate and it's entity defined as IMultitenant but our logic only set the aggregate's tenant id in creation. This created a situation where aggregate's GetAsync, sub collection included, never populated the subcollection. Removin the IMultitenant defintion fron the entity fixed this. This got us thinkin do we still need to define aggregates and entities as multitenant if we know that tenant data will always be separated in tenant specific database?
And we should always set the tenant Id as well?
Hello, As it says here https://docs.abp.io/en/abp/latest/Background-Workers-Quartz default Abp background jobs are executed "on top of each other" if they are long running and the job polling interval is shorter. Same job is executed multiple times. This occurs only when Quartz is used with background workers. As the documentation suggests, I added AbpQuartzBackgroundJobs dependency to fix this, but this did not help. Is is so that I cannot use the default background job abstractions in this case and have to use only Quartz's abstractions all the way?
ABP Framework version: v4.4.3 Exception message and stack trace: No exceptions Steps to reproduce the issue: We have Project with Quartz for background workers and a project that contains Background jobs. The jobs are default Abp AsyncBackgroundJobs. With this configuration when ever I enqueue a background job to be excecuted, the excecution is done multiple times if background job excecution time exceeds the background job poll interval. If I unload the project that includes the AbpBackgroundWorkersQuartzModule, the background job is excecuted correctly (only once)