I often experience failure to download binaries from their repositories (even on run.pivotal.io) with cnx_reset or timeouts (see http://cloudfoundry.zendesk.com/entries/26564506-Getting-failure-or-cnx-reset-on-run-pivotal-io-downloading-custom-buildpack )
Ruby 2.0 seems to have built-in single retry https://github.com/ruby/ruby/blob/044e75db6d810dece06d8a7921aae18a6024faa8/lib/net/http.rb#L1429 . Unfortunately, I understand the current CF stack uses ruby 1.9 to execute java-buildpack code (http://docs.cloudfoundry.com/docs/running/architecture/stacks.html), and therefore no retries are currently applied.
Could the java_buildpack add a retry mechanism similar to the usual http client retries (e.g. http://hc.apache.org/httpclient-3.x/exception-handling.html#Automatic_exception_recovery ) so that most transient GET timeouts/cnx resets get handled transparently ?
I often experience failure to download binaries from their repositories (even on run.pivotal.io) with cnx_reset or timeouts (see http://cloudfoundry.zendesk.com/entries/26564506-Getting-failure-or-cnx-reset-on-run-pivotal-io-downloading-custom-buildpack )
Ruby 2.0 seems to have built-in single retry https://github.com/ruby/ruby/blob/044e75db6d810dece06d8a7921aae18a6024faa8/lib/net/http.rb#L1429 . Unfortunately, I understand the current CF stack uses ruby 1.9 to execute java-buildpack code (http://docs.cloudfoundry.com/docs/running/architecture/stacks.html), and therefore no retries are currently applied.
Could the java_buildpack add a retry mechanism similar to the usual http client retries (e.g. http://hc.apache.org/httpclient-3.x/exception-handling.html#Automatic_exception_recovery ) so that most transient GET timeouts/cnx resets get handled transparently ?