On Thu, Jul 09, 2009 at 01:50:40PM -0500, Shawn Walker wrote: > [email protected] wrote: >> I was under the impression that the transport's callers would prefer not >> to disclose a lot of information about their underlying reasons for >> calling. However, if you're less concerned about this second point, and >> don't have a problem with refreshes knowing whether they're implicit or >> not, we could pass a flag to get_catalog that indicates whether the >> portal test should be run or not. Since 9929 makes the call occur in >> the transport method, instead of hiding it within the initialization >> routine, it's a bit more obvious what's going on. > > I think the way to handle it is to let the caller deal with the > behaviour. That is, I expect the client to catch general network > failure exceptions when they do an implicit refresh and then ignore them > if they don't care. In other words, I don't expect the transport engine > to deal with this. > > In that case, will that still avoid the multiple portal test errors?
If we only run the test once and let the caller catch the exception from the portal test in the implicit case, then the test won't get run again. If the test failed and the client then attempts an operation that needs to get data, but the network is unavailable or misconfigured, it will try its hardest to contact the hosts, because it thinks they're available. Unless I've missed an option, we have the following alternatives: 1. Only run the test in cases where we care about its success / failure. We wouldn't do this for implicit refresh or sending intent data. 2. Leave it as it is now. Operations that are strictly informational don't run the test, but operations that retrieve data run the test. (Refresh yes, intent no). 3. Save the exception that's generated when the test fails. In the current implementation, subsequent calls to capitve_portal_test() return without performing the test. Instead of this behavior, check if the test previously failed, if so, re-raise the previous exception. This handles the case where the test fails but a caller caught the exception and didn't do anything. I don't like this approach because we're continuing to raise an error, and don't have a legitimate recovery mechansim for the client. In my previous e-mail, I was suggesting that #1 might be feasibile, but if I've understood you correctly, you're not so keen on this approach? -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
