Правильный способ вызова метода «выстрелил-забыл» в сервисе-фабрике

У меня есть метод ServiceA, который мне нужно вызвать из ServiceB. Выполнение метода занимает более 5 минут, и меня не волнует его возвращаемое значение. (Выход из метода обрабатывается другим способом)

Я настроил свой метод в IServiceA следующим образом:

[OneWay]
Task LongRunningMethod(int param1);

Однако это не работает, потому что я получаю System.TimeoutException: This can happen if message is dropped when service is busy or its long running operation and taking more time than configured Operation Timeout.

Один из вариантов — увеличить время ожидания, но кажется, что должен быть лучший способ. Есть?


azure-service-fabric service-fabric-remoting
person TomTichy    schedule 12.06.2018    source источник
comment
Не могли бы вы предоставить фрагмент, как вы вызываете этот метод?   -  person Oleg Karasik    schedule 12.06.2018
comment
Похоже, для ваших целей отлично подойдет какая-нибудь платформа обмена сообщениями (например, Azure Queue). Вы рассмотрели это? Другой возможный подход — запустить выполнение в отдельном потоке и немедленно ответить вызывающему.   -  person Alex Riabov    schedule 12.06.2018

Ответы (1)


arrow_upward
2
arrow_downward

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

Чтобы делать то, что вы хотите, без промежуточного программного обеспечения, вашему вызывающему абоненту придется беспокоиться о многих вещах, таких как: тайм-ауты (как в вашем случае), гарантия доставки (подтверждение), доступность службы, исключения и так далее.

С промежуточным программным обеспечением единственная забота, которая нужна логике вашего приложения, — это гарантия доставки, остальное должно обрабатываться промежуточным программным обеспечением и получателем.

Есть много вариантов, например:

  • Служебная шина Azure
  • Очередь хранилища Azure
  • MSMQ
  • Концентратор событий
  • и так далее.

Я бы не рекомендовал использовать обходные пути SF Communication, Task.Run(), Threads, как предлагают многие места, потому что они просто принесут вам дополнительную работу и не будут работать так же гладко, как подход промежуточного программного обеспечения.

person Diego Mendes    schedule 12.06.2018