Allow AbstractRemoteFileStreamingMessageSource#remoteFileToMessage Retry #8562
Labels
Milestone
Comments
jayChrono
added
status: waiting-for-triage
|
Can we see, please, a stack trace for the error to determine what is going on and understand why the next poll does not take that file into account any more. You also can look into a I don't think it is a |
artembilan
added
status: waiting-for-reporter
|
From the source code, the smbFiles to process is called once and stored in the toBeReceived queue (listFiles() function). The poll() function takes from that queue and only does a 'real' poll of files to receive when toBeReceived is empty. So eventually, the skipped file will get processed again only after the current queue is emptied. I'll look into 2023-02-25T21:41:06.569-05:00 ERROR 28924 --- [scheduling-1] o.s.integration.smb.session.SmbFileInfo : Unable to determine if this SmbFile represents a directory |
|
Just tried |
|
OK. Let's see if I understood this correctly. Apparently we have to treat this If that fits to your expectation, we simply can go ahead with the fix I've just suggested. |
|
Your understanding is correct. Clearing |
|
But isn't that what retry advice on a source polling channel adapter would do for us in the end? I see, though, the problem in your stack trace around |
artembilan
added
status: discussion-required
artembilan
added
in: file
backport 5.5.x
and removed
status: discussion-required
artembilan
added a commit
to artembilan/spring-integration
that referenced
this issue
Feb 28, 2023
Fixes spring-projects#8562 The `AbstractRemoteFileStreamingMessageSource.doReceive()` takes files first from a `toBeReceived` queue. When `AbstractRemoteFileStreamingMessageSource.remoteFileToMessage()` fails to fetch the file content because of interim connection issue, we reset this file from a filter and rethrow an exception. The next `receive()` call will just go ahead to the next entry in the `toBeReceived` queue, but the file we have just failed for will be retried only on the next list call to the remove directory. This essentially breaks a possible in-order target application logic. * Introduce `AbstractRemoteFileStreamingMessageSource.strictOrder` option to clear the `toBeReceived` queue when we fail in the `remoteFileToMessage()`, so the next `receive()` call would re-fetch files from remote dir, because the filter has been reset for those files. * Fix `AbstractFileInfo.toString()` to not perform remote calls when we just log this file. For example, we reset the file for connection failure and log the message about it, but it fails again because we request `size` of the file which may require a remote connection. **Cherry-pick to `6.0.x` & `5.5.x`**
garyrussell
pushed a commit
that referenced
this issue
Feb 28, 2023
* GH-8562: Fix streaming source for remote calls Fixes #8562 The `AbstractRemoteFileStreamingMessageSource.doReceive()` takes files first from a `toBeReceived` queue. When `AbstractRemoteFileStreamingMessageSource.remoteFileToMessage()` fails to fetch the file content because of interim connection issue, we reset this file from a filter and rethrow an exception. The next `receive()` call will just go ahead to the next entry in the `toBeReceived` queue, but the file we have just failed for will be retried only on the next list call to the remove directory. This essentially breaks a possible in-order target application logic. * Introduce `AbstractRemoteFileStreamingMessageSource.strictOrder` option to clear the `toBeReceived` queue when we fail in the `remoteFileToMessage()`, so the next `receive()` call would re-fetch files from remote dir, because the filter has been reset for those files. * Fix `AbstractFileInfo.toString()` to not perform remote calls when we just log this file. For example, we reset the file for connection failure and log the message about it, but it fails again because we request `size` of the file which may require a remote connection. **Cherry-pick to `6.0.x` & `5.5.x`** * * Revert `AbstractFileInfo` changes * Override `toString()` in `SmbFileInfo` instead - exactly the place where connection is used to obtain file attributes like `size` or `lastModified`
garyrussell
pushed a commit
that referenced
this issue
Feb 28, 2023
* GH-8562: Fix streaming source for remote calls Fixes #8562 The `AbstractRemoteFileStreamingMessageSource.doReceive()` takes files first from a `toBeReceived` queue. When `AbstractRemoteFileStreamingMessageSource.remoteFileToMessage()` fails to fetch the file content because of interim connection issue, we reset this file from a filter and rethrow an exception. The next `receive()` call will just go ahead to the next entry in the `toBeReceived` queue, but the file we have just failed for will be retried only on the next list call to the remove directory. This essentially breaks a possible in-order target application logic. * Introduce `AbstractRemoteFileStreamingMessageSource.strictOrder` option to clear the `toBeReceived` queue when we fail in the `remoteFileToMessage()`, so the next `receive()` call would re-fetch files from remote dir, because the filter has been reset for those files. * Fix `AbstractFileInfo.toString()` to not perform remote calls when we just log this file. For example, we reset the file for connection failure and log the message about it, but it fails again because we request `size` of the file which may require a remote connection. **Cherry-pick to `6.0.x` & `5.5.x`** * * Revert `AbstractFileInfo` changes * Override `toString()` in `SmbFileInfo` instead - exactly the place where connection is used to obtain file attributes like `size` or `lastModified`
garyrussell
pushed a commit
that referenced
this issue
Feb 28, 2023
* GH-8562: Fix streaming source for remote calls Fixes #8562 The `AbstractRemoteFileStreamingMessageSource.doReceive()` takes files first from a `toBeReceived` queue. When `AbstractRemoteFileStreamingMessageSource.remoteFileToMessage()` fails to fetch the file content because of interim connection issue, we reset this file from a filter and rethrow an exception. The next `receive()` call will just go ahead to the next entry in the `toBeReceived` queue, but the file we have just failed for will be retried only on the next list call to the remove directory. This essentially breaks a possible in-order target application logic. * Introduce `AbstractRemoteFileStreamingMessageSource.strictOrder` option to clear the `toBeReceived` queue when we fail in the `remoteFileToMessage()`, so the next `receive()` call would re-fetch files from remote dir, because the filter has been reset for those files. * Fix `AbstractFileInfo.toString()` to not perform remote calls when we just log this file. For example, we reset the file for connection failure and log the message about it, but it fails again because we request `size` of the file which may require a remote connection. **Cherry-pick to `6.0.x` & `5.5.x`** * * Revert `AbstractFileInfo` changes * Override `toString()` in `SmbFileInfo` instead - exactly the place where connection is used to obtain file attributes like `size` or `lastModified`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expected Behavior
When using
SmbStreamingMessageSource, in the doReceive() function, should be able to retry remoteFileToMessage() call with aRetryTemplatethat can be set viaSmbStreamingInboundChannelAdapterSpec.Current Behavior
AbstractRemoteFileStreamingMessageSource#remoteFileToMessageis only called once. Network errors can cause the call to fail when resolvingSmbFileInfoand drop the file from being processed.Context
I wrote an integration flow that streams/processes zip files from a shared folder in a defined order. Occasionally, the process hits a network error when resolving the
SmbFileInfofor the remote file and gets dropped from processing. Handling the messageException in the errorChannel will cause the zip files to be processed out of order.Could not simply extend
SmbStreamingMessageSourceand add aRetryTemplatebecause the class properties used by the doReceive() function are private. I had to copy/pasteAbstractRemoteFileStreamingMessageSourceinto my project, add aRetryTemplateand modify the call to remoteFileToMessage (line 214).return remoteFileToMessage(file);
->
var processFile = file;
return retry.execute(ctx -> {
if (ctx.getRetryCount() > 0)
logger.info(ctx::toString);
return remoteFileToMessage(processFile);
});
The text was updated successfully, but these errors were encountered: