Re: Move documentation from readme.io to GitHub pages

[Denis Magda]

Copied from the ticket.

*Feature*

*Docusaurus*

*GitBook*

*Free*

Yes (FaceBook open source project)

Yes (Free version only allows 5 contributors)

*Setup and Installation*

Easy installation and configuration steps.

Initial setup is easy; Need to look around for customization.

*Standard Markdown*

Yes

Yes

*Versioning*

Yes (automatic)

Yes (via github branching)

*Search*

Yes

Yes

*Table of contents for pages*

Yes (out-of-the-box)

No (Default theme does not support it; maybe availble through external
plugin)

*Support child pages*

No

Yes

*Allows website design customization*



Yes

Limited; Use external theme plugins.

*Top Nav bar & Footer*

Yes

No

*Live server(localhost) to view changes*

Yes

Yes

*Tab navigation on pages*

No tab navigation support out-of-the box.

Note: It is possible to create tabs using external React JS plugin or
implementing a React component. For example, React Native uses Docusaurus
and have implemented tabs-
http://facebook.github.io/react-native/docs/getting-started.html



No tab navigation support out-of-the box.

Note: It is possible to create tabs using external GitBook plugins.



*Publishing the website*

Publish the documentation site to Github pages or other static file hosts.



Publish the documentation site to git.gitbook.io (or custom domain) or
other static file hosts.



*Store all markdown files on github*

Yes

Yes

*Editor*

Use text editor. Alternatively, IntelliJ can be used, it has a plugin for
Markdown.

Provides desktop and online editor.

*Active support and development*

Yes. Facebook engineers are pretty responsive!

Hmm.. some people are wondering if they are still alive :-)


Prachi, thanks for the research and summary. I cast my ballot for
Docusaurus. It has much more prominent benefits over

GitBook such as a table of content, more advanced visual customization,
ability to edit from IntelliJ, and support by Facebook

engineers -- probably that's the way for Ignite to get installed at
Facebook in the future.


--
Denis

On Tue, Mar 20, 2018 at 4:38 PM, Prachi Garg  wrote:

> I looked into Docusaurus and GitBook. I liked Docusaurus better because it
> allows publishing to github pages or other static files hosts, and various
> other features. My findings are mentioned in the ticket -
> https://issues.apache.org/jira/browse/IGNITE-7595 .
>
> On Fri, Feb 2, 2018 at 2:42 PM, Denis Magda  wrote:
>
> > Looks promising. Thanks for sharing. Updated the ticket.
> >
> > —
> > Denis
> >
> > > On Feb 2, 2018, at 2:25 PM, Dmitriy Setrakyan 
> > wrote:
> > >
> > > I think docusaurus.io could work for us. Denis, what do you think?
> > >
> > > On Fri, Feb 2, 2018 at 3:10 AM, endianignite 
> > wrote:
> > >
> > >> I noticed that Facebook open-sourced a documentation platform last
> > month,
> > >> https://docusaurus.io/, which may be worth considering.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> > >>
> >
> >
>

[jira] [Created] (IGNITE-8002) Authentication: add to REST support of new authentication

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-8002:


 Summary: Authentication:  add to REST support of new authentication
 Key: IGNITE-8002
 URL: https://issues.apache.org/jira/browse/IGNITE-8002
 Project: Ignite
  Issue Type: Task
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov






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

[jira] [Created] (IGNITE-8001) Web console: show more userfriendly error instead of 'Internal error'

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8001:
--

 Summary: Web console: show more userfriendly error instead of 
'Internal error'
 Key: IGNITE-8001
 URL: https://issues.apache.org/jira/browse/IGNITE-8001
 Project: Ignite
  Issue Type: Improvement
Reporter: Pavel Konstantinov
 Attachments: screenshot-1.png

In case if the backend is down we display the 'Internal error' message.
I suggest displaying some other more user-friendly text.




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

Re: Move documentation from readme.io to GitHub pages

[Prachi Garg]

I looked into Docusaurus and GitBook. I liked Docusaurus better because it
allows publishing to github pages or other static files hosts, and various
other features. My findings are mentioned in the ticket -
https://issues.apache.org/jira/browse/IGNITE-7595 .

On Fri, Feb 2, 2018 at 2:42 PM, Denis Magda  wrote:

> Looks promising. Thanks for sharing. Updated the ticket.
>
> —
> Denis
>
> > On Feb 2, 2018, at 2:25 PM, Dmitriy Setrakyan 
> wrote:
> >
> > I think docusaurus.io could work for us. Denis, what do you think?
> >
> > On Fri, Feb 2, 2018 at 3:10 AM, endianignite 
> wrote:
> >
> >> I noticed that Facebook open-sourced a documentation platform last
> month,
> >> https://docusaurus.io/, which may be worth considering.
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> >>
>
>

RE: Ignite Direct I/O plugin description added to wiki

[Raymond Wilson]

Denis,

Thanks for the clarification on read-intensive workloads not being suitable
for Direct IO.

As a counterpoint to that, I would have thought the working set represented
by the in-memory data held by the Ignite node would be significantly larger
than the OS page cache which should mean the read hit rate on the OS page
cache would be very low under those workloads? Of course, this assumes your
WAL page size is configured to be similar to the OS page size, but still

-Original Message-
From: Denis Magda [mailto:dma...@apache.org]
Sent: Wednesday, March 21, 2018 11:59 AM
To: dev@ignite.apache.org; Prachi Garg 
Subject: Re: Ignite Direct I/O plugin description added to wiki

*Dmitriy*, thanks. Astonishing job! We'll add a section to the durable
memory tuning page and refer to the wiki for more details:
https://issues.apache.org/jira/browse/IGNITE-7466

Please clarify the following:

> Direct I/O mode can't be enabled for Write Ahead Log files. However,
> when working with plugin, WAL manager applies advising Linux systems
> do not store the data of the file in page cache as they are not required.


For me, it means that WAL always goes through the operating system I/O
calls. Nothing changes for the WAL. However, I'm not sure what you meant to
explain by saying "when working with the plugin (Direct I/O) WAL manager
applies...". Could you rephrase it to bring more clarity?

*Raymond,*

If Direct I/O is enabled by default it will bring down the performance of
read-intensive application because, as Dmitry says, the reads bypass page
cache. So, I would recommend using it for write-intensive workloads and,
probably, for mixed-workloads depending on the reads and writes rate.

--
Denis


On Tue, Mar 20, 2018 at 2:29 PM, Raymond Wilson 
wrote:

> Looks good!
>
> Is there any reason why this should not be a default setting if it
> gracefully downgrades to non-Direct IO if not supported by the OS?
>
> Thanks,
> Raymond.
>
> -Original Message-
> From: Dmitriy Setrakyan [mailto:dsetrak...@apache.org]
> Sent: Wednesday, March 21, 2018 10:23 AM
> To: dev 
> Subject: Re: Ignite Direct I/O plugin description added to wiki
>
> Thanks Dmitry, awesome work!
>
> On Wed, Mar 21, 2018 at 12:21 AM, Dmitry Pavlov
> 
> wrote:
>
> > Hi Igniters,
> >
> > I've added description of new plugin for Direct I/O for native
> > persistence (
> > https://issues.apache.org/jira/browse/IGNITE-6341)  to wiki
> > https://cwiki.apache.org/confluence/display/IGNITE/
> > Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStore-
> > underthehood-DirectI/O
> >
> >
> > SIncerely,
> > Dmitriy Pavlov
> >
>

Re: Ignite Direct I/O plugin description added to wiki

[Denis Magda]

*Dmitriy*, thanks. Astonishing job! We'll add a section to the durable
memory tuning page and refer to the wiki for more details:
https://issues.apache.org/jira/browse/IGNITE-7466

Please clarify the following:

> Direct I/O mode can't be enabled for Write Ahead Log files. However, when
> working with plugin, WAL manager applies advising Linux systems do not
> store the data of the file in page cache as they are not required.


For me, it means that WAL always goes through the operating system I/O
calls. Nothing changes for the WAL. However, I'm not sure what you meant to
explain by saying "when working with the plugin (Direct I/O) WAL manager
applies...". Could you rephrase it to bring more clarity?

*Raymond,*

If Direct I/O is enabled by default it will bring down the performance of
read-intensive application because, as Dmitry says, the reads bypass page
cache. So, I would recommend using it for write-intensive workloads and,
probably, for mixed-workloads depending on the reads and writes rate.

--
Denis


On Tue, Mar 20, 2018 at 2:29 PM, Raymond Wilson 
wrote:

> Looks good!
>
> Is there any reason why this should not be a default setting if it
> gracefully downgrades to non-Direct IO if not supported by the OS?
>
> Thanks,
> Raymond.
>
> -Original Message-
> From: Dmitriy Setrakyan [mailto:dsetrak...@apache.org]
> Sent: Wednesday, March 21, 2018 10:23 AM
> To: dev 
> Subject: Re: Ignite Direct I/O plugin description added to wiki
>
> Thanks Dmitry, awesome work!
>
> On Wed, Mar 21, 2018 at 12:21 AM, Dmitry Pavlov 
> wrote:
>
> > Hi Igniters,
> >
> > I've added description of new plugin for Direct I/O for native
> > persistence (
> > https://issues.apache.org/jira/browse/IGNITE-6341)  to wiki
> > https://cwiki.apache.org/confluence/display/IGNITE/
> > Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStore-
> > underthehood-DirectI/O
> >
> >
> > SIncerely,
> > Dmitriy Pavlov
> >
>

RE: Ignite Direct I/O plugin description added to wiki

[Raymond Wilson]

Looks good!

Is there any reason why this should not be a default setting if it
gracefully downgrades to non-Direct IO if not supported by the OS?

Thanks,
Raymond.

-Original Message-
From: Dmitriy Setrakyan [mailto:dsetrak...@apache.org]
Sent: Wednesday, March 21, 2018 10:23 AM
To: dev 
Subject: Re: Ignite Direct I/O plugin description added to wiki

Thanks Dmitry, awesome work!

On Wed, Mar 21, 2018 at 12:21 AM, Dmitry Pavlov 
wrote:

> Hi Igniters,
>
> I've added description of new plugin for Direct I/O for native
> persistence (
> https://issues.apache.org/jira/browse/IGNITE-6341)  to wiki
> https://cwiki.apache.org/confluence/display/IGNITE/
> Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStore-
> underthehood-DirectI/O
>
>
> SIncerely,
> Dmitriy Pavlov
>

Re: Ignite Direct I/O plugin description added to wiki

[Dmitriy Setrakyan]

Thanks Dmitry, awesome work!

On Wed, Mar 21, 2018 at 12:21 AM, Dmitry Pavlov 
wrote:

> Hi Igniters,
>
> I've added description of new plugin for Direct I/O for native persistence
> (
> https://issues.apache.org/jira/browse/IGNITE-6341)  to wiki
> https://cwiki.apache.org/confluence/display/IGNITE/
> Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStore-
> underthehood-DirectI/O
>
>
> SIncerely,
> Dmitriy Pavlov
>

Ignite Direct I/O plugin description added to wiki

[Dmitry Pavlov]

Hi Igniters,

I've added description of new plugin for Direct I/O for native persistence (
https://issues.apache.org/jira/browse/IGNITE-6341)  to wiki
https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStore-underthehood-DirectI/O


SIncerely,
Dmitriy Pavlov

Re: readme.io weird interface element

[Prachi Garg]

Hi Petr, Denis,

Sorry missed the message. Petr, please feel free to create a ticket.

Thanks,
-Prachi


On Mon, Mar 19, 2018 at 8:24 PM, Petr Ivanov  wrote:

> Prachi, has you filed the ticket or should I create one?
>
>
>
> > On 15 Mar 2018, at 23:07, Denis Magda  wrote:
> >
> > Please create a ticket and let's fix it in the nearest future.
> >
> > --
> > Denis
> >
> > On Thu, Mar 15, 2018 at 12:47 PM, Prachi Garg 
> wrote:
> >
> >> That's the download button. Tables on feature pages are downloadable in
> >> pdf, csv format. There is a javascript code embedded with the table
> >> element. Not sure why it doesn't work on the download page; works fine
> on
> >> other pages.
> >>
> >> On Thu, Mar 15, 2018 at 12:16 PM, Denis Magda 
> wrote:
> >>
> >>> Have no idea, just makes the table looks nicer :)
> >>>
> >>> Prachi, what is this for? It's not clear from the HTML sources.
> >>>
> >>> --
> >>> Denis
> >>>
> >>> On Thu, Mar 15, 2018 at 12:09 PM, Petr Ivanov 
> >> wrote:
> >>>
>  Sorry for misleading. I meant https://ignite.apache.org/download.cgi
>  indeed.
> 
> 
> 
> > On 15 Mar 2018, at 22:05, Denis Magda  wrote:
> >
> > Petr,
> >
> > What's that? It doesn't look like the readme.io doc that hosts all
>  Ignite
> > docs:
> > https://apacheignite.readme.io/docs
> >
> > --
> > Denis
> >
> > On Thu, Mar 15, 2018 at 1:52 AM, vveider 
> wrote:
> >
> >> Hi, all!
> >>
> >>
> >> Does anyone know what is this button with arrow and disk at the
> right
> >> corner
> >> of versions list header? [1]
> >> Seems that it does nothing.
> >>
> >> [1] https://ibb.co/eJf5uc
> >>
> >>
> >>
> >> --
> >> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> >>
> 
> 
> >>>
> >>
>
>

[jira] [Created] (IGNITE-8000) Implicit transactions may not finish properly on unstable topology.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-8000:
-

 Summary: Implicit transactions may not finish properly on unstable 
topology.
 Key: IGNITE-8000
 URL: https://issues.apache.org/jira/browse/IGNITE-8000
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Alexei Scherbakov
 Fix For: 2.5


Add default tx timeout [1] to IgniteCacheMultiTxLockSelfTest test configuration.

[1] c.getTransactionConfiguration().setDefaultTxTimeout(10);

Looks like in some case remote tx is added to rolled back version (because 
partition is gone) and subsequent near request for the same tx to this node 
fails.

This is not happen if timeouts are disabled because corresponding check is 
skipped.



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

[GitHub] ignite pull request #3663: ignite-7989 returned ConcurrentHashMap8 for backw...

[akalash]

GitHub user akalash opened a pull request:

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

ignite-7989 returned ConcurrentHashMap8 for backward compatibi…

…lity

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

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

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

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






---

Re: 2 phase waiting for partitions release

[Dmitry Pavlov]

Hi Igniters,

I prefer option 1 because throwing any exceptions is bad for product
usability. I think we should do this way only if it is unavoidable.

In the same time it would be good if we could provide so reliable but
optimized (from the point of view of messages count) solution.

Please share your vision.

Sincerely,
Dmitriy Pavlov

пн, 19 мар. 2018 г. в 20:15, Pavel Kovalenko :

> Hello Igniters,
>
> Current implementation of
> GridDhtPartitionsExchangeFuture#waitPartitionRelease function doesn't give
> us 100% guarantees that
> after this method completes there are no ongoing atomic or transactional
> updates on current node during main stage of PME.
> It gives us only guarantee that all primary updates will be finished on
> that node, while we can still receive and process backup updates after this
> method.
> Example of such case is described in
> https://issues.apache.org/jira/browse/IGNITE-7871
>
> To avoid such situations we would like to implement second phase of
> waitPartitionRelease method.
> On this phase every server node participating in PME should wait while all
> other server nodes will finish their ongoing updates.
>
> Here is brief algorithm description:
>
> Non-coordinator node:
> 1) Finish all ongoing atomic & transactional updates.
> 2) Send acknowledgement to coordinator.
> 3) Wait for final acknowledgement from coordinator, that all nodes finished
> their updates.
> 4) Continue PME.
>
> Coordinator node:
> 1) Finish all ongoing atomic & transactional updates.
> 2) Wait for all acknowledgements from all server nodes.
> 3) Send final acknowledgement to all server nodes.
> 4) Continue PME.
>
> Acknowledgement messages have tiny size, so network pressure and overall
> performance drop will be minimal.
>
> Another solution of the problem is just cancelling atomic backup updates
> and transactional backup updates on PREPARED phase if topology version is
> changed.
> But from user perspective it's not correct to catch transaction errors even
> in cases when node is joining to the cluster.
>
> Any thoughts?
>

[jira] [Created] (IGNITE-7999) Enhance performance of the thin JDBC streaming mode

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-7999:


 Summary: Enhance performance of the thin JDBC streaming mode 
 Key: IGNITE-7999
 URL: https://issues.apache.org/jira/browse/IGNITE-7999
 Project: Ignite
  Issue Type: Task
  Components: jdbc
Affects Versions: 2.4
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.5


Try to enhance thin JDBC performance for streaming mode.
Waiting for server response takes a lot of time on streaming INSERT.
Try to skip server response in special mode.



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

[jira] [Created] (IGNITE-7998) SQL: Improve MVCC vacuum performance by iterating over data pages instead of cache tree.

[Roman Kondakov (JIRA)]

Roman Kondakov created IGNITE-7998:
--

 Summary: SQL: Improve MVCC vacuum performance by iterating over 
data pages instead of cache tree. 
 Key: IGNITE-7998
 URL: https://issues.apache.org/jira/browse/IGNITE-7998
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Roman Kondakov


At the moment vacuum process uses cache trees to find outdated (dead) entries 
and cache and index trees to cleanup them. It is not efficient due to several 
reasons. For example, we should lock a datapage for each cache tree entry to 
find out if entry is dead.

We can consider a direct iteration over datapages as a possible improvement of  
the vacuum process. Data page iteration prototype demonstrated 5-10 times time 
improvement over the tree iteration.

