https://issues.apache.org/bugzilla/show_bug.cgi?id=48286
Sandor <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #2 from Sandor <[email protected]> 2009-11-25 14:43:44 UTC ---
Well, dereferencing the delay value with a variable is a good workaround for
the case, although not an elegant solution of the problem, IMHO.
I can't see the point why were the timers designed that way, that their delay
values are not changeable directly on the gui, during a test on-the-fly. That's
why I assumed it was a bug.
The three Timer instance generation and the unnecessary method calls are just
an other issue. Currently they don't cause any problem, but I doubt they should
be created and called 5 times.
Anyway, regarding of the static delay value, the throughput timer behaves the
same way as the normal constant timer, its delay value is not changeable from
the GUI during a running test.
On the other hand you are right: in most cases the throughput timer is way much
useful timer than the constant timer.
As far as I see, the solution would be only that the clone() method of the
timer(s) does not clone the stored properties, but simply copies the reference
of the properties' map. But I accept if this modification is not acceptable,
since it might involve many other issues...
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.