This is the function in indra/llmessage/tests/testrunner.py that iterates
through ports in a specified range, looking for an available one. Other
platforms understand a specification of port 0 to mean: "You pick one. I'll
just use whichever one you picked."
Instead of having testrunner.run()'s caller pass a Thread object on which to
run the caller's server instance's serve_forever() method, just pass the
server instance. testrunner.run() now constructs the Thread. This API change
allows run() to also call shutdown() on the server instance when done, and
then join() the Thread.
The hope is that this will avoid the Python runtime forcing the process
termination code to 1 due to forcibly killing the daemon thread still running
serve_forever().
While at it, eliminate calls to testrunner.freeport() -- just make the runtime
pick a suitable port instead.
Loath though I am to skip testing, this consistent failure is not a failure in
the software being tested (llcorehttp) but rather in the dummy server with
which we're testing it.
Added toTerseString() conversion on HttpStatus to generate a string
that's more descriptive than the hex value of the HttpStatus value
but still forms a short, searchable token (e.g. "Http_503" or
"Core_7"). Using this throughout the viewer now, no live cases
of toHex(), I believe.
Much improved. Unified the global and class options into a single
option list. Implemented static and dynamic setting paths as much
as possible. Dynamic path does require packet/RPC but otherwise
there's near unification. Dynamic modes can't get values back yet
due to the response/notifier scheme but this doesn't bother me.
Flatten global and class options into simpler struct-like entities.
Setter/getter available on these when needed (external APIs) but code
can otherwise fiddle directly when it knows what to do. Much duplicated
options/state removed from HttpPolicy. Comments cleaned up. Threads
better described and consistently mentioned in API docs. Integration
test extended for 503 responses with Reply-After headers.
HttpStatus unit tests have never caused a unit test failure but
they do have the word 'error' in their text descriptions which
gets picked up by the log processor in TC builds. So, reactivate
the tests and reform the descriptions.
I'm calling this the more correct fix. The httprequest tests
actually talk to an HTTP server running in the Python test
scaffold script. Under severe CPU competition, it may not
get the cycles needed to start up and make progress. So this
modifies the test to spin a little faster and dwell waiting
on the server for a longer period. Hope this will be
adequate to make the tests reliable.
library has new exception-throwing behavior when a client disconnects
unannounced. Generally ignore exceptions as a result as we don't
care about the server side. On HTTP trace-mode tests, spin a little
faster and longer to give libcurl time to emit all the junk it wants
to send us. Should reduce 'reasonable time' failures on tests <12>
and <13>.
Not certain what the source of the short data is with one resident but I'm
going to make these problems retryable as they are transport-related. Lift
the retry detection into a method that should be reusable by others interested
in determining what is retryable. Trace output handling on the libcurl debug
callback was attrocious. Some unsafe length handling on my part was protected
by a second layer of defense. Made that correct and more useful by logging
actual data sizes during trace.
Header container moves from a vector of raw lines to a vector
of string pairs representing name/value pairs in headers. For
incoming headers, we normalize the name to lowercase and trim
it. Values are only left-trimmed. Outgoing headers are left
as-is. Simple find() method for the common case, forward and
reverse iterators for those few who need to do it themselves.
The HTTP status line (e.g. 'HTTP/1.1 200 Ok') is no longer treated
as a header to be returned to caller. Unit tests, as usual,
were a bear but they absolutely ensured outgoing HTTP header
conformance after the change. Grunt work paid off.
LLTextureFetch was also given a second options structure
for texture fetches. Same as the original but with header return
to caller requested. Baked textures should use this, the other
20,000 texture fetch requests should continue to use the original.
Cmake files not merged correctly and had to be done by hand. New memory
allocation made some memory usage tests in the llcorehttp integration
tests no longer valid. Would like to work on LLLog sometime and get
it to be consistent. Special flags needed for windows build of example
program.
Define expectations for headers for GET, POST, PUT requests.
Document those in the interface, test those with integration tests.
Verify that header overrides work as expected.
When releasing HTTP waiters, avoid unnecessary sort activity.
For Content-Type in responses, let libcurl do the work and removed
my parsing of headers. Drop Content-Encoding as libcurl will deal
with that. If anyone is interested, they can parse.
First round of integration tests. Added a request header 'reflector'
to the web server to sent the client's headers back with a 'X-Reflect-'
prefix. Use boost::regex to check various headers. Run a test on
a simple GET and a byte-ranged GET a la texture fetch.
Using http_texture_load as the test subject, library looks clean. Did
some better shutdown in the program itself and it looks better. Libcurl
itself is making a lot of noise. Adapted testrunner to run valgrind as
well but the memory allocation tester in the tools themselves grossly
interferes with Valgrind operations.
HttpResponse object now has two strings for these content headers.
Either or both may be empty. Tidied up the cross-platform string
code and got more defensive about the length of a header line.
Integration test for the new response object.
Well, achieved that by doing work in bulk when needed. But
turned into some additional things. Change timebase from
mS to uS as, well, things are headed that way. Implement
an HttpReplyQueue::fetchAll method (advertised one, hadn't
implemented it).
30-second hang doesn't break subsequent tests. Did this by
introducing threads into the HTTP server as I can't find the magic
to detect that my client has gone away.
Nat Goodspeed