英文:
Is Spring's RemoteFileTemplate.get method synchronous?
问题
Is Spring's RemoteFileTemplate.get
method synchronous?
When testing, it appears to be synchronous. When checking the implementation, it seems to be synchronous, too. And I do understand that there is a reason to use a synchronous callback instead of just returning the InputStream
.
But why does the documentation say nothing about the callback being synchronous/asynchronous? Can I assume that the callback will stay synchronous in future releases?
The reason behind this is that I want to make sure the call blocks until the callback is executed. In example, I expect the following code leads to the following output:
Code:
remoteFileTemplate.get(filePath, stream -> System.out.println("1"));
System.out.println(2);
Output:
1
2
And I never want the output to be:
2
1
英文:
Is Spring's RemoteFileTemplate.get method synchronous?
When testing, it appears to be synchronous. When checking the implementation, it seems to be synchronous, too. And I do understand that there is a reason to use a synchronous callback instead of just returning the InputStream
.
But why does the documentation say nothing about the callback being synchronous/asynchronous? Can I assume that the callback will stay synchronous in future releases?
The reason behind this is that I want to make sure the call blocks until the callback is executed. In example, I expect the following code leads to the following output:
Code:
remoteFileTemplate.get(filePath, stream -> System.out.println("1"));
System.out.println(2);
Output:
1
2
And I never want the output to be:
2
1
答案1
得分: 0
以下是翻译好的部分:
"The logic there is like this:
try (InputStream inputStream = session.readRaw(remotePath)) {
callback.doWithInputStream(inputStream);
return session.finalizeRaw();
}
to close InputStream
and release remote resources. The callback
here is just an end-user hook to accept that stream of remote file data. There is no any multi-threaded issues since the session is not shared.
Of course we can't guarantee that provided InputStreamCallback
impl is thread-safe. Although when you hand off that inputStream
to another thread in that callback, it is going to be closed and session released. Therefore, your other thread is going to suffer from an outdated InputStream
reference.
I'm not sure what is your concern about the callback since this one is not what the framework does. You provide its impl when you call this get(String remotePath, InputStreamCallback callback)
."
英文:
The logic there is like this:
try (InputStream inputStream = session.readRaw(remotePath)) {
callback.doWithInputStream(inputStream);
return session.finalizeRaw();
}
to close InputStream
and release remote resources. The callback
here is just an end-user hook to accept that stream of remote file data. There is no any multi-threaded issues since the session is not shared.
Of course we can't guarantee that provided InputStreamCallback
impl is thread-safe. Although when you hand of that inputStream
to other thread in that callback, it is going to be closed and session released. Therefore your other thread is going to suffer from out-dated InputStream
reference.
I'm not sure what is your concern about callback since this one is not what the framework does. You provide its impl when you call this get(String remotePath, InputStreamCallback callback)
.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论