Author: gstein
Date: Wed Jul 20 04:15:31 2011
New Revision: 1148619
URL: http://svn.apache.org/viewvc?rev=1148619&view=rev
Log:
Complete the details on how to test this stuff.
* notes/ra-serf-testing.txt: much more detail. almost there.
Modified:
subversion/trunk/notes/ra-serf-testing.txt
Modified: subversion/trunk/notes/ra-serf-testing.txt
URL:
http://svn.apache.org/viewvc/subversion/trunk/notes/ra-serf-testing.txt?rev=1148619&r1=1148618&r2=1148619&view=diff
==============================================================================
--- subversion/trunk/notes/ra-serf-testing.txt (original)
+++ subversion/trunk/notes/ra-serf-testing.txt Wed Jul 20 04:15:31 2011
@@ -237,6 +237,82 @@ inject some disk content.
Exits in state (6) or (7).
+OVERALL TEST MECHANISM
+
+If we can get a "large enough" [update] report, then we could create
+one large internal test that will move through all the necessary
+states to perform each of the operations. We need control over
+incoming network blocks, the pause/unpause, and when to process
+PENDING data. These controls are typically based on the number of
+outstanding requests in the upate processing. These variables can be
+precisely controlled except for the network content. Thankfully, serf
+does tend to "spill out" of serf_context_run() often enough that we
+may be able to sequence through the test as desired.
+
+At the moment, serf states that a response handler (e.g our handler
+that shoves the incoming data into the XML parser) must consume all
+content found on the network. A future version of serf may allow the
+repsonse handler to push back on that. For now, we're applying the
+push-back as application-level logic.
+
+We can implement the entire test suite in libsvn_ra_serf/util.c as a
+sequence of actions to take for each step. This can be controlled by a
+global variable to track the step, and an array of actions to take at
+each step. The code will use a special #define to enable it, and the
+test will be run manually by a developer by building the appropriate
+subversion, then executing an "svn checkout". When the steps conclude,
+the logic will revert to normal.
+
+Following are the list of steps. We attempt to minimize this list in
+order to get the system tested with as few steps/transitions as
+possible.
+
+1. paused. content arrival is TEST 1.1. step on state (3).
+2. paused. content arrival is TEST 1.3. [no spill]
+3a. network: unpaused. content arrival is TEST 2.3. [no spill]
+3b. loop: no injection
+4a. network: unpaused. extra content is TEST 2.3. [no spill]
+4b. loop: unpaused. inject all memory content. TEST 3.3. step on state (2).
+5. paused. content arrival is TEST 1.2. step on state (3).
+6. paused. content arrival is spilled. step on state (4).
+7. paused. content arrival is TEST 1.4.
+8a. network: unpaused. content arrival is TEST 2.4.
+8b. loop: no injection
+9a. network: unpaused. extra content is TEST 1.4.
+9b. loop: unpaused. inject all memory content. TEST 3.4. step on state (6)
+10. paused. content arrival is TEST 1.6.
+11a. network: unpaused. content arrival is TEST 2.6. step on state (6)
+11b. loop: no injection
+12a. network: unpaused. extra content is TEST 2.6.
+12b. loop: unpaused. inject all disk content. TEST 3.6. step on state (7)
+13. paused. content arrival is TEST 1.7
+14. return to default/normal processing
+
+note: "extra content" means that TEST has been previously tested, so
+ we don't really need this particular test. but since the network
+ content is uncontrolled, we may end up (re)testing.
+
+
+IMPLEMENTATION NOTES
+
+* gotta figure out low-impact
+* array of structures with: paused, inject, force_spill
+* set ->paused on each step increment, since we don't know if the next
+ entry point will be the network or the processing loop
+* there are three content injection steps. transition to next step is
+ straight-forward after injection is complete
+* transition based on network has three transitions from the unpaused
+ state.
+* when paused, there are seven network transitions. exit upon reaching
+ a state? yes. occurs *after* network content is saved (the saving of
+ the content is of of the TEST scenarios)
+* when force_spill is defined, the pending content goes right to disk,
+ independent of the memory_size. since we will put further pending
+ data into the spill file, we don't need to check force_spill ever
+ again. oh... we can just look for step==6 rather than a flag.
+
+
+
------------
OLD NOTES