At first stage we need to implement direct datapages iteration only for 
collecting dead entries links.

At the second stage we need to consider removing links to dead entries from 
index pages directly. In other words, we need to efficiently remove batches of 
dead links from indexes without traversing cache and index tree one dead link 
by one.



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

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

[Ivan Rakov]

Val,


If a storage is in
corrupted state, does it mean that it needs to be completely removed and
cluster needs to be restarted without data?


Yes, there's a chance that in LOG_ONLY all local data will be lost, but 
only in *power loss**/ OS crash* case.
kill -9, JVM crash, death of critical system thread and all other cases 
that usually take place are variations of *process crash*. All WAL modes 
(except NONE, of course) ensure corruption-safety in case of process crash.



If so, I'm not sure any mode
that allows corruption makes much sense to me.
It depends on performance impact of enforcing power-loss corruption 
safety. Price of full protection from power loss is high - FSYNC is way 
slower (2-10 times) than other WAL modes. The question is whether 
ensuring weaker guarantees (corruption can't happen, but loss of last 
updates can) will affect performance as badly as strong guarantees. I'll 
share benchmark results soon.


Best Regards,
Ivan Rakov

On 20.03.2018 5:09, Valentin Kulichenko wrote:

Guys,

What do we understand under "data corruption" here? If a storage is in
corrupted state, does it mean that it needs to be completely removed and
cluster needs to be restarted without data? If so, I'm not sure any mode
that allows corruption makes much sense to me. How am I supposed to use a
database, if virtually any failure can end with complete loss of data?

In any case, this definitely should not be a default behavior. If user ever
switches to corruption-unsafe mode, there should be a clear warning about
this.

-Val

On Fri, Mar 16, 2018 at 1:06 AM, Ivan Rakov  wrote:


Ticket to track changes: https://issues.apache.org/jira/browse/IGNITE-7754

Best Regards,
Ivan Rakov


On 16.03.2018 10:58, Dmitriy Setrakyan wrote:


On Fri, Mar 16, 2018 at 12:55 AM, Ivan Rakov 
wrote:

Vladimir,

Unlike BACKGROUND, LOG_ONLY provides strict write guarantees unless power
loss has happened.
Seems like we need to measure performance difference to decide whether do
we need separate WAL mode. If it will be invisible, we'll just fix these
bugs without introducing new mode; if it will be perceptible, we'll
continue the discussion about introducing LOG_ONLY_SAFE.
Makes sense?

Yes, this sounds like the right approach.

Re: Apache Ignite nightly release builds

[Petr Ivanov]

Not yet.
Project is still under development, I will pass build to community after 
settling corresponding permissions and receiving QA report.

Also — it is time to rise a matter about adding nightly build link to out 
documentation (somewhere here [1]).
Pavel, could you help?


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


> On 20 Mar 2018, at 13:58, Dmitry Pavlov  wrote:
> 
> Thank you, Petr,
> 
> could you share link to run config?
> 
> Sincerely,
> Dmitriy Pavlov
> 
> вт, 20 мар. 2018 г. в 12:17, Petr Ivanov :
> 
>> Prepared prototype build, passed for some preliminary testing.
>> Currently it will provide the following artifacts:
>> * sources
>> * fabric binary
>> * hadoop binary
>> * maven staging
>> * nuget staging
>> 
>> Will keep community informed about progress.
>> 
>> 
>> 
>>> On 14 Mar 2018, at 13:13, vveider  wrote:
>>> 
>>> Prepared corresponding task [1], will start preparing build in the
>> nearest
>>> future.
>>> 
>>> 
>>> [1] https://issues.apache.org/jira/browse/IGNITE-7945
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>> 
>> 

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

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3655: IGNITE-7984

[devozerov]

Github user devozerov closed the pull request at:

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


---

[GitHub] ignite pull request #3662: IGNITE-6113 Backport to 2.4.3.b1

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-6113 Backport to 2.4.3.b1



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

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

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

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


commit e7ca9b65a68de7752195c8f4d2b5180f3c77d19f
Author: Dmitriy Govorukhin 
Date:   2017-11-13T18:52:47Z

ignite-blt-merge -> ignite-2.4.1

commit cc8168fc184bb7f5e3cc3bbb0743397097f78bfb
Author: Dmitriy Govorukhin 
Date:   2017-11-13T19:13:01Z

merge ignite-pitr-rc1 -> ignite-2.4.1

commit 87e6d74cf6a251c7984f9e68c391f790feccc281
Author: Dmitriy Govorukhin 
Date:   2017-11-14T12:49:33Z

ignite-gg-12877 Compact consistent ID in WAL

commit 9f5a22711baea05bd37ab07c8f928a4837dd83a4
Author: Ilya Lantukh 
Date:   2017-11-14T14:12:28Z

Fixed javadoc.

commit d5af2d78dd8eef8eca8ac5391d31d8c779649bb0
Author: Alexey Kuznetsov 
Date:   2017-11-15T08:09:00Z

IGNITE-6913 Baseline: Added new options to controls.sh for baseline 
manipulations.

commit 713924ce865752b6e99b03bd624136541cea5f9f
Author: Sergey Chugunov 
Date:   2017-11-15T09:03:12Z

IGNITE-5850 failover tests for cache operations during BaselineTopology 
changes

commit b65fd134e748d496f732ec2aa0953a0531f544b8
Author: Ilya Lantukh 
Date:   2017-11-15T12:54:35Z

TX read logging if PITR is enabled.

commit 9b2a567c0e04dc33116b51f88bee75f76e9107d1
Author: Ilya Lantukh 
Date:   2017-11-15T13:45:16Z

TX read logging if PITR is enabled.

commit 993058ccf0b2b8d9e80750c3e45a9ffa31d85dfa
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:51:54Z

ignite-2.4.1 optimization for store full set node more compacted

commit 1eba521f608d39967aec376b397b7fc800234e54
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:52:22Z

Merge remote-tracking branch 'professional/ignite-2.4.1' into ignite-2.4.1

commit 564b3fd51f8a7d1d81cb6874df66d0270623049c
Author: Sergey Chugunov 
Date:   2017-11-15T14:00:51Z

IGNITE-5850 fixed issue with initialization of data regions on node 
activation, fixed issue with auto-activation when random node joins inactive 
cluster with existing BLT

commit c6d1fa4da7adfadc80abdc7eaf6452b86a4f6aa4
Author: Sergey Chugunov 
Date:   2017-11-15T16:23:08Z

IGNITE-5850 transitionResult is set earlier when request for changing 
BaselineTopology is sent

commit d65674363163e38a4c5fdd73d1c8d8e1c7610797
Author: Sergey Chugunov 
Date:   2017-11-16T11:59:07Z

IGNITE-5850 new failover tests for changing BaselineTopology up (new node 
added to topology)

commit 20552f3851fe8825191b144179be032965e0b5c6
Author: Sergey Chugunov 
Date:   2017-11-16T12:53:43Z

IGNITE-5850 improved error message when online node is removed from baseline

commit 108bbcae4505ac904a6db774643ad600bfb42c21
Author: Sergey Chugunov 
Date:   2017-11-16T13:45:52Z

IGNITE-5850 BaselineTopology should not change on cluster deactivation

commit deb641ad3bdbf260fa60ad6bf607629652e324bd
Author: Dmitriy Govorukhin 
Date:   2017-11-17T09:45:44Z

ignite-2.4.1 truncate wal and checkpoint history on move/delete snapshot

commit 3c8b06f3659af30d1fd148ccc0f40e216a56c998
Author: Alexey Goncharuk 
Date:   2017-11-17T12:48:12Z

IGNITE-6947 Abandon remap after single map if future is done (fixes NPE)

commit ba2047e5ae7d271a677e0c418375d82d78c4023e
Author: devozerov 
Date:   2017-11-14T12:26:31Z

IGNITE-6901: Fixed assertion during 
IgniteH2Indexing.rebuildIndexesFromHash. This closes #3027.

commit abfc0466d6d61d87255d0fe38cbdf11ad46d4f89
Author: Sergey Chugunov 
Date:   2017-11-17T13:40:57Z

IGNITE-5850 tests for queries in presence of BaselineTopology

commit f4eabaf2a905abacc4c60c01d3ca04f6ca9ec188
Author: Sergey Chugunov 
Date:   2017-11-17T17:23:02Z

IGNITE-5850 implementation for setBaselineTopology(long topVer) migrated 
from wc-251

commit 4edeccd3e0b671aa277f58995df9ff9935baa95a
Author: EdShangGG 
Date:   2017-11-17T18:21:17Z

GG-13074 Multiple snapshot test failures after baseline topology is 
introduced
-adding baseline test to suite
-fixing issues with baseline

commit edae228c8f55990c15ef3044be987dcb00d6c81a
Author: EdShangGG 
Date:   2017-11-18T10:36:41Z

hack with sleep

commit b5bffc7580a4a8ffbcc06f60c282e73979179578
Author: 

Re: Apache Ignite nightly release builds

[Dmitry Pavlov]

Thank you, Petr,

could you share link to run config?

Sincerely,
Dmitriy Pavlov

вт, 20 мар. 2018 г. в 12:17, Petr Ivanov :

> Prepared prototype build, passed for some preliminary testing.
> Currently it will provide the following artifacts:
>  * sources
>  * fabric binary
>  * hadoop binary
>  * maven staging
>  * nuget staging
>
> Will keep community informed about progress.
>
>
>
> > On 14 Mar 2018, at 13:13, vveider  wrote:
> >
> > Prepared corresponding task [1], will start preparing build in the
> nearest
> > future.
> >
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-7945
> >
> >
> >
> > --
> > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>
>

[GitHub] ignite pull request #3657: IGNITE-7888: Added support for SQL_ATTR_LOGIN_TIM...

[asfgit]

Github user asfgit closed the pull request at:

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


---

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

[Yakov Zhdanov]

If java runs oome then you cannot guarantee anything. Including calling
runtime.halt().

My point is about consistent approach throughout the project. I think
developing new mechanism with separate interface is incorrect.

Yakov

[GitHub] ignite pull request #3597: IGNITE-7869 Dynamic start cache by stored cache d...

[akalash]

Github user akalash closed the pull request at:

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


---

[GitHub] ignite pull request #3650: IGNITE-7976 Normalize query entites when dynamic ...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Apache Ignite nightly release builds

[Petr Ivanov]

Prepared prototype build, passed for some preliminary testing.
Currently it will provide the following artifacts:
 * sources
 * fabric binary
 * hadoop binary
 * maven staging
 * nuget staging

Will keep community informed about progress.



> On 14 Mar 2018, at 13:13, vveider  wrote:
> 
> Prepared corresponding task [1], will start preparing build in the nearest
> future.
> 
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-7945
> 
> 
> 
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: Stop nodes after test by default - IGNITE-6842

[Dmitry Pavlov]

Dmitriy, thank you for review. This fix should do our tests more stable.

Nikolay, could you please merge?

вт, 20 мар. 2018 г. в 11:49, Dmitriy Govorukhin <
dmitriy.govoruk...@gmail.com>:

> Looks good for me, please merge.
>
> 19 мар. 2018 г. 3:22 ПП пользователь "Dmitry Pavlov" <
> dpavlov@gmail.com> написал:
>
> I agree it is important, I'm going to do a review, but do not have time
>> slot to do.
>>
>> Who could pick up this review?
>>
>> Dmitriy G., could I ask you?
>>
>> пн, 19 мар. 2018 г. в 15:13, Maxim Muzafarov :
>>
>>> Dmitry and other igniters,
>>>
>>> Will you have time to review this issue?
>>> I've preperated PR and TC for this, also I've fixed all comments made by
>>> Andrey Kuznetsov and Vyacheslav Daradur.
>>>
>>> I think this is important issue and will make test framework more stable
>>> and clear.
>>>
>>>
>>> TC: https://ci.ignite.apache.org/viewLog.html?buildId=1138151
>>> JIRA: https://issues.apache.org/jira/browse/IGNITE-6842
>>> Upsource: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-502
>>> PR: https://github.com/apache/ignite/pull/3542
>>>
>>> чт, 15 мар. 2018 г. в 13:31, Maxim Muzafarov :
>>>
 Dmtry,

 Can we proceed with this change?
 I've done with fixing review comments and tests that you mentioned
 before.

 TC: https://ci.ignite.apache.org/viewLog.html?buildId=1138151
 JIRA: https://issues.apache.org/jira/browse/IGNITE-6842
 Upsource: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-502
 PR: https://github.com/apache/ignite/pull/3542



 вт, 6 мар. 2018 г. в 20:42, Dmitry Pavlov :

