Question

我注意到（代码反编译）当在aggreator上设置超时时，整个消息组将被存储在将来（在内存中）而不是存储中。当高吞吐量发生时，这有时会导致“内存不足”异常。

有没有更好的方法来解决这个问题？

<aggregator input-channel="orderNotificationLoadBalancedExecutorChannelLATAM" output-channel="orderNotificationConverterChannelLATAM"
            message-store="orderNotificationGroupStoreLATAM"
            send-partial-result-on-expiry="true"
            ref="firstOnlyPrimaryKeyMessageAggregator"
            method="aggregate"
            correlation-strategy-expression="headers['erpKeyMap']['erpKey']"
            release-strategy-expression="#this[0].headers['tableName'].topLevel and #this[0].headers['operationType'].operationTypeDelete"
            expire-groups-upon-completion="true"
            expire-groups-upon-timeout="true"
            group-timeout="5000">
</aggregator>

Answer 1

糟糕！

看起来像个错误。我刚刚就此事提出了JIRA。

有罪的代码如下：

private void scheduleGroupToForceComplete(final MessageGroup messageGroup) {
...
    ScheduledFuture<?> scheduledFuture = this.getTaskScheduler()
        .schedule(new Runnable() {

            @Override
            public void run() {
                try {
                    forceReleaseProcessor.processMessageGroup(messageGroup);
                    }
                    catch (MessageDeliveryException e) {
                        if (logger.isDebugEnabled()) {
                            logger.debug("The MessageGroup [ " + messageGroup +
                                "] is rescheduled by the reason: " + e.getMessage());
                        }
                        scheduleGroupToForceComplete(messageGroup);
                    }
                }
            }, new Date(System.currentTimeMillis() + groupTimeout));

因此，ScheduledFuture通过内联final MessageGroup回调保存对Runnable的引用。

我认为我们只会使用groupId来修复它。

抱歉，没有任何解决方法......

Answer 2

您可以设置邮件存储。请参阅here。

对用于存储消息组的MessageGroupStore的引用   在他们的相关键下，直到他们完成。可选，由   默认为易失性内存存储。

内存中聚合器的Spring Integration超时

2 个答案: