[jira] [Created] (IGNITE-10727) [ML] InfModel and Model merging

[Alexey Platonov (JIRA)]

Alexey Platonov created IGNITE-10727:


 Summary: [ML] InfModel and Model merging 
 Key: IGNITE-10727
 URL: https://issues.apache.org/jira/browse/IGNITE-10727
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Alexey Platonov
Assignee: Anton Dmitriev
 Fix For: 2.8


Currently "InfModel" and "Model" provide parallel architecture in terms of 
using of "InfModels" in after-learning steps like compositions, estimations 
etc. I propose to move "InfModel" to top of models hierarchy and rename it to 
just "Model" and current "Model" rename to 
"LearnedModel/LocalModel/Your_ad_may_be_here". So in this way "InfModel" will 
be just model with apply-function for generic I-O values and "Model" will be 
serializable thing on Vector-Double.



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

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

[Павлухин Иван]

Hi Oleg,

Now concerns about junit3 elimination are clear for me. And I agree
that it is worth to do it. By the way is it possible to access tests
which have problems running under junit4? I would like to take a look.

Also a clarifying bit regarding next migration steps is needed. Sorry
if it was described but I missed it. Currently we have tons of tests
which rely on our home brewed beforeTestsStarted, beforeTest,
afterTest, afterTestsStarted. Are you going to mark them all with
corresponding junit4 annotations?
пн, 17 дек. 2018 г. в 19:13, oignatenko :
>
> Hi Ivan,
>
> Per my cursory check of the code currently in master, we have 239 test
> classes that couldn't migrate (that's probably about 500 or something test
> cases). For comparison, over 1600 classes migrated without problems. This is
> to answer your questions about how many tests are affected by change and
> how many tests were not migrated yet.
>
> -
>
> I think we can say that only small percent of tests turned out sensitive to
> JUnit framework change.
>
> In the same time, due to very large overall amount of our tests we have
> quite a big number as an absolute value. I point this because if amount of
> troublesome tests was smaller (say, order of magnitude smaller) I would
> consider delaying migration until all tests reworked to blend totally
> seamlessly into new version JUnit. This is doable - as sort of "pilot
> exercise" me and Ed adjusted one test case this way - but the sheer amount
> of work on 200+ classes raises a question, whether it is worth it (I think
> it isn't).
>
> With regards to question 2, changes to TestCounters are farly trivial (and
> necessary) if you look at the code diff. Prior code counted amount of test
> cases in the class by JUnit 3 convention: it picked public void methods
> without parameters starting with "test". Changed code counts test cases as
> JUnit 4 does: by checking if method is annotated with @Test. Change is
> necessary because it will allow test developers fully use JUnit 4 features
> by adding test cases that don't follow old naming requirement. I
> experimented with it a little and as far as I could see the old TestCounters
> indeed break when there are methods following new convention, it triggered
> afterTestsStopped too early.
>
> The answer to your question 3 lies in javadocs I added to runSerializer
> declaration, or, more precisely, in TestCounters javadoc referred from
> there. As you can see, current plan is to get rid of TestCounters fairly
> soon (per IGNITE-10179) and this will also get rid of runSerializer so this
> is merely a temporary band aid to be removed soon.
>
> For the sake of completeness, my initial plan was to thoroughly investigate
> and test whether change from JUnit 3 to JUnit 4 would keep accessing
> counters safe or not and only introduce runSerializer if it really does but
> after realising that this whole thing is likely to go away in a few days
> from now I decided that it isn't worth wasting time and just temporarily
> made it the way that is waterproof guaranteed to be safe.
>
> -
>
> Now, to answer your question whether it is an option for us to keep part of
> tests under JUnit 3, my answer is most definitely no.
>
> Main reason is that having part of tests under JUnit 3 will deprive us
> ability to consistently use Ignore annotation and force us fallback to old
> way to fail the tests we want to ignore. This would kind of trash the whole
> purpose of migration because we won't be able to simplify and improve
> maintenance of ignored tests.
>
> Another important reason is that keeping JUnit 3 will much complicate our
> test framework code. We will have to implement and maintain two versions of
> TestCounters (see answer to your question #2 above). We will also have to
> keep the code that currently determines first/last test in the class and
> possibly even complicate it to account for two versions of the framework -
> compare that to current plan to simply get rid of all that code per
> IGNITE-10179.
>
> The last but not the least, this makes it much more complicated to later
> migrate to JUnit 5. Although this is currently not in the nearest plans
> (IGNITE-10180) we eventually will want to (especially taking into account
> that migration from JUnit 4 is said to be easy). Having JUnit 3 tests would
> much complicate this because we have no idea if JUnit 5 could interoperate
> with such an old version (and I see no reason why we would want to waste our
> time and efforts investigating and testing this).
>
> Summing up, I believe it is very well worth it for us to get rid of JUnit 3
> completely.
>
>  -
>
> With regards to making LegacySupport enabled only on purpose, at this point
> I see no reason to enforce this in code because I expect that deprecation
> notices will do that job.
>
> If a developer writing new test or reworking an old one follows the
> deprecation recommendations they will use JUnit 4 way instead of deprecated
> methods and 

Re: What is the best approach to extend Thin Client functionality?

[Denis Magda]

Hello Anton,

Is this for TensorFlow only or for ML algorithms Ignite supplies out of the
box? Also, do you need C++ for the training phase?

--
Denis

On Mon, Dec 17, 2018 at 2:02 AM dmitrievanth...@gmail.com <
dmitrievanth...@gmail.com> wrote:

> Currently ML/TensorFlow module requires an ability to expose some
> functionality to be used in C++ code.
>
> As far as I understand, currently Ignite provides an ability to work with
> it from C++ only through the Thin Client. The list of operations supported
> by it is very limited. What is the best approach to work with additional
> Ignite functionality (like ML/TensorFlow) from C++ code?
>
> I see several ways we can do it:
> 1. Extend list of Thin Client operations. Unfortunately, it will lead to
> overgrowth of API. As result of that it will be harder to implement and
> maintain Thin Clients for different languages.
> 2. Use Thin Client as a "transport layer" and make Ignite functionality
> calls via puts/gets commands/responses into/from cache (like command
> pattern). It's looks a bit confusing to use cache with put/get operations
> as a transport.
> 3. Add custom endpoint that will listen specific port and process custom
> commands. It will introduce a new endpoint and a new protocol.
>
> What do you think about these approaches? Could you suggest any other ways?
>
> To have more concrete discussion lets say we need to functions available
> from C++: "saveModel(name, model)", "getModel(name)" already implemented in
> Ignite ML and available via Java API.
>

[jira] [Created] (IGNITE-10726) Web console: error in console after configuration import

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-10726:
-

 Summary: Web console: error in console after configuration import
 Key: IGNITE-10726
 URL: https://issues.apache.org/jira/browse/IGNITE-10726
 Project: Ignite
  Issue Type: Bug
  Components: UI, wizards
Reporter: Ilya Borisov
Assignee: Vasiliy Sisko
 Attachments: the error.png

What happens:
AngularJS error is thrown when switching between configuration domain models.

How to reproduce:
1. Start demo mode, launch web agent.
2. Go to configuration and perform DB import once.
3. Open the result configuration domain models section.
4. Import from in place DB, choose to overwrite domain models.
5. Switch between several domain models.

The issue does not persist after page reload, this looks like faulty caching.



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

[jira] [Created] (IGNITE-10725) Push Initial Commit to repository

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-10725:


 Summary: Push Initial Commit to repository
 Key: IGNITE-10725
 URL: https://issues.apache.org/jira/browse/IGNITE-10725
 Project: Ignite
  Issue Type: Sub-task
Reporter: Ilya Kasnacheev
Assignee: Alexey Goncharuk


Unfortunately, empty repository cannot be forked or offered pull requests.
Therefore there is a need of direct push of commit 
4b30c1a2cff4ee4a615bc0940327035705198cbc to repository 
https://gitbox.apache.org/repos/asf?p=ignite-abbrev-plugin.git as 'master'

Source code licenses are not proper in this commit, but it will be fixed in 
following commits.



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

[jira] [Created] (IGNITE-10724) Publish Abbreviation Plugin source to supplimentary repo

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-10724:


 Summary: Publish Abbreviation Plugin source to supplimentary repo
 Key: IGNITE-10724
 URL: https://issues.apache.org/jira/browse/IGNITE-10724
 Project: Ignite
  Issue Type: New Feature
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev


A repository was created, now we need everyone who worked on abbrev plugin to 
offer pull requests to their code.



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

[jira] [Created] (IGNITE-10723) Investigate failures related to enabling tests (IGNITE-1094)

[Vyacheslav Koptilin (JIRA)]

Vyacheslav Koptilin created IGNITE-10723:


 Summary: Investigate failures related to enabling tests 
(IGNITE-1094)
 Key: IGNITE-10723
 URL: https://issues.apache.org/jira/browse/IGNITE-10723
 Project: Ignite
  Issue Type: Test
Affects Versions: 2.7
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin


The following tests were muted due to IGNITE-1094:
* IgniteChangeGlobalStateTest.testActivateAfterFailGetLock
* CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration 
(Hibernate-4.2)
* CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration 
(Hibernate-5.1)
* IgniteSqlSchemaIndexingTest.testCaseSensitive
* IgniteSqlSchemaIndexingTest.testCustomSchemaMultipleCachesTablesCollision
* GridPartitionedCacheJtaLookupClassNameSelfTest.testIncompatibleTmLookup
* CacheJdbcBlobStoreFactorySelfTest.testIncorrectBeanConfiguration
* CacheJdbcPojoStoreFactorySelfTest.testIncorrectBeanConfiguration

These test should be analyzed and enabled on the TC if possible.



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

Re: Continuous queries and duplicates

[Piotr Romański]

Hi all, sorry for answering so late.

I would like to use SqlQuery because I can leverage indexes there.

As it was already mentioned earlier, the partition update counter is
exposed through CacheQueryEntryEvent. Initially, I thought that the
partition update counter is something what's persisted together with the
data but I'm guessing now that this is only a part of the notification
mechanism.

I imagined that I would be able to implement my own deduplicaton by having
3 stages on the client side: 1. Keep processing initial query results,
store their keys in memory, 2. When initial query is over, then process
listener entries but before that check if they have been already delivered
in the first stage, 3. When we are sure that we are already processing
notifications for commits executed after initial query was done, then we
can process listener entries without any additional checks (so our key set
from stage 1 can be removed from memory). The problem is that I have no way
to say that I can move from stage 2 to 3. Another problem is that we need
to stash listener entries while still processing initial query results
causing an excessive memory pressure on our client.

In my case, values are immutable - I never change them, I just add new
entry for newer versions. Does it mean that I won't have any duplicates
between the initial query and listener entries when using continuous
queries on caches supporting MVCC?

After reading the related thread (
http://apache-ignite-developers.2346864.n4.nabble.com/Continuous-queries-and-MVCC-td33972.html)
I'm now concerned about the ordering. My case assumes that there are groups
of entries which belong to a business aggregate object and I would like to
make sure that if I commit two records in two serial transactions then I
have notifications in the same order. Those entries will have different
keys so based on what you said ("we'd better to leave things as is and
guarantee only per-key ordering"), it would seem that the order is not
guaranteed. But do you think it would possible to guarantee order when
those entries share the same affinity key and they belong to the same
partition?

Piotr

pt., 14 gru 2018, 19:31: Denis Magda  napisał(a):

> Vladimir,
>
> Thanks for referring to the MVCC and Continuous Queries discussion, I knew
> that saw us discussing a solution of the duplication problem. Let me copy
> and paste it in here for others:
>
> 2) *Initial query*. We implemented it so that user can get some initial
> > data snapshot and then start receiving events. Without MVCC we have no
> > guarantees of visibility. E.g. if key is updated from V1 to V2, it is
> > possible to see V2 in initial query and in event. With MVCC it is now
> > technically possible to query data on certain snapshot and then receive
> > only events happened after this snapshot. So that we never see V2 twice.
> > Do
> > you think we this feature will be interesting for our users?
>
>
> Am I right that this would be a generic solution - whether you use Scan or
> SQL query as an initial one? Have we planned it for the transactional SQL
> GA or it's out of scope for now?
>
> --
> Denis
>
> On Thu, Dec 13, 2018 at 12:40 PM Vladimir Ozerov 
> wrote:
>
> > [1]
> >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Continuous-queries-and-MVCC-td33972.html
> >
> > On Thu, Dec 13, 2018 at 11:38 PM Vladimir Ozerov 
> > wrote:
> >
> > > Denis,
> > >
> > > Not really. They are used to ensure that ordering of notifications is
> > > consistent with ordering of updates, so that when a key K is updated to
> > V1,
> > > then V2, then V3, you never observe V1 -> V3 -> V2. It also solves
> > > duplicate notification problem in case of node failures, when the same
> > > update is delivered twice.
> > >
> > > However, partition counters are unable to solve duplicates problem in
> > > general. Essentially, the question is how to get consistent view on
> some
> > > data plus all notifications which happened afterwards. There are only
> two
> > > ways to achieve this - either lock entries during initial query, or
> take
> > a
> > > kind of consistent data snapshot. The former was never implemented in
> > > Ignite - our Scan and SQL queries do not user locking. The latter is
> > > achievable in theory with MVCC. I raised that question earlier [1] (see
> > > p.2), and we came to conclusion that it might be a good feature for the
> > > product. It is not implemented that way for MVCC now, but most probably
> > is
> > > not extraordinary difficult to implement.
> > >
> > > Vladimir.
> > >
> > > [1]
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Continuous-queries-and-MVCC-td33972.html#a33998
> > >
> > > On Thu, Dec 13, 2018 at 11:17 PM Denis Magda 
> wrote:
> > >
> > >> Vladimir,
> > >>
> > >> The partition counter is supposed to be used internally to solve the
> > >> duplication issue. Does it sound like a right approach then?
> > >>
> > >> What would be an approach for SQL queries? Not sure the 

[jira] [Created] (IGNITE-10722) Abbr-plugin: refactoring inside write action error

[Ivan Pavlukhin (JIRA)]

Ivan Pavlukhin created IGNITE-10722:
---

 Summary: Abbr-plugin: refactoring inside write action error
 Key: IGNITE-10722
 URL: https://issues.apache.org/jira/browse/IGNITE-10722
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Pavlukhin


Abbreviation plugin reports error to IDEA log when applying abbreviate 
intention. It claims that deadlock is possible.
{code}
2018-12-17 13:35:10,849 [  21351]  ERROR -
oring.BaseRefactoringProcessor - Refactorings should not be started
inside write action
 because they start progress inside and any read action from the
progress task would cause the deadlock
java.lang.Exception
at 
com.intellij.refactoring.BaseRefactoringProcessor.run(BaseRefactoringProcessor.java:560)
at com.intellij.refactoring.RefactoringImpl.run(RefactoringImpl.java:73)
at 
org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.rename(IgniteAbbreviationInspection.java:163)
at 
org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:148)
at 
org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:121)
at 
com.intellij.codeInspection.ex.QuickFixWrapper.invoke(QuickFixWrapper.java:75)
at 
com.intellij.codeInsight.intention.impl.IntentionActionWithTextCaching$MyIntentionAction.invoke(IntentionActionWithTextCaching.java:173)
at 
com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$invokeIntention$3(ShowIntentionActionsHandler.java:202)
at com.intellij.openapi.application.WriteAction.run(WriteAction.java:105)
at 
com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.invokeIntention(ShowIntentionActionsHandler.java:204)
at 
com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$null$1(ShowIntentionActionsHandler.java:179)
at 
com.intellij.openapi.application.TransactionGuardImpl.runSyncTransaction(TransactionGuardImpl.java:88)
at 
com.intellij.openapi.application.TransactionGuardImpl.submitTransactionAndWait(TransactionGuardImpl.java:153)
at 
com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$chooseActionAndInvoke$2(ShowIntentionActionsHandler.java:178)
at 
com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:139)
at 
com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:97)
at 
com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:87)
at 
com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:73)
at 
com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.chooseActionAndInvoke(ShowIntentionActionsHandler.java:177)
at 
com.intellij.codeInsight.intention.impl.IntentionListStep.lambda$applyAction$0(IntentionListStep.java:118)
at 
com.intellij.openapi.application.TransactionGuardImpl.performUserActivity(TransactionGuardImpl.java:195)
at 
com.intellij.ui.popup.AbstractPopup.lambda$dispose$8(AbstractPopup.java:1417)
at com.intellij.util.ui.UIUtil.invokeLaterIfNeeded(UIUtil.java:3097)
at 
com.intellij.ide.IdeEventQueue.ifFocusEventsInTheQueue(IdeEventQueue.java:183)
at 
com.intellij.ide.IdeEventQueue.executeWhenAllFocusEventsLeftTheQueue(IdeEventQueue.java:132)
at 
com.intellij.openapi.wm.impl.FocusManagerImpl.doWhenFocusSettlesDown(FocusManagerImpl.java:190)
at 
com.intellij.openapi.wm.impl.IdeFocusManagerImpl.doWhenFocusSettlesDown(IdeFocusManagerImpl.java:58)
at com.intellij.ui.popup.AbstractPopup.dispose(AbstractPopup.java:1411)
at com.intellij.ui.popup.WizardPopup.dispose(WizardPopup.java:160)
at com.intellij.ui.popup.list.ListPopupImpl.dispose(ListPopupImpl.java:307)
at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:48)
at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:44)
at 
com.intellij.openapi.util.objectTree.ObjectNode$1.execute(ObjectNode.java:138)
at 
com.intellij.openapi.util.objectTree.ObjectNode$1.execute(ObjectNode.java:107)
at 
com.intellij.openapi.util.objectTree.ObjectTree.executeActionWithRecursiveGuard(ObjectTree.java:182)
at 
com.intellij.openapi.util.objectTree.ObjectNode.execute(ObjectNode.java:107)
at 
com.intellij.openapi.util.objectTree.ObjectTree.executeAll(ObjectTree.java:151)
at com.intellij.openapi.util.Disposer.dispose(Disposer.java:129)
at com.intellij.openapi.util.Disposer.dispose(Disposer.java:125)
at com.intellij.ui.popup.WizardPopup.disposeAllParents(WizardPopup.java:263)
at 
com.intellij.ui.popup.list.ListPopupImpl.handleNextStep(ListPopupImpl.java:442)
at 
com.intellij.ui.popup.list.ListPopupImpl._handleSelect(ListPopupImpl.java:396)
at 

Re: Abbreviation code-style requirement.

[Павлухин Иван]

Dmirity,

Thank you! Permissions works for me.

I will spend a while using a newly built plugin on my machine and then
will publish it to the wiki and write back.


пн, 17 дек. 2018 г. в 15:40, Dmitriy Pavlov :
>
> Hi Ivan,
>
> I've merged your PR and added permissions to the wiki, please check.
>
> I still feel we need to migrate code to ASF repo. I will try to do
> something for that.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 17 дек. 2018 г. в 13:44, Павлухин Иван :
>
> > Hi,
> >
> > I did some investigation regarding scala support and it seems that
> > version used today (3.0.0) was build without scala support. If nobody
> > minds I suggest to build a new version without scala as well.
> >
> > Also there is a thing that bothers me a little. IDEA throws exception
> > in log when a name is abbreviated by plugin (see at the very bottom of
> > this message). I build old version on my machine as well and received
> > the same. It seems that it was there before my changes. Or it might be
> > somehow related to version of IDEA which I used to build the plugin.
> >
> > 2018-12-17 13:35:10,849 [  21351]  ERROR -
> > oring.BaseRefactoringProcessor - Refactorings should not be started
> > inside write action
> >  because they start progress inside and any read action from the
> > progress task would cause the deadlock
> > java.lang.Exception
> > at
> > com.intellij.refactoring.BaseRefactoringProcessor.run(BaseRefactoringProcessor.java:560)
> > at
> > com.intellij.refactoring.RefactoringImpl.run(RefactoringImpl.java:73)
> > at
> > org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.rename(IgniteAbbreviationInspection.java:163)
> > at
> > org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:148)
> > at
> > org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:121)
> > at
> > com.intellij.codeInspection.ex.QuickFixWrapper.invoke(QuickFixWrapper.java:75)
> > at
> > com.intellij.codeInsight.intention.impl.IntentionActionWithTextCaching$MyIntentionAction.invoke(IntentionActionWithTextCaching.java:173)
> > at
> > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$invokeIntention$3(ShowIntentionActionsHandler.java:202)
> > at
> > com.intellij.openapi.application.WriteAction.run(WriteAction.java:105)
> > at
> > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.invokeIntention(ShowIntentionActionsHandler.java:204)
> > at
> > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$null$1(ShowIntentionActionsHandler.java:179)
> > at
> > com.intellij.openapi.application.TransactionGuardImpl.runSyncTransaction(TransactionGuardImpl.java:88)
> > at
> > com.intellij.openapi.application.TransactionGuardImpl.submitTransactionAndWait(TransactionGuardImpl.java:153)
> > at
> > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$chooseActionAndInvoke$2(ShowIntentionActionsHandler.java:178)
> > at
> > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:139)
> > at
> > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:97)
> > at
> > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:87)
> > at
> > com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:73)
> > at
> > com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.chooseActionAndInvoke(ShowIntentionActionsHandler.java:177)
> > at
> > com.intellij.codeInsight.intention.impl.IntentionListStep.lambda$applyAction$0(IntentionListStep.java:118)
> > at
> > com.intellij.openapi.application.TransactionGuardImpl.performUserActivity(TransactionGuardImpl.java:195)
> > at
> > com.intellij.ui.popup.AbstractPopup.lambda$dispose$8(AbstractPopup.java:1417)
> > at com.intellij.util.ui.UIUtil.invokeLaterIfNeeded(UIUtil.java:3097)
> > at
> > com.intellij.ide.IdeEventQueue.ifFocusEventsInTheQueue(IdeEventQueue.java:183)
> > at
> > com.intellij.ide.IdeEventQueue.executeWhenAllFocusEventsLeftTheQueue(IdeEventQueue.java:132)
> > at
> > com.intellij.openapi.wm.impl.FocusManagerImpl.doWhenFocusSettlesDown(FocusManagerImpl.java:190)
> > at
> > com.intellij.openapi.wm.impl.IdeFocusManagerImpl.doWhenFocusSettlesDown(IdeFocusManagerImpl.java:58)
> > at com.intellij.ui.popup.AbstractPopup.dispose(AbstractPopup.java:1411)
> > at com.intellij.ui.popup.WizardPopup.dispose(WizardPopup.java:160)
> > at
> > com.intellij.ui.popup.list.ListPopupImpl.dispose(ListPopupImpl.java:307)
> > at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:48)
> > at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:44)
> > at
> > 

[jira] [Created] (IGNITE-10721) Documentation: Fix UUID thin client format description

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-10721:


 Summary: Documentation: Fix UUID thin client format description
 Key: IGNITE-10721
 URL: https://issues.apache.org/jira/browse/IGNITE-10721
 Project: Ignite
  Issue Type: Task
  Components: documentation, thin client
Reporter: Igor Sapego
 Fix For: 2.8


UUID thin client format description [1] need to be fixed. The actual format of 
the UUID should be two longs, not a single 128-bit value. Two longs written in 
little-endian are not equal to one 128-bit number.

[1] - 
https://apacheignite.readme.io/docs/binary-client-protocol-data-format#section-uuid-guid-



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

Re: How to begin to contribute

[Dmitriy Pavlov]

Hi Michael,

I'm trying to reach you in https://issues.apache.org/jira/browse/IGNITE-7153
 mentions.

To proceed with patch according to
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-SubmittingforReview
we
need to set the ticket to Patch Available state. If you feel your patch is
ready, please set ticket status.

Sincerely,
Dmitriy Pavlov

ср, 31 окт. 2018 г. в 06:04, Michael Fong :

> Absolutely, I am glad to see this problem solved regardless whom the
> assignee is. After all, we are suffering this Redis problem in our Ignite
> PoC, and we are in urgency to solve this problem.
> I would be glad to provide my solution for you guys to apply if you think
> it is a good (enough) solution. :-)
>
> Regards,
>
> Michael
>
> On Tue, Oct 30, 2018 at 7:53 PM Dmitriy Pavlov 
> wrote:
>
> > Hi Michael,
> >
> > I can see that https://issues.apache.org/jira/browse/IGNITE-7153 is
> > already
> > assigned to Roman Shtykh and is In Progress status.
> >
> > I hope Roman can step in and comment if he is interested in continuing of
> > developing this issue/or he could apply you PR as well.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пн, 22 окт. 2018 г. в 11:33, Michael Fong :
> >
> > > Ah, never mind. I found out that I chose the wrong test suite to begin
> > with
> > > on Team City. :-)
> > >
> > > On Sun, Oct 21, 2018 at 10:20 PM Michael Fong 
> > > wrote:
> > >
> > > > Hi, all,
> > > >
> > > > I happened to have a fix for IGNITE-7153 and created pull request for
> > > it. (
> > > > https://github.com/apache/ignite/pull/5044)
> > > >
> > > > I tried to follow the How to Contribute Workflow
> > > > <
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-Workflow
> > >
> > > but
> > > > kind of got stuck on TeamCity CI, where all the test suite build
> failed
> > > at
> > > > unrelated library (ignite-tool). Is there any other easier or more
> > > > intuitive CI or documentation to guide through the testing process?
> > > >
> > > > Furthermore, I wonder what would the code review process be, still
> via
> > > > github comment review?
> > > >
> > > > Regards,
> > > >
> > > > Michael
> > > >
> > >
> >
>

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

[oignatenko]

Hi Ivan,

Per my cursory check of the code currently in master, we have 239 test
classes that couldn't migrate (that's probably about 500 or something test
cases). For comparison, over 1600 classes migrated without problems. This is
to answer your questions about how many tests are affected by change and 
how many tests were not migrated yet.
 
-

I think we can say that only small percent of tests turned out sensitive to
JUnit framework change.

