聚合器在amqp确认后不聚合分割的消息

时间:2016-09-21 02:34:22

标签: spring-integration

  1. 我有一个获取ID列表的数据库查询
  2. 我使用拆分器将它们拆分为带有任务执行器的通道
  3. 然后我为每个Id发布amqp消息
  4. 要求:在进行下一步之前,我需要确认所有消息都已发布。

    所以我在消息ack频道

    之后添加了一个聚合器

    问题:对于较少数量的ID(可能少于3000条记录),解决方案按预期工作。但是对于大量的ID,聚合器会等待

    已发布消息的数量始终正确。所以我在下面的代码中添加了一个db更新,以便在确认通道之后有一个计数器,并且计数小于更大ID列表的ID数

    <!-- service activator query database table and return list of IDs of type: Message<List<Map<String, Object>>> -->
    
    <int:splitter id= "accountsSplitter" input-channel="listOfAccountsChannel" output-channel="accountChannel" />   
    <int:channel id="accountChannel">
        <int:dispatcher task-executor="splitterTaskExecutor"/>
    </int:channel>
    
    <int:chain id="publishMessageChain" input-channel="accountChannel">
        <int:transformer ref="accountIdTransformer"/>
    
        <int-amqp:outbound-channel-adapter 
            amqp-template="amqpTemplateCore" 
            confirm-ack-channel="messageAckChannel"
            confirm-nack-channel="messageAckChannel"
            return-channel="messageAckChannel"
            confirm-correlation-expression="#root"
            exchange-name="ABC"
            routing-key="#{abcRoutingKey}">
        </int-amqp:outbound-channel-adapter>
    </int:chain>
    
    <int:chain id="confirmMessageChain" input-channel="messageAckChannel" output-channel="successMessageChannel">
        <int:header-enricher id="replyChannelHeaderEnricher">
            <int:reply-channel expression="payload.headers['replyChannel']" />
        </int:header-enricher>
    
        <int:transformer id="payloadTransformer" expression="payload" />
    </int:chain>
    
    <int:aggregator id="messagesConfirmedAggregator" input-channel="successMessageChannel" output-channel="aggregateChannel"/>
    
      <task:executor id="splitterTaskExecutor" pool-size="10-40" queue-capacity="1000" rejection-policy="CALLER_RUNS" />
    

1 个答案:

答案 0 :(得分:0)

  

已发布消息的数量始终正确。

是什么让你这么想?

我们添加confirm-nack-channel以查看“否定发布商确认”!

也许return-channel也可以查看“如果发送了”返回的消息“。

<强>更新

经过一些局部测试后,我找到了原因。

您使用并发线程池作为40(最大)发送。默认情况下,CachingConnectionFactory使用25。超过高速缓存大小时,会创建一个新的易失性Channel,这可能只需要等待5秒钟确认。

您应该将CachingConnectionFactory.setChannelCacheSize()增加到相当大的值,以满足您的并发和确认要求。