You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by "Robert M. Mather" <ro...@gmail.com> on 2015/02/21 01:22:20 UTC

Possible ForEach controller bug, more likely I'm using it wrong

This behavior is completely repeatable and hinges on a single change. If I
use a previously bound variable for the "End index..." field (*OrderNums* in
this case) the ForEach controller doesn't fire, if I use a constant number,
it does.

Here's the failing thread group sequence:

   1. fetch 0 or more rows of data via JDBC
   2. bind one column of results with "Variable Names" field set to:
   *,,OrderNums,,,,,,,,,,*
   3. ForEach controller with:
      1. "Input variable prefix" = *OrderNums*
      2. "Start index..." = 0
      3. "End index..." = *${OrderNums_#}*
      4. "Output variable name" = *order_num*
      5. "Add '_' before number ?" = true
   4. (nested under the ForEach controller) JDBC update statement using
   *${order_num}* in the WHERE clause

Step 4 never executes even when I'm sure that step 1 is returning several
rows. If I change the setting in 3.3 to be "End index..." = *999* (or any
other number that I'm sure is bigger than the result set will ever be) then
everything executes exactly as I'd expect.

Here's the strange part that makes me think it might be a bug. The system
I'm testing has both old orders and simultaneously new orders arrive and
are processed, so I have a setUp Thread Group that populates the table with
old orders before anything else, and then a normal Thread Group that writes
new orders concurrently with the process detailed above. With "End
index..." = *${OrderNums_#}*, the old orders inserted by the setUp group
always trigger the ForEach controller, while those placed by the concurrent
process never do. Even if there's something going on with jdbc transactions
and thread groups that I'm not aware of, it doesn't make sense because
theres nothing structurally different about the old and new orders, just
which thread group inserts them.

Unless someone can point me to what I'm doing wrong, I'll file a bug report
with more detailed info.

Thanks,

Robert

Re: Possible ForEach controller bug, more likely I'm using it wrong

Posted by Philippe Mouawad <ph...@gmail.com>.
Hello,
I don't understand what is "${OrderNums_#}" in End index field ?

Is it supposed to be the numbers of orders ?
I suggest you add a Debug Sampler before ForEachCOntroller to see its value.
Because I tested from your explanation and it works.
If issue persists, open a bug with attached simplified test plan.

Thanks
Regards



On Sat, Feb 21, 2015 at 1:22 AM, Robert M. Mather <
robert.mather.rmm@gmail.com> wrote:

> This behavior is completely repeatable and hinges on a single change. If I
> use a previously bound variable for the "End index..." field (*OrderNums*
> in
> this case) the ForEach controller doesn't fire, if I use a constant number,
> it does.
>
> Here's the failing thread group sequence:
>
>    1. fetch 0 or more rows of data via JDBC
>    2. bind one column of results with "Variable Names" field set to:
>    *,,OrderNums,,,,,,,,,,*
>    3. ForEach controller with:
>       1. "Input variable prefix" = *OrderNums*
>       2. "Start index..." = 0
>       3. "End index..." = *${OrderNums_#}*
>       4. "Output variable name" = *order_num*
>       5. "Add '_' before number ?" = true
>    4. (nested under the ForEach controller) JDBC update statement using
>    *${order_num}* in the WHERE clause
>
> Step 4 never executes even when I'm sure that step 1 is returning several
> rows. If I change the setting in 3.3 to be "End index..." = *999* (or any
> other number that I'm sure is bigger than the result set will ever be) then
> everything executes exactly as I'd expect.
>
> Here's the strange part that makes me think it might be a bug. The system
> I'm testing has both old orders and simultaneously new orders arrive and
> are processed, so I have a setUp Thread Group that populates the table with
> old orders before anything else, and then a normal Thread Group that writes
> new orders concurrently with the process detailed above. With "End
> index..." = *${OrderNums_#}*, the old orders inserted by the setUp group
> always trigger the ForEach controller, while those placed by the concurrent
> process never do. Even if there's something going on with jdbc transactions
> and thread groups that I'm not aware of, it doesn't make sense because
> theres nothing structurally different about the old and new orders, just
> which thread group inserts them.
>
> Unless someone can point me to what I'm doing wrong, I'll file a bug report
> with more detailed info.
>
> Thanks,
>
> Robert
>



-- 
Cordialement.
Philippe Mouawad.