Re: Hello, Ignite Community

2018-11-09 Thread Denis Magda
Welcome, Albert! You are in, look forward to your contribution!

--
Denis

On Thu, Nov 8, 2018 at 10:39 PM Альберт Исхаков 
wrote:

> Hello, Ignite Community!
>
> My name is Albert Iskhakov. I want to contribute to Apache Ignite and want
> to start with this issue [1].
>
> JIRA username is aliskhakov.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-10184
>


Re: Service grid redesign

2018-11-09 Thread Denis Magda
Vyacheslav,

What are the cases when the service can be redeployed? Affinity, failure,
etc., right. It would be good to list all the cases on the wiki and then
our tech writers will get everything documented.

--
Denis

On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur 
wrote:

> Denis,
>
> Services reassignment process takes into account previous assignments
> to avoid redundant redeployments.
> So, in the described case, ServiceA won't be moved from node1 to node2.
> On Fri, Nov 9, 2018 at 4:41 AM Denis Magda  wrote:
> >
> > Vyacheslav,
> >
> > First of all, thanks for archiving this milestone and rolling out these
> new
> > capabilities.
> >
> > Speaking of the topology change events [1], does the new architecture
> avoid
> > a running service redeployment when a new node joins? For instance, let's
> > say I have ServiceA running node1, then node2 joins and I don't want the
> > service to be redeployed to any other node.
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> >
> > --
> > Denis
> >
> > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur 
> > wrote:
> >
> > > Dmitriy, I published documentation in wiki:
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > >
> > > Thank you!
> > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov 
> > > wrote:
> > > >
> > > > Hi I think wiki is better than any attached docs. Could you please
> > > create a
> > > > page?
> > > >
> > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur :
> > > >
> > > > > I prepared a description of the implemented solution and attached
> it
> > > > > to the issue [1].
> > > > >
> > > > > This should help during a review. Should I post the document into
> wiki
> > > or
> > > > > IEP?
> > > > >
> > > > > I'd like to ask Ignite's experts review the solution [1] [2],
> please?
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <
> > > daradu...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Hi, Igniters! Good news!
> > > > > >
> > > > > > Service Grid Redesign Phase 1 - is in Patch Available now.
> > > > > >
> > > > > > Nikolay Izhikov has reviewed implementation.
> > > > > >
> > > > > > However, we need additional review from other Ignite experts.
> > > > > >
> > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > >
> > > > > > Could someone step in and do the review?
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <
> > > dmekhani...@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > Pavel, could you assist?
> > > > > > >
> > > > > > > Does it make sense for .Net to specify service class name
> instead
> > > of
> > > > > its
> > > > > > > implementation?
> > > > > > >
> > > > > > > I think, it shouldn't be a problem.
> > > > > > >
> > > > > > > Denis
> > > > > > >
> > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <
> > > daradu...@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > I think that the replacement of serialized instance makes
> sense
> > > to me
> > > > > > > > for Java part.
> > > > > > > >
> > > > > > > > But how it should work for .NET client?
> > > > > > > >
> > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <
> > > > > dsetrak...@apache.org>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > > nsamelc...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hello, Igniters.
> > > > > > > > > >
> > > > > > > > > > I am working on task [1] that would replace serialized
> > > service's
> > > > > > > > instance
> > > > > > > > > > by service's class name and properties map in
> > > > > {ServiceConfiguration}.
> > > > > > > > > >
> > > > > > > > > > The task describes that we should use
> > > > > > > > > > {String className} + {Map properties}
> instead
> > > > > {Service
> > > > > > > > > > srvc}.
> > > > > > > > > >
> > > > > > > > > > I'd like to clarify the following questions:
> > > > > > > > > >
> > > > > > > > > > 1. What about public methods?
> > > > > > > > > > I suggest to mark them as deprecated and use class name
> of
> > > > > provided
> > > > > > > > > > instance.
> > > > > > > > > > Also to add deploying methods with new parameters:
> > > > > > > > > >
> > > > > > > > > > @Deprecated
> > > > > > > > > > public IgniteInternalFuture
> > > deployNodeSingleton(ClusterGroup
> > > > > prj,
> > > > > > > > > > String
> > > > > > > > > > name, Service svc)
> > > > > > > > > >
> > > > > > > > > > public IgniteInternalFuture
> > > deployNodeSingleton(ClusterGroup
> > > > > prj,
> > > > > > > > > > String
> > > > > > > > > > name, String srvcClsName, Map prop)

[GitHub] ignite pull request #5027: IGNITE-9843 If metadata is not available due to r...

2018-11-09 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[GitHub] ignite pull request #5359: IGNITE-10209 some tests in IgniteExamplesMLTestSu...

2018-11-09 Thread oignatenko
GitHub user oignatenko opened a pull request:

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

IGNITE-10209 some tests in IgniteExamplesMLTestSuite fail with 
FileNotFoundException



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

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

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

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


