Jenkins build is back to normal : JMeter-trunk #5583

[Apache Jenkins Server]

See 

Build failed in Jenkins: JMeter-trunk #5582

[Apache Jenkins Server]

See 

Changes:

[fschumacher] Require jdk 8+ for generating docs-api. Bugzilla Id: 60415

[fschumacher] 603982 Guard Exception handler of the JDBCSampler against null 
messages

--
[...truncated 2143 lines...]
Loop5 C1=2 C2=1 C3=6,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
If Test C1=2 C2=1 C3=6,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Loop3 C1=2 C2=1 C3=6,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Module,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Loop3 C1=2 C2=1 C3=6,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Module,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Loop3 C1=2 C2=1 C3=6,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Module,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Loop5 C1=2 C2=2 C3=7,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Loop5 C1=2 C2=3 C3=8,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Loop5 C1=2 C2=4 C3=9,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
If Test C1=2 C2=4 C3=9,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Loop3 C1=2 C2=4 C3=9,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Module,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Loop3 C1=2 C2=4 C3=9,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Module,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Loop3 C1=2 C2=4 C3=9,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Module,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Loop5 C1=2 C2=5 C3=10,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Java If once 1,,,Thread Group 1-1,text,false,,0,1,1,null,,1,1
Java If once 2,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Java If all 1,,,Thread Group 1-1,text,false,,0,1,1,null,,1,1
Java OK,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Java If once 1,,,Thread Group 1-1,text,false,,0,1,1,null,,1,1
Java If once 2,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Java If all 1,,,Thread Group 1-1,text,false,,0,1,1,null,,1,1
Java OK,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
Java 1 C1=1,200,OK,Thread Group 1-2,text,true,,10,1,1,null,,1,0
Java 1 C1=1,200,OK,Thread Group 1-2,text,true,,10,1,1,null,,1,0
Java 1 C1=1,200,OK,Thread Group 1-2,text,true,,10,1,1,null,,1,0
Loop5 C1=1 C2=1 C3=11,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop5 C1=1 C2=2 C3=12,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
If Test C1=1 C2=2 C3=12,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop3 C1=1 C2=2 C3=12,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Module,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop3 C1=1 C2=2 C3=12,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Module,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop3 C1=1 C2=2 C3=12,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Module,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop5 C1=1 C2=3 C3=13,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop5 C1=1 C2=4 C3=14,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop5 C1=1 C2=5 C3=15,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
If Test C1=1 C2=5 C3=15,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop3 C1=1 C2=5 C3=15,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Module,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop3 C1=1 C2=5 C3=15,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Module,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop3 C1=1 C2=5 C3=15,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Module,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Java If once 1,,,Thread Group 1-2,text,false,,0,1,1,null,,1,1
Java If once 2,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Java If all 1,,,Thread Group 1-2,text,false,,0,1,1,null,,1,1
Java OK,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Java If once 1,,,Thread Group 1-2,text,false,,0,1,1,null,,1,1
Java If once 2,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Java If all 1,,,Thread Group 1-2,text,false,,0,1,1,null,,1,1
Java OK,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Java 1 C1=2,200,OK,Thread Group 1-2,text,true,,10,1,1,null,,1,0
Java 1 C1=2,200,OK,Thread Group 1-2,text,true,,10,1,1,null,,1,0
Java 1 C1=2,200,OK,Thread Group 1-2,text,true,,10,1,1,null,,1,0
Loop5 C1=2 C2=1 C3=16,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop5 C1=2 C2=2 C3=17,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop5 C1=2 C2=3 C3=18,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
If Test C1=2 C2=3 C3=18,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop3 C1=2 C2=3 C3=18,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Module,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop3 C1=2 C2=3 C3=18,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Module,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop3 C1=2 C2=3 C3=18,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Module,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
Loop5 C1=2 C2=4 C3=19,200,OK,Thread 

Re: PR235 and matching behaviour

[Felix Schumacher]

Am 29.11.2016 um 20:26 schrieb Philippe Mouawad:

On Tue, Nov 29, 2016 at 8:24 PM, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:


Hi all,

I had a look at PR 235 and it addresses a valid bug. But I think the bug
goes a bit further than that.

The patch addresses the case, where the processor first matches multiple
things with JSON Processor and after that gets an empty input for the
matching. In that case JMeter will leave the old values in refname_matchNr
and refname_.

If on the other hand the first match is again a multi match and the second
gets processed with a matchnumber of "0". Then it gets a bit weird.
refname_matchNr will be set to the number of found elements, but no
elements will be stored in refname_.

Thinking about this, I believe the correct result in both cases would be
to have no refname_matchNr and no refname_ left in the vars.

What do you think?

I agree with your proposal
Ok, but when I implement the proposed behaviour, I get a unit test 
failure in TestJSONPostProcessor#testBug59609 where it is explicitly 
checked for refname_matchNr == 1 with matchnumber = "0".


I think the unit test is wrong and I would like to change it, to 
explicitly check that refname_matchNr is null.


What do you think?

Felix


Regards,

  Felix

Re: PR235 and matching behaviour

[Philippe Mouawad]

On Tue, Nov 29, 2016 at 8:24 PM, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

> Hi all,
>
> I had a look at PR 235 and it addresses a valid bug. But I think the bug
> goes a bit further than that.
>
> The patch addresses the case, where the processor first matches multiple
> things with JSON Processor and after that gets an empty input for the
> matching. In that case JMeter will leave the old values in refname_matchNr
> and refname_.
>
> If on the other hand the first match is again a multi match and the second
> gets processed with a matchnumber of "0". Then it gets a bit weird.
> refname_matchNr will be set to the number of found elements, but no
> elements will be stored in refname_.
>
> Thinking about this, I believe the correct result in both cases would be
> to have no refname_matchNr and no refname_ left in the vars.
>
> What do you think?
>
> I agree with your proposal

> Regards,
>
>  Felix
>
>


-- 
Cordialement.
Philippe Mouawad.

[GitHub] jmeter pull request #235: reset the matchNr and all the values, otherwise th...

[jfan288]

GitHub user jfan288 opened a pull request:

https://github.com/apache/jmeter/pull/235

reset the matchNr and all the values, otherwise the 'ForEach' compone…

reset all the values and the matchNr, otherwise the 'ForEach' component 
will reuse the values in the previous loop.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jfan288/jmeter trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jmeter/pull/235.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #235


commit 92a534f7785338e2cec1ca61daef98780451a962
Author: Qi Chen 
Date:   2016-11-29T08:14:54Z

reset the matchNr and all the values, otherwise the 'ForEach' component 
will reuse the values in the previous loop




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---