spring-integration-aws流上的消息属性导致SQS消息循环，哪里是过滤它们的最佳位置？

Question

因此，我创建了几个短流，使用SQS作为处理段之间的后备存储。基本流程是：

RestController -> SQS Queue1 OCA
  SQS Queue1 MDCA -> Service-Adapter -> SQS Queue2 OCA
  SQS Queue2 MDCA -> Service Adapter

但是，我遇到了一些问题."SQS Queue1 MDCA“使用AWS特定的消息头从队列中读取消息，最终到达写入Queue2的出站适配器。这些消息头指定诸如AWS_queue名称、aws消息id等内容，这将导致消息被重新传递到queue1。

一旦我过滤掉这些头(我使用了一个简单的自定义转换器来测试这个)，出站通道适配器的属性就会按预期工作，并且QueueMessagingTemplate会将消息传递给适当的队列。

因此，我对spring和spring专家的问题是：“您认为筛选出任何已有的SQS标头的合适位置是使它们不会被任何下游SQS处理所捕获？”在我看来，您可能希望在SQSHandler中这样做，因为它们可能与任何基本的spring-aws消息传递调用都相关。

另外，通过从SQS创建消息和流中的对象到json转换器，还会创建12个消息头，这比SQS允许的多2个(导致消息传递失败)。

带有稍微修改标题以保护无辜队列的示例消息..。正如您所看到的，从“扳手_工作流-mjg”读取的消息中仍然存在aws_queue、目的等，因此当试图传递到下一个队列时，这些头文件覆盖了spring配置中的配置，并且从未传递到下一个队列。消息一直循环在SQS队列“扳手_工作流-mjg”(修复了10个以上的属性问题之后)。

GenericMessage [payload={"eventId":"event-1","eventStartDateTime":1476127827.201000000}, 
headers={aws_messageId=db9b6cc0-f133-4182-b79c-4d5d9717a3a9, ApproximateReceiveCount=1, 
SentTimestamp=1476127827803, id=0b662b72-f149-a970-5e63-64a1b28290fb, 
SenderId=AIDAJOYV7TECZCZCOK22C,
aws_receiptHandle=AQEBdaToWo9utbjBwADeSuChX/KrY3l8eoSBMZ0RMmbI8ewjJQw6tV74RwSYxWPKZBSzgJhCmfJ8AUX+
reOy2yGrmefULU7NS8nqYTdMW6BB4Ug2+mHIY+8Tze+2ws15FB5t96q3iJO8+tP5pl/xuo+CiTDv+
L1rlYkVODD0Yv1zosGKx48IhGOXdL8nJ4Im8bujcUNLJy/vEYD8Qcfsi6NHOF3Qn0A4Xw+Nva0wp86zfq,
aws_queue=wrench_workflow-mjg,
lookupDestination=wrench_workflow-mjg, 
ApproximateFirstReceiveTimestamp=1476127827886, timestamp=1476127836254}

如果有必要的话，我也许可以拿出一个例子，但我希望你能理解我没有得到什么。

Answer 1

我们可能应该在适配器中添加头部映射工具，以便像Spring中的其他技术一样，对标头进行选择性映射。

我开了一个GitHub问题。

同时，您可以在出站适配器的上游放置一个<int:header-filter.../> (或HeaderFilter转换器)，以删除不需要的报头。

还可以向出站适配器添加自定义请求处理程序建议。