I have multiple databases each with their own set of hangfire tables. I am hoping to have one dashboard to monitor them all. I see this question has been asked a few times without any answer.
Multiple calls to app.UseHangfireDashboard with the same url don’t seem to stack. Do I have to specify different Urls and monitor each database separately?
Monitoring multiplle databases in one dashboard is not possible. Moreover, current architecture won’t allow multiple dashboards inside a single process, even with different urls, because it heavily relies on static properties like JobStorage.Current. The best you can do at the moment is putting them into different virtual applications.
I managed to get round the issue, in an ASP.NET Core application. I have multiple dashboards in one app, all using their own storage, so in order to overcome the JobStorage.Current singleton issue, you have to find a way to set this to something other than null when HF comes to needing it.
So by stepping into the pipeline, using a call to app.Use(…) and then inspecting the request path, you can determine if the request is a HF request, and then set the JobStorage.Current property to an instance that you have created in the Configure(…) method, something like:
app.Use(async (context, next) =>
{
var pathString = context.Request.Path.Value;
// Here we're only interested in when the dashboard needs to 'trigger' a job...
if (pathString.EndsWith("trigger", StringComparison.InvariantCultureIgnoreCase))
{
// Is it our sms dashboard?
if (pathString.Contains("/hangfire-sms"))
{
JobStorage.Current = smsStorage; // Set the current storage to be our sms storage instance
}
// Is it our email dashboard?
if (pathString.Contains("/hangfire-email"))
{
JobStorage.Current = emailStorage; // Set the current storage to be our email-storage instance.
}
}
await next.Invoke();
});
Note:- This is only safe if 1 user is busy with the site. The moment you get 2 or more requesting different dashboard paths, then the setting of JobStorage.Current could potentially overlap/overwrite a previous request that may be still executing.
Ultimately, the architecture SHOULD change so that the Storage associated with the instance supplied to .UseHangfireDashboard(…) is the one that the request pipeline picks up.