Re: Apache Ignite RPM packaging (Stage II)

[Peter Ivanov]

On Thu, 12 Apr 2018 at 20:04, Ilya Kasnacheev 
wrote:

> Hello! I have tried your RPM scripts.
>
> First of all, I'm not sure that apache-ignite-core is a good name for
> package which contains the actual server node kit, and that apache-ignite
> is a good name for a package that will install everything (including cpp
> bindings). How does other packages solve this naming? I would go with
> apache-ignite and apache-ignite-full.


Previous package was named ‘apache-ignite’ and installed everything.
Current package is named ‘apache-ignite’ and installs everything (via
dependencies). I see convenience in this scheme.

‘apache-ignite-core’ name was selected because it is a core - minimum
required files to start the service. But I am open to suggestions
(-service, -node, etc.)



>
> Moreover I did not find a way to start service if default installed JVM is
> Java 7 :( I understand it's EOL, still this is something that hit me.


Apache Ignite >=2.4 does not support Java 7 - it is said in documentation,
DEVNOTES and even in startup scripts.



>
> apache-ignite-docs only contains scaladoc for scalar. Who would need a
> separate package for that? Why no javadocs? Maybe it's my build problem?


‘apache-ignite-docs’ contains both Javadoc and Scalardoc if sources were
built correctly



>
> apache-ignite-libs is a totally unexpected package name. apache-ignite core
> doesn't depend on it. It doesn't enable anything out of the box. The
> package is huge.


‘apache-ignite-libs’ is an aggregation package (for now) for all optional
libs we are delivering. Possibly later they will be split more granular or
even package per lib (like php, perl, python, etc. do for their libs).
This package dependency on ‘apache-ignite-core’ may seem confusing though,
I will try to explain it in IEP at least for current iteration.

Further naming may become clear when we’ll start initiative on including
packages to popular Linux distributions and theirs community will join
naming discussions.



>
> Frankly speaking, I'm not sure that improvements over Stage I are enough as
> of now. For demo-like activity, we can probably go with one package fits
> all.
>

The process of finding the best package architecture is iterative, but
previously community agreed in split design proposed for 2.5 release.

Also, split architecture is half of proposed improvements. The other half -
new process for deploying packages to Bintray (with virtually indefinite
storage capabilities).



>
> --
> Ilya Kasnacheev
>
> 2018-04-12 19:10 GMT+03:00 Petr Ivanov :
>
> > If someone from PMCы or Committers still sees necessity about including
> > these tasks into Apache Ignite 2.5 release, this is the last chance to do
> > so.
> > Otherwise this task will be moved to at 2.6 release at least, or even
> > moved to backlog indefinitely.
> >
> >
> >
> > > On 9 Apr 2018, at 19:08, Petr Ivanov  wrote:
> > >
> > > To top new RPM architecture off, update to release process is
> introduced
> > — [1] [2].
> > >
> > > Both tasks (this one and IGNITE-7647) are ready for review and should
> be
> > merged simultaneously.
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-8172
> > > [2] https://github.com/apache/ignite-release/pull/1
> > >
> > >
> > >
> > >
> > >> On 2 Apr 2018, at 18:22, Ilya Kasnacheev 
> > wrote:
> > >>
> > >> Hello!
> > >>
> > >> Let me share my idea of how this shoud work. Splitting package into
> > >> sub-packages should be dependency-driven.
> > >>
> > >> It means that all Ignite modules without dependencies or with small
> > >> dependencies (such as ignite-log4j) should be included in ignite-core.
> > It
> > >> doesn't make sense to make a zillion RPM packages.
> > >>
> > >> Critical things like ignite-spring and ignite-indexing should be in
> > >> ignite-core of course, even if they have dependencies. Ignite-core
> > should
> > >> be fully self-sufficient and feature-complete.
> > >>
> > >> However, e.g. .net API should probably be in a separate package,
> > because it
> > >> should depend on mono | net-core. We may also have ignite-devel
> package
> > >> which should include all modules which only make sense for developers
> > who
> > >> write code. Such as hibernate integration.
> > >>
> > >> I'm not sure about MR modules. The main question should be, does it
> have
> > >> dependencies? Can it run stand-alone without writing code?
> > >>
> > >> Hope this helps,
> > >>
> > >> --
> > >> Ilya Kasnacheev
> > >>
> > >> 2018-03-27 15:10 GMT+03:00 Petr Ivanov :
> > >>
> > >>> Hi, Igniters!
> > >>>
> > >>>
> > >>> Here are some news on our RPM packages initiative.
> > >>>
> > >>> 1. I’ve finished preliminary developing of Stage II version of RPM
> > >>> packages [1]. Main “new feature” is — split design. Also I’ve added
> > >>> package.sh script for automating package building process which will
> > help
> > >>> organise 

[GitHub] ignite pull request #3813: IGNITE-8242: Remove method GAGridUtils.getGenesFo...

[techbysample]

GitHub user techbysample opened a pull request:

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

IGNITE-8242: Remove method GAGridUtils.getGenesForChromosome() as pro…

Remove method GAGridUtils.getGenesForChromosome() as problematic when 
Chromosome contains duplicate genes. GAGridUtils.getGenesInOrderForChromosome() 
will be used instead.

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

$ git pull https://github.com/techbysample/ignite ignite-8242

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

https://github.com/apache/ignite/pull/3813.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 #3813


commit bf08d83546d9f11333894f88527d34cad2c5418b
Author: Turik Campbell 
Date:   2018-04-13T01:27:57Z

IGNITE-8242: Remove method GAGridUtils.getGenesForChromosome() as 
problematic when Chromosome contains duplicate genes.
 GAGridUtils.getGenesInOrderForChromosome() will be used 
instead.




---

[jira] [Created] (IGNITE-8242) Remove method GAGridUtils.getGenesForChromosome() as problematic when Chromosome contains duplicate genes.

[Turik Campbell (JIRA)]

Turik Campbell created IGNITE-8242:
--

 Summary: Remove method GAGridUtils.getGenesForChromosome() as 
problematic when Chromosome contains duplicate genes.
 Key: IGNITE-8242
 URL: https://issues.apache.org/jira/browse/IGNITE-8242
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Turik Campbell
Assignee: Turik Campbell
 Fix For: 2.5


Remove method GAGridUtils.getGenesForChromosome() as problematic when 
Chromosome contains duplicate genes.

GAGridUtils.getGenesInOrderForChromosome() will be used instead.



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

Re: Reconsider default WAL mode: we need something between LOG_ONLY and FSYNC

[Dmitriy Setrakyan]

On Thu, Apr 12, 2018 at 9:45 AM, Ivan Rakov  wrote:

> Dmitriy,
>
> fsync() is really slow operation - it's the main reason why FSYNC mode is
> way slower than LOG_ONLY.
> Fix includes extra fsyncs in necessary parts of code and nothing more.
> Every part is important - at the beginning of the thread I described why.
>
> 20% slow in benchmark doesn't mean than Ignite itself will become 20%
> slower. Benchmark replays only "data loading" scenario. It signals that
> maximum throughput with WAL enabled will be 20% slower. By the way, we
> already have option to disable WAL in runtime for the period of data
> loading.
>
>
Ivan, I get it, but I am sure that you can do more things in parallel. Do
we wait for the fsync call to complete? If yes, do we have to wait? Are
there other performance optimizations you can add, considering that we are
in LOG_ONLY or BACKGROUND modes and disk writes may be delayed.

D.

Re: Apache Ignite RPM packaging (Stage II)

[Dmitriy Setrakyan]

I am not sure that an email thread of over 20 messages is a good medium to
discuss proposals. In Ignite, we create IEPs. Can you please summarize your
proposal there and send a link there? Please explain not only the change
itself, but the reason why we need it.

D.

On Thu, Apr 12, 2018 at 4:00 PM, Denis Magda  wrote:

> Petr,
>
> I wouldn't postpone this until 2.6 that will be out nor earlier than 3
> months from now.
>
> *Anton V.*, could review and sign off the changes? Not sure we have a
> better person in the community who can do that.
>
> --
> Denis
>
> On Thu, Apr 12, 2018 at 9:10 AM, Petr Ivanov  wrote:
>
> > If someone from PMCы or Committers still sees necessity about including
> > these tasks into Apache Ignite 2.5 release, this is the last chance to do
> > so.
> > Otherwise this task will be moved to at 2.6 release at least, or even
> > moved to backlog indefinitely.
> >
> >
> >
> > > On 9 Apr 2018, at 19:08, Petr Ivanov  wrote:
> > >
> > > To top new RPM architecture off, update to release process is
> introduced
> > — [1] [2].
> > >
> > > Both tasks (this one and IGNITE-7647) are ready for review and should
> be
> > merged simultaneously.
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-8172
> > > [2] https://github.com/apache/ignite-release/pull/1
> > >
> > >
> > >
> > >
> > >> On 2 Apr 2018, at 18:22, Ilya Kasnacheev 
> > wrote:
> > >>
> > >> Hello!
> > >>
> > >> Let me share my idea of how this shoud work. Splitting package into
> > >> sub-packages should be dependency-driven.
> > >>
> > >> It means that all Ignite modules without dependencies or with small
> > >> dependencies (such as ignite-log4j) should be included in ignite-core.
> > It
> > >> doesn't make sense to make a zillion RPM packages.
> > >>
> > >> Critical things like ignite-spring and ignite-indexing should be in
> > >> ignite-core of course, even if they have dependencies. Ignite-core
> > should
> > >> be fully self-sufficient and feature-complete.
> > >>
> > >> However, e.g. .net API should probably be in a separate package,
> > because it
> > >> should depend on mono | net-core. We may also have ignite-devel
> package
> > >> which should include all modules which only make sense for developers
> > who
> > >> write code. Such as hibernate integration.
> > >>
> > >> I'm not sure about MR modules. The main question should be, does it
> have
> > >> dependencies? Can it run stand-alone without writing code?
> > >>
> > >> Hope this helps,
> > >>
> > >> --
> > >> Ilya Kasnacheev
> > >>
> > >> 2018-03-27 15:10 GMT+03:00 Petr Ivanov :
> > >>
> > >>> Hi, Igniters!
> > >>>
> > >>>
> > >>> Here are some news on our RPM packages initiative.
> > >>>
> > >>> 1. I’ve finished preliminary developing of Stage II version of RPM
> > >>> packages [1]. Main “new feature” is — split design. Also I’ve added
> > >>> package.sh script for automating package building process which will
> > help
> > >>> organise corresponding builds in TC as well as simplify process for
> > >>> developers who wishes to have custom packages.
> > >>> PR#3703 [2] is ready for review. Denis, in order to catch up with
> > Apache
> > >>> Ignite 2.5 release, I’d greatly appreciate your help in finding
> > reviewer.
> > >>> 2. With the help of ASF INFRA team, we now have RPM [3] and DEB [4]
> > >>> repositories on Apache Bintray. Though they are already prepared for
> > >>> hosting RPM and DEB packages respectively, and there is a way of
> > linking
> > >>> them to apache.org/dist/ignite page, there is possible alternative
> in
> > >>> storing there only plain directory layout corresponding to each
> > repository
> > >>> type (RPM and DEB) and manage this layout (repodata, distributions,
> > >>> versions, etc.) by ourselves, having more control over repositories
> but
> > >>> lacking some simplicity of deploying new releases. WDYT? Should we
> try
> > >>> Cassandra approach? They are storing their DEB packages as I
> described
> > >>> above [5].
> > >>>
> > >>> Also — a question arose while I was working on this issue: which OSes
> > (and
> > >>> which versions of each) are we going to support (if we are going) in
> > terms
> > >>> of step-by-step list? Currently RPM packages are tested only with
> > latest
> > >>> CentOS (and, respectively — RHEL), but there are a lot more RPM-based
> > >>> distributives [6] some of which are more o less popular among OS
> > community
> > >>> (ALT, Fedora, openSUSE, etc.).
> > >>>
> > >>>
> > >>> [1] https://issues.apache.org/jira/browse/IGNITE-7647
> > >>> [2] https://github.com/apache/ignite/pull/3703
> > >>> [3] https://bintray.com/apache/ignite-rpm
> > >>> [4] https://bintray.com/apache/ignite-deb
> > >>> [5] https://bintray.com/apache/cassandra/debian#files/
> > >>> [6] https://en.wikipedia.org/wiki/Category:RPM-based_Linux_
> > distributions
> > >>>
> > >>>
> > >>>
> > >>>
> >  On 15 Mar 2018, at 22:15, 

Re: Node.js client update: rev. 2

[Pavel Petroshenko]

Hi Denis,

Thank you for looking at the proposal and raising these questions! We'll
take them to discuss offline and will address your recommendations in the
next revision.

I will let Vladimir comment on the QueryEntity here though to make sure we
are on the same page.

Thanks,

P.


On Thu, Apr 12, 2018 at 2:48 PM, Denis Magda  wrote:

> Hello Pavel,
>
> Thanks for the update. Haven't heard from you guys for a while but seems
> you were too busy polishing the client. Looks great!
>
> Please consider several questions/notes:
>
>- Do we really want to migrate QueryEntity API [1] to Node.JS client? I
>heard we planned to deprecate it in the future. *Vladimir*, please share
>your thoughts.
>- I wouldn't mix key-value and SQL examples together because they
>represent different use cases of Ignite. For the sake of simplicity, I
>would create a single SqlExample file that uses DDL to configure
>tables/cache, inserts data with INSERTS and SELECTs it back (simple
> queries
>and queries with JOINs). We can base it on the database and queries used
>here [2]. Happy to brainstorm on this with you separately.
>-
>
>
> [1]
> https://github.com/nobitlost/ignite/blob/master/modules/
> clients/nodejs/examples/SqlQueryExample.js#L68
> [2] https://apacheignite-sql.readme.io/docs/getting-started
>
> --
> Denis
>
> On Wed, Apr 11, 2018 at 6:45 PM, Pavel Petroshenko 
> wrote:
>
> > Igniters,
> >
> > Just to give you an update on the next iteration of the Ignite Node.js
> thin
> > client implementation.
> >
> > The second iteration is available for review/testing.
> >
> > The changes are available in the pull request [1] or directly from our
> > repository [2].
> >
> > The short README file [3] covers:
> >
> > - the list of supported features
> > - simple instructions:
> >   * how to install the client
> >   * how to run the examples
> >   * how to run the tests
> >
> > And we actually encourage you to give it a look or even a try.
> >
> > The APIs are available both: in sources [4] and in a form of a generated
> > specification, produced automatically from the jsdoc comments [5]
> >
> > Please let us know if you have any questions.
> >
> > Thanks!
> >
> > P.
> >
> > [1] https://github.com/apache/ignite/pull/3680
> > [2] https://github.com/nobitlost/ignite/tree/master/modules/
> clients/nodejs
> > [3] https://github.com/nobitlost/ignite/blob/master/
> > modules/clients/nodejs/README.md
> > [4] https://github.com/nobitlost/ignite/blob/master/
> > modules/clients/nodejs/lib
> > [5] https://rawgit.com/nobitlost/ignite/master/modules/clients/
> nodejs/api_
> > spec/index.html
> >
>

Re: Triggering rebalancing on timeout or manually if the baseline topology is not reassembled

[Denis Magda]

Pavel, thanks for the suggestions. They would definitely work out. I would
document the one with the event subscription:
https://issues.apache.org/jira/browse/IGNITE-8241

Could you help preparing a sample code snippet with such a listener that
will be added to the doc? I know that there are some caveats related to the
way how such an event has to be processed.

Ivan, truly like your idea. Alex G., what's your thought on this?

--
Denis

On Thu, Apr 12, 2018 at 2:22 PM, Ivan Rakov  wrote:

> Guys,
>
> I also heard complaints about absence of option to automatically change
> baseline topology. They absolutely make sense.
> What Pavel suggested will work as a workaround. I think, in future
> releases we should give user an option to enable a similar behavior via
> Ignite Configuration.
> It may be called "Baseline Topology change policy". I see it as rule-based
> language, which allows to specify conditions of BLT change using several
> parameters - timeout and minimum allowed number of partition copies left
> (maybe this option should be provided also on per-cache-group level).
> Policy can also specify conditions for including new nodes in BLT if they
> are present - including node attributes filters and so on.
>
> What do you think?
>
> Best Regards,
> Ivan Rakov
>
>
> On 12.04.2018 19:41, Pavel Kovalenko wrote:
>
>> Denis,
>>
>> It's just one of the ways to implement it. We also can subscribe on node
>> join / fail events to properly track downtime of a node.
>>
>> 2018-04-12 19:38 GMT+03:00 Pavel Kovalenko :
>>
>> Denis,
>>>
>>> Using our API we can implement this task as follows:
>>> Do each minute:
>>> 1) Get all alive server nodes consistent ids =>
>>> ignite().context().discovery().aliveServerNodes() =>
>>> mapToConsistentIds().
>>> 2) Get current baseline topology => ignite().cluster().
>>> currentBaselineTopology()
>>> 3) For each node in baseline and not in alive server nodes check timeout
>>> for this node.
>>> 4) If timeout is reached remove node from baseline
>>> 5) If baseline is changed set new baseline => ignite().cluster().
>>> setNewBaseline()
>>>
>>>
>>> 2018-04-12 2:18 GMT+03:00 Denis Magda :
>>>
>>> Pavel, Val,

 So, it means that the rebalancing will be initiated only after an
 administrator remove the failed node from the topology, right?

 Next, imagine that you are that IT administrator who has to automate the
 rebalancing activation if the node failed and not recovered within 1
 minute. What would you do and what Ignite provides to fulfill the task?

 --
 Denis

 On Wed, Apr 11, 2018 at 1:01 PM, Pavel Kovalenko 
 wrote:

 Denis,
