RabbitMQ - 确保每封邮件的单个帖子

时间:2017-01-02 09:37:15

标签: c# multithreading rabbitmq nservicebus

我有一个程序,它使用NServiceBus作为排队消息机制。 我在日志中看到有时消息被不同的线程处理两次,尽管这些消息只发送一次。

更多,如果我强制我的服务只使用1个线程,我没有这个问题。

如何确保邮件只处理一次?

谢谢。

缩短日志示例(在那里​​你可以看到我收到chunkId 48的消息,我完成了处理所有内容,包括删除回调,然后我再次收到与chunkId 48相同的消息,此时我无法找到回调。然后,NserviceBus异常):

  

Risco.Rsp.RACServiceImpl.RACOutputMessageHandler [(null)]<(null)> - RACOutputMessageHandler.Handle为ProcessType启动:GetClientCacheEntity与ProcessId:44eb600b-87e6-4eab-a54e-0a12480c9784和ChunkId:48和TotalChunks:57和主题:23b041a3-4a62-48d1-a199-20a20e5de72a   ....   ....   ...   Risco.Rsp.RACServiceImpl.RACOutputMessageHandler [(null)]<(null)> - Sucessfuly发送结果(一个或多个)的进程id:44eb600b-87e6-4eab-a54e-0a12480c9784与进程类型:GetClientCacheEntity,客户端44eb600b-87e6-4eab-a54e-0a12480c9784(组块0的0)   2017-01-02 11:13:13,882 [64] INFO Risco.Rsp.RACServiceImpl.RACOutputMessageHandler [(null)]<(null)> - RACOutputMessageHandler.Handle为ProcessType启动:GetClientCacheEntity与ProcessId:44eb600b-87e6-4eab-a54e-0a12480c9784和ChunkId:48和TotalChunks:57和主题:23b041a3-4a62-48d1-a199-20a20e5de72a   2017-01-02 11:13: 13,888 [64] INFO Risco.Rsp.RACServiceImpl.RACOutputMessageHandler [(null)]<(null)> - Handle(RACOutputMessage) - 无法找到关键字44eb600b-87e6-4eab-a54e-0a12480c9784的回调,进程ID:44eb600b-87e6-4eab-a54e-0a12480c9784,进程类型:GetClientCacheEntity   2017-01-02 11:13:13,923 [158] ERROR NServiceBus.Timeout.TimeoutManagerDeferrer [(null)]<(null)> - 延迟消息时出现问题。确保没有为您的端点调用DisableTimeoutManager。   NServiceBus.Unicast.Queuing.QueueNotFoundException:收件人的Exchange不存在---> RabbitMQ.Client.Exceptions.AlreadyClosedException:已经关闭:AMQP操作被中断:AMQP close-reason,由Peer发起,code = 404,text =" NOT_FOUND - no exchange' Risco.Rsp.Ac。 AMAC.Service.Timeouts'在vhost' AxesPlus'",classId = 60,methodId = 40,cause =      在RabbitMQ.Client.Impl.ModelBase.WaitForConfirms(TimeSpan timeout,Boolean& timedOut)      在RabbitMQ.Client.Impl.ModelBase.WaitForConfirmsOrDie(TimeSpan超时)      位于c:\ BuildAgent \ work \ ef98ad7376e3379a \ src \ NServiceBus.RabbitMQ \ ConfirmsAwareChannel.cs中的NServiceBus.Transports.RabbitMQ.ConfirmsAwareChannel.Dispose():第31行      ---内部异常堆栈跟踪结束---      位于c:\ BuildAgent \ work \ ef98ad7376e3379a \ src \ NServiceBus.RabbitMQ \ ConfirmsAwareChannel.cs中的NServiceBus.Transports.RabbitMQ.ConfirmsAwareChannel.Dispose():第47行      位于c:\ BuildAgent \ work \ ef98ad7376e3379a \ src \ NServiceBus.RabbitMQ \ RabbitMqMessageSender.cs中的NServiceBus.Transports.RabbitMQ.RabbitMqMessageSender.Send(TransportMessage message,SendOptions sendOptions):第27行      在NServiceBus.Timeout.TimeoutManagerDeferrer.Defer(TransportMessage消息,SendOptions sendOptions)在C:\ BuildAgent \工作\ 3206e2123f54fce4 \ SRC \ NServiceBus.Core \超时\核心\ TimeoutManagerDeferrer.cs:线42   2017-01-02 11:13:13,936 [174] ERROR NServiceBus.Timeout.TimeoutManagerDeferrer [(null)]<(null)> - 延迟消息时出现问题。确保没有为您的端点调用DisableTimeoutManager。   NServiceBus.Unicast.Queuing.QueueNotFoundException:收件人的Exchange不存在---> RabbitMQ.Client.Exceptions.AlreadyClosedException:已经关闭:AMQP操作被中断:AMQP close-reason,由Peer发起,code = 404,text =" NOT_FOUND - no exchange' Risco.Rsp.Ac。 AMAC.Service.Timeouts'在vhost' AxesPlus'",classId = 60,methodId = 40,cause =      在RabbitMQ.Client.Impl.ModelBase.WaitForConfirms(TimeSpan timeout,Boolean& timedOut)      在RabbitMQ.Client.Impl.ModelBase.WaitForConfirmsOrDie(TimeSpan超时)      位于c:\ BuildAgent \ work \ ef98ad7376e3379a \ src \ NServiceBus.RabbitMQ \ ConfirmsAwareChannel.cs中的NServiceBus.Transports.RabbitMQ.ConfirmsAwareChannel.Dispose():第31行      ---内部异常堆栈跟踪结束---      位于c:\ BuildAgent \ work \ ef98ad7376e3379a \ src \ NServiceBus.RabbitMQ \ ConfirmsAwareChannel.cs中的NServiceBus.Transports.RabbitMQ.ConfirmsAwareChannel.Dispose():第47行      位于c:\ BuildAgent \ work \ ef98ad7376e3379a \ src \ NServiceBus.RabbitMQ \ RabbitMqMessageSender.cs中的NServiceBus.Transports.RabbitMQ.RabbitMqMessageSender.Send(TransportMessage message,SendOptions sendOptions):第27行      在NS:serviceBus.Timeout.TimeoutManagerDeferrer.Defer(TransportMessage message,SendOptions sendOptions)C:\ BuildAgent \ work \ 3206e2123f54fce4 \ src \ NServiceBus.Core \ Timeout \ Core \ TimeoutManagerDeferrer.cs:第42行

1 个答案:

答案 0 :(得分:0)

问题是超时配置。 MessageHandler还不够快,无法处理消息并离开处理程序,所以我通过创建一个新的任务来修复它,这将取代'处理程序(意思是,在处理程序的开头调用替换原始处理程序的函数)