The temp dir is no way to go for the persistence.
I would enforce setting paths for the storage and WAL files if IGNITE_HOME
can't be calculated and we end up placing the storage files under the temp.dir.
Alex G., can you join this thread? Seems that there is an oversight on our side
that needs to be fixed in 2.4.
—
Denis
> On 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.
>
>
