[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] sendRetrieveRequest blocking
|
Hi Henrich,
Henrich Kraemer wrote:
When one retrieves a file using
IRetrieveFileTransferContainerAdapter#sendRetrieveRequest() the
initial request is send in the same thread which may cause blocking.
For example as manifested in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=248555.
The Java Doc talk about the fact that events being delivered
asynchronously. This led me to believe that this call would never
block although the JavaDoc does not strictly specify this.
Should it never block, meaning that the initial IO will be done in
another thread?
That's an open question (should it never block). I actually think it's
OK for it to block, as long as the block is 'short-lived' (e.g. < 30
seconds or some perhaps smaller default). You are right that the fact
that it can block for a provider determined time should certainly be
documented.
Is this a provider implementation issue?
Yes, because various providers expose various ways of connecting and
making the initial request. Although most providers (that I've seen so
far anyway) have a blocking connect call at some point. This is one
area where the HttpClient 4 (HttpCore stuff based upon java new io [non
blocking]) may be helpful.
I think it's OK to have the API specify that it blocks for a bounded
time. Thoughts?
Scott