>
> In case of incomplete baseline topology IgniteCache.rebalance() will do
> nothing, because this event doesn't trigger partitions exchange or
>
 affinity

> change, so states of existing partitions are hold.
>
> 2018-04-11 22:27 GMT+03:00 Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
> Denis,
>>
>> In my understanding, in this case you should remove node from BLT and
>>
> that
>
>> will trigger the rebalancing, no?
>>
>> -Val
>>
>> On Wed, Apr 11, 2018 at 12:23 PM, Denis Magda 
>>
> wrote:
>
>> Igniters,
>>>
>>> As we know the rebalancing doesn't happen if one of the nodes goes
>>>
>> down,
>
>> thus, shrinking the baseline topology. It complies with our
>>>
>> assumption

> that
>>
>>> the node should be recovered soon and there is no need to waste
>>> CPU/memory/networking resources of the cluster shifting the data
>>>
>> around.
>
>> However, there are always edge cases. I was reasonably asked how to
>>>
>> trigger
>>
>>> the rebalancing within the baseline topology manually or on timeout
>>>
>> if:

> - It's not expected that the failed node would be resurrected in
>>>
>> the

> nearest time and
>>> - It's not likely that that node will be replaced by the other
>>>
>> one.

> The question. If I call IgniteCache.rebalance() or configure
>>> CacheConfiguration.rebalanceTimeout will the rebalancing be fired
>>>
>> within
>
>> the baseline topology?
>>>
>>> --
>>> Denis
>>>
>>>
>>>
>

[jira] [Created] (IGNITE-8241) Docs: Triggering automatic rebalancing if the whole baseline topology is not recovered

[Denis Magda (JIRA)]

Denis Magda created IGNITE-8241:
---

 Summary: Docs: Triggering automatic rebalancing if the whole 
baseline topology is not recovered
 Key: IGNITE-8241
 URL: https://issues.apache.org/jira/browse/IGNITE-8241
 Project: Ignite
  Issue Type: Task
  Components: documentation
Affects Versions: 2.4
Reporter: Denis Magda
Assignee: Denis Magda
 Fix For: 2.5


The ticket is created as a result of the following discussion:
http://apache-ignite-developers.2346864.n4.nabble.com/Triggering-rebalancing-on-timeout-or-manually-if-the-baseline-topology-is-not-reassembled-td29299.html

The rebalancing doesn't happen if one of the nodes goes down, 
thus, shrinking the baseline topology. It complies with our assumption that 
the node should be recovered soon and there is no need to waste 
CPU/memory/networking resources of the cluster shifting the data around. 

However, there are always edge cases. I was reasonably asked how to trigger 
the rebalancing within the baseline topology manually or on timeout if: 
* It's not expected that the failed node would be resurrected in the 
   nearest time and 
* It's not likely that that node will be replaced by the other one. 

Until we embedd special facilities in the baseline topology that would consider 
such situations we can document the following workaround. A user 
application/tool/script has to subscribe to node_left events and remove the 
failed node from the baseline topology in some time. Once the node is removed, 
the baseline topology will be changed, and the rebalancing will be kicked off.

 



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

Re: Apache Ignite RPM packaging (Stage II)

[Denis Magda]

Petr,

I wouldn't postpone this until 2.6 that will be out nor earlier than 3
months from now.

*Anton V.*, could review and sign off the changes? Not sure we have a
better person in the community who can do that.

--
Denis

On Thu, Apr 12, 2018 at 9:10 AM, Petr Ivanov  wrote:

> If someone from PMCы or Committers still sees necessity about including
> these tasks into Apache Ignite 2.5 release, this is the last chance to do
> so.
> Otherwise this task will be moved to at 2.6 release at least, or even
> moved to backlog indefinitely.
>
>
>
> > On 9 Apr 2018, at 19:08, Petr Ivanov  wrote:
> >
> > To top new RPM architecture off, update to release process is introduced
> — [1] [2].
> >
> > Both tasks (this one and IGNITE-7647) are ready for review and should be
> merged simultaneously.
> >
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-8172
> > [2] https://github.com/apache/ignite-release/pull/1
> >
> >
> >
> >
> >> On 2 Apr 2018, at 18:22, Ilya Kasnacheev 
> wrote:
> >>
> >> Hello!
> >>
> >> Let me share my idea of how this shoud work. Splitting package into
> >> sub-packages should be dependency-driven.
> >>
> >> It means that all Ignite modules without dependencies or with small
> >> dependencies (such as ignite-log4j) should be included in ignite-core.
> It
> >> doesn't make sense to make a zillion RPM packages.
> >>
> >> Critical things like ignite-spring and ignite-indexing should be in
> >> ignite-core of course, even if they have dependencies. Ignite-core
> should
> >> be fully self-sufficient and feature-complete.
> >>
> >> However, e.g. .net API should probably be in a separate package,
> because it
> >> should depend on mono | net-core. We may also have ignite-devel package
> >> which should include all modules which only make sense for developers
> who
> >> write code. Such as hibernate integration.
> >>
> >> I'm not sure about MR modules. The main question should be, does it have
> >> dependencies? Can it run stand-alone without writing code?
> >>
> >> Hope this helps,
> >>
> >> --
> >> Ilya Kasnacheev
> >>
> >> 2018-03-27 15:10 GMT+03:00 Petr Ivanov :
> >>
> >>> Hi, Igniters!
> >>>
> >>>
> >>> Here are some news on our RPM packages initiative.
> >>>
> >>> 1. I’ve finished preliminary developing of Stage II version of RPM
> >>> packages [1]. Main “new feature” is — split design. Also I’ve added
> >>> package.sh script for automating package building process which will
> help
> >>> organise corresponding builds in TC as well as simplify process for
> >>> developers who wishes to have custom packages.
> >>> PR#3703 [2] is ready for review. Denis, in order to catch up with
> Apache
> >>> Ignite 2.5 release, I’d greatly appreciate your help in finding
> reviewer.
> >>> 2. With the help of ASF INFRA team, we now have RPM [3] and DEB [4]
> >>> repositories on Apache Bintray. Though they are already prepared for
> >>> hosting RPM and DEB packages respectively, and there is a way of
> linking
> >>> them to apache.org/dist/ignite page, there is possible alternative in
> >>> storing there only plain directory layout corresponding to each
> repository
> >>> type (RPM and DEB) and manage this layout (repodata, distributions,
> >>> versions, etc.) by ourselves, having more control over repositories but
> >>> lacking some simplicity of deploying new releases. WDYT? Should we try
> >>> Cassandra approach? They are storing their DEB packages as I described
> >>> above [5].
> >>>
> >>> Also — a question arose while I was working on this issue: which OSes
> (and
> >>> which versions of each) are we going to support (if we are going) in
> terms
> >>> of step-by-step list? Currently RPM packages are tested only with
> latest
> >>> CentOS (and, respectively — RHEL), but there are a lot more RPM-based
> >>> distributives [6] some of which are more o less popular among OS
> community
> >>> (ALT, Fedora, openSUSE, etc.).
> >>>
> >>>
> >>> [1] https://issues.apache.org/jira/browse/IGNITE-7647
> >>> [2] https://github.com/apache/ignite/pull/3703
> >>> [3] https://bintray.com/apache/ignite-rpm
> >>> [4] https://bintray.com/apache/ignite-deb
> >>> [5] https://bintray.com/apache/cassandra/debian#files/
> >>> [6] https://en.wikipedia.org/wiki/Category:RPM-based_Linux_
> distributions
> >>>
> >>>
> >>>
> >>>
>  On 15 Mar 2018, at 22:15, Petr Ivanov  wrote:
> 
>  I suppose that most everything if not all from libs/options will go to
> >>> OPTIONAL (I’d call it simply ‘apache-ignite-libs').
>  More precise lib selection (if something from optional would better to
> >>> have in core package) will be discussed right after preliminary split
> >>> architecture agreement.
> 
> 
> 
> > On 15 Mar 2018, at 22:11, Dmitry Pavlov 
> wrote:
> >
> > I like idea of keeping simple system of modules, so +1 from me.
> >
> > Where optional libs (e.g Direct 

Re: Reconsider default WAL mode: we need something between LOG_ONLY and FSYNC

[Denis Magda]

Ivan,

Could we run Yardstick or YCSB benchmarks to see how the fixed LOG_ONLY
affected the performance under the operational load (after the preloading
part you're referring to is over)?

--
Denis

On Thu, Apr 12, 2018 at 9:45 AM, Ivan Rakov  wrote:

> Dmitriy,
>
> fsync() is really slow operation - it's the main reason why FSYNC mode is
> way slower than LOG_ONLY.
> Fix includes extra fsyncs in necessary parts of code and nothing more.
> Every part is important - at the beginning of the thread I described why.
>
> 20% slow in benchmark doesn't mean than Ignite itself will become 20%
> slower. Benchmark replays only "data loading" scenario. It signals that
> maximum throughput with WAL enabled will be 20% slower. By the way, we
> already have option to disable WAL in runtime for the period of data
> loading.
>
> Best Regards,
> Ivan Rakov
>
>
> On 11.04.2018 9:59, Dmitriy Setrakyan wrote:
>
>> On Tue, Apr 10, 2018 at 11:57 PM, Ilya Suntsov 
>> wrote:
>>
>> Dmitriy,
>>>
>>> I've measured performance on the current master and haven't found any
>>> problems with in-memory mode.
>>>
>>> Got it. I would still say that the performance drop is too big with
>> persistence turned on. It seems like we did not just fix the bug, we also
>> introduced some additional slow down there. I would investigate if we
>> could
>> optimize.
>>
>>
>

Re: Memory usage per cache

[Denis Magda]

Alex, Dmitriy,

Please clarify/consider the following:

   - Can we get the size of a particular secondary index with a method like
   getIndexSize(indexName)? Vladimir Ozerov
   ,
   it should be feasible, right?
   - The new DataRegionMXBean metrics list is not the same as of
   DataRegionMetricsMXBean interface. Why is so that and what's the
   difference between such similar interfaces?
   - I wouldn't do this - *Depricate
   CacheMetrics.getRebalancingPartitionsCount(); and move to
   CacheGroupMetricsMXBean.getRebalancingPartitionsCount()*. If we redesign
   the way we store our data within data pages in the future, then
   CacheMetrics.getRebalancingPartitionsCount() would make sense.


--
Denis

On Thu, Apr 12, 2018 at 8:46 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Sounds good to me.
>
> Folks, any other feedback on metrics API in IGNITE-8078?
>
> 2018-04-06 21:36 GMT+03:00 Denis Magda :
>
> > Alex,
> >
> > Why not return cache group metrics from this method by default and
> properly
> > > document it?
> >
> >
> > What do you think about Dmitry's suggestion? It sounds reasonable to me.
> >
> > --
> > Denis
> >
> > On Wed, Apr 4, 2018 at 12:22 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > On Wed, Apr 4, 2018 at 5:27 AM, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com
> > > > wrote:
> > >
> > > > Denis,
> > > >
> > > > I think this particular metric should be deprecated. The most we can
> do
> > > > about it is to return the actual allocated size when a cache is the
> > only
> > > > cache in a group and return -1 if there are multiple caches in a
> group.
> > > > However, this does not look like a consistent approach to me, so I
> > would
> > > > prefer to always return -1 and suggest that users use corresponding
> > cache
> > > > group metrics.
> > > >
> > >
> > > Why not return cache group metrics from this method by default and
> > properly
> > > document it?
> > >
> >
>

[GitHub] ignite pull request #3812: IGNITE-8240 .NET: Use default scheduler when star...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-8240 .NET: Use default scheduler when starting Tasks



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

$ git pull https://github.com/ptupitsyn/ignite ignite-8240

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

https://github.com/apache/ignite/pull/3812.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 #3812


commit 7746efcebe2bbda3fcb1bcaf4b3015489221532b
Author: Pavel Tupitsyn 
Date:   2018-04-12T21:31:10Z

IGNITE-8240 .NET: Use default scheduler when starting Tasks

commit e411695b65cbe0b9fca129927cd9a5b238b2c753
Author: Pavel Tupitsyn 
Date:   2018-04-12T21:39:31Z

cleanup

commit 35d1f543d8f3c1177d9400d02d2d5999589bf481
Author: Pavel Tupitsyn 
Date:   2018-04-12T21:41:37Z

Fix gitignore

commit 8b3472954affc107bdbb97eb48e2434a3677a16b
Author: Pavel Tupitsyn 
Date:   2018-04-12T21:44:32Z

ContinueWith fixed

commit b979841ab43b724d2efa26f6877e2bd1c111b9d0
Author: Pavel Tupitsyn 
Date:   2018-04-12T21:49:01Z

fixing StartNew

commit 3f2a3561c15772334ae7bc93514b47cc0c705526
Author: Pavel Tupitsyn 
Date:   2018-04-12T21:51:42Z

fixing StartNew

commit 04dd8f6ba285214a1d6d935e9bd8d609f01d1e17
Author: Pavel Tupitsyn 
Date:   2018-04-12T22:03:54Z

StartNew fixed




---

Re: Node.js client update: rev. 2

[Denis Magda]

Hello Pavel,

Thanks for the update. Haven't heard from you guys for a while but seems
you were too busy polishing the client. Looks great!

Please consider several questions/notes:

   - Do we really want to migrate QueryEntity API [1] to Node.JS client? I
   heard we planned to deprecate it in the future. *Vladimir*, please share
   your thoughts.
   - I wouldn't mix key-value and SQL examples together because they
   represent different use cases of Ignite. For the sake of simplicity, I
   would create a single SqlExample file that uses DDL to configure
   tables/cache, inserts data with INSERTS and SELECTs it back (simple queries
   and queries with JOINs). We can base it on the database and queries used
   here [2]. Happy to brainstorm on this with you separately.
   -


[1]
https://github.com/nobitlost/ignite/blob/master/modules/clients/nodejs/examples/SqlQueryExample.js#L68
[2] https://apacheignite-sql.readme.io/docs/getting-started

--
Denis

On Wed, Apr 11, 2018 at 6:45 PM, Pavel Petroshenko 
wrote:

> Igniters,
>
> Just to give you an update on the next iteration of the Ignite Node.js thin
> client implementation.
>
> The second iteration is available for review/testing.
>
> The changes are available in the pull request [1] or directly from our
> repository [2].
>
> The short README file [3] covers:
>
> - the list of supported features
> - simple instructions:
>   * how to install the client
>   * how to run the examples
>   * how to run the tests
>
> And we actually encourage you to give it a look or even a try.
>
> The APIs are available both: in sources [4] and in a form of a generated
> specification, produced automatically from the jsdoc comments [5]
>
> Please let us know if you have any questions.
>
> Thanks!
>
> P.
>
> [1] https://github.com/apache/ignite/pull/3680
> [2] https://github.com/nobitlost/ignite/tree/master/modules/clients/nodejs
> [3] https://github.com/nobitlost/ignite/blob/master/
> modules/clients/nodejs/README.md
> [4] https://github.com/nobitlost/ignite/blob/master/
> modules/clients/nodejs/lib
> [5] https://rawgit.com/nobitlost/ignite/master/modules/clients/nodejs/api_
> spec/index.html
>

Re: Triggering rebalancing on timeout or manually if the baseline topology is not reassembled

[Ivan Rakov]

Guys,

I also heard complaints about absence of option to automatically change 
baseline topology. They absolutely make sense.
What Pavel suggested will work as a workaround. I think, in future 
releases we should give user an option to enable a similar behavior via 
Ignite Configuration.
It may be called "Baseline Topology change policy". I see it as 
rule-based language, which allows to specify conditions of BLT change 
using several parameters - timeout and minimum allowed number of 
partition copies left (maybe this option should be provided also on 
per-cache-group level). Policy can also specify conditions for including 
new nodes in BLT if they are present - including node attributes filters 
and so on.


What do you think?

Best Regards,
Ivan Rakov

On 12.04.2018 19:41, Pavel Kovalenko wrote:

Denis,

It's just one of the ways to implement it. We also can subscribe on node
join / fail events to properly track downtime of a node.

2018-04-12 19:38 GMT+03:00 Pavel Kovalenko :


Denis,

Using our API we can implement this task as follows:
Do each minute:
1) Get all alive server nodes consistent ids =>
ignite().context().discovery().aliveServerNodes() => mapToConsistentIds().
2) Get current baseline topology => ignite().cluster().
currentBaselineTopology()
3) For each node in baseline and not in alive server nodes check timeout
for this node.
4) If timeout is reached remove node from baseline
5) If baseline is changed set new baseline => ignite().cluster().
setNewBaseline()


2018-04-12 2:18 GMT+03:00 Denis Magda :


Pavel, Val,

So, it means that the rebalancing will be initiated only after an
administrator remove the failed node from the topology, right?

Next, imagine that you are that IT administrator who has to automate the
rebalancing activation if the node failed and not recovered within 1
minute. What would you do and what Ignite provides to fulfill the task?

--
Denis

On Wed, Apr 11, 2018 at 1:01 PM, Pavel Kovalenko 
wrote:


Denis,

In case of incomplete baseline topology IgniteCache.rebalance() will do
nothing, because this event doesn't trigger partitions exchange or

affinity

change, so states of existing partitions are hold.

2018-04-11 22:27 GMT+03:00 Valentin Kulichenko <
valentin.kuliche...@gmail.com>:


Denis,

In my understanding, in this case you should remove node from BLT and

that

will trigger the rebalancing, no?

-Val

On Wed, Apr 11, 2018 at 12:23 PM, Denis Magda 

wrote:

Igniters,

As we know the rebalancing doesn't happen if one of the nodes goes

down,

thus, shrinking the baseline topology. It complies with our

assumption

that

the node should be recovered soon and there is no need to waste
CPU/memory/networking resources of the cluster shifting the data

around.

However, there are always edge cases. I was reasonably asked how to

trigger

the rebalancing within the baseline topology manually or on timeout

if:

- It's not expected that the failed node would be resurrected in

the

nearest time and
- It's not likely that that node will be replaced by the other

one.

The question. If I call IgniteCache.rebalance() or configure
CacheConfiguration.rebalanceTimeout will the rebalancing be fired

within

the baseline topology?

--
Denis

[jira] [Created] (IGNITE-8240) .NET: Use default scheduler when starting Tasks

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-8240:
--

 Summary: .NET: Use default scheduler when starting Tasks
 Key: IGNITE-8240
 URL: https://issues.apache.org/jira/browse/IGNITE-8240
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.5


Default scheduler should be specified explicitly when starting new tasks to 
avoid deadlocks: 
http://blog.stephencleary.com/2013/10/continuewith-is-dangerous-too.html

This applies to {{StartNew}}, {{ConyinueWith}}, etc.



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

[jira] [Created] (IGNITE-8239) SQL TX: Do not use skipReducer flag for MVCC DML requests

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-8239:


 Summary: SQL TX: Do not use skipReducer flag for MVCC DML requests
 Key: IGNITE-8239
 URL: https://issues.apache.org/jira/browse/IGNITE-8239
 Project: Ignite
  Issue Type: Task
Reporter: Igor Seliverstov


Currently we explicitly set skipReducer flag to true to get UpdatePlan with 
DmlDistributedPlanInfo. We should check if mvcc is enabled instead.



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

[GitHub] ignite pull request #3675: IGNITE-7983: NPE fix.

[andrey-kuznetsov]

Github user andrey-kuznetsov closed the pull request at:

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


---

Re: Apache Ignite 2.5 release

[Andrey Gura]

Anton,

all is under control.

Branches will be compared and changes that should be included to AI
2.5 will be identified.

On Thu, Apr 12, 2018 at 6:19 PM, Petr Ivanov  wrote:
> Possibly it is Andrey Gura — he initiated this thread and created 
> corresponding branch.
>
>
>> On 12 Apr 2018, at 17:39, Anton Vinogradov  wrote:
>>
>> Release manager is responsible for this change.
>> Do we have release manager for 2.5?
>>
>> 2018-04-12 17:35 GMT+03:00 Dmitry Pavlov :
>>
>>> I've changed my ticket version assignment, and a lot of Igniters changed.
>>>
>>> Filter for double-check tickets related to you
>>> *https://issues.apache.org/jira/issues/?jql=project%
>>> 3DIGNITE%20AND%20fixVersion%3D2.5%20and%20resolution%20is%
>>> 20EMPTY%20%20and%20(assignee%3DcurrentUser()%20or%
>>> 20reporter%3DcurrentUser())
>>> >> 3DIGNITE%20AND%20fixVersion%3D2.5%20and%20resolution%20is%
>>> 20EMPTY%20%20and%20(assignee%3DcurrentUser()%20or%
>>> 20reporter%3DcurrentUser())>*
>>>
>>>
>>> чт, 12 апр. 2018 г. в 17:24, Anton Vinogradov :
>>>
 Folks,
 I see a lot of issues resolved as 2.5 but not merged to ignite-2.5
>>> branch.

 Who is in charge of release 2.5, why (first time in history) nobody
>>> changes
 all 2.5 to 2.6?

 2018-04-06 10:19 GMT+03:00 Petr Ivanov :

> Added corresponding triggers for ignite-2.5 in Ignite Tests 2.4+
>>> project
> in TC.
>
>
>
>> On 5 Apr 2018, at 21:55, Denis Magda  wrote:
>>
>> Thanks Andrey!
>>
>> Folks, if you'd like to add anything to 2.5 please make sure it gets
> merged
>> into 2.5 branch.
>>
>> --
>> Denis
>>
>> On Thu, Apr 5, 2018 at 11:29 AM, Andrey Gura 
>>> wrote:
>>
>>> Hi,
>>>
>>> I've created branch ignite-2.5 for Apache Ignite 2.5 release.
>>>
>>> As always please follow the rules below when merging new commits to
> master:
>>>
>>> 1) If ticket is targeted for 2.5 release, please merge to master,
>>> then
>>> cherry-pick to ignite-2.5
>>> 2) Otherwise just merge to master.
>>>
>>>
>>>
>>> On Wed, Apr 4, 2018 at 9:11 PM, Andrey Gura 
>>> wrote:
 Igniters,

 It's time to create branch for upcoming Apache Ignite 2.5 release
>>> in
 order to start stabilization process.

 If there are no any objections I'll create ignite-2.5 branch
 tomorrow.

 Also please check JIRA issues assigned to you and move it to the
>>> next
 version if this issues shouldn't be included to 2.5 release.

 Release page on wiki [1] contains all issues targeted to 2.5 (fix
 version field).

 [1] https://cwiki.apache.org/confluence/display/IGNITE/
> Apache+Ignite+2.5
>>>
>
>

>>>
>

[GitHub] ignite pull request #3742: IGNITE-8110

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3727: Improve OS config suggestions

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Apache Ignite RPM packaging (Stage II)

[Ilya Kasnacheev]

Hello! I have tried your RPM scripts.

First of all, I'm not sure that apache-ignite-core is a good name for
package which contains the actual server node kit, and that apache-ignite
is a good name for a package that will install everything (including cpp
bindings). How does other packages solve this naming? I would go with
apache-ignite and apache-ignite-full.

Moreover I did not find a way to start service if default installed JVM is
Java 7 :( I understand it's EOL, still this is something that hit me.

apache-ignite-docs only contains scaladoc for scalar. Who would need a
separate package for that? Why no javadocs? Maybe it's my build problem?

apache-ignite-libs is a totally unexpected package name. apache-ignite core
doesn't depend on it. It doesn't enable anything out of the box. The
package is huge.

Frankly speaking, I'm not sure that improvements over Stage I are enough as
of now. For demo-like activity, we can probably go with one package fits
all.


-- 
Ilya Kasnacheev

2018-04-12 19:10 GMT+03:00 Petr Ivanov :

> If someone from PMCы or Committers still sees necessity about including
> these tasks into Apache Ignite 2.5 release, this is the last chance to do
> so.
> Otherwise this task will be moved to at 2.6 release at least, or even
> moved to backlog indefinitely.
>
>
>
> > On 9 Apr 2018, at 19:08, Petr Ivanov  wrote:
> >
> > To top new RPM architecture off, update to release process is introduced
> — [1] [2].
> >
> > Both tasks (this one and IGNITE-7647) are ready for review and should be
> merged simultaneously.
> >
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-8172
> > [2] https://github.com/apache/ignite-release/pull/1
> >
> >
> >
> >
> >> On 2 Apr 2018, at 18:22, Ilya Kasnacheev 
> wrote:
> >>
> >> Hello!
> >>
> >> Let me share my idea of how this shoud work. Splitting package into
> >> sub-packages should be dependency-driven.
> >>
> >> It means that all Ignite modules without dependencies or with small
> >> dependencies (such as ignite-log4j) should be included in ignite-core.
> It
> >> doesn't make sense to make a zillion RPM packages.
> >>
> >> Critical things like ignite-spring and ignite-indexing should be in
> >> ignite-core of course, even if they have dependencies. Ignite-core
> should
> >> be fully self-sufficient and feature-complete.
> >>
> >> However, e.g. .net API should probably be in a separate package,
> because it
> >> should depend on mono | net-core. We may also have ignite-devel package
> >> which should include all modules which only make sense for developers
> who
> >> write code. Such as hibernate integration.
> >>
> >> I'm not sure about MR modules. The main question should be, does it have
> >> dependencies? Can it run stand-alone without writing code?
> >>
> >> Hope this helps,
> >>
> >> --
> >> Ilya Kasnacheev
> >>
> >> 2018-03-27 15:10 GMT+03:00 Petr Ivanov :
> >>
> >>> Hi, Igniters!
> >>>
> >>>
> >>> Here are some news on our RPM packages initiative.
> >>>
> >>> 1. I’ve finished preliminary developing of Stage II version of RPM
> >>> packages [1]. Main “new feature” is — split design. Also I’ve added
> >>> package.sh script for automating package building process which will
> help
> >>> organise corresponding builds in TC as well as simplify process for
> >>> developers who wishes to have custom packages.
> >>> PR#3703 [2] is ready for review. Denis, in order to catch up with
> Apache
> >>> Ignite 2.5 release, I’d greatly appreciate your help in finding
> reviewer.
> >>> 2. With the help of ASF INFRA team, we now have RPM [3] and DEB [4]
> >>> repositories on Apache Bintray. Though they are already prepared for
> >>> hosting RPM and DEB packages respectively, and there is a way of
> linking
> >>> them to apache.org/dist/ignite page, there is possible alternative in
> >>> storing there only plain directory layout corresponding to each
> repository
> >>> type (RPM and DEB) and manage this layout (repodata, distributions,
> >>> versions, etc.) by ourselves, having more control over repositories but
> >>> lacking some simplicity of deploying new releases. WDYT? Should we try
> >>> Cassandra approach? They are storing their DEB packages as I described
> >>> above [5].
> >>>
> >>> Also — a question arose while I was working on this issue: which OSes
> (and
> >>> which versions of each) are we going to support (if we are going) in
> terms
> >>> of step-by-step list? Currently RPM packages are tested only with
> latest
> >>> CentOS (and, respectively — RHEL), but there are a lot more RPM-based
> >>> distributives [6] some of which are more o less popular among OS
> community
> >>> (ALT, Fedora, openSUSE, etc.).
> >>>
> >>>
> >>> [1] https://issues.apache.org/jira/browse/IGNITE-7647
> >>> [2] https://github.com/apache/ignite/pull/3703
> >>> [3] https://bintray.com/apache/ignite-rpm
> >>> [4] https://bintray.com/apache/ignite-deb
> >>> [5] 

Re: Reconsider default WAL mode: we need something between LOG_ONLY and FSYNC

[Ivan Rakov]

Dmitriy,

fsync() is really slow operation - it's the main reason why FSYNC mode 
is way slower than LOG_ONLY.
Fix includes extra fsyncs in necessary parts of code and nothing more. 
Every part is important - at the beginning of the thread I described why.


20% slow in benchmark doesn't mean than Ignite itself will become 20% 
slower. Benchmark replays only "data loading" scenario. It signals that 
maximum throughput with WAL enabled will be 20% slower. By the way, we 
already have option to disable WAL in runtime for the period of data 
loading.


Best Regards,
Ivan Rakov

On 11.04.2018 9:59, Dmitriy Setrakyan wrote:

On Tue, Apr 10, 2018 at 11:57 PM, Ilya Suntsov 
wrote:


Dmitriy,

I've measured performance on the current master and haven't found any
problems with in-memory mode.


Got it. I would still say that the performance drop is too big with
persistence turned on. It seems like we did not just fix the bug, we also
introduced some additional slow down there. I would investigate if we could
optimize.

Re: Triggering rebalancing on timeout or manually if the baseline topology is not reassembled

[Pavel Kovalenko]

Denis,

It's just one of the ways to implement it. We also can subscribe on node
join / fail events to properly track downtime of a node.

2018-04-12 19:38 GMT+03:00 Pavel Kovalenko :

> Denis,
>
> Using our API we can implement this task as follows:
> Do each minute:
> 1) Get all alive server nodes consistent ids =>
> ignite().context().discovery().aliveServerNodes() => mapToConsistentIds().
> 2) Get current baseline topology => ignite().cluster().
> currentBaselineTopology()
> 3) For each node in baseline and not in alive server nodes check timeout
> for this node.
> 4) If timeout is reached remove node from baseline
> 5) If baseline is changed set new baseline => ignite().cluster().
> setNewBaseline()
>
>
> 2018-04-12 2:18 GMT+03:00 Denis Magda :
>
>> Pavel, Val,
>>
>> So, it means that the rebalancing will be initiated only after an
>> administrator remove the failed node from the topology, right?
>>
>> Next, imagine that you are that IT administrator who has to automate the
>> rebalancing activation if the node failed and not recovered within 1
>> minute. What would you do and what Ignite provides to fulfill the task?
>>
>> --
>> Denis
>>
>> On Wed, Apr 11, 2018 at 1:01 PM, Pavel Kovalenko 
>> wrote:
>>
>> > Denis,
>> >
>> > In case of incomplete baseline topology IgniteCache.rebalance() will do
>> > nothing, because this event doesn't trigger partitions exchange or
>> affinity
>> > change, so states of existing partitions are hold.
>> >
>> > 2018-04-11 22:27 GMT+03:00 Valentin Kulichenko <
>> > valentin.kuliche...@gmail.com>:
>> >
>> > > Denis,
>> > >
>> > > In my understanding, in this case you should remove node from BLT and
>> > that
>> > > will trigger the rebalancing, no?
>> > >
>> > > -Val
>> > >
>> > > On Wed, Apr 11, 2018 at 12:23 PM, Denis Magda 
>> > wrote:
>> > >
>> > > > Igniters,
>> > > >
>> > > > As we know the rebalancing doesn't happen if one of the nodes goes
>> > down,
>> > > > thus, shrinking the baseline topology. It complies with our
>> assumption
>> > > that
>> > > > the node should be recovered soon and there is no need to waste
>> > > > CPU/memory/networking resources of the cluster shifting the data
>> > around.
>> > > >
>> > > > However, there are always edge cases. I was reasonably asked how to
>> > > trigger
>> > > > the rebalancing within the baseline topology manually or on timeout
>> if:
>> > > >
>> > > >- It's not expected that the failed node would be resurrected in
>> the
>> > > >nearest time and
>> > > >- It's not likely that that node will be replaced by the other
>> one.
>> > > >
>> > > > The question. If I call IgniteCache.rebalance() or configure
>> > > > CacheConfiguration.rebalanceTimeout will the rebalancing be fired
>> > within
>> > > > the baseline topology?
>> > > >
>> > > > --
>> > > > Denis
>> > > >
>> > >
>> >
>>
>
>

Re: Triggering rebalancing on timeout or manually if the baseline topology is not reassembled

[Pavel Kovalenko]

Denis,

Using our API we can implement this task as follows:
Do each minute:
1) Get all alive server nodes consistent ids =>
ignite().context().discovery().aliveServerNodes() => mapToConsistentIds().
2) Get current baseline topology =>
ignite().cluster().currentBaselineTopology()
3) For each node in baseline and not in alive server nodes check timeout
for this node.
4) If timeout is reached remove node from baseline
5) If baseline is changed set new baseline =>
ignite().cluster().setNewBaseline()


2018-04-12 2:18 GMT+03:00 Denis Magda :

> Pavel, Val,
>
> So, it means that the rebalancing will be initiated only after an
> administrator remove the failed node from the topology, right?
>
> Next, imagine that you are that IT administrator who has to automate the
> rebalancing activation if the node failed and not recovered within 1
> minute. What would you do and what Ignite provides to fulfill the task?
>
> --
> Denis
>
> On Wed, Apr 11, 2018 at 1:01 PM, Pavel Kovalenko 
> wrote:
>
> > Denis,
> >
> > In case of incomplete baseline topology IgniteCache.rebalance() will do
> > nothing, because this event doesn't trigger partitions exchange or
> affinity
> > change, so states of existing partitions are hold.
> >
> > 2018-04-11 22:27 GMT+03:00 Valentin Kulichenko <
> > valentin.kuliche...@gmail.com>:
> >
> > > Denis,
> > >
> > > In my understanding, in this case you should remove node from BLT and
> > that
> > > will trigger the rebalancing, no?
> > >
> > > -Val
> > >
> > > On Wed, Apr 11, 2018 at 12:23 PM, Denis Magda 
> > wrote:
> > >
> > > > Igniters,
> > > >
> > > > As we know the rebalancing doesn't happen if one of the nodes goes
> > down,
> > > > thus, shrinking the baseline topology. It complies with our
> assumption
> > > that
> > > > the node should be recovered soon and there is no need to waste
> > > > CPU/memory/networking resources of the cluster shifting the data
> > around.
> > > >
> > > > However, there are always edge cases. I was reasonably asked how to
> > > trigger
> > > > the rebalancing within the baseline topology manually or on timeout
> if:
> > > >
> > > >- It's not expected that the failed node would be resurrected in
> the
> > > >nearest time and
> > > >- It's not likely that that node will be replaced by the other
> one.
> > > >
> > > > The question. If I call IgniteCache.rebalance() or configure
> > > > CacheConfiguration.rebalanceTimeout will the rebalancing be fired
> > within
> > > > the baseline topology?
> > > >
> > > > --
> > > > Denis
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-8238) Operation can fails with unexpected RuntimeException when node is stopping.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-8238:


 Summary: Operation can fails with unexpected RuntimeException when 
node is stopping.
 Key: IGNITE-8238
 URL: https://issues.apache.org/jira/browse/IGNITE-8238
 Project: Ignite
  Issue Type: Bug
  Components: general
Reporter: Andrew Mashenkov


Operation can fails with RuntimeException when node is stoped in other thread. 
PFA stacktrace.



It is not clear from javadoc that operation can throws RuntimeException.
We should add it to javadoc or e.g. throws IllegalStateException which already 
present in java cache api javadoc.



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

Re: Apache Ignite RPM packaging (Stage II)

[Petr Ivanov]

If someone from PMCы or Committers still sees necessity about including these 
tasks into Apache Ignite 2.5 release, this is the last chance to do so.
Otherwise this task will be moved to at 2.6 release at least, or even moved to 
backlog indefinitely.



> On 9 Apr 2018, at 19:08, Petr Ivanov  wrote:
> 
> To top new RPM architecture off, update to release process is introduced — 
> [1] [2].
> 
> Both tasks (this one and IGNITE-7647) are ready for review and should be 
> merged simultaneously.
> 
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-8172
> [2] https://github.com/apache/ignite-release/pull/1
> 
> 
> 
> 
>> On 2 Apr 2018, at 18:22, Ilya Kasnacheev  wrote:
>> 
>> Hello!
>> 
>> Let me share my idea of how this shoud work. Splitting package into
>> sub-packages should be dependency-driven.
>> 
>> It means that all Ignite modules without dependencies or with small
>> dependencies (such as ignite-log4j) should be included in ignite-core. It
>> doesn't make sense to make a zillion RPM packages.
>> 
>> Critical things like ignite-spring and ignite-indexing should be in
>> ignite-core of course, even if they have dependencies. Ignite-core should
>> be fully self-sufficient and feature-complete.
>> 
>> However, e.g. .net API should probably be in a separate package, because it
>> should depend on mono | net-core. We may also have ignite-devel package
>> which should include all modules which only make sense for developers who
>> write code. Such as hibernate integration.
>> 
>> I'm not sure about MR modules. The main question should be, does it have
>> dependencies? Can it run stand-alone without writing code?
>> 
>> Hope this helps,
>> 
>> -- 
>> Ilya Kasnacheev
>> 
>> 2018-03-27 15:10 GMT+03:00 Petr Ivanov :
>> 
>>> Hi, Igniters!
>>> 
>>> 
>>> Here are some news on our RPM packages initiative.
>>> 
>>> 1. I’ve finished preliminary developing of Stage II version of RPM
>>> packages [1]. Main “new feature” is — split design. Also I’ve added
>>> package.sh script for automating package building process which will help
>>> organise corresponding builds in TC as well as simplify process for
>>> developers who wishes to have custom packages.
>>> PR#3703 [2] is ready for review. Denis, in order to catch up with Apache
>>> Ignite 2.5 release, I’d greatly appreciate your help in finding reviewer.
>>> 2. With the help of ASF INFRA team, we now have RPM [3] and DEB [4]
>>> repositories on Apache Bintray. Though they are already prepared for
>>> hosting RPM and DEB packages respectively, and there is a way of linking
>>> them to apache.org/dist/ignite page, there is possible alternative in
>>> storing there only plain directory layout corresponding to each repository
>>> type (RPM and DEB) and manage this layout (repodata, distributions,
>>> versions, etc.) by ourselves, having more control over repositories but
>>> lacking some simplicity of deploying new releases. WDYT? Should we try
>>> Cassandra approach? They are storing their DEB packages as I described
>>> above [5].
>>> 
>>> Also — a question arose while I was working on this issue: which OSes (and
>>> which versions of each) are we going to support (if we are going) in terms
>>> of step-by-step list? Currently RPM packages are tested only with latest
>>> CentOS (and, respectively — RHEL), but there are a lot more RPM-based
>>> distributives [6] some of which are more o less popular among OS community
>>> (ALT, Fedora, openSUSE, etc.).
>>> 
>>> 
>>> [1] https://issues.apache.org/jira/browse/IGNITE-7647
>>> [2] https://github.com/apache/ignite/pull/3703
>>> [3] https://bintray.com/apache/ignite-rpm
>>> [4] https://bintray.com/apache/ignite-deb
>>> [5] https://bintray.com/apache/cassandra/debian#files/
>>> [6] https://en.wikipedia.org/wiki/Category:RPM-based_Linux_distributions
>>> 
>>> 
>>> 
>>> 
 On 15 Mar 2018, at 22:15, Petr Ivanov  wrote:
 
 I suppose that most everything if not all from libs/options will go to