In the same time, due to very large overall amount of our tests we have
quite a big number as an absolute value. I point this because if amount of
troublesome tests was smaller (say, order of magnitude smaller) I would
consider delaying migration until all tests reworked to blend totally
seamlessly into new version JUnit. This is doable - as sort of "pilot
exercise" me and Ed adjusted one test case this way - but the sheer amount
of work on 200+ classes raises a question, whether it is worth it (I think
it isn't).

With regards to question 2, changes to TestCounters are farly trivial (and
necessary) if you look at the code diff. Prior code counted amount of test
cases in the class by JUnit 3 convention: it picked public void methods
without parameters starting with "test". Changed code counts test cases as
JUnit 4 does: by checking if method is annotated with @Test. Change is
necessary because it will allow test developers fully use JUnit 4 features
by adding test cases that don't follow old naming requirement. I
experimented with it a little and as far as I could see the old TestCounters
indeed break when there are methods following new convention, it triggered
afterTestsStopped too early.

The answer to your question 3 lies in javadocs I added to runSerializer
declaration, or, more precisely, in TestCounters javadoc referred from
there. As you can see, current plan is to get rid of TestCounters fairly
soon (per IGNITE-10179) and this will also get rid of runSerializer so this
is merely a temporary band aid to be removed soon.

For the sake of completeness, my initial plan was to thoroughly investigate
and test whether change from JUnit 3 to JUnit 4 would keep accessing
counters safe or not and only introduce runSerializer if it really does but
after realising that this whole thing is likely to go away in a few days
from now I decided that it isn't worth wasting time and just temporarily
made it the way that is waterproof guaranteed to be safe.

-

Now, to answer your question whether it is an option for us to keep part of
tests under JUnit 3, my answer is most definitely no.
 
Main reason is that having part of tests under JUnit 3 will deprive us
ability to consistently use Ignore annotation and force us fallback to old
way to fail the tests we want to ignore. This would kind of trash the whole
purpose of migration because we won't be able to simplify and improve
maintenance of ignored tests.
 
Another important reason is that keeping JUnit 3 will much complicate our
test framework code. We will have to implement and maintain two versions of
TestCounters (see answer to your question #2 above). We will also have to
keep the code that currently determines first/last test in the class and
possibly even complicate it to account for two versions of the framework -
compare that to current plan to simply get rid of all that code per
IGNITE-10179.
 
The last but not the least, this makes it much more complicated to later
migrate to JUnit 5. Although this is currently not in the nearest plans
(IGNITE-10180) we eventually will want to (especially taking into account
that migration from JUnit 4 is said to be easy). Having JUnit 3 tests would
much complicate this because we have no idea if JUnit 5 could interoperate
with such an old version (and I see no reason why we would want to waste our
time and efforts investigating and testing this).
 
Summing up, I believe it is very well worth it for us to get rid of JUnit 3
completely.
 
 -
 
With regards to making LegacySupport enabled only on purpose, at this point
I see no reason to enforce this in code because I expect that deprecation
notices will do that job.

If a developer writing new test or reworking an old one follows the
deprecation recommendations they will use JUnit 4 way instead of deprecated
methods and you can see from the code that in this case LegacySupport will
just transparently pass-through the test code without introducing anything
else beyond. (Note we can reconsider and rework this later in case if it
turns out that my expectation doesn't hold). 

Does that answer your questions?
 
regards, Oleg


Павлухин Иван wrote
> Hi Oleg,
> 
> The things become challenging. Truly I do not see any trivial solution
> so far. Could you please outline main problems which we are facing
> today? And how many tests are affected? Some clarifying questions:
> 1. I know that setup->test->teardown threading was changed for junit4
> tests, but actually I thought that it might affect only small number
> of tests. Am 

[jira] [Created] (IGNITE-10720) Decrease time to save metadata during checkpoint

[Anton Kalashnikov (JIRA)]

Anton Kalashnikov created IGNITE-10720:
--

 Summary: Decrease time to save metadata during checkpoint
 Key: IGNITE-10720
 URL: https://issues.apache.org/jira/browse/IGNITE-10720
 Project: Ignite
  Issue Type: Improvement
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov


Looks like it's not neccessery save all metadata(like free list) under write 
checkpoint lock because sometimes it's too long.



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

Re: Code inspection

[Andrey Mashenkov]

Maxim,

Looks ok. Let's apply IGNITE-10682.

All,

Also, I'd like to publish idea.logs into artefacts by default.
This will give us more details for investigation in future if any failure
will occurs.
It will costs 1-10 kB.

On Mon, Dec 17, 2018 at 3:21 PM Maxim Muzafarov  wrote:

> Dmitry,
>
> It seems to me that we have two independent issues here.
> 1. An `Unexpected error during build messages processing in TeamCity`
> error message which is related to TC agent configuration. Suppose,
> server.log will provide us more details about it. I have to access
> there.
> 2. A new set of inspection rules was introduced in 2018+ IntelliJ IDEA
> and they should be disabled in our ignite_inspections_teamcity.xml
> configuration file. They are not fixed in the Apache Ignite project
> code yet. I've prepared the issue [1] for it. Please, take a look.
>
>
> Andrey,
>
> I've fixed disabled plugins file according to your suggestions. The
> issue [2] is ready. I've re-run `Excluded [Inspections] Core Debug`
> suite and the log details show me that now only 3 plugins are enabled:
> IDEA CORE, Maven Integration, Properties Support. It seems to me that
> it's correct.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-10709
> [2] https://issues.apache.org/jira/browse/IGNITE-10682
>
> On Sat, 15 Dec 2018 at 15:22, Dmitriy Pavlov  wrote:
> >
> > Folks,
> >
> > There is a strange error on TC
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=2556875=IgniteTests24Java8_InspectionsCore
> >
> > It appeared after TC update to the latest version.
> >
> > Sincerely,
> > Dmitry Pavlov
> >
> > пт, 14 дек. 2018 г. в 16:09, Andrey Mashenkov <
> andrey.mashen...@gmail.com>:
> >
> > > Maxim,
> > >
> > > PR is incomplete. Some plugins should be disabled with different
> id\name.
> > > Maven plugin shouldn't be disabled as Idea Inspector use it to use
> Ignite
> > > project pom file.
> > >
> > > Please, find details in ticket.
> > >
> > >
> > > On Fri, Dec 14, 2018 at 12:00 PM Andrey Mashenkov <
> > > andrey.mashen...@gmail.com> wrote:
> > >
> > > > Maxim,
> > > >
> > > > Thanks, I'll check PR and let you know about results.
> > > >
> > > > For now, Inspections task execution time looks much better (15-22
> min),
> > > > but fluctuation is still noticeable.
> > > >
> > > > On Fri, Dec 14, 2018 at 11:13 AM Maxim Muzafarov  >
> > > > wrote:
> > > >
> > > >> Andrey,
> > > >>
> > > >> Thanks! I've consulted with the IntelliJ IDEA source code and found
> > > >> how this disabled plugins file should look like. I've created a new
> > > >> issue [1] and prepared PR [2] with the set of disabled plugins
> (maybe
> > > >> not complete set). I don't have access to change corresponding
> > > >> `~Excluded [Inspections] Core Debug` test suite properties.
> > > >> Can we test this PR?
> > > >>
> > > >> [1] https://issues.apache.org/jira/browse/IGNITE-10682
> > > >> [2] https://github.com/apache/ignite/pull/5666
> > > >> On Thu, 13 Dec 2018 at 17:35, Andrey Mashenkov
> > > >>  wrote:
> > > >> >
> > > >> > Maxim,
> > > >> >
> > > >> > Idea has a file in config directory ./config/disabled_plugins.txt
> ,
> > > you
> > > >> can easily find it at you local machine.
> > > >> > Teamcity Inspections runner has an option "Disabled plugins" where
> > > >> disabled_plugins.txt file content can be set.
> > > >> >
> > > >> > So, looks like we can disable useless plugins.
> > > >> > But I'm not expert and can't suggest changes we can safely apply.
> > > >> >
> > > >> > On Thu, Dec 13, 2018 at 4:59 PM Maxim Muzafarov <
> maxmu...@gmail.com>
> > > >> wrote:
> > > >> >>
> > > >> >> Andrey,
> > > >> >>
> > > >> >> Thank you for solving this issue with GC pauses! I've checked the
> > > >> >> given report. The inspections configuration is correct, but it
> seems
> > > >> >> to me that we have enabled by default rules of included plugins
> (for
> > > >> >> instance, KotlinInternalInJava in the report is enabled).
> > > >> >>
> > > >> >> Can you share more details about `disable plugin` option you
> found?
> > > >> >>
> > > >> >> I see that idea instance starts with the default
> -Didea.plugins.path
> > > >> >> system property, can we change it so the plugins will be not
> loaded
> > > by
> > > >> >> default?
> > > >> >> On Thu, 13 Dec 2018 at 15:45, Andrey Mashenkov
> > > >> >>  wrote:
> > > >> >> >
> > > >> >> > Maxim,
> > > >> >> >
> > > >> >> > It looks like we can't make logs more verbose due to possible
> bug,
> > > >> I've create a ticket in Jetbrains Jira [1].
> > > >> >> > We can just publish idea logs in artefacts as suggested in this
> > > >> manual [2].
> > > >> >> >
> > > >> >> > For now, Inspections logs looks like this one [3].
> > > >> >> > Also, would you please to take a look at inspection report and
> > > check
> > > >> if we missed smth and there are any unwanted inspection turned on.
> > > >> >> >
> > > >> >> > [1] https://youtrack.jetbrains.com/issue/TW-58422
> > > >> >> > [2]
> > > >>
> > >
> 

[jira] [Created] (IGNITE-10719) [ML] LEarningEnvironmentBuilder is not passed in makeBagged

[Artem Malykh (JIRA)]

Artem Malykh created IGNITE-10719:
-

 Summary: [ML] LEarningEnvironmentBuilder is not passed in 
makeBagged
 Key: IGNITE-10719
 URL: https://issues.apache.org/jira/browse/IGNITE-10719
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Artem Malykh
Assignee: Artem Malykh


During TrainerTrainsformers#makeBagged learning environment builder is not 
passed from trainer which is made bagged



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

Re: Thin clients all in one

[Alexey Kosenchuk]

Hi Stepan,

1) About UUID...

UUID binary encoding must be defined in the Binary Protocol 
specification 
(https://apacheignite.readme.io/docs/binary-client-protocol-data-format#section-uuid-guid-)

So, it's the issue against the spec first.

Regarding the clients..

Python client uses Python UUID class 
(https://docs.python.org/2/library/uuid.html) which, if I understand 
correctly, can operate with different encodings. Dmitry M. can correct me.


NodeJs and PHP do not have standard UUID classes.
So, the clients return/accept UUID as just a 16-byte array with binary 
encoding inside, exactly as it is read / will be written via the binary 
protocol.

An application may convert this array to/from a required representation.

2) About Timestamp...

Python, NodeJs and PHP clients behave strictly according to the Binary 
Protocol specification 
(https://apacheignite.readme.io/docs/binary-client-protocol-data-format#section-timestamp) 
which defines that the second field is "a nanoseconds fraction of a last 
millisecond, which value could be in a range from 0 to 99."


Regards,
-Alexey

14.12.2018 17:41, Stepan Pilschikov пишет:

Hello again

Starting to check compatibility between thin clients in java/c++ and 
py/php/nodejs and met some problems


1) Found that UUID mixed in a strange way if we taken it from Java/C++ 
to PY/PHP/JS client and backwards
Have issue about it https://issues.apache.org/jira/browse/IGNITE-10691, 
please look at it


2) Is more like conversation about seamless experience between all thin 
clients
PY/PHP/JS/C++/Java have Timestamp data type which is contain 
tuple(millis, nanos)

Main concern about nanos

In PHP/JS/Py Nanos count like "nanoseconds of the last millisecond" but 
in Java and C++ its like we have millis and same millis but with nanos 
and its strange for PHP/PY/JS if we take Java how is Base thin client


For example in Java we have new Timestamp(11) and it 
(fastTime=111000, nanos=11100)
In C++ if we getting this cache we take (millis=11, nanos=11100) 
which is kind a right and same as in java
But in py/php/js its look like (millis=11, nanos=0), its kind a 
understandable what logic is, but sill different behavior and experience

What you thinking about it?
For now i can't understand why its done how its done, looks like it 
should be same but something going wrong


пт, 30 нояб. 2018 г. в 01:18, Alexey Kosenchuk 
mailto:alexey.kosenc...@nobitlost.com>>:


Hi Stepan,

pls check the Ignite cfg you use - see the comments in the jira.

Also, the examples executors (including AuthTlsExample) are included
into NodeJS test suite in TeamCity which run periodically and
successfully passed. Eg. the latest one:

https://ci.ignite.apache.org/viewLog.html?buildId=2426645=buildResultsDiv=IgniteTests24Java8_ThinClientNodeJs

Regards,
-Alexey

28.11.2018 17:08, Stepan Pilschikov пишет:
 > Hello again
 >
 > If NodeJS sources found that example AuthTlsExample.js throwing
exception
 > during execution
 > Output and grid configuration in
 > https://issues.apache.org/jira/browse/IGNITE-10447
 >
 > Can someone have a look at it?
 >
 > вс, 25 нояб. 2018 г. в 19:11, Stepan Pilschikov
mailto:pilshchikov@gmail.com>>:
 >
 >> My bad,
 >> You right
 >>
 >> вс, 25 нояб. 2018 г. в 05:37, Dmitry Melnichuk <
 >> dmitry.melnic...@nobitlost.com
>:
 >>
 >>> Stepan,
 >>>
 >>> AFAIK Map type did always behave correctly on client side, as
it does
 >>> now. This is a corresponding piece of my test suite:
 >>>
 >>> ```
 >>> def test_put_get_map(client):
 >>>
 >>>       cache = client.get_or_create_cache('test_map_cache')
 >>>
 >>>       cache.put(
 >>>           'test_map',
 >>>           (
 >>>               MapObject.HASH_MAP,
 >>>               {
 >>>                   (123, IntObject): 'test_data',
 >>>                   456: ((1, [456, 'inner_test_string', 789]),
 >>> CollectionObject),
 >>>                   'test_key': 32.4,
 >>>               }
 >>>           ),
 >>>           value_hint=MapObject
 >>>       )
 >>>       value = cache.get('test_map')
 >>>       assert value == (MapObject.HASH_MAP, {
 >>>           123: 'test_data',
 >>>           456: (1, [456, 'inner_test_string', 789]),
 >>>           'test_key': 32.4,
 >>>       })
 >>>
 >>> ```
 >>>
 >>> Or is there another, more specific problem with maps?
 >>>
 >>> Dmitry
 >>>
 >>> On 11/25/18 3:56 AM, Stepan Pilschikov wrote:
  Dmitry,
 
  Great, checked, now all things woks well
  Hope that Igor made review for this PR
 
  But what about Maps? Looks like different ticket? or it can be
done in
 >>> same
  ticket scope?
 
  пт, 23 нояб. 

RE: Pre-touch for Ignite off-heap memory

[Stanislav Lukyanov]

I don’t think these two issues require to be solved together, although I agree 
there is some connection.

I guess we agree that pre-touch should a be off by default.
Similarly, lazy data region initialization from IGNITE-9113 can be on by 
default.
We can have two boolean properties controlling each feature, e.g. 
IGNITE_EAGER_DATA_REGION_INITIALIZATION
IGNITE_PRE_TOUCH_OFF_HEAP_MEMORY
Setting both to true will make sure that all memory is committed as early as 
possible.
Different combinations will allow for all 4 variants you’ve mentioned. I can 
see a use case for each one:
- lazy region init + no pre-touch (default) – easier configuration (at least 
for simple use cases without a lot of regions and node filters) and faster 
startup
- lazy region init + pre-touch – allows to reuse server config on a client (the 
goal of the IGNITE-9113) but still allows to fail-fast on cache creation
- eager region init + no pre-touch – for cases when you want to eagerly 
allocate memory but don’t care about committing physical pages; e.g. if you 
have overcommit disabled then you don’t need to pre-touch everything to make 
sure the memory is there
- eager region init + pre-touch – to fail as early as possible if there is not 
enough RAM 

Stan

From: Nikolay Izhikov
Sent: 14 декабря 2018 г. 14:42
To: dev; vololo...@gmail.com; stanlukya...@gmail.com
Subject: Re: Pre-touch for Ignite off-heap memory

Bump.

Stanislav, Ivan, can you answer my questions?
Let's discuss these improvements.

ср, 12 дек. 2018 г. в 22:14, Павлухин Иван :

> Hi Stan,
>
> As I participated in discussion in current thread I would like to
> leave a comment.
>
> Your concerns looks clear for me and if you believe that pre-touch
> will help product users then I have nothing against it.
> ср, 12 дек. 2018 г. в 11:09, Nikolay Izhikov :
> >
> > Hello, Stanislav.
> >
> > As far as I can see, we have controversal ticket based on previous
> dev-list discussion:
> >
> > IGNITE-9113 - Allocate memory for a data region when first cache
> assigned to this region is created [1]
> >
> > I planned to implement it soon.
> > Looks like we should have several options of memory(data regions)
> allocation:
> >
> > - allocate all on startup (AFAIK this is how current
> implementation behave)
> > - allocate all on startup AND pre touch.
> > - allocate specific data region for first assignment.
> > - allocate specific data region for first assignment AND pre
> touch.
> >
> > What do you think?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-9113
> >
> > В Вт, 11/12/2018 в 19:39 +0300, Stanislav Lukyanov пишет:
> > > Igniters,
> > >
> > > What is being suggested here is an Ignite off-heap’s version of Java’s
> -XX:+AlwaysPreTouch.
> > > The latter is known to be used to guarantee that the committed memory
> is backed by physical RAM.
> > > This ensures that
> > > a) JVM doesn’t have to do it during the actual work (avoiding overhead
> for physical page allocation, possible contention with page cache, etc)
> > > b) JVM fails fast if the Xmx is greater than available RAM
> > > c) New processes will not be able to claim the memory JVM took for
> itself
> > >
> > > Currently one can’t get the same benefits for Ignite because we use
> off-heap as well as heap.
> > > So, we can implement a similar feature for Ignite – and make sure the
> users can get all the memory pre-touch benefits if they want.
> > > Of course, it impacts startup time so we should enable it by a
> configuration property (I’d suggest a system property for now).
> > >
> > > Are there any objections to implementing this?
> > >
> > > Thanks,
> > > Stan
> > >
> > > From: Павлухин Иван
> > > Sent: 31 октября 2018 г. 12:50
> > > To: dev@ignite.apache.org
> > > Subject: Re: Pre-touch for Ignite off-heap memory
> > >
> > > Hi,
> > >
> > > I did an experiment described above. I created a patch with pre-touch
> [1]
> > > and started a JVM with an option -XX:+AlwaysPreTouch and configured
> > > Ignite with equal values for initial and max sizes for each data
> region.
> > > I did several runs. I observed JVM crash dumps [2], [3]. Also it is
> easy
> > > to observe JVM OOM-killed.
> > >
> > > [1] https://github.com/apache/ignite/pull/5220
> > > [2]
> > >
> https://gist.github.com/pavlukhin/e5e6605e9b4366627ba8d1aab42f#file-hs_err_pid5763-log
> > > [3]
> > >
> https://gist.github.com/pavlukhin/e5e6605e9b4366627ba8d1aab42f#file-hs_err_pid6411-log
> > >
> > > вт, 30 окт. 2018 г. в 9:19, Павлухин Иван :
> > >
> > > > Hi guys,
> > > >
> > > > I am not aware that it is possible to run JVM in "allocation-free"
> fashion.
> > > > If you know that it is possible please share it. As I know JVM
> allocates
> > > > memory out of garbage collectable area for internal purposes like
> JIT,
> > > > GC itself. Also native built-it code can request memory allocation
> from OS,
> > > > e.g. zip facilities. If we imagine that system is running under
> memory
> > > > allocation
> > 

