Control: reassign -1 ruby-soap4r 2.0.5-3 Control: affects -1 + apt-listbugs
On Tue, 1 Aug 2017 23:27:17 +0200 Francesco Poli wrote: [...] > On Tue, 1 Aug 2017 10:34:00 +0200 Vincent Lefevre wrote: > > > On 2017-08-01 10:24:13 +0200, Vincent Lefevre wrote: > > > This solves the timeout issue, but actually the bug is worse than > > > I thought. After setting > > > > > > @drv.options["protocol.http.connect_timeout"] = 10 > > > @drv.options["protocol.http.send_timeout"] = 10 > > > @drv.options["protocol.http.receive_timeout"] = 10 > > > > > > I get: > > > > > > Retrieving bug reports... 0% Fail > > > Error retrieving bug reports from the server with the following error > > > message: > > > E: execution expired > > > It could be because your network is down, or because of broken proxy > > > servers, or the BTS server itself is down. Check network configuration > > > and try again > > > Retry downloading bug information? [Y/n] > > > > > > i.e. it doesn't fallback to the IPv4 address, contrary to what > > > other tools do! > > > > Well, without the above change, I get the usual 2-minute timeout > > per IP address, and the fallback to the first IP address that works > > (here, IPv4). I assume that this is because the timeout occurs at > > the socket level instead of the protocol level, thus not handled > > by the same code. > > Then the situation is less easy than I was hoping... Hello Debian Ruby Extras Maintainers, I am reassigning a [bug report] filed against package apt-listbugs, where the submitter (Vincent) would like to be able to configure the SOAP http timeout, in order to shorten his wait for the fallback to the first IP address that works. [bug report]: <https://bugs.debian.org/869070> Unfortunately, from a test that I suggested, it turned out that setting the protocol.http.* timeout options for ruby-soap4r does not cause the expected behavior. During my summer vacations (and after them), I made some attempts to search for documentation about these ruby-soap4r timeout, but I failed to find a clear explanation of what actually happens when one of these timeouts is reached. Hence, I am asking to you: why does the described behavior (see the bug log) happen? should ruby-soap4r behave as Vincent expected? Please clarify and/or fix the ruby-soap4r behavior and/or forward this bug report upstream. Thanks for your time! Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpotbdRJmQ8K.pgp
Description: PGP signature
_______________________________________________ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers