Implemented/modified PUT & POST to not used chunked encoding for the request.
Made the unit test much happier and probably a better thing for the pipeline.
Have a cheesy static & dynamic proxy capability using both local options and
a way to wire into LLProxy in llmessages. Not a clean thing but it will get
the proxy path working with both socks5 & http proxies. Refactoring to get
rid of unneeded library handler and unified an HttpStatus return for all
requests. Big batch of code removed as a result of that and more is possible
as well as some syscall avoidance with a bit more work. Boosted the unit
tests for simple PUT & POST test which revealed the test harness does *not*
like chunked encoding so we'll avoid it for now (and don't really need it
in any of our schemes).
This brings in a copy of llmessage's llsdmessage testing server. We run
a mocked HTTP service to handle requests and the integration tests run
against it by picking up the LL_TEST_PORT environment variable when running.
Add some checks and output to produce useful info when run in the wrong
environment and when bad status is received. Later will add a dead port
as well so we can test that rather than use 'localhost:2'.
Generally, opaque data operations are expected to be over 'void *' and have
now converted interfaces to do that. Update() method honors millisecond limit to dwell
time. Might want to homologate the millis/uSecs mix later....
Retry/response handling is decided in policy so moved that there. Removed special case
206-without-content-range response in transport. Have this sitation recognizable in the
API and let callers deal with it as needed.
Our logging holds on to a changing bit of memory between operations and the memory
leak detection I'm using senses this and complains. So, for now, disable the
final memory check on Mac & Linux, leave it active on Windows. Solve this for
real some other day. Add try/catch blocks to do cleanup in unit tests that go
wrong so that we don't get a cascade of assertion failures when subsequent tests
find singletons still alive.
surprised me. Added a retry queue similar to ready queue to the
policy object which is sorted by retry time. Currently do five
retries (after the initial try) delayed by .25, .5, 1, 2 and 5
seconds. Removed the retry logic from the lltexturefetch module.
Upped the waiting time in the unit test for the retries. People
won't like this but tough, need tests.
Went through all the code and tried to document lock and thread usage
in the module. There's a huge comment block introducing all of this
at the beginning and I believe it's correct (though not quite complete).
Keep it updated, people. Added a new state, WAIT_HTTP_RESOURCE, that's
sort of a side-state of SEND_HTTP_REQ. If we hit a high-water mark
for HTTP requests, the extra are shunted to the new state once. Once
levels fall to a low-water mark, we run through a wait list of UUIDs,
sort the valid ones by priority and release them for service. This
keeps the HTTP layer busy while leaving the active queue shallow enough
that requests can still be re-prioritzed cheaply. Priority model
changed. The new state uses the PRIORITY_LOW mask, the old users
of _LOW are now at PRIORITY_NORMAL and sleepers woken up after an
external event are kicked off at PRIORITY_HIGH. This combination
along with the new state should avoid priority inversion and keep
things running without resorting to an infinite pipeline. New
state displays as "HTW" with green text in the texture console.
Request cancelation and worker run-down should now be more
correct but this edge case may need more attention.
Implemented first global policy definitions to support SSL CA certificate configuration
to support https: operations. Fixed HTTP 206 status handling to match what is currently
being done by grid services and to lay a foundation for fixes that will be a response
to ER-1824. More libcurl CURLOPT options set on easy handles to do peer verification
in the traditional way. HTTP POST working and now reporting asset metrics back to
grid for the viewer's asset system. This uses LLSD so that is also showing as compatible
with the new library.
Identified and reacted to the priority inversion problem we
have in texturefetch. Includes the introduction of a priority_queue
for the requests that are ready. Start some parameterization in
anticipation of having policy_class everywhere. Removed _assert.h
which isn't really needed in indra codebase. Implemented async
setPriority request (which I hope I can get rid of eventually along
with all priorities in this library). Converted to using unsigned
int for priority rather than float. Implemented POST and did
groundwork for PUT.
This is the first functional viewer pass with the HTTP work of the texture fetch
code performed by the llcorehttp library. Not exactly a 'drop-in' replacement
but a work-alike with some changes (e.g. handler notification in consumer
thread versus responder notification in worker thread).
This also includes some temporary changes in the priority scheme to prevent
the kind of priority inversion found in VWR-28996. Scheme used here does
provide liveness if not optimal responsiveness or order-of-operation.
The llcorehttp library at this point is far from optimally performing.
Its worker thread is making relatively poor use of cycles it gets and
it doesn't idle or sleep intelligently yet. This early integration step
helps shake out the interfaces, implementation niceties will be covered
soon.
while allocating the first easy handle in a descent of the global initiailization
code but that doesn't seem to be a problem on TC machines. Perhaps the static
linking is creating multiple data copies. More work needed.
defenses in the delete functions of the allocation support. General
boost library renaming again. Linux builds in TC though it shouldn't
based on what Boost.cmake lookes like...
boost::thread and the easiest path to that was to go with the 1.48 Boost release
in the 3P tree (eliminating a fork for a modified 1.45 packaging). One unit test,
the most important one, is failing in test_httprequest but that can be attended
to later. This test issues a GET to http://localhost:2/ and that is hitting the
wire but the libcurl plumbing isn't delivering the failure, only the eventual
timeout. An unexpected change in behavior.
Monty Brandenberg