Re: problem with json path extractor

[Philippe Mouawad]

Thank you Roberto.
It's very encouraging to have such kind words from happy users :-) Such
feedback is unfortunately not frequent enough.

And thanks for your contribution and your time.
Regards



On Fri, Oct 21, 2016 at 10:00 PM, Roberto Braga 
wrote:

> thank you all for the wonderfull jemeter and the prompt support
>
>
>
> Il 21/10/2016 21:09, Felix Schumacher ha scritto:
>
>> Am 21.10.2016 um 11:54 schrieb Roberto Braga:
>>
>>> I have attached a patch and two test cases, that show the behaviour for
 Regex and (modified) JSON Extractor.

>>>
>>> Is this patch already in the nightly build?
>>>
>>>
>>> I committed the patch. It should be in the next available nightly.
>>
>> Thanks for your investigations in this bug.
>>
>> Felix
>>
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
>> For additional commands, e-mail: user-h...@jmeter.apache.org
>>
>>
>
> --
> "Ai sensi e per gli effetti della legge sulla tutela dei dati personali
> (D.lgs 196/2003),
> le informazioni contenute nella presente @mail sono di natura riservata e
> destinate
> ad un uso aziendale-lavorativo con esclusione di utilizzi ad uso
> personale; come tali,
> pertanto, sono riservate esclusivamente ai destinatari sopra indicati. E'
> proibito leggere,
> copiare, usare o diffondere il contenuto della presente @mail senza
> autorizzazione.
> Se avete ricevuto questa @mail per errore, siete pregati di rispedire la
> stessa al mittente.
> Grazie"
>
> -
> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
> For additional commands, e-mail: user-h...@jmeter.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: problem with json path extractor

[Roberto Braga]

thank you all for the wonderfull jemeter and the prompt support


Il 21/10/2016 21:09, Felix Schumacher ha scritto:

Am 21.10.2016 um 11:54 schrieb Roberto Braga:

I have attached a patch and two test cases, that show the behaviour for
Regex and (modified) JSON Extractor.


Is this patch already in the nightly build?



I committed the patch. It should be in the next available nightly.

Thanks for your investigations in this bug.

Felix


-
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org




--
"Ai sensi e per gli effetti della legge sulla tutela dei dati personali 
(D.lgs 196/2003),
le informazioni contenute nella presente @mail sono di natura riservata e 
destinate
ad un uso aziendale-lavorativo con esclusione di utilizzi ad uso personale; 
come tali,
pertanto, sono riservate esclusivamente ai destinatari sopra indicati. E' 
proibito leggere,
copiare, usare o diffondere il contenuto della presente @mail senza 
autorizzazione.
Se avete ricevuto questa @mail per errore, siete pregati di rispedire la 
stessa al mittente.

Grazie"

-
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org

Re: problem with json path extractor

[Felix Schumacher]

Am 21.10.2016 um 11:54 schrieb Roberto Braga:

I have attached a patch and two test cases, that show the behaviour for
Regex and (modified) JSON Extractor.


Is this patch already in the nightly build?



I committed the patch. It should be in the next available nightly.

Thanks for your investigations in this bug.

Felix


-
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org

RE: How would you go about creating a new Thread Group type?

[Robin D. Wilson]