>>> OPTIONAL (I’d call it simply ‘apache-ignite-libs').
 More precise lib selection (if something from optional would better to
>>> have in core package) will be discussed right after preliminary split
>>> architecture agreement.
 
 
 
> On 15 Mar 2018, at 22:11, Dmitry Pavlov  wrote:
> 
> I like idea of keeping simple system of modules, so +1 from me.
> 
> Where optional libs (e.g Direct IO plugin) would be included, would it
>>> be
> core or optional?
> 
> чт, 15 мар. 2018 г. в 22:09, Denis Magda :
> 
>>> 
 
 How big would be a final core module?
>>> Around 30M. Can be shrinked to ~15M if separate Visor and create it’s
>>> own
>>> package.
>> 
>> 
>> Guys, 30 vs 280M is a hge difference.  I would agree with Petr and
>> propose the simplest modular system:
>> 
>> - core module that includes 

[GitHub] ignite pull request #3811: IGNITE-8166 PME hangs when error occurs during ch...

[alex-plekhanov]

GitHub user alex-plekhanov opened a pull request:

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

IGNITE-8166 PME hangs when error occurs during checkpoint



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

$ git pull https://github.com/alex-plekhanov/ignite ignite-8166

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

https://github.com/apache/ignite/pull/3811.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 #3811


commit 38f976609f9039cbd31ff47a87773bcbe7ce8e30
Author: Aleksey Plekhanov 
Date:   2018-04-10T19:19:03Z

IGNITE-8166 PME hangs when error occurs during checkpoint




---

[GitHub] ignite pull request #3658: ignite-7978 don't check tag on restore in GridCac...

[dmekhanikov]

Github user dmekhanikov closed the pull request at:

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


---

[GitHub] ignite pull request #3678: Ignite 2.4.4.b1 build

[dmekhanikov]

Github user dmekhanikov closed the pull request at:

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


---

[GitHub] ignite pull request #3784: ignite-8058 fix flaky GridMarshallerMappingConsis...

[dmekhanikov]

Github user dmekhanikov closed the pull request at:

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


---

Re: Memory usage per cache

[Alexey Goncharuk]

Sounds good to me.

Folks, any other feedback on metrics API in IGNITE-8078?

2018-04-06 21:36 GMT+03:00 Denis Magda :

> Alex,
>
> Why not return cache group metrics from this method by default and properly
> > document it?
>
>
> What do you think about Dmitry's suggestion? It sounds reasonable to me.
>
> --
> Denis
>
> On Wed, Apr 4, 2018 at 12:22 PM, Dmitriy Setrakyan 
> wrote:
>
> > On Wed, Apr 4, 2018 at 5:27 AM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > wrote:
> >
> > > Denis,
> > >
> > > I think this particular metric should be deprecated. The most we can do
> > > about it is to return the actual allocated size when a cache is the
> only
> > > cache in a group and return -1 if there are multiple caches in a group.
> > > However, this does not look like a consistent approach to me, so I
> would
> > > prefer to always return -1 and suggest that users use corresponding
> cache
> > > group metrics.
> > >
> >
> > Why not return cache group metrics from this method by default and
> properly
> > document it?
> >
>

Re: Apache Ignite 2.5 release

[Petr Ivanov]

Possibly it is Andrey Gura — he initiated this thread and created corresponding 
branch.


> On 12 Apr 2018, at 17:39, Anton Vinogradov  wrote:
> 
> Release manager is responsible for this change.
> Do we have release manager for 2.5?
> 
> 2018-04-12 17:35 GMT+03:00 Dmitry Pavlov :
> 
>> I've changed my ticket version assignment, and a lot of Igniters changed.
>> 
>> Filter for double-check tickets related to you
>> *https://issues.apache.org/jira/issues/?jql=project%
>> 3DIGNITE%20AND%20fixVersion%3D2.5%20and%20resolution%20is%
>> 20EMPTY%20%20and%20(assignee%3DcurrentUser()%20or%
>> 20reporter%3DcurrentUser())
>> > 3DIGNITE%20AND%20fixVersion%3D2.5%20and%20resolution%20is%
>> 20EMPTY%20%20and%20(assignee%3DcurrentUser()%20or%
>> 20reporter%3DcurrentUser())>*
>> 
>> 
>> чт, 12 апр. 2018 г. в 17:24, Anton Vinogradov :
>> 
>>> Folks,
>>> I see a lot of issues resolved as 2.5 but not merged to ignite-2.5
>> branch.
>>> 
>>> Who is in charge of release 2.5, why (first time in history) nobody
>> changes
>>> all 2.5 to 2.6?
>>> 
>>> 2018-04-06 10:19 GMT+03:00 Petr Ivanov :
>>> 
 Added corresponding triggers for ignite-2.5 in Ignite Tests 2.4+
>> project
 in TC.
 
 
 
> On 5 Apr 2018, at 21:55, Denis Magda  wrote:
> 
> Thanks Andrey!
> 
> Folks, if you'd like to add anything to 2.5 please make sure it gets
 merged
> into 2.5 branch.
> 
> --
> Denis
> 
> On Thu, Apr 5, 2018 at 11:29 AM, Andrey Gura 
>> wrote:
> 
>> Hi,
>> 
>> I've created branch ignite-2.5 for Apache Ignite 2.5 release.
>> 
>> As always please follow the rules below when merging new commits to
 master:
>> 
>> 1) If ticket is targeted for 2.5 release, please merge to master,
>> then
>> cherry-pick to ignite-2.5
>> 2) Otherwise just merge to master.
>> 
>> 
>> 
>> On Wed, Apr 4, 2018 at 9:11 PM, Andrey Gura 
>> wrote:
>>> Igniters,
>>> 
>>> It's time to create branch for upcoming Apache Ignite 2.5 release
>> in
>>> order to start stabilization process.
>>> 
>>> If there are no any objections I'll create ignite-2.5 branch
>>> tomorrow.
>>> 
>>> Also please check JIRA issues assigned to you and move it to the
>> next
>>> version if this issues shouldn't be included to 2.5 release.
>>> 
>>> Release page on wiki [1] contains all issues targeted to 2.5 (fix
>>> version field).
>>> 
>>> [1] https://cwiki.apache.org/confluence/display/IGNITE/
 Apache+Ignite+2.5
>> 
 
 
>>> 
>> 

Re: Apache Ignite 2.5 release

[Anton Vinogradov]

Release manager is responsible for this change.
Do we have release manager for 2.5?

2018-04-12 17:35 GMT+03:00 Dmitry Pavlov :

> I've changed my ticket version assignment, and a lot of Igniters changed.
>
> Filter for double-check tickets related to you
> *https://issues.apache.org/jira/issues/?jql=project%
> 3DIGNITE%20AND%20fixVersion%3D2.5%20and%20resolution%20is%
> 20EMPTY%20%20and%20(assignee%3DcurrentUser()%20or%
> 20reporter%3DcurrentUser())
>  3DIGNITE%20AND%20fixVersion%3D2.5%20and%20resolution%20is%
> 20EMPTY%20%20and%20(assignee%3DcurrentUser()%20or%
> 20reporter%3DcurrentUser())>*
>
>
> чт, 12 апр. 2018 г. в 17:24, Anton Vinogradov :
>
> > Folks,
> > I see a lot of issues resolved as 2.5 but not merged to ignite-2.5
> branch.
> >
> > Who is in charge of release 2.5, why (first time in history) nobody
> changes
> > all 2.5 to 2.6?
> >
> > 2018-04-06 10:19 GMT+03:00 Petr Ivanov :
> >
> > > Added corresponding triggers for ignite-2.5 in Ignite Tests 2.4+
> project
> > > in TC.
> > >
> > >
> > >
> > > > On 5 Apr 2018, at 21:55, Denis Magda  wrote:
> > > >
> > > > Thanks Andrey!
> > > >
> > > > Folks, if you'd like to add anything to 2.5 please make sure it gets
> > > merged
> > > > into 2.5 branch.
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On Thu, Apr 5, 2018 at 11:29 AM, Andrey Gura 
> wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> I've created branch ignite-2.5 for Apache Ignite 2.5 release.
> > > >>
> > > >> As always please follow the rules below when merging new commits to
> > > master:
> > > >>
> > > >> 1) If ticket is targeted for 2.5 release, please merge to master,
> then
> > > >> cherry-pick to ignite-2.5
> > > >> 2) Otherwise just merge to master.
> > > >>
> > > >>
> > > >>
> > > >> On Wed, Apr 4, 2018 at 9:11 PM, Andrey Gura 
> wrote:
> > > >>> Igniters,
> > > >>>
> > > >>> It's time to create branch for upcoming Apache Ignite 2.5 release
> in
> > > >>> order to start stabilization process.
> > > >>>
> > > >>> If there are no any objections I'll create ignite-2.5 branch
> > tomorrow.
> > > >>>
> > > >>> Also please check JIRA issues assigned to you and move it to the
> next
> > > >>> version if this issues shouldn't be included to 2.5 release.
> > > >>>
> > > >>> Release page on wiki [1] contains all issues targeted to 2.5 (fix
> > > >>> version field).
> > > >>>
> > > >>> [1] https://cwiki.apache.org/confluence/display/IGNITE/
> > > Apache+Ignite+2.5
> > > >>
> > >
> > >
> >
>

Re: Apache Ignite 2.5 release

[Dmitry Pavlov]

I've changed my ticket version assignment, and a lot of Igniters changed.

Filter for double-check tickets related to you
*https://issues.apache.org/jira/issues/?jql=project%3DIGNITE%20AND%20fixVersion%3D2.5%20and%20resolution%20is%20EMPTY%20%20and%20(assignee%3DcurrentUser()%20or%20reporter%3DcurrentUser())
*


чт, 12 апр. 2018 г. в 17:24, Anton Vinogradov :

> Folks,
> I see a lot of issues resolved as 2.5 but not merged to ignite-2.5 branch.
>
> Who is in charge of release 2.5, why (first time in history) nobody changes
> all 2.5 to 2.6?
>
> 2018-04-06 10:19 GMT+03:00 Petr Ivanov :
>
> > Added corresponding triggers for ignite-2.5 in Ignite Tests 2.4+ project
> > in TC.
> >
> >
> >
> > > On 5 Apr 2018, at 21:55, Denis Magda  wrote:
> > >
> > > Thanks Andrey!
> > >
> > > Folks, if you'd like to add anything to 2.5 please make sure it gets
> > merged
> > > into 2.5 branch.
> > >
> > > --
> > > Denis
> > >
> > > On Thu, Apr 5, 2018 at 11:29 AM, Andrey Gura  wrote:
> > >
> > >> Hi,
> > >>
> > >> I've created branch ignite-2.5 for Apache Ignite 2.5 release.
> > >>
> > >> As always please follow the rules below when merging new commits to
> > master:
> > >>
> > >> 1) If ticket is targeted for 2.5 release, please merge to master, then
> > >> cherry-pick to ignite-2.5
> > >> 2) Otherwise just merge to master.
> > >>
> > >>
> > >>
> > >> On Wed, Apr 4, 2018 at 9:11 PM, Andrey Gura  wrote:
> > >>> Igniters,
> > >>>
> > >>> It's time to create branch for upcoming Apache Ignite 2.5 release in
> > >>> order to start stabilization process.
> > >>>
> > >>> If there are no any objections I'll create ignite-2.5 branch
> tomorrow.
> > >>>
> > >>> Also please check JIRA issues assigned to you and move it to the next
> > >>> version if this issues shouldn't be included to 2.5 release.
> > >>>
> > >>> Release page on wiki [1] contains all issues targeted to 2.5 (fix
> > >>> version field).
> > >>>
> > >>> [1] https://cwiki.apache.org/confluence/display/IGNITE/
> > Apache+Ignite+2.5
> > >>
> >
> >
>

[GitHub] ignite pull request #3810: IGNITE-7972: Fixed NPE in TTL manager on unwindEv...

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

IGNITE-7972: Fixed NPE in TTL manager on unwindEvicts.



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

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

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

https://github.com/apache/ignite/pull/3810.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 #3810






---

[GitHub] ignite pull request #3809: IGNTIE-7972: Fixed NPE in TTL manager on unwindEv...

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---

[GitHub] ignite pull request #3809: IGNTIE-7972: Fixed NPE in TTL manager on unwindEv...

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

IGNTIE-7972: Fixed NPE in TTL manager on unwindEvicts.



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

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

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

https://github.com/apache/ignite/pull/3809.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 #3809






---

Re: Apache Ignite 2.5 release

[Anton Vinogradov]

Folks,
I see a lot of issues resolved as 2.5 but not merged to ignite-2.5 branch.

Who is in charge of release 2.5, why (first time in history) nobody changes
all 2.5 to 2.6?

2018-04-06 10:19 GMT+03:00 Petr Ivanov :

> Added corresponding triggers for ignite-2.5 in Ignite Tests 2.4+ project
> in TC.
>
>
>
> > On 5 Apr 2018, at 21:55, Denis Magda  wrote:
> >
> > Thanks Andrey!
> >
> > Folks, if you'd like to add anything to 2.5 please make sure it gets
> merged
> > into 2.5 branch.
> >
> > --
> > Denis
> >
> > On Thu, Apr 5, 2018 at 11:29 AM, Andrey Gura  wrote:
> >
> >> Hi,
> >>
> >> I've created branch ignite-2.5 for Apache Ignite 2.5 release.
> >>
> >> As always please follow the rules below when merging new commits to
> master:
> >>
> >> 1) If ticket is targeted for 2.5 release, please merge to master, then
> >> cherry-pick to ignite-2.5
> >> 2) Otherwise just merge to master.
> >>
> >>
> >>
> >> On Wed, Apr 4, 2018 at 9:11 PM, Andrey Gura  wrote:
> >>> Igniters,
> >>>
> >>> It's time to create branch for upcoming Apache Ignite 2.5 release in
> >>> order to start stabilization process.
> >>>
> >>> If there are no any objections I'll create ignite-2.5 branch tomorrow.
> >>>
> >>> Also please check JIRA issues assigned to you and move it to the next
> >>> version if this issues shouldn't be included to 2.5 release.
> >>>
> >>> Release page on wiki [1] contains all issues targeted to 2.5 (fix
> >>> version field).
> >>>
> >>> [1] https://cwiki.apache.org/confluence/display/IGNITE/
> Apache+Ignite+2.5
> >>
>
>

