Retry mechanism for SFTP outbound-channel-adapter

[krzychu]

Hi All,

Any ideas on how to implement simple retry mechanism for SFTP adapter? From time to time I'm getting the following exception:

Caused by: org.springframework.core.NestedIOException: failed to write file; nested exception is 4: java.net.SocketException: Broken pipe
	at org.springframework.integration.sftp.session.SftpSession.write(SftpSession.java:106)

and since it is a network issue I would like to try to send it one more time. Don't want to throw an exception and terminate processing. Is there a common strategy for such cases?

Would it be possible to add max-retries parameter to sftp:outbound-channel-adapter that allows retry in case of an exception during the file transmission?

Your help is really appreciated.

Regards,
Krzysztof

[krzychu]

Hi there,

Any ideas regarding retry mechanism topic?

Regards,
Krzysztof

[oleg.zhurakousky]

Krzysztof
Sorry for the delay, was traveling

Adding max-retrieves could work, but then the question is how soon the next retrieve should be attempted? Right away? With delay? etc.

What you can do now is define error-channel and add subscriber to it which could itself be a delayer http://static.springsource.org/sprin...ingle/#delayer which will send the 'failed message' back to the request channel of sftp adapter after a predefined delay. Can you try that?

[Mark Fisher]

We have an open issue that will address this in 2.1: https://jira.springsource.org/browse/INT-343

The use of RetryTemplate will enable configuration of delay intervals, max # of attempts, etc. Please feel free to add your thoughts in the comments in JIRA.

In the meantime, something like the delayer, as Oleg mentioned, might provide a sufficient workaround.

-Mark

[krzychu]

We have an open issue that will address this in 2.1: https://jira.springsource.org/browse/INT-343

The use of RetryTemplate will enable configuration of delay intervals, max # of attempts, etc. Please feel free to add your thoughts in the comments in JIRA.

In the meantime, something like the delayer, as Oleg mentioned, might provide a sufficient workaround.

-Mark

Hi Mark,

Thanks for an update regarding RetryTemplate, I think it would be a nice feature.

Will try to implement solution suggested by Oleg.

Regards,
Krzysztof

[krzychu]

What you can do now is define error-channel and add subscriber to it which could itself be a delayer http://static.springsource.org/sprin...ingle/#delayer which will send the 'failed message' back to the request channel of sftp adapter after a predefined delay. Can you try that?

Is there any nice way to get the original exception (root cause) that was sent to error channel and based on its type send an original message payload (failed message) to delayer which will sent it back to request channel of SFTP adapter? Could any router implementation do this?

I know in Java code I can do the following:

final Exception exception = ExceptionUtils.getRootCauseMessage((Exception) message.getPayload());
final Object originalPayload = ((MessagingException) message.getPayload()).getFailedMessage().getPayload();

However it would be nice to do this on the XML level without coding

Regards,
Krzysztof

[oleg.zhurakousky]

Yes, take a look at the ErrorMessageExceptionTypeRouter. Is that what you are looking for?
We don't have a namespace support for it but its being brought a few times recently so we'll probably end up wrapping it behind the namespace similar to PayloadTypeRouter.

[krzychu]

Thanks, ErrorMessageExceptionTypeRouter is the one

When creating retry policy based on delayer I added one more component in my retry flow which is transformer. It had to retrieve the original payload out of the MessagingException and then pass it to delayer. The whole process contains the following components:

channel -> ErrorMessageExceptionTypeRouter -> channel -> MessagingExceptionToOriginalMessageTransformer -> channel -> delayer -> sftp adapter

And it works Thanks Oleg!

Regards,
Krzysztof