DO NOT REPLY [Bug 12000] New: - Bogus "No of samples" output in Graph Results

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12000>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12000

Bogus "No of samples" output in Graph Results

           Summary: Bogus "No of samples" output in Graph Results
           Product: JMeter
           Version: Nightly (Please specify date)
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Minor
          Priority: Other
         Component: Main
        AssignedTo: jmeter-dev@jakarta.apache.org
        ReportedBy: eric_97@pobox.com


Version: CVS, 23-Aug-2002, 19:15 (and for several preceding weeks at least)

[I mentioned this a while ago on jmeter-user (7-Aug-2002).  I now
have a bit more information, so it seems worth filing a bug
report.]

If I watch the Graph Results display during a test run, the "No
of Samples" counts up nicely for the most part, but occasionally
it'll display a huge, many-digit number very briefly, then go
back to (as far as I can tell) where it should be.  Something
like:
        318
        319
        320
        323322321
        324
        325

I just made those numbers up; they are NOT an accurate replay of
an example I've seen, since the values flip by too quickly to
make that possible.

The bogus sample "numbers" seem to be the string-concatenation of
a few legitimate values.  I'll punctuate the example:
        318
        319
        320
        323.322.32[1]
        [324]
        [325]

The "."s are just for readability.  The "[]"s indicate values
I've guessed at, and which thus shouldn't be trusted too much:
  - I don't know that the sequence picks up where it should (at
    324 in this case), again because the numbers aren't on the
    screen long enough for me to tell

  - The sample-number field clips after 8 digits, so I'm guessing
    at the last digit of the bogus value.  For all I know, it might
    sometimes be even longer before clipping:
        320
        325.324.32[3.322.321]
        [326]

FWIW, it once happened that the test run ended with a bogus value
still displayed:
        797
        800.799.79[8]
where the total sample count expected was 800.  Random chance,
I presume...
  
I've often seen them in decreasing order as shown above; I can't
recall whether I've also seen them in increasing order:
        321.322.32[3]

This seems to happen more (or exclusively?) with a high number of
threads.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>