これが正常な動作だと言うことは何も見えませんでしたので、盲目でしたらすみません笑。要求応答で MassTransit を使用すると、少し奇妙なことがわかりました。
そのため、データベースからデータを取得するなど、単純なタスクを実行するためのさまざまな要求をリッスンするサービスに複数のコンシューマーがいます。
各コンシューマーをテストするために、各コンシューマーに対して要求を実行し、応答を確認するコンソール アプリを作成しました。
私が気付いているのは、最初の要求と応答が正常に機能することですが、コードが実行されると次のチェックが応答を受信しますが、メッセージはスキップされたキューに移動されて削除されます。
これは、2 番目のリクエストの大量輸送ログです。
送信
[2021-05-14 10:27:11.812 DBG] (MassTransit.)-SEND rabbitmq://192.168.0.25/Ksrs.Requests:ConceptByConceptNoRequest d9360000-cf5b-480f-418f-08d916ba7421 Ksrs.Requests.ConceptByConceptNoRequest
受け取る
[2021-05-14 10:28:00.203 DBG] (MassTransit.ReceiveTransport.)-RECEIVE rabbitmq://192.168.0.25/DESKTOP99KLG9M_Tests_bus_5r5yyygxmpry6jgtbdctpqurrb?temporary=true d9360000-cf5b-480f-2626-08d916ba7429 Ksrs.Response.ConceptResponse MassTransit. MessageHandler<Ksrs.Response.ConceptResponse>(00:00:00.0004546)
スキップ?
[2021-05-14 10:28:41.361 DBG] (MassTransit.ReceiveTransport.)-SKIP rabbitmq://192.168.0.25/DESKTOP99KLG9M_Tests_bus_5r5yyygxmpry6jgtbdctpqurrb?temporary=true d9360000-cf5b-480f-ce25-08f3d91
まだ応答があるのにスキップが理解できません。応答は期待どおりで、コードは次に進むことができます。
これはクライアントのリクエストとレスポンスのコードで、すべてのチェックでほぼ同じです。唯一の違いは、リクエストとレスポンスのタイプです。
static async Task<bool> GetByConceptNo(AutofacServiceProvider autoFac, short ksrsId, short conceptNo, ILogger logger)
{
var client = autoFac.GetService<IRequestClient<ConceptByConceptNoRequest>>();
if (client is null) return false;
Response<ConceptResponse> response;
try
{
response = await client.GetResponse<ConceptResponse>(new ConceptByConceptNoRequest() {KsrsId = ksrsId, ConceptNo = conceptNo});
logger.LogInformation("Received {Concept}.",response.Message.Concept);
}
catch (Exception e)
{
Console.WriteLine(e);
return false;
}
return response.Message.Concept is not null;
}
いくつかのメモ:
コンテナーとして Autofac を使用します。
ロギングには Serilog を使用します。
メッセージ ブローカーとして RabbitMQ (3.8.16) を使用します。
更新: 興味深いものを見つけました。次のログ行を各コンシューマーに追加したので、実行されていることがわかります。
Logger.LogInformation("Request for [what ever consumer running goes here]");
ここで、Consumer1、Consumer2、および Consumer3 があるとします。これはログに表示されています。
Request for Consumer 1
SEND blah blah
RECIEVE blah blah
Request for Consumer 1
Request for Consumer 2
SEND blah blah
RECIEVE blah blah
Request for Consumer 1
Request for Consumer 3
SEND blah blah
RECIEVE blah blah
SEND blah blah
RECIEVE blah blah
そのため、Consumer 1 は実行を続けているようですが、コンシューマーごとにメッセージ タイプが異なり、クライアントがそれを呼び出していない場合、その理由がわかりません。