Crash on request with invalid url about deepdetect

[beniz]

hey, thanks for catching this unfortunate regression again. The parallel loop should now be fixed wrt exceptions and there's a dedicated unit test to avoid further regressions. Let me know if it fixes your issue.

[yhenon]

Hi - this appears to fix the issue for all my test cases - I'll go ahead and close it. Thanks for your help.

[yhenon]

Hey - thanks again for your work here, but I think I'll go ahead and reopen this as I'm encountering another crash (tell me if you'd rather I open a new issue).

This one is proving to be tricky to reproduce, but the issue seems to be cURL timing out on HTTPS requests leading to an unhandled exception in deepdetect. However the curl request seems to be fine most of the time, the timeout only occurs sometimes.

curl -X POST "host.com:8080/predict" -d "{\"service\":\"imgnet\",\"parameters\":{\"input\":{\"width\":224,\"height\":224},\"output\":{\"best\":5}},\"data\":[\"https://scontent.cdninstagram.com/hphotos-xaf1/t51.2885-15/e15/11236339_839225329503090_301378127_n.jpg\"]}"

ERROR - service imgnet mllib bad param: Operation timed out after 0 milliseconds with 0 out of 0 bytes received
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'
what():  remote_endpoint: Transport endpoint is not connected

The strange curl message seems to be something others encounter(see here: http://stackoverflow.com/questions/22485811/curl-operation-timed-out-after-0-milliseconds )

[beniz]

Thanks for the detailed report. As you guessed, I am unable to easily reproduce. However, you should be able to test the potential fix you are pointing to, by modifying src/utils/httpclient.hpp such that the new options can be passed to the curl wrapper used in get_call:

request.setOpt(curlpp::options::Url(url));
request.setOpt(curlpp::options::SslVerifyPeer(false));
request.setOpt(curlpp::options::SslVerifyHost(false));
request.setOpt(curlpp::options::SslVersion(3));

If you could also try various combinations of these options, I am interested in the results. Typically, the version 3 of SSL is considered unsecure so it does feel a bad idea to force it here.

That being said, the Web is a wild wild world, it is very likely that some broken or atypical server out there breaks dd calls, though it is expected that all situations will eventually get covered. If you are dealing with lots of content directly coming from the Web, I am making the suggestion that you first retrieve content with some dedicated tool (e.g. scrapy), store it temporarily and pass it on to dd. That would probably give you the two benefits of being more robust to the outside world, and limiting recurrent calls to useless or broken resources.

I am keeping this ticket open to gather all retrieval glitches then, and to fix them as they come.

[beniz]

@yhenon the fix above catches exceptions around the curl calls, though in your case it will not retrieve the image, assuming it is possible to so.

[yhenon]

Thanks, the catch around the curl call seems to solve the issue. I'm not 100% clear on when curlpp throws an exception - but I think we can agree that failing to retrieve the image is significantly better than deepdetect exiting.

I do see your point though - I might move to a pipeline where I curl the image -> upload to S3 -> query with deepdetect, although this adds quite a bit of latency for the end-user.

Thanks again, I'll leave this open even though I'm not aware of any crashes with image retrieval currently.

[beniz]

we can agree that failing to retrieve the image is significantly better than deepdetect exiting.

Definitely!

I might move to a pipeline where I curl the image -> upload to S3 -> query with deepdetect, although this adds quite a bit of latency for the end-user.

There's support for passing images in base64 format, that comes with an encoding size overhead of course. Also, using batches wherever you can (and with GPU when possible) should yield best performance.

[beniz]

Beware of #68 and pull out the fix if using multiple images prediction at once.