You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't have good details yet about exactly what happens, but it appears that there is a failure mode where the HTTP transport (really the HTTP IO module of wandio) gets stuck trying to read from an HTTP connection that the server has already closed. Rather than trying for a while and then eventually giving up, wandio just keeps polling forever.
The relevant code (afaict) is this loop: https://github.com/wanduow/wandio/blob/master/lib/ior-http.c#L153
I guess the fix will be either some configuration option to libcurl that forces it to give up on a connection after some max time between bytes, or implementing the equivalent check directly within the wandio HTTP reader. This has the potential to cause other issues however because we also use wandio to read from "live" streams where it would be perfectly reasonable for there to be significant time between bytes sent from the server. Maybe there is some other way we can fix this? TCP Keepalives might actually do the trick: https://curl.haxx.se/libcurl/c/CURLOPT_TCP_KEEPALIVE.html
This problem is one that we've seen internally, and has been reported in a few different places, e.g., #175, CAIDA/bgpstream#104.
The text was updated successfully, but these errors were encountered:
I don't have good details yet about exactly what happens, but it appears that there is a failure mode where the HTTP transport (really the HTTP IO module of wandio) gets stuck trying to read from an HTTP connection that the server has already closed. Rather than trying for a while and then eventually giving up, wandio just keeps polling forever.
The relevant code (afaict) is this loop: https://github.com/wanduow/wandio/blob/master/lib/ior-http.c#L153
I guess the fix will be either some configuration option to libcurl that forces it to give up on a connection after some max time between bytes, or implementing the equivalent check directly within the wandio HTTP reader. This has the potential to cause other issues however because we also use wandio to read from "live" streams where it would be perfectly reasonable for there to be significant time between bytes sent from the server. Maybe there is some other way we can fix this? TCP Keepalives might actually do the trick: https://curl.haxx.se/libcurl/c/CURLOPT_TCP_KEEPALIVE.html
This problem is one that we've seen internally, and has been reported in a few different places, e.g., #175, CAIDA/bgpstream#104.
The text was updated successfully, but these errors were encountered: