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

[Dmitry Pavlov]

Yes, will do.

чт, 22 мар. 2018 г. в 1:05, Denis Magda :

> Dmitriy,
>
> Thanks for updating the WAL section. Now it makes total sense to me.
>
> As for the page with JNA projects, let's get added there! Could you
> contact the owners?
>
> --
> Denis
>
>
> On Wed, Mar 21, 2018 at 9:27 AM, Dmitry Pavlov 
> wrote:
>
>> Denis,
>>
>> one more thing, can/should we mention Ignite Direct IO plugin in list of
>> project using JNA here: https://github.com/java-native-access/jna
>>
>> Sincerely,
>> Dmitriy Pavlov
>>
>> ср, 21 мар. 2018 г. в 1:59, 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 <
>>> raymond_wil...@trimble.com>
>>> 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
>>> > >
>>> >
>>>
>>
>

[jira] [Created] (IGNITE-8009) SQL local query to a cache with queryParallelism>1 doesn't use index

[Pavel Vinokurov (JIRA)]

Pavel Vinokurov created IGNITE-8009:
---

 Summary: SQL local query to a cache with queryParallelism>1  
doesn't use index
 Key: IGNITE-8009
 URL: https://issues.apache.org/jira/browse/IGNITE-8009
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.4, 2.3
Reporter: Pavel Vinokurov
 Attachments: ExplainAndIndexReproducer.java

queryParallelism>1 + setLocal(true)  changes the query plan and exclude usage 
of the sql index.

Explain query with setLocal(false) and queryParallelism=1
SELECT
T__Z0.ID AS __C0_0
FROM TABLE(COL VARCHAR='name0') I__Z1
/* function */
INNER JOIN PUBLIC.PERSON T__Z0
/* PUBLIC.PERSON_NAME: NAME = I__Z1.COL */
ON 1=1
WHERE (T__Z0.SOURNAME = 'sourname0')
AND (T__Z0.NAME = I__Z1.COL)

Explain query with setLocal(true) and queryParallelism=2
SELECT
T__Z1.ID AS __C0_0
FROM PUBLIC.PERSON T__Z1
/* PUBLIC.PERSON.__SCAN_ */
/* WHERE T__Z1.SOURNAME = 'sourname0'
*/
INNER JOIN TABLE(COL VARCHAR='name0') I__Z0
/* function: COL = T__Z1.NAME */
ON 1=1
WHERE (T__Z1.SOURNAME = 'sourname0')
AND (T__Z1.NAME = I__Z0.COL)



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

Re: IGNITE-3999 review

[Amir Akhmedov]

Dmitry,

TeamCity RunAll completed but the results look awkward. Almost all test
suites marked as failed. I noticed the same behavior for other builds
though.
If you don't mind could you please check is it alright and let me know?

https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_RunAll&buildId=1150589&branch_IgniteTests24Java8_RunAll=pull/3444/head

Thanks,
Amir

[jira] [Created] (IGNITE-8008) Web console: Add a link to the SQL documentation in Notebook title

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8008:
--

 Summary: Web console: Add a link to the SQL documentation in 
Notebook title
 Key: IGNITE-8008
 URL: https://issues.apache.org/jira/browse/IGNITE-8008
 Project: Ignite
  Issue Type: Improvement
Reporter: Pavel Konstantinov


Add a link to the documentation in Notebook title
https://apacheignite-sql.readme.io/docs/sql-reference-overview



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

Re: Move documentation from readme.io to GitHub pages

[Dmitriy Setrakyan]

On Wed, Mar 21, 2018 at 9:27 PM, Prachi Garg  wrote:

> We can store the project (Markdown & Docusaurus config files) in Git, use
> Docusaurus to build html, and upload them to Ignite website.
>

Sounds good!

[GitHub] ignite pull request #3676: IGNITE-8005: Added example

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3677: IGNITE-8007 We should treat as empty any partitio...

[EdShangGG]

GitHub user EdShangGG opened a pull request:

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

IGNITE-8007 We should treat as empty any partition as empty if it doe…

…sn't have any data

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

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

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

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


commit 5ba8a4d29bf7c8420abff2c7323622bbefdfca2f
Author: Eduard Shangareev 
Date:   2018-03-21T23:36:17Z

IGNITE-8007 We should treat as empty any partition as empty if it doesn't 
have any data




---

[jira] [Created] (IGNITE-8007) We should treat as empty any partition as empty if it doesn't have any data

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-8007:
-

 Summary: We should treat as empty any partition as empty if it 
doesn't have any data
 Key: IGNITE-8007
 URL: https://issues.apache.org/jira/browse/IGNITE-8007
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Reporter: Eduard Shangareev
Assignee: Eduard Shangareev
 Fix For: 2.5


GridCacheOffheapManager#addPartition
Now we take into account was lastIndex = 0 or not, but it doesn't matter. 
Partition doesn't have any data, so it's empty.




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

Subject: new committer: Dmitry Pavlov

[Denis Magda]

The Project Management Committee (PMC) for Apache Ignite
has invited Dmitry Pavlov to become a committer and we are pleased
to announce that he has accepted.

Dmitriy is an active member of the Apache Ignite community. He is an author
of the great 'Make TeamCity Green Again' initiative [1] which already
improved tests stability a lot. Also, he implemented an option to use
direct IO to reduce page buffer cache overuse [2] and thoroughly
investigated the process of page replacement mechanism and identified a
major issue with Ignite page mapping table [3].

Moreover, Dmitriy is the author of Ignite memory and persistence under the
hood series [4] and [5], partition map exchange guide [6] and many other
documentation pages.

Being a committer enables easier contribution to the
project since there is no need to go via the patch
submission process. This should enable better productivity.
Being a PMC member enables assistance with the management
and to guide the direction of the project.

[1] https://cwiki.apache.org/confluence/display/IGNITE/
Make+Teamcity+Green+Again
[2] https://issues.apache.org/jira/browse/IGNITE-6341
[3] https://issues.apache.org/jira/browse/IGNITE-7638
[4]
https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood
[5]
https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Durable+Memory+-+under+the+hood
[6]
https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood

--
Denis

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

[Denis Magda]

Dmitriy,

Thanks for updating the WAL section. Now it makes total sense to me.

As for the page with JNA projects, let's get added there! Could you contact
the owners?

--
Denis


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

> Denis,
>
> one more thing, can/should we mention Ignite Direct IO plugin in list of
> project using JNA here: https://github.com/java-native-access/jna
>
> Sincerely,
> Dmitriy Pavlov
>
> ср, 21 мар. 2018 г. в 1:59, 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 <
>> raymond_wil...@trimble.com>
>> 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-6827 - Review needed.

[Pavel Tupitsyn]

Hi Alexei,

>  Pavel Tupitsyn, could you lend a hand to help completing .NET part (two
new
public API methods are added as a part of working on [3], java code in
branch [2])

Please file a separate ticket for .NET changes.
I would like to help, but maybe some time later. No need to delay your
changes because of that.

Thanks,
Pavel

On Wed, Mar 21, 2018 at 1:08 PM, Dmitry Pavlov 
wrote:

> Hi Alexei ,
>
> Thank you for contribution, unfortunately there is too much tests failed
> there:
> .NET is broken
>
>   Ignite Platform .NET Long Running [ tests 3 ]
> CachePartitionedNearEnabledTest.TestTransactionScopeMultiCache(True)
> CachePartitionedTest.TestTransactionScopeMultiCache(True)
> CacheReplicatedTest.TestTransactionScopeMultiCache(True)
>
>Ignite Platform .NET Core Linux [ tests 2 TC_EXIT_CODE ]
>  TransactionsParityTest.TestTransactions (fail rate 0,0%)
>  CachePartitionedTest.TestTransactionScopeMultiCache(True) (fail rate
> 0,0%)
>
>Ignite Platform .NET [ tests 1 ] agoncharuk More info >>
> Test fail rate less than 1%, probably new failure  exe:
> TransactionsParityTest.TestTransactions (fail rate 0,0%)
>
> Too much timeouts:
>Ignite Cache Failover [2]
>  with CacheAsyncOperationsFailoverTxTest.testPutAllAsyncFailover (last
> started)
>
>~[Obsolete] Ignite Cache Expiry Policy [ tests 1 ]
> with  IgniteCacheExpiryPolicyTestSuite:
> IgniteCacheTtlCleanupSelfTest.testDeferredDeleteTtl
>
>  Ignite Cache Restarts [2]
>   with
> GridCachePutAllFailoverSelfTest.testPutAllFailoverNearDisabledThreeBackups
> (last started)
>
>   Ignite Cache Restarts [1]
>with
> GridCachePartitionedNearDisabledOptimisticTxNodeRestartTest.
> testRestartWithTxTenNodesTwoBackups
> (last started)
>
>  Cache [6]
>with  WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator
> (last started)
> it is not all.
>
> Please fix tests before review. Also you could change ticket status to 'In
> Progress'.
>
> As easy option, you can merge current master to your branch, it is probably
> that some test were fixed already.
>
> Sincerely,
> Dmitriy Pavlov
>
> ср, 21 мар. 2018 г. в 9:58, Alexei Scherbakov <
> alexey.scherbak...@gmail.com
> >:
>
> > Igniters,
> >
> > I prepared rather important patch [1] related to grid stability and need
> a
> > review and some help to finish it.
> >
> > Semyon Boikov, could you please take a look on patch code ? [2]
> >
> > Pavel Tupitsyn, could you lend a hand to help completing .NET part (two
> new
> > public API methods are added as a part of working on [3], java code in
> > branch [2])
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-6827
> >
> > [2] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2
> >
> > [3] https://issues.apache.org/jira/browse/IGNITE-7910
> >
> > --
> >
> > Best regards,
> > Alexei Scherbakov
> >
>

Re: readme.io weird interface element

[Prachi Garg]

Thanks Petr. I'll look into it.

On Wed, Mar 21, 2018 at 12:44 AM, Petr Ivanov  wrote:

> Filed https://issues.apache.org/jira/browse/IGNITE-8003
>
>
>
> > On 20 Mar 2018, at 21:14, Prachi Garg  wrote:
> >
> > 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/
> 
> >>
> >>
> >
> 
> >>
> >>
>
>

Re: Apache Ignite nightly release builds

[Dmitry Pavlov]

Hi Raymond,

You could sign up using valid email address. Please write to @dev list if
link still is not available.

Sincerely,
Dmitriy Pavlov

ср, 21 мар. 2018 г. в 22:34, Raymond Wilson :

> The link to build artifacts requires a Team City login. Is there a public
> access location?
>
>
>
> *From:* Petr Ivanov [mailto:mr.wei...@gmail.com]
> *Sent:* Wednesday, March 21, 2018 10:59 PM
> *To:* dev ; u...@ignite.apache.org
> *Subject:* Re: Apache Ignite nightly release builds
>
>
>
> OK, I guess I can present renewed Apache Ignite Nightly Releases.
>
>
>
> Link to artifacts of the latest successful build:
> https://ci.ignite.apache.org/viewLog.html?buildId=lastSuccessful&buildTypeId=Releases_NightlyRelease_RunApacheIgniteNightlyRelease&tab=artifacts
>
> REST API link to the same (for programmatic access):
> https://ci.ignite.apache.org/app/rest/builds/buildType:(id:Releases_NightlyRelease_RunApacheIgniteNightlyRelease),status:SUCCESS/artifacts
>
> Link to changes of the latest successful build:
> https://ci.ignite.apache.org/viewLog.html?buildId=lastSuccessful&buildTypeId=Releases_NightlyRelease_RunApacheIgniteNightlyRelease&tab=buildChangesDiv
>
>
>
> Some disclaimers:
>
> * currently TeamCity will be used as storage for artifacts;
>
> * artifacts will be stored for 2 weeks;
>
> * nightly release builds are for DEVELOPMENT or TEST purposes only — use
> at your own risk (especially on production environment);
>
> * build configuration is still more or less experimental, final tuning
> will be introduced after some usage.
>
>
>
> Enjoy!
>
>
>
>
>
> As always — questions and feedback are more then welcome.
>
>
>
>
>
>
>
> On 20 Mar 2018, at 15:03, Petr Ivanov  wrote:
>
>
>
> 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/
>
>
>
>
>
>
>

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

[Denis Magda]

+1 for the fix of LOG_ONLY

On Wed, Mar 21, 2018 at 11:23 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> +1 for fixing LOG_ONLY to enforce corruption safety given the provided
> performance results.
>
> 2018-03-21 18:20 GMT+03:00 Vladimir Ozerov :
>
> > +1 for accepting drop in LOG_ONLY. 7% is not that much and not a drop at
> > all, provided that we fixing a bug. I.e. should we implement it correctly
> > in the first place we would never notice any "drop".
> > I do not understand why someone would like to use current broken mode.
> >
> > On Wed, Mar 21, 2018 at 6:11 PM, Dmitry Pavlov 
> > wrote:
> >
> > > Hi, I think option 1 is better. As Val said any mode that allows
> > corruption
> > > does not make much sense.
> > >
> > > What Ivan mentioned here as drop, in relation to old mode DEFAULT
> (FSYNC
> > > now), is still significant perfromance boost.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > ср, 21 мар. 2018 г. в 17:56, Ivan Rakov :
> > >
> > > > I've attached benchmark results to the JIRA ticket.
> > > > We observe ~7% drop in "fair" LOG_ONLY_SAFE mode, independent of WAL
> > > > compaction enabled flag. It's pretty significant drop: WAL compaction
> > > > itself gives only ~3% drop.
> > > >
> > > > I see two options here:
> > > > 1) Change LOG_ONLY behavior. That implies that we'll be ready to
> > release
> > > > AI 2.5 with 7% drop.
> > > > 2) Introduce LOG_ONLY_SAFE, make it default, add release note to AI
> 2.5
> > > > that we added power loss durability in default mode, but user may
> > > > fallback to previous LOG_ONLY in order to retain performance.
> > > >
> > > > Thoughts?
> > > >
> > > > Best Regards,
> > > > Ivan Rakov
> > > >
> > > > On 20.03.2018 16:00, Ivan Rakov wrote:
> > > > > 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 <
> ivan.glu...@gmail.com>
> > > > >> 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 <
> > ivan.glu...@gmail.com
> > > >
> > > >  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

[Raymond Wilson]

The link to build artifacts requires a Team City login. Is there a public
access location?



*From:* Petr Ivanov [mailto:mr.wei...@gmail.com]
*Sent:* Wednesday, March 21, 2018 10:59 PM
*To:* dev ; u...@ignite.apache.org
*Subject:* Re: Apache Ignite nightly release builds



OK, I guess I can present renewed Apache Ignite Nightly Releases.



Link to artifacts of the latest successful build:
https://ci.ignite.apache.org/viewLog.html?buildId=lastSuccessful&buildTypeId=Releases_NightlyRelease_RunApacheIgniteNightlyRelease&tab=artifacts

REST API link to the same (for programmatic access):
https://ci.ignite.apache.org/app/rest/builds/buildType:(id:Releases_NightlyRelease_RunApacheIgniteNightlyRelease),status:SUCCESS/artifacts

Link to changes of the latest successful build:
https://ci.ignite.apache.org/viewLog.html?buildId=lastSuccessful&buildTypeId=Releases_NightlyRelease_RunApacheIgniteNightlyRelease&tab=buildChangesDiv



Some disclaimers:

* currently TeamCity will be used as storage for artifacts;

* artifacts will be stored for 2 weeks;

* nightly release builds are for DEVELOPMENT or TEST purposes only — use at
your own risk (especially on production environment);

* build configuration is still more or less experimental, final tuning will
be introduced after some usage.



Enjoy!





As always — questions and feedback are more then welcome.







On 20 Mar 2018, at 15:03, Petr Ivanov  wrote:



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/

Re: IGNITE-3999 review

[Amir Akhmedov]

Dmitry,

Since the last TC test run has been done almost 2 months ago I decided to
run it again since lot of changes were introduced.
I will let you know when tests are finished.

Thanks,
Amir

[GitHub] ignite pull request #3676: IGNITE-8005: Added example

[zaleslaw]

GitHub user zaleslaw opened a pull request:

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

IGNITE-8005: Added example

Fixed a few points in other SVM files

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

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

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

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


commit 4f6e36ed42037cd9af167715bfb2a66f69d5b67f
Author: Zinoviev Alexey 
Date:   2018-03-21T18:28:54Z

IGNITE-8005: Added example




---

Re: Move documentation from readme.io to GitHub pages

[Prachi Garg]

We can store the project (Markdown & Docusaurus config files) in Git, use
Docusaurus to build html, and upload them to Ignite website.

On Tue, Mar 20, 2018 at 10:29 PM, Dmitriy Setrakyan 
wrote:

> Does docusaurus work with GitHub only, or with Git in general? In Apache
> GitHub is used as a mirror of an internal Git repo, which is the primary
> source of data.
>
> D.
>

Re: IGNITE-3999 review

[Dmitry Pavlov]

Hi Amir,

Thank you for your contribution.

Could you share link to Teamcity run all?

Sincerely
Dmitry Pavlov

ср, 21 мар. 2018 г., 21:23 Amir Akhmedov :

> Hi Team,
>
> Can anybody review https://github.com/apache/ignite/pull/3444 please?
>
> Thanks,
> Amir
>

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

[Alexey Goncharuk]

+1 for fixing LOG_ONLY to enforce corruption safety given the provided
performance results.

2018-03-21 18:20 GMT+03:00 Vladimir Ozerov :

> +1 for accepting drop in LOG_ONLY. 7% is not that much and not a drop at
> all, provided that we fixing a bug. I.e. should we implement it correctly
> in the first place we would never notice any "drop".
> I do not understand why someone would like to use current broken mode.
>
> On Wed, Mar 21, 2018 at 6:11 PM, Dmitry Pavlov 
> wrote:
>
> > Hi, I think option 1 is better. As Val said any mode that allows
> corruption
> > does not make much sense.
> >
> > What Ivan mentioned here as drop, in relation to old mode DEFAULT (FSYNC
> > now), is still significant perfromance boost.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > ср, 21 мар. 2018 г. в 17:56, Ivan Rakov :
> >
> > > I've attached benchmark results to the JIRA ticket.
> > > We observe ~7% drop in "fair" LOG_ONLY_SAFE mode, independent of WAL
> > > compaction enabled flag. It's pretty significant drop: WAL compaction
> > > itself gives only ~3% drop.
> > >
> > > I see two options here:
> > > 1) Change LOG_ONLY behavior. That implies that we'll be ready to
> release
> > > AI 2.5 with 7% drop.
> > > 2) Introduce LOG_ONLY_SAFE, make it default, add release note to AI 2.5
> > > that we added power loss durability in default mode, but user may
> > > fallback to previous LOG_ONLY in order to retain performance.
> > >
> > > Thoughts?
> > >
> > > Best Regards,
> > > Ivan Rakov
> > >
> > > On 20.03.2018 16:00, Ivan Rakov wrote:
> > > > 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 <
> ivan.glu...@gmail.com
> > >
> > >  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.
> > > 
> > > >
> > > >
> > >
> > >
> >
>

IGNITE-3999 review

[Amir Akhmedov]

Hi Team,

Can anybody review https://github.com/apache/ignite/pull/3444 please?

Thanks,
Amir

Re: Exploiting GP GPUs in Ignite ML

[Andrey Kuznetsov]

Yes, as one of possible options.

ср, 21 марта 2018, 20:53 Igor Rudyak :

> You mean utilizing JCuda for CPU bound ML tasks?
>
> Igor
>
> On Wed, Mar 21, 2018 at 10:45 AM, Andrey Kuznetsov 
> wrote:
>
> > Hi, Igniters!
> >
> > Machine Learning algorithms consume much computational resources. So I'm
> > curious whether it's possible to exploit General Purpose GPUs in Ignite?
> > Did somebody think about this?
> >
> > --
> > Best regards,
> >   Andrey Kuznetsov.
> >
>

Re: Exploiting GP GPUs in Ignite ML

[Igor Rudyak]

You mean utilizing JCuda for CPU bound ML tasks?

Igor

On Wed, Mar 21, 2018 at 10:45 AM, Andrey Kuznetsov 
wrote:

> Hi, Igniters!
>
> Machine Learning algorithms consume much computational resources. So I'm
> curious whether it's possible to exploit General Purpose GPUs in Ignite?
> Did somebody think about this?
>
> --
> Best regards,
>   Andrey Kuznetsov.
>

Exploiting GP GPUs in Ignite ML

[Andrey Kuznetsov]

Hi, Igniters!

Machine Learning algorithms consume much computational resources. So I'm
curious whether it's possible to exploit General Purpose GPUs in Ignite?
Did somebody think about this?

-- 
Best regards,
  Andrey Kuznetsov.

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

[andrey-kuznetsov]

GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-7983: NPE fix.



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

$ git pull https://github.com/andrey-kuznetsov/ignite ignite-7983

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

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


commit 82d48683511936af3c075198d586b1d2e92b90f0
Author: Andrey Kuznetsov 
Date:   2018-03-21T17:34:21Z

IGNITE-7983: NPE fix.




---

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

[Dmitry Pavlov]

Hi Nikolai, will you have time to merge this change?

вт, 20 мар. 2018 г. в 11:52, 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 <
>> dpavlov@gmail.com>:
>> > >
>> > > > 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&branch_IgniteTests24Java8=pull%2F3542%2Fhead
>> > > >> <
>> > > >>
>> > >
>> >
>> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=pull%2F3542%2Fhead
>> > > >> >*
>> > > >>
>> > > >>
>> > > >> вт, 27 февр. 2018 г. в 16:41, Dmitry Pavlov <
>> dpavlov@gmail.com>:
>> > > >>
>> > > >> > Hi Maxim,
>> > > >> >
>> > > >> > could you please provide link to TC run on

Re: Nodes which started in separate JVM couldn't stop properly (in tests)

[Dmitry Pavlov]

Hi Nickolay,

it seems we have lazy consesus here.

Failures:  tests 11 suites 1, all these tests are failed in master.

Could you merge?

Sincerely,
Dmitriy Pavlov

пт, 16 мар. 2018 г. в 18:29, Nikolay Izhikov :

> Hello, Guys.
>
> I'm reviewed changes and it looks good to me.
> There is a simple reproducer for a bug in test framework, see below.
>
> It fails in master and works in branch.
>
> I'm planning to merge the fix [1] if Run All will be OK.
>
> Please, write to me if you have any objections.
>
> [1] https://github.com/apache/ignite/pull/2382
>
> ```
> public class MultiJvmSelfTest extends GridCommonAbstractTest {
> @Override protected boolean isMultiJvm() { return true; }
>
> public void testGrid() throws Exception {
> final IgniteInternalFuture fut = GridTestUtils.runAsync(new
> RunnableX() {
> @Override public void runx() throws Exception {
> try {
> startGrid(0);
> startGrid(1);
> }
> finally {
> stopGrid(1);
> stopGrid(0);
> }
> }
> });
>
> try {
> fut.get(20_000L);
> } finally {
> stopAllGrids(true);
> }
> }
> }
> ```
>
> В Чт, 15/03/2018 в 15:59 +, Dmitry Pavlov пишет:
> > I see now. Thank you.
> >
> > Nikolay, could you please merge this change?
> >
> > чт, 15 мар. 2018 г. в 18:48, Vyacheslav Daradur :
> >
> > > In brief:
> > > Nodes in *separate* JVMs are shutting down by the computing task
> > > *StopGridTask* which has sent from *local* JVM *synchronously* that
> > > means *local* node must wait for task's finish.
> > >
> > > At the same time when a node in *separate* JVM executes the received
> > > *StopGridTask* which *synchronously* calls *G.stop(igniteInstanceName,
> > > FALSE)* which is waiting for all computing task's finish, including
> > > *StopGridTask* which has invoked it.
> > >
> > > We have some kind of deadlock:
> > > *Local* node is waiting for the computing task's finish which is
> > > waiting for finish of execution *G.stop* which is waiting for all
> > > computing tasks finish including *StopGridTask*.
> > >
> > > We have not noticed that before because we use only stopAllGrids() in
> > > out tests which stop local JVM without waiting for nodes in other
> > > JVMs.
> > >
> > >
> > >
> > > On Thu, Mar 15, 2018 at 6:11 PM, Dmitry Pavlov 
> > > wrote:
> > > > Please address comments in PR.
> > > >
> > > > I did not fully understood why sync GridStopMessage message was
> lost, but
> > > > async will be successfull. Probably we need discuss it briefly.
> > > >
> > > > чт, 1 мар. 2018 г. в 12:11, Vyacheslav Daradur  >:
> > > > >
> > > > > Thank you, Dmitry!
> > > > >
> > > > > I'll join this review soon.
> > > > >
> > > > > On Thu, Mar 1, 2018 at 12:07 PM, Dmitry Pavlov <
> dpavlov@gmail.com>
> > > > > wrote:
> > > > > > Hi Vyacheslav,
> > > > > >
> > > > > > I will take a look, but first of all I am going to review
> > > > > > https://reviews.ignite.apache.org/ignite/review/IGNT-CR-502  -
> it is
> > > > > > impact
> > > > > > change in testing framework. Hope you also will join to this
> review .
> > > > > >
> > > > > > Sincerely,
> > > > > > Dmitiry Pavlov
> > > > > >
> > > > > >
> > > > > > чт, 1 мар. 2018 г. в 11:13, Vyacheslav Daradur <
> daradu...@gmail.com>:
> > > > > > >
> > > > > > > Hi, Dmitry, could you please review it, because you are one of
> the
> > > > > > > most experienced people in the testing framework.
> > > > > > >
> > > > > > > Please see comment in Jira, because it is in pretty-format
> there.
> > > > > > >
> > > > > > > On Thu, Feb 22, 2018 at 11:56 AM, Vyacheslav Daradur
> > > > > > >  wrote:
> > > > > > > > Hi Igniters!
> > > > > > > >
> > > > > > > > I have investigated the issue [1] and found that stopping
> node in
> > > > > > > > separate JVM may stuck thread or leave system process alive
> after
> > > > > > > > test
> > > > > > > > finished.
> > > > > > > > The main reason is *StopGridTask* that we send from node in
> local
> > >
> > > JVM
> > > > > > > > to node in separate JVM via remote computing.
> > > > > > > > We send job synchronously to be sure that node will be
> stopped, but
> > > > > > > > job calls synchronously *G.stop(igniteInstanceName,
> cancel))* with
> > > > > > > > *cancel = false*, that means node must wait to compute jobs
> before
> > >
> > > it
> > > > > > > > goes down what leads to some kind of deadlock. Using of
> *cancel =
> > > > > > > > true* would solve the issue but may break some tests’ logic,
> for
> > >
> > > this
> > > > > > > > reason, I've reworked the method’s synchronization logic [2].
> > > > > > > >
> > > > > > > > We have not noticed that before because we use only
> > >
> > > *stopAllGrids()*
> > > > > > > > in out tests which stop local JVM without waiting for nodes
> in
> > >
> > > other
> > > > > > > > JVMs.
> > > > > > > > I believe this fix should r

[GitHub] ignite pull request #3674: IGNITE-7682: CPP: Fixed constant for the LocalSiz...

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-7682: CPP: Fixed constant for the LocalSize operation.



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

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

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

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


commit 7887bc506bbf6dde7ff1eb798bdd30f3f389675b
Author: Igor Sapego 
Date:   2018-03-21T17:07:21Z

IGNITE-7682: Fixed constant for the LocalSize operation




---

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

[Dmitry Pavlov]

Denis,

one more thing, can/should we mention Ignite Direct IO plugin in list of
project using JNA here: https://github.com/java-native-access/jna

Sincerely,
Dmitriy Pavlov

ср, 21 мар. 2018 г. в 1:59, 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 <
> raymond_wil...@trimble.com>
> 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

[Dmitry Pavlov]

Hi Igniters,

I've updated page with more detailed info about WAL and NativeIO, added
references to system properties.

Denis, thank you for noticing unclear section.

Sincerely,
Dmitriy Pavlov

ср, 21 мар. 2018 г. в 2:18, 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 <
> raymond_wil...@trimble.com>
> 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
> > >
> >
>

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

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3673: IGNITE-7990 Integrate MLP with partition based da...

[dmitrievanthony]

GitHub user dmitrievanthony opened a pull request:

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

IGNITE-7990 Integrate MLP with partition based dataset



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

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

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

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


commit 66d20fffe238aee76865a27b915f5dd894586fa6
Author: Anton Dmitriev 
Date:   2018-03-21T09:53:53Z

IGNITE-7990 Update simple labeled dataset to support multiple labels and
add first version of MLPTrainer based on partition based dataset.

commit 1350541d4d4386093d633dcb26ee5ca40b5edccf
Author: Anton Dmitriev 
Date:   2018-03-21T15:17:30Z

IGNITE-7990 Make updaters and their parameters serializable.

commit 562d2b48f737c56e5c1ca0c23c6f46c456ef37dc
Author: Anton Dmitriev 
Date:   2018-03-21T15:21:06Z

Merge remote-tracking branch 'origin/master' into ignite-7990

# Conflicts:
#   
modules/ml/src/main/java/org/apache/ignite/ml/svm/SVMLinearBinaryClassificationTrainer.java
#   
modules/ml/src/main/java/org/apache/ignite/ml/svm/SVMPartitionDataBuilderOnHeap.java
#   
modules/ml/src/test/java/org/apache/ignite/ml/svm/SVMBinaryTrainerTest.java

commit 50c8fa0a7fc261d31f9ff59d0fdb8c077bdf3e90
Author: Anton Dmitriev 
Date:   2018-03-21T15:41:59Z

IGNITE-7990 Move MLPTrainer to another package.




---

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

[Vladimir Ozerov]

+1 for accepting drop in LOG_ONLY. 7% is not that much and not a drop at
all, provided that we fixing a bug. I.e. should we implement it correctly
in the first place we would never notice any "drop".
I do not understand why someone would like to use current broken mode.

On Wed, Mar 21, 2018 at 6:11 PM, Dmitry Pavlov 
wrote:

> Hi, I think option 1 is better. As Val said any mode that allows corruption
> does not make much sense.
>
> What Ivan mentioned here as drop, in relation to old mode DEFAULT (FSYNC
> now), is still significant perfromance boost.
>
> Sincerely,
> Dmitriy Pavlov
>
> ср, 21 мар. 2018 г. в 17:56, Ivan Rakov :
>
> > I've attached benchmark results to the JIRA ticket.
> > We observe ~7% drop in "fair" LOG_ONLY_SAFE mode, independent of WAL
> > compaction enabled flag. It's pretty significant drop: WAL compaction
> > itself gives only ~3% drop.
> >
> > I see two options here:
> > 1) Change LOG_ONLY behavior. That implies that we'll be ready to release
> > AI 2.5 with 7% drop.
> > 2) Introduce LOG_ONLY_SAFE, make it default, add release note to AI 2.5
> > that we added power loss durability in default mode, but user may
> > fallback to previous LOG_ONLY in order to retain performance.
> >
> > Thoughts?
> >
> > Best Regards,
> > Ivan Rakov
> >
> > On 20.03.2018 16:00, Ivan Rakov wrote:
> > > 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: Reconsider default WAL mode: we need something between LOG_ONLY and FSYNC

[Dmitry Pavlov]

Hi, I think option 1 is better. As Val said any mode that allows corruption
does not make much sense.

What Ivan mentioned here as drop, in relation to old mode DEFAULT (FSYNC
now), is still significant perfromance boost.

Sincerely,
Dmitriy Pavlov

ср, 21 мар. 2018 г. в 17:56, Ivan Rakov :

> I've attached benchmark results to the JIRA ticket.
> We observe ~7% drop in "fair" LOG_ONLY_SAFE mode, independent of WAL
> compaction enabled flag. It's pretty significant drop: WAL compaction
> itself gives only ~3% drop.
>
> I see two options here:
> 1) Change LOG_ONLY behavior. That implies that we'll be ready to release
> AI 2.5 with 7% drop.
> 2) Introduce LOG_ONLY_SAFE, make it default, add release note to AI 2.5
> that we added power loss durability in default mode, but user may
> fallback to previous LOG_ONLY in order to retain performance.
>
> Thoughts?
>
> Best Regards,
> Ivan Rakov
>
> On 20.03.2018 16:00, Ivan Rakov wrote:
> > 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: Reconsider default WAL mode: we need something between LOG_ONLY and FSYNC

[Ivan Rakov]

I've attached benchmark results to the JIRA ticket.
We observe ~7% drop in "fair" LOG_ONLY_SAFE mode, independent of WAL 
compaction enabled flag. It's pretty significant drop: WAL compaction 
itself gives only ~3% drop.


I see two options here:
1) Change LOG_ONLY behavior. That implies that we'll be ready to release 
AI 2.5 with 7% drop.
2) Introduce LOG_ONLY_SAFE, make it default, add release note to AI 2.5 
that we added power loss durability in default mode, but user may 
fallback to previous LOG_ONLY in order to retain performance.


Thoughts?

Best Regards,
Ivan Rakov

On 20.03.2018 16:00, Ivan Rakov wrote:

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.

[GitHub] ignite pull request #3672: IGNITE-6113 Backport to 2.4.4

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-6113 Backport to 2.4.4



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

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

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

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


commit 4925ffc10ce8e8287980eaec38b587512568a302
Author: Alexey Goncharuk 
Date:   2018-01-17T12:26:03Z

IGNITE-7453 Use GridUnsafe.cleanDirectBuffer in PageSnapshot

commit bcd68a058683b2f17b7ac60471b6e7aab3e4f6de
Author: Pavel Tupitsyn 
Date:   2018-01-17T12:38:20Z

IGNITE-7301 .NET: Baseline topology

This closes #3352

commit 66b96316a7775ce8a6e2ff4475185d5929e4998b
Author: devozerov 
Date:   2018-01-17T12:54:17Z

Merge branch 'master' into ignite-2.4

commit 268481c1cf7fe57df24be130eb67c3e3a13afe01
Author: Alexey Goncharuk 
Date:   2018-01-17T13:50:34Z

IGNITE-7453 Use GridUnsafe.cleanDirectBuffer in WalStat

commit db0cd105719c8ae713b13b34d9dca0a8cd45d377
Author: Pavel Tupitsyn 
Date:   2018-01-17T14:05:25Z

IGNITE-6776 .NET: Thin client: Add SQL & LINQ example

This closes #3390

commit c214db879101aa5660e2a50b11cd20964c0bc114
Author: Andrey Gura 
Date:   2018-01-17T12:42:41Z

ignite-7450 FileWriteAheadLogManager always uses RandomAccessFileIOFactory 
now

commit 75c27d5e49d7458e46eb46e6f87a445c3f1320ea
Author: Alexey Kuznetsov 
Date:   2018-01-18T02:25:19Z

IGNITE-7274 Web Console: Support multiple statements on Queries screen.
(cherry picked from commit 1926783)

commit 36cc822935387b2150e690c29bc6992dca0563f7
Author: Dmitriy Shabalin 
Date:   2018-01-18T04:49:08Z

IGNITE-7306 Web Console: Fixed export data from tables.
(cherry picked from commit 1bb60ec)

commit d753298b4012894b56f5c9218325211cd84a21d5
Author: Peter Ivanov 
Date:   2018-01-18T06:18:53Z

IGNITE-7107 Apache Ignite RPM packages

* added changelog to package specification

This closes #3396

commit 63445893f1bc75dc9777184499f7eabc1d4e51b1
Author: Denis Mekhanikov 
Date:   2018-01-18T08:36:18Z

IGNITE-3935 Use PeerDeployAware for streamer transformer - Fixes #3378.

Signed-off-by: Alexey Goncharuk 

commit f3f9f2a24b23027cf0c835140322e41a788932ae
Author: Pavel Tupitsyn 
Date:   2018-01-18T09:05:12Z

IGNITE-7413 Fix SqlDmlExample

This closes #3389

commit 1daa7c41bf1460a4d9a2b0c26a7a317f2fca3fb7
Author: Alexey Kuznetsov 
Date:   2018-01-18T10:14:53Z

IGNITE-7461 UI tools: Actualized data storage configuration.
(cherry picked from commit 577e632)

commit cf0080210d24d9dd8b057f959446fac5f8a4ca01
Author: dpavlov 
Date:   2018-01-18T10:53:29Z

IGNITE-7380 Implemented pluggable Direct IO - Fixes #3226.

Signed-off-by: Alexey Goncharuk 

commit dd06d0bd7ef266bfbe156e858b312d1ac86e8982
Author: Pavel Tupitsyn 
Date:   2018-01-18T12:55:49Z

IGNITE-7465 .NET: Fix SqlDdlExample failure with standalone node

commit 57479ec564e1761716da3d5f9feb7a64c396a9f9
Author: Pavel Tupitsyn 
Date:   2018-01-18T13:45:54Z