commit 1eeca908a8076a8317947dac8a46845964d1d7ea
Author: Oleg Ignatenko 
Date:   2018-08-23T13:13:28Z

IGNITE-9348 ML examples improvements
- wip (logging improved)
-- verified with diffs overview, executing the examples and studying 
execution logs

commit e50b89c392568ba9b93935c4fa6c7f7f93f5ec6f
Author: Oleg Ignatenko 
Date:   2018-08-23T14:45:57Z

Revert "IGNITE-9348 ML examples improvements"

This reverts commit 1eeca908a8076a8317947dac8a46845964d1d7ea.

commit 474024b4c5bbdb3c0a4ed2f0a66238c8054c6674
Author: Oleg Ignatenko 
Date:   2018-08-23T14:57:34Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit 9642b233b5701bdad47ebea163079160227c582a
Author: Oleg Ignatenko 
Date:   2018-08-28T14:01:11Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit 7fc16d013ab725d2ff2e1a1b042c983f11d0c4d4
Author: Oleg Ignatenko 
Date:   2018-08-28T15:13:02Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit d2caba67b156674f051f50faebeafe0871bf0914
Author: Oleg Ignatenko 
Date:   2018-08-29T13:14:07Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit 16775dff51d71ea68b4a3dea98be552130c493ed
Author: Oleg Ignatenko 
Date:   2018-08-30T09:00:56Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit aedb59929974fe205b949225c1a338c68c60cfc8
Author: Oleg Ignatenko 
Date:   2018-08-30T09:42:38Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit 39c6482fcdca506aa33011ed21c98060b4a8c68b
Author: Oleg Ignatenko 
Date:   2018-08-30T11:28:05Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit 33b32a2760a6559c78283b927e3191180d8ed9e1
Author: Oleg Ignatenko 
Date:   2018-08-30T12:31:16Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit 9531028ddd1aef9e95f7e8c8b528086739bbb1b0
Author: Oleg Ignatenko 
Date:   2018-08-30T14:06:34Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit 28f22c6e2fffcb82717ba5da7be2cfd39715c4e3
Author: Oleg Ignatenko 
Date:   2018-08-30T16:41:51Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit aacac88db519187413b0fc5ff9d0e55b8f8cff22
Author: Oleg Ignatenko 
Date:   2018-08-31T10:12:32Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit 897f920dde46022849b13f9fb86dba8e54119a56
Author: Oleg Ignatenko 
Date:   2018-08-31T13:57:14Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit 114c79e54c1b316006ccc3ff22d20d902f9313df
Author: Oleg Ignatenko 
Date:   2018-08-31T17:39:16Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit fd6b659bb8be1992618ce4ce91f568a0988b3afa
Author: Oleg Ignatenko 
Date:   2018-09-02T06:11:42Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit 6ae6d1d3cf9743d8d466be0330511ddc8589e944
Author: Oleg Ignatenko 
Date:   2018-09-03T10:27:35Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit e8b27dbd3d0c1cbdb7a7659175f5c7bb447482bf
Author: Oleg Ignatenko 
Date:   2018-09-04T09:49:44Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit 622c82efdd0aa182fadea6b7ffa5d4615521a3f5
Author: Oleg Ignatenko 
Date:   2018-09-05T10:50:28Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit fb844fe3751e2e8ae87e6b8030b0e4bd659df9c2
Author: Oleg Ignatenko 
Date:   2018-09-05T11:45:58Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit 480ed78869277d7e32f725ab71bec9621f1ac03a
Author: Oleg Ignatenko 
Date:   2018-09-06T07:52:55Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit c99762498f617c0e98ea3062a43c0b30092166ef
Author: Oleg Ignatenko 
Date:   2018-09-06T14:45:04Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit 2e17175225c72f747d370b5fee96f8be69d6d2cb
Author: Oleg Ignatenko 
Date:   2018-09-06T17:33:54Z

Merge branch 'master' of https://github.com/apache/ignite into master-ml

commit 9ebcd9a2fe5966b0bf42a95484395867c15d863f
Author: Oleg Ignatenko 
Date:   2018-09-07T13:38:51Z

Merge branch 

[GitHub] ignite pull request #5227: ignite-9970 Local hostname fix

2018-11-09 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[jira] [Created] (IGNITE-10210) SQL: jdbc thin connected to newly started client, misses "old" tables

2018-11-09 Thread Pavel Kuznetsov (JIRA)
Pavel Kuznetsov created IGNITE-10210:


 Summary: SQL: jdbc thin connected to newly started client, misses 
"old" tables
 Key: IGNITE-10210
 URL: https://issues.apache.org/jira/browse/IGNITE-10210
 Project: Ignite
  Issue Type: Bug
  Components: jdbc, sql
Affects Versions: 2.6
Reporter: Pavel Kuznetsov


Given cluster.
We are creating table using thin driver.
After that we are starting new client node and connecting to it.
Metadata of this new connection doesn't contain information about this table.

Affected all methods that use 
{{org.apache.ignite.internal.processors.query.GridQueryProcessor#types}} under 
the hood.
Such as:
1) getPrimaryKeys()
2) getColumns()
3) getSchemas() (if no tables are created getSchemas() returns empty list.)
4) getTables()
5) getIndexes()




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


Re: Is it time to move forward to JUnit4 (5)?

2018-11-09 Thread Павлухин Иван
Hi Oleg,

I can outline some motivating ideas. There is no agreed solutions yet,
but junit4 might help us in reusing existing tests for improving MVCC
coverage. Another area is managing RunAll execution time with help
of some kind of tests parameterization.

Regarding concrete tests changes from my experiment [1]. They were
changed in order to demonstrate certain capabilities in action.
1. CacheMvccDmlSimpleTest simply demonstrates that it is a valid
junit4 test. Test names without "test" prefix make it evident that tests
are run by junit4 engine.
2. IgniteCacheCommitDelayTxRecoveryTest shows how a pattern
common for our junit3 tests could be improved by junit4.

I did not have each test method renaming in mind (but I suppose we
cannot avoid marking each test with @Test annotation).

And I also have run RunAll after introducing changes in GridAbstractTest
[2].
There were several rebuilds because of problems found along the way. I will
return to it in order to receive good enough single RunAll result eligible
for
analysis by human.

[1] https://github.com/apache/ignite/pull/5354/files
[2]
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/5354/head=Latest


пт, 9 нояб. 2018 г. в 16:48, oignatenko :

> Hi Ivan,
>
> That's a very good question. I would say the primary motivation in the task
> we discuss is to make the change at the minimal cost and risk. Or, as
> stated
> in description of IGNITE-10173 "move... gradually, smoothly and safely".
>
> With this in mind I would say that main expected benefit is laid out at the
> top of ticket description:
> > Currently unit tests in the project are mix of two versions Junit 3 and
> 4.
> > This makes it hard to develop and maintain. Making all tests use the same
> > version Junit is intended to address this problem.
>
> Above goal is probably modest but given that this change is expected to
> take
> minimal effort it looks good enough for me.
>
> On a more general note I don't expect strong technical benefits of this
> change, at least not immediately. This is based on my studies of prior
> discussions related to this matter and of the existing tests. I believe
> that
> if there were any strong and obvious technical benefits we would be long
> aware of these and we would migrate to newer Junit long time ago.
>
> Observing that migration hasn't happened - despite JUnit 3 being obsolete
> for over 10 years now, and despite many more fundamental changes that
> successfully made it to Ignite in past years - it looks natural to assume
> that there are just no technical reasons that would be strong enough to
> justify investing much effort in the migration.
>
> ---
>
> Now about your experiment at ignite/pull/5354, I briefly skimmed it and
> here
> are some initial impressions.
>
> First the bad news, some parts look indeed "insane" to me. I am talking
> specifically about renames in CacheMvccDmlSimpleTest and changes to test
> design in IgniteCacheCommitDelayTxRecoveryTest. I believe that these are
> wildly out of scope of the discussed change because I firmly want to keep
> it
> limited to absolute minimum of changes (ideally only annotations with
> involved imports).
>
> This is because there are just too many tests to (manually) change. My
> rough
> estimate is there about 7,000 (seven thousands!) test cases to change in
> core module alone; and I guess there are few thousands more in other parts
> of the project. Doing any extra changes to these tests makes things much
> more complicated, effort consuming and risky than was initially supposed.
>
> On a brighter side, changes made to GridAbstractTest look worth further
> studying. At this point I still prefer to keep this class unchanged
> (because
> this gives us a bulletproof guarantee against regressions in all prior
> tests) but this may change after we do "pilot" changes to examples tests
> (IGNITE-10174).
>
> These pilot changes will help us estimate with concrete code how much
> effort
> could be involved in maintaining "twin" classes in sync (you are absolutely
> right pointing that this is concerning). If it turns out too complicated to
> sync we would probably switch to something like you have done in pull/5354
>
> regards, Oleg
>
>
> Павлухин Иван wrote
> > Hi Oleg,
> >
> > Migrating to Junit 4 sounds as great idea. I believe everybody
> > is quite surprised when finds Junit 3 in Ignite.
> > But for me personally it is good to understand what problem we
> > are trying to solve? What benefits will Junit 4 give us? What are
> > the most painful moments with current testing framework?
> > (I my mind I draw a proposal which contains sections "Motivation",
> > "Alternatives", etc.)
> >
> > Also I must say that I made some experiments related to Junit4
> > migration. And from the first glance it seems that the most
> > important Ignite test framework classes contain a huge amount of
> > utility methods and a little amount of code related to a test lifecycle.
> > These classes are 

[jira] [Created] (IGNITE-10209) some tests in IgniteExamplesMLTestSuite fail with FileNotFoundException at SandboxMLCache#fillCacheWith(MLSandboxDatasets)

2018-11-09 Thread Oleg Ignatenko (JIRA)
Oleg Ignatenko created IGNITE-10209:
---

 Summary: some tests in IgniteExamplesMLTestSuite fail with 
FileNotFoundException at SandboxMLCache#fillCacheWith(MLSandboxDatasets)
 Key: IGNITE-10209
 URL: https://issues.apache.org/jira/browse/IGNITE-10209
 Project: Ignite
  Issue Type: Bug
  Components: ml
Affects Versions: 2.8
Reporter: Oleg Ignatenko


Tests for examples that use {{SandboxMLCache#fillCacheWith(MLSandboxDatasets)}} 
fail with FNFE:
{noformat}
[ERROR] Tests run: 34, Failures: 0, Errors: 13, Skipped: 0, Time elapsed: 
638.752 s <<< FAILURE! - in 
org.apache.ignite.testsuites.IgniteExamplesMLTestSuite
[ERROR] 
testExample(org.apache.ignite.examples.ml.KMeansClusterizationExampleSelfName)  
Time elapsed: 21.701 s  <<< ERROR!
java.io.FileNotFoundException: 
examples\src\main\resources\datasets\two_classed_iris.csv (Системе не удается 
найти указанный путь)
at 
org.apache.ignite.examples.ml.KMeansClusterizationExampleSelfName.testExample(KMeansClusterizationExampleSelfName.java)

[ERROR] 
testExample(org.apache.ignite.examples.ml.KNNClassificationExampleSelfName)  
Time elapsed: 13.81 s  <<< ERROR!
java.io.FileNotFoundException: examples\src\main\resources\datasets\iris.txt 
(Системе не удается найти указанный путь)
at 
org.apache.ignite.examples.ml.KNNClassificationExampleSelfName.testExample(KNNClassificationExampleSelfName.java)

[ERROR] testExample(org.apache.ignite.examples.ml.KNNRegressionExampleSelfName) 
 Time elapsed: 13.633 s  <<< ERROR!
java.io.FileNotFoundException: 
examples\src\main\resources\datasets\cleared_machines.csv (Системе не удается 
найти указанный путь)
at 
org.apache.ignite.examples.ml.KNNRegressionExampleSelfName.testExample(KNNRegressionExampleSelfName.java)

[ERROR] 
testExample(org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerExampleSelfName)
  Time elapsed: 13.71 s  <<< ERROR!
java.io.FileNotFoundException: 
examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается 
найти указанный путь)
at 
org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerExampleSelfName.testExample(LinearRegressionLSQRTrainerExampleSelfName.java)

[ERROR] 
testExample(org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName)
  Time elapsed: 13.728 s  <<< ERROR!
java.io.FileNotFoundException: 
examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается 
найти указанный путь)
at 
org.apache.ignite.examples.ml.LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName.testExample(LinearRegressionLSQRTrainerWithMinMaxScalerExampleSelfName.java)

[ERROR] 
testExample(org.apache.ignite.examples.ml.LinearRegressionSGDTrainerExampleSelfName)
  Time elapsed: 13.874 s  <<< ERROR!
java.io.FileNotFoundException: 
examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается 
найти указанный путь)
at 
org.apache.ignite.examples.ml.LinearRegressionSGDTrainerExampleSelfName.testExample(LinearRegressionSGDTrainerExampleSelfName.java)

[ERROR] 
testExample(org.apache.ignite.examples.ml.LogisticRegressionSGDTrainerExampleSelfName)
  Time elapsed: 13.694 s  <<< ERROR!
java.io.FileNotFoundException: 
examples\src\main\resources\datasets\two_classed_iris.csv (Системе не удается 
найти указанный путь)
at 
org.apache.ignite.examples.ml.LogisticRegressionSGDTrainerExampleSelfName.testExample(LogisticRegressionSGDTrainerExampleSelfName.java)

[ERROR] 
testExample(org.apache.ignite.examples.ml.LogRegressionMultiClassClassificationExampleSelfName)
  Time elapsed: 13.823 s  <<< ERROR!
java.io.FileNotFoundException: 
examples\src\main\resources\datasets\glass_identification.csv (Системе не 
удается найти указанный путь)
at 
org.apache.ignite.examples.ml.LogRegressionMultiClassClassificationExampleSelfName.testExample(LogRegressionMultiClassClassificationExampleSelfName.java)

[ERROR] 
testExample(org.apache.ignite.examples.ml.TrainTestDatasetSplitterExampleSelfName)
  Time elapsed: 12.875 s  <<< ERROR!
java.io.FileNotFoundException: 
examples\src\main\resources\datasets\mortalitydata.csv (Системе не удается 
найти указанный путь)
at 
org.apache.ignite.examples.ml.TrainTestDatasetSplitterExampleSelfName.testExample(TrainTestDatasetSplitterExampleSelfName.java)

[ERROR] 
testExample(org.apache.ignite.examples.ml.SVMBinaryClassificationExampleSelfName)
  Time elapsed: 12.795 s  <<< ERROR!
java.io.FileNotFoundException: 
examples\src\main\resources\datasets\two_classed_iris.csv (Системе не удается 
найти указанный путь)
at 
org.apache.ignite.examples.ml.SVMBinaryClassificationExampleSelfName.testExample(SVMBinaryClassificationExampleSelfName.java)

[ERROR] 
testExample(org.apache.ignite.examples.ml.SVMMultiClassClassificationExampleSelfName)
  Time elapsed: 12.948 s  <<< ERROR!
java.io.FileNotFoundException: 

[GitHub] sergey-chugunov-1985 opened a new pull request #64: New Page for TC Bot: Long Running Tests Report

2018-11-09 Thread GitBox
sergey-chugunov-1985 opened a new pull request #64: New Page for TC Bot: Long 
Running Tests Report
URL: https://github.com/apache/ignite-teamcity-bot/pull/64
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Created] (IGNITE-10208) Verify list of tests after migration to Junit 4 against some prior reference (follow-up to IGNITE-10177)

2018-11-09 Thread Oleg Ignatenko (JIRA)
Oleg Ignatenko created IGNITE-10208:
---

 Summary: Verify list of tests after migration to Junit 4 against 
some prior reference  (follow-up to IGNITE-10177)
 Key: IGNITE-10208
 URL: https://issues.apache.org/jira/browse/IGNITE-10208
 Project: Ignite
  Issue Type: Sub-task
Reporter: Oleg Ignatenko


Migration from Junit 3 to 4 involves manually adding {{@Test}} annotation to 
existing test cases. Since Ignite contains many thousands test cases there is a 
substantial risk that we may miss some of these in such a transition.

In order to mitigate the risk, suggest to do a check after completion of 
IGNITE-10177 - somehow generate list of tests in the project and compare it 
against similar list of tests of some "known good" prior project version (at 
this point, 2.7 release branch looks like a good candidate for such a 
reference).

If comparison shows that some test cases from older version are missed in newer 
one, open a ticket to investigate that.



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


Re: Is it time to move forward to JUnit4 (5)?

2018-11-09 Thread oignatenko
Hi Ivan,

That's a very good question. I would say the primary motivation in the task
we discuss is to make the change at the minimal cost and risk. Or, as stated
in description of IGNITE-10173 "move... gradually, smoothly and safely".

With this in mind I would say that main expected benefit is laid out at the
top of ticket description:
> Currently unit tests in the project are mix of two versions Junit 3 and 4.
> This makes it hard to develop and maintain. Making all tests use the same
> version Junit is intended to address this problem.

Above goal is probably modest but given that this change is expected to take
minimal effort it looks good enough for me.

On a more general note I don't expect strong technical benefits of this
change, at least not immediately. This is based on my studies of prior
discussions related to this matter and of the existing tests. I believe that
if there were any strong and obvious technical benefits we would be long
aware of these and we would migrate to newer Junit long time ago.

Observing that migration hasn't happened - despite JUnit 3 being obsolete
for over 10 years now, and despite many more fundamental changes that
successfully made it to Ignite in past years - it looks natural to assume
that there are just no technical reasons that would be strong enough to
justify investing much effort in the migration.

---

Now about your experiment at ignite/pull/5354, I briefly skimmed it and here
are some initial impressions.

First the bad news, some parts look indeed "insane" to me. I am talking
specifically about renames in CacheMvccDmlSimpleTest and changes to test
design in IgniteCacheCommitDelayTxRecoveryTest. I believe that these are
wildly out of scope of the discussed change because I firmly want to keep it
limited to absolute minimum of changes (ideally only annotations with
involved imports).

This is because there are just too many tests to (manually) change. My rough
estimate is there about 7,000 (seven thousands!) test cases to change in
core module alone; and I guess there are few thousands more in other parts
of the project. Doing any extra changes to these tests makes things much
more complicated, effort consuming and risky than was initially supposed.

On a brighter side, changes made to GridAbstractTest look worth further
studying. At this point I still prefer to keep this class unchanged (because
this gives us a bulletproof guarantee against regressions in all prior
tests) but this may change after we do "pilot" changes to examples tests
(IGNITE-10174).

These pilot changes will help us estimate with concrete code how much effort
could be involved in maintaining "twin" classes in sync (you are absolutely
right pointing that this is concerning). If it turns out too complicated to
sync we would probably switch to something like you have done in pull/5354

regards, Oleg


