Bug 61549

Summary:	Thread Group : Remove start and end date
Product:	JMeter - Now in Github	Reporter:	toogoodtopassup
Component:	Main	Assignee:	JMeter issues mailing list <issues>
Status:	RESOLVED FIXED
Severity:	enhancement	CC:	dyptorden, p.mouawad, ra0077
Priority:	P2
Version:	3.3
Target Milestone:	---
Hardware:	All
OS:	All
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.

Comment 10 Philippe Mouawad 2019-03-04 10:40:46 UTC

*** Bug 57689 has been marked as a duplicate of this bug. ***

Comment 11 The ASF infrastructure team 2022-09-24 20:38:10 UTC

This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/4501