It's alright if two threads share a token, in fact it's probably preferable
for that to be part of my test since I'd expect to see that from real users.
I still don't see how I can write to a CSV, however. I was able to get it
to write 1 CSV file per token, but I'm not really interested in having my
folder get filled up with numbered csv files. I was hoping to have it all
in one CSV.
As for sharing within a thread, this still isn't working for me, so I guess
that's what I need help with. Here's how my setup looks.
ThreadGroup
-BSF PreProcessor or Sampler (javascript) -> var myArray = new Array();
vars.putObject("myArray",myArray);
-Loop Controller -> 5 loops
--HTTP Sampler
---Regex postprocessor -> Reference Name = myToken
---BSF postprocessor - > var myArray = vars.getOject("myArray");
myArray.push(myToken); vars.putObject("myArray",myArray);
-BSF Sampler -> var myArray = vars.getObject("myArray"); //At this point,
I expect myArray.length to be 5. Instead it is 0.
Right now I'm taking the approach of serializing into a comma
delimitted string and storing it in props, but that just feels wrong to me.
Sebb, when you say "iteratively create a jmeter array", what do you mean?
Is there some other data structure that I'm completely missing? I thought
the only way you could get a jmeter array was if your single regular
expression returned multiple matching groups... rather than having multiple
runs of a thread or a loop add on to an existing array. If there's some
way to do that, I would love to know.
-Eric
On Fri, Feb 10, 2012 at 8:50 AM, sebb <[email protected]> wrote:
> On 10 February 2012 16:26, Bruce Ide <[email protected]> wrote:
> > In the same thread you can use vars.putObject in a bsf or beanshell
> sampler
> > to store an array in a variable. Or you can just iteratively create a
> > jmeter array.
> >
> > I wrote an addon to allow sharing across threads, see
> > https://github.com/FlyingRhenquest/JmeterThreadGlobal. It's a pretty
> simple
> > addon and isn't currently set up to share arbitrary objects, but it
> should
> > be easy to modify to do that.
> >
> > If you used the new setup things you shouldn't have to synchronize
> between
> > the threads. If it turns out you need to, you can use a synchronizing
> timer
> > or my thread synchronization sampler (Which is also on github.)
> >
> > All this does add quite a bit of complexity to the test though, so if
> > you're ever going to need to explain it to another tester you might want
> to
> > simplify your test design.
>
> Very good point.
>
> Why not create CSV data files containing the tokens in a separate test
> phase?
> You can then randomise the data file if you want.
>
> By the way, you say each thread picks a random token.
> If you have multiple threads, a simple random choice will sometimes
> result in two threads having the same token.
> Is that allowed? If not, the token entries will have to be marked as
> used; this will necessarily entail synchronising across threads.
>
> The CSV data file can be set to only be used once; threads cannot then
> get the same token (unless it is duplicated in the file).
>
> If you have hundreds or thousands of tokens, using a data file is the way
> to go.
>
> > --
> > Bruce Ide
> > [email protected]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
