|Summary:||Thread Group : Remove start and end date|
|Component:||Main||Assignee:||JMeter issues mailing list <issues>|
|Severity:||enhancement||CC:||dyptorden, p.mouawad, ra0077|
|Attachments:||An example of the problem|
Description toogoodtopassup 2017-09-20 15:12:05 UTC
When filling in a time for the Thread Group Scheduler Startup Delay, The UI auto fills in a Start and End time **EVEN IF YOU DELETE THE START AND END TIMES**. The auto fill-in happens when you tab to a different component or save the file. The documentation states that a Startup Delay should override the Start and End Times, however, at runtime JMeter attempts to validate the start and end times and (almost certainly) those dates are in the past, resulting in an error like this: =============================== ThreadGroup: An error occured scheduling delay start of threads for Thread Group: xxx org.apache.jorphan.util.JMeterStopTestException: End Time (2017/09/20 10:01:21) of Scheduler for Thread Group xxx is in the past, fix value of End Time field at org.apache.jmeter.threads.ThreadGroup$ThreadStarter.run(ThreadGroup.java:653) [ApacheJMeter_core.jar:3.2 r1790748] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_51] =============================== Expected behavior: * The UI should not auto fill-in the start and end times and allow the user to leave them blank. * If the start and end times are to be ignored because of other options, don't validate them because their 'validness' is a moving target - valid today and not tomorrow. * If the start and end times are invalid due to other options, typical UI behavior would be to grey out the time fields and make them non-editable. Nice to have: If the UI does not auto-fill in the start and end times, add a button that puts the current date and time into the field when the user wants it. But really, the start and end times should just be removed. Scheduling of this type would normally happen with some other tool (like Jenkins) that would schedule runs. Is there really a use case that involves having a file that with a hard-coded run time in it??
Comment 1 Antonio Gomes Rodrigues 2017-09-20 16:44:17 UTC
Hi, A few days ago we have discuss about it in jmeter dev list. For the moment we are releasing JMeter 3.3 and I will try to work on it after Antonio
Comment 2 Antonio Gomes Rodrigues 2017-09-20 18:29:01 UTC
Hi, For the moment to avoid problem, put end date to a far futur
Comment 3 Philippe Mouawad 2017-09-21 11:13:13 UTC
Hi, Also note that if you fillin rampup and duration, start and end date are not used. This is a preferable approach IMO. Regards
Comment 4 Antonio Gomes Rodrigues 2017-09-21 17:47:49 UTC
Hi Philippe, I don't have check the source code yet, but in 3.2 and 3.3 It don't work In my test plan I have : A thread group with duration + rampup => no problem A thread group with rampup + loop count =1 + startup delay => Ko T=In the second thread group which is KO, I want just to execute 1 VU for 1 iteration with a startup delay I need to test it in old JMeter release because I don't remember to have this behaviour Antonio
Comment 5 Antonio Gomes Rodrigues 2017-09-21 17:54:22 UTC
Created attachment 35358 [details] An example of the problem I have attached a test plan which reproduce the problem. I have tested it and we don't have this problem with 3.0 release It appear in 3.1 release Antonio
Comment 6 Philippe Mouawad 2017-09-23 19:15:50 UTC
I would support removal of start and end date.
Comment 7 toogoodtopassup 2017-09-26 21:49:22 UTC
Removing the start and end date seems like the cleanest and best solution to this issue. Other than a very obvious anti-pattern solution, what would be a use case for having a scheduled start and end date in a script?
Comment 8 Philippe Mouawad 2017-09-27 19:32:22 UTC
Author: pmouawad Date: Wed Sep 27 19:31:38 2017 New Revision: 1809907 URL: http://svn.apache.org/viewvc?rev=1809907&view=rev Log: Bug 61549 - Thread Group : Remove start and end date Bugzilla Id: 61549 Modified: jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties jmeter/trunk/src/core/org/apache/jmeter/resources/messages_de.properties jmeter/trunk/src/core/org/apache/jmeter/resources/messages_es.properties jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties jmeter/trunk/src/core/org/apache/jmeter/resources/messages_ja.properties jmeter/trunk/src/core/org/apache/jmeter/resources/messages_no.properties jmeter/trunk/src/core/org/apache/jmeter/resources/messages_pl.properties jmeter/trunk/src/core/org/apache/jmeter/resources/messages_pt_BR.properties jmeter/trunk/src/core/org/apache/jmeter/resources/messages_tr.properties jmeter/trunk/src/core/org/apache/jmeter/resources/messages_zh_CN.properties jmeter/trunk/src/core/org/apache/jmeter/resources/messages_zh_TW.properties jmeter/trunk/src/core/org/apache/jmeter/threads/ThreadGroup.java jmeter/trunk/src/core/org/apache/jmeter/threads/gui/ThreadGroupGui.java jmeter/trunk/xdocs/changes.xml jmeter/trunk/xdocs/usermanual/component_reference.xml
Comment 9 toogoodtopassup 2017-10-05 14:23:07 UTC
Presumably if the scheduling feature is removed, JMeter should gracefully ignore scheduling data if it is present.