Павлухин Иван wrote
> Hi Oleg,
> 
> Migrating to Junit 4 sounds as great idea. I believe everybody
> is quite surprised when finds Junit 3 in Ignite.
> But for me personally it is good to understand what problem we
> are trying to solve? What benefits will Junit 4 give us? What are
> the most painful moments with current testing framework?
> (I my mind I draw a proposal which contains sections "Motivation",
> "Alternatives", etc.)
> 
> Also I must say that I made some experiments related to Junit4
> migration. And from the first glance it seems that the most
> important Ignite test framework classes contain a huge amount of
> utility methods and a little amount of code related to a test lifecycle.
> These classes are GridAbstractTest and GridCommonAbstractTest.
> Both are quite thick, but as already said it is mostly utility code
> which could be extracted. I would be great to come to very thin base
> test classes (or even to baseclass-less tests at all) and include all
> kind of utilities without inheritance.
> 
> But massive refactoring perhaps is more for future. The main point
> here is that Ignite test framework is not complex at all and could be
> easily adopted to Junit 4.
> 
> Regarding twin classes. How to keep them in sync? If the migration
> process will be paused halfway it could make things complicated in
> future.
> 
> Additionally, I have a wild idea how to marry junit 3 and 4 without
> introducing twins. The idea looks ugly from OOP perspective, but
> here it is. We can simply annotate overridden Junit 3 setUp and
> tearDown methods with @Before and @After annotations. And
> use runTest overridden method for Junit 3 and TestRule for Junit 4
> in order to run test methods in newly started thread.
> 
> For all details you can see an experiment on github [1]. Among them
> are ticks with @RunWith annotation making possible to run a test
> inherited from TestCase as Junit 4 test. Still, I might have missed
> something.
> 
> Does it sound sane anyhow?
> 
> [1] https://github.com/apache/ignite/pull/5354/files
> 
> 
> ср, 7 нояб. 2018 г. в 19:57, oignatenko 

> oignatenko@

> :
> 
>> 

[jira] [Created] (IGNITE-10206) Allow specifying query parallelism in CREATE TABLE's WITH "" clause

2018-11-09 Thread Ilya Kasnacheev (JIRA)
Ilya Kasnacheev created IGNITE-10206:


 Summary: Allow specifying query parallelism in CREATE TABLE's WITH 
"" clause
 Key: IGNITE-10206
 URL: https://issues.apache.org/jira/browse/IGNITE-10206
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.6
Reporter: Ilya Kasnacheev


As in 
{code}
CREATE TABLE foo (id long primary key, val varchar) WITH "backups=1, 
query_parallelism=4";
{code}

Currently it is possible to specify e.g. backups but not query_parallelism.

This leads to necessity to specify cache template for such tables, which is 
cumbersome.
Moreover, people may ignore this option outright and get worse performance.



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


[jira] [Created] (IGNITE-10207) Missed loss policy checks

2018-11-09 Thread Dmitriy Govorukhin (JIRA)
Dmitriy Govorukhin created IGNITE-10207:
---

 Summary: Missed loss policy checks
 Key: IGNITE-10207
 URL: https://issues.apache.org/jira/browse/IGNITE-10207
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Govorukhin


In some cases (client reconnect, new client join, etc) PartitionLossPolicy may 
incorrectly validate operation. Return null for READ_ONLY_SAFE for loss 
partition.
To reproduce run CacheResultIsNotNullOnPartitionLossTest (1000 times
) with random node stop.



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


[GitHub] ignite pull request #5021: IGNITE-9930: Split Zookeeper Discovery 2 onto sev...

2018-11-09 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[GitHub] ignite pull request #5358: IGNITE-10073 Ignite NuGet package without embedde...

2018-11-09 Thread kukushal
GitHub user kukushal opened a pull request:

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

IGNITE-10073 Ignite NuGet package without embedded Ignite JARs



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

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

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

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


commit a9897350f415567caab29ef7514d74b2a5cd8e92
Author: Alexey Kukushkin 
Date:   2018-11-05T23:18:22Z

IGNITE-10073 Ignite NuGet package without embedded Ignite JARs




---


[GitHub] ignite pull request #5330: IGNITE-9870 GridDhtPartitionsFullMessage#prepareM...

2018-11-09 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[GitHub] ignite pull request #5013: IGNITE-9909 Extract file handle from WAL manager

2018-11-09 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[jira] [Created] (IGNITE-10205) add to utility command - ./control.sh --cache idle_verify --dump abbility to exclude cache from output file

2018-11-09 Thread ARomantsov (JIRA)
ARomantsov created IGNITE-10205:
---

 Summary: add to utility command -  ./control.sh --cache 
idle_verify --dump abbility to exclude cache from output file
 Key: IGNITE-10205
 URL: https://issues.apache.org/jira/browse/IGNITE-10205
 Project: Ignite
  Issue Type: Improvement
Reporter: ARomantsov






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


[GitHub] ignite pull request #5357: IGNITE-10167: MVCC-compatible IgniteCache.localEn...

2018-11-09 Thread pavlukhin
GitHub user pavlukhin opened a pull request:

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

IGNITE-10167: MVCC-compatible IgniteCache.localEntries



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

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

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

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


commit 0359a3ad885c869a6d492af23e84fa8507bac848
Author: ipavlukhin 
Date:   2018-11-02T15:32:56Z

mvcc-compatible peek draft

commit 514b793910a88ab4718829d1f77055f45740e349
Author: ipavlukhin 
Date:   2018-11-06T11:09:40Z

do "peek" operation similarly to SQL query (use mvcc tracker)

