You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by sebb <se...@gmail.com> on 2015/02/23 19:36:59 UTC
Java version check in jmeter script files - is it worth the
maintenance effort?
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?
Re: Java version check in jmeter script files - is it worth the
maintenance effort?
Posted by sebb <se...@gmail.com>.
On 24 February 2015 at 20:05, Felix Schumacher
<fe...@internetallee.de> wrote:
>
>
> Am 24. Februar 2015 20:43:28 MEZ, schrieb Milamber <mi...@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 <se...@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
>>>>>
>>>
>
Re: Java version check in jmeter script files - is it worth the maintenance effort?
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 24. Februar 2015 20:43:28 MEZ, schrieb Milamber <mi...@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.
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.
Regards
Felix
>
>Milamber
>
>
>On 23/02/2015 22:32, Philippe Mouawad wrote:
>> On Monday, February 23, 2015, sebb <se...@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
>>>>
>>
Re: Java version check in jmeter script files - is it worth
the maintenance effort?
Posted by Milamber <mi...@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?
Milamber
On 23/02/2015 22:32, Philippe Mouawad wrote:
> On Monday, February 23, 2015, sebb <se...@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
>>>
>
Re: Java version check in jmeter script files - is it worth the
maintenance effort?
Posted by Philippe Mouawad <ph...@gmail.com>.
On Monday, February 23, 2015, sebb <se...@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
> >
>
--
Cordialement.
Philippe Mouawad.
Re: Java version check in jmeter script files - is it worth the
maintenance effort?
Posted by sebb <se...@gmail.com>.
On 23 February 2015 at 19:57, Rainer Jung <ra...@kippdata.de> 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.
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.
> Regards,
>
> Rainer
>
Re: Java version check in jmeter script files - is it worth the maintenance
effort?
Posted by Rainer Jung <ra...@kippdata.de>.
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).
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.
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.
Regards,
Rainer