RabbitMQ - メッセージごとに1つのスレッドを確保する

Question

私はキューに入れられたメッセージのメカニズムにNServiceBusを使用するプログラムを持っています。 ログには、メッセージが別のスレッドによって2回処理されることがありますが、これらのメッセージは1回のみ送信されることがあります。

さらに、私のサービスでスレッドを1つだけ使用すると、この問題は発生しません。

メッセージを一度しか処理できないようにするにはどうすればよいですか？

ありがとうございます。

短縮されたログの例（chunkId 48でメッセージが表示され、コールバックを削除するなどの処理がすべて終了した後、chunkId 48で同じメッセージが再び表示され、この時点でコールバックが見つかりません。そしてその後、NserviceBus例外）：

Risco.Rsp.RACServiceImpl.RACOutputMessageHandler [（ヌル）] <（ヌル）> - PROCESSTYPEため起動RACOutputMessageHandler.Handle：PROCESSIDとGetClientCacheEntity：44eb600b-87e6-4eab- a54e-0a12480c9784およびChunkId：48およびTotalChunks：57およびトピック：23b041a3-4a62-48d1-a199-20a20e5de72a .... .... ... 0プロセスID：44eb600b-87e6-4eab-a54e-0a12480c9784（プロセスタイプ：GetClientCacheEntity、クライアント44eb600b-87e6-4eab）の結果を送信しました。 -A54e-0a12480c9784（チャンク0） 2017-01-02 11：13：13,882 [64] INFO RAC.RACServiceImpl.RACOutputMessageHandler [（null）] <（null）> - RACOutputMessageHandler.Handle start for ProcessType： ProcessId：44eb600b-87e6-4eab-a54e-0a12480c9784およびChunkId：48およびTotalChunks：57およびトピック：23b041a3-4a62-48d1-a199-20a20e5de72a 2017-01-02 11：13：13,888を持つGetClientCacheEntity [64] INFO Risco。ハンドリング（RACOutputMessage） - キー44eb600b-87e6-4eab-a54e-0a12480c9784、プロセスID：44eb600b-87e6-4eab-a54e-0a12480c9784のコールバックを見つけることができません。Rsp.RACServiceImpl.RACOutputMessageHandler [（null）] <プロセスタイプ：GetCメッセージを遅らせる問題がありました。lientCacheEntity 2017-01-02 11：13：13,923 [158]エラーNServiceBus.Timeout.TimeoutManagerDeferrer [（null）] <（null）>エンドポイントに対してDisableTimeoutManagerが呼び出されていないことを確認してください。 NServiceBus.Unicast.Queuing.QueueNotFoundException：受信者のExchangeが存在しない---> RabbitMQ.Client.Exceptions.AlreadyClosedException：既に閉じられている：AMQP操作が中断されました：AMQP close-reason、ピアによって開始された、code = 404、 = "NOT_FOUND - Vhostの 'AxesPlus'でRisco.Rsp.Ac.AMAC.Service.Timeouts 'を交換しないでください、classId = 60、methodId = 40、原因= at RabbitMQ.Client.Impl.ModelBase.WaitForConfirms（TimeSpanタイムアウトNServiceBus.Transports.RabbitMQ.ConfirmsAwareChannel.Dispose（）C中でRabbitMQ.Client.Impl.ModelBase.WaitForConfirmsOrDie（TimeSpanのタイムアウト） で、ブール& TIMEDOUT） ：\ BuildAgent \仕事\ ef98ad7376e3379a \ SRC \ NServiceBus.RabbitMQ \ ConfirmsAwareChannel.cs：行31 --- NacviceBus.Transports.RabbitMQの内部例外スタックトレースの末尾--- 。 CにおけるConfirmsAwareChannel.Dispose（）：\ BuildAgent作業\ \ ef98ad7376e3379a \ SRC \ NServiceBus.RabbitMQ \ ConfirmsAwareChannel.cs：C線におけるNServiceBus.Transports.RabbitMQ.RabbitMqMessageSender.Send（TransportMessageメッセージ、SendOptions sendOptions）で47 ：\ BuildAgent \ work \ ef98ad7376e3379a \ src \ NServiceBus.RabbitMQ \ RabbitMqMessageSender.cs：行27 at NServiceBus.Timeout.TimeoutManagerDeferrer.Defer（TransportMessageメッセージ、SendOptions sendOptions）をC：\ BuildAgent \ work \ 3206e2123f54fce4 \ src \ NServiceBus.Core \ Timeoutに作成します。 \ Core \ TimeoutManagerDeferrer.cs：行42 2017-01-02 11：13：13,936 [174]エラーNServiceBus.Timeout.TimeoutManagerDeferrer [（null）] <（null）> - メッセージを遅延させる問題がありました。エンドポイントに対してDisableTimeoutManagerが呼び出されていないことを確認してください。 NServiceBus.Unicast.Queuing.QueueNotFoundException：受信者のExchangeが存在しない---> RabbitMQ.Client.Exceptions.AlreadyClosedException：既に閉じられている：AMQP操作が中断されました：AMQP close-reason、ピアによって開始された、code = 404、 = "NOT_FOUND - Vhostの 'AxesPlus'でRisco.Rsp.Ac.AMAC.Service.Timeouts 'を交換しないでください、classId = 60、methodId = 40、原因= at RabbitMQ.Client.Impl.ModelBase.WaitForConfirms（TimeSpanタイムアウトNServiceBus.Transports.RabbitMQ.ConfirmsAwareChannel.Dispose（）C中でRabbitMQ.Client.Impl.ModelBase.WaitForConfirmsOrDie（TimeSpanのタイムアウト） で、ブール& TIMEDOUT） ：\ BuildAgent \仕事\ ef98ad7376e3379a \ SRC \ NServiceBus.RabbitMQ \ ConfirmsAwareChannel.cs：行31 --- NacviceBus.Transports.RabbitMQの内部例外スタックトレースの末尾--- 。 c：\ BuildAgent \ work \ ef98ad7376e3379a \ src \ NServiceBus.RabbitMQ \ ConfirmsAwareChannel.csのConfirmsAwareChannel.Dispose（）：行47 at NServiceBus.Transports.RabbitMQ.RabbitMqMessageSender.Send（TransportMessageメッセージ、SendOptions sendOptions）in c：\ BuildAgent \ work \ ef98ad7376e3379a \ src \ NServiceBus.RabbitMQ \ RabbitMqMessageSender.cs：行27 at NServiceBus.Timeout.TimeoutManagerDeferrer.Defer（TransportMessageメッセージ、SendOptions sendOptions）をC：\ BuildAgent \ work \ 3206e2123f54fce4 \ src \ NServiceBus.Core \ Timeoutに作成します。 \ Core \ TimeoutManagerDeferrer.cs：行42

Answer 1

問題はタイムアウトの設定でした。 MessageHandlerはメッセージを処理してハンドラを残すほど速くないので、ハンドラを '置き換える'新しいタスクを作成することで修正しました（つまり、ハンドラの開始時に元のハンドラを置き換える関数を呼び出す）。