[GitHub] ignite pull request #3808: ignite-8205 make services be redeployed when clus...

[dmekhanikov]

GitHub user dmekhanikov opened a pull request:

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

ignite-8205 make services be redeployed when cluster is getting activated



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

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

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

https://github.com/apache/ignite/pull/3808.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 #3808


commit ac1e5ae6aec7cd5f8f4463aab4e5425a092024c1
Author: Denis Mekhanikov 
Date:   2018-04-11T13:40:53Z

ignite-8205 add test for service redeployment on activation

commit 42a00d9c1d11f8af88045ac7e83e6140c5565854
Author: Denis Mekhanikov 
Date:   2018-04-12T12:23:29Z

ignite-8205 clear list of local services in 
GridServiceProcessor#onKernalStop

commit 494846ad9de90a337db91c1021bc984917600cf2
Author: Denis Mekhanikov 
Date:   2018-04-12T13:08:40Z

ignite-8205 add header to test

commit 33957b351d9f7f548b60b38bc0d6de76f5a03602
Author: Denis Mekhanikov 
Date:   2018-04-12T13:10:46Z

ignite-8205 add test to suite

commit 4d20a549f2df492de2d92d634e516d382dcce4aa
Author: Denis Mekhanikov 
Date:   2018-04-11T16:02:17Z

add comments for non-obvious parts of GridServiceProcessor




---

[GitHub] ignite pull request #3807: IGNITE-8233 KNN and SVM algorithms don't work whe...

[dmitrievanthony]

GitHub user dmitrievanthony opened a pull request:

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

IGNITE-8233 KNN and SVM algorithms don't work when partition doesn't 
contain data.



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

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

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

https://github.com/apache/ignite/pull/3807.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 #3807


commit 14a7357afc0f33b07f5d4f56d6081222ec5bb437
Author: Anton Dmitriev 
Date:   2018-04-12T13:35:59Z

IGNITE-8233 Add protection of dataset compute method from empty data.

commit c63105c2cd4d4d8829ff300eaa7d11ed6620ebdb
Author: Anton Dmitriev 
Date:   2018-04-12T13:44:55Z

IGNITE-8233 Fix tests after adding protection of dataset compute method
from empty data.




---

[GitHub] ignite pull request #3806: IGNITE-8232 ML package cleanup for 2.5 release.

[dmitrievanthony]

GitHub user dmitrievanthony opened a pull request:

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

IGNITE-8232 ML package cleanup for 2.5 release.



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

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

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

https://github.com/apache/ignite/pull/3806.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 #3806


commit 3ea8e3df0f7b72ea6f58e2a47d1677dd6863d077
Author: Anton Dmitriev 
Date:   2018-04-12T12:30:08Z

IGNITE-8232 Remove all trainers except DatasetTrainer.




---

[jira] [Created] (IGNITE-8237) Ignite blocks on SecurityException in exchange-worker due to unauthorised off-heap cache configuration

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-8237:


 Summary: Ignite blocks on SecurityException in exchange-worker due 
to unauthorised off-heap cache configuration 
 Key: IGNITE-8237
 URL: https://issues.apache.org/jira/browse/IGNITE-8237
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


Ignite blocks on SecurityException in exchange-worker due to unauthorised 
off-heap cache configuration. Consider moving IGNITE_DISABLE_OFFHEAP_CACHE 
system property check to a more appropriate place to avoid blocking Ignite.



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

[jira] [Created] (IGNITE-8236) Sporadic NPE in IgniteAtomicSequenceExample

[Ivan Artukhov (JIRA)]

Ivan Artukhov created IGNITE-8236:
-

 Summary: Sporadic NPE in IgniteAtomicSequenceExample 
 Key: IGNITE-8236
 URL: https://issues.apache.org/jira/browse/IGNITE-8236
 Project: Ignite
  Issue Type: Bug
  Components: data structures
Affects Versions: 1.9
Reporter: Ivan Artukhov
 Attachments: IgniteAtomicSequenceExample.1.zip

Platforms: Linux, Windows
Reproducibility: ~30%

Sometimes the _datastructures.IgniteAtomicSequenceExample_ throws the following 
exception during run:

