当前位置: 首页 > 知识库问答 >
问题:

Spring集成-并发服务激活器

富波光
2023-03-14

我有一个队列通道和一个带有轮询器的服务激活器,轮询器从该队列中读取数据。我希望配置为“我希望50个线程轮询该队列,每次轮询并返回消息时,在此线程上调用服务激活器指向的服务。”

该服务没有异步注释,但无状态,可以以并发方式安全运行。

下面的方法能做到吗?有没有其他首选的方法来实现这一点?

<int:channel id="titles">
    <int:queue/>
</int:channel>

<int:service-activator output-channel="resolvedIds" ref="searchService" method="searchOnTitle" input-channel="titles">
    <int:poller fixed-delay="100" time-unit="MILLISECONDS" task-executor="taskExecutor"></int:poller>
</int:service-activator>

<task:executor id="taskExecutor" pool-size="50" keep-alive="120" />

共有1个答案

饶铭
2023-03-14

是的,我想这是你想要的。引入QueueChannel后,交互将变为异步-不需要@async。如果没有明确设置轮询器,它将使用默认轮询器。

您所概述的是实现它的最佳方法。您还可以考虑对队列大小进行限制——这样,如果在跟上生产者方面出现延迟,就不会导致内存溢出问题。如果指定了大小,那么通道上的发送调用将阻塞——充当节流阀。

您拥有的配置将按预期工作。唯一的问题是,一旦开始为每个endpoint创建执行器和轮询器,就很难找出整个应用程序的最佳配置。对一些特定步骤进行此类优化是可以的,但不是对所有endpoint进行优化(您的问题中没有任何内容表明您正在进行优化,只是想我无论如何都会提出优化。

 类似资料:
  • 我有一个非常简单的集成流程: 服务激活器调用的方法尝试将消息中的数据与数据库中的某些数据相匹配。如果是,则返回匹配的数据。如果没有,它将返回。 如果我没有设置必需回复为真,那么回复似乎会从集成流中消失,导致服务接口永远不会返回,从而导致应用程序挂起。如果我设置了必需回复为真,我至少会得到一个异常,但是应用程序仍然挂起,因为网关的服务接口永远不会返回: spring集成参考资料中似乎没有记录这种行为

  • 我在一个简单的POJO中配置了一个服务激活器,我想将其转换为Java DSL。 现在,我的Java DSL如下所示, 有一个带有服务激活器的POJO, 在XML中,相应的配置如下所示, 如何在Java DSL中调用ServiceActivator方法?我正在考虑使用,但参数应该是什么 在使用Java DSL时,是否有空通道的概念?如果是,我们如何指定

  • 我有一个Web服务,每个版本将有多个版本和多个类。我想在启动时动态创建服务激活器,这样我就可以减少配置量,从而更容易维护。开发人员可以放入一个新类,SI会自动拾取它。 我编码了一个Application Listener: 稍后在路由器中,我有以下代码: 但当路由器尝试路由时,我会出现以下错误: 我该怎么做?我需要动态创建服务激活器,并在以后将消息路由到这些激活器。 没有办法在ServiceAct

  • 我试图从Spring集成示例中转换“Hello World示例”(https://github.com/spring-projects/spring-integration-samples/tree/master/basic/helloworld)从XML到Java配置(使用注释也是如此)。 配置类如下所示: 为了测试它,我使用示例项目提供的: 我在控制台中看到“Message payload:t

  • 带有服务工作者的网站,托管https://121eddie.github.io/并在Chrome 66.0中运行。3359.181 /索引。html在每次加载时正确跟踪以下注册 }); 第一次运行时,/serviceWorker。js执行“激活”事件,正确获取缓存名称并缓存文件 在第二次运行时,不会触发“激活”(没有日志跟踪,没有获取)。 在第三次运行中,甚至不再触发“抓取”。这意味着脱机请求不被

  • 是否有一种方法可以丢弃使用Spring Integration DSL方法定义的Spring Integration Service Activator中的消息? 更具体地说,假设下面的IntegrationFlow定义... 我发现,从返回似乎可以有效地结束流,但我不确定这是否是最优雅/正确的解决方案。如果这是推荐的解决方案,那很好。