DO NOT REPLY [Bug 48889] Wrong response time with mode=Statistical and num_sample_threshold 1
https://issues.apache.org/bugzilla/show_bug.cgi?id=48889 --- Comment #1 from JottKa j.kalsb...@jk-itberatung.de 2010-03-11 12:57:40 UTC --- Created an attachment (id=25115) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25115) proposed patch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org
DO NOT REPLY [Bug 48889] Wrong response time with mode=Statistical and num_sample_threshold 1
https://issues.apache.org/bugzilla/show_bug.cgi?id=48889 --- Comment #3 from JottKa j.kalsb...@jk-itberatung.de 2010-03-11 15:55:35 UTC --- (In reply to comment #2) Thanks for the suggested patch, which should help. However, I think the threadGroup is still needed, otherwise unrelated threads in different thread groups will be aggregated, leading to the same problem. Yes but at least with the current implementation the event.getResult().getThreadName() call already contains the threadGroup name. A typical key would be NameOfSampler-NameOfThreadGroup 1-10. I just verified the proper working with two threadgroups. But an explicit call to getThreadGroup would make it more robust. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org
DO NOT REPLY [Bug 48889] Wrong response time with mode=Statistical and num_sample_threshold 1
https://issues.apache.org/bugzilla/show_bug.cgi?id=48889 Sebb s...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Sebb s...@apache.org 2010-03-11 23:40:11 UTC --- Turns out that the problem was not really due to aggregating across thread groups. The StatisticalSampleResult now maintains the elapsed time directly, rather than trying to fake it by setting the start and end times. See: URL: http://svn.apache.org/viewvc?rev=922072view=rev Log: Bug 48889 - Wrong response time with mode=Statistical and num_sample_threshold 1 See also SVN revisions: 922069,922067,922055,922054,922051 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org