{code}
[06:26:26,810][SEVERE][utility-#62%null%][GridCacheIoManager] Failed processing 
message [senderId=71fea304-3e08-4706-880a-7b00bebb280f, 
msg=GridNearTxPrepareRequest 
[futId=d889888b261-bc99dff6-1c40-4ab1-90d2-5a1d12832afc, 
miniId=e889888b261-bc99dff6-1c40-4ab1-90d2-5a1d12832afc, near=false, 
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0], last=true, 
lastBackups=null, retVal=false, implicitSingle=false, explicitLock=false, 
subjId=71fea304-3e08-4706-880a-7b00bebb280f, taskNameHash=0, 
firstClientReq=false, super=GridDistributedTxPrepareRequest [threadId=134, 
concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, writeVer=GridCacheVersion 
[topVer=134994380, time=1523514386721, order=1523514383656, nodeOrder=2], 
timeout=0, invalidate=false, reads=[], writes=[IgniteTxEntry 
[key=KeyCacheObjectImpl [val=CacheDataStructuresConfigurationKey [], 
hasValBytes=true], cacheId=-2100569601, partId=-1, txKey=IgniteTxKey 
[key=KeyCacheObjectImpl [val=CacheDataStructuresConfigurationKey [], 
hasValBytes=true], cacheId=-2100569601], val=[op=TRANSFORM, val=null], 
prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
entryProcessorsCol=[IgniteBiTuple [val1=AddAtomicProcessor 
[info=DataStructureInfo [name=example-sequence, type=ATOMIC_SEQ]], 
val2=[Ljava.lang.Object;@1540f725]], ttl=-1, conflictExpireTime=-1, 
conflictVer=null, explicitVer=null, dhtVer=null, filters=[], 
filtersPassed=false, filtersSet=false, entry=GridDhtColocatedCacheEntry 
[super=GridDhtCacheEntry [rdrs=[], locPart=GridDhtLocalPartition 
[rmvQueueMaxSize=128, rmvdEntryTtl=1, id=21, 
map=o.a.i.i.processors.cache.GridCacheConcurrentMapImpl@1ea42fb7, cntr=1, 
shouldBeRenting=false, state=OWNING, reservations=0, empty=false, 
createTime=04/12/2018 06:26:18], super=GridDistributedCacheEntry 
[super=GridCacheMapEntry [key=KeyCacheObjectImpl 
[val=CacheDataStructuresConfigurationKey [], hasValBytes=true], 
val=CacheObjectImpl [val={example-sequence=DataStructureInfo 
[name=example-sequence, type=ATOMIC_SEQ]}, hasValBytes=true], 
startVer=1523514383659, ver=GridCacheVersion [topVer=134994380, 
time=1523514386783, order=1523514383665, nodeOrder=1], hash=-1424345221, 
extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc 
[locs=[GridCacheMvccCandidate [nodeId=15305184-e5a2-4872-a549-d98e0df8b745, 
ver=GridCacheVersion [topVer=134994380, time=1523514386744, 
order=1523514383660, nodeOrder=1], threadId=113, id=6, 
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0], reentry=null, 
otherNodeId=15305184-e5a2-4872-a549-d98e0df8b745, otherVer=GridCacheVersion 
[topVer=134994380, time=1523514386744, order=1523514383660, nodeOrder=1], 
mappedDhtNodes=null, mappedNearNodes=null, ownerVer=GridCacheVersion 
[topVer=134994380, time=1523514386732, order=1523514383657, nodeOrder=1], 
serOrder=null, key=KeyCacheObjectImpl [val=CacheDataStructuresConfigurationKey 
[], hasValBytes=true], 
masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
 prevVer=null, nextVer=GridCacheVersion [topVer=134994380, time=1523514386789, 
order=1523514383667, nodeOrder=1]]], rmts=null]], flags=0, prepared=0, 
locked=false, nodeId=null, locMapped=false, expiryPlc=null, 
transferExpiryPlc=false, flags=0, partUpdateCntr=0, serReadVer=null, 
xidVer=null]], dhtVers={IgniteTxKey [key=KeyCacheObjectImpl 
[val=CacheDataStructuresConfigurationKey [], hasValBytes=true], 
cacheId=-2100569601]=null}, txSize=0, onePhaseCommit=true, sys=true, plc=5, 
txState=IgniteTxStateImpl [activeCacheIds=GridLongList [idx=1, 
arr=[-2100569601]], txMap={IgniteTxKey [key=KeyCacheObjectImpl 
[val=CacheDataStructuresConfigurationKey [], hasValBytes=true], 
cacheId=-2100569601]=IgniteTxEntry [key=KeyCacheObjectImpl 
[val=CacheDataStructuresConfigurationKey [], hasValBytes=true], 
cacheId=-2100569601, partId=21, txKey=IgniteTxKey [key=KeyCacheObjectImpl 
[val=CacheDataStructuresConfigurationKey [], hasValBytes=true], 
cacheId=-2100569601], val=[op=TRANSFORM, val=null], prevVal=[op=NOOP, 
val=null], oldVal=[op=NOOP, val=null], entryProcessorsCol=[IgniteBiTuple 
[val1=AddAtomicProcessor [info=DataStructureInfo [name=example-sequence, 
type=ATOMIC_SEQ]], val2=[Ljava.lang.Object;@1540f725]], ttl=-1, 
conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null, 
filters=[], filtersPassed=false, filtersSet=false, 

[GitHub] ignite pull request #3803: IGNITE-8230

[devozerov]

Github user devozerov closed the pull request at:

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


---

[GitHub] ignite pull request #3804: IGNITE-7871 Fixed condition for cache partitions ...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3801: IGNITE-8135

[devozerov]

Github user devozerov closed the pull request at:

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


---

[GitHub] ignite pull request #3805: Ignite 1.8.19

[aealeksandrov]

GitHub user aealeksandrov opened a pull request:

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

Ignite 1.8.19



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

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

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

https://github.com/apache/ignite/pull/3805.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 #3805


commit f81964f59b0ea5b8dfdc8eb2acc34d2a5b8fee07
Author: sboikov 
Date:   2017-01-10T13:59:17Z

Do not evict removed entries, otherwise removes can be lost.

(cherry picked from commit 55ac6e7)

commit 5dd74ff635de50ff9561ccdb51bdeb620f60c3db
Author: sboikov 
Date:   2017-01-10T13:59:17Z

Do not evict removed entries, otherwise removes can be lost.

(cherry picked from commit 55ac6e7)

commit 5fb5c7e3b54ae4efb7a6a1832ba647677d93e0cd
Author: Evgenii Zhuravlev 
Date:   2017-06-22T06:43:03Z

IGNITE-5399 Manual cache rebalancing feature is broken

commit 01d41b72ecc3e81dfc8966cc0e395c247037241c
Author: Evgenii Zhuravlev 
Date:   2017-06-21T10:48:15Z

GG-12256 H2Indexes are not deleted if key class implements Externalizable

commit 5ac9afc719138e37a7d97d9d9db05243eee9a942
Author: Evgenii Zhuravlev 
Date:   2017-06-22T09:36:14Z

IGNITE-5399 add test to testsuite

commit a935d40a80e2f928a84a145aba540a45b156687f
Author: Evgenii Zhuravlev 
Date:   2017-06-22T12:10:32Z

GG-12256 Minor fixes

commit 7e2468770a4eb47a4f61204d8c2000b6ab67c967
Author: nikolay_tikhonov 
Date:   2017-06-22T13:13:01Z

IGNITE-GG-12197 Fixed "Ignore events for discarded update in CLOCK mode".

Signed-off-by: nikolay_tikhonov 

commit 5858efd406bb54352de14a0a7e7f21c2ac7bf899
Author: sboikov 
Date:   2016-12-16T16:23:29Z

IGNITE-2412 - Do not acquire asyncSemaphore for synchronous operations 
(cherry-picked from master)

(cherry picked from commit 82b4073)

commit 113a1380da34ea804d68757d39926da97dee09b6
Author: Alexey Goncharuk 
Date:   2017-06-13T05:20:22Z

GG-12355: Backported IO latency test.

commit 540ca449f1bd2386d3ba0722afb21dd3a504d044
Author: Alexey Goncharuk 
Date:   2017-06-13T17:55:38Z

GG-12355: Added discovery ring latency test + made it available from MBean 
(cherry-picked from master).

commit 0fc6271d8e39125bf5ee341e50a2665a04fc8b1e
Author: Andrey V. Mashenkov 
Date:   2017-06-21T10:42:12Z

GG-12350: GridDhtAtomicSingleUpdateRequest misses topologyVersion() method 
override.

commit f8224d13cf9a6432ba65e0016370ba51bbb544e9
Author: Alexey Goncharuk 
Date:   2017-06-15T19:49:45Z

GG-12299: Make sure concurrent type registrations do not trigger multiple 
cache updates.

commit 4ffc3acfa1bc43bea8c79bfd1864787c15cfc4de
Author: Alexey Goncharuk 
Date:   2017-06-20T04:59:09Z

IGNITE-5528 - IS_EVICT_DISABLED flag is not cleared on cache store 
exception.

commit 8cd9e829380f4c91cc9bb126169863286d1cb323
Author: Andrey V. Mashenkov 
Date:   2017-06-21T12:40:14Z

GG-12353: Added local binary context flag.

Backport of IGNITE-5223 with fixes.

commit 9036ad239d68eff663bc73a81baab2826b054d9a
Author: Andrey V. Mashenkov 
Date:   2017-06-21T15:25:31Z

Added MBean for system cache executors.

commit ed34a5dc681ea8f284f4d25c5575ad46569cc600
Author: Andrey V. Mashenkov 
Date:   2017-06-21T15:33:55Z

Partial fix of IGNITE-5562.

commit d427021f329292fb69d348ba949ad1f8f1e9089e
Author: Andrey V. Mashenkov 
Date:   2017-06-21T16:30:27Z

IGNITE-5552: ServiceProcessor recalculates all service assignments even if 
there is a pending topology change.

commit f1b9cdc0716a1b23f54d68ce0fe19eb85107567d
Author: Alexey Goncharuk 
Date:   2017-06-14T18:37:54Z

GG-12354: Partial fix of IGNITE-5473: Introduce troubleshooting logger.

commit beb2409cfe2045789443d47de735d879961d371e
Author: Andrey V. Mashenkov 
Date:   2017-06-23T09:26:06Z

GG-12352: Forcible node drop makes cluster instable in some cases.
Disable forcible node drop by default.

commit 802f18fc250cbae8959192c78bb28dc525ed3cf7
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Fix compilation

commit 39d2dec85a3c571dfdb1cd6189b53ae2413a5d22
Author: Andrey V. Mashenkov 
Date:   2017-06-23T10:41:30Z

Merge branch 'ignite-1.7.12-b2' into ignite-1.8.8

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/internal/GridTopic.java
#   

[GitHub] ignite pull request #3804: IGNITE-7871 Fixed condition for cache partitions ...

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-7871 Fixed condition for cache partitions validation.



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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-7871-validation-condition-fix

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

https://github.com/apache/ignite/pull/3804.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 #3804


commit 044ecd2cced4ccbe745cfc53442e35d7f7b5d300
Author: Pavel Kovalenko 
Date:   2018-04-12T11:16:47Z

IGNITE-7871 Fixed condition for cache partitions validation.




---

[jira] [Created] (IGNITE-8235) Implement execution of selected part of SQL query

[Alexander Kalinin (JIRA)]

Alexander Kalinin created IGNITE-8235:
-

 Summary: Implement execution of selected part of SQL query
 Key: IGNITE-8235
 URL: https://issues.apache.org/jira/browse/IGNITE-8235
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Alexander Kalinin
Assignee: Alexander Kalinin


If we had 3 SQL rows in the notebook, and selected one and clicked execute. 
We should only execute the highlighted row. If no row is highlighted, then all 
rows should be executed. That's a standard feature of graphical SQL tools.



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

Some troubles using CacheMode.REPLICATED

[rv]

Hi All!

I have few troubles using Cache in CacheMode.REPLICATED (Ignite 2.4.0).

Problem One:
1. Start Ignite N1 with default storage configuration with persistence
enabled set to true;
2. Create cache C1 with cache mode = CacheMode.REPLICATED;
3. Create cache C2 with cache mode = CacheMode.REPLICATED;
4. Start Ignite N2 (same as N1);
5. Get C1 C2 on N2;
6. Lock L1 on N1 on C1; Successfully read data from C1 on N1; Unlock L1 on
N1;
7. Lock L1 on N2 on C1; Successfully read data from C1 on N2; Unlock L1 on
N2;
8. kill -9 N1;
9. Lock L1 on N2; Get exception on N2: javax.cache.CacheException: Failed to
lock keys (all partition nodes left the grid). at
org.apache.ignite.internal.processors.cache.CacheLockImpl.lock(CacheLockImpl.java:79)
10. Put data into C2 on N2; Get exception on N2:
org.apache.ignite.cache.CacheServerNotFoundException: Failed to map keys to
nodes (partition is not mapped to any node)

Problem Two:
11. Stop N2;
12. Try to start N2; Get exception: Apr 12, 2018 1:34:29 PM
org.apache.ignite.logger.java.JavaLogger error
SEVERE:  Failed to rollback transaction (cache may contain stale locks):
GridNearTxLocal [mappings=IgniteTxMappingsSingleImpl [mapping=null],
nearLocallyMapped=false, colocatedLocallyMapped=false, needCheckBackup=null,
hasRemoteLocks=false, trackTimeout=false, thread=main,
mappings=IgniteTxMappingsSingleImpl [mapping=null],
super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[],
dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter
[completedBase=null, sndTransformedVals=false, depEnabled=false,
txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false],
super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=135009268,
order=1523529267021, nodeOrder=1], writeVer=null, implicit=true, loc=true,
threadId=1, startTime=1523529269496,
nodeId=09ce651b-55bc-4863-a1f7-6bcf0ac75ed1, startVer=GridCacheVersion
[topVer=135009268, order=1523529267021, nodeOrder=1], endVer=null,
isolation=READ_COMMITTED, concurrency=OPTIMISTIC, timeout=0,
sysInvalidate=false, sys=false, plc=2, commitVer=null, finalizing=NONE,
invalidParts=null, state=ROLLED_BACK, timedOut=false,
topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], duration=139ms,
onePhaseCommit=false], size=1]]]
class org.apache.ignite.IgniteCheckedException: Failed to commit
transaction:
GridNearTxLocal[id=d47bb69b261--080c-13f4--0001,
concurrency=OPTIMISTIC, isolation=READ_COMMITTED, state=ROLLED_BACK,
invalidate=false, rollbackOnly=true,
nodeId=09ce651b-55bc-4863-a1f7-6bcf0ac75ed1, duration=139]
13. Succ start N2 only after rm –rf Ignite db or after start N1.

Please, help me to find a mistake and explain how to fix it.

Thanks,
Roman




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

[GitHub] ignite pull request #3788: IGNITE-7824

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3803: IGNITE-8230

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-8230



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

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

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

https://github.com/apache/ignite/pull/3803.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 #3803


commit b30298fcccb7153d7bc66118bd0d1d61de223258
Author: devozerov 
Date:   2018-04-12T09:47:39Z

WIP

commit 2585132d5e5e12c9eb8c3dd0eb9a65616c3a19ec
Author: devozerov 
Date:   2018-04-12T10:14:08Z

Test.




---

[jira] [Created] (IGNITE-8234) Web console: refactor inputs

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-8234:


 Summary: Web console: refactor inputs
 Key: IGNITE-8234
 URL: https://issues.apache.org/jira/browse/IGNITE-8234
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Ilya Borisov
Assignee: Dmitriy Shabalin


Inputs are getting out of hand, we need to do some housekeeping:
1. Converge and simplify SCSS for inputs with both styles of error message 
(text vs icon).
2. Converge and remove duplicate input mixins.



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

[jira] [Created] (IGNITE-8233) KNN and SVM algorithms don't work when partition doesn't contain data

[Anton Dmitriev (JIRA)]

Anton Dmitriev created IGNITE-8233:
--

 Summary: KNN and SVM algorithms don't work when partition doesn't 
contain data
 Key: IGNITE-8233
 URL: https://issues.apache.org/jira/browse/IGNITE-8233
 Project: Ignite
  Issue Type: Bug
  Components: ml
Affects Versions: 2.4
Reporter: Anton Dmitriev
Assignee: Anton Dmitriev
 Fix For: 2.5






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

[jira] [Created] (IGNITE-8232) ML package cleanup for 2.5 release

[Anton Dmitriev (JIRA)]

Anton Dmitriev created IGNITE-8232:
--

 Summary: ML package cleanup for 2.5 release
 Key: IGNITE-8232
 URL: https://issues.apache.org/jira/browse/IGNITE-8232
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Affects Versions: 2.5
Reporter: Anton Dmitriev
Assignee: Anton Dmitriev






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

[GitHub] ignite pull request #3802: IGNITE-8231 Added timeout to waiting WAL segment ...

[akalash]

GitHub user akalash opened a pull request:

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

IGNITE-8231 Added timeout to waiting WAL segment archivation



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

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

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

https://github.com/apache/ignite/pull/3802.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 #3802


commit 489ab797d0f77587bc9af5d3302f168ee5934ed2
Author: Anton Kalashnikov 
Date:   2018-04-12T09:28:05Z

IGNITE-8231 Added timeout to waiting WAL segment archivation




---

[jira] [Created] (IGNITE-8231) Waiting to WAL segment archivation without timeout

[Anton Kalashnikov (JIRA)]

Anton Kalashnikov created IGNITE-8231:
-

 Summary: Waiting to WAL segment archivation without timeout
 Key: IGNITE-8231
 URL: https://issues.apache.org/jira/browse/IGNITE-8231
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov


Waiting to WAL segment archivation without timeout



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

[GitHub] ignite pull request #3801: IGNITE-8135

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-8135



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

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

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

https://github.com/apache/ignite/pull/3801.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 #3801


commit 208803b724303f1ecc0bfa1a0af9020b916709d0
Author: devozerov 
Date:   2018-04-12T08:31:36Z

DROP TABLE tests.




---

[GitHub] ignite pull request #3800: Mmuzaf ignite 7791

[Mmuzaf]

GitHub user Mmuzaf opened a pull request:

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

Mmuzaf ignite 7791



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

$ git pull https://github.com/Mmuzaf/ignite mmuzaf-ignite-7791

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

https://github.com/apache/ignite/pull/3800.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 #3800






---

[GitHub] ignite pull request #3787: IGNITE-8176 Integrate gradient descent linear reg...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3790: IGNITE-8042

[devozerov]

Github user devozerov closed the pull request at:

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


---