私は ServiceStack を使用して構築された Web API を持っています。これは、RabbitMQ 上にある MassTransit を介して TopShelf サービス バックエンドと通信します。ほとんどの場合、問題なく動作しますが、多数のリクエストがエラー キューに送られ始めるという問題が発生することがあります。
API は比較的単純で、2 つの呼び出ししかありません。私が知る限り、ログを見ると、メイン コールは正常に機能しています。ただし、もう 1 つの呼び出しは、ノードのステータスを判断するために使用される呼び出しであり、問題を引き起こしています。どちらの呼び出しも、Request/Respond メソッドを使用して同じ方法で実装されています。
エラーの 1 つからのログ ファイルを次に示します。
2012-08-25 00:01:28,544 [6] DEBUG MassTransit.Messages - SEND:rabbitmq://testapi:password@localhost:5672/test_API.Models:StatusMessage::test_API.Models.StatusMessage, Models
2012-08-25 00:01:28,575 [38] DEBUG MassTransit.Messages - SKIP:rabbitmq://testapi:password@localhost:5672/testapi_web:08cf3caf-6d81-0d5b-0050-56a800810000
2012-08-25 00:01:28,575 [38] DEBUG MassTransit.Messages - SKIP:rabbitmq://testapi:password@localhost:5672/testapi_web:08cf3caf-6d81-0d5b-0050-56a800810000
2012-08-25 00:01:28,575 [38] DEBUG MassTransit.Messages - SKIP:rabbitmq://testapi:password@localhost:5672/testapi_web:08cf3caf-6d81-0d5b-0050-56a800810000
2012-08-25 00:01:28,575 [38] DEBUG MassTransit.Messages - SKIP:rabbitmq://testapi:password@localhost:5672/testapi_web:08cf3caf-6d81-0d5b-0050-56a800810000
2012-08-25 00:01:28,575 [38] DEBUG MassTransit.Messages - SKIP:rabbitmq://testapi:password@localhost:5672/testapi_web:08cf3caf-6d81-0d5b-0050-56a800810000
2012-08-25 00:01:28,575 [38] DEBUG MassTransit.Messages - SKIP:rabbitmq://testapi:password@localhost:5672/testapi_web:08cf3caf-6d81-0d5b-0050-56a800810000
2012-08-25 00:01:28,575 [38] DEBUG MassTransit.Messages - SKIP:rabbitmq://testapi:password@localhost:5672/testapi_web:08cf3caf-6d81-0d5b-0050-56a800810000
2012-08-25 00:01:28,575 [38] DEBUG MassTransit.Messages - SKIP:rabbitmq://testapi:password@localhost:5672/testapi_web:08cf3caf-6d81-0d5b-0050-56a800810000
2012-08-25 00:01:28,575 [38] DEBUG MassTransit.Messages - SKIP:rabbitmq://testapi:password@localhost:5672/testapi_web:08cf3caf-6d81-0d5b-0050-56a800810000
2012-08-25 00:01:28,575 [38] DEBUG MassTransit.Messages - SKIP:rabbitmq://testapi:password@localhost:5672/testapi_web:08cf3caf-6d81-0d5b-0050-56a800810000
2012-08-25 00:01:28,575 [38] ERROR MassTransit.Transports.Endpoint - Message retry limit exceeded rabbitmq://testapi:password@localhost:5672/testapi_web:08cf3caf-6d81-0d5b-0050-56a800810000
2012-08-25 00:01:28,575 [38] DEBUG MassTransit.Messages - SEND:rabbitmq://testapi:password@localhost:5672/testapi_web_error:08cf3caf-6d81-0d5b-0050-56a800810000:
2012-08-25 00:01:28,575 [38] INFO MassTransit.Messages - MOVE:rabbitmq://testapi:password@localhost:5672/testapi_web:rabbitmq://testapi:password@localhost:5672/testapi_web_error:08cf3caf-6d81-0d5b-0050-56a800810000:
2012-08-25 00:01:33,888 [29] ERROR ServiceStack.ServiceInterface.ServiceBase`1 - ServiceBase<TRequest>::Service Exception
MassTransit.Exceptions.RequestTimeoutException: The request timed out: 08cf4f95-1a2b-d545-0050-56a800810000
at MassTransit.RequestResponse.RequestImpl`1.Wait() in d:\BuildAgent-03\work\8d1373c869590c5b\src\MassTransit\RequestResponse\RequestImpl.cs:line 107
at test.API.StatusService.OnGet(Status request)
at ServiceStack.ServiceInterface.RestServiceBase`1.Get(TRequest request)
タイムアウトについて不平を言っていることに注意してください。可変長を試してみましたが、役に立たないようです。データベースへの接続を見ると、消費者が実際にそれを保持するものではないように見えるため、送信時の複数の失敗が原因でタイムアウトが発生したのか、それとも単に接続の問題なのかはわかりません. 通常、応答は 1 秒以内に発生します。
リクエストは次のように行われます。
this.DataBus.PublishRequest(new StatusMessage(request, RequestType.GET), x =>
{
x.Handle<StatusResponseMessage>(message =>
{
if (message.Exception != null)
{
Response.Message = message.Exception.Message;
}
Response.Node = message.Response.Node;
Response.Status = message.Response.Status;
});
x.SetTimeout(5.Seconds());
});
消費者は次のとおりです。
public void Consume(IConsumeContext<StatusMessage> context)
{
try
{
// Get status from database (not included)
context.Respond(new StatusResponseMessage(context.Message.CorrelationId, new StatusResponsePacket(context.Message.Request.Node, status, lastUpdated)));
}
catch (Exception e)
{
context.Respond(new StatusResponseMessage(context.Message.CorrelationId, e));
}
誰かがこれで明らかに間違っていることを見ることができますか? API とサービスが異なるキューから読み取られていること (エラーは最終的に test_web_error キューに入れられる) を確認し、相関 ID と CorrelatedBy がステータス要求パケットと応答パケットに設定されていることを確認しました。前述のように、これはこの呼び出しでのみ発生し、他の呼び出しでは発生しません。これを実行している複数のサーバーもありますが、一度に1つのサーバーでのみ発生するようですが、常に同じサーバーではありません。