jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Java version check in jmeter script files - is it worth the maintenance effort?
Date Wed, 25 Feb 2015 02:03:28 GMT
On 24 February 2015 at 20:05, Felix Schumacher
<felix.schumacher@internetallee.de> wrote:
>
>
> Am 24. Februar 2015 20:43:28 MEZ, schrieb Milamber <milamber@apache.org>:
>>Hello,
>>
>>Please note, the mean reason to add the Java version check is to avoid
>>the Java 8 warning message:
>>Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
>>PermSize=64m;
>>support was removed in 8.0
>>Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
>>MaxPermSize=128m; support was removed in 8.0
>>
>>
>>Below the code for checking in bin/jmeter:
>>
>># Java 8 remove Permanent generation, don't settings the PermSize
>>if [ $current_version -lt "8" ]; then
>>    # Increase MaxPermSize if you use a lot of Javascript in your Test
>>Plan :
>>    PERM="-XX:PermSize=64m -XX:MaxPermSize=128m"
>>fi
>>
>>We can remove the Java version check, but the users with Java 8 will
>>have the warning message.
>>Or remove the permanent size config?

>
> I believe IBMs java would not even start with the perm size option.

In which case it would be better to just remove the option.

The -XX options should not be included in the default settings because
-XX is used for non-standard options.

> And since java 7 will reach its end of live soon (at least the public support from Oracle)
we should consider what to do next with the perm size option.
>
> I think it would be nice to factor out all memory related options into one variable,
that can be overridden easily by the user.
>
> On the original question of whether we should keep the logic to determine the java version:
let us keep it, if no one else complains.

The problem is that the Java version determination is expensive, and
it looks like it is not needed now anyway.

> Regards
> Felix
>
>>
>>Milamber
>>
>>
>>On 23/02/2015 22:32, Philippe Mouawad wrote:
>>> On Monday, February 23, 2015, sebb <sebbaz@gmail.com> wrote:
>>>
>>>> On 23 February 2015 at 19:57, Rainer Jung <rainer.jung@kippdata.de
>>>> <javascript:;>> wrote:
>>>>> Am 23.02.2015 um 19:36 schrieb sebb:
>>>>>> The Java version check in JMeter script files is somewhat fragile,
>>and
>>>>>> has to be maintained.
>>>>>>
>>>>>> Does it really provide enough benefit to keep it?
>>>>>
>>>>> IMHO currently there's no real necessity to remove it, or did you
>>find
>>>>> another problem with it? I suspect you ask, because there's always
>>exotic
>>>>> systems and writing portable shell scripts is a hard task and one
>>can't
>>>>> easily test them (because the platforms are not available).
>>>> As I recall, the scripts have already had to be updated at least
>>twice
>>>> to fix bugs in the Java checks.
>>>>
>>>> The risk is that additional bugs still exist which may mean the
>>script
>>>> won't work on some other platform.
>>>> Apart from the additional work needed, in the meantime the user may
>>>> not be able to use JMeter.
>>>>
>>>> It seems unnecessary effort to maintain a feature of the scripts
>>that
>>>> is not required for proper operation of JMeter.
>>>>
>>>> As far as I can tell, the only benefit is that users who don't have
>>>> the correct Java version on the path will get a nicer error message.
>>>> However every time the script is used, there are 4 invocations of
>>awk
>>>> and one of "java -version".
>>>> This is rather wasteful.
>>>>
>>>>
>>> No opinion on this.
>>>
>>>
>>>
>>>
>>> Seems to me that there are better ways to spend our time maintaining
>>JMeter.
>>>>> Since our requirements are very relaxed (Java 6), there's no big
>>use in
>>>> the
>>>>> version check either. In most cases the condition will be
>>fulfilled, so a
>>>>> clear documentation statement should suffice. I think currently the
>>info
>>>> is
>>>>> only on the download page and in the changelog. Maybe it could be
>>added
>>>> to
>>>>> the "a 100% pure Java application" sentence in the landing page and
>>in
>>>> the
>>>>> intro page of the users manual without bloating that pages to much.
>>>> Yes, that is a much better use of developer time.
>>>> Could also document the errors that are produced if the wrong JVM is
>>used.
>>>>
>>>>> So I'm fine with either keeping or removing the check, but I think
>>we
>>>> should
>>>>> place the requirement a little bit more prominent in the docs in
>>any
>>>> case.
>>>>
>>>> Agreed.
>>> Same opinion
>>> I think anyway that command line options where this could be added
>>should
>>> be isolated in a dedicated page.
>>> I always find myself searching for those.
>>>
>>> New users should find easily:
>>> - tool pre requisites
>>> - command line options
>>>
>>>
>>>
>>>
>>>>> Regards,
>>>>>
>>>>> Rainer
>>>>>
>>>
>

Mime
View raw message