Re: IEP-14: Ignite failures handling (Discussion)

[Vladimir Ozerov]

As far as shutdown, what we need to implement is “hard shutdown” mode. This
is when we first close all network sockets, then cancel all registered
futures. This would enough to unblock the cluster and local user threads.

ср, 14 марта 2018 г. в 8:40, Vladimir Ozerov :

> Valya,
>
> This is very easy to answer - if CommandLineStartup is used, then it is
> standalone node. In all other cases it is embedded.
>
> If node shutdown hangs - just let it continue hanging, so that application
> admins are able to decide on their own what to do next. Someone would want
> to get the stack trace, others would decide to restart outside of business
> hours (e.g. because Ignite is used only in part of their application),
> someone else would try to shutdown gracefully other components before
> stopping the process to minimize negative impact, etc.
>
> I am quite understand why are we guessing here how embedded Ignite is
> used. It could be used in any way and in any combination with other
> frameworks. Process stop by default is simply not an option.
>
> ср, 14 марта 2018 г. в 3:12, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
>> Ivan,
>>
>> If grid hangs, graceful shutdown would most likely hang as well. Almost
>> never you can recover from a bad state using graceful procedures.
>>
>> I agree that we should not create two defaults, especially in this case.
>> It's not even strictly defined what is embedded node in Ignite. For
>> example, if I start it using a custom main class and/or custom script
>> instead of ignite.sh, would it be embedded or standalone node?
>>
>> -Val
>>
>> On Tue, Mar 13, 2018 at 4:58 PM, Ivan Rakov 
>> wrote:
>>
>> > One more note: "kill if standalone, stop if embedded" differs from what
>> > you are suggesting "try graceful, then kill process regardless" only in
>> > case when graceful shutdown hangs.
>> > Do we have understanding, how often does graceful shutdown hang?
>> > Obviously, *grid hang* is often case, but it shouldn't be messed with
>> > *graceful shutdown hang*. From my experience, if something went wrong,
>> > users just prefer to do kill -9  because it's much more reliable and
>> easy.
>> > Probably, in most of cases when kill -9 worked, graceful stop would have
>> > worked as well - we just don't have such statistics.
>> > It may be bad example, but: in our CI tests we intentionally break grid
>> in
>> > many harsh ways and perform a graceful stop after the test execution,
>> and
>> > it doesn't hang - otherwise we'd see many "Execution timeout" test suite
>> > hangs.
>> >
>> > Best Regards,
>> > Ivan Rakov
>> >
>> >
>> > On 14.03.2018 2:24, Dmitriy Setrakyan wrote:
>> >
>> >> On Tue, Mar 13, 2018 at 7:13 PM, Ivan Rakov 
>> >> wrote:
>> >>
>> >> I just would like to add my +1 for "kill if standalone, stop if
>> embedded"
>> >>> default option. My arguments:
>> >>>
>> >>> 1) Regarding "If Ignite hangs - it will likely be impossible to stop":
>> >>> Unfortunately, it's true that Ignite can hang during stop procedure.
>> >>> However, most of failures described under IEP-14 (storage IO
>> exceptions,
>> >>> death of critical system worker thread, etc) normally shouldn't turn
>> node
>> >>> into "impossible to stop" state. Turning into that state is a bug
>> >>> itself. I
>> >>> guess that we shouldn't choose system behavior on the basis of known
>> >>> bugs.
>> >>>
>> >>
>> >> The whole discussion is about protecting against force-major issues,
>> >> including Ignite bugs. You are assuming that a user application will
>> >> somehow continue to function if an Ignite node is stopped. In most
>> cases
>> >> it
>> >> will just freeze itself and cause the rest of the application to hang.
>> >>
>> >> Again, "kill+stop" is the most deterministic and the safest default
>> >> behavior. Try a graceful shutdown (which will make restart easier), and
>> >> then kill the process regardless.
>> >>
>> >> Note that we are arguing about the default behavior. If a user does not
>> >> like this default, then this user can change it to another behavior.
>> >>
>> >>
>> >> 2) User might want to handle Ignite node crash before shutting down the
>> >>> whole JVM - raise alert, close external resources, etc
>> >>>
>> >>> Very unlikely, but if a user is this advanced, then this user can
>> change
>> >> the default behavior. Most users will not even know how to configure
>> such
>> >> custom shutdown behavior and would prefer an automatic kill.
>> >>
>> >> 3) IEP-14 document has important notes: "More than one Ignite node
>> could
>> >> be
>> >>
>> >>> started in one JVM process" and "Different nodes in one JVM process
>> could
>> >>> belong to different clusters". This is possible only in embedded
>> mode. I
>> >>> think, we shouldn't shock user by sudden JVM halt (possibly, along
>> with
>> >>> another healthy nodes) if there's a chance of successful node stop.
>> >>>
>> >>> Has anyone actually seen a real example of that? I have 

Re: IEP-14: Ignite failures handling (Discussion)

[Vladimir Ozerov]

Valya,

This is very easy to answer - if CommandLineStartup is used, then it is
standalone node. In all other cases it is embedded.

If node shutdown hangs - just let it continue hanging, so that application
admins are able to decide on their own what to do next. Someone would want
to get the stack trace, others would decide to restart outside of business
hours (e.g. because Ignite is used only in part of their application),
someone else would try to shutdown gracefully other components before
stopping the process to minimize negative impact, etc.

I am quite understand why are we guessing here how embedded Ignite is used.
It could be used in any way and in any combination with other frameworks.
Process stop by default is simply not an option.

ср, 14 марта 2018 г. в 3:12, Valentin Kulichenko <
valentin.kuliche...@gmail.com>:

> Ivan,
>
> If grid hangs, graceful shutdown would most likely hang as well. Almost
> never you can recover from a bad state using graceful procedures.
>
> I agree that we should not create two defaults, especially in this case.
> It's not even strictly defined what is embedded node in Ignite. For
> example, if I start it using a custom main class and/or custom script
> instead of ignite.sh, would it be embedded or standalone node?
>
> -Val
>
> On Tue, Mar 13, 2018 at 4:58 PM, Ivan Rakov  wrote:
>
> > One more note: "kill if standalone, stop if embedded" differs from what
> > you are suggesting "try graceful, then kill process regardless" only in
> > case when graceful shutdown hangs.
> > Do we have understanding, how often does graceful shutdown hang?
> > Obviously, *grid hang* is often case, but it shouldn't be messed with
> > *graceful shutdown hang*. From my experience, if something went wrong,
> > users just prefer to do kill -9  because it's much more reliable and
> easy.
> > Probably, in most of cases when kill -9 worked, graceful stop would have
> > worked as well - we just don't have such statistics.
> > It may be bad example, but: in our CI tests we intentionally break grid
> in
> > many harsh ways and perform a graceful stop after the test execution, and
> > it doesn't hang - otherwise we'd see many "Execution timeout" test suite
> > hangs.
> >
> > Best Regards,
> > Ivan Rakov
> >
> >
> > On 14.03.2018 2:24, Dmitriy Setrakyan wrote:
> >
> >> On Tue, Mar 13, 2018 at 7:13 PM, Ivan Rakov 
> >> wrote:
> >>
> >> I just would like to add my +1 for "kill if standalone, stop if
> embedded"
> >>> default option. My arguments:
> >>>
> >>> 1) Regarding "If Ignite hangs - it will likely be impossible to stop":
> >>> Unfortunately, it's true that Ignite can hang during stop procedure.
> >>> However, most of failures described under IEP-14 (storage IO
> exceptions,
> >>> death of critical system worker thread, etc) normally shouldn't turn
> node
> >>> into "impossible to stop" state. Turning into that state is a bug
> >>> itself. I
> >>> guess that we shouldn't choose system behavior on the basis of known
> >>> bugs.
> >>>
> >>
> >> The whole discussion is about protecting against force-major issues,
> >> including Ignite bugs. You are assuming that a user application will
> >> somehow continue to function if an Ignite node is stopped. In most cases
> >> it
> >> will just freeze itself and cause the rest of the application to hang.
> >>
> >> Again, "kill+stop" is the most deterministic and the safest default
> >> behavior. Try a graceful shutdown (which will make restart easier), and
> >> then kill the process regardless.
> >>
> >> Note that we are arguing about the default behavior. If a user does not
> >> like this default, then this user can change it to another behavior.
> >>
> >>
> >> 2) User might want to handle Ignite node crash before shutting down the
> >>> whole JVM - raise alert, close external resources, etc
> >>>
> >>> Very unlikely, but if a user is this advanced, then this user can
> change
> >> the default behavior. Most users will not even know how to configure
> such
> >> custom shutdown behavior and would prefer an automatic kill.
> >>
> >> 3) IEP-14 document has important notes: "More than one Ignite node could
> >> be
> >>
> >>> started in one JVM process" and "Different nodes in one JVM process
> could
> >>> belong to different clusters". This is possible only in embedded mode.
> I
> >>> think, we shouldn't shock user by sudden JVM halt (possibly, along with
> >>> another healthy nodes) if there's a chance of successful node stop.
> >>>
> >>> Has anyone actually seen a real example of that? I have not. This
> >> scenario
> >> is extremely unlikely and should not define the default behavior. Again,
> >> if
> >> a user is so advanced to come up with such a sophisticated deployment,
> >> then
> >> the same user should be able to set different default behaviors for
> >> different clusters.
> >>
> >>
> >
>

Re: Ignite contibutors page

[techbysample]

Denis,

Please add my name as well.

Best
Turik Campbell





--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: IEP-14: Ignite failures handling (Discussion)

[Nikolay Izhikov]

Dmitriy.

I think you and other participants of discussion are talking about different 
cases.

May be it be usefull to look at specific cases and discuss each of them 
separately?

I look at IEP page and see following:

```
File IO errors. Usually IOException's threw by read/write operations on file 
system. The following subsystems should be considered as critical:
* WAL
* Page store
* Meta store
* Binary meta store
```

Suppose, we ran out of disk space on some node.
The other things are all right.
Should we do `System.exit(-1);` in that case?

Personally, I fully agreed with Nick Podrash: 

"I can tell you as a user that if any library I was using in my application 
called System.exit without my consent would result in a lot of frustration."

Also, do you have any examples of other products that do `System.exit(-1);` in 
case of troubles?

В Вт, 13/03/2018 в 19:07 -0400, Dmitriy Setrakyan пишет:
> On Tue, Mar 13, 2018 at 6:55 PM, Dmitry Pavlov 
> wrote:
> 
> > What do you think if stop is default for all cases?
> > 
> > Kill is configurable.
> > 
> > We can consider enforse sockets close for 'stop'. This will allow to ignore
> > hang node by rest of the cluster.
> > 
> 
> Dmitriy, I see that you cannot come to terms with stopping a process that
> was not started by Ignite. However, in majority of the deployments, users
> would prefer that you would "kill" the process instead of leaving it
> running in a "frozen" state. Frozen state is non-deterministic and it is
> impossible to create a recovery for it. Killing the process is very
> deterministic and can be recovered by restarting it in most cases.
> 
> "stop" does not fix the problem we are trying to solve. The whole point is
> to prevent frozen state, and "stop" without "kill" does not prevent it. I
> am OK if "stop+kill" is the default behavior, which means that we try a
> graceful shutdown and then always kill the process anyway.
> 
> I think we should have the following configurable options:
> - "stop+kill" (default)
> - "kill"
> - "stop"
> - "stop+restart" (if stop fails, we should kill regardless)

signature.asc
Description: This is a digitally signed message part

Re: [jira] [Created] (IGNITE-7940) Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().

[Vasiliy Sisko]

Issue created. https://ggsystems.atlassian.net/browse/WC-454

On Wed, Mar 14, 2018 at 9:52 AM, Denis Magda  wrote:

> Alex,
>
> What's about Web Console? Have you created a similar ticket?
>
> On Tue, Mar 13, 2018 at 5:29 PM, Alexey Kuznetsov (JIRA) 
> wrote:
>
> > Alexey Kuznetsov created IGNITE-7940:
> > 
> >
> >  Summary: Visor CMD: Support cache.lostPartitions() and
> > ignite.resetLostPartitions().
> >  Key: IGNITE-7940
> >  URL: https://issues.apache.org/jira/browse/IGNITE-7940
> >  Project: Ignite
> >   Issue Type: Task
> >   Components: visor
> > Reporter: Alexey Kuznetsov
> > Assignee: Vasiliy Sisko
> >  Fix For: 2.5
> >
> >
> > See: https://apacheignite.readme.io/docs/partition-loss-policies
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v7.6.3#76005)
> >
>



-- 
Vasiliy Sisko
GridGain Systems
www.gridgain.com

[jira] [Created] (IGNITE-7941) Update dependencies to latest versions and migrate to caret(^) in package.json + package.json.lock

[Alexander Kalinin (JIRA)]

Alexander Kalinin created IGNITE-7941:
-

 Summary: Update dependencies to latest versions and migrate to 
caret(^) in package.json + package.json.lock 
 Key: IGNITE-7941
 URL: https://issues.apache.org/jira/browse/IGNITE-7941
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Alexander Kalinin
Assignee: Alexander Kalinin
 Fix For: 2.5


We should orgnized package.json files in way that latest stable dependencies 
are installed
 * move to caret versions notations.
 * add package.json.lock to git versioning.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: IEP-14: Ignite failures handling (Discussion)

[Nick Pordash]

I can tell you as a user that if any library I was using in my application
called System.exit without my consent would result in a lot of frustration.

If ignite enters an unrecoverable state then I think that is something that
should be observable locally, similar to node segmentation and then the
application can decide the best course of action.

Of course, if ignite was started as a standalone process do what you think
is best, but don't think you can kill the process without backlash from
users if it's running in embedded mode.

- Nick

On Tue, Mar 13, 2018, 5:12 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Ivan,
>
> If grid hangs, graceful shutdown would most likely hang as well. Almost
> never you can recover from a bad state using graceful procedures.
>
> I agree that we should not create two defaults, especially in this case.
> It's not even strictly defined what is embedded node in Ignite. For
> example, if I start it using a custom main class and/or custom script
> instead of ignite.sh, would it be embedded or standalone node?
>
> -Val
>
> On Tue, Mar 13, 2018 at 4:58 PM, Ivan Rakov  wrote:
>
> > One more note: "kill if standalone, stop if embedded" differs from what
> > you are suggesting "try graceful, then kill process regardless" only in
> > case when graceful shutdown hangs.
> > Do we have understanding, how often does graceful shutdown hang?
> > Obviously, *grid hang* is often case, but it shouldn't be messed with
> > *graceful shutdown hang*. From my experience, if something went wrong,
> > users just prefer to do kill -9  because it's much more reliable and
> easy.
> > Probably, in most of cases when kill -9 worked, graceful stop would have
> > worked as well - we just don't have such statistics.
> > It may be bad example, but: in our CI tests we intentionally break grid
> in
> > many harsh ways and perform a graceful stop after the test execution, and
> > it doesn't hang - otherwise we'd see many "Execution timeout" test suite
> > hangs.
> >
> > Best Regards,
> > Ivan Rakov
> >
> >
> > On 14.03.2018 2:24, Dmitriy Setrakyan wrote:
> >
> >> On Tue, Mar 13, 2018 at 7:13 PM, Ivan Rakov 
> >> wrote:
> >>
> >> I just would like to add my +1 for "kill if standalone, stop if
> embedded"
> >>> default option. My arguments:
> >>>
> >>> 1) Regarding "If Ignite hangs - it will likely be impossible to stop":
> >>> Unfortunately, it's true that Ignite can hang during stop procedure.
> >>> However, most of failures described under IEP-14 (storage IO
> exceptions,
> >>> death of critical system worker thread, etc) normally shouldn't turn
> node
> >>> into "impossible to stop" state. Turning into that state is a bug
> >>> itself. I
> >>> guess that we shouldn't choose system behavior on the basis of known
> >>> bugs.
> >>>
> >>
> >> The whole discussion is about protecting against force-major issues,
> >> including Ignite bugs. You are assuming that a user application will
> >> somehow continue to function if an Ignite node is stopped. In most cases
> >> it
> >> will just freeze itself and cause the rest of the application to hang.
> >>
> >> Again, "kill+stop" is the most deterministic and the safest default
> >> behavior. Try a graceful shutdown (which will make restart easier), and
> >> then kill the process regardless.
> >>
> >> Note that we are arguing about the default behavior. If a user does not
> >> like this default, then this user can change it to another behavior.
> >>
> >>
> >> 2) User might want to handle Ignite node crash before shutting down the
> >>> whole JVM - raise alert, close external resources, etc
> >>>
> >>> Very unlikely, but if a user is this advanced, then this user can
> change
> >> the default behavior. Most users will not even know how to configure
> such
> >> custom shutdown behavior and would prefer an automatic kill.
> >>
> >> 3) IEP-14 document has important notes: "More than one Ignite node could
> >> be
> >>
> >>> started in one JVM process" and "Different nodes in one JVM process
> could
> >>> belong to different clusters". This is possible only in embedded mode.
> I
> >>> think, we shouldn't shock user by sudden JVM halt (possibly, along with
> >>> another healthy nodes) if there's a chance of successful node stop.
> >>>
> >>> Has anyone actually seen a real example of that? I have not. This
> >> scenario
> >> is extremely unlikely and should not define the default behavior. Again,
> >> if
> >> a user is so advanced to come up with such a sophisticated deployment,
> >> then
> >> the same user should be able to set different default behaviors for
> >> different clusters.
> >>
> >>
> >
>

Re: [jira] [Created] (IGNITE-7940) Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().

[Denis Magda]

Alex,

What's about Web Console? Have you created a similar ticket?

On Tue, Mar 13, 2018 at 5:29 PM, Alexey Kuznetsov (JIRA) 
wrote:

