On 03/ 6/12 11:17 AM, [email protected] wrote:
On Tue, Mar 06, 2012 at 10:08:00AM +1300, Tim Foster wrote:
I've got an incremental, and new webrev at:
https://cr.opensolaris.org/action/browse/pkg/timf/poisoned-cache-v2/
On lines 1286-1298 and 1887-1899 you're not recording the fact that
you've seen a content error, which is going to skew the repository
statistics for future choices.
Fair point - I'm hand-wringing a bit here, as to whether a fast cache
that occasionally returns bad content should be treated differently to a
slow or unavailable repository..
In general, I'm not really thrilled with this approach. It might be
simpler to set the cache-clearing headers on any subsequent attempt to
connect to a repository that has already given us a content error.
To do this, you'd want to add the iteration count to gen_repos, as Shawn
suggested.
That sounds reasonable too, thanks for the suggestion. I'm already part
of the way through updating __gen_repos after Shawn's recent suggestion,
so I'll factor this in too.
? You'll also want to add a content_errors property to the
repo statistics, in stats.py. Then, instead of doing a big dance with
adjusting the retry count on the fly, simply record a content error when
verification fails. At the beginning of the 'for d, v in
self.__gen_repo()' loop, you can check whether you're on a subsequent
iteration, and if so, look at the repostats to determine if you've seen
a content error.
I'll give that a go. Recording content errors seems like a good start,
and perhaps might allow us to take different actions on repositories
with content errors in the future.
Apart from the bug report, I don't know how prevalent this problem is in
the wild, but it certainly felt like something we should be addressing.
I'll go back to the drawing board, and send another webrev when I'm
done. Thanks for the suggestions.
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