commit 751048bed4012be6608bb01fdc42a2ab58ef5395
Author: ipavlukhin 
Date:   2018-11-06T11:13:23Z

add todo

commit 067782a81e7851f3c84455fdfb281a537fd142a3
Author: ipavlukhin 
Date:   2018-11-06T11:28:25Z

Merge branch 'master' into mvcc-peek

commit 1b2a19969039c9a53da9de9b5802c7aa751a6a7c
Author: ipavlukhin 
Date:   2018-11-06T11:29:56Z

cleanup

commit c1f774ee78b46587cb42010782b8b435df640159
Author: ipavlukhin 
Date:   2018-11-06T14:02:45Z

use special MAX snapshot which can see all committed versions for mvccPeek

commit 1d46b4b20f49dd2cdacebc45b993b4972fe2c533
Author: ipavlukhin 
Date:   2018-11-06T17:45:33Z

tune MVCC_MAX_SNAPSHOT

commit 35b822e87b80ba428dec23d4068cead3ea306988
Author: ipavlukhin 
Date:   2018-11-06T17:47:30Z

dummy for a code style

commit c90c3f34c0b7b732f139024e24e42716c03e02ac
Author: ipavlukhin 
Date:   2018-11-07T06:28:20Z

move peek test to core module

commit e88d70910ef43f0c7803928d6732e0b6ea0bcaac
Author: ipavlukhin 
Date:   2018-11-07T06:31:17Z

remove test checking that peek is not supported for mvcc

commit 61b019bbf7a270d4f80b4acfeb9b1c113a9fbef4
Author: ipavlukhin 
Date:   2018-11-07T08:45:25Z

* call checkObsolete() in mvccPeek;
* javadoc for mvccPeek.

commit c4e2807c53ce545d46f6b0161eaa7c484487c600
Author: ipavlukhin 
Date:   2018-11-07T09:31:54Z

update IgniteCache.peek javadoc

commit 0db14098fe2e36cc74c1a0a35b0eefb4a709453d
Author: ipavlukhin 
Date:   2018-11-07T09:38:27Z

minor javadoc fix

commit 63e8de61963b10b3c71800275d0f44c8169550a6
Author: ipavlukhin 
Date:   2018-11-07T09:43:58Z

comments for special mvcc constants

commit b57533135cace90828caa1cea0d964e709876213
Author: ipavlukhin 
Date:   2018-11-07T10:03:35Z

rework MvccCachePeekTest to stop grid only once

commit 25653c9b255294268722e2e62dfeb422b6a8c21b
Author: ipavlukhin 
Date:   2018-11-07T10:41:20Z

Merge branch 'master' into mvcc-peek

commit edb496b9489615852d2c48960d79b4d8325e375a
Author: ipavlukhin 
Date:   2018-11-07T13:28:22Z

adopt existing peek tests and add them to MVCC suite

commit 16219757547e0fe14a96622ad9d53cce1c7ff331
Author: ipavlukhin 
Date:   2018-11-08T13:27:36Z

Merge branch 'master' into mvcc-peek

commit 977f13a2d39e0f4785e06ea4775d25a3e45ce264
Author: ipavlukhin 
Date:   2018-11-08T16:08:57Z

IgniteCache.localEntries draft

commit 5d71df8da19211aedc428bf96ea95eb2359b4789
Author: ipavlukhin 
Date:   2018-11-09T10:59:27Z

use MvccUtils.MVCC_MAX_SNAPSHOT for "localEntries" implementation

commit eea412024fcb58072c7ddfcc92a9e36ae28ac943
Author: ipavlukhin 
Date:   2018-11-09T11:03:29Z

minor




---


[GitHub] ignite pull request #5356: IGNITE-10196 Change scope of kafka-clients-*-test...

2018-11-09 Thread Max-Pudov
GitHub user Max-Pudov opened a pull request:

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

IGNITE-10196 Change scope of kafka-clients-*-test dependency to test



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

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

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

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


commit 0b6a30d71004b0746fe9290c606b10a26062d529
Author: Max-Pudov 
Date:   2018-11-09T11:19:05Z

IGNITE-10196 Change scope of kafka-clients-*-test dependency to test




---


[jira] [Created] (IGNITE-10204) Web Console: Rename "Allow non-collocated joins" checkbox

2018-11-09 Thread Vica Abramova (JIRA)
Vica Abramova created IGNITE-10204:
--

 Summary: Web Console: Rename "Allow non-collocated joins" checkbox
 Key: IGNITE-10204
 URL: https://issues.apache.org/jira/browse/IGNITE-10204
 Project: Ignite
  Issue Type: Improvement
  Components: UI, wizards
Reporter: Vica Abramova
Assignee: Alexey Kuznetsov


Rename checkbox "Allow non-collocated joins" => "Allow distributed joins"

In the Web Console's query tab, it says "Allow non-collocated joins".  I 
propose that this be renamed to "Allow distributed joins".  I say that because 
in your documentation it refers to it as distributed joins. Inconsistent naming 
caused some confusion to our development teams. Consistent naming can solve 
this.

