I think we should still keep System property and Environment variable
check. Our product has a user base that depends on these properties and
changing them at will is not an option.
I do agree that the product should not start if IGNITE_HOME cannot be
calculated, but I still do not understand how this could be possible.
Setting it to TMP directory seems vary flaky and should be disabled.
This seems to be a blocker for 2.4 release and needs to be fixed. Do we
have an appropriate ticket for this?
D.
On Tue, Jan 30, 2018 at 2:52 AM, Stanislav Lukyanov <stanlukya...@gmail.com>
wrote:
> I checked the code handling the IGNITE_HOME and persistent storage paths,
> and here is what the algorithm looks like.
>
> For IGNITE_HOME the following is checked in order; if on any step a value
> is found then we use it.
> - IgniteHome in IgniteConfiguration
> - IGNITE_HOME system property
> - IGNITE_HOME environment variable
> - Current working directory (user.dir) and all its ancestors (all
> directories are checked to have “bin/” and “config/”)
> - Class path entry containing ignite-core classes and all its ancestors
>
> After that, the working directory will be created at one of the following
> paths
> - WorkingDirectory in IgniteConfiguration, if set
> - ${IGNITE_HOME}/work, if IGNITE_HOME could be calculated previously
> - ${java.io.tmpdir}/work
>
> Persistent storage will be stored in the working directory, unless
> StoragePath are specified in the config
> (same for WAL and WalPath).
>
> The issue here is that if we’ve ended up having persistent DB in the
> working directory in the /tmp,
> then persistence files will be cleared upon restart.
> Also, IgniteConfiguration::getIgniteHome claims that Igntie fails if
> IGNITE_HOME is not set, but that’s not the case.
>
> So, how about actually disallowing to run Ignite when IGNITE_HOME can’t be
> calculated? Using /tmp for working
> directory seems to be an obscure and potentially harmful scenario.
> IgniteConfiguration’s documentation can also be adjusted to specify actual
> steps used to find IgniteHome and WorkingDirectory
> if they aren’t set explicitly.
> Additionally, I’d suggest not to promote setting IGNITE_HOME system
> property and environment variable
> (e.g. let’s remove it from readmeio). IgniteConfiguration seems to be the
> most straightforward way to configure Ignite,
> and system properties should be used as a backup plan when convenient.
>
> WDYT?
>
> Thanks,
> Stan
>
> From: Denis Magda
> Sent: 30 января 2018 г. 3:38
> To: dev@ignite.apache.org
> Subject: Re: IGNITE_HOME for persistence
>
> No we don’t. I’ve never touched IGNITE_HOME variable for any other purpose.
>
> As it was suggested, the reported should share the project to reproduce
> his scenario.
>
> —
> Denis
>
> > On Jan 26, 2018, at 9:05 PM, Dmitriy Setrakyan <d...@gridgain.com> wrote:
> >
> > Igniters,
> >
> > I have just stumbled upon this post on SO:
> > https://stackoverflow.com/questions/48434929/apache-
> ignite-persistent-storage
> >
> > Do we require IGNITE_HOME to be set if the persistence is enabled? If
> yes,
> > do we check for it on startup?
> >
> > D.
>
>
>