.NET: Fix CacheLocalTest.TestTxDeadlockDetection

commit bd6be8a4653322905a3b63850c7e033ce3801ce5
Author: Pavel Tupitsyn 
Date:   2018-01-18T18:25:05Z

.NET: Thin client: Fix OP_BINARY_TYPE_GET schema passing format

commit 97564d160586d6d57d300937e6b8877994e35fc7
Author: rkondakov 
Date:   2018-01-19T08:24:51Z

IGNITE-6456: Ability to separately enable or disable JDBC, ODBC and thin 
client endpoints. This closes #3309.

commit d50274ca8875c9680c12e8786ac355a787ba95e0
Author: Yakov Zhdanov 
Date:   2018-01-18T17:57:17Z

Javadoc enhancements - added @see

commit cb2d3cf22388ab19fb2d34ae5bdfc8f1b608db75
Author: Dmitriy Govorukhin 
Date:   2018-01-18T14:14:26Z

IGNITE-7471 Use soft reference for checkpoint entry contents to avoid 
excessive memory usage

commit 3965923369870bb4e8e57e3332c1a1eb1e5f5ed3
Author: rkondakov 
Date:   2018-01-19T09:00:55Z

IGNITE-6772: SQL exception messages became more informative. This closes 
#3342.

commit ba68cb0fa87f776fcd0499d030c333f182611f41
Author: devozerov 
Date:   2018-01-19T09:03:52Z

Merge remote-tracking branch 'origin/ignite-2.4' into ignite-2.4

commit b54c0c8786bd74aa0abb208f537c29f0c4be4b1e
Author: tledkov-gridgain 
Date:   2018-01-19T09:09:34Z

IGNITE-7248: JDBC: fixed schema resolution for streaming mode. This closes 
#3384.

commit 2f5997788ccff265a088921210f561985f640517
Author: Dmitriy Govorukhin 
Date:   2018-01-19T11:46:38Z

IGNITE-7471 fix npe

commit 7adce10750704cc50cbf54fa7020aa3b20da87cb
Author: Oleg Ignatenko 
Date:   2018-01-19T11:59:01Z

IGNITE-7454 Wrong package in IgniteExamplesMLTestSuite

this closes #3393

(cherry picked from commit cb1233a)

commit 25e9

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

[Jokser]

Github user Jokser closed the pull request at:

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


---

[GitHub] ignite pull request #3671: IGNITE-7852: Supported username/password authenti...

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-7852: Supported username/password authentication for ODBC



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

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

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

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


commit 0ce6c54db47fb16c48a21bbb3543cc89ca0a9da7
Author: Igor Sapego 
Date:   2018-03-19T16:04:37Z

IGNITE-7852: Implemented server-side auth for ODBC

commit 7bceaefd269f902302ed25fcc86d1ad5739c9b72
Author: Igor Sapego 
Date:   2018-03-20T09:55:16Z

IGNITE-7852: ODBC connection string attributes added.

commit 8877272881607ebb021438c852cd052cd1bcb291
Author: Igor Sapego 
Date:   2018-03-20T14:12:22Z

IGNITE-7852: Added user and password to DSN UI

commit 5b1f56127287a6f967b4de4ee4eaceae676fa6f2
Author: Igor Sapego 
Date:   2018-03-20T14:45:07Z

IGNITE-7852: Added login and pass to handshake message

commit e53901550f42526ec79a3c5915996b5690cc6684
Author: Igor Sapego 
Date:   2018-03-21T13:36:31Z

IGNITE-7852: Added tests for ODBC

commit 73544cc8445677871ddaef4fe11353d530e0b39d
Author: Igor Sapego 
Date:   2018-03-21T14:02:41Z

IGNITE-7852: Fixed test for ODBC




---

[GitHub] ignite pull request #3670: Separate cache for non-collocated IgniteSet (TC r...

[xtern]

GitHub user xtern opened a pull request:

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

Separate cache for non-collocated IgniteSet (TC run)



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

$ git pull https://github.com/xtern/ignite IGNITE-7823

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

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


commit 2bbdff2aea3f33afd2a021d8a2328bbe403bda56
Author: pereslegin-pa 
Date:   2018-03-14T07:57:27Z

IGNITE-7823 wip

commit ddd8374a0eeed988a1f39b9b4f166545917edfbd
Author: pereslegin-pa 
Date:   2018-03-15T07:41:21Z

IGNITE-7823 wip igniteset -> set.

commit 73aa1084be484012832e65b02b5497a870d04b89
Author: pereslegin-pa 
Date:   2018-03-15T13:28:17Z

IGNITE-7823 replicated test

commit fa455e3af1ff6514050e6b67fc9e63d6c0eebfda
Author: pereslegin-pa 
Date:   2018-03-21T11:24:13Z

IGNITE-7823 Use separate cache for non-collocated IgniteSet (don't create 
IgniteSet#asSet API)




---

[GitHub] ignite pull request #3669: Ignite-2.3.3.b2

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

Ignite-2.3.3.b2

for test purposes

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

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

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

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


commit be91bbf8bcb7e9c71fe6d3bea0f79763f9606558
Author: Krzysztof Chmielewski 
Date:   2017-10-10T14:50:59Z

Fixed "IGNITE-6234 Initialize schemaIds to empty set if schemas field is 
null during the deserialization".

Signed-off-by: nikolay_tikhonov 

commit 08389601728512dc4e7fa5b953f5afe34ae4506f
Author: AMRepo 
Date:   2017-10-10T08:57:20Z

IGNITE-6545: Failure during Ignite Service.cancel() can break normal 
shutdown process. This closes #2807.

(cherry picked from commit 8ffa109)

commit 57547b5afae059a0a6dfa13c08b2e0b6c0e96ebd
Author: devozerov 
Date:   2017-10-13T09:34:35Z

Merge branch 'ignite-2.3.1' into ignite-2.3.2

commit 08798f8e47bdfdd68a557385ed2ce98b4bb1609a
Author: devozerov 
Date:   2017-10-13T11:12:44Z

IGNITE-6605: SQL: common backup filter. This closes #2836.

commit 2b59a241de3935a338842b8fc3221aedc8e11e1d
Author: devozerov 
Date:   2017-10-16T07:33:36Z

IGNITE-6631: Minor improvements to GridH2KeyValueRowOnheap. This closes 
#2855.

commit 98438c954c5f9a08634cf3132361268456397864
Author: devozerov 
Date:   2017-10-16T09:38:54Z

IGNITE-6632: SQL: simplified GridH2Row inheritance tree. This closes #2856.

commit 95b7ab518dd3c3db6fcc5142c2ee85da2516c2b6
Author: devozerov 
Date:   2017-10-16T10:37:11Z

IGNITE-6634: Removed IgniteDistributedJoinTestSuite. It's tests are 
distributed between "Query" and "Query 2" suites. This closes #2857.

commit 9c91deff877ebc0eed84559d4abca71408e3cb0a
Author: devozerov 
Date:   2017-10-16T13:46:13Z

Merge branch 'ignite-2.3.1' into ignite-2.3.2

commit 911ab7ab7a8a6968d219b053adb2338477738506
Author: Alexey Popov 
Date:   2017-10-17T11:45:42Z

IGNITE-6627 .NET: Fix serialization of enums within generic collections

* Fix EnumEqualityComparer serialization
* Fix enum arrays serialization
* Fix empty objects missing metadata

This closes #2864

commit 3ba374c319ac7048a05871692060e2f143d6acdf
Author: Alexey Kuznetsov 
Date:   2017-10-06T17:11:37Z

IGNITE-6463 Web Console: Fixed output of big numbers in SQL query results.
(cherry picked from commit 35589a7)

commit b67feb0f175bfbd6ffbefe82a8d693c8ab7d4213
Author: Vasiliy Sisko 
Date:   2017-10-09T10:55:23Z

IGNITE-5767 Web console: Use byte array type instead of java.lang.Object 
for binary JDBC types.
(cherry picked from commit 3184437)

commit 8e1560322b87d79b3d3250832a3969ac4032d6fc
Author: Alexey Kuznetsov 
Date:   2017-10-06T18:10:08Z

IGNITE-6574 Remove pending requests in case STATUS_AUTH_FAILURE && 
credentials == null.
(cherry picked from commit 85261a3)

commit 7a0300ae35894c389b126e95615f720a99a3d360
Author: devozerov 
Date:   2017-10-18T11:18:08Z

Merge branch 'ignite-2.3.1' into ignite-2.3.2

commit ad01f9b099d0bf92537378859ad6d5a52de57748
Author: Alexey Kuznetsov 
Date:   2017-10-19T02:43:20Z

IGNITE-6647 Web Console: Implemented support of schema migration scripts.
(cherry picked from commit c65399c)

commit 0c66344bc752dac98b256dd140fcab95d1662862
Author: Pavel Tupitsyn 
Date:   2017-10-19T09:36:39Z

IGNITE-6627 .NET: Fix repeated known metadata updates

This closes #2876

commit 1b8abd214ed2afcd3fd1f6a4c71a19d6fe1a4b01
Author: Alexey Kuznetsov 
Date:   2017-10-20T04:23:23Z

IGNITE-6647 Added missing Mongo injector.
(cherry picked from commit 173ecef)

commit a221066b3d029afc392be704a810c0e830fc0c49
Author: Alexey Kuznetsov 
Date:   2017-10-20T14:15:02Z

IGNITE-6647 Web Console: Added folder for modules migrations.
(cherry picked from commit 3700717)

commit da8a9d5a968ba071697a28adb01bc59f80d1893c
Author: Pavel Tupitsyn 
Date:   2017-10-23T08:55:33Z

Merge branch 'ignite-2.3.1' into ignite-2.3.2

# Conflicts:
#   
modules/platforms/dotnet/Apache.Ignite.Core.Tests/Apache.Ignite.Core.Tests.csproj

commit 69fdac3acf768ecb9df80d4412c4de5ffd5bc4f5
Author: Dmitriy Shabalin 
Date:   2017-10-23T09:09:47Z

IGNITE-5909 Added list editable component.
(cherry picked from commit 01daee6)

commit 4a2c38333c112d4956d6394667672c1470503435
Author: apopov 
Date:   2017-10-24T08:56:33Z

IGNITE-6362 NPE in Log4J2Logger

commit 089ebecb3e5962c7a38afd01bd18c77feb23d155
Author: vsisko 
Date:   2017-10-25T04:23:11Z

IGNITE-6671 Web Agent: Fixed data type conversion for Oracle NUMBER(N) data 
types.
(cherry picked from commit 93be8ea)

commit 1e56de86525a79c895eba2d839b7887b61979b07
Author: D

[jira] [Created] (IGNITE-8006) Starting multiple caches inhibits exchange process on joining node

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-8006:
-

 Summary: Starting multiple caches inhibits exchange process on 
joining node
 Key: IGNITE-8006
 URL: https://issues.apache.org/jira/browse/IGNITE-8006
 Project: Ignite
  Issue Type: Improvement
Reporter: Vladislav Pyatkov


In some cases when we starts multiple caches (over 2K caches), we can to got a 
stop on exchange when new node joining to the cluster.

Coordinator-node wait to receive a single message from all other nodes, but 
last node (which want to joining to the cluster) stopped on starting caches:

 

{noformat}

Stack trace
 at java.lang.Thread.dumpStack(Thread.java:1329)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1159)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1900)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1764)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:740)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:622)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2329)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
 at java.lang.Thread.run(Thread.java:745)

{noformat}

 

that inhibits cluster exchange process, until all caches started on the last 
node.

 

We should to start caches in parallel threads or exclude the action from 
exchange init process.



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

Re: welcome

[Alexey Goncharuk]

Andrei,

Welcome to the community! Added you to the contributors list.

2018-03-21 15:04 GMT+03:00 Andrei Aleksandrov :

> Hi Dmitry,
>
> This one is that I see in my profile:
>
> Username:
>aealeksandrov
>
> Full name:
>Andrey Aleksandrov
>
> Email:
>aealexsandrov at gmail dot com
>
>
> Best regards,
> Andrei Aleksandrov
>
> 21.03.2018 13:31, Dmitry Pavlov пишет:
>
> Hi Andrei,
>>
>> Thank you for your interest in Apache Ignite.
>>
>> Could we double-check you username? Is it  aealeksandrov ?
>>
>> Sincerely,
>> Dmitriy Pavlov
>>
>> ср, 21 мар. 2018 г. в 13:18, Andrei Aleksandrov > >:
>>
>> Hello Ignite Community!
>>>
>>> My name isAndrei. I want to contribute to Apache Ignite and want to
>>> start with this issue - IGNITE-7902but I can't assign it to me, my JIRA
>>> usernameaealeksandrov. Any help on this will be appreciated.
>>>
>>> Thanks!
>>>
>>>
>>>
>

[GitHub] ignite pull request #3339: IGNITE-7335: add test

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #1974: IGNITE-4892 Support DML for thin client based JDB...

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #2233: IGNITE-5679: add JDBC example

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #1294: IGNITE-4263 Hadoop: abstract out offheap/heap mem...

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #1026: IGNITE-3611 IGFS: Merge listPaths and listFiles o...

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #1159: IGNITE-4054 Add debug to trace HadoopMapReducePla...

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #1268: IGNITE-3640 IGFS: Local secondary: Investigate wh...

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #822: GG-11133 TTL should be tracked in off-heap page st...

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #987: IGNITE-3167 Hadoop: restore external execution.

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #1647: IGNITE-3018 Performance tuning of the Rendezvous ...

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #967: IGNITE-3694 IgfsLocalSecondaryFileSystemDualAsyncS...

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #1446: IGNITE-4580 Async API: IgniteCompute refactoring

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #969: IGNITE-3632 IGFS: Use task execution for PARTITION...

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #1460: IGNITE-4582 Async API: IgniteFileSystem refactori...

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #1452: IGNITE-4581: Async API: IgniteCache refactoring

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #1462: IGNITE-4583 Async API: Other components refactori...

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #1485: IGNITE-4584 Async API: Tests refactoring to use n...

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #3668: IGNITE-6711 DataRegionMetrics#totalAllocatedPages...

[alamar]

GitHub user alamar opened a pull request:

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

 IGNITE-6711 DataRegionMetrics#totalAllocatedPages is not valid after PDS 
restart



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

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

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

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


commit be91bbf8bcb7e9c71fe6d3bea0f79763f9606558
Author: Krzysztof Chmielewski 
Date:   2017-10-10T14:50:59Z

Fixed "IGNITE-6234 Initialize schemaIds to empty set if schemas field is 
null during the deserialization".

Signed-off-by: nikolay_tikhonov 

commit 08389601728512dc4e7fa5b953f5afe34ae4506f
Author: AMRepo 
Date:   2017-10-10T08:57:20Z

IGNITE-6545: Failure during Ignite Service.cancel() can break normal 
shutdown process. This closes #2807.

(cherry picked from commit 8ffa109)

commit 57547b5afae059a0a6dfa13c08b2e0b6c0e96ebd
Author: devozerov 
Date:   2017-10-13T09:34:35Z

Merge branch 'ignite-2.3.1' into ignite-2.3.2

commit 08798f8e47bdfdd68a557385ed2ce98b4bb1609a
Author: devozerov 
Date:   2017-10-13T11:12:44Z

IGNITE-6605: SQL: common backup filter. This closes #2836.

commit 2b59a241de3935a338842b8fc3221aedc8e11e1d
Author: devozerov 
Date:   2017-10-16T07:33:36Z

IGNITE-6631: Minor improvements to GridH2KeyValueRowOnheap. This closes 
#2855.

commit 98438c954c5f9a08634cf3132361268456397864
Author: devozerov 
Date:   2017-10-16T09:38:54Z

IGNITE-6632: SQL: simplified GridH2Row inheritance tree. This closes #2856.

commit 95b7ab518dd3c3db6fcc5142c2ee85da2516c2b6
Author: devozerov 
Date:   2017-10-16T10:37:11Z

IGNITE-6634: Removed IgniteDistributedJoinTestSuite. It's tests are 
distributed between "Query" and "Query 2" suites. This closes #2857.

commit 9c91deff877ebc0eed84559d4abca71408e3cb0a
Author: devozerov 
Date:   2017-10-16T13:46:13Z

Merge branch 'ignite-2.3.1' into ignite-2.3.2

commit 911ab7ab7a8a6968d219b053adb2338477738506
Author: Alexey Popov 
Date:   2017-10-17T11:45:42Z

IGNITE-6627 .NET: Fix serialization of enums within generic collections

* Fix EnumEqualityComparer serialization
* Fix enum arrays serialization
* Fix empty objects missing metadata

This closes #2864

commit 3ba374c319ac7048a05871692060e2f143d6acdf
Author: Alexey Kuznetsov 
Date:   2017-10-06T17:11:37Z

IGNITE-6463 Web Console: Fixed output of big numbers in SQL query results.
(cherry picked from commit 35589a7)

commit b67feb0f175bfbd6ffbefe82a8d693c8ab7d4213
Author: Vasiliy Sisko 
Date:   2017-10-09T10:55:23Z

IGNITE-5767 Web console: Use byte array type instead of java.lang.Object 
for binary JDBC types.
(cherry picked from commit 3184437)

commit 8e1560322b87d79b3d3250832a3969ac4032d6fc
Author: Alexey Kuznetsov 
Date:   2017-10-06T18:10:08Z

IGNITE-6574 Remove pending requests in case STATUS_AUTH_FAILURE && 
credentials == null.
(cherry picked from commit 85261a3)

commit 7a0300ae35894c389b126e95615f720a99a3d360
Author: devozerov 
Date:   2017-10-18T11:18:08Z

Merge branch 'ignite-2.3.1' into ignite-2.3.2

commit ad01f9b099d0bf92537378859ad6d5a52de57748
Author: Alexey Kuznetsov 
Date:   2017-10-19T02:43:20Z

IGNITE-6647 Web Console: Implemented support of schema migration scripts.
(cherry picked from commit c65399c)

commit 0c66344bc752dac98b256dd140fcab95d1662862
Author: Pavel Tupitsyn 
Date:   2017-10-19T09:36:39Z

IGNITE-6627 .NET: Fix repeated known metadata updates

This closes #2876

commit 1b8abd214ed2afcd3fd1f6a4c71a19d6fe1a4b01
Author: Alexey Kuznetsov 
Date:   2017-10-20T04:23:23Z

IGNITE-6647 Added missing Mongo injector.
(cherry picked from commit 173ecef)

commit a221066b3d029afc392be704a810c0e830fc0c49
Author: Alexey Kuznetsov 
Date:   2017-10-20T14:15:02Z

