Id rather than sha1 hash, since that is rarely used in modern
certs. The previous form was storing trusted certs using an empty sha1
hash value as the key, which meant most certificates matched... not good.
Modify the LLCertException to pass certificate information back as
LLSD rather than an LLPointer<LLCertificate>, because when the
exception is being thown from the certificate constructor that results
in one of a couple of other exceptions (even refcounting won't save
you when the problem is that the thing you're pointing to never
finished coming into being properly).
Update the certificates in the llsechandler_basic_test to modern
conventions, and extend the classes to allow for an optional
validation date so that the test can use a fixed date. Also make all
the certificates include the plain text form for ease of reference.
Wrap coroutine call in try/catch in top-level coroutine wrapper function
LLCoros::toplevel(). Distinguish exception classes derived from
LLContinueError (log and continue) from all others (crash with LL_ERRS).
Enhance CRASH_ON_UNHANDLED_EXCEPTIONS() and LOG_UNHANDLED_EXCEPTIONS() macros
to accept a context string to supplement the log message. This lets us replace
many places that called boost::current_exception_diagnostic_information() with
LOG_UNHANDLED_EXCEPTIONS() instead, since the explicit calls were mostly to
log supplemental information.
Provide supplemental information (coroutine name, function parameters) for
some of the previous LOG_UNHANDLED_EXCEPTIONS() calls. This information
duplicates LL_DEBUGS() information at the top of these functions, but in a
typical log file we wouldn't see the LL_DEBUGS() message.
Eliminate a few catch (std::exception e) clauses: the information we get from
boost::current_exception_diagnostic_information() in a catch (...) clause
makes it unnecessary to distinguish.
In a few cases, add a final 'throw;' to a catch (...) clause: having logged
the local context info, propagate the exception to be caught by higher-level
try/catch.
In a couple places, couldn't resist reconciling indentation within a
particular function: tabs where the rest of the function uses tabs, spaces
where the rest of the function uses spaces.
In LLLogin::Impl::loginCoro(), eliminate some confusing comments about an
array of rewritten URIs that date back to a long-deleted implementation.
Turns out we have a surprising number of catch (...) clauses in the viewer
code base. If all we currently do is
LL_ERRS() << "unknown exception" << LL_ENDL;
then call CRASH_ON_UNHANDLED_EXCEPTION() instead. If what we do is
LL_WARNS() << "unknown exception" << LL_ENDL;
then call LOG_UNHANDLED_EXCEPTION() instead.
Since many places need LOG_UNHANDLED_EXCEPTION() and nobody catches
LLContinueError yet, eliminate LLContinueError& parameter from
LOG_UNHANDLED_EXCEPTION(). This permits us to use the same log message as
CRASH_ON_UNHANDLED_EXCEPTION(), just with a different severity level.
Where a catch (...) clause actually provides contextual information, or makes
an error string, add boost::current_exception_diagnostic_information() to try
to figure out actual exception class and message.
The LLProtectedDataException and LLCertException exception classes didn't used
to be derived from std::exception, so they followed their own getMessage()
convention instead of the standard what() convention. Now that they're derived
from std::exception, remove getMessage() and change its few consumers to use
what() instead. Thanks NickyD for suggesting.
connections. Convert background and foreground fetches, both
items and folders/inventory and library, to use new HTTP.
Non-fetch inventory operations continue to use LLHTTPClient
(at least for now). Error handling and retry on fetches wasn't
100% previously and that's still the case. I'll rip through
this again to clean that up. Cleaned up logging in much of
the inventory code with consistent labels on logging events
and correct macros (removed deprecation warnings).
This started as an attempt to get libcurl to do pipelining
on POSTs and PUTs. Discovered that this is going to be
very difficult to support in general in libcurl. May
look at that again in the future.
some problems disabling pipelining on a multi handle with outstanding
requests so build a more conservative system that allows requests
to drain before setting curl multi options. Would rather not have
this but it is significantly safer. "HttpPipelining" debug setting
is now fully dynamic. Connection limits can also be made dynamic
in the near future. Upped the default connection count back to 8 for
now but will revisit this in the tuning phase. It might be time to
combine mesh and textures into a single asset class. For normal
server operations that would be a clear path, but for server under
load, the current scheme may be better. Minor cleanup in logging
to elminate some redundant strings. Might add some more tracing to the
stall logic 'just in case'.
data so their isn't an opportunity for gaps over overruns (init_data).
Start some preliminary tweaking of policy class numbers. It looks
like I can easily drop the default connection count to '4' and
still hit the throttles. Did some experiments running pipeline
deeper which was mostly fine for textures but tended to slow
meshes. Reason uncertain but a depth of '5' seems generally healthy
for mesh. I had one run of 52.6S with a theoretical minimum of 51.2S.
That's as good as I've ever seen.
GetTexture and GetMesh2 at a pipeline depth of 5. Create
global debug option, HttpPipelining, to enable and disable
HTTP pipelining (defaults to true). Tweak texture and
mesh low- and high-water request levels based on pipelining
status and depth. Fixup texture console which was damaged
in a recent release. Split logging of the no-request
HTTP error case into two cases: one for missing URL in
HTTP request, one for HTTP request not created. A refactor
in llcorehttp is coming: I will be moving all libcurl-
using code into libcurl-specific modules.
Last bit for this release. Describe stream adapters and how
to select a policy class. Slight changes to setup code to
make reality reflect documentation.
While linking GetMesh2 to the old setting was simpler from a user
point-of-view, they really shouldn't be linked and the old one will
go away. This one may be renamed to AssetMaxConcurrentRequests or
something similar if we get to the mesh/texture unification step.
This really extended into the client-side request throttling.
Moved this from llmeshrepository (which doesn't really want
to do connection management) into llcorehttp. It's now a
class option with configurable rate. This still isn't the
right thing to do as it creates coupling between viewer
and services. When we get to pipelining, this notion becomes
invalid.
Ansariel