You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Данилов Семён <sa...@yandex.ru> on 2020/09/24 12:35:46 UTC
JVM_OPTS in control.sh and ignite.sh
Hello, Igniters!
I recently discovered, that control.sh and ignite.sh both use JVM_OPTS environment variable. This can lead to various issues (especially in docker), such as:
* Control utility will have the same xms/xmx parameters.
* Control utility won't launch due to JMX port being in use (as it is set in JVM_OPTS and already occupied by ignite).
And so on.
I suggest using different environment variable in control.sh (CONTROL_JVM_OPTS for example).
Here is the JIRA issue — https://issues.apache.org/jira/browse/IGNITE-13479
And a pull request — https://github.com/apache/ignite/pull/8275/
Regards, Semyon.
Re: JVM_OPTS in control.sh and ignite.sh
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
I think this is sensible approach, but please make sure that our
experimental features enabling patterns are unaffected.
Regards,
--
Ilya Kasnacheev
чт, 1 окт. 2020 г. в 14:45, Данилов Семён <sa...@yandex.ru>:
> Hello!
>
> I added message
> "JVM_OPTS environment variable is set, but will not be used. To pass JVM
> options use CONTROL_JVM_OPTS"
> "JVM_OPTS=${JVM_OPTS}"
> in both control.sh and control.bat files.
>
> Cheers, Sam.
>
> 28.09.2020, 16:56, "Ilya Kasnacheev" <il...@gmail.com>:
> > Hello!
> >
> > Can we at least print a warning when control.sh is run and JVM_OPTS is
> set?
> > Then you can use other env var. Or get rid of it and rely on -J<arg>.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> > пн, 28 сент. 2020 г. в 12:39, Данилов Семён <sa...@yandex.ru>:
> >
> >> Hello, everyone!
> >>
> >> Let's wrap this up somehow.
> >>
> >> I think that creating a different control.sh script for docker will
> create
> >> a precedent and we might end up with a plethora of scripts for
> different
> >> situations.
> >>
> >> Control.sh should be independent from ignite.sh thus using different
> set
> >> of environment variables seems like a viable option to me.
> >> Breaking compatibility isn't the best thing, yes, but in the same time,
> >> control.sh shouldn't really have used JVM_OPTS in the first place (and
> if
> >> you really must provide some JVM options, you'll still be able to do
> it via
> >> new variable).
> >>
> >> Cheers,
> >> Sam.
> >>
> >> 24.09.2020, 17:58, "Valentin Kulichenko" <
> valentin.kulichenko@gmail.com>:
> >> > Why does the control.sh use JVM_OPTS in the first place? Is there a
> case
> >> > when a user might need to modify them? I can't think of one.
> >> >
> >> > -Val
> >> >
> >> > On Thu, Sep 24, 2020 at 6:42 AM Evgenii Zhuravlev <
> >> e.zhuravlev.wk@gmail.com>
> >> > wrote:
> >> >
> >> >> Ilya,
> >> >>
> >> >> You can get absolutely the same behaviour when you set JVM_OPTS even
> >> >> without Docker.
> >> >>
> >> >> Evgenii
> >> >>
> >> >> чт, 24 сент. 2020 г. в 05:44, Ilya Kasnacheev <
> >> ilya.kasnacheev@gmail.com>:
> >> >>
> >> >> > Hello!
> >> >> >
> >> >> > If the issue is with docker only, then maybe we should get rid of
> >> >> JVM_OPTS
> >> >> > with docker entirely? E.g. pass them as parameters.
> >> >> >
> >> >> > I'm not sold on this change yet, it breaks backward compatibility
> for
> >> >> > marginal benefit.
> >> >> >
> >> >> > Regards,
> >> >> > --
> >> >> > Ilya Kasnacheev
> >> >> >
> >> >> >
> >> >> > чт, 24 сент. 2020 г. в 15:35, Данилов Семён <sa...@yandex.ru>:
> >> >> >
> >> >> > > Hello, Igniters!
> >> >> > >
> >> >> > > I recently discovered, that control.sh and ignite.sh both use
> >> JVM_OPTS
> >> >> > > environment variable. This can lead to various issues
> (especially
> >> in
> >> >> > > docker), such as:
> >> >> > > * Control utility will have the same xms/xmx parameters.
> >> >> > > * Control utility won't launch due to JMX port being in use (as
> it
> >> is
> >> >> set
> >> >> > > in JVM_OPTS and already occupied by ignite).
> >> >> > > And so on.
> >> >> > >
> >> >> > > I suggest using different environment variable in control.sh
> >> >> > > (CONTROL_JVM_OPTS for example).
> >> >> > >
> >> >> > > Here is the JIRA issue —
> >> >> > > https://issues.apache.org/jira/browse/IGNITE-13479
> >> >> > > And a pull request —
> https://github.com/apache/ignite/pull/8275/
> >> >> > >
> >> >> > > Regards, Semyon.
> >> >> > >
> >> >> >
>
Re: JVM_OPTS in control.sh and ignite.sh
Posted by Данилов Семён <sa...@yandex.ru>.
Hello!
I added message
"JVM_OPTS environment variable is set, but will not be used. To pass JVM options use CONTROL_JVM_OPTS"
"JVM_OPTS=${JVM_OPTS}"
in both control.sh and control.bat files.
Cheers, Sam.
28.09.2020, 16:56, "Ilya Kasnacheev" <il...@gmail.com>:
> Hello!
>
> Can we at least print a warning when control.sh is run and JVM_OPTS is set?
> Then you can use other env var. Or get rid of it and rely on -J<arg>.
>
> Regards,
> --
> Ilya Kasnacheev
>
> пн, 28 сент. 2020 г. в 12:39, Данилов Семён <sa...@yandex.ru>:
>
>> Hello, everyone!
>>
>> Let's wrap this up somehow.
>>
>> I think that creating a different control.sh script for docker will create
>> a precedent and we might end up with a plethora of scripts for different
>> situations.
>>
>> Control.sh should be independent from ignite.sh thus using different set
>> of environment variables seems like a viable option to me.
>> Breaking compatibility isn't the best thing, yes, but in the same time,
>> control.sh shouldn't really have used JVM_OPTS in the first place (and if
>> you really must provide some JVM options, you'll still be able to do it via
>> new variable).
>>
>> Cheers,
>> Sam.
>>
>> 24.09.2020, 17:58, "Valentin Kulichenko" <va...@gmail.com>:
>> > Why does the control.sh use JVM_OPTS in the first place? Is there a case
>> > when a user might need to modify them? I can't think of one.
>> >
>> > -Val
>> >
>> > On Thu, Sep 24, 2020 at 6:42 AM Evgenii Zhuravlev <
>> e.zhuravlev.wk@gmail.com>
>> > wrote:
>> >
>> >> Ilya,
>> >>
>> >> You can get absolutely the same behaviour when you set JVM_OPTS even
>> >> without Docker.
>> >>
>> >> Evgenii
>> >>
>> >> чт, 24 сент. 2020 г. в 05:44, Ilya Kasnacheev <
>> ilya.kasnacheev@gmail.com>:
>> >>
>> >> > Hello!
>> >> >
>> >> > If the issue is with docker only, then maybe we should get rid of
>> >> JVM_OPTS
>> >> > with docker entirely? E.g. pass them as parameters.
>> >> >
>> >> > I'm not sold on this change yet, it breaks backward compatibility for
>> >> > marginal benefit.
>> >> >
>> >> > Regards,
>> >> > --
>> >> > Ilya Kasnacheev
>> >> >
>> >> >
>> >> > чт, 24 сент. 2020 г. в 15:35, Данилов Семён <sa...@yandex.ru>:
>> >> >
>> >> > > Hello, Igniters!
>> >> > >
>> >> > > I recently discovered, that control.sh and ignite.sh both use
>> JVM_OPTS
>> >> > > environment variable. This can lead to various issues (especially
>> in
>> >> > > docker), such as:
>> >> > > * Control utility will have the same xms/xmx parameters.
>> >> > > * Control utility won't launch due to JMX port being in use (as it
>> is
>> >> set
>> >> > > in JVM_OPTS and already occupied by ignite).
>> >> > > And so on.
>> >> > >
>> >> > > I suggest using different environment variable in control.sh
>> >> > > (CONTROL_JVM_OPTS for example).
>> >> > >
>> >> > > Here is the JIRA issue —
>> >> > > https://issues.apache.org/jira/browse/IGNITE-13479
>> >> > > And a pull request — https://github.com/apache/ignite/pull/8275/
>> >> > >
>> >> > > Regards, Semyon.
>> >> > >
>> >> >
Re: JVM_OPTS in control.sh and ignite.sh
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
Can we at least print a warning when control.sh is run and JVM_OPTS is set?
Then you can use other env var. Or get rid of it and rely on -J<arg>.
Regards,
--
Ilya Kasnacheev
пн, 28 сент. 2020 г. в 12:39, Данилов Семён <sa...@yandex.ru>:
> Hello, everyone!
>
> Let's wrap this up somehow.
>
> I think that creating a different control.sh script for docker will create
> a precedent and we might end up with a plethora of scripts for different
> situations.
>
> Control.sh should be independent from ignite.sh thus using different set
> of environment variables seems like a viable option to me.
> Breaking compatibility isn't the best thing, yes, but in the same time,
> control.sh shouldn't really have used JVM_OPTS in the first place (and if
> you really must provide some JVM options, you'll still be able to do it via
> new variable).
>
> Cheers,
> Sam.
>
> 24.09.2020, 17:58, "Valentin Kulichenko" <va...@gmail.com>:
> > Why does the control.sh use JVM_OPTS in the first place? Is there a case
> > when a user might need to modify them? I can't think of one.
> >
> > -Val
> >
> > On Thu, Sep 24, 2020 at 6:42 AM Evgenii Zhuravlev <
> e.zhuravlev.wk@gmail.com>
> > wrote:
> >
> >> Ilya,
> >>
> >> You can get absolutely the same behaviour when you set JVM_OPTS even
> >> without Docker.
> >>
> >> Evgenii
> >>
> >> чт, 24 сент. 2020 г. в 05:44, Ilya Kasnacheev <
> ilya.kasnacheev@gmail.com>:
> >>
> >> > Hello!
> >> >
> >> > If the issue is with docker only, then maybe we should get rid of
> >> JVM_OPTS
> >> > with docker entirely? E.g. pass them as parameters.
> >> >
> >> > I'm not sold on this change yet, it breaks backward compatibility for
> >> > marginal benefit.
> >> >
> >> > Regards,
> >> > --
> >> > Ilya Kasnacheev
> >> >
> >> >
> >> > чт, 24 сент. 2020 г. в 15:35, Данилов Семён <sa...@yandex.ru>:
> >> >
> >> > > Hello, Igniters!
> >> > >
> >> > > I recently discovered, that control.sh and ignite.sh both use
> JVM_OPTS
> >> > > environment variable. This can lead to various issues (especially
> in
> >> > > docker), such as:
> >> > > * Control utility will have the same xms/xmx parameters.
> >> > > * Control utility won't launch due to JMX port being in use (as it
> is
> >> set
> >> > > in JVM_OPTS and already occupied by ignite).
> >> > > And so on.
> >> > >
> >> > > I suggest using different environment variable in control.sh
> >> > > (CONTROL_JVM_OPTS for example).
> >> > >
> >> > > Here is the JIRA issue —
> >> > > https://issues.apache.org/jira/browse/IGNITE-13479
> >> > > And a pull request — https://github.com/apache/ignite/pull/8275/
> >> > >
> >> > > Regards, Semyon.
> >> > >
> >> >
>
Re: JVM_OPTS in control.sh and ignite.sh
Posted by Данилов Семён <sa...@yandex.ru>.
Hello, everyone!
Let's wrap this up somehow.
I think that creating a different control.sh script for docker will create a precedent and we might end up with a plethora of scripts for different situations.
Control.sh should be independent from ignite.sh thus using different set of environment variables seems like a viable option to me.
Breaking compatibility isn't the best thing, yes, but in the same time, control.sh shouldn't really have used JVM_OPTS in the first place (and if you really must provide some JVM options, you'll still be able to do it via new variable).
Cheers,
Sam.
24.09.2020, 17:58, "Valentin Kulichenko" <va...@gmail.com>:
> Why does the control.sh use JVM_OPTS in the first place? Is there a case
> when a user might need to modify them? I can't think of one.
>
> -Val
>
> On Thu, Sep 24, 2020 at 6:42 AM Evgenii Zhuravlev <e....@gmail.com>
> wrote:
>
>> Ilya,
>>
>> You can get absolutely the same behaviour when you set JVM_OPTS even
>> without Docker.
>>
>> Evgenii
>>
>> чт, 24 сент. 2020 г. в 05:44, Ilya Kasnacheev <il...@gmail.com>:
>>
>> > Hello!
>> >
>> > If the issue is with docker only, then maybe we should get rid of
>> JVM_OPTS
>> > with docker entirely? E.g. pass them as parameters.
>> >
>> > I'm not sold on this change yet, it breaks backward compatibility for
>> > marginal benefit.
>> >
>> > Regards,
>> > --
>> > Ilya Kasnacheev
>> >
>> >
>> > чт, 24 сент. 2020 г. в 15:35, Данилов Семён <sa...@yandex.ru>:
>> >
>> > > Hello, Igniters!
>> > >
>> > > I recently discovered, that control.sh and ignite.sh both use JVM_OPTS
>> > > environment variable. This can lead to various issues (especially in
>> > > docker), such as:
>> > > * Control utility will have the same xms/xmx parameters.
>> > > * Control utility won't launch due to JMX port being in use (as it is
>> set
>> > > in JVM_OPTS and already occupied by ignite).
>> > > And so on.
>> > >
>> > > I suggest using different environment variable in control.sh
>> > > (CONTROL_JVM_OPTS for example).
>> > >
>> > > Here is the JIRA issue —
>> > > https://issues.apache.org/jira/browse/IGNITE-13479
>> > > And a pull request — https://github.com/apache/ignite/pull/8275/
>> > >
>> > > Regards, Semyon.
>> > >
>> >
Re: JVM_OPTS in control.sh and ignite.sh
Posted by Valentin Kulichenko <va...@gmail.com>.
Why does the control.sh use JVM_OPTS in the first place? Is there a case
when a user might need to modify them? I can't think of one.
-Val
On Thu, Sep 24, 2020 at 6:42 AM Evgenii Zhuravlev <e....@gmail.com>
wrote:
> Ilya,
>
> You can get absolutely the same behaviour when you set JVM_OPTS even
> without Docker.
>
> Evgenii
>
> чт, 24 сент. 2020 г. в 05:44, Ilya Kasnacheev <il...@gmail.com>:
>
> > Hello!
> >
> > If the issue is with docker only, then maybe we should get rid of
> JVM_OPTS
> > with docker entirely? E.g. pass them as parameters.
> >
> > I'm not sold on this change yet, it breaks backward compatibility for
> > marginal benefit.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > чт, 24 сент. 2020 г. в 15:35, Данилов Семён <sa...@yandex.ru>:
> >
> > > Hello, Igniters!
> > >
> > > I recently discovered, that control.sh and ignite.sh both use JVM_OPTS
> > > environment variable. This can lead to various issues (especially in
> > > docker), such as:
> > > * Control utility will have the same xms/xmx parameters.
> > > * Control utility won't launch due to JMX port being in use (as it is
> set
> > > in JVM_OPTS and already occupied by ignite).
> > > And so on.
> > >
> > > I suggest using different environment variable in control.sh
> > > (CONTROL_JVM_OPTS for example).
> > >
> > > Here is the JIRA issue —
> > > https://issues.apache.org/jira/browse/IGNITE-13479
> > > And a pull request — https://github.com/apache/ignite/pull/8275/
> > >
> > > Regards, Semyon.
> > >
> >
>
Re: JVM_OPTS in control.sh and ignite.sh
Posted by Evgenii Zhuravlev <e....@gmail.com>.
Ilya,
You can get absolutely the same behaviour when you set JVM_OPTS even
without Docker.
Evgenii
чт, 24 сент. 2020 г. в 05:44, Ilya Kasnacheev <il...@gmail.com>:
> Hello!
>
> If the issue is with docker only, then maybe we should get rid of JVM_OPTS
> with docker entirely? E.g. pass them as parameters.
>
> I'm not sold on this change yet, it breaks backward compatibility for
> marginal benefit.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 24 сент. 2020 г. в 15:35, Данилов Семён <sa...@yandex.ru>:
>
> > Hello, Igniters!
> >
> > I recently discovered, that control.sh and ignite.sh both use JVM_OPTS
> > environment variable. This can lead to various issues (especially in
> > docker), such as:
> > * Control utility will have the same xms/xmx parameters.
> > * Control utility won't launch due to JMX port being in use (as it is set
> > in JVM_OPTS and already occupied by ignite).
> > And so on.
> >
> > I suggest using different environment variable in control.sh
> > (CONTROL_JVM_OPTS for example).
> >
> > Here is the JIRA issue —
> > https://issues.apache.org/jira/browse/IGNITE-13479
> > And a pull request — https://github.com/apache/ignite/pull/8275/
> >
> > Regards, Semyon.
> >
>
Re: JVM_OPTS in control.sh and ignite.sh
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
If the issue is with docker only, then maybe we should get rid of JVM_OPTS
with docker entirely? E.g. pass them as parameters.
I'm not sold on this change yet, it breaks backward compatibility for
marginal benefit.
Regards,
--
Ilya Kasnacheev
чт, 24 сент. 2020 г. в 15:35, Данилов Семён <sa...@yandex.ru>:
> Hello, Igniters!
>
> I recently discovered, that control.sh and ignite.sh both use JVM_OPTS
> environment variable. This can lead to various issues (especially in
> docker), such as:
> * Control utility will have the same xms/xmx parameters.
> * Control utility won't launch due to JMX port being in use (as it is set
> in JVM_OPTS and already occupied by ignite).
> And so on.
>
> I suggest using different environment variable in control.sh
> (CONTROL_JVM_OPTS for example).
>
> Here is the JIRA issue —
> https://issues.apache.org/jira/browse/IGNITE-13479
> And a pull request — https://github.com/apache/ignite/pull/8275/
>
> Regards, Semyon.
>