> Alexey Kuznetsov created IGNITE-7940:
> 
>
>  Summary: Visor CMD: Support cache.lostPartitions() and
> ignite.resetLostPartitions().
>  Key: IGNITE-7940
>  URL: https://issues.apache.org/jira/browse/IGNITE-7940
>  Project: Ignite
>   Issue Type: Task
>   Components: visor
> Reporter: Alexey Kuznetsov
> Assignee: Vasiliy Sisko
>  Fix For: 2.5
>
>
> See: https://apacheignite.readme.io/docs/partition-loss-policies
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>

Re: Partition recovery issue on partition loss.

[Valentin Kulichenko]

This indeed looks like a bigger issue. Basically, there is no clear way (or
no way at all) to synchronize code that listens to partition loss event,
and the code that calls resetLostPartitions() method. Example scenario:

1. Cache is configured with 3rd party persistence.
2. One or more nodes fail causing loss of several partitions in memory.
3. Ignite blocks access to those partitions according to partition loss
policy and fires an event.
4. Application listens to the event and starts reloading the data from
store.
5. When reloading is complete, application calls resetLostPartitions() to
restore access.
6. Nodes fail again causing another partition loss, new event is fired.

There is race between steps 5 and 6. If 2nd failure happens BEFORE
resetLostPartitions() is called, we end up with inconsistent data.

I believe the only way to fix this is to add corresponding topology version
to partition loss event, and also add it as a parameter for
resetLostPartitions().
This way if resetLostPartitions() is invoked with a version that is not the
latest anymore, the invocation will be ignored.

The only problem with this approach  is that topology version itself is
currently not a part of public API. It needs to be properly exposed there
first.

-Val

On Mon, Mar 12, 2018 at 1:07 PM, Denis Magda  wrote:

> Just in case here is you can find the present documentation:
> https://apacheignite.readme.io/docs/cache-modes#partition-loss-policies
>
> Let us know what needs to be updated once the issues reported by you are
> addressed.
>
> --
> Denis
>
> On Mon, Mar 12, 2018 at 3:33 AM, Andrey Mashenkov <
> andrey.mashen...@gmail.com> wrote:
>
> > Hi Igniters,
> >
> > I've found we no documentation how user can recover cache from cacheStore
> > in case of partition loss.
> > Ignite provides some instruments (methods and events) that should help
> user
> > to solve this problem,
> > but looks like these instruments have an architecture lack.
> >
> > The first one is an usability issue. Ignite provides partition loss event
> > to user can handle this, but Ignite fires an event per partition.
> > Why we can't have an event with list of lost partitions?
> >
> > The second one is a bug. Ignite.resetLostPartitions() method doesn't care
> > about what topology version recovered partitions belonged to.
> > Tthere is a race, when user call this method after a node was failed, but
> > right before Ignite fire an event.
> > So, it is possible state of just lost partitions will be reseted
> > unexpectedly.
> >
> >
> > I've created a ticket for this [1] and think we should rethink the
> > architecture of the partition recovery mechanics and improve
> documentation.
> > Any thoughts?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-7832
> >
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
> >
>

Re: Partition loss policy - how to use?

[Alexey Kuznetsov]

 Gaurav,

I think it make sense to add this for tools.
Created issue: https://issues.apache.org/jira/browse/IGNITE-7940

On Wed, Mar 14, 2018 at 1:44 AM, Gaurav Bajaj 
wrote:

> Hi Denis,
> Thanks. Document certainly looks useful. Do we have ticket for improvement
> in Webconsole/Visor for marking resetLostPartitions()?
>
>
> Regards,
> Gaurav
>
> On 13-Mar-2018 7:42 PM, "Denis Magda"  wrote:
>
> For those interested, here is a doc we put together for the partition
> policies which considers extra improvements released in 2.4:
> https://apacheignite.readme.io/v2.4/docs/partition-loss-policies
>
> --
> Denis
>
> On Tue, Mar 6, 2018 at 11:19 AM, Denis Magda  wrote:
>
> > Hi,
> >
> > Here is documentation we prepared for 2.4 release: https://apacheignite.
> > readme.io/v2.3/docs/cache-modes-24#partition-loss-policies
> >
> > It's hidden for now and will become visible to everyone once Ignite 2.4
> > vote passes (in progress).
> >
> > --
> > Denis
> >
> > On Tue, Mar 6, 2018 at 6:59 AM, gauravhb  wrote:
> >
> >> Hi,
> >>
> >> Is there any update on this topic?
> >> Any tickets created for points mentioned by Valentin?
> >>
> >> Thanks.
> >>
> >>
> >>
> >> --
> >> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> >>
> >
> >
>



-- 
Alexey Kuznetsov

[jira] [Created] (IGNITE-7940) Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-7940:


 Summary: Visor CMD: Support cache.lostPartitions() and 
ignite.resetLostPartitions().
 Key: IGNITE-7940
 URL: https://issues.apache.org/jira/browse/IGNITE-7940
 Project: Ignite
  Issue Type: Task
  Components: visor
Reporter: Alexey Kuznetsov
Assignee: Vasiliy Sisko
 Fix For: 2.5


See: https://apacheignite.readme.io/docs/partition-loss-policies



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: IEP-14: Ignite failures handling (Discussion)

[Valentin Kulichenko]

Ivan,

If grid hangs, graceful shutdown would most likely hang as well. Almost
never you can recover from a bad state using graceful procedures.

I agree that we should not create two defaults, especially in this case.
It's not even strictly defined what is embedded node in Ignite. For
example, if I start it using a custom main class and/or custom script
instead of ignite.sh, would it be embedded or standalone node?

-Val

On Tue, Mar 13, 2018 at 4:58 PM, Ivan Rakov  wrote:

> One more note: "kill if standalone, stop if embedded" differs from what
> you are suggesting "try graceful, then kill process regardless" only in
> case when graceful shutdown hangs.
> Do we have understanding, how often does graceful shutdown hang?
> Obviously, *grid hang* is often case, but it shouldn't be messed with
> *graceful shutdown hang*. From my experience, if something went wrong,
> users just prefer to do kill -9  because it's much more reliable and easy.
> Probably, in most of cases when kill -9 worked, graceful stop would have
> worked as well - we just don't have such statistics.
> It may be bad example, but: in our CI tests we intentionally break grid in
> many harsh ways and perform a graceful stop after the test execution, and
> it doesn't hang - otherwise we'd see many "Execution timeout" test suite
> hangs.
>
> Best Regards,
> Ivan Rakov
>
>
> On 14.03.2018 2:24, Dmitriy Setrakyan wrote:
>
>> On Tue, Mar 13, 2018 at 7:13 PM, Ivan Rakov 
>> wrote:
>>
>> I just would like to add my +1 for "kill if standalone, stop if embedded"
>>> default option. My arguments:
>>>
>>> 1) Regarding "If Ignite hangs - it will likely be impossible to stop":
>>> Unfortunately, it's true that Ignite can hang during stop procedure.
>>> However, most of failures described under IEP-14 (storage IO exceptions,
>>> death of critical system worker thread, etc) normally shouldn't turn node
>>> into "impossible to stop" state. Turning into that state is a bug
>>> itself. I
>>> guess that we shouldn't choose system behavior on the basis of known
>>> bugs.
>>>
>>
>> The whole discussion is about protecting against force-major issues,
>> including Ignite bugs. You are assuming that a user application will
>> somehow continue to function if an Ignite node is stopped. In most cases
>> it
>> will just freeze itself and cause the rest of the application to hang.
>>
>> Again, "kill+stop" is the most deterministic and the safest default
>> behavior. Try a graceful shutdown (which will make restart easier), and
>> then kill the process regardless.
>>
>> Note that we are arguing about the default behavior. If a user does not
>> like this default, then this user can change it to another behavior.
>>
>>
>> 2) User might want to handle Ignite node crash before shutting down the
>>> whole JVM - raise alert, close external resources, etc
>>>
>>> Very unlikely, but if a user is this advanced, then this user can change
>> the default behavior. Most users will not even know how to configure such
>> custom shutdown behavior and would prefer an automatic kill.
>>
>> 3) IEP-14 document has important notes: "More than one Ignite node could
>> be
>>
>>> started in one JVM process" and "Different nodes in one JVM process could
>>> belong to different clusters". This is possible only in embedded mode. I
>>> think, we shouldn't shock user by sudden JVM halt (possibly, along with
>>> another healthy nodes) if there's a chance of successful node stop.
>>>
>>> Has anyone actually seen a real example of that? I have not. This
>> scenario
>> is extremely unlikely and should not define the default behavior. Again,
>> if
>> a user is so advanced to come up with such a sophisticated deployment,
>> then
>> the same user should be able to set different default behaviors for
>> different clusters.
>>
>>
>

Re: IEP-14: Ignite failures handling (Discussion)

[Ivan Rakov]

One more note: "kill if standalone, stop if embedded" differs from what 
you are suggesting "try graceful, then kill process regardless" only in 
case when graceful shutdown hangs.
Do we have understanding, how often does graceful shutdown hang? 
Obviously, *grid hang* is often case, but it shouldn't be messed with 
*graceful shutdown hang*. From my experience, if something went wrong, 
users just prefer to do kill -9  because it's much more reliable and 
easy. Probably, in most of cases when kill -9 worked, graceful stop 
would have worked as well - we just don't have such statistics.
It may be bad example, but: in our CI tests we intentionally break grid 
in many harsh ways and perform a graceful stop after the test execution, 
and it doesn't hang - otherwise we'd see many "Execution timeout" test 
suite hangs.


Best Regards,
Ivan Rakov

On 14.03.2018 2:24, Dmitriy Setrakyan wrote:

On Tue, Mar 13, 2018 at 7:13 PM, Ivan Rakov  wrote:


I just would like to add my +1 for "kill if standalone, stop if embedded"
default option. My arguments:

1) Regarding "If Ignite hangs - it will likely be impossible to stop":
Unfortunately, it's true that Ignite can hang during stop procedure.
However, most of failures described under IEP-14 (storage IO exceptions,
death of critical system worker thread, etc) normally shouldn't turn node
into "impossible to stop" state. Turning into that state is a bug itself. I
guess that we shouldn't choose system behavior on the basis of known bugs.


The whole discussion is about protecting against force-major issues,
including Ignite bugs. You are assuming that a user application will
somehow continue to function if an Ignite node is stopped. In most cases it
will just freeze itself and cause the rest of the application to hang.

Again, "kill+stop" is the most deterministic and the safest default
behavior. Try a graceful shutdown (which will make restart easier), and
then kill the process regardless.

Note that we are arguing about the default behavior. If a user does not
like this default, then this user can change it to another behavior.



2) User might want to handle Ignite node crash before shutting down the
whole JVM - raise alert, close external resources, etc


Very unlikely, but if a user is this advanced, then this user can change
the default behavior. Most users will not even know how to configure such
custom shutdown behavior and would prefer an automatic kill.

3) IEP-14 document has important notes: "More than one Ignite node could be

started in one JVM process" and "Different nodes in one JVM process could
belong to different clusters". This is possible only in embedded mode. I
think, we shouldn't shock user by sudden JVM halt (possibly, along with
another healthy nodes) if there's a chance of successful node stop.


Has anyone actually seen a real example of that? I have not. This scenario
is extremely unlikely and should not define the default behavior. Again, if
a user is so advanced to come up with such a sophisticated deployment, then
the same user should be able to set different default behaviors for
different clusters.

Re: IEP-14: Ignite failures handling (Discussion)

[Dmitriy Setrakyan]

On Tue, Mar 13, 2018 at 7:13 PM, Ivan Rakov  wrote:

> I just would like to add my +1 for "kill if standalone, stop if embedded"
> default option. My arguments:
>
> 1) Regarding "If Ignite hangs - it will likely be impossible to stop":
> Unfortunately, it's true that Ignite can hang during stop procedure.
> However, most of failures described under IEP-14 (storage IO exceptions,
> death of critical system worker thread, etc) normally shouldn't turn node
> into "impossible to stop" state. Turning into that state is a bug itself. I
> guess that we shouldn't choose system behavior on the basis of known bugs.


The whole discussion is about protecting against force-major issues,
including Ignite bugs. You are assuming that a user application will
somehow continue to function if an Ignite node is stopped. In most cases it
will just freeze itself and cause the rest of the application to hang.

Again, "kill+stop" is the most deterministic and the safest default
behavior. Try a graceful shutdown (which will make restart easier), and
then kill the process regardless.

Note that we are arguing about the default behavior. If a user does not
like this default, then this user can change it to another behavior.


> 2) User might want to handle Ignite node crash before shutting down the
> whole JVM - raise alert, close external resources, etc
>

Very unlikely, but if a user is this advanced, then this user can change
the default behavior. Most users will not even know how to configure such
custom shutdown behavior and would prefer an automatic kill.

3) IEP-14 document has important notes: "More than one Ignite node could be
> started in one JVM process" and "Different nodes in one JVM process could
> belong to different clusters". This is possible only in embedded mode. I
> think, we shouldn't shock user by sudden JVM halt (possibly, along with
> another healthy nodes) if there's a chance of successful node stop.
>

Has anyone actually seen a real example of that? I have not. This scenario
is extremely unlikely and should not define the default behavior. Again, if
a user is so advanced to come up with such a sophisticated deployment, then
the same user should be able to set different default behaviors for
different clusters.

Re: IEP-14: Ignite failures handling (Discussion)

[Ivan Rakov]

I just would like to add my +1 for "kill if standalone, stop if 
embedded" default option. My arguments:


1) Regarding "If Ignite hangs - it will likely be impossible to stop":
Unfortunately, it's true that Ignite can hang during stop procedure. 
However, most of failures described under IEP-14 (storage IO exceptions, 
death of critical system worker thread, etc) normally shouldn't turn 
node into "impossible to stop" state. Turning into that state is a bug 
itself. I guess that we shouldn't choose system behavior on the basis of 
known bugs.


2) User might want to handle Ignite node crash before shutting down the 
whole JVM - raise alert, close external resources, etc


3) IEP-14 document has important notes: "More than one Ignite node could 
be started in one JVM process" and "Different nodes in one JVM process 
could belong to different clusters". This is possible only in embedded 
mode. I think, we shouldn't shock user by sudden JVM halt (possibly, 
along with another healthy nodes) if there's a chance of successful node 
stop.


Best Regards,
Ivan Rakov

On 14.03.2018 1:47, Dmitriy Setrakyan wrote:

Guys, I do not think there is an understanding here. If Ignite hangs - it
will likely be impossible to stop. So if you are suggesting "stop if
embedded", you might as well suggest "do nothing if embedded".

I have seen many Ignite deployments, embedded or not, large and small, and
in all those deployments if Ignite went into a frozen state, killing it was
the best option. Moreover, it provided the most predictable behavior. I am
not guessing here, but it seems to me that the rest of the community is
guessing.

Killing a frozen Ignite node should be a default behavior in all cases,
embedded or not. Stopping a frozen Ignite node should be a configurable
option, so a user has an ability to turn off auto-kill behavior. We should
also have a 3rd option, "stop+kill", so if stopping fails, then the process
is automatically killed (this is also a good default option).

Personally, I am OK if the default behavior is "kill" or "stop+kill", but
it should be the same default in all cases. We should stop the practice of
creating different default behaviors for the same problem. It is confusing
and hard to document.

D.

On Tue, Mar 13, 2018 at 2:19 PM, Denis Magda  wrote:


+1 for "kill if standalone, stop if embedded" behavior. If the practice
shows that the node should be killed regardless of the mode, then it will
be an easy change. Now we are just guessing, and common sense suggests
going for "kill if standalone, stop if embedded" until we get feedback.

-
Denis

On Tue, Mar 13, 2018 at 8:30 AM, Dmitry Pavlov 
wrote:


You are suggesting to kill the process, which was not started by Ignite,
are not you?

More consistently is to stop only those processes that are generated by

the

control of Ignite, e.g. from ignite.sh - here it is ok for me.

If we relese 'kill by default' as part of 2.5, we will end up with 2.6
emergency release to change it back, if one user will face with such
unexpected behaviour.

вт, 13 мар. 2018 г. в 18:17, Dmitriy Setrakyan :


Dmitriy,

I think everyone is suggesting that stopping the node will likely be
impossible if Ignite is frozen. Moreover, it is very likely that all

other

apps are frozen too.

My comments are below...

On Tue, Mar 13, 2018 at 9:12 AM, Dmitry Pavlov 
wrote:


Please consider that user application may use Ignite as optional

cache

for

some low-priority feature, but main logic is well functioning without
Ingnite. I can say, as Ignite user in the past, that it is quite real

case.
I have been a part of this project for a while, but I have never seen
Ignite used as an optional cache. Usually, Ignite is a mandatory part

of

the application, not optional.



Second real case is using several war files within one application

server,

running different logic. Some apps use Ignite, some applications -

not.

Killing application server in this case is not an option too.


Not very likely, but possible. This is not a common use case. Most

commonly

Ignite would be serving all WAR files with a common data layer.



So default should be stopping all node threads, but not kill the

process.

If user is aware process may be killed, it may setup option.


No, the default should be to kill the process. If user does not like

it,

then it should be possible to change it to stop the node first.



вт, 13 мар. 2018 г. в 15:24, Dmitriy Setrakyan <

dsetrak...@apache.org

:

On Tue, Mar 13, 2018 at 8:16 AM, Dmitry Pavlov <

dpavlov@gmail.com>

wrote:


Dmitriy, alternative is "kill if standalone, stop if embedded"



User will be still able to set something like
-DNODE_CRASH_ACTION="kill"
if ignite.sh is not used and user accepts alternative that whole

process

would be killed if node is crashed.

Default would be 'node stop', but not hang up infinetely.


Dmitriy, if Ignite if frozen, 

Re: IGNITE_HOME for persistence

[Dmitriy Setrakyan]

On Tue, Mar 13, 2018 at 7:01 PM, Dmitry Pavlov 
wrote:

> Hi,
>
> do we have a task to print this warning message?
>
> It seems we don't print warning currently.
>

I do not think we have a ticket. As AG mentioned, this is an issue for
cases when persistence is disabled as well. Dmitriy, do you mind creating
one and assigning it to 2.5 release?

Re: IEP-14: Ignite failures handling (Discussion)

[Dmitriy Setrakyan]

On Tue, Mar 13, 2018 at 6:55 PM, Dmitry Pavlov 
wrote:

> What do you think if stop is default for all cases?
>
> Kill is configurable.
>
> We can consider enforse sockets close for 'stop'. This will allow to ignore
> hang node by rest of the cluster.
>

Dmitriy, I see that you cannot come to terms with stopping a process that
was not started by Ignite. However, in majority of the deployments, users
would prefer that you would "kill" the process instead of leaving it
running in a "frozen" state. Frozen state is non-deterministic and it is
impossible to create a recovery for it. Killing the process is very
deterministic and can be recovered by restarting it in most cases.

"stop" does not fix the problem we are trying to solve. The whole point is
to prevent frozen state, and "stop" without "kill" does not prevent it. I
am OK if "stop+kill" is the default behavior, which means that we try a
graceful shutdown and then always kill the process anyway.

I think we should have the following configurable options:
- "stop+kill" (default)
- "kill"
- "stop"
- "stop+restart" (if stop fails, we should kill regardless)

Re: IGNITE_HOME for persistence

[Dmitry Pavlov]

Hi,

do we have a task to print this warning message?

It seems we don't print warning currently.

Sincerely,
Dmitry Pavlov

ср, 31 янв. 2018 г., 0:55 Dmitriy Setrakyan :

> I think at this point all we can do is print a warning. However, starting
> with 3.0, we should require IGNITE_HOME to be set if we cannot determine it
> automatically. Do we print a warning already?
>
> On Tue, Jan 30, 2018 at 12:55 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > Denis, Dmitriy,
> >
> > I do not think the behavior should be in any way specific to the case
> when
> > persistence is enabled. We have quite a bit of other information (such as
> > binary marshaller metadata and marshaller class mappings) that are also
> > stored in the work folder and may be required after the cluster restart,
> > moreover, this has been so for years since ignite 1.0.
> >
> > If you think this is a blocker, please suggest what behavior we want to
> see
> > in ignite 2.4. We cannot calculate IGNITE_HOME when Ignite is run in an
> > embedded mode (in other words, the Ignite distribution package structure
> is
> > not preserved). Printing a warning in this case looks good enough for me.
> >
> > 2018-01-30 23:35 GMT+03:00 Denis Magda :
> >
> > > 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 
> > 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.
> > > >
> > > >
> > >
> > >
> >
>

Re: IEP-14: Ignite failures handling (Discussion)

[Dmitry Pavlov]

What do you think if stop is default for all cases?

Kill is configurable.

We can consider enforse sockets close for 'stop'. This will allow to ignore
hang node by rest of the cluster.

ср, 14 мар. 2018 г., 1:48 Dmitriy Setrakyan :

> Guys, I do not think there is an understanding here. If Ignite hangs - it
> will likely be impossible to stop. So if you are suggesting "stop if
> embedded", you might as well suggest "do nothing if embedded".
>
> I have seen many Ignite deployments, embedded or not, large and small, and
> in all those deployments if Ignite went into a frozen state, killing it was
> the best option. Moreover, it provided the most predictable behavior. I am
> not guessing here, but it seems to me that the rest of the community is
> guessing.
>
> Killing a frozen Ignite node should be a default behavior in all cases,
> embedded or not. Stopping a frozen Ignite node should be a configurable
> option, so a user has an ability to turn off auto-kill behavior. We should
> also have a 3rd option, "stop+kill", so if stopping fails, then the process
> is automatically killed (this is also a good default option).
>
> Personally, I am OK if the default behavior is "kill" or "stop+kill", but
> it should be the same default in all cases. We should stop the practice of
> creating different default behaviors for the same problem. It is confusing
> and hard to document.
>
> D.
>
> On Tue, Mar 13, 2018 at 2:19 PM, Denis Magda  wrote:
>
> > +1 for "kill if standalone, stop if embedded" behavior. If the practice
> > shows that the node should be killed regardless of the mode, then it will
> > be an easy change. Now we are just guessing, and common sense suggests
> > going for "kill if standalone, stop if embedded" until we get feedback.
> >
> > -
> > Denis
> >
> > On Tue, Mar 13, 2018 at 8:30 AM, Dmitry Pavlov 
> > wrote:
> >
> > > You are suggesting to kill the process, which was not started by
> Ignite,
> > > are not you?
> > >
> > > More consistently is to stop only those processes that are generated by
> > the
> > > control of Ignite, e.g. from ignite.sh - here it is ok for me.
> > >
> > > If we relese 'kill by default' as part of 2.5, we will end up with 2.6
> > > emergency release to change it back, if one user will face with such
> > > unexpected behaviour.
> > >
> > > вт, 13 мар. 2018 г. в 18:17, Dmitriy Setrakyan  >:
> > >
> > > > Dmitriy,
> > > >
> > > > I think everyone is suggesting that stopping the node will likely be
> > > > impossible if Ignite is frozen. Moreover, it is very likely that all
> > > other
> > > > apps are frozen too.
> > > >
> > > > My comments are below...
> > > >
> > > > On Tue, Mar 13, 2018 at 9:12 AM, Dmitry Pavlov <
> dpavlov@gmail.com>
> > > > wrote:
> > > >
> > > > > Please consider that user application may use Ignite as optional
> > cache
> > > > for
> > > > > some low-priority feature, but main logic is well functioning
> without
> > > > > Ingnite. I can say, as Ignite user in the past, that it is quite
> real
> > > > case.
> > > > >
> > > >
> > > > I have been a part of this project for a while, but I have never seen
> > > > Ignite used as an optional cache. Usually, Ignite is a mandatory part
> > of
> > > > the application, not optional.
> > > >
> > > >
> > > > > Second real case is using several war files within one application
> > > > server,
> > > > > running different logic. Some apps use Ignite, some applications -
> > not.
> > > > > Killing application server in this case is not an option too.
> > > > >
> > > >
> > > > Not very likely, but possible. This is not a common use case. Most
> > > commonly
> > > > Ignite would be serving all WAR files with a common data layer.
> > > >
> > > >
> > > > >
> > > > > So default should be stopping all node threads, but not kill the
> > > process.
> > > > > If user is aware process may be killed, it may setup option.
> > > > >
> > > >
> > > > No, the default should be to kill the process. If user does not like
> > it,
> > > > then it should be possible to change it to stop the node first.
> > > >
> > > >
> > > > >
> > > > > вт, 13 мар. 2018 г. в 15:24, Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > > >:
> > > > >
> > > > > > On Tue, Mar 13, 2018 at 8:16 AM, Dmitry Pavlov <
> > > dpavlov@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Dmitriy, alternative is "kill if standalone, stop if embedded"
> > > > > >
> > > > > >
> > > > > > > User will be still able to set something like
> > > > > > > -DNODE_CRASH_ACTION="kill"
> > > > > > > if ignite.sh is not used and user accepts alternative that
> whole
> > > > > process
> > > > > > > would be killed if node is crashed.
> > > > > > >
> > > > > > > Default would be 'node stop', but not hang up infinetely.
> > > > > > >
> > > > > >
> > > > > > Dmitriy, if Ignite if frozen, you will not be able to stop it.
> The
> > > only
> > > > > > guaranteed way to "un-freeze" the cluster is 

Re: IEP-14: Ignite failures handling (Discussion)

[Dmitriy Setrakyan]

Guys, I do not think there is an understanding here. If Ignite hangs - it
will likely be impossible to stop. So if you are suggesting "stop if
embedded", you might as well suggest "do nothing if embedded".

I have seen many Ignite deployments, embedded or not, large and small, and
in all those deployments if Ignite went into a frozen state, killing it was
the best option. Moreover, it provided the most predictable behavior. I am
not guessing here, but it seems to me that the rest of the community is
guessing.

Killing a frozen Ignite node should be a default behavior in all cases,
embedded or not. Stopping a frozen Ignite node should be a configurable
option, so a user has an ability to turn off auto-kill behavior. We should
also have a 3rd option, "stop+kill", so if stopping fails, then the process
is automatically killed (this is also a good default option).

Personally, I am OK if the default behavior is "kill" or "stop+kill", but
it should be the same default in all cases. We should stop the practice of
creating different default behaviors for the same problem. It is confusing
and hard to document.

D.

On Tue, Mar 13, 2018 at 2:19 PM, Denis Magda  wrote:

> +1 for "kill if standalone, stop if embedded" behavior. If the practice
> shows that the node should be killed regardless of the mode, then it will
> be an easy change. Now we are just guessing, and common sense suggests
> going for "kill if standalone, stop if embedded" until we get feedback.
>
> -
> Denis
>
> On Tue, Mar 13, 2018 at 8:30 AM, Dmitry Pavlov 
> wrote:
>
> > You are suggesting to kill the process, which was not started by Ignite,
> > are not you?
> >
> > More consistently is to stop only those processes that are generated by
> the
> > control of Ignite, e.g. from ignite.sh - here it is ok for me.
> >
> > If we relese 'kill by default' as part of 2.5, we will end up with 2.6
> > emergency release to change it back, if one user will face with such
> > unexpected behaviour.
> >
> > вт, 13 мар. 2018 г. в 18:17, Dmitriy Setrakyan :
> >
> > > Dmitriy,
> > >
> > > I think everyone is suggesting that stopping the node will likely be
> > > impossible if Ignite is frozen. Moreover, it is very likely that all
> > other
> > > apps are frozen too.
> > >
> > > My comments are below...
> > >
> > > On Tue, Mar 13, 2018 at 9:12 AM, Dmitry Pavlov 
> > > wrote:
> > >
> > > > Please consider that user application may use Ignite as optional
> cache
> > > for
> > > > some low-priority feature, but main logic is well functioning without
> > > > Ingnite. I can say, as Ignite user in the past, that it is quite real
> > > case.
> > > >
> > >
> > > I have been a part of this project for a while, but I have never seen
> > > Ignite used as an optional cache. Usually, Ignite is a mandatory part
> of
> > > the application, not optional.
> > >
> > >
> > > > Second real case is using several war files within one application
> > > server,
> > > > running different logic. Some apps use Ignite, some applications -
> not.
> > > > Killing application server in this case is not an option too.
> > > >
> > >
> > > Not very likely, but possible. This is not a common use case. Most
> > commonly
> > > Ignite would be serving all WAR files with a common data layer.
> > >
> > >
> > > >
> > > > So default should be stopping all node threads, but not kill the
> > process.
> > > > If user is aware process may be killed, it may setup option.
> > > >
> > >
> > > No, the default should be to kill the process. If user does not like
> it,
> > > then it should be possible to change it to stop the node first.
> > >
> > >
> > > >
> > > > вт, 13 мар. 2018 г. в 15:24, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >:
> > > >
> > > > > On Tue, Mar 13, 2018 at 8:16 AM, Dmitry Pavlov <
> > dpavlov@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Dmitriy, alternative is "kill if standalone, stop if embedded"
> > > > >
> > > > >
> > > > > > User will be still able to set something like
> > > > > > -DNODE_CRASH_ACTION="kill"
> > > > > > if ignite.sh is not used and user accepts alternative that whole
> > > > process
> > > > > > would be killed if node is crashed.
> > > > > >
> > > > > > Default would be 'node stop', but not hang up infinetely.
> > > > > >
> > > > >
> > > > > Dmitriy, if Ignite if frozen, you will not be able to stop it. The
> > only
> > > > > guaranteed way to "un-freeze" the cluster is to kill the frozen
> JVM.
> > > > >
> > > > > On top of that, it is very likely that if you stop the "embedded"
> > > Ignite,
> > > > > the user application will not be able to function any way, so
> killing
> > > the
> > > > > node does sound like a better and *safer* option.
> > > > >
> > > > > D.
> > > > >
> > > >
> > >
> >
>

Re: IGNITE-6879

[Denis Magda]

Hello Roman,

It's not a big deal, I've added you to the contributors' list in JIRA. Go
ahead and assign the ticket to yourself.

Folks, anyway, who can review Roman's contribution that brings Spring 2.0
support to Ignite?

--
Denis



On Tue, Mar 13, 2018 at 2:21 PM, Роман Меерсон  wrote:

> Hello!
>
> I want to work on https://issues.apache.org/jira/browse/IGNITE-6879 issue.
> Following the rules here
> https://ignite.apache.org/community/contribute.html#contribute my Jira
> username is "homich" so assign me to this ticket please.
>
> P.S. I found this rules page after I made PR, so sorry for this
> inconvenience.
>
> Regards.
>

[jira] [Created] (IGNITE-7939) .NET client node throws IgniteClientDisconnectedCheckedException when listening to EVT_CLIENT_NODE_DISCONNECTED and all Java server nodes exit

[Kevin Jin (JIRA)]

Kevin Jin created IGNITE-7939:
-

 Summary: .NET client node throws 
IgniteClientDisconnectedCheckedException when listening to 
EVT_CLIENT_NODE_DISCONNECTED and all Java server nodes exit
 Key: IGNITE-7939
 URL: https://issues.apache.org/jira/browse/IGNITE-7939
 Project: Ignite
  Issue Type: Bug
  Components: 2.3, messaging, platforms
Affects Versions: 2.3
 Environment: .NET and JVM Ignite nodes running on the same Windows 7 
6.1 am64 machine.

Server node: Ignite JVM

Client node: Ignite.NET
Reporter: Kevin Jin
 Fix For: None


I'm using the following Java code to start an Ignite server node:
{code:title=IgniteDotNetEventExample.java|borderStyle=solid}
import org.apache.ignite.Ignite;
import org.apache.ignite.Ignition;
import org.apache.ignite.configuration.DataRegionConfiguration;
import org.apache.ignite.configuration.DataStorageConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.events.EventType;
import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;

import java.io.IOException;
import java.util.Collections;

public class IgniteDotNetEventExample {
@SuppressWarnings("Duplicates")
private static Ignite startLocalIgniteServer() {
IgniteConfiguration cfg = new IgniteConfiguration();
// Do not persist the database to the disk.
cfg.setDataStorageConfiguration(new 
DataStorageConfiguration().setDefaultDataRegionConfiguration(new 
DataRegionConfiguration().setPersistenceEnabled(false)));
// Only discover other cluster nodes on the same machine.
cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(new 
TcpDiscoveryVmIpFinder(true).setAddresses(Collections.singletonList("127.0.0.1";
cfg.setIncludeEventTypes(EventType.EVT_CLIENT_NODE_DISCONNECTED, 
EventType.EVT_CLIENT_NODE_RECONNECTED);
cfg.setClientMode(false);

return Ignition.start(cfg);
}

@SuppressWarnings({"try","unused"})
public static void main(String[] args) throws IOException {
try (Ignite ignite = startLocalIgniteServer()) {
//noinspection ResultOfMethodCallIgnored
System.in.read();
}
}
}
{code}

I'm using the following C# code to start an Ignite client node:
{code:title=IgniteDotNetEventExample.cs|borderStyle=solid}
using Apache.Ignite.Core;
using Apache.Ignite.Core.Configuration;
using Apache.Ignite.Core.Discovery.Tcp;
using Apache.Ignite.Core.Discovery.Tcp.Static;
using Apache.Ignite.Core.Events;
using System;
using System.Threading;

internal class DelegateBackedEventListener : IEventListener where T : 
IEvent
{
private Func handler;

internal DelegateBackedEventListener(Func handler)
{
this.handler = handler;
}

public bool Invoke(T evt)
{
return handler(evt);
}
}

class IgniteDotNetEventExample
{
private static IIgnite StartLocalIgniteServer()
{
if (Environment.GetEnvironmentVariable("JAVA_HOME") == null)
{
if (Environment.Is64BitProcess)
Environment.SetEnvironmentVariable("JAVA_HOME", @"C:\Program 
Files\jdk\1.8");
else
Environment.SetEnvironmentVariable("JAVA_HOME", @"C:\Program 
Files (x86)\jdk\1.8");
}
var cfg = new IgniteConfiguration()
{
DataStorageConfiguration = new DataStorageConfiguration()
{
DefaultDataRegionConfiguration = new DataRegionConfiguration()
{
Name = "default",
PersistenceEnabled = false
}
},
DiscoverySpi = new TcpDiscoverySpi
{
IpFinder = new TcpDiscoveryStaticIpFinder
{
Endpoints = new string[] { "127.0.0.1" }
}
},
IncludedEventTypes = new int[] {
EventType.ClientNodeDisconnected, 
EventType.ClientNodeReconnected
},
ClientMode = true
};

return Ignition.Start(cfg);
}

public static void Main(string[] args)
{
using (IIgnite ignite = StartLocalIgniteServer())
{
ignite.GetEvents().LocalListen(new 
DelegateBackedEventListener(evt =>
{
Console.WriteLine(evt.Name + " " + evt.GetType());
return true;
}), EventType.ClientNodeDisconnected, 
EventType.ClientNodeReconnected);

Console.Read();
}
}
}
{code}

When I start the JVM server node and wait until it gives me the "Topology 
snapshot" message, then start the .NET client node and wait until it gives me 
the "Topology snapshot" message, and then terminate the server node, I receive 
the following error in 

IGNITE-6879

[Роман Меерсон]

Hello!

I want to work on https://issues.apache.org/jira/browse/IGNITE-6879 issue.
Following the rules here
https://ignite.apache.org/community/contribute.html#contribute my Jira
username is "homich" so assign me to this ticket please.

P.S. I found this rules page after I made PR, so sorry for this
inconvenience.

Regards.

Re: [RESULT] [VOTE] Apache Ignite 2.4.0 Release (RC1)

[Denis Magda]

Then tell me what to correct and I'll merge the changes.

Alternatively, you can send me an SVN patch with changes if it's simples:
https://cwiki.apache.org/confluence/display/IGNITE/Website+Development

--
Denis

On Tue, Mar 13, 2018 at 12:25 PM, Petr Ivanov  wrote:

> I have no access to site and readme.io  has no errors.
>
>
> > On 13 Mar 2018, at 22:23, Denis Magda  wrote:
> >
> > Petr,
> >
> > Have you corrected the site and readme.io docs (if it was required)?
> >
> > --
> > Denis
> >
> > On Mon, Mar 12, 2018 at 11:14 PM, Petr Ivanov 
> wrote:
> >
> >> There is an error in RPM documentation on site — missing header for
> >> ignite.repo file and formatting is also wrong.
> >> Otherwise — I’m able to install and run Apache Ignite from RPM from ASF
> >> according to manual.
> >>
> >>
> >>
> >>> On 12 Mar 2018, at 23:25, Denis Magda  wrote:
> >>>
> >>> Released RPM installation section on the downloads page:
> >>> https://ignite.apache.org/download.cgi#rpm-package
> >>>
> >>> *Petr*, please double check that the section and the readme getting
> >> started
> >>> look good:
> >>> https://apacheignite.readme.io/docs/getting-started#
> section-rpm-package-
> >> installation
> >>>
> >>> *Mauricio*, could you please create a patch that points out "latest"
> docs
> >>> to "2.4.0"?
> >>>
> >>> --
> >>> Denis
> >>>
> >>>
> >>>
> >>> On Mon, Mar 12, 2018 at 7:36 AM, Pavel Tupitsyn 
> >>> wrote:
> >>>
>  NuGet packages uploaded: https://www.nuget.org/
> packages?q=Apache.Ignite
> 
>  Thanks,
>  Pavel
> 
> 
>  On Mon, Mar 12, 2018 at 1:54 PM, Vladimir Ozerov <
> voze...@gridgain.com>
>  wrote:
> 
> > Correct, it is a matter of time. Download links already work on my
> side
> > [1].
> >
> > [1] http://mirror.linux-ia64.org/apache/ignite/2.4.0/
> >
> > On Mon, Mar 12, 2018 at 1:29 PM, Petr Ivanov 
>  wrote:
> >
> >> Link to 2.4.0 is pointing to RBC mirror, not Apache Dist itself.
> >>
> >> I do not know how often RBC updates its mirror, but I think we have
> to
> >> devise better solution for pointing to fresh release artifacts.
> >>
> >>
> >>
> >>> On 12 Mar 2018, at 13:24, Pavel Tupitsyn 
>  wrote:
> >>>
> >>> Hi Vladimir,
> >>>
> >>> I see the link for 2.4.0 on https://ignite.apache.org/
> >> download.cgi#binaries,
> >>> but it does not work.
> >>>
> >>> On Mon, Mar 12, 2018 at 10:55 AM, Vladimir Ozerov <
> > voze...@gridgain.com>
> >>> wrote:
> >>>
>  Correction: " Apache Ignite *2.4.0* release (RC1) has been
>  accepted."
> 
>  On Mon, Mar 12, 2018 at 10:51 AM, Vladimir Ozerov <
> > voze...@gridgain.com
> >>>
>  wrote:
> 
> > Igniters,
> >
> > Apache Ignite 2.3.0 release (RC1) has been accepted.
> >
> > 5 "+1" binding votes received:
> > - Alexey Goncharuk
> > - Alexey Kuznetsov
> > - Anton Vinogradov
> > - Denis Magda
> > - Pavel Tupitsyn
> >
> > Vote thread:
> >
> > *http://apache-ignite-developers.2346864.n4.nabble.
>  com/VOTE-Apache-Ignite-2-4-0-RC1-td27687.html
> >   com/VOTE-Apache-Ignite-2-4-0-RC1-td27687.html>*
> >
> > Ignite 2.4.0 will be released soon.
> >
> > Vladimir.
> >
> 
> >>
> >>
> >
> 
> >>
> >>
>
>

Re: [RESULT] [VOTE] Apache Ignite 2.4.0 Release (RC1)

[Petr Ivanov]

I have no access to site and readme.io  has no errors.


> On 13 Mar 2018, at 22:23, Denis Magda  wrote:
> 
> Petr,
> 
> Have you corrected the site and readme.io docs (if it was required)?
> 
> --
> Denis
> 
> On Mon, Mar 12, 2018 at 11:14 PM, Petr Ivanov  wrote:
> 
>> There is an error in RPM documentation on site — missing header for
>> ignite.repo file and formatting is also wrong.
>> Otherwise — I’m able to install and run Apache Ignite from RPM from ASF
>> according to manual.
>> 
>> 
>> 
>>> On 12 Mar 2018, at 23:25, Denis Magda  wrote:
>>> 
>>> Released RPM installation section on the downloads page:
>>> https://ignite.apache.org/download.cgi#rpm-package
>>> 
>>> *Petr*, please double check that the section and the readme getting
>> started
>>> look good:
>>> https://apacheignite.readme.io/docs/getting-started#section-rpm-package-
>> installation
>>> 
>>> *Mauricio*, could you please create a patch that points out "latest" docs
>>> to "2.4.0"?
>>> 
>>> --
>>> Denis
>>> 
>>> 
>>> 
>>> On Mon, Mar 12, 2018 at 7:36 AM, Pavel Tupitsyn 
>>> wrote:
>>> 
 NuGet packages uploaded: https://www.nuget.org/packages?q=Apache.Ignite
 
 Thanks,
 Pavel
 
 
 On Mon, Mar 12, 2018 at 1:54 PM, Vladimir Ozerov 
 wrote:
 
> Correct, it is a matter of time. Download links already work on my side
> [1].
> 
> [1] http://mirror.linux-ia64.org/apache/ignite/2.4.0/
> 
> On Mon, Mar 12, 2018 at 1:29 PM, Petr Ivanov 
 wrote:
> 
>> Link to 2.4.0 is pointing to RBC mirror, not Apache Dist itself.
>> 
>> I do not know how often RBC updates its mirror, but I think we have to
>> devise better solution for pointing to fresh release artifacts.
>> 
>> 
>> 
>>> On 12 Mar 2018, at 13:24, Pavel Tupitsyn 
 wrote:
>>> 
>>> Hi Vladimir,
>>> 
>>> I see the link for 2.4.0 on https://ignite.apache.org/
>> download.cgi#binaries,
>>> but it does not work.
>>> 
>>> On Mon, Mar 12, 2018 at 10:55 AM, Vladimir Ozerov <
> voze...@gridgain.com>
>>> wrote:
>>> 
 Correction: " Apache Ignite *2.4.0* release (RC1) has been
 accepted."
 
 On Mon, Mar 12, 2018 at 10:51 AM, Vladimir Ozerov <
> voze...@gridgain.com
>>> 
 wrote:
 
> Igniters,
> 
> Apache Ignite 2.3.0 release (RC1) has been accepted.
> 
> 5 "+1" binding votes received:
> - Alexey Goncharuk
> - Alexey Kuznetsov
> - Anton Vinogradov
> - Denis Magda
> - Pavel Tupitsyn
> 
> Vote thread:
> 
> *http://apache-ignite-developers.2346864.n4.nabble.
 com/VOTE-Apache-Ignite-2-4-0-RC1-td27687.html
> *
> 
> Ignite 2.4.0 will be released soon.
> 
> Vladimir.
> 
 
>> 
>> 
> 
 
>> 
>> 

Re: [RESULT] [VOTE] Apache Ignite 2.4.0 Release (RC1)

[Denis Magda]

Petr,

Have you corrected the site and readme.io docs (if it was required)?

--
Denis

On Mon, Mar 12, 2018 at 11:14 PM, Petr Ivanov  wrote:

> There is an error in RPM documentation on site — missing header for
> ignite.repo file and formatting is also wrong.
> Otherwise — I’m able to install and run Apache Ignite from RPM from ASF
> according to manual.
>
>
>
> > On 12 Mar 2018, at 23:25, Denis Magda  wrote:
> >
> > Released RPM installation section on the downloads page:
> > https://ignite.apache.org/download.cgi#rpm-package
> >
> > *Petr*, please double check that the section and the readme getting
> started
> > look good:
> > https://apacheignite.readme.io/docs/getting-started#section-rpm-package-
> installation
> >
> > *Mauricio*, could you please create a patch that points out "latest" docs
> > to "2.4.0"?
> >
> > --
> > Denis
> >
> >
> >
> > On Mon, Mar 12, 2018 at 7:36 AM, Pavel Tupitsyn 
> > wrote:
> >
> >> NuGet packages uploaded: https://www.nuget.org/packages?q=Apache.Ignite
> >>
> >> Thanks,
> >> Pavel
> >>
> >>
> >> On Mon, Mar 12, 2018 at 1:54 PM, Vladimir Ozerov 
> >> wrote:
> >>
> >>> Correct, it is a matter of time. Download links already work on my side
> >>> [1].
> >>>
> >>> [1] http://mirror.linux-ia64.org/apache/ignite/2.4.0/
> >>>
> >>> On Mon, Mar 12, 2018 at 1:29 PM, Petr Ivanov 
> >> wrote:
> >>>
>  Link to 2.4.0 is pointing to RBC mirror, not Apache Dist itself.
> 
>  I do not know how often RBC updates its mirror, but I think we have to
>  devise better solution for pointing to fresh release artifacts.
> 
> 
> 
> > On 12 Mar 2018, at 13:24, Pavel Tupitsyn 
> >> wrote:
> >
> > Hi Vladimir,
> >
> > I see the link for 2.4.0 on https://ignite.apache.org/
>  download.cgi#binaries,
> > but it does not work.
> >
> > On Mon, Mar 12, 2018 at 10:55 AM, Vladimir Ozerov <
> >>> voze...@gridgain.com>
> > wrote:
> >
> >> Correction: " Apache Ignite *2.4.0* release (RC1) has been
> >> accepted."
> >>
> >> On Mon, Mar 12, 2018 at 10:51 AM, Vladimir Ozerov <
> >>> voze...@gridgain.com
> >
> >> wrote:
> >>
> >>> Igniters,
> >>>
> >>> Apache Ignite 2.3.0 release (RC1) has been accepted.
> >>>
> >>> 5 "+1" binding votes received:
> >>> - Alexey Goncharuk
> >>> - Alexey Kuznetsov
> >>> - Anton Vinogradov
> >>> - Denis Magda
> >>> - Pavel Tupitsyn
> >>>
> >>> Vote thread:
> >>>
> >>> *http://apache-ignite-developers.2346864.n4.nabble.
> >> com/VOTE-Apache-Ignite-2-4-0-RC1-td27687.html
> >>>  >> com/VOTE-Apache-Ignite-2-4-0-RC1-td27687.html>*
> >>>
> >>> Ignite 2.4.0 will be released soon.
> >>>
> >>> Vladimir.
> >>>
> >>
> 
> 
> >>>
> >>
>
>

Re: Partition loss policy - how to use?

[Denis Magda]

Hi Gaurav,

I'm not sure about that, but it sounds like a right addition anyway.

Alex K., could you chime in please and clarify if the tools somehow support
the loss policies?

--
Denis


On Tue, Mar 13, 2018 at 11:44 AM, Gaurav Bajaj 
wrote:

> Hi Denis,
> Thanks. Document certainly looks useful. Do we have ticket for improvement
> in Webconsole/Visor for marking resetLostPartitions()?
>
>
> Regards,
> Gaurav
>
> On 13-Mar-2018 7:42 PM, "Denis Magda"  wrote:
>
> For those interested, here is a doc we put together for the partition
> policies which considers extra improvements released in 2.4:
> https://apacheignite.readme.io/v2.4/docs/partition-loss-policies
>
> --
> Denis
>
> On Tue, Mar 6, 2018 at 11:19 AM, Denis Magda  wrote:
>
> > Hi,
> >
> > Here is documentation we prepared for 2.4 release: https://apacheignite.
> > readme.io/v2.3/docs/cache-modes-24#partition-loss-policies
> >
> > It's hidden for now and will become visible to everyone once Ignite 2.4
> > vote passes (in progress).
> >
> > --
> > Denis
> >
> > On Tue, Mar 6, 2018 at 6:59 AM, gauravhb  wrote:
> >
> >> Hi,
> >>
> >> Is there any update on this topic?
> >> Any tickets created for points mentioned by Valentin?
> >>
> >> Thanks.
> >>
> >>
> >>
> >> --
> >> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> >>
> >
> >
>

Re: Partition loss policy - how to use?

[Gaurav Bajaj]

Hi Denis,
Thanks. Document certainly looks useful. Do we have ticket for improvement
in Webconsole/Visor for marking resetLostPartitions()?


Regards,
Gaurav

On 13-Mar-2018 7:42 PM, "Denis Magda"  wrote:

For those interested, here is a doc we put together for the partition
policies which considers extra improvements released in 2.4:
https://apacheignite.readme.io/v2.4/docs/partition-loss-policies

--
Denis

On Tue, Mar 6, 2018 at 11:19 AM, Denis Magda  wrote:

> Hi,
>
> Here is documentation we prepared for 2.4 release: https://apacheignite.
> readme.io/v2.3/docs/cache-modes-24#partition-loss-policies
>
> It's hidden for now and will become visible to everyone once Ignite 2.4
> vote passes (in progress).
>
> --
> Denis
>
> On Tue, Mar 6, 2018 at 6:59 AM, gauravhb  wrote:
>
>> Hi,
>>
>> Is there any update on this topic?
>> Any tickets created for points mentioned by Valentin?
>>
>> Thanks.
>>
>>
>>
>> --
>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>>
>
>

Re: Partition loss policy - how to use?

[Denis Magda]

For those interested, here is a doc we put together for the partition
policies which considers extra improvements released in 2.4:
https://apacheignite.readme.io/v2.4/docs/partition-loss-policies

--
Denis

On Tue, Mar 6, 2018 at 11:19 AM, Denis Magda  wrote:

> Hi,
>
> Here is documentation we prepared for 2.4 release: https://apacheignite.
> readme.io/v2.3/docs/cache-modes-24#partition-loss-policies
>
> It's hidden for now and will become visible to everyone once Ignite 2.4
> vote passes (in progress).
>
> --
> Denis
>
> On Tue, Mar 6, 2018 at 6:59 AM, gauravhb  wrote:
>
>> Hi,
>>
>> Is there any update on this topic?
>> Any tickets created for points mentioned by Valentin?
>>
>> Thanks.
>>
>>
>>
>> --
>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>>
>
>

Re: Data eviction/expiration from Ignite persistence

[Denis Magda]

Alexey,

My understanding was that the expiration policies worked for data in RAM
only. Ok, if an expired entry is removed from both RAM and Ignite
persistence then what happens if a cache store is used instead of Ignite
storage? Do we remove expired entries from RDBMs, Cassandra, etc? My guess
that we don't which doesn't look consistent product wide.

--
Denis

On Tue, Mar 13, 2018 at 12:50 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Denis,
>
> What do you mean by 'current behavior when data is evicted from the memory
> only'? TTL expiration effectively means that the corresponding key-value
> pairs are destroyed. If you are talking about page replacement, then there
> is no way to do this on per-key basis because a page must be replaced as a
> whole and it makes no sense to track keys.
>
> --AG
>
> 2018-03-13 0:03 GMT+03:00 Denis Magda :
>
> > Dmitriy,
> >
> > It will break the current default behavior when data is evicted from the
> > memory only, and I would disagree that it's a right decision overall.
> >
> > There are many scenarios when users need to have the eviction in the
> memory
> > layer and preserve data on disk for later usage. So, can we keep what we
> > have now and merely expand the eviction to disk if the user requires it?
> >
> > --
> > Denis
> >
> >
> > On Mon, Mar 12, 2018 at 1:35 PM, Dmitry Pavlov 
> > wrote:
> >
> > > Denis,
> > >
> > > I suppose there is no configuration will be required. If TTL configured
> > > entry will be removed from disk & memory both.
> > >
> > > SIncerely,
> > > Dmitriy Pavlov
> > >
> > > пн, 12 мар. 2018 г. в 23:32, Denis Magda :
> > >
> > > > Alexey, Dmitriy,
> > > >
> > > > What would be the configuration parameter that defines if the
> eviction
> > > > should happen in the in-memory layer only or in both memory and disk?
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On Mon, Mar 12, 2018 at 9:22 AM, Alexey Goncharuk <
> > > > alexey.goncha...@gmail.com> wrote:
> > > >
> > > > > Val,
> > > > >
> > > > > Yes, the entries will be removed from both memory and persistence.
> > > > >
> > > > > 2018-03-12 19:20 GMT+03:00 Valentin Kulichenko <
> > > > > valentin.kuliche...@gmail.com>:
> > > > >
> > > > > > Alex,
> > > > > >
> > > > > > What is behavior going to be after IGNITE-5874 is fixed? Will
> > expired
> > > > > entry
> > > > > > be removed from both memory and persistence?
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Sat, Mar 10, 2018 at 12:06 AM, Alexey Goncharuk <
> > > > > > alexey.goncha...@gmail.com> wrote:
> > > > > >
> > > > > > > The ticket [1] is in patch available state looks good, the only
> > > thing
> > > > > > left
> > > > > > > there is to transfer old entries to new storage. I hope Andrey
> > will
> > > > > have
> > > > > > > time to finish this soon, so we can target the fix for 2.5.
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-5874
> > > > > > >
> > > > > > > 2018-03-09 22:51 GMT+03:00 Denis Magda :
> > > > > > >
> > > > > > > > Val,
> > > > > > > >
> > > > > > > > I'd like to hear Alexey G. opinion on this? Alex, please
> chime
> > > in.
> > > > > > > >
> > > > > > > > In general, the more deployments the persistence will get the
> > > more
> > > > > > demand
> > > > > > > > we will see for that capability. Personally, I'd create a
> > ticket
> > > > for
> > > > > > now
> > > > > > > > and put it off to our backlog.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Denis
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Mar 9, 2018 at 9:34 AM, Dmitriy Setrakyan <
> > > > > > dsetrak...@apache.org
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Fri, Mar 9, 2018 at 3:43 AM, Dmitry Pavlov <
> > > > > dpavlov@gmail.com
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > As far as I know there is no plans. Denis please correct
> me
> > > if
> > > > > I'm
> > > > > > > > wrong.
> > > > > > > > > >
> > > > > > > > > > But users found these or similar bugs, it seems we need
> to
> > > > > support
> > > > > > > PDS
> > > > > > > > > and
> > > > > > > > > > TTL.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > We should either support it or throw a clear  exception on
> > > > startup
> > > > > > > > clearly
> > > > > > > > > stating that it is not. I suppose, it should be the latter
> > for
> > > > now.
> > > > > > > > > Dmitriy, any chance you can file a ticket for it?
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: MTCGA: IGNITE-7791 and GridDhtPartitionsSingleMessage

[Dmitry Pavlov]

Hi Alexey,

Could you help with this question?

I've observed such messages, it were probably sent by timeout, but not sure
their purpose.

Sincerely,
Dmitriy Pavlov

вт, 13 мар. 2018 г. в 20:58, Maxim Muzafarov :

> Hi all,
>
> I'm working on [1] IgniteClientReconnectCacheTest class with frakly
> test-case testReconnectCacheDestroyedAndCreated with success rate 32.4%.
>
> I've leaved comment in JIRA [2] and new test-case with reproducing this
> issue.
> Basicly, when we receiving GridDhtPartitionsSingleMessage with exchId=null
> not
> in proper time we've got this Assertion error. Ignite client instance
> erases all it's caches after reconnect, so it has no information about
> cache named 'static-cache' that persists on server nodes and when he
> recieve this SignleMessage after reconnection it will have 'Failed to
> reinitialize local partitions (preloading will be stopped)'.
>
> Should we perform clean-up [3] client caches in case of reconnect client
> ignite instance?
> Why we should clean clinent caches after node reconnects? Can't catch the
> idea of it.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-7791
> [2]
>
> https://issues.apache.org/jira/browse/IGNITE-7791?focusedCommentId=16391409=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16391409
> [3]
>
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CacheAffinitySharedManager.java#L190
>

Re: Deploying 2.4 artifacts to maven repo

[Denis Magda]

That's not a maven central but rather a 3rd party portal that enlists maven
dependencies. We had a conversation about this with INFRA before:
https://issues.apache.org/jira/browse/INFRA-13073

I see that Ignite is already in maven central:
http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.ignite%22%20AND%20a%3A%22ignite-core%22
http://repo.maven.apache.org/maven2/org/apache/ignite/ignite-core/

Let's give more time to MvnRepository to sync up.

--
Denis



On Tue, Mar 13, 2018 at 6:16 AM, Dmitry Pavlov 
wrote:

> Thank you for noticing that.
>
> Vladimir, is it expected for current release stage?
>
> Sincerely,
> Dmitriy Pavlov
>
> вт, 13 мар. 2018 г. в 15:34, aaksenov :
>
> > hello, it seems that 2.4 jars are missing in maven central
> > https://mvnrepository.com/artifact/org.apache.ignite/ignite-core
> > but the version has been released.
> > could you please upload them?
> >
> >
> >
> > --
> > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> >
>

Re: IEP-14: Ignite failures handling (Discussion)

[Denis Magda]

+1 for "kill if standalone, stop if embedded" behavior. If the practice
shows that the node should be killed regardless of the mode, then it will
be an easy change. Now we are just guessing, and common sense suggests
going for "kill if standalone, stop if embedded" until we get feedback.

-
Denis

On Tue, Mar 13, 2018 at 8:30 AM, Dmitry Pavlov 
wrote:

> You are suggesting to kill the process, which was not started by Ignite,
> are not you?
>
> More consistently is to stop only those processes that are generated by the
> control of Ignite, e.g. from ignite.sh - here it is ok for me.
>
> If we relese 'kill by default' as part of 2.5, we will end up with 2.6
> emergency release to change it back, if one user will face with such
> unexpected behaviour.
>
> вт, 13 мар. 2018 г. в 18:17, Dmitriy Setrakyan :
>
> > Dmitriy,
> >
> > I think everyone is suggesting that stopping the node will likely be
> > impossible if Ignite is frozen. Moreover, it is very likely that all
> other
> > apps are frozen too.
> >
> > My comments are below...
> >
> > On Tue, Mar 13, 2018 at 9:12 AM, Dmitry Pavlov 
> > wrote:
> >
> > > Please consider that user application may use Ignite as optional cache
> > for
> > > some low-priority feature, but main logic is well functioning without
> > > Ingnite. I can say, as Ignite user in the past, that it is quite real
> > case.
> > >
> >
> > I have been a part of this project for a while, but I have never seen
> > Ignite used as an optional cache. Usually, Ignite is a mandatory part of
> > the application, not optional.
> >
> >
> > > Second real case is using several war files within one application
> > server,
> > > running different logic. Some apps use Ignite, some applications - not.
> > > Killing application server in this case is not an option too.
> > >
> >
> > Not very likely, but possible. This is not a common use case. Most
> commonly
> > Ignite would be serving all WAR files with a common data layer.
> >
> >
> > >
> > > So default should be stopping all node threads, but not kill the
> process.
> > > If user is aware process may be killed, it may setup option.
> > >
> >
> > No, the default should be to kill the process. If user does not like it,
> > then it should be possible to change it to stop the node first.
> >
> >
> > >
> > > вт, 13 мар. 2018 г. в 15:24, Dmitriy Setrakyan  >:
> > >
> > > > On Tue, Mar 13, 2018 at 8:16 AM, Dmitry Pavlov <
> dpavlov@gmail.com>
> > > > wrote:
> > > >
> > > > > Dmitriy, alternative is "kill if standalone, stop if embedded"
> > > >
> > > >
> > > > > User will be still able to set something like
> > > > > -DNODE_CRASH_ACTION="kill"
> > > > > if ignite.sh is not used and user accepts alternative that whole
> > > process
> > > > > would be killed if node is crashed.
> > > > >
> > > > > Default would be 'node stop', but not hang up infinetely.
> > > > >
> > > >
> > > > Dmitriy, if Ignite if frozen, you will not be able to stop it. The
> only
> > > > guaranteed way to "un-freeze" the cluster is to kill the frozen JVM.
> > > >
> > > > On top of that, it is very likely that if you stop the "embedded"
> > Ignite,
> > > > the user application will not be able to function any way, so killing
> > the
> > > > node does sound like a better and *safer* option.
> > > >
> > > > D.
> > > >
> > >
> >
>

Re: Apache Ignite community in social network VK.com

[Denis Magda]

Could you add a reference to the group to the "events" section on the site?
The section itself needs to be renamed to "Events & Groups" after that.

--
Denis

2018-03-13 6:47 GMT-07:00 Dmitry Pavlov :

> Hi! We created https://vk.com/apacheignite for Russian speaking community.
> That will be the hub for Apache Ignite events and resources in Russian.
> Follow the group to get latest news and suggest activities for Moscow,
> Petersburg or other cities.
>
> Привет! Мы создали  https://vk.com/apacheignite для русскоговорящего
> сообщества. В группе будут появляться анонсы мероприятий и материалов
> Apache Ignite на русском языке. Присоединяйтесь и предлагайте активности в
> Москве, Петербурге или других городах.
>

MTCGA: IGNITE-7791 and GridDhtPartitionsSingleMessage

[Maxim Muzafarov]

Hi all,

I'm working on [1] IgniteClientReconnectCacheTest class with frakly
test-case testReconnectCacheDestroyedAndCreated with success rate 32.4%.

I've leaved comment in JIRA [2] and new test-case with reproducing this
issue.
Basicly, when we receiving GridDhtPartitionsSingleMessage with exchId=null not
in proper time we've got this Assertion error. Ignite client instance
erases all it's caches after reconnect, so it has no information about
cache named 'static-cache' that persists on server nodes and when he
recieve this SignleMessage after reconnection it will have 'Failed to
reinitialize local partitions (preloading will be stopped)'.

Should we perform clean-up [3] client caches in case of reconnect client
ignite instance?
Why we should clean clinent caches after node reconnects? Can't catch the
idea of it.

[1] https://issues.apache.org/jira/browse/IGNITE-7791
[2]
https://issues.apache.org/jira/browse/IGNITE-7791?focusedCommentId=16391409=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16391409
[3]
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CacheAffinitySharedManager.java#L190

Re: Apache Ignite nightly release builds

[Raymond Wilson]

Yes please! :)

Sent from my iPhone

> On 14/03/2018, at 4:10 AM, Dmitry Pavlov  wrote:
> 
> We can start with this approach. And if we will need some staging maven
> repo, we can support it later.
> 
> вт, 13 мар. 2018 г. в 18:08, Dmitriy Setrakyan :
> 
>> Huge +1.
>> 
>> Any idea about how much effort this involves?
>> 
>> D.
>> 
>>> On Tue, Mar 13, 2018 at 11:05 AM, vveider  wrote:
>>> 
>>> Hi, Igniters!
>>> 
>>> 
>>> I suggest we continue our discussion concerning Apache Ignite nightly
>>> release builds.
>>> 
>>> I'd like to prepare one on our CI server (TeamCity) and will be glad to
>>> hear
>>> wishes and proposal about this project.
>>> Currently, I see it as scheduled build which builds release binaries from
>>> master branch (with SNAPSHOT version) and where artifacts will be stored
>> at
>>> TeamCity itself and be populated as some kind of link on our main site
>> [1]
>>> to latest successful artifacts.
>>> 
>>> What do you think?
>>> 
>>> 
>>> [1] https://ignite.apache.org/download.cgi
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>>> 
>> 

Re: Apache Ignite community in social network VK.com

[Vladimir Ozerov]

Dmitry,

Awesome thing!

2018-03-13 16:47 GMT+03:00 Dmitry Pavlov :

> Hi! We created https://vk.com/apacheignite for Russian speaking community.
> That will be the hub for Apache Ignite events and resources in Russian.
> Follow the group to get latest news and suggest activities for Moscow,
> Petersburg or other cities.
>
> Привет! Мы создали  https://vk.com/apacheignite для русскоговорящего
> сообщества. В группе будут появляться анонсы мероприятий и материалов
> Apache Ignite на русском языке. Присоединяйтесь и предлагайте активности в
> Москве, Петербурге или других городах.
>

[GitHub] ignite pull request #3611: Ignite 7751

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3611


---

[GitHub] ignite pull request #3629: IGNITE-7875: MultiSVM - added Model, Trainer and ...

[zaleslaw]

GitHub user zaleslaw opened a pull request:

https://github.com/apache/ignite/pull/3629

IGNITE-7875: MultiSVM - added Model, Trainer and Tests



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-7887

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3629.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3629


commit ba5b5aa5c4a7133db73640921a7a570d882a0957
Author: zaleslaw 
Date:   2018-03-13T16:10:57Z

IGNITE-7875: Model, Trainer and Tests




---

[GitHub] ignite pull request #3229: IGNITE-7182: Checkpoint pages: optimize and paral...

[dspavlov]

Github user dspavlov closed the pull request at:

https://github.com/apache/ignite/pull/3229


---

[jira] [Created] (IGNITE-7938) [ML] Adopt KMeans to the new Partitioned Dataset

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-7938:


 Summary: [ML] Adopt KMeans to the new Partitioned Dataset
 Key: IGNITE-7938
 URL: https://issues.apache.org/jira/browse/IGNITE-7938
 Project: Ignite
  Issue Type: Improvement
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3628: IGNITE-6879 and migration to spring-data 2.0.5.RE...

[homich1991]

GitHub user homich1991 opened a pull request:

https://github.com/apache/ignite/pull/3628

IGNITE-6879 and migration to spring-data 2.0.5.RELEASE

Fixed IGNITE-6879
Migrated to spring-data 2.0.5.RELEASE
Migrated to spring 5.0.4.RELEASE
Fixed overrided methods naming

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/homich1991/ignite ignite-6879

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3628.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3628


commit ae280108fad94d42a04d8b955262178ef6a365dd
Author: Roman_Meerson 
Date:   2018-03-13T15:32:46Z

Fixed IGNITE-6879
Migrated to spring-data 2.0.5.RELEASE
Migrated to spring 5.0.4.RELEASE
Fixed overrided methods naming




---

Re: IEP-14: Ignite failures handling (Discussion)

[Dmitry Pavlov]

You are suggesting to kill the process, which was not started by Ignite,
are not you?

More consistently is to stop only those processes that are generated by the
control of Ignite, e.g. from ignite.sh - here it is ok for me.

If we relese 'kill by default' as part of 2.5, we will end up with 2.6
emergency release to change it back, if one user will face with such
unexpected behaviour.

вт, 13 мар. 2018 г. в 18:17, Dmitriy Setrakyan :

> Dmitriy,
>
> I think everyone is suggesting that stopping the node will likely be
> impossible if Ignite is frozen. Moreover, it is very likely that all other
> apps are frozen too.
>
> My comments are below...
>
> On Tue, Mar 13, 2018 at 9:12 AM, Dmitry Pavlov 
> wrote:
>
> > Please consider that user application may use Ignite as optional cache
> for
> > some low-priority feature, but main logic is well functioning without
> > Ingnite. I can say, as Ignite user in the past, that it is quite real
> case.
> >
>
> I have been a part of this project for a while, but I have never seen
> Ignite used as an optional cache. Usually, Ignite is a mandatory part of
> the application, not optional.
>
>
> > Second real case is using several war files within one application
> server,
> > running different logic. Some apps use Ignite, some applications - not.
> > Killing application server in this case is not an option too.
> >
>
> Not very likely, but possible. This is not a common use case. Most commonly
> Ignite would be serving all WAR files with a common data layer.
>
>
> >
> > So default should be stopping all node threads, but not kill the process.
> > If user is aware process may be killed, it may setup option.
> >
>
> No, the default should be to kill the process. If user does not like it,
> then it should be possible to change it to stop the node first.
>
>
> >
> > вт, 13 мар. 2018 г. в 15:24, Dmitriy Setrakyan :
> >
> > > On Tue, Mar 13, 2018 at 8:16 AM, Dmitry Pavlov 
> > > wrote:
> > >
> > > > Dmitriy, alternative is "kill if standalone, stop if embedded"
> > >
> > >
> > > > User will be still able to set something like
> > > > -DNODE_CRASH_ACTION="kill"
> > > > if ignite.sh is not used and user accepts alternative that whole
> > process
> > > > would be killed if node is crashed.
> > > >
> > > > Default would be 'node stop', but not hang up infinetely.
> > > >
> > >
> > > Dmitriy, if Ignite if frozen, you will not be able to stop it. The only
> > > guaranteed way to "un-freeze" the cluster is to kill the frozen JVM.
> > >
> > > On top of that, it is very likely that if you stop the "embedded"
> Ignite,
> > > the user application will not be able to function any way, so killing
> the
> > > node does sound like a better and *safer* option.
> > >
> > > D.
> > >
> >
>

Re: IEP-14: Ignite failures handling (Discussion)

[Dmitriy Setrakyan]

Dmitriy,

I think everyone is suggesting that stopping the node will likely be
impossible if Ignite is frozen. Moreover, it is very likely that all other
apps are frozen too.

My comments are below...

On Tue, Mar 13, 2018 at 9:12 AM, Dmitry Pavlov 
wrote:

> Please consider that user application may use Ignite as optional cache for
> some low-priority feature, but main logic is well functioning without
> Ingnite. I can say, as Ignite user in the past, that it is quite real case.
>

I have been a part of this project for a while, but I have never seen
Ignite used as an optional cache. Usually, Ignite is a mandatory part of
the application, not optional.


> Second real case is using several war files within one application server,
> running different logic. Some apps use Ignite, some applications - not.
> Killing application server in this case is not an option too.
>

Not very likely, but possible. This is not a common use case. Most commonly
Ignite would be serving all WAR files with a common data layer.


>
> So default should be stopping all node threads, but not kill the process.
> If user is aware process may be killed, it may setup option.
>

No, the default should be to kill the process. If user does not like it,
then it should be possible to change it to stop the node first.


>
> вт, 13 мар. 2018 г. в 15:24, Dmitriy Setrakyan :
>
> > On Tue, Mar 13, 2018 at 8:16 AM, Dmitry Pavlov 
> > wrote:
> >
> > > Dmitriy, alternative is "kill if standalone, stop if embedded"
> >
> >
> > > User will be still able to set something like
> > > -DNODE_CRASH_ACTION="kill"
> > > if ignite.sh is not used and user accepts alternative that whole
> process
> > > would be killed if node is crashed.
> > >
> > > Default would be 'node stop', but not hang up infinetely.
> > >
> >
> > Dmitriy, if Ignite if frozen, you will not be able to stop it. The only
> > guaranteed way to "un-freeze" the cluster is to kill the frozen JVM.
> >
> > On top of that, it is very likely that if you stop the "embedded" Ignite,
> > the user application will not be able to function any way, so killing the
> > node does sound like a better and *safer* option.
> >
> > D.
> >
>

Re: Apache Ignite nightly release builds

[Dmitry Pavlov]

We can start with this approach. And if we will need some staging maven
repo, we can support it later.

вт, 13 мар. 2018 г. в 18:08, Dmitriy Setrakyan :

> Huge +1.
>
> Any idea about how much effort this involves?
>
> D.
>
> On Tue, Mar 13, 2018 at 11:05 AM, vveider  wrote:
>
> > Hi, Igniters!
> >
> >
> > I suggest we continue our discussion concerning Apache Ignite nightly
> > release builds.
> >
> > I'd like to prepare one on our CI server (TeamCity) and will be glad to
> > hear
> > wishes and proposal about this project.
> > Currently, I see it as scheduled build which builds release binaries from
> > master branch (with SNAPSHOT version) and where artifacts will be stored
> at
> > TeamCity itself and be populated as some kind of link on our main site
> [1]
> > to latest successful artifacts.
> >
> > What do you think?
> >
> >
> > [1] https://ignite.apache.org/download.cgi
> >
> >
> >
> > --
> > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> >
>

Re: Apache Ignite nightly release builds

[Petr Ivanov]

Not mush I presume, at least for woking prototype.

As I mentioned before — there is fully operational Release Build, which can be 
used as example for nightly builds.


> On 13 Mar 2018, at 18:07, Dmitriy Setrakyan  wrote:
> 
> Huge +1.
> 
> Any idea about how much effort this involves?
> 
> D.
> 
> On Tue, Mar 13, 2018 at 11:05 AM, vveider  wrote:
> 
>> Hi, Igniters!
>> 
>> 
>> I suggest we continue our discussion concerning Apache Ignite nightly
>> release builds.
>> 
>> I'd like to prepare one on our CI server (TeamCity) and will be glad to
>> hear
>> wishes and proposal about this project.
>> Currently, I see it as scheduled build which builds release binaries from
>> master branch (with SNAPSHOT version) and where artifacts will be stored at
>> TeamCity itself and be populated as some kind of link on our main site [1]
>> to latest successful artifacts.
>> 
>> What do you think?
>> 
>> 
>> [1] https://ignite.apache.org/download.cgi
>> 
>> 
>> 
>> --
>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>> 

Re: Apache Ignite nightly release builds

[Dmitriy Setrakyan]

Huge +1.

Any idea about how much effort this involves?

D.

On Tue, Mar 13, 2018 at 11:05 AM, vveider  wrote:

> Hi, Igniters!
>
>
> I suggest we continue our discussion concerning Apache Ignite nightly
> release builds.
>
> I'd like to prepare one on our CI server (TeamCity) and will be glad to
> hear
> wishes and proposal about this project.
> Currently, I see it as scheduled build which builds release binaries from
> master branch (with SNAPSHOT version) and where artifacts will be stored at
> TeamCity itself and be populated as some kind of link on our main site [1]
> to latest successful artifacts.
>
> What do you think?
>
>
> [1] https://ignite.apache.org/download.cgi
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

Apache Ignite nightly release builds

[vveider]

Hi, Igniters!


I suggest we continue our discussion concerning Apache Ignite nightly
release builds.

I'd like to prepare one on our CI server (TeamCity) and will be glad to hear
wishes and proposal about this project.
Currently, I see it as scheduled build which builds release binaries from
master branch (with SNAPSHOT version) and where artifacts will be stored at
TeamCity itself and be populated as some kind of link on our main site [1]
to latest successful artifacts.

What do you think?


[1] https://ignite.apache.org/download.cgi



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[jira] [Created] (IGNITE-7937) Move Apache Ignite 2.4+ Java 8 tests to Single Build architecture

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-7937:


 Summary: Move Apache Ignite 2.4+ Java 8 tests to Single Build 
architecture
 Key: IGNITE-7937
 URL: https://issues.apache.org/jira/browse/IGNITE-7937
 Project: Ignite
  Issue Type: Task
Reporter: Peter Ivanov
Assignee: Peter Ivanov


# Use working example from [\[Not for production use\] Ignite Tests 2.0+ (Java 
8/9)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests20Java89] 
project.
# Start with green tests suites.
# Revise _templates_ and _VSC roots_.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7936) Make partition state transfer from OWNING state possible only within exchange.

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-7936:


 Summary: Make partition state transfer from OWNING state possible 
only within exchange.
 Key: IGNITE-7936
 URL: https://issues.apache.org/jira/browse/IGNITE-7936
 Project: Ignite
  Issue Type: Improvement
Reporter: Ilya Lantukh


Currently partition is moved from OWNING to RENTING state right after exchange, 
which makes it necessary to handle races while mapping distributed operations. 
It can be improved, simplified and optimized by performing such transfer within 
exchange.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7934) Do not checkpoint pages from MOVING partitions

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-7934:


 Summary: Do not checkpoint pages from MOVING partitions
 Key: IGNITE-7934
 URL: https://issues.apache.org/jira/browse/IGNITE-7934
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.4
Reporter: Ilya Lantukh
Assignee: Ilya Lantukh


To remove necessity to acquire checkpoint lock and write records to WAL while 
processing supply messages, it might be beneficial to skip pages from MOVING 
partitions during checkpointing. 

The only problem that it might cause is index consistency, which can be avoided 
by splitting rebalancing in 2 steps:
1. data preloading;
2. index rebuild.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7935) Add batch put operation to B+ tree implementation.

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-7935:


 Summary: Add batch put operation to B+ tree implementation.
 Key: IGNITE-7935
 URL: https://issues.apache.org/jira/browse/IGNITE-7935
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.4
Reporter: Ilya Lantukh






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Apache Ignite community in social network VK.com

[Dmitry Pavlov]

Hi! We created https://vk.com/apacheignite for Russian speaking community.
That will be the hub for Apache Ignite events and resources in Russian.
Follow the group to get latest news and suggest activities for Moscow,
Petersburg or other cities.

Привет! Мы создали  https://vk.com/apacheignite для русскоговорящего
сообщества. В группе будут появляться анонсы мероприятий и материалов
Apache Ignite на русском языке. Присоединяйтесь и предлагайте активности в
Москве, Петербурге или других городах.

Re: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts

[Denis Mekhanikov]

Absolutely agree.

Personally I find it particularly frustrating, that
*IgniteConfiguration.networkTimeout* and TcpDiscoverySpi.networkTime*out *are
not the same thing.

If we had a small set of timeouts with simple and clear semantics, it would
make everybody happier.

Denis

вт, 6 мар. 2018 г. в 15:23, Alexey Popov :

> Yakov,
>
> 1. The proposal list of parameters to deprecate:
> TcpDiscoverySpi.setConnectTimeout (covered by
> IgniteConfiguration.setFailureDetectionTimeout)
> TcpDiscoverySpi.setReconnectCount (covered by
> IgniteConfiguration.setFailureDetectionTimeout)
> TcpDiscoverySpi.setSocketTimeout (covered by
> IgniteConfiguration.setFailureDetectionTimeout)
> TcpDiscoverySpi.setAckTimeout (covered by
> IgniteConfiguration.setFailureDetectionTimeout)
> TcpDiscoverySpi.setMaxAckTimeout (covered by
> IgniteConfiguration.setFailureDetectionTimeout)
> TcpDiscoverySpi.setNetworkTimeout (IgniteConfiguration.setNetworkTimeout
> should be used here)
> TcpCommunicationSpi.setConnectTimeout (covered by
> IgniteConfiguration.setFailureDetectionTimeout)
> TcpCommunicationSpi.setMaxConnectTimeout (covered by
> IgniteConfiguration.setFailureDetectionTimeout)
> TcpCommunicationSpi.setReconnectCount (covered by
> IgniteConfiguration.setFailureDetectionTimeout)
> TcpCommunicationSpi.setSocketWriteTimeout
> (IgniteConfiguration.setNetworkTimeout should be used here)
>
> 2. Internal logic should continue to use
> IgniteConfiguration.setFailureDetectionTimeout and
> IgniteConfiguration.setNetworkTimeout as it is now.
> The deprecated parameters should be alive for a while with the
> corresponding
> javadoc update.
> TcpDiscoverySpi.getNetworkTimeout should use
> IgniteConfiguration.getNetworkTimeout by default.
> TcpCommunicationSpi.getSocketWriteTimeout should use
> IgniteConfiguration.getNetworkTimeout by default.
>
> In a few releases, the deprecated parameters could be removed.
>
> 3. I think we can keep the existent description of the parameters.
> Probably,
> it could be updated for more clear statements for
> IgniteConfiguration.setFailureDetectionTimeout and
> IgniteConfiguration.setNetworkTimeout.
>
> Thanks,
> Alexey
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

[GitHub] ignite pull request #3481: IGNITE-7638: Page replacement process in PDS mode...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3481


---

[GitHub] ignite pull request #3627: IGNITE-7932: Add example for Linear SVM with Iris...

[zaleslaw]

GitHub user zaleslaw opened a pull request:

https://github.com/apache/ignite/pull/3627

IGNITE-7932: Add example for Linear SVM with Iris Dataset



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-7932

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3627.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3627


commit 69aab6c927812b586452ffa6e0a06ab9690ce864
Author: zaleslaw 
Date:   2018-03-13T13:33:16Z

IGNITE-7932: Add example




---

Re: Deploying 2.4 artifacts to maven repo

[Dmitry Pavlov]

Thank you for noticing that.

Vladimir, is it expected for current release stage?

Sincerely,
Dmitriy Pavlov

вт, 13 мар. 2018 г. в 15:34, aaksenov :

> hello, it seems that 2.4 jars are missing in maven central
> https://mvnrepository.com/artifact/org.apache.ignite/ignite-core
> but the version has been released.
> could you please upload them?
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

Re: IEP-14: Ignite failures handling (Discussion)

[Dmitry Pavlov]

Please consider that user application may use Ignite as optional cache for
some low-priority feature, but main logic is well functioning without
Ingnite. I can say, as Ignite user in the past, that it is quite real case.

Second real case is using several war files within one application server,
running different logic. Some apps use Ignite, some applications - not.
Killing application server in this case is not an option too.

So default should be stopping all node threads, but not kill the process.
If user is aware process may be killed, it may setup option.

вт, 13 мар. 2018 г. в 15:24, Dmitriy Setrakyan :

> On Tue, Mar 13, 2018 at 8:16 AM, Dmitry Pavlov 
> wrote:
>
> > Dmitriy, alternative is "kill if standalone, stop if embedded"
>
>
> > User will be still able to set something like
> > -DNODE_CRASH_ACTION="kill"
> > if ignite.sh is not used and user accepts alternative that whole process
> > would be killed if node is crashed.
> >
> > Default would be 'node stop', but not hang up infinetely.
> >
>
> Dmitriy, if Ignite if frozen, you will not be able to stop it. The only
> guaranteed way to "un-freeze" the cluster is to kill the frozen JVM.
>
> On top of that, it is very likely that if you stop the "embedded" Ignite,
> the user application will not be able to function any way, so killing the
> node does sound like a better and *safer* option.
>
> D.
>

[jira] [Created] (IGNITE-7933) The error writing wal point to cp/node-start file can lead to the inability to start node

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-7933:
--

 Summary: The error writing wal point to cp/node-start file can 
lead to the inability to start node
 Key: IGNITE-7933
 URL: https://issues.apache.org/jira/browse/IGNITE-7933
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Govorukhin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Data eviction/expiration from Ignite persistence

[Alexey Goncharuk]

Dmitriy,

The TTL map is a regular B+Tree-based map with the key being a pair (expire
time + key). It is obviously stored in memory when there is no persistence.
When persistence is enabled, it is handled as any other index tree - the
page replacement algorithm is applied. No heap is consumed for this tree.

--AG

2018-03-13 15:30 GMT+03:00 Dmitriy Setrakyan :

>
>
> On Tue, Mar 13, 2018 at 3:50 AM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
>> Denis,
>>
>> What do you mean by 'current behavior when data is evicted from the memory
>> only'? TTL expiration effectively means that the corresponding key-value
>> pairs are destroyed.
>
>
> AG, can you please explain how this is implemented? Are we really keeping
> the whole TTL map in memory?
>
>

[GitHub] ignite pull request #3571: IGNITE-7531: Implemented copy, insert, batched in...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3571


---

[jira] [Created] (IGNITE-7932) [ML] Adopt SVM Linear Binary Classification Example to the new Partitioned Dataset

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-7932:


 Summary: [ML] Adopt SVM Linear Binary Classification Example to 
the new Partitioned Dataset
 Key: IGNITE-7932
 URL: https://issues.apache.org/jira/browse/IGNITE-7932
 Project: Ignite
  Issue Type: Sub-task
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Deploying 2.4 artifacts to maven repo

[aaksenov]

hello, it seems that 2.4 jars are missing in maven central
https://mvnrepository.com/artifact/org.apache.ignite/ignite-core
but the version has been released.
could you please upload them?



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[GitHub] ignite pull request #3626: IGNITE-7898 Fixed IgniteCachePartitionLossPolicy ...

[Jokser]

GitHub user Jokser opened a pull request:

https://github.com/apache/ignite/pull/3626

IGNITE-7898 Fixed IgniteCachePartitionLossPolicy tests



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-7898

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3626.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3626


commit 7cc9e112316b01d527720c3ed85114d69c8b58ad
Author: Pavel Kovalenko 
Date:   2018-03-13T12:30:07Z

IGNITE-7898 Fixed IgniteCachePartitionLossPolicy tests




---

Re: Data eviction/expiration from Ignite persistence

[Dmitriy Setrakyan]

On Tue, Mar 13, 2018 at 3:50 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Denis,
>
> What do you mean by 'current behavior when data is evicted from the memory
> only'? TTL expiration effectively means that the corresponding key-value
> pairs are destroyed.


AG, can you please explain how this is implemented? Are we really keeping
the whole TTL map in memory?

Re: IEP-14: Ignite failures handling (Discussion)

[Dmitriy Setrakyan]

On Tue, Mar 13, 2018 at 8:16 AM, Dmitry Pavlov 
wrote:

> Dmitriy, alternative is "kill if standalone, stop if embedded"


> User will be still able to set something like
> -DNODE_CRASH_ACTION="kill"
> if ignite.sh is not used and user accepts alternative that whole process
> would be killed if node is crashed.
>
> Default would be 'node stop', but not hang up infinetely.
>

Dmitriy, if Ignite if frozen, you will not be able to stop it. The only
guaranteed way to "un-freeze" the cluster is to kill the frozen JVM.

On top of that, it is very likely that if you stop the "embedded" Ignite,
the user application will not be able to function any way, so killing the
node does sound like a better and *safer* option.

D.

Re: IEP-14: Ignite failures handling (Discussion)

[Andrey Kuznetsov]

The most doubtful thing is 'stopping'. What if node does not respond due to
critical failure?

2018-03-13 15:16 GMT+03:00 Dmitry Pavlov :

> Dmitriy, alternative is "kill if standalone, stop if embedded"
>
> User will be still able to set something like
> -DNODE_CRASH_ACTION="kill"
> if ignite.sh is not used and user accepts alternative that whole process
> would be killed if node is crashed.
>
> Default would be 'node stop', but not hang up infinetely.
>
> Sincerely,
> Dmitriy Pavlov
>
> вт, 13 мар. 2018 г. в 14:53, Dmitriy Setrakyan :
>
> --
Best regards,
  Andrey Kuznetsov.

Re: MAC addresses emulation in Testing Framework

[Dmitry Pavlov]

Sure, agree here that static/final and reflection update is not best
practice.

вт, 13 мар. 2018 г. в 11:26, Vyacheslav Daradur :

> Dmitry, I've changed a logic of my tests and reflection isn't needed
> anymore.
>
> Using reflection in tests, especially on 'private static | final'
> fields may provide side-effects on other tests in a common test suite
> which will be started in same JVM because of a previous value that may
> be cached in other classes.
>
> You can easily find such candidates by searching 'of
> 'GridTestUtils.setFieldValue(null' in the project.
>
>
>
> On Tue, Mar 6, 2018 at 11:19 PM, Dmitry Pavlov 
> wrote:
> > Hi Vyacheslav,
> >
> > Why do you think reflection is bad in that case? Tests often use
> > reflection, moreover U.field() to access some private stuff and test it.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > вт, 6 мар. 2018 г. в 21:11, Vyacheslav Daradur :
> >
> >> Hi, Igniters!
> >>
> >> I need your help about the following question:
> >>
> >> How to set-up (emulate) custom MAC address at node startup in Testing
> >> Framework?
> >>
> >> I need to write unit-test that checks requests distribution which
> >> depends on ClusterNodes MAC addresses. I tried to change it after
> >> instance startup via reflection but looks like a bad idea and may lead
> >> to unexpected behavior.
> >>
> >>
> >> --
> >> Best Regards, Vyacheslav D.
> >>
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: IEP-14: Ignite failures handling (Discussion)

[Dmitry Pavlov]

Dmitriy, alternative is "kill if standalone, stop if embedded"

User will be still able to set something like
-DNODE_CRASH_ACTION="kill"
if ignite.sh is not used and user accepts alternative that whole process
would be killed if node is crashed.

Default would be 'node stop', but not hang up infinetely.

Sincerely,
Dmitriy Pavlov

вт, 13 мар. 2018 г. в 14:53, Dmitriy Setrakyan :

> Guys, I do not understand the alternative. If Ignite is frozen and causes
> the whole grid to freeze, how can we justify not killing it? Will uses
> rather have their applications freeze?
>
> I would consider real life use cases here. Can someone present a life
> example where keeping a frozen grid node around is better than killing JVM?
>
> D.
>
> On Tue, Mar 13, 2018 at 6:16 AM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > I also like "kill if standalone, stop if embedded" by default. A use can
> > change it to kill for embedded mode, but it will be a controlled safe
> > choice.
> >
> > 2018-03-13 11:26 GMT+03:00 Vladimir Ozerov :
> >
> > > +1 for "kill if standalone, stop if embedded". We should never kill a
> > > process in embedded node because it might be disastrous for user
> > > application.
> > >
> > > On Tue, Mar 13, 2018 at 10:41 AM, Dmitry Pavlov  >
> > > wrote:
> > >
> > > > Denis, Dmitriy, I am not sure I agree here, please see close
> analogue -
> > > JVM
> > > > itself, and its parameter ExitOnOutOfMemoryError,- it is not default.
> > > >
> > > > If server node is started from sh script, kill OK for me, as process
> is
> > > > controlled only by ignite.  It is sufficient to add option to
> override
> > > > default for sh script.
> > > >
> > > > Users interested in this behaviour may also setup this option to
> "kill"
> > > >
> > > > If server node is started from java, it should never kill whole
> > process.
> > > > This mode is not prohibited by docs, users are allowed to start
> several
> > > > nodes in one process, run its own application logic in this node.
> > > >
> > > > Why we should kill user code running? It could be negative surprise
> to
> > > > user.
> > > >
> > > >
> > > >
> > > > вт, 13 мар. 2018 г. в 8:26, Dmitriy Setrakyan  >:
> > > >
> > > > > On Tue, Mar 13, 2018 at 1:18 AM, Andrey Kornev <
> > > andrewkor...@hotmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > I believe the only reasonable way to handle a critical system
> > failure
> > > > (as
> > > > > > it is defined in the IEP) is a JVM halt (not a graceful
> > > > exit/shutdown!).
> > > > > > The sooner - the better, lesser impact. There’s simply no way to
> > > reason
> > > > > > about the state of the system in a situation like that, all bets
> > are
> > > > off.
> > > > > > Any other policy would only confuse the matters and in all
> > likelihood
> > > > > make
> > > > > > things worse.
> > > > > >
> > > > > > In practice, SREs/Operations would very much rather have a
> process
> > > die
> > > > a
> > > > > > quick clean death, than let it run indefinitely and hope that
> it’ll
> > > > > somehow
> > > > > > recover by itself at some point in future, potentially degrading
> > the
> > > > > > overall system stability and availability all the while.
> > > > > >
> > > > >
> > > > > Completely agree.
> > > > >
> > > >
> > >
> >
>

Re: Data eviction/expiration from Ignite persistence

[Dmitry Pavlov]

Hi Denis,

I've created summary of terms here
https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Durable+Memory+-+under+the+hood#IgniteDurableMemory-underthehood-Eviction,rotationandexpiration

Hope this should solve a lot of miscommunications.

In this thread I meant only Expiration (aka TTL)

Sincerely,
Dmitriy Pavlov

вт, 13 мар. 2018 г. в 10:50, Alexey Goncharuk :

> Denis,
>
> What do you mean by 'current behavior when data is evicted from the memory
> only'? TTL expiration effectively means that the corresponding key-value
> pairs are destroyed. If you are talking about page replacement, then there
> is no way to do this on per-key basis because a page must be replaced as a
> whole and it makes no sense to track keys.
>
> --AG
>
> 2018-03-13 0:03 GMT+03:00 Denis Magda :
>
> > Dmitriy,
> >
> > It will break the current default behavior when data is evicted from the
> > memory only, and I would disagree that it's a right decision overall.
> >
> > There are many scenarios when users need to have the eviction in the
> memory
> > layer and preserve data on disk for later usage. So, can we keep what we
> > have now and merely expand the eviction to disk if the user requires it?
> >
> > --
> > Denis
> >
> >
> > On Mon, Mar 12, 2018 at 1:35 PM, Dmitry Pavlov 
> > wrote:
> >
> > > Denis,
> > >
> > > I suppose there is no configuration will be required. If TTL configured
> > > entry will be removed from disk & memory both.
> > >
> > > SIncerely,
> > > Dmitriy Pavlov
> > >
> > > пн, 12 мар. 2018 г. в 23:32, Denis Magda :
> > >
> > > > Alexey, Dmitriy,
> > > >
> > > > What would be the configuration parameter that defines if the
> eviction
> > > > should happen in the in-memory layer only or in both memory and disk?
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On Mon, Mar 12, 2018 at 9:22 AM, Alexey Goncharuk <
> > > > alexey.goncha...@gmail.com> wrote:
> > > >
> > > > > Val,
> > > > >
> > > > > Yes, the entries will be removed from both memory and persistence.
> > > > >
> > > > > 2018-03-12 19:20 GMT+03:00 Valentin Kulichenko <
> > > > > valentin.kuliche...@gmail.com>:
> > > > >
> > > > > > Alex,
> > > > > >
> > > > > > What is behavior going to be after IGNITE-5874 is fixed? Will
> > expired
> > > > > entry
> > > > > > be removed from both memory and persistence?
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Sat, Mar 10, 2018 at 12:06 AM, Alexey Goncharuk <
> > > > > > alexey.goncha...@gmail.com> wrote:
> > > > > >
> > > > > > > The ticket [1] is in patch available state looks good, the only
> > > thing
> > > > > > left
> > > > > > > there is to transfer old entries to new storage. I hope Andrey
> > will
> > > > > have
> > > > > > > time to finish this soon, so we can target the fix for 2.5.
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-5874
> > > > > > >
> > > > > > > 2018-03-09 22:51 GMT+03:00 Denis Magda :
> > > > > > >
> > > > > > > > Val,
> > > > > > > >
> > > > > > > > I'd like to hear Alexey G. opinion on this? Alex, please
> chime
> > > in.
> > > > > > > >
> > > > > > > > In general, the more deployments the persistence will get the
> > > more
> > > > > > demand
> > > > > > > > we will see for that capability. Personally, I'd create a
> > ticket
> > > > for
> > > > > > now
> > > > > > > > and put it off to our backlog.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Denis
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Mar 9, 2018 at 9:34 AM, Dmitriy Setrakyan <
> > > > > > dsetrak...@apache.org
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Fri, Mar 9, 2018 at 3:43 AM, Dmitry Pavlov <
> > > > > dpavlov@gmail.com
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > As far as I know there is no plans. Denis please correct
> me
> > > if
> > > > > I'm
> > > > > > > > wrong.
> > > > > > > > > >
> > > > > > > > > > But users found these or similar bugs, it seems we need
> to
> > > > > support
> > > > > > > PDS
> > > > > > > > > and
> > > > > > > > > > TTL.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > We should either support it or throw a clear  exception on
> > > > startup
> > > > > > > > clearly
> > > > > > > > > stating that it is not. I suppose, it should be the latter
> > for
> > > > now.
> > > > > > > > > Dmitriy, any chance you can file a ticket for it?
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: IEP-14: Ignite failures handling (Discussion)

[Dmitriy Setrakyan]

Guys, I do not understand the alternative. If Ignite is frozen and causes
the whole grid to freeze, how can we justify not killing it? Will uses
rather have their applications freeze?

I would consider real life use cases here. Can someone present a life
example where keeping a frozen grid node around is better than killing JVM?

D.

On Tue, Mar 13, 2018 at 6:16 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> I also like "kill if standalone, stop if embedded" by default. A use can
> change it to kill for embedded mode, but it will be a controlled safe
> choice.
>
> 2018-03-13 11:26 GMT+03:00 Vladimir Ozerov :
>
> > +1 for "kill if standalone, stop if embedded". We should never kill a
> > process in embedded node because it might be disastrous for user
> > application.
> >
> > On Tue, Mar 13, 2018 at 10:41 AM, Dmitry Pavlov 
> > wrote:
> >
> > > Denis, Dmitriy, I am not sure I agree here, please see close analogue -
> > JVM
> > > itself, and its parameter ExitOnOutOfMemoryError,- it is not default.
> > >
> > > If server node is started from sh script, kill OK for me, as process is
> > > controlled only by ignite.  It is sufficient to add option to override
> > > default for sh script.
> > >
> > > Users interested in this behaviour may also setup this option to "kill"
> > >
> > > If server node is started from java, it should never kill whole
> process.
> > > This mode is not prohibited by docs, users are allowed to start several
> > > nodes in one process, run its own application logic in this node.
> > >
> > > Why we should kill user code running? It could be negative surprise to
> > > user.
> > >
> > >
> > >
> > > вт, 13 мар. 2018 г. в 8:26, Dmitriy Setrakyan :
> > >
> > > > On Tue, Mar 13, 2018 at 1:18 AM, Andrey Kornev <
> > andrewkor...@hotmail.com
> > > >
> > > > wrote:
> > > >
> > > > > I believe the only reasonable way to handle a critical system
> failure
> > > (as
> > > > > it is defined in the IEP) is a JVM halt (not a graceful
> > > exit/shutdown!).
> > > > > The sooner - the better, lesser impact. There’s simply no way to
> > reason
> > > > > about the state of the system in a situation like that, all bets
> are
> > > off.
> > > > > Any other policy would only confuse the matters and in all
> likelihood
> > > > make
> > > > > things worse.
> > > > >
> > > > > In practice, SREs/Operations would very much rather have a process
> > die
> > > a
> > > > > quick clean death, than let it run indefinitely and hope that it’ll
> > > > somehow
> > > > > recover by itself at some point in future, potentially degrading
> the
> > > > > overall system stability and availability all the while.
> > > > >
> > > >
> > > > Completely agree.
> > > >
> > >
> >
>

[GitHub] ignite pull request #3625: Ignite wc 157

[vveider]

GitHub user vveider opened a pull request:

https://github.com/apache/ignite/pull/3625

Ignite wc 157



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-wc-157

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3625.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3625


commit e7f72baeaf7eac33513b30089bec50d922c4b94b
Author: alexdel 
Date:   2018-02-21T04:56:46Z

WC-157. Web Console. Controller renamed.

commit c04551bc0b0329b92b4490eff83da7c0352a9a42
Author: alexdel 
Date:   2018-02-21T06:14:43Z

WC-157. Web Console. Components renamed.

commit c931ebc5e2452957bbd2a37a4d191c569ec2de17
Author: alexdel 
Date:   2018-02-21T06:49:57Z

WC-157. Web Console. Notebook compoment splitted from queries screen

commit b0d06cc781d25e5e65803ddcee188a98ee53af97
Author: alexdel 
Date:   2018-02-21T06:56:08Z

WC-157. Web Console. Barebone for page-queries cmp.

commit 57931fbbd4454b62b0764ce0232ae548eb90988e
Author: alexdel 
Date:   2018-02-21T09:37:18Z

WC-157. Web Console. Tabs for queries screen.

commit cfcd4841b8b77a87720e590e012e82d095fdc6ae
Author: alexdel 
Date:   2018-02-22T07:08:50Z

WC-157. Web Console. Upgraded notebooks list routing and layout.

commit 36a966659b89487d1c0004e2d9e2e3ff69fa306d
Author: alexdel 
Date:   2018-02-22T08:36:54Z

WC-157. Web Console. Showing lists of notebooks.

commit 1f9feb75d3618ce10ceec2aecae25ed191f36076
Author: alexdel 
Date:   2018-02-22T09:06:17Z

WC-157. Web Console. Links for notebooks in grid.

commit 39d74238ccf3f268ba0ee1c491aa85244a6ad554
Author: alexdel 
Date:   2018-02-22T09:26:30Z

WC-157. Web Console. WIP.

commit e96dc3c3a49af7938df403c656ff102712c4b639
Author: alexdel 
Date:   2018-02-26T05:48:31Z

WC-157. Web Console. Notebooks list ready.

commit 2c9c3546d68aee0f100cbf98f13dc9a55cdd1d83
Author: alexdel 
Date:   2018-02-26T07:16:29Z

WC-157. Web Console. Delete notebooks.

commit 55dd3870f2a686b09b398bda74ec5da4e49b7cee
Author: alexdel 
Date:   2018-02-27T04:26:30Z

WC-157. Web Console. Rendering slots with transclusion

commit 40ea0722d47cdfd3f5c943a458271ad2d2cbcac2
Author: alexdel 
Date:   2018-02-27T09:20:52Z

WC-157. Web Console. Creating notebooks facilities.

commit 9ad3a058b8415a0f6ff24bb3b46d13afe1a09b8e
Author: alexdel 
Date:   2018-02-27T09:30:33Z

WC-157. Web Console. Cleaning slots.

commit a09502b358fba7369fe8d269fcc7b0c90fc9bab7
Author: alexdel 
Date:   2018-02-27T10:50:28Z

WC-157. Web Console. Demo support for notebook changes.

commit be9381063c2e04775c0d17ac4bf44e70617084ea
Author: alexdel 
Date:   2018-02-27T10:57:18Z

WC-157. Web Console. "Back to notebooks" link.

commit 82cf684445d64396305a04191eb0873702fbf020
Author: alexdel 
Date:   2018-02-28T03:04:50Z

WC-157. Web Console. Style fix.

commit 94b1bca08f3799f1d1e32f7578c1cfee10a1ffce
Author: alexdel 
Date:   2018-02-28T03:15:47Z

WC-157. Web Console. Loading notebooks indication.

commit fa45fd5a78f86135bd306d21db772503b4cea5c2
Author: alexdel 
Date:   2018-02-28T05:57:44Z

WC-157. Web Console. Modal wrapped in promise.

commit 705d845d9d64238b5e3be7079fbdae98b388ffce
Author: alexdel 
Date:   2018-02-28T06:24:40Z

WC-157. Web Console. Texts for cloning mode.

commit 6eed76cf21bd48835629d15cc9a6ec837071ec14
Author: alexdel 
Date:   2018-02-28T06:35:54Z

WC-157. Web Console. Sorting fixed.

commit 59567e1f43644457dfced368b23a811a15c33cdb
Author: alexdel 
Date:   2018-02-28T09:47:04Z

Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite 
into ignite-wc-157

commit 7ad000d09e2c1c8242ee6dac53b2c01b8fd7d2cc
Author: Ilya Borisov 
Date:   2017-12-01T03:41:03Z

WC-157. Breadcrumbs back-ported.
(cherry picked from commit 154177b)
(cherry picked from commit 25a22d4)

commit 75d3478ed9b88e1894e7dc57e45d43fe049c4128
Author: Ilya Borisov 
Date:   2017-12-12T06:59:08Z

WC-157. Web Console. Add "home" icon.

(cherry picked from commit 45bfcc8)

commit 52c3206f0ac54d77ae5762e11189be821ac3b850
Author: Ilya Borisov 
Date:   2017-12-12T07:00:24Z

WC-157. Web Console. Transclude breadcrumbs "home" image into first 
element, use svg icon instead of an asset.

(cherry picked from commit 526547f)

commit 33d3d2e2f968f11289237ff0809b244991bb2129
Author: alexdel 
Date:   2018-02-28T10:57:52Z

WC-157. Web Console. Breadcrumbs for notebooks added.

[jira] [Created] (IGNITE-7931) Wrong arguments for `keys` in DataStreamerImpl

[Ivan Fedotov (JIRA)]

Ivan Fedotov created IGNITE-7931:


 Summary:  Wrong arguments for `keys` in DataStreamerImpl
 Key: IGNITE-7931
 URL: https://issues.apache.org/jira/browse/IGNITE-7931
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov


When creating \{{keys=new (...);}} [1],[2] result of `U.capacity` is passed 
as `loadfactor` value. When loadFactory == U.capacity, initial size of table is 
1. This leads to performance penalty due to rehashing of internal map.

[1][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L633]

[2][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L574]

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7930) Partition map hang in incorrect state when backup filter is assigned

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-7930:
-

 Summary: Partition map hang in incorrect state when backup filter 
is assigned
 Key: IGNITE-7930
 URL: https://issues.apache.org/jira/browse/IGNITE-7930
 Project: Ignite
  Issue Type: Bug
Reporter: Vladislav Pyatkov
 Attachments: IgnitePdsRebalanceCompletionTest.java

The test ([^IgnitePdsRebalanceCompletionTest.java]) shown, which some partition 
turn up OWNING (but this should not be so) state and whole cluster hangs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: IEP-14: Ignite failures handling (Discussion)

[Alexey Goncharuk]

I also like "kill if standalone, stop if embedded" by default. A use can
change it to kill for embedded mode, but it will be a controlled safe
choice.

2018-03-13 11:26 GMT+03:00 Vladimir Ozerov :

> +1 for "kill if standalone, stop if embedded". We should never kill a
> process in embedded node because it might be disastrous for user
> application.
>
> On Tue, Mar 13, 2018 at 10:41 AM, Dmitry Pavlov 
> wrote:
>
> > Denis, Dmitriy, I am not sure I agree here, please see close analogue -
> JVM
> > itself, and its parameter ExitOnOutOfMemoryError,- it is not default.
> >
> > If server node is started from sh script, kill OK for me, as process is
> > controlled only by ignite.  It is sufficient to add option to override
> > default for sh script.
> >
> > Users interested in this behaviour may also setup this option to "kill"
> >
> > If server node is started from java, it should never kill whole process.
> > This mode is not prohibited by docs, users are allowed to start several
> > nodes in one process, run its own application logic in this node.
> >
> > Why we should kill user code running? It could be negative surprise to
> > user.
> >
> >
> >
> > вт, 13 мар. 2018 г. в 8:26, Dmitriy Setrakyan :
> >
> > > On Tue, Mar 13, 2018 at 1:18 AM, Andrey Kornev <
> andrewkor...@hotmail.com
> > >
> > > wrote:
> > >
> > > > I believe the only reasonable way to handle a critical system failure
> > (as
> > > > it is defined in the IEP) is a JVM halt (not a graceful
> > exit/shutdown!).
> > > > The sooner - the better, lesser impact. There’s simply no way to
> reason
> > > > about the state of the system in a situation like that, all bets are
> > off.
> > > > Any other policy would only confuse the matters and in all likelihood
> > > make
> > > > things worse.
> > > >
> > > > In practice, SREs/Operations would very much rather have a process
> die
> > a
> > > > quick clean death, than let it run indefinitely and hope that it’ll
> > > somehow
> > > > recover by itself at some point in future, potentially degrading the
> > > > overall system stability and availability all the while.
> > > >
> > >
> > > Completely agree.
> > >
> >
>

[GitHub] ignite pull request #3600: IGNITE-7860 JDBC thin driver: set default socket ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3600


---

[jira] [Created] (IGNITE-7929) Web console: error frame too long on sign in

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-7929:
--

 Summary: Web console: error frame too long on sign in
 Key: IGNITE-7929
 URL: https://issues.apache.org/jira/browse/IGNITE-7929
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
 Fix For: 2.5
 Attachments: screenshot-1.png

To reproduce enter incorrect email and click 'Sign in'



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7928) Exception is not propagated to the C# client and the app hangs

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-7928:
-

 Summary: Exception is not propagated to the C# client and the app 
hangs
 Key: IGNITE-7928
 URL: https://issues.apache.org/jira/browse/IGNITE-7928
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.3
Reporter: Evgenii Zhuravlev


An exception like https://issues.apache.org/jira/browse/IGNITE-1903 is not 
propagated to the C# client:
the issue has happened during JNI call, that is why .NET hung.
The marshaller is unable to unmarshal CacheStoreFactory class (it is absent on 
the client node).
 
Stack trace:
 


{code:java}
class org.apache.ignite.IgniteException: Platform 
error:System.ArgumentNullException: Value cannot be null. Parameter name: key   
 at System.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument)   
 at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)    at 
System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& value)    
at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type type)    at 
Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadFullObject[T](Int32 pos, Type 
typeOverride)    at 
Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
typeOverride)    at 
Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride)   
 at Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadBinaryObject[T](Boolean 
doDetach)    at 
Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
typeOverride)    at 
Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride)   
 at Apache.Ignite.Core.Impl.Cache.Store.CacheStore.CreateInstance(Int64 memPtr, 
HandleRegistry registry)    at 
Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.CacheStoreCreate(Int64 
memPtr)    at 
Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.InLongOutLong(Void* 
target, Int32 type, Int64 val)         at 
org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:373)
         at 
org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:423)
         at 
org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:434)
         at 
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
         at 
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
 Method)         at 
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.cacheStoreCreate(PlatformCallbackGateway.java:65)
         at 
org.apache.ignite.internal.processors.platform.dotnet.PlatformDotNetCacheStore.initialize(PlatformDotNetCacheStore.java:403)
         at 
org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore0(PlatformProcessorImpl.java:650)
         at 
org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore(PlatformProcessorImpl.java:293)
         at 
org.apache.ignite.internal.processors.cache.store.CacheOsStoreManager.start0(CacheOsStoreManager.java:60)
         at 
org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.start(GridCacheManagerAdapter.java:50)
         at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1097)
         at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1826)
         at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCacheStartRequests(CacheAffinitySharedManager.java:428)
         at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCachesChanges(CacheAffinitySharedManager.java:611)
         at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCustomExchangeTask(GridCacheProcessor.java:338)
         at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.processCustomTask(GridCachePartitionExchangeManager.java:2142)
         at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2231)
         at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)      
   at java.lang.Thread.run(Thread.java:748){code}
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: IEP-14: Ignite failures handling (Discussion)

[Vladimir Ozerov]

+1 for "kill if standalone, stop if embedded". We should never kill a
process in embedded node because it might be disastrous for user
application.

On Tue, Mar 13, 2018 at 10:41 AM, Dmitry Pavlov 
wrote:

> Denis, Dmitriy, I am not sure I agree here, please see close analogue - JVM
> itself, and its parameter ExitOnOutOfMemoryError,- it is not default.
>
> If server node is started from sh script, kill OK for me, as process is
> controlled only by ignite.  It is sufficient to add option to override
> default for sh script.
>
> Users interested in this behaviour may also setup this option to "kill"
>
> If server node is started from java, it should never kill whole process.
> This mode is not prohibited by docs, users are allowed to start several
> nodes in one process, run its own application logic in this node.
>
> Why we should kill user code running? It could be negative surprise to
> user.
>
>
>
> вт, 13 мар. 2018 г. в 8:26, Dmitriy Setrakyan :
>
> > On Tue, Mar 13, 2018 at 1:18 AM, Andrey Kornev  >
> > wrote:
> >
> > > I believe the only reasonable way to handle a critical system failure
> (as
> > > it is defined in the IEP) is a JVM halt (not a graceful
> exit/shutdown!).
> > > The sooner - the better, lesser impact. There’s simply no way to reason
> > > about the state of the system in a situation like that, all bets are
> off.
> > > Any other policy would only confuse the matters and in all likelihood
> > make
> > > things worse.
> > >
> > > In practice, SREs/Operations would very much rather have a process die
> a
> > > quick clean death, than let it run indefinitely and hope that it’ll
> > somehow
> > > recover by itself at some point in future, potentially degrading the
> > > overall system stability and availability all the while.
> > >
> >
> > Completely agree.
> >
>

Re: MAC addresses emulation in Testing Framework

[Vyacheslav Daradur]

Dmitry, I've changed a logic of my tests and reflection isn't needed anymore.

Using reflection in tests, especially on 'private static | final'
fields may provide side-effects on other tests in a common test suite
which will be started in same JVM because of a previous value that may
be cached in other classes.

You can easily find such candidates by searching 'of
'GridTestUtils.setFieldValue(null' in the project.



On Tue, Mar 6, 2018 at 11:19 PM, Dmitry Pavlov  wrote:
> Hi Vyacheslav,
>
> Why do you think reflection is bad in that case? Tests often use
> reflection, moreover U.field() to access some private stuff and test it.
>
> Sincerely,
> Dmitriy Pavlov
>
> вт, 6 мар. 2018 г. в 21:11, Vyacheslav Daradur :
>
>> Hi, Igniters!
>>
>> I need your help about the following question:
>>
>> How to set-up (emulate) custom MAC address at node startup in Testing
>> Framework?
>>
>> I need to write unit-test that checks requests distribution which
>> depends on ClusterNodes MAC addresses. I tried to change it after
>> instance startup via reflection but looks like a bad idea and may lead
>> to unexpected behavior.
>>
>>
>> --
>> Best Regards, Vyacheslav D.
>>



-- 
Best Regards, Vyacheslav D.

Re: MD5 sums in the releases

[Vladimir Ozerov]

Hi Cos,

Thank you for noticing it. As ASF veteran, could you please confirm that it
is valid to remove MD5 from already published release? I am in doubts
because it means that we voted on one fileset and released another. Is it
Ok from ASF perspective?

Vladimir.

On Mon, Mar 12, 2018 at 9:16 PM, Konstantin Boudnik  wrote:

> Please be aware about the changes in the Foundation's release policy [1]
>
> * SHOULD NOT supply a MD5 checksum file
>
> [1] https://www.apache.org/dev/release-distribution#sigs-and-sums
> --
>   With regards,
> Konstantin (Cos) Boudnik
> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
>

Re: Data eviction/expiration from Ignite persistence

[Alexey Goncharuk]

Denis,

What do you mean by 'current behavior when data is evicted from the memory
only'? TTL expiration effectively means that the corresponding key-value
pairs are destroyed. If you are talking about page replacement, then there
is no way to do this on per-key basis because a page must be replaced as a
whole and it makes no sense to track keys.

--AG

2018-03-13 0:03 GMT+03:00 Denis Magda :

> Dmitriy,
>
> It will break the current default behavior when data is evicted from the
> memory only, and I would disagree that it's a right decision overall.
>
> There are many scenarios when users need to have the eviction in the memory
> layer and preserve data on disk for later usage. So, can we keep what we
> have now and merely expand the eviction to disk if the user requires it?
>
> --
> Denis
>
>
> On Mon, Mar 12, 2018 at 1:35 PM, Dmitry Pavlov 
> wrote:
>
> > Denis,
> >
> > I suppose there is no configuration will be required. If TTL configured
> > entry will be removed from disk & memory both.
> >
> > SIncerely,
> > Dmitriy Pavlov
> >
> > пн, 12 мар. 2018 г. в 23:32, Denis Magda :
> >
> > > Alexey, Dmitriy,
> > >
> > > What would be the configuration parameter that defines if the eviction
> > > should happen in the in-memory layer only or in both memory and disk?
> > >
> > > --
> > > Denis
> > >
> > > On Mon, Mar 12, 2018 at 9:22 AM, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com> wrote:
> > >
> > > > Val,
> > > >
> > > > Yes, the entries will be removed from both memory and persistence.
> > > >
> > > > 2018-03-12 19:20 GMT+03:00 Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com>:
> > > >
> > > > > Alex,
> > > > >
> > > > > What is behavior going to be after IGNITE-5874 is fixed? Will
> expired
> > > > entry
> > > > > be removed from both memory and persistence?
> > > > >
> > > > > -Val
> > > > >
> > > > > On Sat, Mar 10, 2018 at 12:06 AM, Alexey Goncharuk <
> > > > > alexey.goncha...@gmail.com> wrote:
> > > > >
> > > > > > The ticket [1] is in patch available state looks good, the only
> > thing
> > > > > left
> > > > > > there is to transfer old entries to new storage. I hope Andrey
> will
> > > > have
> > > > > > time to finish this soon, so we can target the fix for 2.5.
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-5874
> > > > > >
> > > > > > 2018-03-09 22:51 GMT+03:00 Denis Magda :
> > > > > >
> > > > > > > Val,
> > > > > > >
> > > > > > > I'd like to hear Alexey G. opinion on this? Alex, please chime
> > in.
> > > > > > >
> > > > > > > In general, the more deployments the persistence will get the
> > more
> > > > > demand
> > > > > > > we will see for that capability. Personally, I'd create a
> ticket
> > > for
> > > > > now
> > > > > > > and put it off to our backlog.
> > > > > > >
> > > > > > > --
> > > > > > > Denis
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Mar 9, 2018 at 9:34 AM, Dmitriy Setrakyan <
> > > > > dsetrak...@apache.org
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Fri, Mar 9, 2018 at 3:43 AM, Dmitry Pavlov <
> > > > dpavlov@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > As far as I know there is no plans. Denis please correct me
> > if
> > > > I'm
> > > > > > > wrong.
> > > > > > > > >
> > > > > > > > > But users found these or similar bugs, it seems we need to
> > > > support
> > > > > > PDS
> > > > > > > > and
> > > > > > > > > TTL.
> > > > > > > > >
> > > > > > > >
> > > > > > > > We should either support it or throw a clear  exception on
> > > startup
> > > > > > > clearly
> > > > > > > > stating that it is not. I suppose, it should be the latter
> for
> > > now.
> > > > > > > > Dmitriy, any chance you can file a ticket for it?
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: IEP-14: Ignite failures handling (Discussion)

[Dmitry Pavlov]

Denis, Dmitriy, I am not sure I agree here, please see close analogue - JVM
itself, and its parameter ExitOnOutOfMemoryError,- it is not default.

If server node is started from sh script, kill OK for me, as process is
controlled only by ignite.  It is sufficient to add option to override
default for sh script.

Users interested in this behaviour may also setup this option to "kill"

If server node is started from java, it should never kill whole process.
This mode is not prohibited by docs, users are allowed to start several
nodes in one process, run its own application logic in this node.

Why we should kill user code running? It could be negative surprise to user.



вт, 13 мар. 2018 г. в 8:26, Dmitriy Setrakyan :

> On Tue, Mar 13, 2018 at 1:18 AM, Andrey Kornev 
> wrote:
>
> > I believe the only reasonable way to handle a critical system failure (as
> > it is defined in the IEP) is a JVM halt (not a graceful exit/shutdown!).
> > The sooner - the better, lesser impact. There’s simply no way to reason
> > about the state of the system in a situation like that, all bets are off.
> > Any other policy would only confuse the matters and in all likelihood
> make
> > things worse.
> >
> > In practice, SREs/Operations would very much rather have a process die a
> > quick clean death, than let it run indefinitely and hope that it’ll
> somehow
> > recover by itself at some point in future, potentially degrading the
> > overall system stability and availability all the while.
> >
>
> Completely agree.
>

Re: IGNITE-5357 is ready for review (Replicated cache reads load balancing)

[Vyacheslav Daradur]

Dmitry,

Nickolay accepted PR changes at Upsource [1].

Latest ci.build [2] looks good in comparison with master [3].

Following tests passed locally:
CacheAffinityCallSelfTest.testAffinityCallFromClientRestartNode
CacheAffinityCallSelfTest.testAffinityCallRestartNode
IgniteOptimisticTxSuspendResumeMultiServerTest.testTxTimeoutOnSuspend
IgniteSqlSplitterSelfTest.testReplicatedTablesUsingPartitionedCacheSegmentedClient


[1] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-509
[2] https://ci.ignite.apache.org/viewLog.html?buildId=1134466
[3] https://ci.ignite.apache.org/viewLog.html?buildId=1134372

On Mon, Mar 5, 2018 at 7:16 PM, Vyacheslav Daradur  wrote:
> Dmitry, I saw them, but it looks like just randomness.
>
> I've checked it locally several times.
> They failed only in one TeamCity's build of four.
>
> Started build once again to be sure.
>
> On Mon, Mar 5, 2018 at 6:59 PM, Dmitry Pavlov  wrote:
>> I can see Nikolay Izhikov as reviewer in Upsource.
>>
>> Nikolay, would you run review first?
>>
>> I've found several suspicious tests : Test fail rate is less than 1%, it is
>> probably new failure
>> IgniteCacheTestSuite2:
>> GridCachePartitionedTxSingleThreadedSelfTest.testOptimisticReadCommittedRollback
>> (fail rate 0,0%)
>> IgniteCacheTestSuite2:
>> GridCachePartitionedTxSingleThreadedSelfTest.testOptimisticRepeatableReadRollback
>> (fail rate 0,0%)
>> IgniteCacheTestSuite2:
>> GridCachePartitionedTxSingleThreadedSelfTest.testPessimisticReadCommittedCommit
>> (fail rate 0,0%)
>> IgniteCacheTestSuite2:
>> GridCachePartitionedTxSingleThreadedSelfTest.testPessimisticReadCommittedRollback
>> (fail rate 0,0%)
>> IgniteCacheTestSuite2:
>> GridCachePartitionedTxSingleThreadedSelfTest.testPessimisticSerializableCommit
>> (fail rate 0,0%)
>>
>> Vyacheslav, could you please check if these failures are related to the new
>> changes?
>>
>>
>> пн, 5 мар. 2018 г. в 18:50, Vyacheslav Daradur :
>>
>>> I've done some test-builds iteration on the weekends.
>>>
>>> Tests [1] look well.
>>>
>>> Does anyone have time to do the final review [2][3] and merge it?
>>>
>>>
>>> [1] https://ci.ignite.apache.org/viewLog.html?buildId=1125676
>>> [2] https://github.com/apache/ignite/pull/3578
>>> [3] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-509
>>>
>>>
>>> On Fri, Mar 2, 2018 at 10:17 PM, Vyacheslav Daradur 
>>> wrote:
>>> > Hi, Igniters!
>>> >
>>> > This task [1] is about 'get' requests distribution between primary and
>>> > backup nodes in the replicated cache if 'readFromBackup' flag is
>>> > enabled.
>>> >
>>> > I've prepared a solution [2] suggested by Alexei Scherbakov in Jira
>>> > comments. It passed prereviews by Alexei and Nikolay Izhikov.
>>> >
>>> > TeamCity tests look similar with the master branch.
>>> >
>>> > Could someone of core module maintainers do the final review [2][3]?
>>> >
>>> >
>>> > [1] https://issues.apache.org/jira/browse/IGNITE-5357
>>> > [2] https://github.com/apache/ignite/pull/3578
>>> > [3] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-509
>>> >
>>> > --
>>> > Best Regards, Vyacheslav D.
>>>
>>>
>>>
>>> --
>>> Best Regards, Vyacheslav D.
>>>
>
>
>
> --
> Best Regards, Vyacheslav D.



-- 
Best Regards, Vyacheslav D.

Re: [RESULT] [VOTE] Apache Ignite 2.4.0 Release (RC1)

[Petr Ivanov]

There is an error in RPM documentation on site — missing header for ignite.repo 
file and formatting is also wrong.
Otherwise — I’m able to install and run Apache Ignite from RPM from ASF 
according to manual.



> On 12 Mar 2018, at 23:25, Denis Magda  wrote:
> 
> Released RPM installation section on the downloads page:
> https://ignite.apache.org/download.cgi#rpm-package
> 
> *Petr*, please double check that the section and the readme getting started
> look good:
> https://apacheignite.readme.io/docs/getting-started#section-rpm-package-installation
> 
> *Mauricio*, could you please create a patch that points out "latest" docs
> to "2.4.0"?
> 
> --
> Denis
> 
> 
> 
> On Mon, Mar 12, 2018 at 7:36 AM, Pavel Tupitsyn 
> wrote:
> 
>> NuGet packages uploaded: https://www.nuget.org/packages?q=Apache.Ignite
>> 
>> Thanks,
>> Pavel
>> 
>> 
>> On Mon, Mar 12, 2018 at 1:54 PM, Vladimir Ozerov 
>> wrote:
>> 
>>> Correct, it is a matter of time. Download links already work on my side
>>> [1].
>>> 
>>> [1] http://mirror.linux-ia64.org/apache/ignite/2.4.0/
>>> 
>>> On Mon, Mar 12, 2018 at 1:29 PM, Petr Ivanov 
>> wrote:
>>> 
 Link to 2.4.0 is pointing to RBC mirror, not Apache Dist itself.
 
 I do not know how often RBC updates its mirror, but I think we have to
 devise better solution for pointing to fresh release artifacts.
 
 
 
> On 12 Mar 2018, at 13:24, Pavel Tupitsyn 
>> wrote:
> 
> Hi Vladimir,
> 
> I see the link for 2.4.0 on https://ignite.apache.org/
 download.cgi#binaries,
> but it does not work.
> 
> On Mon, Mar 12, 2018 at 10:55 AM, Vladimir Ozerov <
>>> voze...@gridgain.com>
> wrote:
> 
>> Correction: " Apache Ignite *2.4.0* release (RC1) has been
>> accepted."
>> 
>> On Mon, Mar 12, 2018 at 10:51 AM, Vladimir Ozerov <
>>> voze...@gridgain.com
> 
>> wrote:
>> 
>>> Igniters,
>>> 
>>> Apache Ignite 2.3.0 release (RC1) has been accepted.
>>> 
>>> 5 "+1" binding votes received:
>>> - Alexey Goncharuk
>>> - Alexey Kuznetsov
>>> - Anton Vinogradov
>>> - Denis Magda
>>> - Pavel Tupitsyn
>>> 
>>> Vote thread:
>>> 
>>> *http://apache-ignite-developers.2346864.n4.nabble.
>> com/VOTE-Apache-Ignite-2-4-0-RC1-td27687.html
>>> > com/VOTE-Apache-Ignite-2-4-0-RC1-td27687.html>*
>>> 
>>> Ignite 2.4.0 will be released soon.
>>> 
>>> Vladimir.
>>> 
>> 
 
 
>>> 
>>