Update Once Per Iteration reverses execution sequence of Preprocessors

[minerva001]

Didn't got a reply on the user list, hoping to get some help from the devs.

I noticed when having in a simple controller with several User Parameters
(Preprocessors) with the "Update Once Per Iteration" flag marked, that the
Preprocessors are run in reverse order.

 Simple Controller
  User Parameter
P XX
Q${Q}q1
  User Parameter
P1  ${P}
Q   ${Q}q2
  Debug Sampler


In case "Update Once Per Iteration" is marked, P1=${P}, Q=${Q}q2q1
When not marked, P1=XX, Q=${Q}q1q2

Why does "Update Once Per Iteration" reverses the execution sequence of
Preprocessors?
Is this behavior intended and somewhere documented?

Re: Update Once Per Iteration reverses execution sequence of Preprocessors

[jmeter tea]

User parameters are strictly hierarchical
But when checking Update Once Per Iteration it saves before iteration the
variables beforehand
So that second User Parameter will have P as not exists variable and Q as
defined in its own declaration
and therefore:
P1  is saved as ${P} , Q is saved as ${Q}q2
Now User Parameter 1 will update Q  =  ${Q}q1
and  User Parameter 2 will update Q =  ${Q}q1q2 where ${Q}q1 is the stored
variable

It sounds like a bug, but this is the flow.

On Wed, Nov 15, 2017 at 10:15 AM, minerva001  wrote:

> Didn't got a reply on the user list, hoping to get some help from the devs.
>
> I noticed when having in a simple controller with several User Parameters
> (Preprocessors) with the "Update Once Per Iteration" flag marked, that the
> Preprocessors are run in reverse order.
>
>  Simple Controller
>   User Parameter
> P XX
> Q${Q}q1
>   User Parameter
> P1  ${P}
> Q   ${Q}q2
>   Debug Sampler
>
>
> In case "Update Once Per Iteration" is marked, P1=${P}, Q=${Q}q2q1
> When not marked, P1=XX, Q=${Q}q1q2
>
> Why does "Update Once Per Iteration" reverses the execution sequence of
> Preprocessors?
> Is this behavior intended and somewhere documented?
>
>

[GitHub] jmeter issue #330: Remove Workbench

[codecov-io]

Github user codecov-io commented on the issue:

https://github.com/apache/jmeter/pull/330
  
