Spring Integration Aggregator 或 Router 是正确的模式？答案

【问题标题】：Spring Integration Aggregator or Router the right pattern?Spring Integration Aggregator 或 Router 是正确的模式？
【发布时间】：2017-01-18 19:29:05
【问题描述】：

我有一个场景，乍一看似乎非常适合使用 Spring Integration Aggregator：

目前产生了大量的 PDF 报告。这些通过 Printrequests 打印到 JMS 队列。打印服务器接受带有打印请求的客户端套接字。

为了在负载方面达到一定的“公平性”，我们希望对同一台打印机的打印请求进行聚合。然后将聚合请求发送到打印服务器。我们有聚合请求的完整性标准，基本上是为“批次”生成的 pdf 数量，并且每个“批次”请求的 PDF 报告都有一个唯一键。然后，聚合的请求将通过服务激活器通过相同的客户端套接字“发送”到打印服务器。所以基本上我们采用的是 Spring Integration Documentation 中描述的方法。

问题：报告只会在“批处理”的最后一个 pdf 报告生成时才开始打印，这似乎造成了相当大的瓶颈。

理想情况下，我们可以在 MessageGroup 的第一个 Message 到达时立即开始打印，并有效地聚合打印请求的结果。

我一直在考虑使用自定义 MessageStore 来实现这一点，其中

public void add(Message<?> messageToAdd)

方法实现了额外的逻辑调用打印机服务器并实际聚合服务器的响应。类似于“活动”的 MessageStore。

但是自定义 MessageStore 的 add 方法可能是一个“大”瓶颈...阻止每个添加到“活动”MessageStore...而且似乎是错误的比喻：存储与处理某些东西。

聚合器是满足这些要求的正确方法吗？

或者我应该更多地使用Dynamic Ftp Spring Integration Example中描述的动态路由器通道

每个“批次”打印请求都有一个子/父应用程序上下文？那里孩子的应用程序上下文的生命周期对我来说不是很清楚。

理想情况下，我将能够使用 JMX 管理所有上下文 - 孩子和父母，如 the Monitoring Example of Spring Integration 中所述

【问题讨论】：

标签： spring spring-integration

【解决方案1】：

看起来你有一些Buttered cat paradox。

您希望通过聚合请求最小化网络负载，但同时您希望将每个项目从聚合器发送到打印。

你应该自己决定什么是你真正的目标。

也许您只需要一个router，它的逻辑将基于一些key 来委派特定套接字发送到打印服务器的正确通道？

否则很抱歉：您的问题不清楚...

【讨论】：

我明白你的意思 ;-) ....只是使用 Spring Integration 寻找正确的模式和抽象，顺便说一句很棒！
我不是想最大程度地减少网络负载，而是对请求进行分组，将它们发送到一个常设的连接上，并且最重要的是有一个确定的标准来确定何时再次关闭连接。我相信聚合器将是一个完美的选择，但是是的，我等到聚合完成。正如您建议的那样，我现在正在遵循的路由器方法不是这种情况，但是在这里我看不到如何根据消息输入确定性地关闭每个套接字的通道套接字的子上下文。？跨度>
这听起来像是一个不同的故事......我完全不清楚为什么每个套接字都必须有子上下文。您有严格数量的打印服务器，因此只需为每个打印服务器配置<int-tcp:connection-factrory mode="client"> 和相应的通道适配器，以通过客户端套接字进行通信。您可以通过一些外部事件或空闲间隔关闭并重新连接。
对不起，是的，我完全不清楚。问题领域是大批量的批量打印。我们实际上只有一台打印服务器。但是希望在打印机（批次）的基础上建立一个常设连接，并通过同一个常设连接发送对同一台打印机的请求。最终，打印机的“批处理”完成了。
所以，忘记聚合器并手动执行“批处理”，但仍然使用路由器获取正确的套接字来发送项目