Skip to content
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

Closed
yang-xiaodong opened this issue Nov 25, 2017 · 3 comments

Comments

@yang-xiaodong
Copy link
Member

commented Nov 25, 2017

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有哪些。

image

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 , 不存在以上问题。

@yang-xiaodong

This comment has been minimized.

Copy link
Member Author

commented Nov 29, 2017

在 v2.1.1+ 版本中,当应用程序启动时CAP会将默认Group设置为当前程序集名称,这样可以一定程度解决队列冲突问题。

@yang-xiaodong

This comment has been minimized.

Copy link
Member Author

commented Dec 28, 2017

另外一个原因触发这个异常是:

由于不同的实例连接到了相同的数据库,CAP要求相同的实例可以连接同一个库,不同的实例需要连接不同的数据库。

Another reason triggers this exception:
Because different instances connect to the one database, CAP requires the same instance can connect to one database, But different instances need to connect to the different databases.

@2821840032

This comment has been minimized.

Copy link

commented Nov 24, 2018

我遇到了这个问题,有一个项目无论怎么改都会报错,但是相同的代码放在另一个项目中完美运行。
数据库里的Content字段引导我来到了这里。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.