On 19/11/2008, Ondrej Baudys <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 19, 2008 at 10:47 PM, sebb <[EMAIL PROTECTED]> wrote:
> > On 19/11/2008, Ondrej Baudys <[EMAIL PROTECTED]> wrote:
> >> Hello List,
> >>
> >> I have stumbled upon what time me is definitely a bug in Jmeter. I was
> >> able to reproduce the problem in Jmeter 2.3.1, 2.3, and 2.2
> >>
> >> Consider the following test plan configuration:
> >>
> >> Test Plan
> >> Thread Group
> >> User Defined Variables
> >> ForEach Controller
> >> HTTP Request Defaults
> >> HTTP Request #1
> >> HTTP Request #2
> >> View Results Tree (Listener)
> >>
> >>
> >> Where the user defined variables are:
> >> SITE_1 = web-server
> >> SITE_2 = dev-server
> >> SITE_3 = localbox
> >>
> >> and the ForEach Controller takes 'SITE' as input spits out 'siteName' as
> output
> >>
> >> The "Server Name or IP" field of the "HTTP Request defaults" set to
> >> ${siteName}.localdomain
> >>
> >> I also use ${siteName} in the Path Field of the "HTTP Requests"
> >> 1. ${siteName}/index.html
> >> 2. ${siteName}/main.jsp
> >>
> >>
> >> This is what I expect to see in the Request tab of the "View Results
> Tree":
> >>
> >> 1. GET http://dev-server.localdomain/dev-server/index.html
> >> 2. GET http://dev-server.localdomain/dev-server/main.jsp
> >> 3. GET http://web-server.localdomain/web-server/index.html
> >> 4. GET http://web-server.localdomain/web-server/main.jsp
> >> 5. GET http://localbox.localdomain/localbox/index.html
> >> 6. GET http://localbox.localdomain/localbox/main.jsp
> >>
> >> ie. each pair of above requests has the output variable ${siteName}
> >> populated as expected.
> >>
> >> What actually happens: requests 3. and 5. above are instead
> >>
> >> 3. GET http://dev-server.localdomain/web-server/index.html
> >> 5. GET http://web-server.localdomain/localbox/index.html
> >>
> >> Ie. the 'siteName' variable as used in HTTP Restquest Defaults' server
> >> name field is populated with the *previous iterations value* for the
> >> *first http request only*.
> >>
> >> Obviously everything works in the first step since there is no
> >> previous iteration, any subsequent HTTP Requests are fine (only 2
> >> requests above but I have tested with varing numbers). The problem
> >> always occurs on the first HTTP request.
> >>
> >> I have tested with the java HTTP request and the apache commons
> >> implementation. Same results.
> >>
> >> I also added a test parameter on the HTTP Request Defaults: it works
> >> fine both with and without the variable in the Server Name field. So
> >> I think the problem is with the Server Name field only.
> >>
> >> I am attaching my example test plan (hopefully the mailing list lets
> >> it through) so that you can reproduce the problem quickly.
> >
> > Please don't send attachments to the list.
> >
> >> I have
> >> looked through bugzilla for anything similar but I must admit I don't
> >> know how to use it properly... if someone can reproduce the problem
> >> and/or cannot find a problem with my configuration, I will try and
> >> open a bug report.
> >>
> >
> > This is not a bug.
> >
> > HTTP Request Defaults is a Configuration item; they are processed at
> > the start of their scope only. They are not processed at run-time like
> > samplers or Pre- or Post-Processors.
>
>
> Ah, I see.
>
> Not to contradict what you just said, but the HTTP Request Defaults DO
> get updated at run time in the example I gave above, just not for the
> first HTTP request. Is this the expected behaviour? It seems very
> strange to me, but then I don't really know where scope of the Request
> Defaults begins and ends.
It's not just the scope of the Request Default, it's when the element
is processed.
As it is a Configuration element it is only processed once at the
start of its scope.
I would not expect it to work properly in a For Each controller.
>
> >
> > There is no need for the Request Defaults in this case - just use the
> > variable on the samplers.
> >
>
>
> Will do.
>
> Thanks for your reply
>
>
> Ondrej
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
