-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RabbitMQ : SubscriberNotFoundException #63
Comments
在 v2.1.1+ 版本中,当应用程序启动时CAP会将默认Group设置为当前程序集名称,这样可以一定程度解决队列冲突问题。 |
另外一个原因触发这个异常是: 由于不同的实例连接到了相同的数据库,CAP要求相同的实例可以连接同一个库,不同的实例需要连接不同的数据库(或使用TableNamePrefix|Schema 指定不同的表前缀|空间)。 Another reason triggers this exception: |
我遇到了这个问题,有一个项目无论怎么改都会报错,但是相同的代码放在另一个项目中完美运行。 |
I'd just like to note that this does not seem to be the case, as I just received this error using Kafka. I have two copies of the same service, one with the default group and one with the group set to something different so I can guarantee one will receive all messages for testing. |
Sorry, I am not quite sure how to resolve this. Exception message brings me to this page. I tried to remove the exchange and unbind the queue. But I am still getting the exception: {"Headers":{"cap-msg-group":"cap.queue.logserver.v1","cap-exception":"SerializationException-->Message can not be found subscriber. Name:, Group:cap.queue.logserver.v1. \r\n see: https://github.com/dotnetcore/CAP/issues/63"},"Value":"data:UnknownType;base64,ZA=="} |
@ajaffie |
Ok thanks.
…On Mon, 3 Aug 2020 at 8:46 AM, Savorboard ***@***.***> wrote:
@ajaffie <https://github.com/ajaffie> data:UnknownType;base64,ZA== This
is because the message type you produce cannot be converted by the consumer
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#63 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGDEEVV2ACQYZHQYLLAWIYTR6YCFXANCNFSM4EFKGPHQ>
.
|
UseInMemoryMessageQueue |
Hi, i found this error many times in my project. what i can see is that the retry processor is trying to resolve all the receive failure all the group without filtering its own subscription. GetReceivedMessagesOfNeedRetry() private async Task ProcessReceivedAsync(IDataStorage connection, ProcessingContext context)
do you think we should filter the events here? |
@desperazo You need to check whether you use the same event table in multiple services by mistake, different services need to have their own event tables |
查log的时候出现这个异常,最后发现真实异常可能会写在数据库cap.received,content——Headers——cap-exception中。 |
我kafka也发现了一样的问题 找不到订阅者 直接卡这个找不到订阅者 不消费? |
Is...solved? |
no |
@henrydingchina yes, please see above |
如果是用着用着出问题的话,把cap.published与cap.received数据全清了。 |
我用的是kafka 但是也出现了这个报错 不知道该怎么解决 |
Message (Name:SJZY.FMC.VoucherRedundantCalc,Group:cap.queue.resharpertestrunner.v1) can not be found subscriber. |
For any future visitors: This exception can also be triggered if you forgot to register your Queue Handlers with the Dependency Injection engine! |
你这个问题解决了吗?我现在生产者和消费者是两个不同的程序,当生产者和消费都都连接配置到同一个数据库实例时,生产者也就会收到这个错误,但是消费都是正常的。 |
另外一个原因触发这个异常是: 请问一下:通过SqlServerStorageInitializer为不同实例各建1张数据库表,是否就可以连接到相同数据库了? |
@daimeiquan https://cap.dotnetcore.xyz/user-guide/zh/samples/faq/ Use different |
This situation is because the Queue is bound to the RoutingKey before using RabbitMQ because the Queue is persistent, so the previously bound RoutingKey will not be lost.When you reduce the subscription to RoutingKey, you actually have the same RoutingKey that was bound before the RabbitMQ end, so you get messages from previous subscriptions.
这个情况是由于在使用RabbitMQ的时候以前 Queue上绑定过 Routing Key,因为 Queue是持久化的,所以之前绑定的RoutingKey不会丢失。当你减少RoutingKey的订阅以后,实际上在RabbitMQ端以前绑定的RoutingKey还存在,所以会收到以前的订阅的消息。
You can see the current Queue binding's RoutingKey in the admin page.
你可以在管理页面看到当前的Queue绑定的RoutingKey有哪些。
Solution :
解决方案:
I tried to remove all the binding of RoutingKey by modifying the code and then rebinding, but RabbitMQ didn't provide the relevant API.
我尝试通过修改代码的方式来删除所有绑定的RoutingKey然后重新绑定,但是RabbitMQ没有提供相关API。
Another way to do this is to unbind a specific RoutingKey, but I can't get access to the already binding RoutingKey, which is only available through the client tool, so it's not feasible.
另外一种方式解绑某个具体的RoutingKey,但是我无法获取到已经绑定的RoutingKey有哪些,这个只能够通过客户端工具来获取,所以此种方案不可行。
After careful consideration, I don't think it should be done by CAP program, if there is a scene.Project A and Project B is subscribed to the same Group, A Group of Topic, corresponding to the RabbitMQ are they listening to the same queue, when ProjectA reduce the subscribed to the Topic, for some reason so if unbundling RoutingKey causes ProejctB cannot receive related to subscribe to news, this is obviously wrong behavior.
通过仔细思考后,我认为不应该由CAP程序来做这个事情,假如有以下场景。Project A 和Project B都订阅了同一Group组的Topic,对应到RabbitMQ也就是他们监听的是同一个队列,当ProjectA由于某种原因减少Topic的订阅了,那么如果解绑了RoutingKey会导致ProejctB也无法收到相关订阅的消息,这显然是错误的行为。
So I decided to let the user to do this, and they said if you reduce the subscription topic, so you need to manually to the rabbitmq console the queue is removed (unbundling) old topic, and then the user must make clear the expected behavior of the message queue.
所以我决定让使用者来做这个事情,也是就说如果你减少了订阅的topic,那么你需要手动去rabbitmq的控制台的queue中删除(解绑)旧的topic,那么使用者就必须要清楚消息队列的预期行为。
In addition, this place where the program is wrong will be treated as a more elegant prompt, because it is also a warning to the user!.
另外,程序报错的这个地方我会处理为一种更加优雅的提示方式,因为这对使用者来说也是一个警告!。
PS: if Kafka is used, there are no problems.
PS: 如果使用 Kafka , 不存在以上问题。
The text was updated successfully, but these errors were encountered: