Bug 61549 - Thread Group : Remove start and end date
Summary: Thread Group : Remove start and end date
Status: RESOLVED FIXED
Alias: None
Product: JMeter
Classification: Unclassified
Component: Main (show other bugs)
Version: 3.3
Hardware: All All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-20 15:12 UTC by toogoodtopassup
Modified: 2017-10-05 14:23 UTC (History)
2 users (show)



Attachments
An example of the problem (30.34 KB, application/xml)
2017-09-21 17:54 UTC, Antonio Gomes Rodrigues
Details

Note You need to log in before you can comment on or make changes to this bug.
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.