The thread count in ThreadGroup is only going to work for static
variables - ie, nothing that changes during a test run will work here.
the reason is the variable is resolved at compile time, not runtime. If
it doesn't have a value at that time, it will never be checked again.
This means only jmeter properties and TestPlan variables will have an
effect here. Just like listener filenames.
-Mike
On Thu, 2005-06-02 at 10:21 +0200, Sander Stevens wrote:
> Hi Sebb,
>
> Sounds promising.
> I did some testing, but without luck.
> What I do is the following:
>
> In my user parameters I add one line with the variable name (rows) and
> the __csvread to my csv file. The first column has the row count. So my
> syntax is: ${__CSVRead(c:\temp\migration.csv,0)}
> Secondly I use the variable in the Thread Group window.
> Number of Threads: ${rows}
> Ramp-up period: 50
>
> My script doesn't work anymore now. No result. Will stop directly.
>
> In the log I see the following:
> 2005/06/02 10:18:34 INFO - jmeter.functions.FileWrapper: Attaching
> c:\temp\Migratie.csv
> 2005/06/02 10:18:34 INFO - jmeter.functions.FileWrapper: Opening
> c:\temp\Migratie.csv as c:\temp\Migratie.csv
> 2005/06/02 10:18:34 INFO - jmeter.functions.FileWrapper: Saved
> c:\temp\Migratie.csv as c:\temp\Migratie.csv delimiter=<;>
> 2005/06/02 10:18:34 INFO - jmeter.functions.FileWrapper: Stored
> c:\temp\Migratie.csv as c:\temp\Migratie.csv
> 2005/06/02 10:18:34 INFO - jmeter.engine.StandardJMeterEngine: Starting
> 0 threads for group ADSL. Ramp up = 50.
>
> The version of JMeter I am using is: 20050508 (internal version)
>
> Any ideas?
>
> Sander
>
> -----Original Message-----
> From: sebb [mailto:[EMAIL PROTECTED]
> Sent: donderdag 2 juni 2005 1:37
> To: JMeter Users List
> Subject: Re: Variable use in 'number of threads'?
>
> It's certainly possible to use a property to specify the number of
> threads.
> So functions work, i.e. CSVRead will work.
>
> The count should be placed in the first row of the CSV file.
>
> Try the following (tested):
>
> ${__CSVRead(test.txt,0)}${__CSVRead(test.txt,next)}
>
> Should also work for the ramp-up loop count if needed (not tested).
> There is no guarantee that fields will be read in the same order in
> each release, so all the values must be columns in the first row.
> And you will either need to experiment to find which field should have
> the "next" in it, or put it as the first entry in the UP
> Pre-Processor.
>
> The rest of the file can then be read in a User Parameters (UP)
> Pre-processor or in samplers etc.
>
> But it may be simpler to pass in the thread group settings as
> properties, so you can use the same test file for different
> variations, e.g.
>
> 1 thread, 10 loops
> 2 threads 5 loops
> etc
>
> S.
> On 6/1/05, Sander Stevens <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Maybe a nice idea (because I think it is not possible yet):
> >
> > I am using JMeter as a functional test tool with Excel (csv) as input
> for my test cases. In this way I have to set the number of threads to
> the number of rows in my excel sheet. No problem, but it would be nice
> if this is filled automatically. Just to follow the excel sheet, even if
> there are test cases (rows) added or deleted. The way I am thinking is
> the following: I count the rows in the excel sheet (excel function
> COUNT). Place the number of rows somewhere in the sheet, read this value
> with function __CSVRead (e.g. rows) and use this value to notify the
> number of threads (${rows}).
> >
> > Would that be a nice feature?
> >
> >
> >
> > Met Vriendelijke Groet,
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