Re: Apache Ignite TeamCity Bot - muted tests

[Anton Vinogradov]

>>  In this case, we will not need TeamCity mutes anymore.
Sounds great!

On Mon, Dec 17, 2018 at 5:23 PM Dmitrii Ryabov 
wrote:

> Dmitriy,
>
> with ignore annotations we will need to check forgotten tests
> manually. Thats bad, but we will save some machine time in common
> runs.
> пн, 17 дек. 2018 г. в 17:06, Dmitriy Pavlov :
> >
> > Investigation parameters: Can leave as empty
> > Unmute: Manual (don't use auto because of flaky tests)
> > Text: https://issues.apache.org/jira/browse/IGNITE-N
> >
> > But anyway, I hope in the nearest future best way to mute test will be to
> > ignore it using:
> > @IgniteIgnore
> > or @Ignore
> > or Assume.that()
> >
> > In this case, we will not need TeamCity mutes anymore.
> >
> > I'm not sure which way of ignoring will be best.
> >
> > пн, 17 дек. 2018 г. в 17:02, Anton Vinogradov :
> >
> > > Dmitrii,
> > >
> > > My question was mostly about how to mute test properly.
> > >
> > >
> > > On Mon, Dec 17, 2018 at 4:27 PM Dmitrii Ryabov 
> > > wrote:
> > >
> > > > Anton,
> > > >
> > > > In the "Mute" column you can find link to the test on TeamCity. On
> > > > this page you can see test details like run history and current
> mutes.
> > > > Here you should be able to unmute existing mutes.
> > > > пн, 17 дек. 2018 г. в 16:21, Anton Vinogradov :
> > > > >
> > > > > Great feature!
> > > > >
> > > > > Could you please explain how to have a deal with it?
> > > > > How should I mite/unmute tests for now?
> > > > >
> > > > > On Fri, Dec 14, 2018 at 6:50 PM Dmitriy Pavlov  >
> > > > wrote:
> > > > >
> > > > > > We have IgniteIgnore, so we can use it. It seems behavior is the
> > > same.
> > > > We
> > > > > > need just to understand in which case we can get issue ID from TC
> > > REST
> > > > (for
> > > > > > the Bot).
> > > > > >
> > > > > > пт, 14 дек. 2018 г. в 17:51, Vyacheslav Daradur <
> daradu...@gmail.com
> > > >:
> > > > > >
> > > > > > > Dmitry Pavlov,
> > > > > > >
> > > > > > > As far as I know, we are able to use following construction to
> > > ignore
> > > > > > test:
> > > > > > > Assume.assumeTrue("link-to-issue", false);
> > > > > > >
> > > > > > > On Fri, Dec 14, 2018 at 5:44 PM Dmitriy Pavlov <
> dpav...@apache.org
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > Thank you, Dmitrii,
> > > > > > > >
> > > > > > > >  I've started unmuting tests starting from yesterday.
> > > > > > > >
> > > > > > > > Now muted test count was decreased from 3540 to 3408
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=mutedProblems_IgniteTests24Java8=%3Cdefault%3E
> > > > > > > >
> > > > > > > >
> > > > > > > > Probably we could automate this activity by auto-unmute, but
> > > > hopefully,
> > > > > > > > JUnit4 & @Ignore opportunity will come earlier.
> > > > > > > >
> > > > > > > > Sincerely,
> > > > > > > > Dmitriy Pavlov
> > > > > > > >
> > > > > > > > пт, 14 дек. 2018 г. в 17:24, Dmitrii Ryabov <
> > > somefire...@gmail.com
> > > > >:
> > > > > > > >
> > > > > > > > > Hello, Igniters!
> > > > > > > > >
> > > > > > > > > Our Bot got new functionality - it shows tests muted on
> > > TeamCity
> > > > and
> > > > > > > their
> > > > > > > > > ticket status [1].
> > > > > > > > >
> > > > > > > > > So, we can see forgotten mutes for resolved tickets now.
> > > > > > > > >
> > > > > > > > > Igniters with rights to unmute tests on TC - please, check
> this
> > > > page
> > > > > > > > > periodically for forgotten mutes.
> > > > > > > > >
> > > > > > > > > [1] https://mtcga.gridgain.com/mutes.html
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > > >
> > > >
> > >
>

Re: Apache Ignite TeamCity Bot - muted tests

[Dmitrii Ryabov]

Dmitriy,

with ignore annotations we will need to check forgotten tests
manually. Thats bad, but we will save some machine time in common
runs.
пн, 17 дек. 2018 г. в 17:06, Dmitriy Pavlov :
>
> Investigation parameters: Can leave as empty
> Unmute: Manual (don't use auto because of flaky tests)
> Text: https://issues.apache.org/jira/browse/IGNITE-N
>
> But anyway, I hope in the nearest future best way to mute test will be to
> ignore it using:
> @IgniteIgnore
> or @Ignore
> or Assume.that()
>
> In this case, we will not need TeamCity mutes anymore.
>
> I'm not sure which way of ignoring will be best.
>
> пн, 17 дек. 2018 г. в 17:02, Anton Vinogradov :
>
> > Dmitrii,
> >
> > My question was mostly about how to mute test properly.
> >
> >
> > On Mon, Dec 17, 2018 at 4:27 PM Dmitrii Ryabov 
> > wrote:
> >
> > > Anton,
> > >
> > > In the "Mute" column you can find link to the test on TeamCity. On
> > > this page you can see test details like run history and current mutes.
> > > Here you should be able to unmute existing mutes.
> > > пн, 17 дек. 2018 г. в 16:21, Anton Vinogradov :
> > > >
> > > > Great feature!
> > > >
> > > > Could you please explain how to have a deal with it?
> > > > How should I mite/unmute tests for now?
> > > >
> > > > On Fri, Dec 14, 2018 at 6:50 PM Dmitriy Pavlov 
> > > wrote:
> > > >
> > > > > We have IgniteIgnore, so we can use it. It seems behavior is the
> > same.
> > > We
> > > > > need just to understand in which case we can get issue ID from TC
> > REST
> > > (for
> > > > > the Bot).
> > > > >
> > > > > пт, 14 дек. 2018 г. в 17:51, Vyacheslav Daradur  > >:
> > > > >
> > > > > > Dmitry Pavlov,
> > > > > >
> > > > > > As far as I know, we are able to use following construction to
> > ignore
> > > > > test:
> > > > > > Assume.assumeTrue("link-to-issue", false);
> > > > > >
> > > > > > On Fri, Dec 14, 2018 at 5:44 PM Dmitriy Pavlov  > >
> > > > > wrote:
> > > > > > >
> > > > > > > Thank you, Dmitrii,
> > > > > > >
> > > > > > >  I've started unmuting tests starting from yesterday.
> > > > > > >
> > > > > > > Now muted test count was decreased from 3540 to 3408
> > > > > > >
> > > > > >
> > > > >
> > >
> > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=mutedProblems_IgniteTests24Java8=%3Cdefault%3E
> > > > > > >
> > > > > > >
> > > > > > > Probably we could automate this activity by auto-unmute, but
> > > hopefully,
> > > > > > > JUnit4 & @Ignore opportunity will come earlier.
> > > > > > >
> > > > > > > Sincerely,
> > > > > > > Dmitriy Pavlov
> > > > > > >
> > > > > > > пт, 14 дек. 2018 г. в 17:24, Dmitrii Ryabov <
> > somefire...@gmail.com
> > > >:
> > > > > > >
> > > > > > > > Hello, Igniters!
> > > > > > > >
> > > > > > > > Our Bot got new functionality - it shows tests muted on
> > TeamCity
> > > and
> > > > > > their
> > > > > > > > ticket status [1].
> > > > > > > >
> > > > > > > > So, we can see forgotten mutes for resolved tickets now.
> > > > > > > >
> > > > > > > > Igniters with rights to unmute tests on TC - please, check this
> > > page
> > > > > > > > periodically for forgotten mutes.
> > > > > > > >
> > > > > > > > [1] https://mtcga.gridgain.com/mutes.html
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > > >
> > >
> >

[jira] [Created] (IGNITE-10718) [ML] Merge XGBoost and Ignite ML Trees together

[Anton Dmitriev (JIRA)]

Anton Dmitriev created IGNITE-10718:
---

 Summary: [ML] Merge XGBoost and Ignite ML Trees together
 Key: IGNITE-10718
 URL: https://issues.apache.org/jira/browse/IGNITE-10718
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Affects Versions: 2.8
Reporter: Anton Dmitriev
Assignee: Anton Dmitriev
 Fix For: 2.8


Currently we have two similar hierarchy of trees: XGBoost trees and Ignite ML 
trees. Would be great to merge them together.



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

Re: What is the best approach to extend Thin Client functionality?

[Ilya Kasnacheev]

Hello!

We absolutely have C++ thick client and can implement very complex API on
top of it.

However, there is also push towards thin clients currently since they're
easier to get working.

So naturally you have to decide according to your use cases.

Bonus points if you find a way to go with thin client, that you can also
have the same functionality in Python client, etc...

Regards,
-- 
Ilya Kasnacheev


пн, 17 дек. 2018 г. в 13:02, dmitrievanth...@gmail.com <
dmitrievanth...@gmail.com>:

> Currently ML/TensorFlow module requires an ability to expose some
> functionality to be used in C++ code.
>
> As far as I understand, currently Ignite provides an ability to work with
> it from C++ only through the Thin Client. The list of operations supported
> by it is very limited. What is the best approach to work with additional
> Ignite functionality (like ML/TensorFlow) from C++ code?
>
> I see several ways we can do it:
> 1. Extend list of Thin Client operations. Unfortunately, it will lead to
> overgrowth of API. As result of that it will be harder to implement and
> maintain Thin Clients for different languages.
> 2. Use Thin Client as a "transport layer" and make Ignite functionality
> calls via puts/gets commands/responses into/from cache (like command
> pattern). It's looks a bit confusing to use cache with put/get operations
> as a transport.
> 3. Add custom endpoint that will listen specific port and process custom
> commands. It will introduce a new endpoint and a new protocol.
>
> What do you think about these approaches? Could you suggest any other ways?
>
> To have more concrete discussion lets say we need to functions available
> from C++: "saveModel(name, model)", "getModel(name)" already implemented in
> Ignite ML and available via Java API.
>

Re: Apache Ignite TeamCity Bot - muted tests

[Dmitriy Pavlov]

Investigation parameters: Can leave as empty
Unmute: Manual (don't use auto because of flaky tests)
Text: https://issues.apache.org/jira/browse/IGNITE-N

But anyway, I hope in the nearest future best way to mute test will be to
ignore it using:
@IgniteIgnore
or @Ignore
or Assume.that()

In this case, we will not need TeamCity mutes anymore.

I'm not sure which way of ignoring will be best.

пн, 17 дек. 2018 г. в 17:02, Anton Vinogradov :

> Dmitrii,
>
> My question was mostly about how to mute test properly.
>
>
> On Mon, Dec 17, 2018 at 4:27 PM Dmitrii Ryabov 
> wrote:
>
> > Anton,
> >
> > In the "Mute" column you can find link to the test on TeamCity. On
> > this page you can see test details like run history and current mutes.
> > Here you should be able to unmute existing mutes.
> > пн, 17 дек. 2018 г. в 16:21, Anton Vinogradov :
> > >
> > > Great feature!
> > >
> > > Could you please explain how to have a deal with it?
> > > How should I mite/unmute tests for now?
> > >
> > > On Fri, Dec 14, 2018 at 6:50 PM Dmitriy Pavlov 
> > wrote:
> > >
> > > > We have IgniteIgnore, so we can use it. It seems behavior is the
> same.
> > We
> > > > need just to understand in which case we can get issue ID from TC
> REST
> > (for
> > > > the Bot).
> > > >
> > > > пт, 14 дек. 2018 г. в 17:51, Vyacheslav Daradur  >:
> > > >
> > > > > Dmitry Pavlov,
> > > > >
> > > > > As far as I know, we are able to use following construction to
> ignore
> > > > test:
> > > > > Assume.assumeTrue("link-to-issue", false);
> > > > >
> > > > > On Fri, Dec 14, 2018 at 5:44 PM Dmitriy Pavlov  >
> > > > wrote:
> > > > > >
> > > > > > Thank you, Dmitrii,
> > > > > >
> > > > > >  I've started unmuting tests starting from yesterday.
> > > > > >
> > > > > > Now muted test count was decreased from 3540 to 3408
> > > > > >
> > > > >
> > > >
> >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=mutedProblems_IgniteTests24Java8=%3Cdefault%3E
> > > > > >
> > > > > >
> > > > > > Probably we could automate this activity by auto-unmute, but
> > hopefully,
> > > > > > JUnit4 & @Ignore opportunity will come earlier.
> > > > > >
> > > > > > Sincerely,
> > > > > > Dmitriy Pavlov
> > > > > >
> > > > > > пт, 14 дек. 2018 г. в 17:24, Dmitrii Ryabov <
> somefire...@gmail.com
> > >:
> > > > > >
> > > > > > > Hello, Igniters!
> > > > > > >
> > > > > > > Our Bot got new functionality - it shows tests muted on
> TeamCity
> > and
> > > > > their
> > > > > > > ticket status [1].
> > > > > > >
> > > > > > > So, we can see forgotten mutes for resolved tickets now.
> > > > > > >
> > > > > > > Igniters with rights to unmute tests on TC - please, check this
> > page
> > > > > > > periodically for forgotten mutes.
> > > > > > >
> > > > > > > [1] https://mtcga.gridgain.com/mutes.html
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > > >
> >
>

Re: Apache Ignite TeamCity Bot - muted tests

[Anton Vinogradov]

Dmitrii,

My question was mostly about how to mute test properly.


On Mon, Dec 17, 2018 at 4:27 PM Dmitrii Ryabov 
wrote:

> Anton,
>
> In the "Mute" column you can find link to the test on TeamCity. On
> this page you can see test details like run history and current mutes.
> Here you should be able to unmute existing mutes.
> пн, 17 дек. 2018 г. в 16:21, Anton Vinogradov :
> >
> > Great feature!
> >
> > Could you please explain how to have a deal with it?
> > How should I mite/unmute tests for now?
> >
> > On Fri, Dec 14, 2018 at 6:50 PM Dmitriy Pavlov 
> wrote:
> >
> > > We have IgniteIgnore, so we can use it. It seems behavior is the same.
> We
> > > need just to understand in which case we can get issue ID from TC REST
> (for
> > > the Bot).
> > >
> > > пт, 14 дек. 2018 г. в 17:51, Vyacheslav Daradur :
> > >
> > > > Dmitry Pavlov,
> > > >
> > > > As far as I know, we are able to use following construction to ignore
> > > test:
> > > > Assume.assumeTrue("link-to-issue", false);
> > > >
> > > > On Fri, Dec 14, 2018 at 5:44 PM Dmitriy Pavlov 
> > > wrote:
> > > > >
> > > > > Thank you, Dmitrii,
> > > > >
> > > > >  I've started unmuting tests starting from yesterday.
> > > > >
> > > > > Now muted test count was decreased from 3540 to 3408
> > > > >
> > > >
> > >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=mutedProblems_IgniteTests24Java8=%3Cdefault%3E
> > > > >
> > > > >
> > > > > Probably we could automate this activity by auto-unmute, but
> hopefully,
> > > > > JUnit4 & @Ignore opportunity will come earlier.
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > > пт, 14 дек. 2018 г. в 17:24, Dmitrii Ryabov  >:
> > > > >
> > > > > > Hello, Igniters!
> > > > > >
> > > > > > Our Bot got new functionality - it shows tests muted on TeamCity
> and
> > > > their
> > > > > > ticket status [1].
> > > > > >
> > > > > > So, we can see forgotten mutes for resolved tickets now.
> > > > > >
> > > > > > Igniters with rights to unmute tests on TC - please, check this
> page
> > > > > > periodically for forgotten mutes.
> > > > > >
> > > > > > [1] https://mtcga.gridgain.com/mutes.html
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> > >
>

Re: Place Ignite Abbrev Plugin to ASF Ignite supplementary git repo

[Dmitriy Pavlov]

Hi Igniters,

I've created an empty repository :
New repository ignite-abbrev-plugin.git was created, as requested by
dpavlov.
You may view it at: https://gitbox.apache.org/repos/asf/ignite-abbrev
-plugin.git

Alex G., could you please prepare a PR with your initial changes from
https://github.com/dspavlov/ignite-abbrev-plugin/commit/4b30c1a2cff4ee4a615bc0940327035705198cbc

Later we can start to create changes if other community members agree to
place their work in the ASF repo.

Sincerely,
Dmitriy Pavlov


чт, 19 июл. 2018 г. в 14:04, Dmitry Pavlov :

> Hi Vyacheslav,
>
> For Abbrev plugin I also thought that ASF git repo as primary and
> https://github.com/apacheignite mirror would cover all cases.
>
> Thank you for sharing your vision.
>
> Sincerely,
> Dmitriy Pavlov
>
> чт, 19 июл. 2018 г. в 9:08, Vyacheslav Daradur :
>
>> I vote for a separate repo for the Ignite Abbrev Plugin project.
>>
>> The reason is:
>> Ignite Abbrev Plugin - build on top of IntelliJ Platform SDK [1] and
>> can't be easily packaged without it, moreover, it doesn't depend on
>> Ignite internals (unlike .NET/C++ clients).
>>
>> One more place where we could place the project (if this repo
>> maintained by Ignite's commiters) [2].
>>
>> [1] http://www.jetbrains.org/intellij/sdk/docs/welcome.html
>> [2] https://github.com/apacheignite
>> On Thu, Jul 19, 2018 at 12:48 AM Dmitry Pavlov 
>> wrote:
>> >
>> > Hi Denis,
>> >
>> > This option can be considered also. I have no arguments against this
>> > solution.
>> >
>> > In the same time I think Ignite developer will need pre-build
>> distributive
>> > (Jar) of plugin, probably in /idea subfolder.
>> >
>> > So standalone ASF repo & [build/link to build] in main repo can be still
>> > considered. This option can save checkout time, and reduce main repo
>> size.
>> >
>> > I hope this make sense. I would appreciate Igniter's opinion on this
>> topic.
>> >
>> > Sincerely,
>> > Dmitriy Pavlov
>> >
>> > ср, 18 июл. 2018 г. в 23:05, Denis Magda :
>> >
>> > > Hi Dmitriy,
>> > >
>> > > Yes, I would have this tool at hands soon as I check out Ignite repo
>> and
>> > > start setting it up. However, instead of a new repo let's place it
>> under
>> > > {ignite}/dev-tools folder. What do you think?
>> > >
>> > > --
>> > > Denis
>> > >
>> > > On Wed, Jul 18, 2018 at 4:37 AM Dmitry Pavlov 
>> > > wrote:
>> > >
>> > > > Hi Igniters,
>> > > >
>> > > > There is one mode widely used tool in Apache Ignite, abbreviation
>> plugin
>> > > > for Intelli J Idea. This plugin is used by almost all experienced
>> Ignite
>> > > > contributors.
>> > > >
>> > > > I would like to say thanks to all contributors which created this
>> plugin:
>> > > > vkazakov, sevdokimov, daradurvs, agoncharuk. And because this
>> plugin is
>> > > > also a part of our process I also want to place plugin code to ASF
>> > > > repository.
>> > > >
>> > > > What do you think about placing plugin code to supplementary Apache
>> > > > repository? Please share your vision till 24 July.
>> > > >
>> > > > Sincerely,
>> > > > Dmitriy Pavlov
>> > > >
>> > > >
>> > > >
>> > >
>> https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-IntelliJIdeaPlugin
>> > > >
>> > > >
>> > > > https://github.com/dspavlov/ignite-abbrev-plugin
>> > > >
>> > >
>>
>>
>>
>> --
>> Best Regards, Vyacheslav D.
>>
>

Re: Broken layout of Ignite javadoc on web

[Павлухин Иван]

Dmitriy,

Yep, it looks like the problem is inside assembly/docfiles/javadoc.css

I will try to dig into some time later on a spare time. Of course, if
nobody fixes the problem earlier.
пн, 17 дек. 2018 г. в 15:18, Dmitriy Pavlov :
>
> I see the same, browsers checked: Edge & Chrome. I guess it is not a layout
> is broken, but a style missing.
>
> Unfortunately, I don't know how to fix. Probably we should start research
> from ignite/pom.xml:191
>
> ${basedir}/assembly/docfiles/javadoc.css
>
>
> пн, 17 дек. 2018 г. в 14:32, Павлухин Иван :
>
> > Hi,
> >
> > I noticed that Ignite javadoc layout on web for latest versions has
> > some problems. For example, I see no links near the "Class" at heading
> > of the page [1]. Here is a screenshot [2]. Do you see the same?
> >
> > I was able to build javadoc on my machine. With current configuration
> > I see the same broken layout. After using commenting out customized
> > style sheet configuration (referring to assembly/docfiles/javadoc.css)
> > I was able to obtain an html which renders fine for me.
> >
> > Can anyone suggest a simple solution for this?
> >
> > [1]
> > https://ignite.apache.org/releases/2.7.0/javadoc/org/apache/ignite/cache/eviction/EvictionPolicy.html
> > [2]
> > https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1b257ad73f81cb4698f6105a9d1646295ba55795/javadoc_layout.png
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >



-- 
Best regards,
Ivan Pavlukhin

Re: Apache Ignite TeamCity Bot - muted tests

[Dmitrii Ryabov]

Anton,

In the "Mute" column you can find link to the test on TeamCity. On
this page you can see test details like run history and current mutes.
Here you should be able to unmute existing mutes.
пн, 17 дек. 2018 г. в 16:21, Anton Vinogradov :
>
> Great feature!
>
> Could you please explain how to have a deal with it?
> How should I mite/unmute tests for now?
>
> On Fri, Dec 14, 2018 at 6:50 PM Dmitriy Pavlov  wrote:
>
> > We have IgniteIgnore, so we can use it. It seems behavior is the same. We
> > need just to understand in which case we can get issue ID from TC REST (for
> > the Bot).
> >
> > пт, 14 дек. 2018 г. в 17:51, Vyacheslav Daradur :
> >
> > > Dmitry Pavlov,
> > >
> > > As far as I know, we are able to use following construction to ignore
> > test:
> > > Assume.assumeTrue("link-to-issue", false);
> > >
> > > On Fri, Dec 14, 2018 at 5:44 PM Dmitriy Pavlov 
> > wrote:
> > > >
> > > > Thank you, Dmitrii,
> > > >
> > > >  I've started unmuting tests starting from yesterday.
> > > >
> > > > Now muted test count was decreased from 3540 to 3408
> > > >
> > >
> > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=mutedProblems_IgniteTests24Java8=%3Cdefault%3E
> > > >
> > > >
> > > > Probably we could automate this activity by auto-unmute, but hopefully,
> > > > JUnit4 & @Ignore opportunity will come earlier.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > пт, 14 дек. 2018 г. в 17:24, Dmitrii Ryabov :
> > > >
> > > > > Hello, Igniters!
> > > > >
> > > > > Our Bot got new functionality - it shows tests muted on TeamCity and
> > > their
> > > > > ticket status [1].
> > > > >
> > > > > So, we can see forgotten mutes for resolved tickets now.
> > > > >
> > > > > Igniters with rights to unmute tests on TC - please, check this page
> > > > > periodically for forgotten mutes.
> > > > >
> > > > > [1] https://mtcga.gridgain.com/mutes.html
> > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >

Re: Apache Ignite TeamCity Bot - muted tests

[Anton Vinogradov]

Great feature!

Could you please explain how to have a deal with it?
How should I mite/unmute tests for now?

On Fri, Dec 14, 2018 at 6:50 PM Dmitriy Pavlov  wrote:

> We have IgniteIgnore, so we can use it. It seems behavior is the same. We
> need just to understand in which case we can get issue ID from TC REST (for
> the Bot).
>
> пт, 14 дек. 2018 г. в 17:51, Vyacheslav Daradur :
>
> > Dmitry Pavlov,
> >
> > As far as I know, we are able to use following construction to ignore
> test:
> > Assume.assumeTrue("link-to-issue", false);
> >
> > On Fri, Dec 14, 2018 at 5:44 PM Dmitriy Pavlov 
> wrote:
> > >
> > > Thank you, Dmitrii,
> > >
> > >  I've started unmuting tests starting from yesterday.
> > >
> > > Now muted test count was decreased from 3540 to 3408
> > >
> >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=mutedProblems_IgniteTests24Java8=%3Cdefault%3E
> > >
> > >
> > > Probably we could automate this activity by auto-unmute, but hopefully,
> > > JUnit4 & @Ignore opportunity will come earlier.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > пт, 14 дек. 2018 г. в 17:24, Dmitrii Ryabov :
> > >
> > > > Hello, Igniters!
> > > >
> > > > Our Bot got new functionality - it shows tests muted on TeamCity and
> > their
> > > > ticket status [1].
> > > >
> > > > So, we can see forgotten mutes for resolved tickets now.
> > > >
> > > > Igniters with rights to unmute tests on TC - please, check this page
> > > > periodically for forgotten mutes.
> > > >
> > > > [1] https://mtcga.gridgain.com/mutes.html
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

Re: Abbreviation code-style requirement.

[Dmitriy Pavlov]

Hi Ivan,

I've merged your PR and added permissions to the wiki, please check.

I still feel we need to migrate code to ASF repo. I will try to do
something for that.

Sincerely,
Dmitriy Pavlov

пн, 17 дек. 2018 г. в 13:44, Павлухин Иван :

> Hi,
>
> I did some investigation regarding scala support and it seems that
> version used today (3.0.0) was build without scala support. If nobody
> minds I suggest to build a new version without scala as well.
>
> Also there is a thing that bothers me a little. IDEA throws exception
> in log when a name is abbreviated by plugin (see at the very bottom of
> this message). I build old version on my machine as well and received
> the same. It seems that it was there before my changes. Or it might be
> somehow related to version of IDEA which I used to build the plugin.
>
> 2018-12-17 13:35:10,849 [  21351]  ERROR -
> oring.BaseRefactoringProcessor - Refactorings should not be started
> inside write action
>  because they start progress inside and any read action from the
> progress task would cause the deadlock
> java.lang.Exception
> at
> com.intellij.refactoring.BaseRefactoringProcessor.run(BaseRefactoringProcessor.java:560)
> at
> com.intellij.refactoring.RefactoringImpl.run(RefactoringImpl.java:73)
> at
> org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.rename(IgniteAbbreviationInspection.java:163)
> at
> org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:148)
> at
> org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:121)
> at
> com.intellij.codeInspection.ex.QuickFixWrapper.invoke(QuickFixWrapper.java:75)
> at
> com.intellij.codeInsight.intention.impl.IntentionActionWithTextCaching$MyIntentionAction.invoke(IntentionActionWithTextCaching.java:173)
> at
> com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$invokeIntention$3(ShowIntentionActionsHandler.java:202)
> at
> com.intellij.openapi.application.WriteAction.run(WriteAction.java:105)
> at
> com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.invokeIntention(ShowIntentionActionsHandler.java:204)
> at
> com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$null$1(ShowIntentionActionsHandler.java:179)
> at
> com.intellij.openapi.application.TransactionGuardImpl.runSyncTransaction(TransactionGuardImpl.java:88)
> at
> com.intellij.openapi.application.TransactionGuardImpl.submitTransactionAndWait(TransactionGuardImpl.java:153)
> at
> com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$chooseActionAndInvoke$2(ShowIntentionActionsHandler.java:178)
> at
> com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:139)
> at
> com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:97)
> at
> com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:87)
> at
> com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:73)
> at
> com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.chooseActionAndInvoke(ShowIntentionActionsHandler.java:177)
> at
> com.intellij.codeInsight.intention.impl.IntentionListStep.lambda$applyAction$0(IntentionListStep.java:118)
> at
> com.intellij.openapi.application.TransactionGuardImpl.performUserActivity(TransactionGuardImpl.java:195)
> at
> com.intellij.ui.popup.AbstractPopup.lambda$dispose$8(AbstractPopup.java:1417)
> at com.intellij.util.ui.UIUtil.invokeLaterIfNeeded(UIUtil.java:3097)
> at
> com.intellij.ide.IdeEventQueue.ifFocusEventsInTheQueue(IdeEventQueue.java:183)
> at
> com.intellij.ide.IdeEventQueue.executeWhenAllFocusEventsLeftTheQueue(IdeEventQueue.java:132)
> at
> com.intellij.openapi.wm.impl.FocusManagerImpl.doWhenFocusSettlesDown(FocusManagerImpl.java:190)
> at
> com.intellij.openapi.wm.impl.IdeFocusManagerImpl.doWhenFocusSettlesDown(IdeFocusManagerImpl.java:58)
> at com.intellij.ui.popup.AbstractPopup.dispose(AbstractPopup.java:1411)
> at com.intellij.ui.popup.WizardPopup.dispose(WizardPopup.java:160)
> at
> com.intellij.ui.popup.list.ListPopupImpl.dispose(ListPopupImpl.java:307)
> at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:48)
> at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:44)
> at
> com.intellij.openapi.util.objectTree.ObjectNode$1.execute(ObjectNode.java:138)
> at
> com.intellij.openapi.util.objectTree.ObjectNode$1.execute(ObjectNode.java:107)
> at
> com.intellij.openapi.util.objectTree.ObjectTree.executeActionWithRecursiveGuard(ObjectTree.java:182)
> at
> com.intellij.openapi.util.objectTree.ObjectNode.execute(ObjectNode.java:107)
> at
> 

[jira] [Created] (IGNITE-10717) Behaviour of Binary Marshaller not consistent with Deployment Mode

[Gert Dubois (JIRA)]

Gert Dubois created IGNITE-10717:


 Summary: Behaviour of Binary Marshaller not consistent with 
Deployment Mode
 Key: IGNITE-10717
 URL: https://issues.apache.org/jira/browse/IGNITE-10717
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Gert Dubois
 Attachments: tm-ignite-serialization-poc.zip

When 2 clients submit different versions of the same job to the ignite cluster 
that have conflicting class definitions for the Binary Marshaller (different 
Type of a class field, eg.), the execution fails because of Binary MetaData 
merging even with Deployment Mode ISOLATED specified.

This issue prevents us to support clients that might execute older versions of 
our code (or 3rd party library code) on our Ignite cluster using the default 
Marshalling settings.

I added a sample maven project that contains the code to reproduce the issue 
easily.



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

Re: Code inspection

[Maxim Muzafarov]

Dmitry,

It seems to me that we have two independent issues here.
1. An `Unexpected error during build messages processing in TeamCity`
error message which is related to TC agent configuration. Suppose,
server.log will provide us more details about it. I have to access
there.
2. A new set of inspection rules was introduced in 2018+ IntelliJ IDEA
and they should be disabled in our ignite_inspections_teamcity.xml
configuration file. They are not fixed in the Apache Ignite project
code yet. I've prepared the issue [1] for it. Please, take a look.


Andrey,

I've fixed disabled plugins file according to your suggestions. The
issue [2] is ready. I've re-run `Excluded [Inspections] Core Debug`
suite and the log details show me that now only 3 plugins are enabled:
IDEA CORE, Maven Integration, Properties Support. It seems to me that
it's correct.

[1] https://issues.apache.org/jira/browse/IGNITE-10709
[2] https://issues.apache.org/jira/browse/IGNITE-10682

On Sat, 15 Dec 2018 at 15:22, Dmitriy Pavlov  wrote:
>
> Folks,
>
> There is a strange error on TC
> https://ci.ignite.apache.org/viewLog.html?buildId=2556875=IgniteTests24Java8_InspectionsCore
>
> It appeared after TC update to the latest version.
>
> Sincerely,
> Dmitry Pavlov
>
> пт, 14 дек. 2018 г. в 16:09, Andrey Mashenkov :
>
> > Maxim,
> >
> > PR is incomplete. Some plugins should be disabled with different id\name.
> > Maven plugin shouldn't be disabled as Idea Inspector use it to use Ignite
> > project pom file.
> >
> > Please, find details in ticket.
> >
> >
> > On Fri, Dec 14, 2018 at 12:00 PM Andrey Mashenkov <
> > andrey.mashen...@gmail.com> wrote:
> >
> > > Maxim,
> > >
> > > Thanks, I'll check PR and let you know about results.
> > >
> > > For now, Inspections task execution time looks much better (15-22 min),
> > > but fluctuation is still noticeable.
> > >
> > > On Fri, Dec 14, 2018 at 11:13 AM Maxim Muzafarov 
> > > wrote:
> > >
> > >> Andrey,
> > >>
> > >> Thanks! I've consulted with the IntelliJ IDEA source code and found
> > >> how this disabled plugins file should look like. I've created a new
> > >> issue [1] and prepared PR [2] with the set of disabled plugins (maybe
> > >> not complete set). I don't have access to change corresponding
> > >> `~Excluded [Inspections] Core Debug` test suite properties.
> > >> Can we test this PR?
> > >>
> > >> [1] https://issues.apache.org/jira/browse/IGNITE-10682
> > >> [2] https://github.com/apache/ignite/pull/5666
> > >> On Thu, 13 Dec 2018 at 17:35, Andrey Mashenkov
> > >>  wrote:
> > >> >
> > >> > Maxim,
> > >> >
> > >> > Idea has a file in config directory ./config/disabled_plugins.txt ,
> > you
> > >> can easily find it at you local machine.
> > >> > Teamcity Inspections runner has an option "Disabled plugins" where
> > >> disabled_plugins.txt file content can be set.
> > >> >
> > >> > So, looks like we can disable useless plugins.
> > >> > But I'm not expert and can't suggest changes we can safely apply.
> > >> >
> > >> > On Thu, Dec 13, 2018 at 4:59 PM Maxim Muzafarov 
> > >> wrote:
> > >> >>
> > >> >> Andrey,
> > >> >>
> > >> >> Thank you for solving this issue with GC pauses! I've checked the
> > >> >> given report. The inspections configuration is correct, but it seems
> > >> >> to me that we have enabled by default rules of included plugins (for
> > >> >> instance, KotlinInternalInJava in the report is enabled).
> > >> >>
> > >> >> Can you share more details about `disable plugin` option you found?
> > >> >>
> > >> >> I see that idea instance starts with the default -Didea.plugins.path
> > >> >> system property, can we change it so the plugins will be not loaded
> > by
> > >> >> default?
> > >> >> On Thu, 13 Dec 2018 at 15:45, Andrey Mashenkov
> > >> >>  wrote:
> > >> >> >
> > >> >> > Maxim,
> > >> >> >
> > >> >> > It looks like we can't make logs more verbose due to possible bug,
> > >> I've create a ticket in Jetbrains Jira [1].
> > >> >> > We can just publish idea logs in artefacts as suggested in this
> > >> manual [2].
> > >> >> >
> > >> >> > For now, Inspections logs looks like this one [3].
> > >> >> > Also, would you please to take a look at inspection report and
> > check
> > >> if we missed smth and there are any unwanted inspection turned on.
> > >> >> >
> > >> >> > [1] https://youtrack.jetbrains.com/issue/TW-58422
> > >> >> > [2]
> > >>
> > https://confluence.jetbrains.com/display/TCD10/Reporting+Issues#ReportingIssues-IntelliJIDEAInspections
> > >> >> > [3]
> > >>
> > https://ci.ignite.apache.org/viewLog.html?buildId=2538111=IgniteTests24Java8_ExcludedInspections2=artifacts
> > >> >> >
> > >> >> > On Thu, Dec 13, 2018 at 3:19 PM Dmitriy Pavlov  > >
> > >> wrote:
> > >> >> >>
> > >> >> >> Maxim M, do you know if we can disable inspections by wildcard?
> > E.g.
> > >> >> >> Android* ?
> > >> >> >>
> > >> >> >> чт, 13 дек. 2018 г. в 14:59, Andrey Mashenkov <
> > >> andrey.mashen...@gmail.com>:
> > >> >> >>
> > >> >> >> > Fixed memory issues with increasing heap size and forcing 

Re: Broken layout of Ignite javadoc on web

[Dmitriy Pavlov]

I see the same, browsers checked: Edge & Chrome. I guess it is not a layout
is broken, but a style missing.

Unfortunately, I don't know how to fix. Probably we should start research
from ignite/pom.xml:191

${basedir}/assembly/docfiles/javadoc.css


пн, 17 дек. 2018 г. в 14:32, Павлухин Иван :

> Hi,
>
> I noticed that Ignite javadoc layout on web for latest versions has
> some problems. For example, I see no links near the "Class" at heading
> of the page [1]. Here is a screenshot [2]. Do you see the same?
>
> I was able to build javadoc on my machine. With current configuration
> I see the same broken layout. After using commenting out customized
> style sheet configuration (referring to assembly/docfiles/javadoc.css)
> I was able to obtain an html which renders fine for me.
>
> Can anyone suggest a simple solution for this?
>
> [1]
> https://ignite.apache.org/releases/2.7.0/javadoc/org/apache/ignite/cache/eviction/EvictionPolicy.html
> [2]
> https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1b257ad73f81cb4698f6105a9d1646295ba55795/javadoc_layout.png
>
> --
> Best regards,
> Ivan Pavlukhin
>

[jira] [Created] (IGNITE-10716) Rest clients should call ctx.security().onSessionExpired(subjid) on disconnect to avoid the possible leaking of the memory

[Andrey Aleksandrov (JIRA)]

Andrey Aleksandrov created IGNITE-10716:
---

 Summary: Rest clients should call 
ctx.security().onSessionExpired(subjid) on disconnect to avoid the possible 
leaking of the memory
 Key: IGNITE-10716
 URL: https://issues.apache.org/jira/browse/IGNITE-10716
 Project: Ignite
  Issue Type: Bug
  Components: clients
Affects Versions: 2.7
Reporter: Andrey Aleksandrov
Assignee: Andrey Aleksandrov
 Fix For: 2.8


At the moment ctx.security().onSessionExpired(subjid) didn't called on rest 
session expiration.

It provides the leaking of the memory related to resources that were generated 
during authentification.



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

Re: Set 'TcpDiscoveryVmIpFinder' as default IP finder for tests instead of 'TcpDiscoveryMulticastIpFinder'

[Vyacheslav Daradur]

The task [1] is done.

'TcpDiscoveryVmIpFinder' is default IP finder in tests now.

The IP finder is initialized on per tests class level to avoid hidden
affecting among tests, it means the test methods in the common test
class will use the same IP finder.

You don't need to set up 'TcpDiscoveryVmIpFinder' in your tests
explicitly anymore, also task [2] has been filled to remove related
boilerplate if nobody minds.

[1] https://issues.apache.org/jira/browse/IGNITE-10555
[2] https://issues.apache.org/jira/browse/IGNITE-10715


