On 07/16/12 13:18, Frank Batschulat wrote:
but apparently they do not quite work as advertised:
root@osoldev:~# env|grep PKG
PKG_CLIENT_MAX_CONSECUTIVE_ERROR=0
PKG_CLIENT_CONNECT_TIMEOUT=300
PKG_CLIENT_LOWSPEED_TIMEOUT=0
root@osoldev:~# pkg update -v --accept
pkg: 2/4 catalogs successfully updated:
Framework stall:
URL:
'http://ipkg.us.oracle.com/internal/solaris11/internal-only/versions/0/'
Framework stall:
URL: 'http://ipkg.us.oracle.com/opensolaris/extra/versions/0/'
after also setting PKG_CLIENT_CONNECT_TIMEOUT=0
it gets going for some time...
the real cool thing to report was that it re-used the already downloaded
400MB from belows 1st attempt out of the cache and was not trying to
get them again from OTW, awesome !
but then again I bomb out:
DOWNLOAD PKGS FILES XFER (MB) SPEED
system/locale 536/731 11943/14268 533.9/679.3 23.0k/s
Errors were encountered while attempting to retrieve package or file
data for
the requested operation.
Details follow:
1: Framework stall:
URL:
'http://ipkg.us.oracle.com/solaris11/dev/solaris/file/1/6ed1a33937a27a4708c97f521084cd15cc3e3204'
(happened 4 times)
...
The environment variables in question simply set libcurl controls.
The "Framework stall" here is a general error that's raised to
workaround (what was) a known libcurl issue at the time.
However, I would note that zero value case for the timeout control is
not being properly honoured here; a bug will be filed for that.
As a workaround, I would set the timeout to a rather large value (< 24
hours, but at least a few hours) and try again.
Finally, I would note that by default, access to ipkg.us.oracle.com will
be proxied if you're on OWAN. You will likely get significantly better
transport performance if you include ipkg.us.oracle.com in your
$no_proxy environment variable, like this:
export no_proxy=ipkg.us.oracle.com
-Shawn
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
