I believe there is a discrepancy - The context reads it from the thread
which is 0 based and the other from the name.
Its probably late to change this without potentially breaking backward
compatibility - perhaps a documentation update is better .
regards
deepak
On Wed, Sep 19, 2018 at 12:54 AM Ivan Rancati <ivan.ranc...@gmail.com>
wrote:
> As JMeter 5.0 has been released today, a quick update:
>
> the behaviour with the thread number is the same with JMeter 4.0 and 5.0. I
> tried both versions of JMeter on Linux with a mix of OpenJDK10, Oracle JDK
> 9 and Oracle JDK 10
>
> Thanks for the 5.0 release and best regards
>
> On Wed, Sep 19, 2018 at 8:00 AM Ivan Rancati <ivan.ranc...@gmail.com>
> wrote:
>
> > Good morning,
> >
> > I think that ctx.getThreadNum() returns a 0-based thread number, while
> the
> > variable __threadNum is 1-based.
> >
> > I have prepared test plan with a just a thread group, a constant
> > throughput timer and JSR223 sampler which just logs
> >
> > log.info("from ctx:"+ctx.getThreadNum())
> > log.info("from variable: ${__threadNum}")
> >
> > in jmeter.log I see for example for the first thread
> >
> > 2018-09-18 22:45:07,610 INFO o.a.j.t.JMeterThread: Thread started: Thread
> > Group 1-1
> > ...
> > 2018-09-18 22:45:08,085 INFO o.a.j.p.j.s.JSR223Sampler: from ctx:0
> > 2018-09-18 22:45:08,085 INFO o.a.j.p.j.s.JSR223Sampler: from variable: 1
> >
> > and so on. Am I reading incorrectly one of the two values?
> >
> > I thought, as the threads are numbered with <thread group starting from
> > 1>-<thread number starting from 1>
> > in jmeter.log, both values should be 1-based
> >
> > Thanks and best regards,
> > Ivan
> >
>