On Wed, Dec 5, 2018 at 7:17 PM Dmitriy Pavlov  wrote:
>
> ++1
>
> ср, 5 дек. 2018 г. в 18:38, Denis Mekhanikov :
>
> > Andrey,
> >
> > Multi-JVM tests may also use a static IP finder, but it should use some
> > specific port range instead of being shared.
> > Something like 127.0.0.1:48500..48509 would do.
> >
> > Denis
> >
> > ср, 5 дек. 2018 г. в 18:34, Vyacheslav Daradur :
> >
> > > I filled a task [1].
> > >
> > > >> Slava, do you think Platforms tests can be fixed as well or one more
> > > ticket
> > > should be created?
> > >
> > > I'll try to fix them within one ticket, it should be investigated a bit
> > > deeper.
> > >
> > > I'll inform about the task's progress in this thread later.
> > >
> > > Thanks!
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-10555
> > > On Wed, Dec 5, 2018 at 6:28 PM Andrey Mashenkov
> > >  wrote:
> > > >
> > > > Slava,
> > > > +1 for your proposal.
> > > > Is there any ticket for this?
> > > >
> > > > Denis,
> > > > I've just read in nabble thread you suggest to allow multicast finder
> > for
> > > > multiJVM tests
> > > > and I'd think we shouldn't use multicast in test at all (excepts
> > > multicast
> > > > Ip finder self tests of course),
> > > > but e.g. add an assertion to force user to create ipfinder properly.
> > > >
> > > >
> > > > Also, we have a ticket for similar issue in 'examples' module.
> > > > Seems, there are some issues with Platforms module integration.
> > > > Slava, do you think Platforms tests can be fixed as well or one more
> > > ticket
> > > > should be created?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-6826
> > > >
> > > > On Wed, Dec 5, 2018 at 5:55 PM Denis Mekhanikov  > >
> > > > wrote:
> > > >
> > > > > Slava,
> > > > >
> > > > > These are exactly my thoughts, so I fully support you here.
> > > > > I already wrote about it:
> > > > >
> > > > >
> > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/IP-finder-in-tests-td33322.html
> > > > > But I kind of abandoned this activity. Feel free to take over it.
> > > > >
> > > > > Denis
> > > > >
> > > > > ср, 5 дек. 2018 г. в 17:22, Vladimir Ozerov :
> > > > >
> > > > > > Huge +1
> > > > > >
> > > > > > On Wed, Dec 5, 2018 at 5:09 PM Vyacheslav Daradur <
> > > daradu...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > I've found that the project's test framework uses
> > > > > > > 'TcpDiscoveryMulticastIpFinder' as default IP finder for tests
> > and
> > > > > > > there are a lot of tests written by Ignite's experts that
> > override
> > > it
> > > > > > > to 'TcpDiscoveryVmIpFinder'.
> > > > > > >
> > > > > > > Most of our tests starting Ignite nodes in the same JVM, that
> > > allows
> > > > > > > us using shared 'TcpDiscoveryVmIpFinder'.
> > > > > > >
> > > > > > > I think that using of 'TcpDiscoveryMulticastIpFinder' may be
> > useful
> > > > > > > only in platforms tests, BTW multi-JVM tests use the tuned
> > > > > > > 'TcpDiscoveryVmIpFinder'.
> > > > > > >
> > > > > > > I see the following main advantages of using
> > > 'TcpDiscoveryVmIpFinder':
> > > > > > > * reducing possible conflicts in the development environment,
> > when
> > > > > > > nodes from different clusters may find each other;
> > > > > > > * speedup of nodes initial discovery, especially on Windows;
> > > > > > > * avoiding of overwriting 'getConfiguration' and copypasta only
> > to
> > > set
> > > > > > > up static IP finder in tests;
> > > > > > >
> > > > > > > So, I'd suggest changing the default IP finder in tests to
> > > > > > > 'TcpDiscoveryVmIpFinder' as the first step and remove related
> > > > > > > boilerplate as the second step.
> > > > > > >
> > > > > > > What do you think?
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Andrey V. Mashenkov
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >



--
Best Regards, Vyacheslav D.

Re: Set 'TcpDiscoveryVmIpFinder' as default IP finder for tests instead of 'TcpDiscoveryMulticastIpFinder'

[Vyacheslav Daradur]

Andrey Mashenkov, at first sight, I have not seen any problems with
.NET platform.

I believe we need carefully configure ports in platform's examples,
additional actions should not be required.

On Mon, Dec 17, 2018 at 2:35 PM Vyacheslav Daradur  wrote:
>
> The task [1] is done.
>
> 'TcpDiscoveryVmIpFinder' is default IP finder in tests now.
>
> The IP finder is initialized on per tests class level to avoid hidden
> affecting among tests, it means the test methods in the common test
> class will use the same IP finder.
>
> You don't need to set up 'TcpDiscoveryVmIpFinder' in your tests
> explicitly anymore, also task [2] has been filled to remove related
> boilerplate if nobody minds.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-10555
> [2] https://issues.apache.org/jira/browse/IGNITE-10715
>
>
> On Wed, Dec 5, 2018 at 7:17 PM Dmitriy Pavlov  wrote:
> >
> > ++1
> >
> > ср, 5 дек. 2018 г. в 18:38, Denis Mekhanikov :
> >
> > > Andrey,
> > >
> > > Multi-JVM tests may also use a static IP finder, but it should use some
> > > specific port range instead of being shared.
> > > Something like 127.0.0.1:48500..48509 would do.
> > >
> > > Denis
> > >
> > > ср, 5 дек. 2018 г. в 18:34, Vyacheslav Daradur :
> > >
> > > > I filled a task [1].
> > > >
> > > > >> Slava, do you think Platforms tests can be fixed as well or one more
> > > > ticket
> > > > should be created?
> > > >
> > > > I'll try to fix them within one ticket, it should be investigated a bit
> > > > deeper.
> > > >
> > > > I'll inform about the task's progress in this thread later.
> > > >
> > > > Thanks!
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-10555
> > > > On Wed, Dec 5, 2018 at 6:28 PM Andrey Mashenkov
> > > >  wrote:
> > > > >
> > > > > Slava,
> > > > > +1 for your proposal.
> > > > > Is there any ticket for this?
> > > > >
> > > > > Denis,
> > > > > I've just read in nabble thread you suggest to allow multicast finder
> > > for
> > > > > multiJVM tests
> > > > > and I'd think we shouldn't use multicast in test at all (excepts
> > > > multicast
> > > > > Ip finder self tests of course),
> > > > > but e.g. add an assertion to force user to create ipfinder properly.
> > > > >
> > > > >
> > > > > Also, we have a ticket for similar issue in 'examples' module.
> > > > > Seems, there are some issues with Platforms module integration.
> > > > > Slava, do you think Platforms tests can be fixed as well or one more
> > > > ticket
> > > > > should be created?
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-6826
> > > > >
> > > > > On Wed, Dec 5, 2018 at 5:55 PM Denis Mekhanikov  > > >
> > > > > wrote:
> > > > >
> > > > > > Slava,
> > > > > >
> > > > > > These are exactly my thoughts, so I fully support you here.
> > > > > > I already wrote about it:
> > > > > >
> > > > > >
> > > >
> > > http://apache-ignite-developers.2346864.n4.nabble.com/IP-finder-in-tests-td33322.html
> > > > > > But I kind of abandoned this activity. Feel free to take over it.
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > ср, 5 дек. 2018 г. в 17:22, Vladimir Ozerov :
> > > > > >
> > > > > > > Huge +1
> > > > > > >
> > > > > > > On Wed, Dec 5, 2018 at 5:09 PM Vyacheslav Daradur <
> > > > daradu...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > > I've found that the project's test framework uses
> > > > > > > > 'TcpDiscoveryMulticastIpFinder' as default IP finder for tests
> > > and
> > > > > > > > there are a lot of tests written by Ignite's experts that
> > > override
> > > > it
> > > > > > > > to 'TcpDiscoveryVmIpFinder'.
> > > > > > > >
> > > > > > > > Most of our tests starting Ignite nodes in the same JVM, that
> > > > allows
> > > > > > > > us using shared 'TcpDiscoveryVmIpFinder'.
> > > > > > > >
> > > > > > > > I think that using of 'TcpDiscoveryMulticastIpFinder' may be
> > > useful
> > > > > > > > only in platforms tests, BTW multi-JVM tests use the tuned
> > > > > > > > 'TcpDiscoveryVmIpFinder'.
> > > > > > > >
> > > > > > > > I see the following main advantages of using
> > > > 'TcpDiscoveryVmIpFinder':
> > > > > > > > * reducing possible conflicts in the development environment,
> > > when
> > > > > > > > nodes from different clusters may find each other;
> > > > > > > > * speedup of nodes initial discovery, especially on Windows;
> > > > > > > > * avoiding of overwriting 'getConfiguration' and copypasta only
> > > to
> > > > set
> > > > > > > > up static IP finder in tests;
> > > > > > > >
> > > > > > > > So, I'd suggest changing the default IP finder in tests to
> > > > > > > > 'TcpDiscoveryVmIpFinder' as the first step and remove related
> > > > > > > > boilerplate as the second step.
> > > > > > > >
> > > > > > > > What do you think?
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Andrey V. Mashenkov
> > > >
> > > >
> > 

Re: Page eviction for in-memory mode with enabled MVCC

[Roman Kondakov]

Ivan,

probably you are right. The main usage of in-memory cache with allowed 
evictions is a caching layer for third party stores. And the fact that 
page eviction is not a transactional process by the nature, forces user 
to use workarounds (i.e. explicit locking) to prevent evictions of the 
hot data. This workaround is quite a heavyweight solution as well. Using 
explicit locking (select for update, etc.) for each read request may 
lead to the increased number of aborted transactions due to the need to 
obtain an exclusive lock for each key we read. The repeatable read 
semantics for MVCC caches with evictions will result to the performance 
drop, which makes useless this application of MVCC caches.


Perhaps, we should prohibit MVCC caches creations in regions with 
configured eviction policy, as you proposed?


Igor, Vladimir, what do you think?


--
Kind Regards
Roman Kondakov

On 17.12.2018 8:53, Павлухин Иван wrote:

Roman,

Thank you for pointing out usage as an in-memory cache. I will try to
describe how do I see the use case.

First of all our MVCC caches provides transactions. And a user will
choose MVCC if his workflow is transactional. If a use case is a
caching layer then some backing storage is assumed. But we have not
yet well integrated support for 3rd party persistence [1]. And I think
that it is better to cover whole track in complex.

Of course there might be another valid use cases which I am not aware
of. Please point me out if you have one in mind.

[1] https://apacheignite.readme.io/docs/3rd-party-store

2018-12-14 18:40 GMT+03:00, Seliverstov Igor :

Roman,

I would prefer first option.

The fact user uses MVCC says he needs some more strict guaranties which
cannot meet in other modes.
I would rollback both txs in case we cannot provide such guaranties.

Regards,
Igor

пт, 14 дек. 2018 г. в 15:36, Roman Kondakov :


Vladimir,

I was thinking about your proposal to not evict locked and recent (the
transaction that created the record is still active) entries from the
cache. Let's imagine next situation: we have almost full memory and two
transactions:

1. txA: "SELECT * FOR UPDATE"

2. txB: "INSERT ...many keys here..."

In this case txA locks all entries in the cache, and therefore we cannot
evict any of them. If then txB is trying to add a lot of data, it lead
us to the OOM situation, which user is trying to avoid using cache
evictions.

I see two ways how to deal with this issue:

1. Allow OOM in MVCC caches with configured evictions and warn user
about it in the docs.

2. Give up with the repeatable read guaranties in case of evictions for
MVCC caches and warn users about it in the documentation.

Second variant looks better for me because user may not expect OOM when
he has configured eviction policy for cache.

What do you think?


--
Kind Regards
Roman Kondakov

On 13.12.2018 22:33, Vladimir Ozerov wrote:

It's hard to believe that entries are not locked on backups, because we
wrtite data right away. Even if it so, it should be very easy to fix -

just

do not evict and entry if it was created or deleted by currently active
transaction.

On Thu, Dec 13, 2018 at 10:28 PM Roman Kondakov



wrote:


Vladimir,

we do not lock entries on backups when MVCC is enabled and therefore
we
don't avoid entry eviction from backup by locking. So, your first
scenario with primary stop is still relevant.


--
Kind Regards
Roman Kondakov

On 13.12.2018 22:14, Vladimir Ozerov wrote:

No, I mean that we should think about what kind of guarantees it

possible.

My proposal was to prevent evictions of locked entries. This way we
can

say

users: "if you want true REPEATABLE_READ when evictions are enabled,

then

make sure to lock entries on every access". This effectively means
that

all

SELECT's should be replaced with "SELECT FOR UPDATE".

On Thu, Dec 13, 2018 at 10:09 PM Roman Kondakov



wrote:


Vladimir,

correct me please if i misunderstood your thought. So, if eviction
is
not about a consistency at all, we may evict keys in any way because
broken repeatable read semantics is not the biggest problem here.
But

we

should add some notes about it to user documentation. Right?


--
Kind Regards
Roman Kondakov

On 13.12.2018 17:45, Vladimir Ozerov wrote:

Roman,

I would start with the fact that eviction can never be consistent

unless

it

utilizes atomic broadcast protocol, which is not the case for
Ignite.

In

Ignite entries on node are evicted independently.

So you may easily get into situation like this:
1) Start a cache with 1 backup and FULL_SYNC mode
2) Put a key to primary node
3) Stop primary
4) Try reading from new primary and get null because key was
evicted
concurrently

Or:
1) Start a transaction in PESSIMISTIC/READ_COMMITTED mode
2) Read a key, get value
3) Read the same key again, get null

So in reality the choice is not between consistent and inconsistent
behavior, but rather about degree of inconsistency. Any solution is
possible as long as we can explain it to the 

Broken layout of Ignite javadoc on web

[Павлухин Иван]

Hi,

I noticed that Ignite javadoc layout on web for latest versions has
some problems. For example, I see no links near the "Class" at heading
of the page [1]. Here is a screenshot [2]. Do you see the same?

I was able to build javadoc on my machine. With current configuration
I see the same broken layout. After using commenting out customized
style sheet configuration (referring to assembly/docfiles/javadoc.css)
I was able to obtain an html which renders fine for me.

Can anyone suggest a simple solution for this?

[1] 
https://ignite.apache.org/releases/2.7.0/javadoc/org/apache/ignite/cache/eviction/EvictionPolicy.html
[2] 
https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1b257ad73f81cb4698f6105a9d1646295ba55795/javadoc_layout.png

-- 
Best regards,
Ivan Pavlukhin

[jira] [Created] (IGNITE-10715) Remove boilerplate of settings 'TcpDiscoveryVmIpFinder' in tests

[Vyacheslav Daradur (JIRA)]

Vyacheslav Daradur created IGNITE-10715:
---

 Summary: Remove boilerplate of settings 'TcpDiscoveryVmIpFinder' 
in tests
 Key: IGNITE-10715
 URL: https://issues.apache.org/jira/browse/IGNITE-10715
 Project: Ignite
  Issue Type: Task
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
 Fix For: 2.8


It's necessary to remove boilerplate of settings 'TcpDiscoveryVmIpFinder' in 
tests since this is default IP finder in tests after IGNITE-10555.



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

[jira] [Created] (IGNITE-10714) MVCC TX: JTA transaction manager.

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-10714:
-

 Summary: MVCC TX: JTA transaction manager.
 Key: IGNITE-10714
 URL: https://issues.apache.org/jira/browse/IGNITE-10714
 Project: Ignite
  Issue Type: Bug
