Hi Joanie,
On Fri, May 01, 2009 at 06:23:51PM -0400, Joanmarie Diggs wrote:
> > # This control how long the socket library waits before a timeout.
> > socket.setdefaulttimeout(int(os.environ.get("PKG_CLIENT_TIMEOUT",
> > "30"))) # in seconds
> >
> > # Override default PKG_TIMEOUT_MAX if a value has been specified
> > # in the environment.
> > global_settings.PKG_TIMEOUT_MAX = int(os.environ.get("PKG_TIMEOUT_MAX",
> > global_settings.PKG_TIMEOUT_MAX))
> >
> > I'd ask you to not override these if the user has set the matching
> > environment variables.
>
> Admittedly I should read docs more than I do. :-) Regardless, now that I
> know about these environment variables, I can see myself using them --
> not decreasing their values, but rather increasing them.
Where do you install your package content from? We've configured a
number of on-SWAN mirrors throughout the world, but I don't know if
there's one in your area. One possibility might be to setup a mirror in
your neighborhood. You wouldn't have to wait so long for downloads in
that case.
> It's a drag, when installing several large packages or doing an
> update, to walk away for a while and return to discover that the
> install/update failed due to a repo or my connection being flakey. I'd
> rather packagemanager keep trying.
My hope is that this will get better over time. I'm replacing the
client-side transport, which currently uses Python's urllib, with
PyCurl/libcurl. It's a more robust and high-performance download
framework. Soon after that, we ought to be adding support for full
mirrors (mirrors that contain metadata and package content).
The client-side transport improvements will allow us to set up more
mirrors in different geographical locations, which should make access to
data faster. The new transport should also allow us to make better use
of web caches and CDNs, since it won't be sending POST requests to
download data. Instead, we'll be issuing piplined GET requests, and
just about anything can cache the response from that type of HTTP
request.
> So assuming I'm following this thread correctly, on my systems the
> progress dialog in question is going to be displayed for even longer
> before failing, even after this issue is addressed?? :-)
The new transport should also make it easier to cancel downloads that
are in progress. My hope is that you'd need to wait less time, but some
network problems are transient, geographical, or both. Getting your
data from a nearby mirror might improve your download speed today,
assuming you're not doing that already.
> The alternatives are waiting it out and doing a forced quit. In the
> latter case (which seems more appealing if you're beginning to suspect
> an app has become non-responsive), packagemanager isn't given much of
> a chance to clean up before being terminated.
This may be a hidden RFE. If the client's aren't properly catching
signals or force-quits (how's that delivered to the app?) then it may be
missing some of the cleanup. I would imagine that it would be pretty
straight forward to introduce a fall-back cleanup handler that tidies up
when an unexpected signal arrives.
-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
