DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=44374>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=44374 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Additional Comments From [EMAIL PROTECTED] 2008-02-07 08:24 ------- At least, the following statement is wrong (IMHO): long msPerRequest = (long) (MILLISEC_PER_MIN / getThroughput()); the result shoud be of floating point type (i.e. double), NOT integer (long) and ONLY after in subsequent calculations like: delay = JMeterContextService.getNumberOfThreads() * msPerRequest; it is OK to cast floating point result to cast to integer (of long type). Otherwise, all the requested throughputs more than 60000 will result to zero dalay for every interation. But 60000 samples per minute not to much, especially if you configure this throughput for all threads! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
