Log level changes in GridCacheWriteBehindStore.updateStore

2019-08-25 Thread Sunny Chan, CLSA 
Hello,

In the 
GridCacheWriteBehindStore,
 when the updateStore failed to write to underlying store, it logs this as 
error:

LT.error(log, e, "Unable to update underlying store: " + store);

After this line logged the error, it would return false so that it would retry 
the store (by returning false).

While later on in the updatStore function, when the writeCache overflows, it 
would log this:

log.warning("Failed to update store (value will be lost as current buffer size 
is greater " + ...

then it will remove the failed entry.

I think the severity of the log messages is not right, as the fail update would 
still be retried.

So I propose to change the log severity level so that the first one would be a 
warn, and second one would be error. Is that acceptable?

Sunny Chan
Senior Lead Engineer, Executive Services
D  +852 2600 8907  |  M  +852 6386 1835  |  T  +852 2600 
5/F, One Island East, 18 Westlands Road, Island East, Hong Kong

[:1. Social Media Icons:CLSA_Social Media 
Icons_linkedin.png][:1. Social Media 
Icons:CLSA_Social Media 
Icons_twitter.png][:1. Social Media 
Icons:CLSA_Social Media 
Icons_youtube.png][:1.
 Social Media Icons:CLSA_Social Media 
Icons_facebook.png]

clsa.com
Insights. Liquidity. Capital.

[CLSA_RGB]

A CITIC Securities Company

The content of this communication is intended for the recipient and is subject 
to CLSA Legal and Regulatory Notices.
These can be viewed at https://www.clsa.com/disclaimer.html or sent to you upon 
request.
Please consider before printing. CLSA is ISO14001 certified and committed to 
reducing its impact on the environment.

Re: Replacing default work dir from tmp to current dir

2019-08-25 Thread Павлухин Иван 
Ilya,

2 points:
1. It is a good point that a directory name "work" in arbitrary place
can cause a lot of confusion.
2. As far as I got, default directory is not in e.g. /home/username
but in one pointed by "user.dir" system property which is a directory
where a java process started (if property was not overridden).

2019-08-26 1:59 GMT+11:00, Ilya Kasnacheev :
> 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 :
>
>> +1 for the user.dir as a default one.
>>
>> Denis
>>
>> On Monday, August 12, 2019, Dmitriy Pavlov  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 :
>> >
>> > > 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.darling...@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 
>> 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
>>
>


-- 
Best regards,
Ivan Pavlukhin

IGNITE-12018 Web Agent docker image: 'functions.sh' not found

2019-08-25 Thread Saikat Maitra 
Hello,

I have raised PR for the following issue

IGNITE-12018 Web Agent docker image: 'functions.sh' not found

Jira issue : https://issues.apache.org/jira/browse/IGNITE-12018

PR : https://github.com/apache/ignite/pull/6808

Please review and share feedback.

Regards,
Saikat

Re: Replacing default work dir from tmp to current dir

2019-08-25 Thread Ilya Kasnacheev 
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 :

> +1 for the user.dir as a default one.
>
> Denis
>
> On Monday, August 12, 2019, Dmitriy Pavlov  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 :
> >
> > > 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.darling...@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 
> 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
>