# [Codecov](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=h1) 
Report
> Merging 
[#330](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=desc) into 
[trunk](https://codecov.io/gh/apache/jmeter/commit/2628269bce667670456bf57bbd6f6a6310683aa8?src=pr&el=desc)
 will **increase** coverage by `<.01%`.
> The diff coverage is `33.33%`.

[![Impacted file tree 
graph](https://codecov.io/gh/apache/jmeter/pull/330/graphs/tree.svg?height=150&token=6Q7CI1wFSh&width=650&src=pr)](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=tree)

```diff
@@ Coverage Diff  @@
##  trunk #330  +/-   ##

+ Coverage 57.82%   57.83%   +<.01% 
  Complexity 9937 9937  

  Files  1141 1141  
  Lines 7322773235   +8 
  Branches   7305 7307   +2 

+ Hits  4234742352   +5 
  Misses2841328413  
- Partials   2467 2470   +3
```


| [Impacted 
Files](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=tree) | Coverage 
Δ | Complexity Δ | |
|---|---|---|---|
| 
[...pache/jmeter/protocol/http/proxy/ProxyControl.java](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=tree#diff-c3JjL3Byb3RvY29sL2h0dHAvb3JnL2FwYWNoZS9qbWV0ZXIvcHJvdG9jb2wvaHR0cC9wcm94eS9Qcm94eUNvbnRyb2wuamF2YQ==)
 | `23.58% <ø> (+0.1%)` | `64 <0> (ø)` | :arrow_down: |
| 
[...re/org/apache/jmeter/control/gui/WorkBenchGui.java](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=tree#diff-c3JjL2NvcmUvb3JnL2FwYWNoZS9qbWV0ZXIvY29udHJvbC9ndWkvV29ya0JlbmNoR3VpLmphdmE=)
 | `65.71% <ø> (ø)` | `6 <0> (ø)` | :arrow_down: |
| 
[.../core/org/apache/jmeter/gui/action/CheckDirty.java](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=tree#diff-c3JjL2NvcmUvb3JnL2FwYWNoZS9qbWV0ZXIvZ3VpL2FjdGlvbi9DaGVja0RpcnR5LmphdmE=)
 | `0% <ø> (ø)` | `0 <0> (ø)` | :arrow_down: |
| 
[src/core/org/apache/jmeter/gui/action/Move.java](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=tree#diff-c3JjL2NvcmUvb3JnL2FwYWNoZS9qbWV0ZXIvZ3VpL2FjdGlvbi9Nb3ZlLmphdmE=)
 | `0% <0%> (ø)` | `0 <0> (ø)` | :arrow_down: |
| 
[...c/core/org/apache/jmeter/gui/util/MenuFactory.java](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=tree#diff-c3JjL2NvcmUvb3JnL2FwYWNoZS9qbWV0ZXIvZ3VpL3V0aWwvTWVudUZhY3RvcnkuamF2YQ==)
 | `0% <0%> (ø)` | `0 <0> (ø)` | :arrow_down: |
| 
[...meter/protocol/http/proxy/gui/ProxyControlGui.java](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=tree#diff-c3JjL3Byb3RvY29sL2h0dHAvb3JnL2FwYWNoZS9qbWV0ZXIvcHJvdG9jb2wvaHR0cC9wcm94eS9ndWkvUHJveHlDb250cm9sR3VpLmphdmE=)
 | `62.31% <0%> (ø)` | `27 <0> (ø)` | :arrow_down: |
| 
[src/core/org/apache/jmeter/gui/action/Load.java](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=tree#diff-c3JjL2NvcmUvb3JnL2FwYWNoZS9qbWV0ZXIvZ3VpL2FjdGlvbi9Mb2FkLmphdmE=)
 | `6.66% <0%> (ø)` | `1 <0> (ø)` | :arrow_down: |
| 
[src/core/org/apache/jmeter/gui/action/Save.java](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=tree#diff-c3JjL2NvcmUvb3JnL2FwYWNoZS9qbWV0ZXIvZ3VpL2FjdGlvbi9TYXZlLmphdmE=)
 | `13.92% <0%> (+0.75%)` | `4 <0> (ø)` | :arrow_down: |
| 
[...ore/org/apache/jmeter/control/gui/TestPlanGui.java](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=tree#diff-c3JjL2NvcmUvb3JnL2FwYWNoZS9qbWV0ZXIvY29udHJvbC9ndWkvVGVzdFBsYW5HdWkuamF2YQ==)
 | `62.85% <0%> (-0.92%)` | `6 <0> (ø)` | |
| 
[...re/org/apache/jmeter/gui/tree/JMeterTreeModel.java](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=tree#diff-c3JjL2NvcmUvb3JnL2FwYWNoZS9qbWV0ZXIvZ3VpL3RyZWUvSk1ldGVyVHJlZU1vZGVsLmphdmE=)
 | `43.69% <44.73%> (-4.18%)` | `13 <4> (+2)` | |
| ... and [1 
more](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=tree-more) | |

--

[Continue to review full report at 
Codecov](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=continue).
> **Legend** - [Click here to learn 
more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute  (impact)`, `ø = not affected`, `? = missing 
data`
> Powered by 
[Codecov](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=footer). Last 
update 
[2628269...9a5e890](https://codecov.io/gh/apache/jmeter/pull/330?src=pr&el=lastupdated).
 Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).



---

[GitHub] jmeter issue #329: Expansion of "Add expand/collapse all menu in render XML ...

[codecov-io]

Github user codecov-io commented on the issue:

https://github.com/apache/jmeter/pull/329
  
# [Codecov](https://codecov.io/gh/apache/jmeter/pull/329?src=pr&el=h1) 
Report
> Merging 
[#329](https://codecov.io/gh/apache/jmeter/pull/329?src=pr&el=desc) into 
[trunk](https://codecov.io/gh/apache/jmeter/commit/2628269bce667670456bf57bbd6f6a6310683aa8?src=pr&el=desc)
 will **decrease** coverage by `0.03%`.
> The diff coverage is `3.22%`.

[![Impacted file tree 
graph](https://codecov.io/gh/apache/jmeter/pull/329/graphs/tree.svg?width=650&height=150&src=pr&token=6Q7CI1wFSh)](https://codecov.io/gh/apache/jmeter/pull/329?src=pr&el=tree)

```diff
@@ Coverage Diff  @@
##  trunk #329  +/-   ##

- Coverage 57.82%   57.79%   -0.04% 
+ Complexity 9937 9936   -1 

  Files  1141 1141  
  Lines 7322773274  +47 
  Branches   7305 7310   +5 

- Hits  4234742346   -1 
- Misses2841328461  +48 
  Partials   2467 2467
```


| [Impacted 
Files](https://codecov.io/gh/apache/jmeter/pull/329?src=pr&el=tree) | Coverage 
Δ | Complexity Δ | |
|---|---|---|---|
| 
[...nts/org/apache/jmeter/visualizers/RenderAsXML.java](https://codecov.io/gh/apache/jmeter/pull/329?src=pr&el=tree#diff-c3JjL2NvbXBvbmVudHMvb3JnL2FwYWNoZS9qbWV0ZXIvdmlzdWFsaXplcnMvUmVuZGVyQXNYTUwuamF2YQ==)
 | `4.8% <3.22%> (-2.9%)` | `3 <1> (ø)` | |
| 
[...c/core/org/apache/jmeter/reporters/Summariser.java](https://codecov.io/gh/apache/jmeter/pull/329?src=pr&el=tree#diff-c3JjL2NvcmUvb3JnL2FwYWNoZS9qbWV0ZXIvcmVwb3J0ZXJzL1N1bW1hcmlzZXIuamF2YQ==)
 | `85.38% <0%> (-0.77%)` | `18% <0%> (-1%)` | |

--

[Continue to review full report at 
Codecov](https://codecov.io/gh/apache/jmeter/pull/329?src=pr&el=continue).
> **Legend** - [Click here to learn 
more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute  (impact)`, `ø = not affected`, `? = missing 
data`
> Powered by 
[Codecov](https://codecov.io/gh/apache/jmeter/pull/329?src=pr&el=footer). Last 
update 
[2628269...f8c7a06](https://codecov.io/gh/apache/jmeter/pull/329?src=pr&el=lastupdated).
 Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).



---

RE: Update Once Per Iteration reverses execution sequence of Preprocessors

[minerva001]

In case "Update Once Per Iteration" is marked my outcome is not the same as 
your result with your explanation.

I can only explain the outcome, that the Preprocessors are executed in reverse 
order. When true it could be pointed at in the code.

When not, what is really going on; which steps are taken.

> -Original Message-
> From: jmeter tea [mailto:jmeter...@gmail.com]
> Sent: Wednesday, 15. November 2017 10:06
> To: dev@jmeter.apache.org
> Subject: Re: Update Once Per Iteration reverses execution sequence of
> Preprocessors
> 
> User parameters are strictly hierarchical
> But when checking Update Once Per Iteration it saves before iteration the
> variables beforehand
> So that second User Parameter will have P as not exists variable and Q as
> defined in its own declaration
> and therefore:
> P1  is saved as ${P} , Q is saved as ${Q}q2
> Now User Parameter 1 will update Q  =  ${Q}q1
> and  User Parameter 2 will update Q =  ${Q}q1q2 where ${Q}q1 is the stored
> variable
> 
> It sounds like a bug, but this is the flow.
> 
> On Wed, Nov 15, 2017 at 10:15 AM, minerva001 
> wrote:
> 
> > Didn't got a reply on the user list, hoping to get some help from the devs.
> >
> > I noticed when having in a simple controller with several User Parameters
> > (Preprocessors) with the "Update Once Per Iteration" flag marked, that the
> > Preprocessors are run in reverse order.
> >
> >  Simple Controller
> >   User Parameter
> > P XX
> > Q${Q}q1
> >   User Parameter
> > P1  ${P}
> > Q   ${Q}q2
> >   Debug Sampler
> >
> >
> > In case "Update Once Per Iteration" is marked, P1=${P}, Q=${Q}q2q1
> > When not marked, P1=XX, Q=${Q}q1q2
> >
> > Why does "Update Once Per Iteration" reverses the execution sequence
> of
> > Preprocessors?
> > Is this behavior intended and somewhere documented?
> >
> >

[GitHub] jmeter pull request #330: Remove Workbench

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Workbench : Let's drop it ?

[Philippe Mouawad]

Hello,
PR merged this evening, I am happy with the change as I feel we removed a
lot of weird conditional codes.

Good by Workbench ! We won't miss you :-)

Thanks for the PR, merged with little modifications to avoid meaning less
popup menus.

I feel we should find a better name to "Non Test Elements":

   - it's negative
   - it's meaningless, it says what they are not, but not what they are

Proposals:

   - Test Building Elements
   - Debug Elements


Regards

Philippe M.

On Tue, Nov 14, 2017 at 2:54 PM, Artem Fedorov  wrote:

> I attached patch in this bug:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61591
>
>
> On Sun, Nov 12, 2017 at 4:05 PM, Ralf Roeber  wrote:
>
> > I use the workbench for recording.
> > I propose to add recording information to documentation about workbench.
> > I propose to rename workbench to "temporary elements"
> >
> > -0
> >
> > El 12 nov. 2017 1:33 p. m., "Felix Schumacher" <
> > felix.schumac...@internetallee.de> escribió:
> >
> >
> >
> > Am 10. November 2017 16:07:39 MEZ schrieb Philippe Mouawad <
> > philippe.moua...@gmail.com>:
> > >If we look at consensus, we have:
> > >
> > >  - 3 (+1) to remove it (Maxime, Antonio and me) with favor to move the
> > >elements inside Test plan as disabled (so backward compat). If we have
> > >a PR
> > >or patch that does that, I'll merge it after testing as much as
> > >possible.
> > > - 1 (-1) or (0) for sebb, do you agree sebb ? what would be your exact
> > >   position ?
> > >
> > >
> > >@Felix, @Milamber, @Vladimir,@Graham, @Mikhail , any thoughts on this ?
> >
> > I only use the workbench for the recorder and the mirror server. If I can
> > place them somewhere else, I personally would be fine with removal of
> > workbench.
> >
> > But I understand sebb's concerns.
> >
> > So it is a weak +1 from me.
> >
> > Felix
> > >
> > >
> > >
> > >Thanks
> > >
> > >On Fri, Nov 10, 2017 at 4:01 PM, Andrey Pokhilko  wrote:
> > >
> > >> I don't see any point for Workbench to exist. Simply disabling
> > >elements
> > >> in-place makes them temporary stored anywhere in test plan.
> > >>
> > >> Do we have a decision to remote it or not? I don't want to spend
> > >> resources if we don't have consensus.
> > >>
> > >> Andrey Pokhilko
> > >>
> > >> 09.11.2017 13:41, sebb пишет:
> > >> > Why not consider how to make the Workbench more intuitive and
> > >useful?
> > >> >
> > >> > On 8 November 2017 at 16:47, Philippe Mouawad
> > >> >  wrote:
> > >> >> As you say, it’s oddity.
> > >> >> A tool should be intuitive, this part is not, we cannot always
> > >say,
> > >> rtfm.
> > >> >> You know that lot of people don’t read docs.
> > >> >>
> > >> >> Let’s try and see if it is that complex.
> > >> >>
> > >> >> We shouldn’t say , we cannot touch, JMeter is not legacy, so we
> > >touch ,
> > >> >> break then fix .
> > >> >>
> > >> >> Regards
> > >> >>
> > >> >> On Wednesday, November 8, 2017, sebb  wrote:
> > >> >>
> > >> >>> On 8 November 2017 at 16:18, Philippe Mouawad
> > >> >>> > wrote:
> > >>  Hello,
> > >>  I’d say Test Plan.
> > >>  I suggest testcompiler ignores them
> > >> >>> That would involve a lot of testing to ensure nothing broke.
> > >> >>>
> > >> >>> Are you sure it's worth it?
> > >> >>>
> > >> >>> There have been other instances where what seems to be a minor
> > >change
> > >> >>> turns out to be far more intrusive than first expected.
> > >> >>> Dropping Workbench seems like such a case to me; it's been part
> > >of
> > >> >>> JMeter for so long that there are bound to be lots of places that
> > >> >>> assume it is present.
> > >> >>>
> > >> >>> I agree that the Workbench is a bit of an oddity, but I think
> > >removing
> > >> >>> it is going to prove much more of a headache than improving the
> > >> >>> documentation to explain it better.
> > >> >>> And potentially find more uses for it.
> > >> >>>
> > >>  Regards
> > >> 
> > >>  On Wednesday, November 8, 2017, Artem Fedorov <
> > >> >>> artem.fedo...@blazemeter.com >
> > >>  wrote:
> > >> 
> > >> > Hello,
> > >> >
> > >> > If we dropped WorkBench, in which element we can add Non-Test
> > >> Elements
> > >> > (HTTP Mirror Server, HTTP(S) Test Script Recorder, Property
> > >Display)?
> > >> > Can we add these Non-Test Elements to Test Plan (root) or Test
> > >> Fragment?
> > >> >
> > >> > Thanks
> > >> >
> > >> >  > >> > source=link&utm_campaign=sig-email&utm_content=webmail>
> > >> > Без
> > >> > вирусов. www.avast.ru
> > >> >  > >> > source=link&utm_campaign=sig-email&utm_content=webmail>
> > >> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > >> >
> > >> > On Wed, Nov 8, 2017 at 4:41 PM, Philippe Mouawad <
> > >> > philippe.moua...@gmail.com  
> > >> >> wrote:
> > >> >> Great !
> > >> >>
> > >> >> On Wed, Nov 8, 2017 at 2:38 PM, Andrey Pokhilko  > >> >>> 
>

[GitHub] jmeter pull request #324: Save backup refactor

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] jmeter issue #324: Save backup refactor

[pmouawad]

Github user pmouawad commented on the issue:

https://github.com/apache/jmeter/pull/324
  
Thanks @ham1 ,
Could you review my commit as your PR had a conflict after merging of 
Workbench before it.

I think I didn't miss anything but another eye is welcome.
Regards


---

[GitHub] jmeter pull request #327: Utilising more modern Java, simplifying code and f...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] jmeter issue #324: Save backup refactor

[ham1]

Github user ham1 commented on the issue:

https://github.com/apache/jmeter/pull/324
  
@pmouawad Thank you for committing my changes - in future I'm happy to 
rebase and fix merge issues so you don't have to :)

There were only a few minor things:
- formatting of streams api code - they seem to be mostly on one line, 
whereas I think they read much better when split, (perhaps this is the eclipse 
formatter?)
- some extra whitespace was added (maybe eclipse settings?)
- I question the JavaDoc on the private methods - it didn't seem to help, I 
had hoped the method name was sufficient - is there a reason it was added?
- formatting of JavaDoc comments, I think we should agree on a format and 
make sure it's updated in the style guide on the wiki as we currently have a 
mix and it would be good to agree to prevent further inconsistency (the 
location of the description of the param, same or new line)

What's the best way for me to provide these changes? Force push to this PR, 
new PR, email patch file?

Thanks


---