reply-channel for tcp-inbound-gateway

[johnjianfang]

Yes, you are right. I added a CRLF because I didn't know the client will automatically add a CRLF to the message. After strip off the CRLF, no error any more.

Thanks again for your help.

John

[Gary Russell]

Great!

I would still recommend you protect yourself, though, by filtering out the replyChannel with a <header-filter/> on the aggregatedProductChannel leg, just in case.

[johnjianfang]

Sorry for bothering you again. Here is the latest connection factory

    <beans:bean id="tcpSerializer"
          class="org.springframework.integration.ip.tcp.serializer.ByteArrayLengthHeaderSerializer">
            <beans:property name="maxMessageSize" value="20480"/>
    </beans:bean>

    <beans:bean id="tcpDeserializer"
          class="org.springframework.integration.ip.tcp.serializer.ByteArrayLengthHeaderSerializer">
        <beans:property name="maxMessageSize" value="20480"/>
    </beans:bean>

	<ip:tcp-connection-factory id="client"
        serializer="tcpSerializer"
        deserializer="tcpDeserializer"
		type="client"
		host="localhost"
		port="8888"
        using-nio="true"
        single-use="true"
		so-timeout="10000"/>

	<ip:tcp-connection-factory id="crLfServer"
        serializer="tcpSerializer"
        deserializer="tcpDeserializer"
		type="server"
        pool-size="40"
        using-nio="true"
		port="8888"/>

But I keep seeing the following error message.

2011-02-09 16:34:19,863 (pool-1-thread-12) [TcpNioConnection.readPacket]
ERROR - Exception on Read localhost.localdomain:58631:404837374 Connection reset by peer

Any idea to remove this kind of errors?

Thanks,

John

[johnjianfang]

Great!

I would still recommend you protect yourself, though, by filtering out the replyChannel with a <header-filter/> on the aggregatedProductChannel leg, just in case.

Thanks, I renamed the aggregatedProductChannel to productPublishChannel and did what you suggested as follows.

    <publish-subscribe-channel id="productPublishChannel" task-executor="executor" ignore-failures="true"/>

    <task:executor id="executor" pool-size="40"/>

    <poller id="poller" default="true" max-messages-per-poll="1" fixed-rate="1000" task-executor="executor"/>

    <service-activator input-channel="productPublishChannel" output-channel="replyChannel"
		ref="productValidator" method="validate"/>

    <chain input-channel="productPublishChannel" output-channel="productsChannel">
        <header-filter header-names="replyChannel"/>
        <service-activator ref="productSplitter"  method="split"/>
    </chain>

The productValidator should return either "successful" or "failed" back to the client. But I still saw the client received the product json message instead of the "successful" or "failed" message. Anything I did wrong here?

Thanks,

John

[Gary Russell]

Any idea to remove this kind of errors?

Try upgrading to Spring-Integration 2.0.2.RELEASE (released yesterday) or try setting so-linger to, say, 5000. (See https://jira.springsource.org/browse/INT-1707).

[johnjianfang]

Seems the header-filter does not take effect, see the log here.

DEBUG - postSend (sent=true) on channel 'productsChannel', message: [Payload=[Product{ean='20001191', type='BOOKS'}, Product{ean='20001192', type='BOOKS'}, Product{ean='20001193', type='BOOKS'}, Product{ean='20001194', type='BOOKS'}, Product{ean='20001195', type='BOOKS'}, Product{ean='20001196', type='BOOKS'}, Product{ean='20001197', type='BOOKS'}, Product{ean='20001198', type='BOOKS'}, Product{ean='20001199', type='BOOKS'}, Product{ean='20001200', type='BOOKS'}, Product{ean='20001201', type='BOOKS'}, Product{ean='20001202', type='BOOKS'}, Product{ean='20001203', type='BOOKS'}, Product{ean='20001204', type='BOOKS'}, Product{ean='20001205', type='BOOKS'}, Product{ean='20001206', type='BOOKS'}, Product{ean='20001207', type='BOOKS'}, Product{ean='20001208', type='BOOKS'}, Product{ean='20001209', type='BOOKS'}, Product{ean='20001210', type='BOOKS'}, Product{ean='20001211', type='BOOKS'}, Product{ean='20001212', type='BOOKS'}, Product{ean='20001213', type='BOOKS'}, Product{ean='20001214', type='BOOKS'}, Product{ean='20001215', type='BOOKS'}, Product{ean='20001216', type='BOOKS'}, Product{ean='20001217', type='BOOKS'}, Product{ean='20001218', type='BOOKS'}, Product{ean='20001219', type='BOOKS'}, Product{ean='20001220', type='BOOKS'}, Product{ean='20001221', type='BOOKS'}, Product{ean='20001222', type='BOOKS'}, Product{ean='20001223', type='BOOKS'}, Product{ean='20001224', type='BOOKS'}, Product{ean='20001225', type='BOOKS'}, Product{ean='20001226', type='BOOKS'}, Product{ean='20001227', type='BOOKS'}, Product{ean='20001228', type='BOOKS'}, Product{ean='20001229', type='BOOKS'}, Product{ean='20001230', type='BOOKS'}, Product{ean='20001231', type='BOOKS'}, Product{ean='20001232', type='BOOKS'}, Product{ean='20001233', type='BOOKS'}, Product{ean='20001234', type='BOOKS'}, Product{ean='20001235', type='BOOKS'}, Product{ean='20001236', type='BOOKS'}, Product{ean='20001237', type='BOOKS'}, Product{ean='20001238', type='BOOKS'}, Product{ean='20001239', type='BOOKS'}, Product{ean='20001240', type='BOOKS'}, Product{ean='20001241', type='BOOKS'}]][Headers={timestamp=1297289282817, id=7c11b459-a421-4945-b6b0-4cc28df0c5e8, errorChannel=org.springframework.integration.core. MessagingTemplate$TemporaryReplyChannel@76d78df0, ip_address=127.0.0.1, replyChannel=org.springframework.integration.core. MessagingTemplate$TemporaryReplyChannel@76d78df0, ip_connection_seq=1, ip_hostname=localhost.localdomain, ip_tcp_remote_port=44213, ip_connection_id=localhost.localdomain:44213:19527 03843}]

The replyChannel is still there.

[johnjianfang]

2.0.2 is out? Great. Will try that. Hope it is in the Maven repo now.

Try upgrading to Spring-Integration 2.0.2.RELEASE (released yesterday) or try setting so-linger to, say, 5000. (See https://jira.springsource.org/browse/INT-1707).

[Gary Russell]

The replyChannel is still there.

Hmmm... can't explain that (and I can't reproduce it either with a simpler test case). Can you share more of the log?

[johnjianfang]

Attached please find the log file and the xml configurations for the server and the client.

The client now receives the "successful" message, but the Channel closed error is still there even I upgraded to SI 2.0.2 release.

Thanks,

John

[Gary Russell]

Thanks

2011-02-09 18:14:51,905 (pool-1-thread-4) [TcpNioConnection.readPacket]
ERROR - Exception on Read localhost.localdomain:37779:343935649 Channel closed

At least we are getting a close now, instead of a reset (which is what the 2.0.2 fix was about) but, given your configuration, I wouldn't expect to see a thread in readPacket() at this point (when the client closed the socket), we should have no pending data in the socket so we shouldn't have received any indication that we needed to read more data. Threads are only dispatched into readPacket() when the selector has indicated there is data to read.

2011-02-09 18:14:51,824 (pool-1-thread-2) [TcpNioConnection.doRead]
DEBUG - Read 135 into raw buffer
2011-02-09 18:14:51,825 (pool-1-thread-3) [ByteArrayLengthHeaderSerializer.read]
DEBUG - Read 4 bytes, buffer is now at 4 of 4
2011-02-09 18:14:51,825 (pool-1-thread-3) [ByteArrayLengthHeaderSerializer.deserialize]
DEBUG - Message length is 131
2011-02-09 18:14:51,825 (pool-1-thread-3) [ByteArrayLengthHeaderSerializer.read]
DEBUG - Read 131 bytes, buffer is now at 131 of 131

What operating system are you running on?

Do you see a similar ERROR when using-nio="false"?

Can you provide a TRACE level log from the server with using-nio="true"? (Please also send the corresponding client-side log).

What happens if you set single-use="true" (with using-nio="true") on the server connection factory?

Thanks!