Приложение MVC с использованием Hangfire с несколькими очередями - PullRequest
0 голосов
/ 19 февраля 2019

Я работаю над приложением ASP.NET MVC, использующим Hangfire для постановки в очередь заданий для разных частей проекта.

Для справки, проект настроен как одно приложение с несколькими библиотеками, на которые ссылаются как на другие проекты, над которыми мы работали ранее.Сервер зависания настраивается из приложения MVC, и все методы, которые вызывают задания для постановки в очередь, находятся в разных контроллерах приложения.Существуют разные контроллеры для разных библиотек, на которые есть ссылки.

Мне удалось успешно создать задания для первой библиотеки;они поставлены в очередь в порядке, обработаны и завершены или не удалось успешноПроблема сейчас в том, что я попытался добавить вторую библиотеку в настройку Hangfire, я получаю Could not load type 'SPPC_Jobs.Controllers.FB.FBMetricsController' from assembly 'SPPC_Jobs, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' на панели мониторинга Hangfire, когда пытаюсь поставить в очередь новую работу.Так как постановка в очередь происходит от контроллера, в котором библиотека непосредственно ссылается и используется, я застрял в том, почему это происходит.Я также могу напрямую вызывать метод библиотеки из действия контроллера, и он работает нормально, сталкиваясь только с проблемой, когда он направляется к Hangfire.

Вот некоторый код, используемый в проекте для демонстрации установки и какзадания пытаются быть поставлены в очередь.

Startup.cs

GlobalConfiguration.Configuration.UseMongoStorage("...");

app.UseHangfireDashboard("/hangfire", new DashboardOptions = { 
    Authorization = System.Linq.Enumerable.Empty<IDashboardAuthorizationFilter() 
});

var options = new BackgroundJobServerOptions { Queues = new[] { "scp", "metrics" } };

app.UseHangfireServer(options);

Стоит отметить, что он использует конфигурацию MongoDB.Изначально у меня не было отдельных очередей в настройках конфигурации, но после некоторого исследования этого, похоже, это может помочь.Каждое действие контроллера имеет атрибут Queue.

Контроллер 1

Первый контроллер вызывает BackgroundJob.Schedule(() => Processor(id), scheduleDate);, который ссылается на другое созданное мной действие, которое называется Processor.Процессор берет идентификатор, запрашивает запись у базы данных (база данных SQL Server, а не mongo), а затем вызывает службу в указанной библиотеке, которая называется ProcessorService.

[Queue("scp")]
public Void Processor(int id) {
    var callback = repo.GetSocialCallback(id);

    //-- Referenced library
    var processorService = new ProcessorService();
    processorService.Process(callback);
}

Контроллер 2

Второй контроллер вызывает метод второй библиотеки по существу так же, как и первый:

BackgroundJob.Enqueue(() => Enqueue(providerClientAccount));

Метод enqueue вызывает метод указанной библиотеки следующим образом:

[Queue("metrics")]
public void Enqueue(ProviderClientAccount providerAccount) {

    //-- Referenced library
    var metricsService = new MetricsService();
    metricsService.Call(providerAccount);
}

Единственное реальное отличие, которое я вижу, состоит в том, что второй контроллер передает весь объект, а не ID.Я также попытался передать только идентификатор в метод Enqueue, запросить объект внутри этого метода и затем вызвать его, но все равно получился тот же результат.


Все вопросы / руководства/ Ошибки, которые я мог найти в похожих ситуациях, все использовали несколько проектов с одним центральным приложением для панели мониторинга Hangfire, или другие конфигурации, чем те, которые я сейчас использую.Что я не понимаю, так это то, что для этой второй библиотеки, когда я пытаюсь поставить задачу в очередь, она выдает ошибку, говорящую, что она не может загрузить тип FBMetricsController, который является контроллером, из которого она вызывается, поэтому я неНе знаю, чего мне не хватает.

Любая помощь или совет по этому вопросу будет принята с благодарностью.

1 Ответ

0 голосов
/ 19 февраля 2019

Оказывается, что более серьезная проблема заключалась в том, что существовал активный экземпляр Azure, на котором работал отдельный сервер зависания без самого современного кода, поэтому он собирался там вместо локального сервера.

...