ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilya Kasnacheev <ilya.kasnach...@gmail.com>
Subject Re: Replacing default work dir from tmp to current dir
Date Sun, 25 Aug 2019 14:59:01 GMT
Hello!

I am really worried by the fact that previously we had /tmp/ignite and in
it work/, whereas now we're going to write to /home/username/work

I doubt that users can attribute work/ directory in their home to Ignite,
especially when it is used as library by something else.

Is there a chance we could move this work dir to /home/username/ignite with
work/ (and possibly logs/) dir in it? WDYT?

We could even auto-create README.TXT in this /home/username/ignite/ to
describe that it's Apache Ignite work directory and how to change it.

Regards,
-- 
Ilya Kasnacheev


пн, 12 авг. 2019 г. в 19:02, Denis Magda <dmagda@apache.org>:

> +1 for the user.dir as a default one.
>
> Denis
>
> On Monday, August 12, 2019, Dmitriy Pavlov <dpavlov@apache.org> wrote:
>
> > +1 to user home directory. A number of open source products create their
> > dirs there. For me, it is a kind of expected behavior.
> >
> > Ivan mentioned an important point: binary meta & marshaller. We should
> > update documentation and stop require PDS dir setup, but require home
> setup
> > (for older versions of Ignite, it is relevant anyway).
> >
> > пн, 12 авг. 2019 г. в 18:49, Pavel Tupitsyn <ptupitsyn@apache.org>:
> >
> > > Hi Ivan,
> > >
> > > >  fail Ignite node in case neither IGNITE_HOME
> > > nor IgniteConfiguration#igniteWorkDir is set
> > > I strongly disagree, this is bad usability.
> > > Ignition.start() should work without any extra configuration as is it
> > right
> > > now.
> > >
> > > Let's come up with reasonable defaults instead, user dir sounds good to
> > me.
> > >
> > > On Mon, Aug 12, 2019 at 6:45 PM Stephen Darlington <
> > > stephen.darlington@gridgain.com> wrote:
> > >
> > > > Yes, when data is a stake, fail early is the absolutely the right
> thing
> > > to
> > > > do.
> > > >
> > > > Regards,
> > > > Stephen
> > > >
> > > > > On 12 Aug 2019, at 16:37, Ivan Rakov <ivan.glukos@gmail.com>
> wrote:
> > > > >
> > > > > Hi Anton,
> > > > >
> > > > > Actually, the issue is even more unpleasant.
> > > > >
> > > > > Official Ignite documentation says that it's possible to configure
> > path
> > > > where your persistence files will be stored:
> > > > https://apacheignite.readme.io/docs/distributed-persistent-store
> > > > > However, even if you have set all path options (storage, WAL, WAL
> > > > archive), Ignite will still store crucial metadata in resolved work
> > > > directory (java.io.tmpdir by default). Example is binary metadata
> > files,
> > > > absence of which can make your data unavailable.
> > > > >
> > > > > I propose to fail Ignite node in case neither IGNITE_HOME nor
> > > > IgniteConfiguration#igniteWorkDir is set. It's better to let user
> know
> > > > about missing configuration options during startup than let OS
> corrupt
> > > > storage by cleaning temp dirs.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Best Regards,
> > > > > Ivan Rakov
> > > > >
> > > > > On 12.08.2019 18:10, Anton Kalashnikov wrote:
> > > > >> Hello, Igniters.
> > > > >>
> > > > >> Currently, in the case, when work directory wasn't set by user
> > ignite
> > > > can resolve it to tmp directory which leads to some problem - tmp
> > > directory
> > > > can be cleared at some unexpected moment by operation system and
> > > different
> > > > types of critical data would be lost(ex. binary_meta, persistance
> > data).
> > > > >>
> > > > >> Looks like it is not expected behaviour and maybe it is better
> > instead
> > > > of tmp directory use the current working directory("user.dir")? Or
> any
> > > > other idea?
> > > > >>
> > > > >> A little more details you can find in the ticket -
> > > > https://issues.apache.org/jira/browse/IGNITE-12057
> > > > >> --
> > > > >> Best regards,
> > > > >> Anton Kalashnikov
> > > > >>
> > > >
> > > >
> > > >
> > >
> >
>
>
> --
> -
> Denis
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message