-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
asyncmap never ends with HTTP.get #909
Comments
Thanks for the report! Can you confirm the versions of HTTP and MbedTLS packages please? |
HTTP v1.2.1 |
I've made some progress on this, but haven't gotten it working all the way. |
Fixes #909. Great issue that stretches our current system and exposes a bunch of places where we weren't accounting for timeouts. The core issues here are when we have a proxy involved, we had a couple more places where we were connecting/writing/reading, but weren't applying a user-provided `connect_timeout` or `readtimeout`. Also for our ssl upgrade path. In the OP's example, we're hitting thousands of mostly non-functional proxies, so it's basically a huge stress test on all the error paths of our request code. This PR proposes: * a new `try_with_timeout` function to provide a consistent way to run code while waiting for a timeout * use the new function in a number of places where we might be stuck waiting I'm able to get the original script OP provided to finish in ~150 seconds, and I tried out a multithreaded version that finished in about ~17 seconds w/ 8 threads.
* Cleanup all timeout code and places where we might timeout Fixes #909. Great issue that stretches our current system and exposes a bunch of places where we weren't accounting for timeouts. The core issues here are when we have a proxy involved, we had a couple more places where we were connecting/writing/reading, but weren't applying a user-provided `connect_timeout` or `readtimeout`. Also for our ssl upgrade path. In the OP's example, we're hitting thousands of mostly non-functional proxies, so it's basically a huge stress test on all the error paths of our request code. This PR proposes: * a new `try_with_timeout` function to provide a consistent way to run code while waiting for a timeout * use the new function in a number of places where we might be stuck waiting I'm able to get the original script OP provided to finish in ~150 seconds, and I tried out a multithreaded version that finished in about ~17 seconds w/ 8 threads. * fixes
@quinnj Thanks a lot for the support but the problem persists in version 1.3.0 Error in Timer:
MethodError: no method matching shouldtimeout(::HTTP.ConnectionPool.Connection, ::Int64, ::HTTP.ConnectionRequest.var"#5#11")
Closest candidates are:
shouldtimeout(::HTTP.ConnectionPool.Connection, ::Any) at ~/.julia/packages/HTTP/GjUWZ/src/ConnectionPool.jl:102
Stacktrace:
[1] (::HTTP.ConnectionRequest.var"#4#10"{Int64})()
@ HTTP.ConnectionRequest ~/.julia/packages/HTTP/GjUWZ/src/clientlayers/ConnectionRequest.jl:92
[2] (::HTTP.Exceptions.var"#5#8"{HTTP.ConnectionRequest.var"#4#10"{Int64}, Int64, HTTP.Exceptions.var"#3#6", Condition})(tm::Timer)
@ HTTP.Exceptions ~/.julia/packages/HTTP/GjUWZ/src/Exceptions.jl:40
[3] macro expansion
@ ./asyncevent.jl:281 [inlined]
[4] (::Base.var"#665#666"{HTTP.Exceptions.var"#5#8"{HTTP.ConnectionRequest.var"#4#10"{Int64}, Int64, HTTP.Exceptions.var"#3#6", Condition}, Timer})()
@ Base ./task.jl:134Error in Timer:
MethodError: no method matching shouldtimeout(::HTTP.ConnectionPool.Connection, ::Int64, ::HTTP.ConnectionRequest.var"#5#11")
Closest candidates are:
shouldtimeout(::HTTP.ConnectionPool.Connection, ::Any) at ~/.julia/packages/HTTP/GjUWZ/src/ConnectionPool.jl:102
Stacktrace:
2[1] fail 213.6.145.33:4153(::HTTP.ConnectionRequest.var"#4#10"{Int64})
()
@ HTTP.ConnectionRequest ~/.julia/packages/HTTP/GjUWZ/src/clientlayers/ConnectionRequest.jl:92
[2] (::HTTP.Exceptions.var"#5#8"{HTTP.ConnectionRequest.var"#4#10"{Int64}, Int64, HTTP.Exceptions.var"#3#6", Condition})(tm::Timer)
@ HTTP.Exceptions ~/.julia/packages/HTTP/GjUWZ/src/Exceptions.jl:40
[3] macro expansion
@ ./asyncevent.jl:281 [inlined]
[4] (::Base.var"#665#666"{HTTP.Exceptions.var"#5#8"{HTTP.ConnectionRequest.var"#4#10"{Int64}, Int64, HTTP.Exceptions.var"#3#6", Condition}, Timer})()
@ Base ./task.jl:1342 fail 141.105.86.130:44660
|
Ah shoot, sorry about that. I was moving the code around a little bit last minute and forgot to update on place, but must have still had the working code loaded in my session that was passing. PR to fix: #911 |
Ok, the new release (v1.3.1) is out now, so hopefully all is good |
Worked perfectly!! Thank you very much |
Hello guys. I believe I found a bug in the asyncmap or the HTTP package. My goal is to test a list of 4881 proxies and find the ones that are working. But
asyncmap
never seems to finish.To compare the performance I ran the
asyncmap
function with two functions. One that has asleep(5)
and one that makes aHTTP.get
request withreadtimeout=5, retry=false
.The execution time of the function with
sleep(5)
was 248.891672 seconds. The execution ofHTTP.get
never ends, it gets slower and slower until it almost stops.Here is my versioninfo():
Here is my list of proxies:
https://paste.debian.net/plain/1251148
Here is my test code:
The text was updated successfully, but these errors were encountered: