spring 集成中 tcp-inbound-gateway 中的回复超时含义 [英] reply-timeout meaning in tcp-inbound-gateway in spring integration

问题描述

Spring 集成 tcp 网关可以设置如下:

Spring integration tcp gateway can be setup as follows:

<!-- Server side -->

<int-ip:tcp-connection-factory id="crLfServer"
    type="server"
    port="${availableServerSocket}"/>

<int-ip:tcp-inbound-gateway id="gatewayCrLf"
    connection-factory="crLfServer"
    request-channel="serverBytes2StringChannel"
    error-channel="errorChannel"
    reply-timeout="10000" />

<int:channel id="toSA" />

<int:service-activator input-channel="toSA"
    ref="echoService"
    method="test"/>

<bean id="echoService"
    class="org.springframework.integration.samples.tcpclientserver.EchoService" />
<int:object-to-string-transformer id="serverBytes2String"
    input-channel="serverBytes2StringChannel"
    output-channel="toSA"/>
<int:transformer id="errorHandler"
    input-channel="errorChannel"
    expression="Error processing payload"/>

注意回复超时设置为 10 秒.

Notice the reply-timeout which is set as 10 seconds.

是不是意味着TCP服务器会调用服务，最多可以等待10秒?如果服务在 10 秒内没有回复，TCP 服务器是否会将消息发送到 errorChannel，然后再发送客户端错误消息Error processing payload"?

Does it mean that the TCP server will call the service and can wait for a maximum of 10 seconds? If the service does not reply within 10 seconds, Does the TCP server will send the message to errorChannel which in turn sends the client error message "Error processing payload"?

当我使用需要 20 秒的服务测试 TCP 服务器时，客户端需要 20 秒才能获得响应.我没有看到错误消息.

When I tested the TCP Server with a service that takes 20 seconds, client is taking 20 seconds to get the response. I am not seeing error message.

您能否帮助理解 TCP 入站网关中的回复超时?

Can you please help in understanding the reply-timeout in TCP inbound-gateway?

谢谢

更新:感谢 Artem 帮助解决这个问题.解决此问题的最佳方法是使用以下配置:

UPDATE: Thanks for Artem to help out with this issue. Best way to solve this problem is with the following config:

<beans>
    <int-ip:tcp-connection-factory id="crLfServer" type="server" port="${availableServerSocket}"/>
    <int-ip:tcp-inbound-gateway id="gatewayCrLf" connection-factory="crLfServer" request-channel="requestChannel" error-channel="errorChannel" reply-timeout="5000" />
    <int:service-activator input-channel="requestChannel" ref="gateway" requires-reply="true"/>
    <int:gateway id="gateway" default-request-channel="timeoutChannel" default-reply-timeout="5000" />
    <int:object-to-string-transformer id="serverBytes2String" input-channel="timeoutChannel" output-channel="serviceChannel"/>
    <int:channel id="timeoutChannel">
        <int:dispatcher task-executor="executor"/>
    </int:channel>
    <bean id="executor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
        <property name="corePoolSize" value="5" />
        <property name="maxPoolSize" value="10" />
        <property name="queueCapacity" value="25" />
    </bean>
    <int:service-activator input-channel="serviceChannel" ref="echoService" method="test"/>
    <bean id="echoService" class="org.springframework.integration.samples.tcpclientserver.EchoService" />
    <int:transformer id="errorHandler" input-channel="errorChannel" expression="payload.failedMessage.payload + ' errorHandleMsg: may be timeout error'"/>
</beans>

谢谢

推荐答案

嗯，实际上我们应该像在其他类似的地方那样对该属性进行描述，例如HTTP 入站网关:

Well, actually we should on that attribute a description like we have in other similar places, e.g. HTTP Inbound Gateway:

        <xsd:attribute name="reply-timeout" type="xsd:string">
                    <xsd:annotation>
                        <xsd:documentation><![CDATA[
Used to set the receiveTimeout on the underlying MessagingTemplate instance
(org.springframework.integration.core.MessagingTemplate) for receiving messages
from the reply channel. If not specified this property will default to "1000"
(1 second).
                        ]]></xsd:documentation>
                    </xsd:annotation>
                </xsd:attribute>

该超时意味着等待下游流回复的时间.但是！如果您的流程转移到某个地方的另一个线程，那是可能的.否则一切都在调用者的线程中执行，因此等待时间不是确定性的.

That timeout means how much to wait for reply from downstream flow. But! That is possible if you flow is shifted to another thread somewhere. Otherwise everything is performed in the caller's Thread and therefore the wait time isn't deterministic.

无论如何我们在超时后返回 null 没有回复.并且体现在TcpInboundGateway:

Anyway we return null there after timeout without reply. And it is reflected in the TcpInboundGateway:

Message<?> reply = this.sendAndReceiveMessage(message);
if (reply == null) {
    if (logger.isDebugEnabled()) {
        logger.debug("null reply received for " + message + " nothing to send");
    }
    return false;
}

我们可以重新考虑 TcpInboundGateway 中的逻辑:

We can reconsider a logic in the TcpInboundGateway for :

if (reply == null && this.errorOnTimeout) {
    if (object instanceof Message) {
        error = new MessageTimeoutException((Message<?>) object, "No reply received within timeout");
    }
    else {
        error = new MessageTimeoutException("No reply received within timeout");
    }
}

但在我看来，依靠客户端的超时确实会更好.

But seems for me it really would be better on to rely on the timeout from the client.

更新

我认为我们可以通过 midflow 克服限制并满足您的要求:

I think we can overcome the limitation and meet you requirements with the midflow <gateway>:

<gateway id="gateway" default-request-channel="timeoutChannel" default-reply-timeout="10000"/>

<channel id="timeoutChannel">
    <dispatcher task-executor="executor"/>
</channel>

<service-activator input-channel="requestChannel"
                   ref="gateway"
                   requires-reply="true"/>  

因此， 调用 并等待来自那里的回复.当然，要求最后一个以 ReplyRequiredException 结束，您可以在 error-channel=" 上的错误流中将其转换为所需的 MessageTimeoutExceptionerrorChannel".

So, the <service-activator> calls <gateway> and waits for reply from there. Requiring the last one, of course, to end up with the ReplyRequiredException, which you can convert into desired MessageTimeoutException in your error flow on the error-channel="errorChannel".

timeoutChannel 是一个执行器，使我们的 default-reply-timeout="10000" 非常有用，因为我们立即将网关上的消息转移到单独的线程中，并且从那里向右移动到在 CountDonwLatch 上包裹超时的回复等待过程.

The timeoutChannel is an executor one, making our default-reply-timeout="10000" very useful because we shift a message on the gateway into separate thread immediately and move right from there into reply waiting process wrapped with that timeout on the CountDonwLatch.

希望这很清楚.

这篇关于spring 集成中 tcp-inbound-gateway 中的回复超时含义的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！