Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] sendRetrieveRequest blocking

Hi Henrich,

Henrich Kraemer wrote:

<stuff deleted>

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.


Yes, but it would require a provider that can/could make requests without blocking (through whatever means...i.e. threading or non-blocking i/o, etc).


>
> I think it's OK to have the API specify that it blocks for a bounded
> time.  Thoughts?

How would the time be bounded?


Via a default (which is 30 seconds now)...or perhaps an option (to change the bounding to something else).


Bounding the time would help if it guarantueed that the call would
not wait on a blocking network call longer than that time.


The network call being made here (for http) is tcp 'connect'...just to be clear. The Socket-based IO is supposed to guarantee that if a connect timeout is specified that the blocking connect only waits the connect timeout time...and throws an IOException (I believe) if a connect response has not been made.

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


It's possible of course that there is a bug in the socket library, or some interaction with a server bug that is preventing the socket from not timing out on connect. But it's not obvious to me that this bug is resulting from such a situation.

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.


What would be such a situation? (i.e. when cancel has to work 'instantly'?). Any interprocess communication is going to take some measurable time (whether blocking or not), and so what is the usefulness of an 'instantaneous' cancel?


More thoughts?


Although I agree with you that it's possible to make a completely non-blocking implementation of sendRetrieveRequest, I'm not convinced it reaches a threshold of 'worth doing'. That is, the bug cited above may very well not be a case of socket.connect() waiting forever...it might very well be something else. And so making the sendRetrieveRequest completely non-blocking seems like more effort than it's worth at this point.

But, I'm not at all against the notion. It might be useful to implement it with the httpclient-based implementation...since we seem to be moving to more usage of there is momentum for that provider anyway.

Scott



Back to the top