IGNITE-6647 Web Console: Added folder for modules migrations.
(cherry picked from commit 3700717)

commit da8a9d5a968ba071697a28adb01bc59f80d1893c
Author: Pavel Tupitsyn 
Date:   2017-10-23T08:55:33Z

Merge branch 'ignite-2.3.1' into ignite-2.3.2

# Conflicts:
#   
modules/platforms/dotnet/Apache.Ignite.Core.Tests/Apache.Ignite.Core.Tests.csproj

commit 69fdac3acf768ecb9df80d4412c4de5ffd5bc4f5
Author: Dmitriy Shabalin 
Date:   2017-10-23T09:09:47Z

IGNITE-5909 Added list editable component.
(cherry picked from commit 01daee6)

commit 4a2c38333c112d4956d6394667672c1470503435
Author: apopov 
Date:   2017-10-24T08:56:33Z

IGNITE-6362 NPE in Log4J2Logger

commit 089ebecb3e5962c7a38afd01bd18c77feb23d155
Author: vsisko 
Date:   2017-10-25T04:23:11Z

IGNITE-6671 Web Agent: Fixed data type conversion for Oracle NUMBER(N) data 
types.
(cherry picked from commit 93be8ea)

commit 1e56de

Re: welcome

[Andrei Aleksandrov]

Hi Dmitry,

This one is that I see in my profile:

Username:
   aealeksandrov

Full name:
   Andrey Aleksandrov

Email:
   aealexsandrov at gmail dot com


Best regards,
Andrei Aleksandrov

21.03.2018 13:31, Dmitry Pavlov пишет:

Hi Andrei,

Thank you for your interest in Apache Ignite.

Could we double-check you username? Is it  aealeksandrov ?

Sincerely,
Dmitriy Pavlov

ср, 21 мар. 2018 г. в 13:18, Andrei Aleksandrov :


Hello Ignite Community!

My name isAndrei. I want to contribute to Apache Ignite and want to
start with this issue - IGNITE-7902but I can't assign it to me, my JIRA
usernameaealeksandrov. Any help on this will be appreciated.

Thanks!

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

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8005:


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






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

[GitHub] ignite pull request #3667: Ignite 2.4.4

[ilantukh]

GitHub user ilantukh opened a pull request:

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

Ignite 2.4.4



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

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

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

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


commit 4925ffc10ce8e8287980eaec38b587512568a302
Author: Alexey Goncharuk 
Date:   2018-01-17T12:26:03Z

IGNITE-7453 Use GridUnsafe.cleanDirectBuffer in PageSnapshot

commit bcd68a058683b2f17b7ac60471b6e7aab3e4f6de
Author: Pavel Tupitsyn 
Date:   2018-01-17T12:38:20Z

IGNITE-7301 .NET: Baseline topology

This closes #3352

commit 66b96316a7775ce8a6e2ff4475185d5929e4998b
Author: devozerov 
Date:   2018-01-17T12:54:17Z

Merge branch 'master' into ignite-2.4

commit 268481c1cf7fe57df24be130eb67c3e3a13afe01
Author: Alexey Goncharuk 
Date:   2018-01-17T13:50:34Z

IGNITE-7453 Use GridUnsafe.cleanDirectBuffer in WalStat

commit db0cd105719c8ae713b13b34d9dca0a8cd45d377
Author: Pavel Tupitsyn 
Date:   2018-01-17T14:05:25Z

IGNITE-6776 .NET: Thin client: Add SQL & LINQ example

This closes #3390

commit c214db879101aa5660e2a50b11cd20964c0bc114
Author: Andrey Gura 
Date:   2018-01-17T12:42:41Z

ignite-7450 FileWriteAheadLogManager always uses RandomAccessFileIOFactory 
now

commit 75c27d5e49d7458e46eb46e6f87a445c3f1320ea
Author: Alexey Kuznetsov 
Date:   2018-01-18T02:25:19Z

IGNITE-7274 Web Console: Support multiple statements on Queries screen.
(cherry picked from commit 1926783)

commit 36cc822935387b2150e690c29bc6992dca0563f7
Author: Dmitriy Shabalin 
Date:   2018-01-18T04:49:08Z

IGNITE-7306 Web Console: Fixed export data from tables.
(cherry picked from commit 1bb60ec)

commit d753298b4012894b56f5c9218325211cd84a21d5
Author: Peter Ivanov 
Date:   2018-01-18T06:18:53Z

IGNITE-7107 Apache Ignite RPM packages

* added changelog to package specification

This closes #3396

commit 63445893f1bc75dc9777184499f7eabc1d4e51b1
Author: Denis Mekhanikov 
Date:   2018-01-18T08:36:18Z

IGNITE-3935 Use PeerDeployAware for streamer transformer - Fixes #3378.

Signed-off-by: Alexey Goncharuk 

commit f3f9f2a24b23027cf0c835140322e41a788932ae
Author: Pavel Tupitsyn 
Date:   2018-01-18T09:05:12Z

IGNITE-7413 Fix SqlDmlExample

This closes #3389

commit 1daa7c41bf1460a4d9a2b0c26a7a317f2fca3fb7
Author: Alexey Kuznetsov 
Date:   2018-01-18T10:14:53Z

IGNITE-7461 UI tools: Actualized data storage configuration.
(cherry picked from commit 577e632)

commit cf0080210d24d9dd8b057f959446fac5f8a4ca01
Author: dpavlov 
Date:   2018-01-18T10:53:29Z

IGNITE-7380 Implemented pluggable Direct IO - Fixes #3226.

Signed-off-by: Alexey Goncharuk 

commit dd06d0bd7ef266bfbe156e858b312d1ac86e8982
Author: Pavel Tupitsyn 
Date:   2018-01-18T12:55:49Z

IGNITE-7465 .NET: Fix SqlDdlExample failure with standalone node

commit 57479ec564e1761716da3d5f9feb7a64c396a9f9
Author: Pavel Tupitsyn 
Date:   2018-01-18T13:45:54Z

.NET: Fix CacheLocalTest.TestTxDeadlockDetection

commit bd6be8a4653322905a3b63850c7e033ce3801ce5
Author: Pavel Tupitsyn 
Date:   2018-01-18T18:25:05Z

.NET: Thin client: Fix OP_BINARY_TYPE_GET schema passing format

commit 97564d160586d6d57d300937e6b8877994e35fc7
Author: rkondakov 
Date:   2018-01-19T08:24:51Z

IGNITE-6456: Ability to separately enable or disable JDBC, ODBC and thin 
client endpoints. This closes #3309.

commit d50274ca8875c9680c12e8786ac355a787ba95e0
Author: Yakov Zhdanov 
Date:   2018-01-18T17:57:17Z

Javadoc enhancements - added @see

commit cb2d3cf22388ab19fb2d34ae5bdfc8f1b608db75
Author: Dmitriy Govorukhin 
Date:   2018-01-18T14:14:26Z

IGNITE-7471 Use soft reference for checkpoint entry contents to avoid 
excessive memory usage

commit 3965923369870bb4e8e57e3332c1a1eb1e5f5ed3
Author: rkondakov 
Date:   2018-01-19T09:00:55Z

IGNITE-6772: SQL exception messages became more informative. This closes 
#3342.

commit ba68cb0fa87f776fcd0499d030c333f182611f41
Author: devozerov 
Date:   2018-01-19T09:03:52Z

Merge remote-tracking branch 'origin/ignite-2.4' into ignite-2.4

commit b54c0c8786bd74aa0abb208f537c29f0c4be4b1e
Author: tledkov-gridgain 
Date:   2018-01-19T09:09:34Z

IGNITE-7248: JDBC: fixed schema resolution for streaming mode. This closes 
#3384.

commit 2f5997788ccff265a088921210f561985f640517
Author: Dmitriy Govorukhin 
Date:   2018-01-19T11:46:38Z

IGNITE-7471 fix npe

commit 7adce10750704cc50cbf54fa7020aa3b20da87cb
Author: Oleg Ignatenko 
Date:   2018-01-19T11:59:01Z

IGNITE-7454 Wrong package in IgniteExamplesMLTestSuite

this closes #3393

(cherry picked from commit cb1233a)

commit 25e91b60694c589d8bf50c63a0d8

Re: welcome

[Dmitry Pavlov]

Hi Andrei,

Thank you for your interest in Apache Ignite.

Could we double-check you username? Is it  aealeksandrov ?

Sincerely,
Dmitriy Pavlov

ср, 21 мар. 2018 г. в 13:18, Andrei Aleksandrov :

> Hello Ignite Community!
>
> My name isAndrei. I want to contribute to Apache Ignite and want to
> start with this issue - IGNITE-7902but I can't assign it to me, my JIRA
> usernameaealeksandrov. Any help on this will be appreciated.
>
> Thanks!
>
>

welcome

[Andrei Aleksandrov]

Hello Ignite Community!

My name isAndrei. I want to contribute to Apache Ignite and want to 
start with this issue - IGNITE-7902but I can't assign it to me, my JIRA 
usernameaealeksandrov. Any help on this will be appreciated.


Thanks!

Re: IGNITE-6827 - Review needed.

[Dmitry Pavlov]

Hi Alexei ,

Thank you for contribution, unfortunately there is too much tests failed
there:
.NET is broken

  Ignite Platform .NET Long Running [ tests 3 ]
