> > > 2. Why is MAX_TIMEOUT_COUNT 3? 3 x 30s is 90s--David's recommended > > > 120s with the current code, so I'm curious if we have a > > > justification for this setting. Should MAX_TIMEOUT_COUNT also be > > > tunable? > > > > I pulled this number out of thin air. I missed David's reccomendation > > about 120s. Was that in a bug report or a discussion on this list? > > > > MAX_TIMEOUT_COUNT is tuneable. You can set PKG_CLIENT_TIMEOUT in the > > environemnt to adjust the duration we wait before a timeout occurs. > > PKG_TIMEOUT_MAX sets the number of timeouts before we give up. > > > > Would you like me to set the default to 4 instead? > > I think we should error out at 120s.
You're suggesting we count the total amount of elapsed time lost to timing out and give up, as a policy, after 120 seconds instead of counting the number of timeouts? I'm trying to make sure I understand what you're recommending. If that is indeed what you're suggesting, then I may as well add exponential backoff code, since the amount of additional work would be trivial. How do you envision this give up after 120s working in that case? We'd wait 30, 60, and then give up, or 30, 60, 120 and then give up? In one case we've only waited 90 seconds, the other 210. > > > 3. How do pkgsend and pkgrecv fare in this new world of > > > TransferInterruptedException? > > > > Both the timeout and its exception handling are controlled by the client > > code. I was under the impression that we didn't have any of that in > > place for pkgsend or pkgrecv. > > I had thought that at least pkgrecv used some of the same retrieval > code--versioned_urlopen() was what I was thinking of. But defer it, > if not. Ooh. I had forgotten about that. Thanks, I'll go double-check to see what's going on in those modules. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
