| Re: [ecf-dev] sendRetrieveRequest blocking |
Hi Scott,
See comments below:
> 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.
Currently the file transfer job for providers using
AbstractRetrieveFileTransfer is scheduled when the
listener calls one of the receive methods of the fired
IIncomingFileTransferReceiveStartEvent. This event is fired during
their openStream implementation while the initiating
sendRetrieveRequest call has not yet returned.
AbstractRetrieveFileTransfer is used for http/s by both HttpClient
provide as well as URLConnection based provide. It is also used
for scp.
When the startEvent is received information from the initial server
response is already available. This is great.
For example if the caller knows how large a file is supposed to be
it can avoid downloading a file with a mismatched size. I think the
API should quarantuee that this information will
be available when the start event is fired for protocols that
reveal the information in the intial server response, before the
actual content is provided.
But it seems the job could also be scheduled before the first
request/respnse is made to the server. However this would require
the FileTransferJob related information currently passed into
IIncomingFileTransferReceiveStartEvent#receive to be made available
in some way. I believe this could be done without using non
blocking network IO.
>
> I think it's OK to have the API specify that it blocks for a bounded
> time. Thoughts?
How would the time be bounded?
Bounding the time would help if it guarantueed that the call would
not wait on a blocking network call longer than that time.
However I believe there are situations where this is not happening
despite having socket timeouts in place.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=234916
Cases like this may make callers of the API introduce another
thread or job. This would presumably be also needed in situations
where cancel needs to works instantly.
More thoughts?
Thanks,
Henrich