Oleg,
First option is recommended if we upgrade to 4.0 I take it? Is it a
stable release or beta?
Third option, could you please explain it in some more detail, I
don't get it.=/
/regards, Håkan
19 jan 2009 kl. 19.50 skrev Oleg Kalnichevski:
You have three options:
(1) Recalculate (decrease) the SO_TIMEOUT value after each
successful read from the input stream. Not recommended unless you
are willing to upgrade to HttpClient 4.0
(2) Start a controller thread that aborts the request if it has not
completed to a specific deadline. Not recommended unless the number
of requests is relatively small.
(3) Reconsider the requirements (for instance, retrieve content
asynchronously instead of enforcing a total timeout on the
requests). Recommended.
Oleg
/best regards, Håkan - and thanx for your patience
19 jan 2009 kl. 17.56 skrev Oleg Kalnichevski:
On Mon, 2009-01-19 at 17:38 +0100, hakan.jacobsson wrote:
Oleg,
You said:
Socket timeout is the maximum period of inactivity between two
_consecutive_ read operations.
So, if this is true how can I limit the time taken by the read
operations?
I'll repeat it again. SO_TIMEOUT is a pretty standard TCP/IP
concept.
This value represents the maximum period of inactivity between two
consecutive read operations on a TCP/IP socket, which in Java terms
means the maximum period of time Socket#read method can remain
blocked
waiting for data.
For example, it SO_TIMEOUT is set to 1000 ms, and the remote host
sends
a packet every 999 ms, the socket will NEVER time out.
I need to be able to set a timeout which aborts the request
under any
circumstance.
What circumstances? What is it that you are trying to do? Make
sure the
socket does not block indefinitely? Limit the total request
execution
time?
Is this not possible with HttpClient?
WHAT IS IT EXACTLY that you want to achieve?
Oleg
/best regards, Håkan
If all depends what you want to achieve.
19 jan 2009 kl. 17.21 skrev Chad La Joie:
I agree, that's why I said it would help if it were documented
which (if
any) of those were the actual behavior.
Oleg Kalnichevski wrote:
Guessing does not always help.
--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
[email protected], http://www.switch.ch
------------------------------------------------------------------
---
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: httpclient-users-
[email protected]
-------------------------------------------------------------------
--
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: httpclient-users-
[email protected]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
