Mailing-List: contact issues-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@jmeter.apache.org
From: bugzilla@apache.org
To: issues@jmeter.apache.org
Subject: [Bug 61549] New: Not possible to use Thread Group Scheduler Delay
Date: Wed, 20 Sep 2017 15:12:05 +0000
Message-ID: <bug-61549-58895@https.bz.apache.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Auto-Submitted: auto-generated
MIME-Version: 1.0
archived-at: Wed, 20 Sep 2017 15:12:14 -0000

https://bz.apache.org/bugzilla/show_bug.cgi?id=3D61549

            Bug ID: 61549
           Summary: Not possible to use Thread Group Scheduler Delay
           Product: JMeter
           Version: 3.2
          Hardware: Macintosh
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Main
          Assignee: issues@jmeter.apache.org
          Reporter: toogoodtopassup@gmail.com
  Target Milestone: ---

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 ti=
mes
and (almost certainly) those dates are in the past, resulting in an error l=
ike
this:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
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 fie=
ld
        at
org.apache.jmeter.threads.ThreadGroup$ThreadStarter.run(ThreadGroup.java:65=
3)
[ApacheJMeter_core.jar:3.2 r1790748]
        at java.lang.Thread.run(Thread.java:745) [?:1.8.0_51]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D

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, do=
n'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??

--=20
You are receiving this mail because:
You are the assignee for the bug.=