【发布时间】：2021-05-27 18:14:20
【问题描述】：
此问题与之前的 2 个问题有关：
- How to implement HTTP request/reply when the response comes from a rabbitMQ reply queue using Spring Integration DSL?
- How do I find the connection information of a RabbitMQ server that is bound to a SCDF stream deployed on Tanzu (Pivotal/PCF) environment?
您可以看到上面问题 2 的更新，我们可以从 rabbit sink 收到正确的响应。但是，它只有一半的时间以循环方式交替工作（成功-超时-成功-超时-...）。外部 http 应用程序是使用问题 1 中所示的 Spring Integration 实现的 - 将请求发送到请求兔子源队列并接收来自响应兔子接收器队列的响应。这仅在我们部署了外部 http 应用程序并在那里创建流（参见以下 POC 流）之后发生在 PCF 环境中。但是，它一直在本地工作（不是交替工作）。我们错过了什么吗？不知道 PCF 的罪魁祸首是什么。谢谢。
rabbitSource: rabbit --queues=rabbitSource | my-processor | rabbitSink: rabbit --routing-key=pocStream.rabbitSink.pocStream
【问题讨论】：
-
听起来您在该 PCF 环境中有多个流实例。这样，同一个 RabbitMQ 队列的订阅者就不止一个（循环感觉就像两个）。由于只有请求的发起者等待回复，因此该队列必须只有一个消费者，但奇数（或偶数）回复会发送到同一队列的不同消费者。我不把它作为答案，只是因为这是最好的猜测，因为你在本地看不到问题。
-
感谢您的快速回复！你说的有道理。现在的任务是在 PCF 中找到额外的订阅者 - 快速检查并没有发现它，但我们会继续寻找它并通知您。
-
我认为这可能类似于 PCF 中的自动缩放。抱歉，我对应用平台不熟悉。
-
嗨，Artem，对不起，我误导了你。刚刚发现我们在本地遇到了同样的问题 - 它曾经一直有效。可能是最近的一些变化造成的。仍在调查中，
-
进一步调查发现问题在于流的第二步是什么，它总是在启动时绑定兔子源队列（在我们原来的流中，第二步是一个定制的处理器，我们也试图添加一个内置的“桥”作为第二步，然后桥成为绑定兔子源队列的那个） - 我想这就是它应该做的 - 每个下一个相邻步骤都必须绑定上一步的队列以获取消息通过？如果是这样，这是否意味着我们不能将内部 SCDF 流 rabbitmq 用于外部 http 应用程序？我们必须使用独立的rabbit服务器吗？
标签： rabbitmq spring-integration cloud-foundry spring-cloud-stream spring-cloud-dataflow