jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milamber <milam...@apache.org>
Subject Re: jmeter.properties cleanup
Date Fri, 10 May 2013 00:30:29 GMT

Le 09/05/2013 22:52, Milamber a ecrit :
>
> Le 09/05/2013 21:47, Philippe Mouawad a ecrit :
>> Hello,
>> I have implemented the shutdown hook on nightly build (thanks sebb for
>> review and nice idea).
>>
>> Milamber if you have time to test and give feedback it would be nice.
>
>
> Currently, I have a issue with ant distribution task:
>
>      [java] Time: 73.459
>      [java] There were 2 failures:
>      [java] 1) 
> runSerialTest(org.apache.jmeter.junit.JMeterTest)junit.framework.AssertionFailedError:

> serialization of org.apache.jmeter.reporters.MailerResultCollector 
> failed: java.io.NotSerializableException: java.lang.Thread
>      [java]     at 
> org.apache.jmeter.junit.JMeterTest.runSerialTest(JMeterTest.java:506)
>      [java]     at 
> sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
>      [java]     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      [java]     at 
> org.apache.jorphan.test.AllTests.main(AllTests.java:236)
>      [java] 2) 
> runSerialTest(org.apache.jmeter.junit.JMeterTest)junit.framework.AssertionFailedError:

> serialization of org.apache.jmeter.reporters.ResultCollector failed: 
> java.io.NotSerializableException: java.lang.Thread
>      [java]     at 
> org.apache.jmeter.junit.JMeterTest.runSerialTest(JMeterTest.java:506)
>      [java]     at 
> sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
>      [java]     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      [java]     at 
> org.apache.jorphan.test.AllTests.main(AllTests.java:236)
>      [java] FAILURES!!!
>      [java] Tests run: 2436,  Failures: 2,  Errors: 0
>
>

Since last commit, now the ant dist task works.

I've make the same simple test and it's works now. No results data lost.
Thanks

Milamber
>
>
>> Any other users watching this discussion are also welcome to test.
>>
>> Test case:
>>
>>     - Run a test
>>     - Call kill <PID> or CTRL+C during the run and see if you have 
>> results
>>
>> Note you can lose the results emitted during execution of Shutdown hook.
>> Regards
>> Philippe
>>
>> On Thu, May 9, 2013 at 1:41 PM, sebb <sebbaz@gmail.com> wrote:
>>
>>> On 9 May 2013 11:38, Milamber <milamber@apache.org> wrote:
>>>> Le 09/05/2013 11:31, sebb a ecrit :
>>>>
>>>>> On 9 May 2013 11:15, Milamber <milamber@apache.org> wrote:
>>>>>> Le 09/05/2013 10:45, sebb a ecrit :
>>>>>>
>>>>>>> I don't see any need to tidy up the properties.
>>>>>>>
>>>>>>> As to the autoflush, I agree that the default should be false,