CachePartitionedNearEnabledTest.TestTransactionScopeMultiCache(True)
CachePartitionedTest.TestTransactionScopeMultiCache(True)
CacheReplicatedTest.TestTransactionScopeMultiCache(True)

   Ignite Platform .NET Core Linux [ tests 2 TC_EXIT_CODE ]
 TransactionsParityTest.TestTransactions (fail rate 0,0%)
 CachePartitionedTest.TestTransactionScopeMultiCache(True) (fail rate
0,0%)

   Ignite Platform .NET [ tests 1 ] agoncharuk More info >>
Test fail rate less than 1%, probably new failure  exe:
TransactionsParityTest.TestTransactions (fail rate 0,0%)

Too much timeouts:
   Ignite Cache Failover [2]
 with CacheAsyncOperationsFailoverTxTest.testPutAllAsyncFailover (last
started)

   ~[Obsolete] Ignite Cache Expiry Policy [ tests 1 ]
with  IgniteCacheExpiryPolicyTestSuite:
IgniteCacheTtlCleanupSelfTest.testDeferredDeleteTtl

 Ignite Cache Restarts [2]
  with
GridCachePutAllFailoverSelfTest.testPutAllFailoverNearDisabledThreeBackups
(last started)

  Ignite Cache Restarts [1]
   with
GridCachePartitionedNearDisabledOptimisticTxNodeRestartTest.testRestartWithTxTenNodesTwoBackups
(last started)

 Cache [6]
   with  WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator
(last started)
it is not all.

Please fix tests before review. Also you could change ticket status to 'In
Progress'.

As easy option, you can merge current master to your branch, it is probably
that some test were fixed already.

Sincerely,
Dmitriy Pavlov

ср, 21 мар. 2018 г. в 9:58, Alexei Scherbakov :

> Igniters,
>
> I prepared rather important patch [1] related to grid stability and need a
> review and some help to finish it.
>
> Semyon Boikov, could you please take a look on patch code ? [2]
>
> Pavel Tupitsyn, could you lend a hand to help completing .NET part (two new
> public API methods are added as a part of working on [3], java code in
> branch [2])
>
> [1] https://issues.apache.org/jira/browse/IGNITE-6827
>
> [2] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2
>
> [3] https://issues.apache.org/jira/browse/IGNITE-7910
>
> --
>
> Best regards,
> Alexei Scherbakov
>

[GitHub] ignite pull request #3666: IGNITE-7712 Add flag IGNITE_SQL_LAZY_RESULT_SET f...

[alamar]

GitHub user alamar opened a pull request:

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

IGNITE-7712 Add flag IGNITE_SQL_LAZY_RESULT_SET for setting default

…value of SqlFieldsQuery.lazy

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

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

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

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


commit 1c6af228b122ebc3f8bac51266aa808c2dacf23b
Author: Ilya Kasnacheev 
Date:   2018-03-21T09:57:31Z

IGNITE-7712 Add flag IGNITE_SQL_LAZY_RESULT_SET for setting default value 
of SqlFieldsQuery.lazy




---

Re: Apache Ignite nightly release builds

[Petr Ivanov]

OK, I guess I can present renewed Apache Ignite Nightly Releases.

Link to artifacts of the latest successful build: 
https://ci.ignite.apache.org/viewLog.html?buildId=lastSuccessful&buildTypeId=Releases_NightlyRelease_RunApacheIgniteNightlyRelease&tab=artifacts
 

REST API link to the same (for programmatic access): 
https://ci.ignite.apache.org/app/rest/builds/buildType:(id:Releases_NightlyRelease_RunApacheIgniteNightlyRelease),status:SUCCESS/artifacts
 

Link to changes of the latest successful build: 
https://ci.ignite.apache.org/viewLog.html?buildId=lastSuccessful&buildTypeId=Releases_NightlyRelease_RunApacheIgniteNightlyRelease&tab=buildChangesDiv
 


Some disclaimers:
* currently TeamCity will be used as storage for artifacts;
* artifacts will be stored for 2 weeks;
* nightly release builds are for DEVELOPMENT or TEST purposes only — use at 
your own risk (especially on production environment);
* build configuration is still more or less experimental, final tuning will be 
introduced after some usage.

Enjoy!


As always — questions and feedback are more then welcome.



> On 20 Mar 2018, at 15:03, Petr Ivanov  wrote:
> 
> 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/
>>> 
>>> 
> 

Re: 2 phase waiting for partitions release

[Alexey Goncharuk]

For now, I think the two-phase await is the only option. After the fix is
prototyped we need to benchmark and check what is the impact of this change
on PME timing.

2018-03-20 18:09 GMT+03:00 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?
> >
>

[GitHub] ignite pull request #3665: ignite-8004 set compatibilityMode to true in coll...

[akalash]

GitHub user akalash opened a pull request:

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

ignite-8004 set compatibilityMode to true in collectGridNodeData



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

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

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

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


commit 4b993adeedcbe4b55d407d4a19b303cfd6e53032
Author: Anton Kalashnikov 
Date:   2018-03-21T08:35:31Z

ignite-8004 set compatibilityMode to true in collectGridNodeData




---

Re: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts

[Alexey Popov]

Hi Yakov, 

Do the proposed changes look good to you?

Thanks,
Alexey



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

[jira] [Created] (IGNITE-8004) Failed to find class BaselineTopology

[Anton Kalashnikov (JIRA)]

Anton Kalashnikov created IGNITE-8004:
-

 Summary: Failed to find class BaselineTopology
 Key: IGNITE-8004
 URL: https://issues.apache.org/jira/browse/IGNITE-8004
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov


Broken compatibility when old node joining to cluster of new nodes.

 

{noformat}


class org.apache.ignite.IgniteException: Failed to find class with given class 
loader for unmarshalling (make sure same versions of all classes are available 
on all nodes or enable peer-class-loading) 
[clsLdr=sun.misc.Launcher$AppClassLoader@659e0bfd, cls=Unknown pair 
[platformId=0, typeId=677944946]]

    at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:985)
    at 
org.apache.ignite.internal.cluster.IgniteClusterImpl.active(IgniteClusterImpl.java:315)
    at org.apache.ignite.internal.IgniteKernal.active(IgniteKernal.java:3462)
    at 
org.gridgain.grid.compatibility.tests.GridCompatibilitySnapshotOperationDifferentServersTest.start(GridCompatibilitySnapshotOperationDifferentServersTest.java:168)
    at 
org.gridgain.grid.compatibility.tests.GridCompatibilitySnapshotOperationDifferentServersTest.test(GridCompatibilitySnapshotOperationDifferentServersTest.java:86)
    at 
org.gridgain.grid.compatibility.tests.GridCompatibilitySnapshotOperationDifferentServersTest.testReverseOrderStart(GridCompatibilitySnapshotOperationDifferentServersTest.java:65)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at junit.framework.TestCase.runTest(TestCase.java:176)
    at 
org.gridgain.grid.compatibility.tests.GridCompatibilityAbstractTest.runTestInternal(GridCompatibilityAbstractTest.java:137)
    at 
org.gridgain.grid.compatibility.tests.GridCompatibilityAbstractTest.access$000(GridCompatibilityAbstractTest.java:41)
    at 
org.gridgain.grid.compatibility.tests.GridCompatibilityAbstractTest$2.run(GridCompatibilityAbstractTest.java:168)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to find class 
with given class loader for unmarshalling (make sure same versions of all 
classes are available on all nodes or enable peer-class-loading) 
[clsLdr=sun.misc.Launcher$AppClassLoader@659e0bfd, cls=Unknown pair 
[platformId=0, typeId=677944946]]
    at 
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller.unmarshal0(OptimizedMarshaller.java:230)
    at 
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
    at 
org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1775)
    at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1962)
    at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
    at 
org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1791)
    at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.readObject(BinaryReaderExImpl.java:1329)
    at 
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C4.readBinary(GridClosureProcessor.java:1959)
    at 
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:833)
    at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
    at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
    at 
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:307)
    at 
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
    at 
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
    at 
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9763)
    at 
org.apache.ignite.internal.processors.job.GridJobWorker.initialize(GridJobWorker.java:438)
    at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1109)
    at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1908)
    at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1562)
    at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1190)
    at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
    at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
    at 

[GitHub] ignite pull request #3664: IGNITE-7969 Fixed failure of failure of IgniteTop...

[alex-plekhanov]

GitHub user alex-plekhanov opened a pull request:

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

IGNITE-7969 Fixed failure of failure of 
IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup



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

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

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

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






---

Re: readme.io weird interface element

[Petr Ivanov]

Filed https://issues.apache.org/jira/browse/IGNITE-8003



> On 20 Mar 2018, at 21:14, Prachi Garg  wrote:
> 
> 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-8003) Dead documentation interface element

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-8003:


 Summary: Dead documentation interface element
 Key: IGNITE-8003
 URL: https://issues.apache.org/jira/browse/IGNITE-8003
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Affects Versions: 2.4
Reporter: Peter Ivanov
Assignee: Prachi Garg
 Attachments: Screen_Shot_2018_03_15_at_11_43_07.png

Most of the tables in lists of artifacts (for example on Downloads page) have 
strange interface element settling down to the right, which does nothing (see 
[^Screen_Shot_2018_03_15_at_11_43_07.png]).

I guess it should be either removed or fixed, whatever designation it has.



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