Reporter: Igor Seliverstov


Add JTA transactions support for MVCC transactions



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

Re: Abbreviation code-style requirement.

[Павлухин Иван]

Hi,

I did some investigation regarding scala support and it seems that
version used today (3.0.0) was build without scala support. If nobody
minds I suggest to build a new version without scala as well.

Also there is a thing that bothers me a little. IDEA throws exception
in log when a name is abbreviated by plugin (see at the very bottom of
this message). I build old version on my machine as well and received
the same. It seems that it was there before my changes. Or it might be
somehow related to version of IDEA which I used to build the plugin.

2018-12-17 13:35:10,849 [  21351]  ERROR -
oring.BaseRefactoringProcessor - Refactorings should not be started
inside write action
 because they start progress inside and any read action from the
progress task would cause the deadlock
java.lang.Exception
at 
com.intellij.refactoring.BaseRefactoringProcessor.run(BaseRefactoringProcessor.java:560)
at com.intellij.refactoring.RefactoringImpl.run(RefactoringImpl.java:73)
at 
org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.rename(IgniteAbbreviationInspection.java:163)
at 
org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:148)
at 
org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:121)
at 
com.intellij.codeInspection.ex.QuickFixWrapper.invoke(QuickFixWrapper.java:75)
at 
com.intellij.codeInsight.intention.impl.IntentionActionWithTextCaching$MyIntentionAction.invoke(IntentionActionWithTextCaching.java:173)
at 
com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$invokeIntention$3(ShowIntentionActionsHandler.java:202)
at com.intellij.openapi.application.WriteAction.run(WriteAction.java:105)
at 
com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.invokeIntention(ShowIntentionActionsHandler.java:204)
at 
com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$null$1(ShowIntentionActionsHandler.java:179)
at 
com.intellij.openapi.application.TransactionGuardImpl.runSyncTransaction(TransactionGuardImpl.java:88)
at 
com.intellij.openapi.application.TransactionGuardImpl.submitTransactionAndWait(TransactionGuardImpl.java:153)
at 
com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$chooseActionAndInvoke$2(ShowIntentionActionsHandler.java:178)
at 
com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:139)
at 
com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:97)
at 
com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:87)
at 
com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:73)
at 
com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.chooseActionAndInvoke(ShowIntentionActionsHandler.java:177)
at 
com.intellij.codeInsight.intention.impl.IntentionListStep.lambda$applyAction$0(IntentionListStep.java:118)
at 
com.intellij.openapi.application.TransactionGuardImpl.performUserActivity(TransactionGuardImpl.java:195)
at 
com.intellij.ui.popup.AbstractPopup.lambda$dispose$8(AbstractPopup.java:1417)
at com.intellij.util.ui.UIUtil.invokeLaterIfNeeded(UIUtil.java:3097)
at 
com.intellij.ide.IdeEventQueue.ifFocusEventsInTheQueue(IdeEventQueue.java:183)
at 
com.intellij.ide.IdeEventQueue.executeWhenAllFocusEventsLeftTheQueue(IdeEventQueue.java:132)
at 
com.intellij.openapi.wm.impl.FocusManagerImpl.doWhenFocusSettlesDown(FocusManagerImpl.java:190)
at 
com.intellij.openapi.wm.impl.IdeFocusManagerImpl.doWhenFocusSettlesDown(IdeFocusManagerImpl.java:58)
at com.intellij.ui.popup.AbstractPopup.dispose(AbstractPopup.java:1411)
at com.intellij.ui.popup.WizardPopup.dispose(WizardPopup.java:160)
at com.intellij.ui.popup.list.ListPopupImpl.dispose(ListPopupImpl.java:307)
at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:48)
at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:44)
at 
com.intellij.openapi.util.objectTree.ObjectNode$1.execute(ObjectNode.java:138)
at 
com.intellij.openapi.util.objectTree.ObjectNode$1.execute(ObjectNode.java:107)
at 
com.intellij.openapi.util.objectTree.ObjectTree.executeActionWithRecursiveGuard(ObjectTree.java:182)
at 
com.intellij.openapi.util.objectTree.ObjectNode.execute(ObjectNode.java:107)
at 
com.intellij.openapi.util.objectTree.ObjectTree.executeAll(ObjectTree.java:151)
at com.intellij.openapi.util.Disposer.dispose(Disposer.java:129)
at com.intellij.openapi.util.Disposer.dispose(Disposer.java:125)
at com.intellij.ui.popup.WizardPopup.disposeAllParents(WizardPopup.java:263)
at 
com.intellij.ui.popup.list.ListPopupImpl.handleNextStep(ListPopupImpl.java:442)
at 

Re: What is the best approach to extend Thin Client functionality?

[Igor Sapego]

Hello,

First of all, it would help to know what is the functionality you need,
to give you an answer. Can you scribed required API?

Best Regards,
Igor


On Mon, Dec 17, 2018 at 1:02 PM dmitrievanth...@gmail.com <
dmitrievanth...@gmail.com> wrote:

> Currently ML/TensorFlow module requires an ability to expose some
> functionality to be used in C++ code.
>
> As far as I understand, currently Ignite provides an ability to work with
> it from C++ only through the Thin Client. The list of operations supported
> by it is very limited. What is the best approach to work with additional
> Ignite functionality (like ML/TensorFlow) from C++ code?
>
> I see several ways we can do it:
> 1. Extend list of Thin Client operations. Unfortunately, it will lead to
> overgrowth of API. As result of that it will be harder to implement and
> maintain Thin Clients for different languages.
> 2. Use Thin Client as a "transport layer" and make Ignite functionality
> calls via puts/gets commands/responses into/from cache (like command
> pattern). It's looks a bit confusing to use cache with put/get operations
> as a transport.
> 3. Add custom endpoint that will listen specific port and process custom
> commands. It will introduce a new endpoint and a new protocol.
>
> What do you think about these approaches? Could you suggest any other ways?
>
> To have more concrete discussion lets say we need to functions available
> from C++: "saveModel(name, model)", "getModel(name)" already implemented in
> Ignite ML and available via Java API.
>

[jira] [Created] (IGNITE-10713) [ML] Refactor examples with accuracy calculation and another metrics usage

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-10713:
-

 Summary: [ML] Refactor examples with accuracy calculation and 
another metrics usage
 Key: IGNITE-10713
 URL: https://issues.apache.org/jira/browse/IGNITE-10713
 Project: Ignite
  Issue Type: Sub-task
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev


Avoid manual calculation of accuracy, use evaluator instead of counters in 
examples



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

[jira] [Created] (IGNITE-10712) Control.sh add ability to get cluster metrics

[Sergey Antonov (JIRA)]

Sergey Antonov created IGNITE-10712:
---

 Summary: Control.sh add ability to get cluster metrics
 Key: IGNITE-10712
 URL: https://issues.apache.org/jira/browse/IGNITE-10712
 Project: Ignite
  Issue Type: New Feature
Reporter: Sergey Antonov
 Fix For: 3.0






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

[jira] [Created] (IGNITE-10711) [ML] [Umbrella] Provide metrics to evaluate the quality of model

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-10711:
-

 Summary: [ML] [Umbrella] Provide metrics to evaluate the quality 
of model
 Key: IGNITE-10711
 URL: https://issues.apache.org/jira/browse/IGNITE-10711
 Project: Ignite
  Issue Type: New Feature
  Components: ml
Affects Versions: 2.8
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev
 Fix For: 2.8


This is an umbrella ticket for all metric-related tickets



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

What is the best approach to extend Thin Client functionality?

[dmitrievanthony]

Currently ML/TensorFlow module requires an ability to expose some functionality 
to be used in C++ code. 

As far as I understand, currently Ignite provides an ability to work with it 
from C++ only through the Thin Client. The list of operations supported by it 
is very limited. What is the best approach to work with additional Ignite 
functionality (like ML/TensorFlow) from C++ code?

I see several ways we can do it:
1. Extend list of Thin Client operations. Unfortunately, it will lead to 
overgrowth of API. As result of that it will be harder to implement and 
maintain Thin Clients for different languages.
2. Use Thin Client as a "transport layer" and make Ignite functionality calls 
via puts/gets commands/responses into/from cache (like command pattern). It's 
looks a bit confusing to use cache with put/get operations as a transport.
3. Add custom endpoint that will listen specific port and process custom 
commands. It will introduce a new endpoint and a new protocol.

What do you think about these approaches? Could you suggest any other ways?

To have more concrete discussion lets say we need to functions available from 
C++: "saveModel(name, model)", "getModel(name)" already implemented in Ignite 
ML and available via Java API.

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

[Павлухин Иван]

Hi Oleg,

The things become challenging. Truly I do not see any trivial solution
so far. Could you please outline main problems which we are facing
today? And how many tests are affected? Some clarifying questions:
1. I know that setup->test->teardown threading was changed for junit4
tests, but actually I thought that it might affect only small number
of tests. Am I right here?
2. Also I saw that in your experiment [1] some changes related to
TestCounters were made. What is wrong with them?
3. Why do we need wrap test execution into critical section
(runSerializer lock)? I thought that we always run tests serially.

I generally like an idea of having workaround falling back to old test
execution flow. But for me the most desired trait of things like
LegacySupport is being lightweight and enabled only on purpose. And
from the first glance current prototype looks a little bit
complicated. As an alternative we can keep junit3 for troublesome
tests, can't we?

Also is there any vision how many migration problems do we have so far
and how many tests was not migrated yet?
вс, 16 дек. 2018 г. в 17:39, oignatenko :
>
> Hi Ivan,
>
> As promised in my prior mail, here is the branch where I experimented to
> address concerns you raised:
> - https://github.com/gridgain/apache-ignite/tree/ignite-10177-experimental
>
> I tested it locally and on Teamcity and it worked as intended.
>
> I think I managed to exactly reproduce execution sequence of JUnit 3 test
> case so that tests designed expecting it will run exactly as it was before.
>
> As for troublesome APIs I used deprecation to warn developers agains using
> these and recommend what they need to use instead.
>
> If you are interested in closer studying the changes, class
> GridAbstractTest1 is probably best as a starting point. This class is a
> temporary copy of GridAbstractTest made to minimise amount of editing in
> dependent classes while I was experimenting; in real implementation (per
> IGNITE-10177) this code is expected to be in GridAbstractTest.
>
> Also, I used ML testsuite to debug the changes I made, because it contains
> convenient mix of usecases and runs fast.
>
> Your feedback is much appreciated.
>
> regards, Oleg
>
>
> Павлухин Иван wrote
> > Hi guys,
> >
> > I started writing a junit4 test for a feature I am currently working
> > on. And immediately I faced a peculiarity with @Before test fixture. I
> > automatically named a method "setUp" and realized that I override a
> > method from a superclass. It can produce unwanted effects. First, it
> > looks reasonable to call a corresponding superclass method in an
> > overridden method, but in my understanding it is not a canonical way
> > in junit4. Second, in junit4 overriding method annotated with @Before
> > can lead changing order of this method execution among other @Before
> > method. Second point might lead to surprising effects in tests
> > hierarchies defining @Before methods on different levels.
> >
> > Let's return to the test I mentioned in the beginning of current
> > email. I decided to use a different name for my @Before method
> > (actually it was unpleasant "setUp1"). I think that we can do the
> > following to make things straightforward:
> > 1. Prohibit overriding base class setUp and tearDown methods by making
> > them final (at least in GridCommonAbstractTest and
> > GridSpiAbstractTest).
> > 2. Use common default name for @Before and @After methods defined in
> > concrete test classes. I do not have really good candidates for names.
> > Simply we can use setUp1, tearDown1. Another option initTest,
> > cleanupTest. Your name candidates are quite appreciated.
> >
> > WDYT?
> >
> > P.S. Also I went through other tests and found really dangerous thing.
> > In IgniteJmsStreamerTest (not migrated to junit4 yet) we have
> > beforeTest method (overriding GridAbstractTest framework method)
> > annotated with @Before annotation (I believe accidentally)! It means
> > that migrating such test to junit4 will lead to calling beforeTest
> > twice. Ouch!
> > ср, 12 дек. 2018 г. в 13:21, Павлухин Иван 
>
> > vololo100@
>
> > :
> >>
> >> Hi Oleg,
> >>
> >> Thanks your for detailed answer. Using junit4 annotations where
> >> possible sounds good to me.
> >>
> >> Also I would like to thank everybody involved in migration to junit4
> >> process for your efforts. You were able to move a problem which looked
> >> mountain-heavy. I believe that is a significant milestone on Ignite
> >> stabilization road.
> >>
> >> Well done!
> >> вт, 11 дек. 2018 г. в 20:20, oignatenko 
>
> > oignatenko@
>
> > :
> >> >
> >> > Hi Ivan,
> >> >
> >> > That's a very good question and I think you spotted a point where
> >> Ignite
> >> > test developer's preferences need to change when migrating from Junit 3
> >> to
> >> > 4.
> >> >
> >> > In brief, when developing under JUnit 3 there were good reasons to
> >> prefer
> >> > our homebrew template methods (beforeTestsStarted, beforeTest,
> >> afterTest,
> >> > 

[jira] [Created] (IGNITE-10710) Document new REST API for baseline topology command.

[Andrey Novikov (JIRA)]

Andrey Novikov created IGNITE-10710:
---

 Summary: Document new REST API for baseline topology command.
 Key: IGNITE-10710
 URL: https://issues.apache.org/jira/browse/IGNITE-10710
 Project: Ignite
  Issue Type: Task
  Components: documentation
Affects Versions: 2.8
Reporter: Andrey Novikov
 Fix For: 2.8






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

[jira] [Created] (IGNITE-10709) New inspections introduced in 2018+ IntelliJ IDEA version must be disabled on TC configuration

[Maxim Muzafarov (JIRA)]

Maxim Muzafarov created IGNITE-10709:


 Summary: New inspections introduced in 2018+ IntelliJ IDEA version 
must be disabled on TC configuration
 Key: IGNITE-10709
 URL: https://issues.apache.org/jira/browse/IGNITE-10709
 Project: Ignite
  Issue Type: Task
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov


IntelliJ IDEA since 2018.1 version has new inspection rules enabled by default. 
This leads to the {{[Inspections] Core}} suite fail as these rules are not 
fixed in the Apache Ignite project code.

We need to add and disable them in {{ignite_inspections_teamcity.xml}} 
configuration file.



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