> Ok, thank you.
>
> Please let me know when we can proceed with review
> https://reviews.ignite.apache.org/ignite/review/IGNT-CR-502
>
>
> вт, 6 мар. 2018 г. в 20:17, Maxim Muzafarov :
>
> > Hello Dmitry,
> >
> > Yes, I've updated test classes as you metioned before.
> > Now i'm fixing review comments. Within next few days I'll prepare
> final
> > version of this PR.
> >
> > вт, 6 мар. 2018 г. в 20:12, Dmitry Pavlov :
> >
> > > Hi Maxim,
> > >
> > > are there any news on these test fails?
> > >
> > > Is issue ready for review?
> > >
> > > Sincerely,
> > > Dmitiry Pavlov
> > >
> > > вт, 27 февр. 2018 г. в 17:12, Dmitry Pavlov  >:
> > >
> > > > Hi, thank you!
> > > >
> > > > I've found several suspicious fails: such test fails have rate
> less
> > than
> > > > 1%, it is probably new failures.
> > > >
> > > > It would be great if we can fix it before merge. Could you
> address this
> > > > fails?
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > IgniteCacheTestSuite5:
> IgniteCacheStoreCollectionTest.testStoreMap
> > (fail
> > > > rate 0,0%)
> > > > IgniteCacheTestSuite5:
> > > > CacheLateAffinityAssignmentTest.testDelayAssignmentClientJoin
> (fail
> > rate
> > > > 0,0%)
> > > > IgniteCacheWithIndexingTestSuite:
> > > > CacheRandomOperationsMultithreadedTest.testAtomicOffheapEviction
> (fail
> > > rate
> > > > 0,0%)
> > > > IgniteCacheWithIndexingTestSuite:
> > > >
> >
> CacheRandomOperationsMultithreadedTest.testAtomicOffheapEvictionIndexing
> > > > (fail rate 0,0%)
> > > > IgniteCacheWithIndexingTestSuite:
> > > > CacheRandomOperationsMultithreadedTest.testTxOffheapEviction
> (fail rate
> > > > 0,0%)
> > > > IgniteCacheWithIndexingTestSuite:
> > > >
> CacheRandomOperationsMultithreadedTest.testTxOffheapEvictionIndexing
> > > (fail
> > > > rate 0,0%)
> > > >
> > > > IgniteBinarySimpleNameMapperCacheFullApiTestSuite:
> > > >
> > >
> >
> GridCachePartitionedNearDisabledMultiNodeWithGroupFullApiSelfTest.testWithSkipStoreTx
> > > > (fail rate 0,0%)
> > > >
> > > > вт, 27 февр. 2018 г. в 17:04, Maxim Muzafarov <
> maxmu...@gmail.com>:
> > > >
> > > >> Yep, link may not be correct.
> > > >>
> > > >> Here is correct version:
> > > >> TC: *
> > > >>
> > >
> >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3542%2Fhead
> > > >> <
> > > >>
> > >
> >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3542%2Fhead
> > > >> >*
> > > >>
> > > >>
> > > >> вт, 27 февр. 2018 г. в 16:41, Dmitry Pavlov <
> dpavlov@gmail.com>:
> > > >>
> > > >> > Hi Maxim,
> > > >> >
> > > >> > could you please provide link to TC run on your PR? It seems
> link
> > > >> provided
> > > >> > points to run of master. In changes field you may select
> > > pull/3542/head
> > > >> > 

Re: Stop nodes after test by default - IGNITE-6842

[Dmitriy Govorukhin]

Looks good for me, please merge.

19 мар. 2018 г. 3:22 ПП пользователь "Dmitry Pavlov" 
написал:

