On 09/04/2008, Steve Kapinos <[EMAIL PROTECTED]> wrote:
> Gotcha.. Read that but even tho it specifically says UDV I didn't
> connect the two breezing right by the specific example given! For some
> reason thought it was referening to the configuration fields of the
> elements rather then the entire thing. Stupid me.
>
> I've gotten the behavior desired by using a User Paremeter and the
> increment checkbox enabled.
>
> It looks like this now
>
> > Thread Plan
> > UDV
> > User parameter where vcsCount = ${__threadNum}
>
> > CSV
> > Loop Controller
> > Simple Controllers
> > Sampler
> > Timer
> > [..]
> > Simple Data Writer
> > Debug Sampler
> > View Results Tree
>
>
> Now if I run the loop 2 times and run with 3 users, I get the desired
> effect of having the same vcsCount value used multiple times within a
> thread without incrementing - and each thread has its own vcsCount that
> doesn't overlap with the other threads. 1, 2, 3, etc
>
> A small tip found for future idiots like me (maybe should be noted in
> documentation?) is that function names seem to be case sensative where
> variables are not?
>
They are both case-sensitive.
>
> -Steve
>
>
> -----Original Message-----
> From: sebb [mailto:[EMAIL PROTECTED]
>
> Sent: Wednesday, April 09, 2008 9:21 AM
> To: JMeter Users List
> Subject: Re: Help with __counter function
>
> On 09/04/2008, Steve Kapinos <[EMAIL PROTECTED]> wrote:
> > I tried using a UDV simply setting vcsCount = ${__threadNum} in the
> > start of my thread group.
> >
>
> See:
>
> http://jakarta.apache.org/jmeter/usermanual/functions.html#__threadNum
>
> which says:
>
> "This function does not work in any Configuration elements (e.g. User
> Defined Variables) as these are run from a separate thread."
>
> > The test plan is setup with a single thread group, several
> > configuration elements, followed by a logic controller which includes
>
> > all the samplers, followed by the listeners for reporting/debugging.
> >
> > Thread Plan
> > UDV
> > UDV
> > CSV
> > Loop Controller
> > Simple Controllers
> > Sampler
> > Timer
> > [..]
> > Simple Data Writer
> > Debug Sampler
> > View Results Tree
> >
> > But I noticed two behaviors..
> >
> > threadNum I guess increments with total threads since the jmeter
> > instance started.. It did not correlate to 'thread 1', 'thread 2',
> > etc like I expected for each run, but rather 'thread 38' or something
>
> > since the jmeter instance started (testing in GUI).
>
> See above.
>
> > While variables are supposed to be local to a thread only - if I told
>
> > the thread group to run 3 times (3 'users').. The debug sampler showed
>
> > vcscount = to the same value for all three thread instances.
> >
> > Is __threadNum simply not usable and not the same as 'user1' 'user2'
> > 'user3' meaning of 'thread' ?
> >
> > I will try with a user paremeter similar to your suggestion now
> >
> >
> > -----Original Message-----
> > From: sebb [mailto:[EMAIL PROTECTED]
> >
> > Sent: Wednesday, April 09, 2008 8:16 AM
> > To: JMeter Users List
> >
> > Subject: Re: Help with __counter function
> >
> > On 09/04/2008, Steve Kapinos <[EMAIL PROTECTED]> wrote:
> > > Any help sebb? I know what I want is simple, just I'm stupid and
> > > can't figure out how to do it right.
> >
> > It does not seem to be simple...
> >
> > Try using the counter in a User Parameters Pre-Processor as a child
> > of the first sampler - that will run once.
> >
> > > It's a counter simply shared by all threads, but I want to
> > increment
> >
> > > once at the start of each thread and then be able to reference that
>
> > > instance of the count value throughout the thread.
> >
> > Understood.
> >
> > >
> > > -----Original Message-----
> > > From: Steve Kapinos
> > > Sent: Tuesday, April 08, 2008 8:07 PM > To: JMeter Users List >
>
> > > Subject: RE: Help with __counter function > > Rather simple in
> > the practical sense..
> > >
> > > I need each thread to use a different number for each pass that
> > will > not overlap with the other threads executing.
> > >
> > > One thread could use '1' for its first pass second thread could
> > use '2'
> > > for its first pass
> > >
> > > On the second pass, they need to use a new number, as to prevent
> > > possible overlap with another thread that is still running.
> > >
> > > So I have a UDV at the start of a thread defining a count,
> vcsCount.
> > > The thread uses that variable in the rest of the thread group as
> > the
> >
> > > unique variable... with the hope that each time a pass through the
>
> > > thread group is executed, the count is incremented.
> > >
> > > Thinking out loud now.. I guess that should be a User Parameter
> > that
> >
> > > should have the checkbox marked instead of a UDV shouldn't I? But
> > I > don't understand why the current implementation seems to
> > increment > everytime vcsCount is referenced.
> > >
> > >
> > > -----Original Message-----
> > > From: sebb [mailto:[EMAIL PROTECTED]
> > > Sent: Tue 4/8/2008 6:35 PM
> > > To: JMeter Users List
> > > Cc:
> > > Subject: Re: Help with __counter function
> > >
> > > What do you mean by "unique per thread"?
> > >
> > > If there are two threads, unique per thread could mean that they
> > each
> >
> > > see the same unique set of numbers, or that each thread sees
> > numbers > that are different from the numbers seen in all other
> threads.
> > >
> > >
> > > On 08/04/2008, Steve Kapinos <[EMAIL PROTECTED]> wrote:
> > > > I'm trying to create an integeter that is going to be unique per
>
> > > thread.
> > > >
> > > > I have a UDV element defining
> > > >
> > > > vcsGlobalCount ${__counter(FALSE,vcsCount)} > > However,
> > each > time vcsCount is referenced, that seems to increment > the
> counter.
> >
> > > I would have thought the counter would only increment > when the
> > UDV
> >
> > > element was ran.. Each time a thread starts.
> > > >
> > > > What is the proper way of handling a counter like this that
> > should
> >
> > > be
> > >
> > > > unique per thread in this fashion?
> > > >
> > > > Thx
> > > >
> > > > -Steve
> > > >
> > > >
> > > >
> > >
> > ---------------------------------------------------------------------
> > > > 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]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
>
> ---------------------------------------------------------------------
> 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]