>>>>>>> as that
>>>>>>> improves performance.
>>>>>>
>>>>>> I suppose you would says: the default should be true (activating
the
>>>>>> autoflush)?
>>>>>>
>>>>> No, I think the default should be false, as that improves performance
>>>>> for the normal case, and it is the original behaviour.
>>>>
>>>> In my mind, the original behavior (current in 2.9) is autoflush to 
>>>> true
>>>> (don't lost data).
>>> Sorry, I was wrong, you are correct.
>>> The original behaviour was autoflush = true as you say.
>>>
>>> Given that, I'm not 100% convinced we should change the behaviour.
>>>
>>> Maybe we can find a better way to improve the performance that reduces
>>> the possibility of lost output.
>>>
>>>>
>>>>
>>>>>>> Let's see if a shutdown hook works.
>>>>>>>
>>>>>>> On 9 May 2013 10:10, Milamber <milamber@apache.org> wrote:
>>>>>>>> Le 09/05/2013 09:32, Philippe Mouawad a ecrit :
>>>>>>>>
>>>>>>>>> On Thursday, May 9, 2013, Milamber wrote:
>>>>>>>>>
>>>>>>>>>> Le 09/05/2013 08:16, Philippe Mouawad a ecrit :
>>>>>>>>>>
>>>>>>>>>>> On Thursday, May 9, 2013, Milamber wrote:
>>>>>>>>>>>
>>>>>>>>>>>      Le 08/05/2013 23:03, Philippe Mouawad a
ecrit :
>>>>>>>>>>>>      Bad post, should have gone here
>>>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>>>> From: *Philippe Mouawad*
>>>>>>>>>>>>> Date: Wednesday, May 8, 2013
>>>>>>>>>>>>> Subject: jmeter.properties cleanup
>>>>>>>>>>>>> To: JMeter Users List <user@jmeter.apache.org>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> jmeter.properties has grown with a lot
of properties that 
>>>>>>>>>>>>> maybe
>>>>>>>>>>>>> are
>>>>>>>>>>>>> not
>>>>>>>>>>>>> that useful.
>>>>>>>>>>>>> I find it a good thing that lot of things
are configurable in
>>>>>>>>>>>>> JMeter
>>>>>>>>>>>>> but
>>>>>>>>>>>>> maybe it's too much and one of the issues
is users may not 
>>>>>>>>>>>>> find
>>>>>>>>>>>>> the
>>>>>>>>>>>>> really
>>>>>>>>>>>>> useful ones (recently for example with

>>>>>>>>>>>>> https.socket.protocols).
>>>>>>>>>>>>>
>>>>>>>>>>>>> I propose to remove the following:
>>>>>>>>>>>>>
>>>>>>>>>>>>>          - jmeter.loggerpanel.display=****false
=> It's so 
>>>>>>>>>>>>> easy
>>> to
>>>>>>>>>>>>> just
>>>>>>>>>>>>> click it
>>>>>>>>>>>>>          - jmeter.errorscounter.display=****true
=> Why would
>>>>>>>>>>>>> someone
>>>>>>>>>>>>> not
>>>>>>>>>>>>> want
>>>>>>>>>>>>> this
>>>>>>>>>>>>>          feature ?
>>>>>>>>>>>>>          - jmeter.toolbar.display=true
=> Why would 
>>>>>>>>>>>>> someone not
>>>>>>>>>>>>> want
>>>>>>>>>>>>> this
>>>>>>>>>>>>> cool
>>>>>>>>>>>>>          feature ?
>>>>>>>>>>>>>          - jmeter.toolbar => Will
users really want to 
>>>>>>>>>>>>> reorganize
>>>>>>>>>>>>> these
>>>>>>>>>>>>> icons ?
>>>>>>>>>>>>>          - jmeter.toolbar.icons =>
Same as before
>>>>>>>>>>>>>
>>>>>>>>>>>>>      If you are a JMeter plugins developer,
you may want to
>>>>>>>>>>>>> re-organize
>>>>>>>>>>>>> or
>>>>>>>>>>>> change the toolbar.
>>>>>>>>>>>>
>>>>>>>>>>>>           - onload.expandtree => Current
default behaviour 
>>>>>>>>>>>> seems
>>>>>>>>>>>> fine
>>>>>>>>>>>> no ?
>>>>>>>>>>>>
>>>>>>>>>>>>>          - jmeter.save.saveservice.****autoflush
=> After 
>>>>>>>>>>>>> some
>>>>>>>>>>>>> further
>>>>>>>>>>>>> thinking, why
>>>>>>>>>>>>>          would users not need this one
? If JMeter crashes 
>>>>>>>>>>>>> and
>>> some
>>>>>>>>>>>>> data
>>>>>>>>>>>>> is
>>>>>>>>>>>>> lost ,
>>>>>>>>>>>>>          then there are big chances that
the test was not 
>>>>>>>>>>>>> that
>>> fine
>>>>>>>>>>>>> before
>>>>>>>>>>>>> the
>>>>>>>>>>>>> crash.
>>>>>>>>>>>>>
>>>>>>>>>>>>>      No! I prefer (and I put) this property
to the value 
>>>>>>>>>>>>> "true" !
>>>>>>>>>>>>> If
>>>>>>>>>>>>> you
>>>>>>>>>>>> make a
>>>>>>>>>>>> simple load test and we stop the test with
a Ctrl-C, we lost a
>>> lot
>>>>>>>>>>>> of
>>>>>>>>>>>> results (with some tests in my case, I've
lost the *entire*
>>> results
>>>>>>>>>>>> (small
>>>>>>>>>>>> test of 5-10 min). Please don't touch this
property, and I
>>>>>>>>>>>> recommend
>>>>>>>>>>>> to
>>>>>>>>>>>> put
>>>>>>>>>>>> to true by default. It's a very annoying
behavior.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> We could introduce a  shutdown hook to handle
these Ctrl+C 
>>>>>>>>>>>> cases.
>>>>>>>>>>>>
>>>>>>>>>>> In my opinion it should be false as performances
for high
>>> throughput
>>>>>>>>>>> tests
>>>>>>>>>>> are way better. And imho default settings should
 be the most
>>>>>>>>>>> performing
>>>>>>>>>>> for a load testing tool  no ?
>>>>>>>>>>>
>>>>>>>>>> Not sure. A new JMeter user can be disoriented if
he don't 
>>>>>>>>>> see his
>>>>>>>>>> results.
>>>>>>>>>> I've prefer a reliable software that a more performance
software
>>>>>>>>>> which
>>>>>>>>>> can
>>>>>>>>>> loose my results.
>>>>>>>>> With shutdown hook you won't loose results as quit signal
will be
>>>>>>>>> trapped
>>>>>>>>> and we can flush the file, no ?
>>>>>>>>>
>>>>>>>>>> Perhaps, make this autoflush behavior more visible
in JMeter UI.
>>> For
>>>>>>>>>> example, add a checkbox in Test Plan (or a checkbox-menu)
to
>>>>>>>>>> enable/disable
>>>>>>>>>> this option. (and add a warning message when the
option is 
>>>>>>>>>> enabled
>>> :
>>>>>>>>>> "you
>>>>>>>>>> can lost some results if you stop the test with Ctrl-C")
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Do you think it s still needed with what  I described
above ?
>>>>>>>>> What was the scenario that made you lost some resuts
?
>>>>>>>>
>>>>>>>>
>>>>>>>> A simple scenario :
>>>>>>>>
>>>>>>>> Thread group with 1 / 1 / infinite loop
>>>>>>>>         |-- Java Sampler with 1000 ms delay
>>>>>>>>
>>>>>>>>
>>>>>>>> Launch JMeter in non-gui mode, with 30 sec and Ctrl-C :
>>>>>>>>
>>>>>>>> milamber@ender:~/opt/apache-jmeter-2.10-SNAPSHOT/bin$ ./jmeter

>>>>>>>> -n -t
>>>>>>>> ./lost-results.jmx -l myresults.csv
>>>>>>>> Creating summariser <summary>
>>>>>>>> Created the tree successfully using ./lost-results.jmx
>>>>>>>> Starting the test @ Thu May 09 10:05:23 WEST 2013 (1368090323095)
>>>>>>>> Waiting for possible shutdown message on port 4445
>>>>>>>> summary +      7 in     8s =    0.9/s Avg:  1076 Min:  1005

>>>>>>>> Max: 1162
>>>>>>>> Err:
>>>>>>>> 0 (0.00%) Active: 1 Started: 1 Finished: 0
>>>>>>>> summary +     27 in  30.2s =    0.9/s Avg:  1117 Min:  1023

>>>>>>>> Max: 1251
>>>>>>>> Err:
>>>>>>>> 0 (0.00%) Active: 1 Started: 1 Finished: 0
>>>>>>>> summary =     34 in    38s =    0.9/s Avg:  1108 Min:  1005

>>>>>>>> Max: 1251
>>>>>>>> Err:
>>>>>>>> 0 (0.00%)
>>>>>>>> ^C
>>>>>>>> milamber@ender:~/opt/apache-jmeter-2.10-SNAPSHOT/bin$ wc
-l
>>>>>>>> myresults.csv
>>>>>>>> 0 myresults.csv
>>>>>>>> milamber@ender:~/opt/apache-jmeter-2.10-SNAPSHOT/bin$ cat
>>> myresults.csv
>>>>>>>> <===
>>>>>>>> empty file
>>>>>>>> milamber@ender:~/opt/apache-jmeter-2.10-SNAPSHOT/bin$
>>>>>>>>
>>>>>>>> Not good in my opinion.
>>>>>>>>
>>>>>>>> Milamber
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Ok for the rest let's keep the statu quo if you
think all are
>>>>>>>>>>> needed.
>>>>>>>>>>>
>>>>>>>>>>>      I have doubts about those ones:
>>>>>>>>>>>>> # Netscape HTTP Cookie file
>>>>>>>>>>>>> cookies=cookies => What does it do
?
>>>>>>>>>>>>>
>>>>>>>>>>>>> We could try to remove them and if users
want them, we would
>>> have
>>>>>>>>>>>>> some
>>>>>>>>>>>>> bugzilla request to get them back.
>>>>>>>>>>>>>
>>>>>>>>>>>>>      If you remove these properties,
you introduce a lot of
>>>>>>>>>>>>> incompatibilty
>>>>>>>>>>>> changes and (in my opinion) you remove some
freedom of the 
>>>>>>>>>>>> user's
>>>>>>>>>>>> preferences. Please double check before remove.
>>>>>>>>>>>>
>>>>>>>>>>>> Milamber.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>
>>
>
>


Mime
View raw message