> I agree it is important, I'm going to do a review, but do not have time
> slot to do.
>
> Who could pick up this review?
>
> Dmitriy G., could I ask you?
>
> пн, 19 мар. 2018 г. в 15:13, Maxim Muzafarov :
>
>> Dmitry and other igniters,
>>
>> Will you have time to review this issue?
>> I've preperated PR and TC for this, also I've fixed all comments made by
>> Andrey Kuznetsov and Vyacheslav Daradur.
>>
>> I think this is important issue and will make test framework more stable
>> and clear.
>>
>>
>> TC: https://ci.ignite.apache.org/viewLog.html?buildId=1138151
>> JIRA: https://issues.apache.org/jira/browse/IGNITE-6842
>> Upsource: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-502
>> PR: https://github.com/apache/ignite/pull/3542
>>
>> чт, 15 мар. 2018 г. в 13:31, Maxim Muzafarov :
>>
>>> Dmtry,
>>>
>>> Can we proceed with this change?
>>> I've done with fixing review comments and tests that you mentioned
>>> before.
>>>
>>> TC: https://ci.ignite.apache.org/viewLog.html?buildId=1138151
>>> JIRA: https://issues.apache.org/jira/browse/IGNITE-6842
>>> Upsource: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-502
>>> PR: https://github.com/apache/ignite/pull/3542
>>>
>>>
>>>
>>> вт, 6 мар. 2018 г. в 20:42, Dmitry Pavlov :
>>>
 Ok, thank you.

 Please let me know when we can proceed with review
 https://reviews.ignite.apache.org/ignite/review/IGNT-CR-502


 вт, 6 мар. 2018 г. в 20:17, Maxim Muzafarov :

 > Hello Dmitry,
 >
 > Yes, I've updated test classes as you metioned before.
 > Now i'm fixing review comments. Within next few days I'll prepare
 final
 > version of this PR.
 >
 > вт, 6 мар. 2018 г. в 20:12, Dmitry Pavlov :
 >
 > > Hi Maxim,
 > >
 > > are there any news on these test fails?
 > >
 > > Is issue ready for review?
 > >
 > > Sincerely,
 > > Dmitiry Pavlov
 > >
 > > вт, 27 февр. 2018 г. в 17:12, Dmitry Pavlov :
 > >
 > > > Hi, thank you!
 > > >
 > > > I've found several suspicious fails: such test fails have rate
 less
 > than
 > > > 1%, it is probably new failures.
 > > >
 > > > It would be great if we can fix it before merge. Could you
 address this
 > > > fails?
 > > >
 > > > Sincerely,
 > > > Dmitriy Pavlov
 > > >
 > > > IgniteCacheTestSuite5: IgniteCacheStoreCollectionTest
 .testStoreMap
 > (fail
 > > > rate 0,0%)
 > > > IgniteCacheTestSuite5:
 > > > CacheLateAffinityAssignmentTest.testDelayAssignmentClientJoin
 (fail
 > rate
 > > > 0,0%)
 > > > IgniteCacheWithIndexingTestSuite:
 > > > CacheRandomOperationsMultithreadedTest.testAtomicOffheapEviction
 (fail
 > > rate
 > > > 0,0%)
 > > > IgniteCacheWithIndexingTestSuite:
 > > >
 > CacheRandomOperationsMultithreadedTest.testAtomicOffheapEvictionIndex
 ing
 > > > (fail rate 0,0%)
 > > > IgniteCacheWithIndexingTestSuite:
 > > > CacheRandomOperationsMultithreadedTest.testTxOffheapEviction
 (fail rate
 > > > 0,0%)
 > > > IgniteCacheWithIndexingTestSuite:
 > > > CacheRandomOperationsMultithreadedTest.
 testTxOffheapEvictionIndexing
 > > (fail
 > > > rate 0,0%)
 > > >
 > > > IgniteBinarySimpleNameMapperCacheFullApiTestSuite:
 > > >
 > >
 > GridCachePartitionedNearDisabledMultiNodeWithGroupFullApiSel
 fTest.testWithSkipStoreTx
 > > > (fail rate 0,0%)
 > > >
 > > > вт, 27 февр. 2018 г. в 17:04, Maxim Muzafarov :
 > > >
 > > >> Yep, link may not be correct.
 > > >>
 > > >> Here is correct version:
 > > >> TC: *
 > > >>
 > >
 > https://ci.ignite.apache.org/project.html?projectId=
 IgniteTests24Java8_IgniteTests24Java8=pull%2F3542%2Fhead
 > > >> <
 > > >>
 > >
 > https://ci.ignite.apache.org/project.html?projectId=
 IgniteTests24Java8_IgniteTests24Java8=pull%2F3542%2Fhead
 > > >> >*
 > > >>
 > > >>
 > > >> вт, 27 февр. 2018 г. в 16:41, Dmitry Pavlov <
 dpavlov@gmail.com>:
 > > >>
 > > >> > Hi Maxim,
 > > >> >
 > > >> > could you please provide link to TC run on your PR? It seems
 link
 > > >> provided
 > > >> > points to run of master. In changes field you may select
 > > pull/3542/head
 > > >> > before starting RunAll.
 > > >> >
 > > >> > Igniters,
 > > >> >
 > > >> > this change is related to our test framework, so change may
 affect
 > > your
 > > >> > tests. Please join to review
 > > >> > https://reviews.ignite.apache.org/ignite/review/IGNT-CR-502
 > > >> >
 > > >> > Sincerely,
 > > >> > 

[GitHub] ignite pull request #3661: IGNITE-7993 Striped pool can't be disabled

[gromtech]

GitHub user gromtech opened a pull request:

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

IGNITE-7993 Striped pool can't be disabled

Restored the capability to disable striped pool

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

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

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

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


commit ae1919f258ca1c3dea9624107d975c866c8dffd5
Author: Roman Guseinov 
Date:   2018-03-20T08:29:40Z

IGNITE-7993 Striped pool can't be disabled




---

[jira] [Created] (IGNITE-7996) Web console: move cluster configuration form templates

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-7996:


 Summary: Web console: move cluster configuration form templates
 Key: IGNITE-7996
 URL: https://issues.apache.org/jira/browse/IGNITE-7996
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Ilya Borisov
Assignee: Ilya Borisov


The IGNITE-5466 introduced individual components for each of cluster 
configuration forms, but  template files were left in the same place to 
decrease incoming changes merge conflicts during development time. When 
IGNITE-5466 gets merged into master, it should be safe to move all the 
templates into component directories.



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

[GitHub] ignite pull request #3641: Keep marshaller mappings in consistent state: bac...

[dmekhanikov]

Github user dmekhanikov closed the pull request at:

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


---

[jira] [Created] (IGNITE-7995) Assertion on GridGhtPartitionDemandMessage

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-7995:


 Summary: Assertion on GridGhtPartitionDemandMessage
 Key: IGNITE-7995
 URL: https://issues.apache.org/jira/browse/IGNITE-7995
 Project: Ignite
  Issue Type: New Feature
  Components: general
Affects Versions: 2.4
Reporter: Alexander Belyak


After applying new baseline topology get
Failed processing message [sender=..., 
msg=GridGhtPartitionDemandMessage[updateSeq=10524, timeout=1, workerId=-1, 
topVer=ArrinityTopologyVersion [topVer=170, minorTopVer=1], partCnt=1, 
super=GridCacheGroupIdMessage [grpId=-1029020343]]]
java.lang.AssertionError: partCntr=5338946, reservations=Map []
from GridCacheOffheapManager.rebalanceIterator:704




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