The behavior I have explained is observed. I see a test run for 10+ minutes 
with 100 threads, then I see the active thread count drop off consistently at 
the end of the test well before I hit the end of the test. If all the threads 
were on the same loop, then the smallest possible number of completed threads 
would be the loop count subtracted from the total threads. (E.g, if there were 
going to be 1 loops for each sampler, I would expect to see the last 
sampler to have at most 9901 incomplete threads when the test begins to wind 
down. But I have observed that the test actually begins to wind down with 8000 
(give or take a few) and then continues to finish running threads until it 
finally completes all 1 loops. This means that there are many threads that 
are not on the last loop when the first thread finishes its last loop.

BUT, when I use the CSV file, I don't see the same behavior. I see what I want 
- which is that I maintain all 100 threads until the number of remaining loops 
passes the '9900'.

Also, your assertion is mistaken, simply because you and I are not apparently 
talking about the same things. A 'thread-loop' is 1 thread running through all 
of the steps in a thread group one time. This is the thing that is taking 10-20 
seconds. And the timing is variable depending on what is going on in the test. 

If you want to just simulate the behavior, setup a web page that waits between 
0 and 5 seconds to respond (using a random number generator). Then run a test 
against it with 100 simultaneous threads and 100 loops. You will see what I'm 
talking about.


--
Robin D. Wilson
Voice: 512-426-3929
rwils...@gmail.com

-Original Message-
From: Deepak Goel [mailto:deic...@gmail.com] 
Sent: Friday, October 21, 2016 9:09 AM
To: JMeter Users List 
Subject: RE: How would you go about creating a new Thread Group type?

your assumption that the slowest thread takes 20sec and the fastest thread 
takes 10 sec is false. Usually the difference is in milliseconds and over a 
period of time,  it becomes zero. All threads receive their answer in about the 
same time..they have to wait or queue for the same time

On Oct 21, 2016 6:31 PM, "Robin D. Wilson"  wrote:

> If you have a thread group with 10 HTTP Request samplers in it (or 
> 100, or 1000, whatever the number is - the more you have, the more 
> pronounced this concern will become), and you run a thread that steps 
> through each of the samplers in sequence, some threads will get done 
> sooner than others - that is practically guaranteed - since there is 
> no way that the server will respond identically quickly to each request.
>
> So, after 1 loop through your test plan you will have a bell curve of 
> times it took for each thread to complete the loop. A few threads will 
> have completed relatively fast, a few will have completed relatively 
> slower, and the bulk of the threads will have completed with times 
> somewhere in the middle. Let's say that the fastest thread completes 
> the full set of requests for the loop in 10 seconds. And the slowest 
> thread completes the loop in 20 seconds. For argument's sake, let's 
> say that the differential between fastest and slowest is not 
> necessarily due to the capacity of the server, but just an artifact of 
> random chance - the fastest thread caught all the green lights, and 
> the slowest thread caught all the red lights (e.g., i/o blocking, lock waits, 
> network congestion back offs, etc.)...
>
> If you re-start the loop for each thread, as soon as it completes the 
> last loop - then the fast threads will restart much earlier than the 
> loops that are completing on the slower end of the curve. In fact, 
> given that the 'fastest' time was only 10 seconds, and the slowest 
> time was 20 seconds - there is a non-zero chance that the fastest 
> thread could actually complete another full loop by the time the 
> slowest thread is completing its first full loop.
>
> If you assign the loops based on a pure division of "number of loops / 
> number of threads", you will assure that each thread has an equal 
> number of loops. But you will also assure that some threads complete 
> their total number of loops well before other threads complete their full set 
> of loops.
> Moreover, the longer your test run is, the wider the disparity will be 
> between the threads that reach their full loop count early, and the 
> threads that finish the full loop count last. Such that, the slower 
> running threads may be running their last several loops while the 
> faster threads have completely died off - meaning that the last few 
> threads will be running while the machine is under a progressively lighter 
> load.
>
> Clearly, you can't help this from happening during the 'last' loop for 
> every thread, since each thread must stop once it has completed a full 
> loop
> - if there are no more loops left to run. But if you don't really care 
> how 

Re: How to specify JDBC request parameter values for OracleTypes.ARRAY in JMeter for stote procedure

[Sharad Yadav]

please try same with store procedure .don't try with function

On Fri, Oct 21, 2016 at 4:16 PM, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
>
> Am 21. Oktober 2016 11:18:34 MESZ, schrieb Sharad Yadav <
> sharad.yadav9...@gmail.com>:
> >please update
>
> What should be updated?
>
> The images you wanted to sent, were stripped and this could not be seen by
> us.
>
> I don't have Oracle and I don't have your plsql function and this can't
> test your setup.
>
> I think it is up to you to give us more information.
>
> I would try a simpler function - where the user defined type is replaced
> by an array and that has a really simple implementation, like the one I
> used for postgresql - and see if it is giving the same error.
>
> Regards,
> Felix
> >
> >On Thu, Oct 20, 2016 at 4:53 PM, Sharad Yadav
> >
> >wrote:
> >
> >>
> >>
> >> On Thu, Oct 20, 2016 at 4:13 PM, Felix Schumacher  >> internetallee.de> wrote:
> >>
> >>> The list strips most attachments. Your images were stripped and this
> >>> can't be seen.
> >>>
> >>> Felix
> >>>
> >>> Am 20. Oktober 2016 17:06:52 MESZ, schrieb Sharad Yadav <
> >>> sharad.yadav9...@gmail.com>:
> >>> >Getting same exception..
> >>> >
> >>> >
> >>> >[image: Inline image 1]
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >[image: Inline image 2]
> >>> >
> >>> >On Thu, Oct 20, 2016 at 3:19 PM, Felix Schumacher <
> >>> >felix.schumac...@internetallee.de> wrote:
> >>> >
> >>> >> Am 20.10.2016 15:55, schrieb Sharad Yadav:
> >>> >>
> >>> >>> For REF CURSOR ,I am using Parameter value "ResultSet" and
> >Parameter
> >>> >type
> >>> >>> "OUT -10" and  getting correct result.but for Array.not able to
> >get
> >>> >any
> >>> >>> docs or any help.Please suggest asap
> >>> >>>
> >>> >>
> >>> >> I tried a simple example callable statement using postgresql with
> >a
> >>> >> function f_array declared ad:
> >>> >>
> >>> >> create or replace function f_array(OUT a1 INT[]) AS $$
> >>> >> BEGIN
> >>> >>   a1[0]=1;
> >>> >>   a1[1]=2;
> >>> >> END;
> >>> >> $$
> >>> >> language plpgsql;
> >>> >>
> >>> >> and called that with a JDBC Sampler using
> >>> >>
> >>> >> Query Type: Callable Statement
> >>> >> Query: {call f_array(?)}
> >>> >> Parameter values: dummy
> >>> >> Parameter Types: OUT 2003
> >>> >> Variable name: a1
> >>> >>
> >>> >> and it worked OK.
> >>> >>
> >>> >> I don't have an oracle db at hand, so can't test it.
> >>> >>
> >>> >> Regards,
> >>> >>  Felix
> >>> >>
> >>> >>
> >>> >>
> >>> >>> On Thu, Oct 20, 2016 at 1:51 PM, Sharad Yadav
> >>> > >>> >>> >
> >>> >>> wrote:
> >>> >>>
> >>> >>> I have specified all parameter and  have checked only problem
> >with
> >>> >Array
> >>>  Type.Please let me know how to declare Array as Output
> >Parameter
> >>> >value
> >>>  and
> >>>  Type
> >>> 
> >>>  On Thu, Oct 20, 2016 at 12:57 PM, Felix Schumacher
> >>> > >>>  internetallee.de> wrote:
> >>> 
> >>> 
> >>> >
> >>> > Am 20. Oktober 2016 13:18:46 MESZ, schrieb Sharad Yadav <
> >>> > sharad.yadav9...@gmail.com>:
> >>> > >Please find below menytioned response that we are getting
> >from
> >>> >store
> >>> > >procedure
> >>> > >
> >>> > >ORA-06553: PLS-306: wrong number or types of arguments in
> >call to
> >>> > >'P_GET_SUMMARY_DETAILS'
> >>> >
> >>> > Have you specified all parameters? Is there anything more in
> >the
> >>> >JMeter
> >>> > logs?
> >>> >
> >>> > Even tough, I suspect you get more problems, when you have
> >solved
> >>> >this
> >>> > first step and want to access the results as an array.
> >>> >
> >>> > Regards,
> >>> > Felix
> >>> >
> >>> > >
> >>> > >
> >>> > >also find belwo mentioned store procedure body
> >>> > >
> >>> > > procedure p_get_summary_details(p_application_id   in
> >>> > >xxfe_application_summaries.id%type,
> >>> > >  p_application_summary out
> >>> > >xxco_alg_appl_summary_t_type,
> >>> > >  p_error_code  out
> >>> >number,
> >>> > >  p_error_message   out
> >>> >varchar2);
> >>> > >
> >>> > >
> >>> > >
> >>> > >Calling from Java is working fine as below mentioned
> >>> > >
> >>> > >   String getDBUSERByUserIdSql = "Call
> >>> > >OASPK014.P_GET_SUMMARY_DETAILS(?,?,?,?)";
> >>> > >
> >>> > >   dbConnection =getDBConnection();
> >>> > >callableStatement =
> >>> >dbConnection.prepareCall(getDBUSERByUserIdSql);
> >>> > >callableStatement.setBigDecimal(1, new
> >>> >BigDecimal(applicationId));
> >>> > >callableStatement.registerOutParameter(2,
> >>> > >java.sql.Types.ARRAY,"XXCO.XXCO_ALG_APPL_SUMMARY_T_TYPE");
> >>> > >callableStatement.registerOutParameter(3,
> >>> >java.sql.Types.INTEGER);
> >>> > >callableStatement.registerOutParameter(4,
> 

Re: How to specify JDBC request parameter values for OracleTypes.ARRAY in JMeter for stote procedure

[Felix Schumacher]

Am 21. Oktober 2016 11:18:34 MESZ, schrieb Sharad Yadav 
:
>please update

What should be updated?

The images you wanted to sent, were stripped and this could not be seen by us.

I don't have Oracle and I don't have your plsql function and this can't test 
your setup.

I think it is up to you to give us more information.

I would try a simpler function - where the user defined type is replaced by an 
array and that has a really simple implementation, like the one I used for 
postgresql - and see if it is giving the same error.

Regards,
Felix
>
>On Thu, Oct 20, 2016 at 4:53 PM, Sharad Yadav
>
>wrote:
>
>>
>>
>> On Thu, Oct 20, 2016 at 4:13 PM, Felix Schumacher > internetallee.de> wrote:
>>
>>> The list strips most attachments. Your images were stripped and this
>>> can't be seen.
>>>
>>> Felix
>>>
>>> Am 20. Oktober 2016 17:06:52 MESZ, schrieb Sharad Yadav <
>>> sharad.yadav9...@gmail.com>:
>>> >Getting same exception..
>>> >
>>> >
>>> >[image: Inline image 1]
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >[image: Inline image 2]
>>> >
>>> >On Thu, Oct 20, 2016 at 3:19 PM, Felix Schumacher <
>>> >felix.schumac...@internetallee.de> wrote:
>>> >
>>> >> Am 20.10.2016 15:55, schrieb Sharad Yadav:
>>> >>
>>> >>> For REF CURSOR ,I am using Parameter value "ResultSet" and
>Parameter
>>> >type
>>> >>> "OUT -10" and  getting correct result.but for Array.not able to
>get
>>> >any
>>> >>> docs or any help.Please suggest asap
>>> >>>
>>> >>
>>> >> I tried a simple example callable statement using postgresql with
>a
>>> >> function f_array declared ad:
>>> >>
>>> >> create or replace function f_array(OUT a1 INT[]) AS $$
>>> >> BEGIN
>>> >>   a1[0]=1;
>>> >>   a1[1]=2;
>>> >> END;
>>> >> $$
>>> >> language plpgsql;
>>> >>
>>> >> and called that with a JDBC Sampler using
>>> >>
>>> >> Query Type: Callable Statement
>>> >> Query: {call f_array(?)}
>>> >> Parameter values: dummy
>>> >> Parameter Types: OUT 2003
>>> >> Variable name: a1
>>> >>
>>> >> and it worked OK.
>>> >>
>>> >> I don't have an oracle db at hand, so can't test it.
>>> >>
>>> >> Regards,
>>> >>  Felix
>>> >>
>>> >>
>>> >>
>>> >>> On Thu, Oct 20, 2016 at 1:51 PM, Sharad Yadav
>>> >>> >>> >
>>> >>> wrote:
>>> >>>
>>> >>> I have specified all parameter and  have checked only problem
>with
>>> >Array
>>>  Type.Please let me know how to declare Array as Output
>Parameter
>>> >value
>>>  and
>>>  Type
>>> 
>>>  On Thu, Oct 20, 2016 at 12:57 PM, Felix Schumacher
>>> >>>  internetallee.de> wrote:
>>> 
>>> 
>>> >
>>> > Am 20. Oktober 2016 13:18:46 MESZ, schrieb Sharad Yadav <
>>> > sharad.yadav9...@gmail.com>:
>>> > >Please find below menytioned response that we are getting
>from
>>> >store
>>> > >procedure
>>> > >
>>> > >ORA-06553: PLS-306: wrong number or types of arguments in
>call to
>>> > >'P_GET_SUMMARY_DETAILS'
>>> >
>>> > Have you specified all parameters? Is there anything more in
>the
>>> >JMeter
>>> > logs?
>>> >
>>> > Even tough, I suspect you get more problems, when you have
>solved
>>> >this
>>> > first step and want to access the results as an array.
>>> >
>>> > Regards,
>>> > Felix
>>> >
>>> > >
>>> > >
>>> > >also find belwo mentioned store procedure body
>>> > >
>>> > > procedure p_get_summary_details(p_application_id   in
>>> > >xxfe_application_summaries.id%type,
>>> > >  p_application_summary out
>>> > >xxco_alg_appl_summary_t_type,
>>> > >  p_error_code  out
>>> >number,
>>> > >  p_error_message   out
>>> >varchar2);
>>> > >
>>> > >
>>> > >
>>> > >Calling from Java is working fine as below mentioned
>>> > >
>>> > >   String getDBUSERByUserIdSql = "Call
>>> > >OASPK014.P_GET_SUMMARY_DETAILS(?,?,?,?)";
>>> > >
>>> > >   dbConnection =getDBConnection();
>>> > >callableStatement =
>>> >dbConnection.prepareCall(getDBUSERByUserIdSql);
>>> > >callableStatement.setBigDecimal(1, new
>>> >BigDecimal(applicationId));
>>> > >callableStatement.registerOutParameter(2,
>>> > >java.sql.Types.ARRAY,"XXCO.XXCO_ALG_APPL_SUMMARY_T_TYPE");
>>> > >callableStatement.registerOutParameter(3,
>>> >java.sql.Types.INTEGER);
>>> > >callableStatement.registerOutParameter(4,
>>> >java.sql.Types.VARCHAR);
>>> > >System.out.println(":::Array
>Value:::"+java.sql.Types.ARRAY);
>>> > >System.out.println(":::INTEGER
>>> >Value:::"+java.sql.Types.INTEGER);
>>> > >System.out.println(":::VARCHAR
>>> >Value:::"+java.sql.Types.VARCHAR);
>>> > >System.out.println(":::VARCHAR
>Value:::"+OracleTypes.CURSOR);
>>> > >
>>> > >callableStatement.executeUpdate();
>>> > >Integer errorCode = (Integer) 

RE: How would you go about creating a new Thread Group type?

[Deepak Goel]

your assumption that the slowest thread takes 20sec and the fastest thread
takes 10 sec is false. Usually the difference is in milliseconds and over a
period of time,  it becomes zero. All threads receive their answer in about
the same time..they have to wait or queue for the same time

On Oct 21, 2016 6:31 PM, "Robin D. Wilson"  wrote:

> If you have a thread group with 10 HTTP Request samplers in it (or 100, or
> 1000, whatever the number is - the more you have, the more pronounced this
> concern will become), and you run a thread that steps through each of the
> samplers in sequence, some threads will get done sooner than others - that
> is practically guaranteed - since there is no way that the server will
> respond identically quickly to each request.
>
> So, after 1 loop through your test plan you will have a bell curve of
> times it took for each thread to complete the loop. A few threads will have
> completed relatively fast, a few will have completed relatively slower, and
> the bulk of the threads will have completed with times somewhere in the
> middle. Let's say that the fastest thread completes the full set of
> requests for the loop in 10 seconds. And the slowest thread completes the
> loop in 20 seconds. For argument's sake, let's say that the differential
> between fastest and slowest is not necessarily due to the capacity of the
> server, but just an artifact of random chance - the fastest thread caught
> all the green lights, and the slowest thread caught all the red lights
> (e.g., i/o blocking, lock waits, network congestion back offs, etc.)...
>
> If you re-start the loop for each thread, as soon as it completes the last
> loop - then the fast threads will restart much earlier than the loops that
> are completing on the slower end of the curve. In fact, given that the
> 'fastest' time was only 10 seconds, and the slowest time was 20 seconds -
> there is a non-zero chance that the fastest thread could actually complete
> another full loop by the time the slowest thread is completing its first
> full loop.
>
> If you assign the loops based on a pure division of "number of loops /
> number of threads", you will assure that each thread has an equal number of
> loops. But you will also assure that some threads complete their total
> number of loops well before other threads complete their full set of loops.
> Moreover, the longer your test run is, the wider the disparity will be
> between the threads that reach their full loop count early, and the threads
> that finish the full loop count last. Such that, the slower running threads
> may be running their last several loops while the faster threads have
> completely died off - meaning that the last few threads will be running
> while the machine is under a progressively lighter load.
>
> Clearly, you can't help this from happening during the 'last' loop for
> every thread, since each thread must stop once it has completed a full loop
> - if there are no more loops left to run. But if you don't really care how
> many times each thread runs a loop, you could schedule the loops from a
> queue - where instead of pre-calculating the total loops for each thread,
> you just maintained the total number of loops you needed for the test to
> run, and each thread would just decrement the count when it finished its
> previous loop. Once the count drops all the way to '0', all of the threads
> still running would complete their final loops, and the test would be done.
> BUT no threads would be starting new loops while the server was under a
> lighter load (even though they would complete their last loops while the
> load steadily declined).
>
> Sebb's suggestion of just using a CSV file to count the loops accomplishes
> this exact requirement. If I want a test to run 100,000 loops, I just
> supply a CSV file with 10 records it. Then I set the Thread Group to
> run "Infinite" loops, and set the CSV file to stop on EOF. The test runs
> until the 10th record is retrieved from the CSV file, and once that
> loop starts - the threads all stop when they finish their most recent loop
> because they can't get another record from the CSV. (HINT: you can give the
> CSV variable a name like 'loop_count', and make your CSV file contain
> records that count up from 1-10, and you will also gain a variable that
> tells you which loop you were on for specific sets of requests.)
>
> This isn't a huge concern, just a way to make sure that you maintain the
> same relative server load all through the duration of the test.
>
> --
> Robin D. Wilson
> Voice: 512-426-3929
> rwils...@gmail.com
>
> -Original Message-
> From: Deepak Goel [mailto:deic...@gmail.com]
> Sent: Friday, October 21, 2016 1:46 AM
> To: JMeter Users List 
> Subject: Re: How would you go about creating a new Thread Group type?
>
> I am not sure I understand your problem correctly...
>
> Why would the load be reduced to 99 threads? As the threads 

RE: How would you go about creating a new Thread Group type?

[Robin D. Wilson]

If you have a thread group with 10 HTTP Request samplers in it (or 100, or 
1000, whatever the number is - the more you have, the more pronounced this 
concern will become), and you run a thread that steps through each of the 
samplers in sequence, some threads will get done sooner than others - that is 
practically guaranteed - since there is no way that the server will respond 
identically quickly to each request.

So, after 1 loop through your test plan you will have a bell curve of times it 
took for each thread to complete the loop. A few threads will have completed 
relatively fast, a few will have completed relatively slower, and the bulk of 
the threads will have completed with times somewhere in the middle. Let's say 
that the fastest thread completes the full set of requests for the loop in 10 
seconds. And the slowest thread completes the loop in 20 seconds. For 
argument's sake, let's say that the differential between fastest and slowest is 
not necessarily due to the capacity of the server, but just an artifact of 
random chance - the fastest thread caught all the green lights, and the slowest 
thread caught all the red lights (e.g., i/o blocking, lock waits, network 
congestion back offs, etc.)...

If you re-start the loop for each thread, as soon as it completes the last loop 
- then the fast threads will restart much earlier than the loops that are 
completing on the slower end of the curve. In fact, given that the 'fastest' 
time was only 10 seconds, and the slowest time was 20 seconds - there is a 
non-zero chance that the fastest thread could actually complete another full 
loop by the time the slowest thread is completing its first full loop.

If you assign the loops based on a pure division of "number of loops / number 
of threads", you will assure that each thread has an equal number of loops. But 
you will also assure that some threads complete their total number of loops 
well before other threads complete their full set of loops. Moreover, the 
longer your test run is, the wider the disparity will be between the threads 
that reach their full loop count early, and the threads that finish the full 
loop count last. Such that, the slower running threads may be running their 
last several loops while the faster threads have completely died off - meaning 
that the last few threads will be running while the machine is under a 
progressively lighter load.

Clearly, you can't help this from happening during the 'last' loop for every 
thread, since each thread must stop once it has completed a full loop - if 
there are no more loops left to run. But if you don't really care how many 
times each thread runs a loop, you could schedule the loops from a queue - 
where instead of pre-calculating the total loops for each thread, you just 
maintained the total number of loops you needed for the test to run, and each 
thread would just decrement the count when it finished its previous loop. Once 
the count drops all the way to '0', all of the threads still running would 
complete their final loops, and the test would be done. BUT no threads would be 
starting new loops while the server was under a lighter load (even though they 
would complete their last loops while the load steadily declined).

Sebb's suggestion of just using a CSV file to count the loops accomplishes this 
exact requirement. If I want a test to run 100,000 loops, I just supply a CSV 
file with 10 records it. Then I set the Thread Group to run "Infinite" 
loops, and set the CSV file to stop on EOF. The test runs until the 10th 
record is retrieved from the CSV file, and once that loop starts - the threads 
all stop when they finish their most recent loop because they can't get another 
record from the CSV. (HINT: you can give the CSV variable a name like 
'loop_count', and make your CSV file contain records that count up from 
1-10, and you will also gain a variable that tells you which loop you were 
on for specific sets of requests.)

This isn't a huge concern, just a way to make sure that you maintain the same 
relative server load all through the duration of the test.

--
Robin D. Wilson
Voice: 512-426-3929
rwils...@gmail.com

-Original Message-
From: Deepak Goel [mailto:deic...@gmail.com] 
Sent: Friday, October 21, 2016 1:46 AM
To: JMeter Users List 
Subject: Re: How would you go about creating a new Thread Group type?

I am not sure I understand your problem correctly...

Why would the load be reduced to 99 threads? As the threads which haven't 
finished their earlier cycle are still running...they are spending time 
finishing their previous request (which would also indicate a problem with the 
server responding the request)

Hey

Namaskara~Nalama~Guten Tag~Bonjour


   --
Keigu

Deepak
73500 12833
www.simtree.net, dee...@simtree.net
deic...@gmail.com

LinkedIn: www.linkedin.com/in/deicool
Skype: thumsupdeicool
Google talk: deicool
Blog: http://loveandfearless.wordpress.com

Re: problem with json path extractor

[Roberto Braga]

I have attached a patch and two test cases, that show the behaviour for
Regex and (modified) JSON Extractor.


Is this patch already in the nightly build?


--
"Ai sensi e per gli effetti della legge sulla tutela dei dati personali 
(D.lgs 196/2003),
le informazioni contenute nella presente @mail sono di natura riservata e 
destinate
ad un uso aziendale-lavorativo con esclusione di utilizzi ad uso personale; 
come tali,
pertanto, sono riservate esclusivamente ai destinatari sopra indicati. E' 
proibito leggere,
copiare, usare o diffondere il contenuto della presente @mail senza 
autorizzazione.
Se avete ricevuto questa @mail per errore, siete pregati di rispedire la 
stessa al mittente.

Grazie"

-
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org

Re: How can I unsubscribe myself ?

[sebb]

Please unsubscribe yourself; send a message to

user-unsubscr...@jmeter.apache.org

and reply to the confirmation mail.


On 21 October 2016 at 09:06, Sheetal Jharia Baru  wrote:
> Hi Team,
> I no longer work in JMeter hence do not wish to receive these emails.
> Can I please be unsubscribed ?
>
> Thanks,
> Sheetal

-
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org

Re: How to specify JDBC request parameter values for OracleTypes.ARRAY in JMeter for stote procedure

[Sharad Yadav]

please update

On Thu, Oct 20, 2016 at 4:53 PM, Sharad Yadav 
wrote:

>
>
> On Thu, Oct 20, 2016 at 4:13 PM, Felix Schumacher  internetallee.de> wrote:
>
>> The list strips most attachments. Your images were stripped and this
>> can't be seen.
>>
>> Felix
>>
>> Am 20. Oktober 2016 17:06:52 MESZ, schrieb Sharad Yadav <
>> sharad.yadav9...@gmail.com>:
>> >Getting same exception..
>> >
>> >
>> >[image: Inline image 1]
>> >
>> >
>> >
>> >
>> >
>> >[image: Inline image 2]
>> >
>> >On Thu, Oct 20, 2016 at 3:19 PM, Felix Schumacher <
>> >felix.schumac...@internetallee.de> wrote:
>> >
>> >> Am 20.10.2016 15:55, schrieb Sharad Yadav:
>> >>
>> >>> For REF CURSOR ,I am using Parameter value "ResultSet" and Parameter
>> >type
>> >>> "OUT -10" and  getting correct result.but for Array.not able to get
>> >any
>> >>> docs or any help.Please suggest asap
>> >>>
>> >>
>> >> I tried a simple example callable statement using postgresql with a
>> >> function f_array declared ad:
>> >>
>> >> create or replace function f_array(OUT a1 INT[]) AS $$
>> >> BEGIN
>> >>   a1[0]=1;
>> >>   a1[1]=2;
>> >> END;
>> >> $$
>> >> language plpgsql;
>> >>
>> >> and called that with a JDBC Sampler using
>> >>
>> >> Query Type: Callable Statement
>> >> Query: {call f_array(?)}
>> >> Parameter values: dummy
>> >> Parameter Types: OUT 2003
>> >> Variable name: a1
>> >>
>> >> and it worked OK.
>> >>
>> >> I don't have an oracle db at hand, so can't test it.
>> >>
>> >> Regards,
>> >>  Felix
>> >>
>> >>
>> >>
>> >>> On Thu, Oct 20, 2016 at 1:51 PM, Sharad Yadav
>> >> >>> >
>> >>> wrote:
>> >>>
>> >>> I have specified all parameter and  have checked only problem with
>> >Array
>>  Type.Please let me know how to declare Array as Output Parameter
>> >value
>>  and
>>  Type
>> 
>>  On Thu, Oct 20, 2016 at 12:57 PM, Felix Schumacher
>> >>  internetallee.de> wrote:
>> 
>> 
>> >
>> > Am 20. Oktober 2016 13:18:46 MESZ, schrieb Sharad Yadav <
>> > sharad.yadav9...@gmail.com>:
>> > >Please find below menytioned response that we are getting from
>> >store
>> > >procedure
>> > >
>> > >ORA-06553: PLS-306: wrong number or types of arguments in call to
>> > >'P_GET_SUMMARY_DETAILS'
>> >
>> > Have you specified all parameters? Is there anything more in the
>> >JMeter
>> > logs?
>> >
>> > Even tough, I suspect you get more problems, when you have solved
>> >this
>> > first step and want to access the results as an array.
>> >
>> > Regards,
>> > Felix
>> >
>> > >
>> > >
>> > >also find belwo mentioned store procedure body
>> > >
>> > > procedure p_get_summary_details(p_application_id   in
>> > >xxfe_application_summaries.id%type,
>> > >  p_application_summary out
>> > >xxco_alg_appl_summary_t_type,
>> > >  p_error_code  out
>> >number,
>> > >  p_error_message   out
>> >varchar2);
>> > >
>> > >
>> > >
>> > >Calling from Java is working fine as below mentioned
>> > >
>> > >   String getDBUSERByUserIdSql = "Call
>> > >OASPK014.P_GET_SUMMARY_DETAILS(?,?,?,?)";
>> > >
>> > >   dbConnection =getDBConnection();
>> > >callableStatement =
>> >dbConnection.prepareCall(getDBUSERByUserIdSql);
>> > >callableStatement.setBigDecimal(1, new
>> >BigDecimal(applicationId));
>> > >callableStatement.registerOutParameter(2,
>> > >java.sql.Types.ARRAY,"XXCO.XXCO_ALG_APPL_SUMMARY_T_TYPE");
>> > >callableStatement.registerOutParameter(3,
>> >java.sql.Types.INTEGER);
>> > >callableStatement.registerOutParameter(4,
>> >java.sql.Types.VARCHAR);
>> > >System.out.println(":::Array Value:::"+java.sql.Types.ARRAY);
>> > >System.out.println(":::INTEGER
>> >Value:::"+java.sql.Types.INTEGER);
>> > >System.out.println(":::VARCHAR
>> >Value:::"+java.sql.Types.VARCHAR);
>> > >System.out.println(":::VARCHAR Value:::"+OracleTypes.CURSOR);
>> > >
>> > >callableStatement.executeUpdate();
>> > >Integer errorCode = (Integer) callableStatement.getInt(3);
>> > >String errorMessage  = (String) callableStatement.getString(4);
>> > >
>> > >Object[] data = (Object[]) ((Array)
>> > >callableStatement.getObject(2)).getArray();
>> > >
>> > >On Thu, Oct 20, 2016 at 11:01 AM, Felix Schumacher <
>> > >felix.schumac...@internetallee.de> wrote:
>> > >
>> > >>
>> > >>
>> > >> Am 20. Oktober 2016 11:51:55 MESZ, schrieb Sharad Yadav <
>> > >> sharad.yadav9...@gmail.com>:
>> > >> >HI,
>> > >> >
>> > >> >Not able to set  Parameter values and Parameter types for
>> >Return
>> > >type
>> > >> >of
>> > >> >OracleTypes.ARRAY by store procedure.Please give some
>> >suggestion as
>> > >i
>> > >> >have
>> 

How can I unsubscribe myself ?

[Sheetal Jharia Baru]

Hi Team,
I no longer work in JMeter hence do not wish to receive these emails.
Can I please be unsubscribed ?

Thanks,
Sheetal

Re: How would you go about creating a new Thread Group type?

[Ivan Rancati]

I'm also not sure I understand the problem.
Assuming I do

1)
use more threads, for example 125, and add a Throughput Controller


2)
There was a similar discussion 3 years ago
http://jmeter.512774.n5.nabble.com/Coordinated-Omission-CO-possible-strategies-tt5718456.html#none

br,
Ivan


On Fri, Oct 21, 2016 at 8:46 AM, Deepak Goel  wrote:

> I am not sure I understand your problem correctly...
>
> Why would the load be reduced to 99 threads? As the threads which haven't
> finished their earlier cycle are still running...they are spending time
> finishing their previous request (which would also indicate a problem with
> the server responding the request)
>
> Hey
>
>

Re: How would you go about creating a new Thread Group type?

[Deepak Goel]

I am not sure I understand your problem correctly...

Why would the load be reduced to 99 threads? As the threads which haven't
finished their earlier cycle are still running...they are spending time
finishing their previous request (which would also indicate a problem with
the server responding the request)

Hey

Namaskara~Nalama~Guten Tag~Bonjour


   --
Keigu

Deepak
73500 12833
www.simtree.net, dee...@simtree.net
deic...@gmail.com

LinkedIn: www.linkedin.com/in/deicool
Skype: thumsupdeicool
Google talk: deicool
Blog: http://loveandfearless.wordpress.com
Facebook: http://www.facebook.com/deicool

"Contribute to the world, environment and more : http://www.gridrepublic.org
"

On Tue, Oct 18, 2016 at 2:38 AM, Robin D. Wilson  wrote:

> Just throwing this out there - to see if anyone wants to lead a code-level
> newbie down the right path. I've been using JMeter for
> 8-9 years now, and really like it. But one thing that bugs me is the way
> the Thread Group works. Specifically, the idea of the
> "loops" bothers me.
>
>
>
> Consider this scenario:
>
>
>
> 1) 100 "users" (e.g., threads)
>
> 2) 10 loops
>
> 3) Test has 10 HTTP Requests in it
>
>
>
> By this logic, you should end up with 100 (users) X 10 loops X 10 HTTP
> Requests = 10,000 requests.
>
>
>
> And you do.
>
>
>
> BUT, what you actually get when you run the test isn't as clear as you
> think. It is basically 100 threads, each running 10 times,
> and each thread loop running 10 HTTP requests in sequence.
>
>
>
> Here's the problem, if thread 1 completes its 10 loops in 100 seconds, but
> threads 2-100 take 200 seconds to complete their 10
> loops. The load will be reduced to only 99 simultaneous threads (users)
> for the last 100 seconds of the test run. That's not a
> 'huge' deal, but it can affect the perception of the test if you look at
> it more like threads 1-50 finish in 100 seconds, and
> threads 51-100 take an extra 100 seconds after that to complete. Then only
> half of your test cycle was at the required 'max' load
> you wanted to create, while the other half was at 50% of the required
> load. (It is reasonably possible that I'm just misinterpreting
> how it actually works, but it appears to work like this from my experience
> since I can see threads continuing to process after some
> threads appear to stop - and it lasts longer than it takes to get through
> the entire cycle - sometimes for several minutes at the
> end of a test run.)
>
>
>
> I'd like to create a new Thread Group that doesn't assign the thread to
> the loop until it starts again at the top of the cycle. So
> if thread-1 finishes really fast, and there are still loops to run - it
> just picks up another loop and runs it. I would always want
> to maintain at least 100 threads executing, so long as there were loops
> left to run. So basically, you multiply the number of loops
> by the number of threads (1000 in my example), and your 100 threads always
> restart until there are no loops left to run. Then the
> longest period you have where you aren't fully loading the servers is just
> the last loop for every thread.
>
>
>
> BUT, I am not 100% sure where I would start in the source code. I have
> programmed before (a long time ago), but if someone could
> point me in the right direction (like, which source files would need to be
> modified, and how would I register my new Thread Group as
> a different option), I think I could figure it out pretty quickly.
>
>
>
> --
>
> Robin D. Wilson
>
>   rwils...@gmail.com
>
>
>
>