FtpSession readRaw + finalizeRaw blocking until 421 timeout

[rcwinder]

In what version(s) of Spring Integration are you seeing this issue?

6.1.2 - 6.1.4, and probably older too

Describe the bug

I am using the spring integration ftp package to connect to an ftp server to try and download some files.
Before downloading the actual files I created a check to see if the file is actually downloadable in the following way:

1. Open inputStream using FtpSession readRaw(String source) method.
2. Check if inputStream is not null and if no Exception is thrown
3. Close inputStream
4. call FtpSession finalizeRaw() to complete the transaction

However, when I do this for a file to which my ftpuser does not have access by OS permissions, the readRaw method will throw an Exception because of a 550 FTP error. This makes sense.
Then when I call finalizeRaw to allow to check or download another file afterwards, the readingRaw atomic boolean is correctly set to false. However when the finalizeRaw method calls this.client.completePendingCommand() it hangs until it receives a 421 (timeout) error.

Therefore my assumption that it seems the completePendingCommand should not be called when readRaw throws an Exception.
However the atomic boolean readingRaw is still set to true, so I am not able to skip the finalizeRaw call since this would not allow me to do another readRaw call.

To Reproduce

See above, when using readraw + finalizeraw on a path to a file to which the ftp user does not have os permissions

Expected behavior

Either of 3 possibilities:

1. The readRaw method should put the atomicBoolean readingRaw to false because the process is no longer active
2. There should be a (different) way to call finalize when readRaw threw an IOException
3. The finalizeRaw method should not block upon completePendingCommand

[artembilan]

I see. So, we don't react properly to the exception during input stream opening.
I thought about using if (FTPReply.isPositiveIntermediate(this.client.getReplyCode())) { in the finalizeRaw(), but looks like my client returns when we do readRaw():

150 File status okay; about to open data connection.

which really doesn't fit into:

    public static boolean isPositiveIntermediate(final int reply) {
        return reply >= 300 && reply < 400;
    }

it is this one:

    public static boolean isPositivePreliminary(final int reply) {
        return reply >= 100 && reply < 200;
    }

But that one indicates that we cannot call any new command until full response.
All of that I took from the FTPClient.completePendingCommand() Javadocs.

So, looks like we have to go a route where we reset readingRaw to false on exception in the readRaw and then make finalizeRaw() to shortcircuit on false instead of throwing exception.

Would you mind to share your experience what is reply code in your case when you do just readRaw()? And yes, it is positive.
Well, it might be also great to know what it is in case of exception.
Then we indeed might go with the isPositivePreliminary() check in the finilizeRaw().
The pattern really should be like this anyway:

try (InputStream inputStream = session.readRaw("myFile.txt")) {
			...
}
finally {
	session.finalizeRaw();
}

[rcwinder]

Would you mind to share your experience what is reply code in your case when you do just readRaw()? And yes, it is positive.

In the case I described, where you try to access a file on the FTP server to which the FTP user does not have access. (in extreme case because of chmod 000 permissions). I receive a 550 ftp reply code. So its not in the positive ranges.

So, looks like we have to go a route where we reset readingRaw to false on exception in the readRaw

I think this would indeed solve the issue of non-positive replies. It would make sure that when you get a non-positive reply, you reset the readingraw boolean to false which then allows you to still call finalizeRaw(), because it will instantly notify that there is no readRaw in progress, instead of the blocking issue that I have now

Your code fragment below is indeed the format that I originally intended to use, but unfortunately not possible at the moment in case of the non-positive reply on readRaw.

try (InputStream inputStream = session.readRaw("myFile.txt")) {
			...
}
finally {
	session.finalizeRaw();
}

The second attempt I did was to move the finalizeRaw out of the finally, and only do it if the readRaw has managed to create an inputstream:

try (InputStream inputStream = session.readRaw("myFile.txt")) {
	if(inputStream != null) {
                .. do things
                inputStream.close();
                session.finalizeRaw();
        }
}

However this runs into the issue that the readingRaw flag is not set to false after a non-positive reply on readRaw, we do not call finalizeRaw, and therefore cannot start a new readRaw within the same FtpSession.

So my current workaround is to use the session.getClientInstance() and use the readRaw and completepending on the client directly

[rcwinder]

Whoops did not mean to press close with comment