ftp:outbound-channel-adapter with an unreliable FTP server

[zmoog]

Hi,

as a final step of a business process we have to publish a file on a remote FTP server. But the remote server isn't always available, so we're figuring out how to handle this situation.

Starting from this setup:

	<int:channel id="delivery-channel">
		<int:queue message-store="message-store" />
	</int:channel>

        <ftp:outbound-channel-adapter channel="delivery-channel" ... />

When the outbound-channel-adapter get an error - because the FTP server went away - the message is no longer stored in the channel and is "lost".

How can we update this solution to periodically retry the FTP operation until the FTP server is finally available?

Thank you,
Maurizio Branca

[Gary Russell]

When posting configuration/code, please use [ code ] ... [ /code ] tags (no spaces in the brackets).

You need to configure the poller to use transactions; then he'll start a transaction and it will be rolled back on a delivery failure.

[zmoog]

Hi,

this is a follow up with solution found with Gary's suggestion:

	<int:channel id="delivery-channel">
		<int:queue message-store="message-store" />
	</int:channel>
	
	<int:channel id="publish-channel" />
	
	<!-- Bridge between a PollableChannel and a SubscribableChannel -->
	<int:bridge id="delivery-bridge" input-channel="delivery-channel" output-channel="publish-channel">
		<int:poller max-messages-per-poll="1" fixed-delay="30000">
			<!-- This is the application transaction manager -->
			<int:transactional transaction-manager="transactionManager" />
		</int:poller>
	</int:bridge>

	<ftp:outbound-channel-adapter channel="publish-channel" ... />

Thank you Gary, I've completly missed the http://static.springsource.org/sprin...saction-poller section in the reference.

Maurizio

[yozh-tema]

Hi,

is there a way to easily do the same but without source queue being backed up by message store? As I understand in this case transaction rollback will not affect queue and popped-up element will not be returned to it (isn't it?). My initial guess was to use separate local folder to put files into and then read it, send files and delete from there on success - but this is conceptually the same "home-backed" persistent message store. Maybe there are some "integration-level" transactions implemented? Or any other options?