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