https://apacheignite-sql.readme.io/docs/distributed-joins 

Attached is screenshot of what I get from google when  search for 
non-collocated joins which seems to suggests that distrbuted joins is the 
preferred terminology. 
https://www.google.com/search?q=GridGain+non-collocated+joins



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


[GitHub] ignite pull request #5316: IGNITE-10151 Fix BinaryMarshallerSelfTest#testDef...

2018-11-09 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[GitHub] ignite pull request #5056: IGNITE-9976

2018-11-09 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[GitHub] ignite pull request #4314: IGNITE-8619 Remote node could not start in ssh co...

2018-11-09 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[GitHub] ololo3000 opened a new pull request #63: IGNITE-10181 [Tc Bot] Add fail-rate handling for test's page

2018-11-09 Thread GitBox
ololo3000 opened a new pull request #63: IGNITE-10181 [Tc Bot] Add fail-rate 
handling for test's page
URL: https://github.com/apache/ignite-teamcity-bot/pull/63
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Created] (IGNITE-10203) [TC Bot] Support for alternative configurations for PR testing

2018-11-09 Thread Nikolai Kulagin (JIRA)
Nikolai Kulagin created IGNITE-10203:


 Summary: [TC Bot] Support for alternative configurations for PR 
testing
 Key: IGNITE-10203
 URL: https://issues.apache.org/jira/browse/IGNITE-10203
 Project: Ignite
  Issue Type: Task
Reporter: Nikolai Kulagin
Assignee: Nikolai Kulagin


Support for alternative configurations for PR testing (for example, 
IgniteTests24Java8_RunMl)



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


[GitHub] ignite pull request #5241: IGNITE-10128 Race in read\write cache configurati...

2018-11-09 Thread asfgit
Github user asfgit closed the pull request at:

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


---


Re: Is it time to move forward to JUnit4 (5)?

2018-11-09 Thread oignatenko
Hi Vyacheslav,

GridCommonAbstractTest is expected to change too.

As pointed in IGNITE-10173 our approach involves all the subclasses of
GridAbstractTest - including but not limited to one you mentioned
(GridCommonAbstractTest).

regards, Oleg




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


[jira] [Created] (IGNITE-10202) ML: Create a POC of TensorFlow model inference in Java

2018-11-09 Thread Anton Dmitriev (JIRA)
Anton Dmitriev created IGNITE-10202:
---

 Summary: ML: Create a POC of TensorFlow model inference in Java
 Key: IGNITE-10202
 URL: https://issues.apache.org/jira/browse/IGNITE-10202
 Project: Ignite
  Issue Type: Sub-task
  Components: ml
Affects Versions: 2.8
Reporter: Anton Dmitriev
Assignee: Anton Dmitriev
 Fix For: 2.8


TensorFlow models are represented internally as computation graphs that are 
saved as a Protobuf objects with some kind of metadata. TensorFlow provides a 
good API for Python that allows to work with them, but Java API is very poor.

TensorFlow allows to import computation graph in Java API and manipulate it 
using low-level API and it looks like a one way to make model inference in 
Java. Another way is based on the fact that the most popular way to build a 
TensorFlow model is using of the Keras API. It allows to save model in _.h5_ 
format that can be imported into Java using Deeplearning4J.

So, the goal of this task is to *prepare a POC that demonstrates*:
 * How to import TensorFlow model into Java and make inference using TensorFlow 
Java API.
 * How to import TensorFlow model into Java and make inference using 
Deeplearning4J.



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


[jira] [Created] (IGNITE-10201) ML: TensorFlow model inference on Apache Ignite

2018-11-09 Thread Anton Dmitriev (JIRA)
Anton Dmitriev created IGNITE-10201:
---

 Summary: ML: TensorFlow model inference on Apache Ignite
 Key: IGNITE-10201
 URL: https://issues.apache.org/jira/browse/IGNITE-10201
 Project: Ignite
  Issue Type: New Feature
  Components: ml
Affects Versions: 2.8
Reporter: Anton Dmitriev
Assignee: Anton Dmitriev
 Fix For: 2.8


Machine learning pipeline consists of two stages: *model training* and *model 
inference* _(model training is a process of training a model using existing 
data with known target values, model inference is a process of making 
predictions on a new data using trained model)._

It's important that a model can be trained in one environment/system and after 
that is used for inference in another. A trained model is an immutable object 
without any side-effects (a pure mathematical function in math language). As 
result of that, an inference process has an excellent linear scalability 
characteristics because different inferences can be done in parallel in 
different threads or on different nodes.

The goal of "TensorFlow model inference on Apache Ignite" is to allow user to 
easily import pre-trained TensorFlow model into Apache Ignite, distribute it 
across nodes in a cluster, provide a common interface to call these models to 
make inference and finally perform load balancing so that all node resources 
are properly utilized.



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