I have started using Gridner 3.4 for a few weeks now.
Recently I have decided to use Jython 2.5.2 in replacement to 2.2.1 that comes with Grinder 3.4.
I have checked the list and the trackers to no avail.
I have a test script which I recorded with TCPProxy.
Here are some interesting excerpts (for those who are not used to Python scripts generated by TCPProxy):
request101 = HTTPRequestCheck(url=url0, headers=headers0)
request101 = Test(101, 'GET /').wrap(request101)
request102 = HTTPRequestCheck(url=url0, headers=headers1)
request102 = Test(102, 'GET jpetstore.css').wrap(request102)
"""A TestRunner instance is created for each worker thread."""
# A method for each recorded page.
"""GET / (requests 101-103)."""
result = request101.GET('/mybatis-jpetstore-6.0.1/')
"""This method is called for every run performed by the worker thread."""
self.page1() # GET / (requests 101-103)
def instrumentMethod(test, method_name, c=TestRunner):
"""Instrument a method with the given Test."""
unadorned = getattr(c, method_name)
method = new.instancemethod(test.wrap(unadorned), None, c)
setattr(c, method_name, method)
# Replace each method with an instrumented version.
# You can call the unadorned method using self.page1.__target__().
instrumentMethod(Test(100, 'Page 1'), 'page1')
Now when I run this script from the console (just one agent and one worker process), collected statistics show rows for test "100" (the test encapsulating "page1" method) and tests "101", "102"... (tests encapsulating each HTTP request).
The problem I have is that statistics data for test "100" are always 0, although they should aggregate statistics from each sub test.
Note that it worked well with Jython 2.2.1 and the "old" instrumentation.
I have checked a couple of things:
- data collected by the worker (data-*.txt file) have no trace of the test "100" at all (only the subtests).
- I have tried to replace "instrumentMethod" (generated by TCPProxy with the standard httpToJythonScript.xsl transformation) in order to directly transform the bytecode of the "TestRunner.page1" method, but this didn't changed anything
- inside the page1 method, I have added a call to grinder.forCurrentTest and this immediately threw an InvalidContextException
Now I am surprised to see this behavior for such a common scenario, and I wonder if I have something wrong somewhere in my setup.
Is there someone out there, using grinder 3.4, jython 2.5.2, and scripts generated by TCPProxy, that could confirm or refute this behavior regarding this fact?
Or someone who knows about this problem and has found a way to work around it?
If this matters, I am using Java version 1.6.0_23 64 bits on a Windows Vista 7 machine.
Any help would be greatly appreciated.