[jira] [Created] (IGNITE-8314) Web console: add a new type of reusable loading indicator

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-8314:


 Summary: Web console: add a new type of reusable loading indicator
 Key: IGNITE-8314
 URL: https://issues.apache.org/jira/browse/IGNITE-8314
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Ilya Borisov
Assignee: Ilya Borisov


The thin red line under the header of newer-style table was supposed to be a 
loading progress indicator. The component that implements the line progress 
indicator should:

1. Support finished (100%) and indeterminate states. The in-between state can 
be added later.
 2. Indeterminate state should have an animation.
 3. Look like a 1px high red line in finished state.

The implementation might look something like this:
{code}
Indeterminate:

Complete:

{code}



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

[GitHub] ignite pull request #3871: IGNITE-8286: ScanQuery ignore setLocal with non l...

[shroman]

GitHub user shroman opened a pull request:

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

IGNITE-8286: ScanQuery ignore setLocal with non local partition.



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

$ git pull https://github.com/shroman/ignite IGNITE-8286

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

https://github.com/apache/ignite/pull/3871.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3871


commit f4c751c98840154fc29d069582de2b272b6e14a5
Author: shroman 
Date:   2018-04-19T02:38:14Z

IGNITE-8286: ScanQuery ignore setLocal with non local partition.




---

Re: Please add me to contributors

[Denis Magda]

Andrew, you're in, enjoy!

--
Denis

On Wed, Apr 18, 2018 at 5:02 AM, Andrew Medvedev <
andrew.y.medve...@gmail.com> wrote:

> Hi everybody.
>
> Please add me to contributors
> My name is Andrew Medvedev
> My Jira Id is "andmed"
>
> Best
> Andrew
>

Re: [IGNITE-7909]: Java code examples are needed for Spark Data Frames.

[Nikolay Izhikov]

Hello, Akmal.

I see 3 pull requests attached to the ticket [1], [2], [3].
I see 3 java files attached to the ticket, also.

Which changes you want to be reviewed and merge? Please, clarify.

Delete all unnecessary pull requests link from the ticket.
Add new examples to the tests so we can test it on the Team City.
You can take IgniteDataFrameSelfTest as an example.

I also suggest to rename java examples with "Java" prefix.

IgniteDataFrameWriteExample.java -> JavaIgniteDataFrameWriteExample.java

[1] https://github.com/apache/ignite/pull/3857
[2] https://github.com/apache/ignite/pull/3858I
[3] https://github.com/apache/ignite/pull/3859
[4] 
https://github.com/apache/ignite/blob/master/examples/src/test/spark/org/apache/ignite/spark/examples/IgniteDataFrameSelfTest.java




В Ср, 18/04/2018 в 17:20 +0100, Akmal Chaudhri пишет:
> If any community members have time, please review the code. Three Java
> files are attached to the Jira ticket:
> 
> https://issues.apache.org/jira/browse/IGNITE-7909
> 
> The code should be functionally equivalent to the Scala Data Frames code
> that was shipped in 2.4.
> 
> Data Frame documentation is here:
> 
> https://apacheignite-fs.readme.io/docs/ignite-data-frame
> 
> Thank you!

signature.asc
Description: This is a digitally signed message part

[GitHub] ignite pull request #3865: IGNITE-8302 Reduce test IO consumption in case Di...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3850: IGNITE-8243 Fixed possible memory leak

[asfgit]

Github user asfgit closed the pull request at:

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


---

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

[Pavel Kovalenko]

Ivan,

I think your version is better, because it handles cases when several nodes
are left sequentially, so no needs to shrink baseline for each node left.
New version also saves some resources using internal scheduler.

2018-04-18 20:41 GMT+03:00 Ivan Rakov :

> I can suggest an improvement to BaselineWatcher by Pavel. I've added a new
> version to https://issues.apache.org/jira/browse/IGNITE-8241 comments.
> Pavel, what do you think?
>
> Best Regards,
> Ivan Rakov
>
>
> On 17.04.2018 20:47, Denis Magda wrote:
>
>> Thanks, Pavel!
>>
>> Alexey, Ivan, could you check that there are no any pitfalls in the
>> example
>> and it can be used as a template for our users?
>> https://issues.apache.org/jira/secure/attachment/12919452/
>> BaselineWatcher.java
>>
>> --
>> Denis
>>
>> On Tue, Apr 17, 2018 at 10:40 AM, Pavel Kovalenko 
>> wrote:
>>
>> Denis,
>>>
>>> I've attached example how to manage baseline automatically (It's named
>>> BaselineWatcher). It's just an concept and doesn't cover all possible
>>> cases, but might be good for a start.
>>>
>>> 2018-04-13 2:14 GMT+03:00 Denis Magda :
>>>
>>> Pavel, thanks for the suggestions. They would definitely work out. I

>>> would
>>>
 document the one with the event subscription:
 https://issues.apache.org/jira/browse/IGNITE-8241

 Could you help preparing a sample code snippet with such a listener that
 will be added to the doc? I know that there are some caveats related to

>>> the
>>>
 way how such an event has to be processed.

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

 --
 Denis

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

>>> wrote:
>>>
 Guys,
>
> I also heard complaints about absence of option to automatically change
> baseline topology. They absolutely make sense.
> What Pavel suggested will work as a workaround. I think, in future
> releases we should give user an option to enable a similar behavior via
> Ignite Configuration.
> It may be called "Baseline Topology change policy". I see it as
>
 rule-based

> language, which allows to specify conditions of BLT change using
>
 several
>>>
 parameters - timeout and minimum allowed number of partition copies
>
 left
>>>
 (maybe this option should be provided also on per-cache-group level).
> Policy can also specify conditions for including new nodes in BLT if
>
 they
>>>
 are present - including node attributes filters and so on.
>
> What do you think?
>
> Best Regards,
> Ivan Rakov
>
>
> On 12.04.2018 19:41, Pavel Kovalenko wrote:
>
> Denis,
>>
>> It's just one of the ways to implement it. We also can subscribe on
>>
> node
>>>
 join / fail events to properly track downtime of a node.
>>
>> 2018-04-12 19:38 GMT+03:00 Pavel Kovalenko :
>>
>> Denis,
>>
>>> Using our API we can implement this task as follows:
>>> Do each minute:
>>> 1) Get all alive server nodes consistent ids =>
>>> ignite().context().discovery().aliveServerNodes() =>
>>> mapToConsistentIds().
>>> 2) Get current baseline topology => ignite().cluster().
>>> currentBaselineTopology()
>>> 3) For each node in baseline and not in alive server nodes check
>>>
>> timeout

> for this node.
>>> 4) If timeout is reached remove node from baseline
>>> 5) If baseline is changed set new baseline => ignite().cluster().
>>> setNewBaseline()
>>>
>>>
>>> 2018-04-12 2:18 GMT+03:00 Denis Magda :
>>>
>>> Pavel, Val,
>>>
 So, it means that the rebalancing will be initiated only after an
 administrator remove the failed node from the topology, right?

 Next, imagine that you are that IT administrator who has to automate

>>> the

> rebalancing activation if the node failed and not recovered within 1
 minute. What would you do and what Ignite provides to fulfill the

>>> task?

> --
 Denis

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

>>> jokse...@gmail.com>
>>>
 wrote:

 Denis,

> In case of incomplete baseline topology IgniteCache.rebalance()
>
 will
>>>
 do

> nothing, because this event doesn't trigger partitions exchange or
>
> affinity

 change, so states of existing partitions are hold.
>
> 2018-04-11 22:27 GMT+03:00 Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
> Denis,
>
>> In my understanding, in this case you should remove node from BLT
>>
> and

> that
>
> will trigger the 

[GitHub] ignite pull request #2400: Fail tests with issue link

[dspavlov]

Github user dspavlov closed the pull request at:

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


---

[jira] [Created] (IGNITE-8313) Trace logs enhancement for exchange and affinity calculation

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8313:
---

 Summary: Trace logs enhancement for exchange and affinity 
calculation
 Key: IGNITE-8313
 URL: https://issues.apache.org/jira/browse/IGNITE-8313
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.6


For better problems debugging we should add more trace logs to following places:
1) Partition states before and after exchange.
2) Affinity distribution for each topology version.



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

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

[Ivan Rakov]

I can suggest an improvement to BaselineWatcher by Pavel. I've added a 
new version to https://issues.apache.org/jira/browse/IGNITE-8241 comments.

Pavel, what do you think?

Best Regards,
Ivan Rakov

On 17.04.2018 20:47, Denis Magda wrote:

Thanks, Pavel!

Alexey, Ivan, could you check that there are no any pitfalls in the example
and it can be used as a template for our users?
https://issues.apache.org/jira/secure/attachment/12919452/BaselineWatcher.java

--
Denis

On Tue, Apr 17, 2018 at 10:40 AM, Pavel Kovalenko 
wrote:


Denis,

I've attached example how to manage baseline automatically (It's named
BaselineWatcher). It's just an concept and doesn't cover all possible
cases, but might be good for a start.

2018-04-13 2:14 GMT+03:00 Denis Magda :


Pavel, thanks for the suggestions. They would definitely work out. I

would

document the one with the event subscription:
https://issues.apache.org/jira/browse/IGNITE-8241

Could you help preparing a sample code snippet with such a listener that
will be added to the doc? I know that there are some caveats related to

the

way how such an event has to be processed.

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

--
Denis

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

wrote:

Guys,

I also heard complaints about absence of option to automatically change
baseline topology. They absolutely make sense.
What Pavel suggested will work as a workaround. I think, in future
releases we should give user an option to enable a similar behavior via
Ignite Configuration.
It may be called "Baseline Topology change policy". I see it as

rule-based

language, which allows to specify conditions of BLT change using

several

parameters - timeout and minimum allowed number of partition copies

left

(maybe this option should be provided also on per-cache-group level).
Policy can also specify conditions for including new nodes in BLT if

they

are present - including node attributes filters and so on.

What do you think?

Best Regards,
Ivan Rakov


On 12.04.2018 19:41, Pavel Kovalenko wrote:


Denis,

It's just one of the ways to implement it. We also can subscribe on

node

join / fail events to properly track downtime of a node.

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

Denis,

Using our API we can implement this task as follows:
Do each minute:
1) Get all alive server nodes consistent ids =>
ignite().context().discovery().aliveServerNodes() =>
mapToConsistentIds().
2) Get current baseline topology => ignite().cluster().
currentBaselineTopology()
3) For each node in baseline and not in alive server nodes check

timeout

for this node.
4) If timeout is reached remove node from baseline
5) If baseline is changed set new baseline => ignite().cluster().
setNewBaseline()


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

Pavel, Val,

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

Next, imagine that you are that IT administrator who has to automate

the

rebalancing activation if the node failed and not recovered within 1
minute. What would you do and what Ignite provides to fulfill the

task?

--
Denis

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

jokse...@gmail.com>

wrote:

Denis,

In case of incomplete baseline topology IgniteCache.rebalance()

will

do

nothing, because this event doesn't trigger partitions exchange or


affinity


change, so states of existing partitions are hold.

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

Denis,

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

and

that


will trigger the rebalancing, no?

-Val

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

dma...@gridgain.com>

wrote:


Igniters,

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

goes

down,
thus, shrinking the baseline topology. It complies with our
assumption

that

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


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

to

trigger


the rebalancing within the baseline topology manually or on

timeout

if:

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

in

the

 nearest time and

 - It's not likely that that node will be replaced by the

other

one.

The question. If I call IgniteCache.rebalance() or configure

CacheConfiguration.rebalanceTimeout will the rebalancing be

fired

within
the baseline topology?

--
Denis

[GitHub] ignite pull request #3870: IGNITE-8312: Simplified the choice of exception t...

[andrey-kuznetsov]

GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-8312: Simplified the choice of exception thrown in pessimistic…

… "prepare-after-rollback" scenario.

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

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

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

https://github.com/apache/ignite/pull/3870.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3870


commit d6cf50e7a3c6c33a4c122b056897576c06f6ec7c
Author: Andrey Kuznetsov 
Date:   2018-04-18T16:48:44Z

IGNITE-8312: Simplified the choice of exception thrown in pessimistic 
"prepare-after-rollback" scenario.




---

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

[Dmitriy Setrakyan]

On Tue, Apr 17, 2018 at 4:38 PM, Denis Magda  wrote:

> Dmitriy,
>
> We don't want to disable the baseline topology for the scenario discussed
> here. The goal is to make it more flexible by triggering the rebalancing in
> some circumstances.
>
> As for the SAFE or AGGRESSIVE policies, haven't seen the discussion on the
> dev. So, not sure what it's intended for (use case, scenario, behavior).
>

The idea was to have a mode for disabling BLT, so users will not have to
provide coding callbacks to force the rebalance. Essentially, if we had
this policy, you would not need to provide this example.

[jira] [Created] (IGNITE-8312) .NET: CacheAbstractTransactionalTest.TestTxRollbackOnly failure

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-8312:


 Summary: .NET: CacheAbstractTransactionalTest.TestTxRollbackOnly 
failure
 Key: IGNITE-8312
 URL: https://issues.apache.org/jira/browse/IGNITE-8312
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
 Fix For: 2.5


{noformat}
Test(s) failed.   Expected: 

  But was:   (Invalid transaction 
state for prepare [state=MARKED_ROLLBACK, tx=GridNearPessimisticTxPrepareFuture 
[innerFuts=[], super=GridCompoundFuture 
[rdc=org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxPrepareFutureAdapter$1@62e703a4,
 initFlag=0, lsnrCalls=0, done=false, cancelled=false, err=null, futs=[)
{noformat}

Caused by changes made in [1]

[1] https://issues.apache.org/jira/browse/IGNITE-7770




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

[jira] [Created] (IGNITE-8311) IgniteClientRejoinTest.testClientsReconnectDisabled causes exchange-worker to terminate via NPE

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-8311:


 Summary: IgniteClientRejoinTest.testClientsReconnectDisabled 
causes exchange-worker to terminate via NPE
 Key: IGNITE-8311
 URL: https://issues.apache.org/jira/browse/IGNITE-8311
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Andrey Kuznetsov
 Fix For: 2.6


Currently, tests use {{NoOpFailureHandler}} by default, hence this 
exchange-worker termination is masked. We are to fix it: test code should not 
be able to terminate system-critical thread.



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

[IGNITE-7909]: Java code examples are needed for Spark Data Frames.

[Akmal Chaudhri]

If any community members have time, please review the code. Three Java
files are attached to the Jira ticket:

https://issues.apache.org/jira/browse/IGNITE-7909

The code should be functionally equivalent to the Scala Data Frames code
that was shipped in 2.4.

Data Frame documentation is here:

https://apacheignite-fs.readme.io/docs/ignite-data-frame

Thank you!

[GitHub] ignite pull request #3869: IGNITE-7108 Apache Ignite 2.5 RPM and DEB package...

[vveider]

GitHub user vveider opened a pull request:

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

IGNITE-7108 Apache Ignite 2.5 RPM and DEB packages

 * added package.sh script for automation DEB and RPM packages build
 * added DEB package build
 * updated RPM package version to 2.5.0
 * refactored RPM files layout for unification of build process
 * improved packages layout hierarchy

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

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

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

https://github.com/apache/ignite/pull/3869.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3869


commit f00c6bafb5524bd7fdfb50a94671ab5eee94ef38
Author: Ivanov Petr 
Date:   2018-04-17T07:59:11Z

IGNITE-7108 Apache Ignite 2.5 RPM and DEB packages
 * added package.sh script for automation DEB and RPM packages build
 * added DEB package build
 * updated RPM package version to 2.5.0
 * refactored RPM files layout for unification of build process
 * improved packages layout hierarchy




---

[GitHub] ignite pull request #3827: IGNITE-8276 : Removed incorrect assertion, fixed ...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: [GitHub] ignite pull request #3719: IGNITE-8048 merge query entities for dynamic cach...

[Manu]

Hi,

Sorry, I assumed that QueryEntities merge process was always applied (on
active or inactive cluster) and that it was responsible for auto creating
and populate new indexes and columns on the fly... my fault.

Then, in addition to updating CacheConfiguration and QuerySchema, does it do
something else?

One more question, when the cluster is re-activated, will new columns and
new indexes be created and populated?

Thanks!



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

[GitHub] ignite pull request #3868: IGNITE-7968 IgniteAtomicSequence.incrementAndGet ...

[pvinokurov]

GitHub user pvinokurov opened a pull request:

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

IGNITE-7968 IgniteAtomicSequence.incrementAndGet throws ClusterTopolo…

…gyException: Failed to acquire lock for keys

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

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

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

https://github.com/apache/ignite/pull/3868.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3868


commit 692118e590ee66e2987eeb1b1f96024284bb52ae
Author: pvinokurov 
Date:   2018-04-18T15:19:14Z

IGNITE-7968 IgniteAtomicSequence.incrementAndGet throws 
ClusterTopologyException: Failed to acquire lock for keys




---

Re: Can't run CPP tests locally on linux machine

[Nikolay Izhikov]

Igor.

I tried to comment unexisted header and got following error:

src/teamcity/teamcity_boost.cpp: In constructor 
‘JetBrains::TeamcityFormatterRegistrar::TeamcityFormatterRegistrar()’:
src/teamcity/teamcity_boost.cpp:72:100: error: invalid new-expression of 
abstract class type ‘JetBrains::TeamcityBoostLogFormatter’
 boost::unit_test::unit_test_log.set_formatter(new 
JetBrains::TeamcityBoostLogFormatter());

Do I need some additional team city library for tets?
Can tests for odbc be executed locally?

В Ср, 18/04/2018 в 16:29 +0300, Igor Sapego пишет:
> I think it is better to remove this strong dependency on the
> exact Boost version at all. I've filed a ticket for that: [1].
> 
> [1] - https://issues.apache.org/jira/browse/IGNITE-8310
> 
> Best Regards,
> Igor
> 
> On Wed, Apr 18, 2018 at 4:20 PM, Nikolay Izhikov  wrote:
> > Hello, Igor.
> > 
> > Thanks!
> > I will try to find boost-1.58.0 distribution and setup it.
> > 
> > > 2. Well, it is the old issue that we are working only with the specific> 
> > > Boost version (1.58.0). You can try commenting out the following line:> 
> > 
> > Should we mention it in DEVNOTES?
> > Should we add some readme to setup development environment for CPP module?
> > 
> > В Ср, 18/04/2018 в 16:11 +0300, Igor Sapego пишет:
> > > Hi, Nikolay,
> > > 
> > > 1. Yes, it's OK;
> > > 2. Well, it is the old issue that we are working only with the specific
> > > Boost version (1.58.0). You can try commenting out the following line:
> > > 
> > > #include 
> > > 
> > > in teamcity_boost.cpp files to make it working with your version.
> > > 
> > > Best Regards,
> > > Igor
> > > 
> > > On Wed, Apr 18, 2018 at 3:55 PM, Nikolay Izhikov 
> > > wrote:
> > > 
> > > > Hello, Igniters.
> > > > 
> > > > Is there way to run CPP tests locally on linux machine?
> > > > 
> > > > I'm trying to follow DEVNOTES.txt but doesn't get lucky.
> > > > 
> > > > 1. `./configure --enable-odbc --enable-tests` [1]
> > > > I see
> > > > 
> > > > "rm: cannot remove 'core': Is a directory"
> > > > 
> > > > Is it OK?
> > > > 
> > > > 2. `make` [2]
> > > > 
> > > > I got following error:
> > > > 
> > > > "src/teamcity/teamcity_boost.cpp:22:10: fatal error:
> > > > boost/test/unit_test_suite_impl.hpp: Нет такого файла или каталога
> > > >  #include "
> > > > 
> > > > I've installed boost-dev - `sudo apt-get install libboost-all-dev`
> > > > But, there is no `unit_test_suite_impl.hpp` in /usr/header/boost/test.
> > > > Without tests it all compiles OK.
> > > > 
> > > > What should I do to be able run tests for CPP locally?
> > > > 
> > > > [1] https://gist.github.com/nizhikov/8a451b73db17fa05d10992ae50524b7b
> > > > [2] https://gist.github.com/nizhikov/9d0da202c3e52f3ee1cd5bc2053e1073
> 
> 

signature.asc
Description: This is a digitally signed message part

[GitHub] ignite pull request #3867: -

[daradurvs]

GitHub user daradurvs opened a pull request:

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

-



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

$ git pull https://github.com/daradurvs/ignite ignite-4756-client-fix

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

https://github.com/apache/ignite/pull/3867.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3867


commit e67285e164291f5b19298f9b2b0fffad26d2c107
Author: Vyacheslav Daradur 
Date:   2018-04-18T15:10:11Z

ignite-4756: denied printing at clients nodes




---

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

[Dmitry Pavlov]

First of all it should be new way for testing without modificaitions in
JUnit3-style tests and its base classes. Test would migrate one-by one.

If old test is quite stable on 3 and no need to mute it/apply config
variations (Parametrized annotation) we could keep it as is for some time.


ср, 18 апр. 2018 г. в 17:37, Vyacheslav Daradur :

> I vote for upgrading to JUnit 5.


>
> It will entail significant changes in the current testing framework.
>
> Dmitriy, do you want to change API of GridCommonAbstractTest or
> deprecate some methods?
>

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

[Maxim Muzafarov]

+1 for JUnit5

I suppose we should change\create new not only GridCommonAbstractTest, but
also rework GridSpiAbstractTest, GridAbstractTest.


ср, 18 апр. 2018 г. в 17:37, Vyacheslav Daradur :

> I vote for upgrading to JUnit 5.
>
> It will entail significant changes in the current testing framework.
>
> Dmitriy, do you want to change API of GridCommonAbstractTest or
> deprecate some methods?
>

[GitHub] ignite pull request #3866: IGNITE-8192 Print out information on how many nod...

[alex-plekhanov]

GitHub user alex-plekhanov opened a pull request:

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

IGNITE-8192 Print out information on how many nodes left until 
auto-activation



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

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

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

https://github.com/apache/ignite/pull/3866.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3866


commit 22a06255a73deed2aee338c25a20e64a00b5ca14
Author: Aleksey Plekhanov 
Date:   2018-04-18T09:57:43Z

IGNITE-8192 Print out information on how many nodes left until 
auto-activation

commit 62446ebd41f8510c489c7bf0c834cb119a89f0ae
Author: Aleksey Plekhanov 
Date:   2018-04-18T14:31:47Z

IGNITE-8192 Bug fixed

commit fe2eac3ec090f1556e1426ce29862abfe19f4f8f
Author: Aleksey Plekhanov 
Date:   2018-04-18T14:32:07Z

IGNITE-8192 Unit test

commit 36502dc357d760e420b7c4bae77a1835b1807ffc
Author: Aleksey Plekhanov 
Date:   2018-04-18T14:32:39Z

IGNITE-8192 Unit test removed




---

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

[Vyacheslav Daradur]

I vote for upgrading to JUnit 5.

It will entail significant changes in the current testing framework.

Dmitriy, do you want to change API of GridCommonAbstractTest or
deprecate some methods?

[GitHub] ignite pull request #3865: IGNITE-8302 Reduce test IO consumption in case Di...

[dspavlov]

GitHub user dspavlov opened a pull request:

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

IGNITE-8302 Reduce test IO consumption in case Direct IO is enabled, …

…fixes flakyness of testPageRecoveryAfterFileCorruption

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

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

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

https://github.com/apache/ignite/pull/3865.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3865


commit 73a89092ba1cf898408e03b3385176f6f76e0228
Author: dpavlov 
Date:   2018-04-18T14:32:47Z

IGNITE-8302 Reduce test IO consumption in case Direct IO is enabled, fixes 
flakyness of testPageRecoveryAfterFileCorruption




---

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

[Alexey Kuznetsov]

+100500 for upgrading of JUnit

https://developer.ibm.com/dwblog/2017/top-five-reasons-to-use-junit-5-java/
https://stackify.com/junit-5/

On Wed, Apr 18, 2018 at 8:59 PM, Dmitry Pavlov 
wrote:

> Hi Igniters,
>
> During MTCGA monitoring I’ve discovered a number of issues related to test
> framework itself.
>
> In addition it is not convinient to mute tests on TC, because in branches
> (e.g. 2.5 and in master) we can’t mute it separately. So some tests, which
> already fixed are shown as failed in our PRs and release branches. But
> current JUnit3 test style does not allow to use @Ignore.
>
> Is it time to start translating tests to Unit 4 style?
>
> Are there any of us who would like to assist in the research and create a
> new GridCommonAbstractTest and/or IgniteJUnitRunner?
>
> Sincerely,
> Dmitriy Pavlov
>



-- 
Alexey Kuznetsov

[GitHub] ignite pull request #3839: Ignite 6681 .NET: QueryMetrics

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Orphaned, duplicate, and main-class tests!

[Anton Vinogradov]

Ilya,

what's the reason to create new thread with unreadable history attached?

2018-04-18 17:07 GMT+03:00 Ilya Kasnacheev :

> Hello!
>
> Most of tests were committed by Semyon Boikov. I hope he can shed some
> light on the purpose of those.
>
> E.g. GridBasicPerformanceTest.
>
> --
> Ilya Kasnacheev
>
> 2018-04-18 16:51 GMT+03:00 Dmitry Pavlov :
>
> > Hi Ilya,
> >
> > could you please involve authors to this dicussions personally? What git
> > annotate says us about test author?
> >
> > Can I hope you would provide assistance to MakeTC Green in case some
> > returned to CI classes will began to fail?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > ср, 18 апр. 2018 г. в 16:42, Ilya Kasnacheev  >:
> >
> > > Hello!
> > >
> > > I've decided to return to this task after a break.
> > >
> > > Can you please tell me why do we have main-class tests? Such as
> > >
> > > GridBasicPerformanceTest.class,
> > > GridBenchmarkCacheGetLoadTest.class,
> > > GridBoundedConcurrentLinkedHashSetLoadTest.class,
> > > GridCacheDataStructuresLoadTest.class,
> > > GridCacheReplicatedPreloadUndeploysTest.class,
> > > GridCacheLoadTest.class,
> > > GridCacheMultiNodeDataStructureTest.class,
> > > GridCapacityLoadTest.class,
> > > GridContinuousOperationsLoadTest.class,
> > > GridFactoryVmShutdownTest.class,
> > > GridFutureListenPerformanceTest.class,
> > > GridFutureQueueTest.class,
> > > GridGcTimeoutTest.class,
> > > GridJobExecutionSingleNodeLoadTest.class,
> > > GridJobExecutionSingleNodeSemaphoreLoadTest.class,
> > > GridJobLoadTest.class,
> > > GridMergeSortLoadTest.class,
> > > GridNioBenchmarkTest.class,
> > > GridThreadPriorityTest.class,
> > > GridSystemCurrentTimeMillisTest.class,
> > > BlockingQueueTest.class,
> > > MultipleFileIOTest.class,
> > > GridSingleExecutionTest.class
> > >
> > >
> > > If nobody wants them, how about we delete them in master branch? Start
> > > afresh?
> > >
> > > --
> > > Ilya Kasnacheev
> > >
> > > 2018-02-13 17:02 GMT+03:00 Ilya Kasnacheev  >:
> > >
> > > > Anton,
> > > >
> > > > >Tests should be attached to appropriate suites
> > > >
> > > > This I can do
> > > >
> > > > > and muted if necessary, Issues should be created on each mute.
> > > >
> > > > This is roughly a week of work. I can't spare that right now. I doubt
> > > > anyone can.
> > > >
> > > > Can we approach this by smaller steps?
> > > >
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > > 2018-02-06 19:55 GMT+03:00 Anton Vinogradov <
> avinogra...@gridgain.com
> > >:
> > > >
> > > >> Val,
> > > >>
> > > >> Tests should be attached to appropriate suites and muted if
> necessary,
> > > >> Issues should be created on each mute.
> > > >>
> > > >> On Tue, Feb 6, 2018 at 7:23 PM, Valentin Kulichenko <
> > > >> valentin.kuliche...@gmail.com> wrote:
> > > >>
> > > >> > Anton,
> > > >> >
> > > >> > I tend to agree with Ilya that identifying and fixing all the
> > possible
> > > >> > broken tests in one go is not feasible. What is the proper way in
> > your
> > > >> > view? What are you suggesting?
> > > >> >
> > > >> > -Val
> > > >> >
> > > >> > On Mon, Feb 5, 2018 at 2:18 AM, Anton Vinogradov <
> > > >> avinogra...@gridgain.com
> > > >> > >
> > > >> > wrote:
> > > >> >
> > > >> > > Ilya,
> > > >> > >
> > > >> > > 1) Still see no reason for such changes. Does this break
> > something?
> > > >> > >
> > > >> > > 2) Looks like you're trying to add Trash*TestSuite.java which
> will
> > > >> never
> > > >> > be
> > > >> > > refactored.
> > > >> > > We should do everything in proper way now, not sometime.
> > > >> > >
> > > >> > > 3) Your comments looks odd to me.
> > > >> > > Issue should be resolved in proper way.
> > > >> > >
> > > >> > > On Mon, Feb 5, 2018 at 1:07 PM, Ilya Kasnacheev <
> > > >> > ilya.kasnach...@gmail.com
> > > >> > > >
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Anton,
> > > >> > > >
> > > >> > > > 1) We already have ~100 files named "*AbstractTest.java".
> > Renaming
> > > >> > these
> > > >> > > > several files will help checking for orphaned tests in the
> > future,
> > > >> as
> > > >> > > well
> > > >> > > > as increasing code base consistency.
> > > >> > > >
> > > >> > > > 2) This is huge work that is not doable by any single
> developer.
> > > >> While
> > > >> > > > IgniteLostAndFoundTestSuite can be slowly refactored away
> > > >> > > > This is unless you are OK with putting all these tests, most
> of
> > > >> which
> > > >> > are
> > > >> > > > red and some are hanging, in production test suites and
> > therefore
> > > >> > > breaking
> > > >> > > > productivity for a couple months while this gets sorted.
> > > >> > > > Are you OK with that? Anybody else?
> > > >> > > >
> > > >> > > > 3) I think I *could* put them in some test suite or another,
> but
> > > I'm
> > > >> > > pretty
> > > >> > > > sure I can't fix them 

Re: Orphaned, duplicate, and main-class tests!

[Ilya Kasnacheev]

Hello!

Most of tests were committed by Semyon Boikov. I hope he can shed some
light on the purpose of those.

E.g. GridBasicPerformanceTest.

-- 
Ilya Kasnacheev

2018-04-18 16:51 GMT+03:00 Dmitry Pavlov :

> Hi Ilya,
>
> could you please involve authors to this dicussions personally? What git
> annotate says us about test author?
>
> Can I hope you would provide assistance to MakeTC Green in case some
> returned to CI classes will began to fail?
>
> Sincerely,
> Dmitriy Pavlov
>
> ср, 18 апр. 2018 г. в 16:42, Ilya Kasnacheev :
>
> > Hello!
> >
> > I've decided to return to this task after a break.
> >
> > Can you please tell me why do we have main-class tests? Such as
> >
> > GridBasicPerformanceTest.class,
> > GridBenchmarkCacheGetLoadTest.class,
> > GridBoundedConcurrentLinkedHashSetLoadTest.class,
> > GridCacheDataStructuresLoadTest.class,
> > GridCacheReplicatedPreloadUndeploysTest.class,
> > GridCacheLoadTest.class,
> > GridCacheMultiNodeDataStructureTest.class,
> > GridCapacityLoadTest.class,
> > GridContinuousOperationsLoadTest.class,
> > GridFactoryVmShutdownTest.class,
> > GridFutureListenPerformanceTest.class,
> > GridFutureQueueTest.class,
> > GridGcTimeoutTest.class,
> > GridJobExecutionSingleNodeLoadTest.class,
> > GridJobExecutionSingleNodeSemaphoreLoadTest.class,
> > GridJobLoadTest.class,
> > GridMergeSortLoadTest.class,
> > GridNioBenchmarkTest.class,
> > GridThreadPriorityTest.class,
> > GridSystemCurrentTimeMillisTest.class,
> > BlockingQueueTest.class,
> > MultipleFileIOTest.class,
> > GridSingleExecutionTest.class
> >
> >
> > If nobody wants them, how about we delete them in master branch? Start
> > afresh?
> >
> > --
> > Ilya Kasnacheev
> >
> > 2018-02-13 17:02 GMT+03:00 Ilya Kasnacheev :
> >
> > > Anton,
> > >
> > > >Tests should be attached to appropriate suites
> > >
> > > This I can do
> > >
> > > > and muted if necessary, Issues should be created on each mute.
> > >
> > > This is roughly a week of work. I can't spare that right now. I doubt
> > > anyone can.
> > >
> > > Can we approach this by smaller steps?
> > >
> > > --
> > > Ilya Kasnacheev
> > >
> > > 2018-02-06 19:55 GMT+03:00 Anton Vinogradov  >:
> > >
> > >> Val,
> > >>
> > >> Tests should be attached to appropriate suites and muted if necessary,
> > >> Issues should be created on each mute.
> > >>
> > >> On Tue, Feb 6, 2018 at 7:23 PM, Valentin Kulichenko <
> > >> valentin.kuliche...@gmail.com> wrote:
> > >>
> > >> > Anton,
> > >> >
> > >> > I tend to agree with Ilya that identifying and fixing all the
> possible
> > >> > broken tests in one go is not feasible. What is the proper way in
> your
> > >> > view? What are you suggesting?
> > >> >
> > >> > -Val
> > >> >
> > >> > On Mon, Feb 5, 2018 at 2:18 AM, Anton Vinogradov <
> > >> avinogra...@gridgain.com
> > >> > >
> > >> > wrote:
> > >> >
> > >> > > Ilya,
> > >> > >
> > >> > > 1) Still see no reason for such changes. Does this break
> something?
> > >> > >
> > >> > > 2) Looks like you're trying to add Trash*TestSuite.java which will
> > >> never
> > >> > be
> > >> > > refactored.
> > >> > > We should do everything in proper way now, not sometime.
> > >> > >
> > >> > > 3) Your comments looks odd to me.
> > >> > > Issue should be resolved in proper way.
> > >> > >
> > >> > > On Mon, Feb 5, 2018 at 1:07 PM, Ilya Kasnacheev <
> > >> > ilya.kasnach...@gmail.com
> > >> > > >
> > >> > > wrote:
> > >> > >
> > >> > > > Anton,
> > >> > > >
> > >> > > > 1) We already have ~100 files named "*AbstractTest.java".
> Renaming
> > >> > these
> > >> > > > several files will help checking for orphaned tests in the
> future,
> > >> as
> > >> > > well
> > >> > > > as increasing code base consistency.
> > >> > > >
> > >> > > > 2) This is huge work that is not doable by any single developer.
> > >> While
> > >> > > > IgniteLostAndFoundTestSuite can be slowly refactored away
> > >> > > > This is unless you are OK with putting all these tests, most of
> > >> which
> > >> > are
> > >> > > > red and some are hanging, in production test suites and
> therefore
> > >> > > breaking
> > >> > > > productivity for a couple months while this gets sorted.
> > >> > > > Are you OK with that? Anybody else?
> > >> > > >
> > >> > > > 3) I think I *could* put them in some test suite or another, but
> > I'm
> > >> > > pretty
> > >> > > > sure I can't fix them all, not in one commit, not ever. Nobody
> can
> > >> do
> > >> > > that
> > >> > > > single-handedly. We need a plan here.
> > >> > > >
> > >> > > > Ilya.
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > Ilya Kasnacheev
> > >> > > >
> > >> > > > 2018-02-05 13:00 GMT+03:00 Anton Vinogradov <
> > >> avinogra...@gridgain.com
> > >> > >:
> > >> > > >
> > >> > > > > Ilya,
> > >> > > > >
> > >> > > > > 1) I don't think it's a good idea to rename classes to
> > >> > 

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

[Dmitry Pavlov]

Hi Igniters,

During MTCGA monitoring I’ve discovered a number of issues related to test
framework itself.

In addition it is not convinient to mute tests on TC, because in branches
(e.g. 2.5 and in master) we can’t mute it separately. So some tests, which
already fixed are shown as failed in our PRs and release branches. But
current JUnit3 test style does not allow to use @Ignore.

Is it time to start translating tests to Unit 4 style?

Are there any of us who would like to assist in the research and create a
new GridCommonAbstractTest and/or IgniteJUnitRunner?

Sincerely,
Dmitriy Pavlov

Re: Orphaned, duplicate, and main-class tests!

[Dmitry Pavlov]

Hi Ilya,

could you please involve authors to this dicussions personally? What git
annotate says us about test author?

Can I hope you would provide assistance to MakeTC Green in case some
returned to CI classes will began to fail?

Sincerely,
Dmitriy Pavlov

ср, 18 апр. 2018 г. в 16:42, Ilya Kasnacheev :

> Hello!
>
> I've decided to return to this task after a break.
>
> Can you please tell me why do we have main-class tests? Such as
>
> GridBasicPerformanceTest.class,
> GridBenchmarkCacheGetLoadTest.class,
> GridBoundedConcurrentLinkedHashSetLoadTest.class,
> GridCacheDataStructuresLoadTest.class,
> GridCacheReplicatedPreloadUndeploysTest.class,
> GridCacheLoadTest.class,
> GridCacheMultiNodeDataStructureTest.class,
> GridCapacityLoadTest.class,
> GridContinuousOperationsLoadTest.class,
> GridFactoryVmShutdownTest.class,
> GridFutureListenPerformanceTest.class,
> GridFutureQueueTest.class,
> GridGcTimeoutTest.class,
> GridJobExecutionSingleNodeLoadTest.class,
> GridJobExecutionSingleNodeSemaphoreLoadTest.class,
> GridJobLoadTest.class,
> GridMergeSortLoadTest.class,
> GridNioBenchmarkTest.class,
> GridThreadPriorityTest.class,
> GridSystemCurrentTimeMillisTest.class,
> BlockingQueueTest.class,
> MultipleFileIOTest.class,
> GridSingleExecutionTest.class
>
>
> If nobody wants them, how about we delete them in master branch? Start
> afresh?
>
> --
> Ilya Kasnacheev
>
> 2018-02-13 17:02 GMT+03:00 Ilya Kasnacheev :
>
> > Anton,
> >
> > >Tests should be attached to appropriate suites
> >
> > This I can do
> >
> > > and muted if necessary, Issues should be created on each mute.
> >
> > This is roughly a week of work. I can't spare that right now. I doubt
> > anyone can.
> >
> > Can we approach this by smaller steps?
> >
> > --
> > Ilya Kasnacheev
> >
> > 2018-02-06 19:55 GMT+03:00 Anton Vinogradov :
> >
> >> Val,
> >>
> >> Tests should be attached to appropriate suites and muted if necessary,
> >> Issues should be created on each mute.
> >>
> >> On Tue, Feb 6, 2018 at 7:23 PM, Valentin Kulichenko <
> >> valentin.kuliche...@gmail.com> wrote:
> >>
> >> > Anton,
> >> >
> >> > I tend to agree with Ilya that identifying and fixing all the possible
> >> > broken tests in one go is not feasible. What is the proper way in your
> >> > view? What are you suggesting?
> >> >
> >> > -Val
> >> >
> >> > On Mon, Feb 5, 2018 at 2:18 AM, Anton Vinogradov <
> >> avinogra...@gridgain.com
> >> > >
> >> > wrote:
> >> >
> >> > > Ilya,
> >> > >
> >> > > 1) Still see no reason for such changes. Does this break something?
> >> > >
> >> > > 2) Looks like you're trying to add Trash*TestSuite.java which will
> >> never
> >> > be
> >> > > refactored.
> >> > > We should do everything in proper way now, not sometime.
> >> > >
> >> > > 3) Your comments looks odd to me.
> >> > > Issue should be resolved in proper way.
> >> > >
> >> > > On Mon, Feb 5, 2018 at 1:07 PM, Ilya Kasnacheev <
> >> > ilya.kasnach...@gmail.com
> >> > > >
> >> > > wrote:
> >> > >
> >> > > > Anton,
> >> > > >
> >> > > > 1) We already have ~100 files named "*AbstractTest.java". Renaming
> >> > these
> >> > > > several files will help checking for orphaned tests in the future,
> >> as
> >> > > well
> >> > > > as increasing code base consistency.
> >> > > >
> >> > > > 2) This is huge work that is not doable by any single developer.
> >> While
> >> > > > IgniteLostAndFoundTestSuite can be slowly refactored away
> >> > > > This is unless you are OK with putting all these tests, most of
> >> which
> >> > are
> >> > > > red and some are hanging, in production test suites and therefore
> >> > > breaking
> >> > > > productivity for a couple months while this gets sorted.
> >> > > > Are you OK with that? Anybody else?
> >> > > >
> >> > > > 3) I think I *could* put them in some test suite or another, but
> I'm
> >> > > pretty
> >> > > > sure I can't fix them all, not in one commit, not ever. Nobody can
> >> do
> >> > > that
> >> > > > single-handedly. We need a plan here.
> >> > > >
> >> > > > Ilya.
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Ilya Kasnacheev
> >> > > >
> >> > > > 2018-02-05 13:00 GMT+03:00 Anton Vinogradov <
> >> avinogra...@gridgain.com
> >> > >:
> >> > > >
> >> > > > > Ilya,
> >> > > > >
> >> > > > > 1) I don't think it's a good idea to rename classes to
> >> > > *AbstractTest.java
> >> > > > > since they already have abstract word at definition.
> >> > > > > We can perform such renaming only in case whole project will be
> >> > > > refactored,
> >> > > > > but I see no reason to do this.
> >> > > > >
> >> > > > > 2) All not included test should be included to appropriate
> siutes.
> >> > > > > Creating IgniteLostAndFoundTestSuite,java is not acceptable.
> >> > > > >
> >> > > > > 3) In case you're not sure what to do with particular tests,
> >> please
> >> > > > provide
> >> > > > > lists of 

[GitHub] ignite pull request #3429: IGNITE-7512: fixed NPE when entry processor remov...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Orphaned, duplicate, and main-class tests!

[Ilya Kasnacheev]

Hello!

I've decided to return to this task after a break.

Can you please tell me why do we have main-class tests? Such as

GridBasicPerformanceTest.class,
GridBenchmarkCacheGetLoadTest.class,
GridBoundedConcurrentLinkedHashSetLoadTest.class,
GridCacheDataStructuresLoadTest.class,
GridCacheReplicatedPreloadUndeploysTest.class,
GridCacheLoadTest.class,
GridCacheMultiNodeDataStructureTest.class,
GridCapacityLoadTest.class,
GridContinuousOperationsLoadTest.class,
GridFactoryVmShutdownTest.class,
GridFutureListenPerformanceTest.class,
GridFutureQueueTest.class,
GridGcTimeoutTest.class,
GridJobExecutionSingleNodeLoadTest.class,
GridJobExecutionSingleNodeSemaphoreLoadTest.class,
GridJobLoadTest.class,
GridMergeSortLoadTest.class,
GridNioBenchmarkTest.class,
GridThreadPriorityTest.class,
GridSystemCurrentTimeMillisTest.class,
BlockingQueueTest.class,
MultipleFileIOTest.class,
GridSingleExecutionTest.class


If nobody wants them, how about we delete them in master branch? Start
afresh?

-- 
Ilya Kasnacheev

2018-02-13 17:02 GMT+03:00 Ilya Kasnacheev :

> Anton,
>
> >Tests should be attached to appropriate suites
>
> This I can do
>
> > and muted if necessary, Issues should be created on each mute.
>
> This is roughly a week of work. I can't spare that right now. I doubt
> anyone can.
>
> Can we approach this by smaller steps?
>
> --
> Ilya Kasnacheev
>
> 2018-02-06 19:55 GMT+03:00 Anton Vinogradov :
>
>> Val,
>>
>> Tests should be attached to appropriate suites and muted if necessary,
>> Issues should be created on each mute.
>>
>> On Tue, Feb 6, 2018 at 7:23 PM, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>>
>> > Anton,
>> >
>> > I tend to agree with Ilya that identifying and fixing all the possible
>> > broken tests in one go is not feasible. What is the proper way in your
>> > view? What are you suggesting?
>> >
>> > -Val
>> >
>> > On Mon, Feb 5, 2018 at 2:18 AM, Anton Vinogradov <
>> avinogra...@gridgain.com
>> > >
>> > wrote:
>> >
>> > > Ilya,
>> > >
>> > > 1) Still see no reason for such changes. Does this break something?
>> > >
>> > > 2) Looks like you're trying to add Trash*TestSuite.java which will
>> never
>> > be
>> > > refactored.
>> > > We should do everything in proper way now, not sometime.
>> > >
>> > > 3) Your comments looks odd to me.
>> > > Issue should be resolved in proper way.
>> > >
>> > > On Mon, Feb 5, 2018 at 1:07 PM, Ilya Kasnacheev <
>> > ilya.kasnach...@gmail.com
>> > > >
>> > > wrote:
>> > >
>> > > > Anton,
>> > > >
>> > > > 1) We already have ~100 files named "*AbstractTest.java". Renaming
>> > these
>> > > > several files will help checking for orphaned tests in the future,
>> as
>> > > well
>> > > > as increasing code base consistency.
>> > > >
>> > > > 2) This is huge work that is not doable by any single developer.
>> While
>> > > > IgniteLostAndFoundTestSuite can be slowly refactored away
>> > > > This is unless you are OK with putting all these tests, most of
>> which
>> > are
>> > > > red and some are hanging, in production test suites and therefore
>> > > breaking
>> > > > productivity for a couple months while this gets sorted.
>> > > > Are you OK with that? Anybody else?
>> > > >
>> > > > 3) I think I *could* put them in some test suite or another, but I'm
>> > > pretty
>> > > > sure I can't fix them all, not in one commit, not ever. Nobody can
>> do
>> > > that
>> > > > single-handedly. We need a plan here.
>> > > >
>> > > > Ilya.
>> > > >
>> > > >
>> > > > --
>> > > > Ilya Kasnacheev
>> > > >
>> > > > 2018-02-05 13:00 GMT+03:00 Anton Vinogradov <
>> avinogra...@gridgain.com
>> > >:
>> > > >
>> > > > > Ilya,
>> > > > >
>> > > > > 1) I don't think it's a good idea to rename classes to
>> > > *AbstractTest.java
>> > > > > since they already have abstract word at definition.
>> > > > > We can perform such renaming only in case whole project will be
>> > > > refactored,
>> > > > > but I see no reason to do this.
>> > > > >
>> > > > > 2) All not included test should be included to appropriate siutes.
>> > > > > Creating IgniteLostAndFoundTestSuite,java is not acceptable.
>> > > > >
>> > > > > 3) In case you're not sure what to do with particular tests,
>> please
>> > > > provide
>> > > > > lists of such tests. Please group tests by "problem".
>> > > > >
>> > > > >
>> > > > > On Fri, Feb 2, 2018 at 12:28 AM, Dmitry Pavlov <
>> > dpavlov@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > > Hi Ilya,
>> > > > > >
>> > > > > > Thank you for this research. I think it is useful for community
>> to
>> > > > > identify
>> > > > > > and remove obsolete tests (if any), and include lost test into
>> CI
>> > run
>> > > > > chain
>> > > > > > (if applicable).
>> > > > > >
>> > > > > > For test with main() methods I suggest to ask authors (git
>> > annotate)
>> > > > and
>> > > > > if
>> > > > > > there is no response probably 

Re: Can't run CPP tests locally on linux machine

[Igor Sapego]

I think it is better to remove this strong dependency on the
exact Boost version at all. I've filed a ticket for that: [1].

[1] - https://issues.apache.org/jira/browse/IGNITE-8310

Best Regards,
Igor

On Wed, Apr 18, 2018 at 4:20 PM, Nikolay Izhikov 
wrote:

> Hello, Igor.
>
> Thanks!
> I will try to find boost-1.58.0 distribution and setup it.
>
> > 2. Well, it is the old issue that we are working only with the specific>
> Boost version (1.58.0). You can try commenting out the following line:>
>
> Should we mention it in DEVNOTES?
> Should we add some readme to setup development environment for CPP module?
>
> В Ср, 18/04/2018 в 16:11 +0300, Igor Sapego пишет:
> > Hi, Nikolay,
> >
> > 1. Yes, it's OK;
> > 2. Well, it is the old issue that we are working only with the specific
> > Boost version (1.58.0). You can try commenting out the following line:
> >
> > #include 
> >
> > in teamcity_boost.cpp files to make it working with your version.
> >
> > Best Regards,
> > Igor
> >
> > On Wed, Apr 18, 2018 at 3:55 PM, Nikolay Izhikov 
> > wrote:
> >
> > > Hello, Igniters.
> > >
> > > Is there way to run CPP tests locally on linux machine?
> > >
> > > I'm trying to follow DEVNOTES.txt but doesn't get lucky.
> > >
> > > 1. `./configure --enable-odbc --enable-tests` [1]
> > > I see
> > >
> > > "rm: cannot remove 'core': Is a directory"
> > >
> > > Is it OK?
> > >
> > > 2. `make` [2]
> > >
> > > I got following error:
> > >
> > > "src/teamcity/teamcity_boost.cpp:22:10: fatal error:
> > > boost/test/unit_test_suite_impl.hpp: Нет такого файла или каталога
> > >  #include "
> > >
> > > I've installed boost-dev - `sudo apt-get install libboost-all-dev`
> > > But, there is no `unit_test_suite_impl.hpp` in /usr/header/boost/test.
> > > Without tests it all compiles OK.
> > >
> > > What should I do to be able run tests for CPP locally?
> > >
> > > [1] https://gist.github.com/nizhikov/8a451b73db17fa05d10992ae50524b7b
> > > [2] https://gist.github.com/nizhikov/9d0da202c3e52f3ee1cd5bc2053e1073
>

[jira] [Created] (IGNITE-8310) CPP: Remove strong dependency on Boost 1.58.0

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-8310:
---

 Summary: CPP: Remove strong dependency on Boost 1.58.0
 Key: IGNITE-8310
 URL: https://issues.apache.org/jira/browse/IGNITE-8310
 Project: Ignite
  Issue Type: Improvement
  Components: odbc, platforms
Affects Versions: 2.4
Reporter: Igor Sapego
 Fix For: 2.6


Currently, tests for C++ client and ODBC depends on the Boost 1.58.0. There is 
a strong dependency on the exact version, which causes troubles for the 
developers and which should not be there from the very beginning as we do not 
really need some features from this particular version.



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

Re: Can't run CPP tests locally on linux machine

[Igor Sapego]

Hi, Nikolay,

1. Yes, it's OK;
2. Well, it is the old issue that we are working only with the specific
Boost version (1.58.0). You can try commenting out the following line:

#include 

in teamcity_boost.cpp files to make it working with your version.

Best Regards,
Igor

On Wed, Apr 18, 2018 at 3:55 PM, Nikolay Izhikov 
wrote:

> Hello, Igniters.
>
> Is there way to run CPP tests locally on linux machine?
>
> I'm trying to follow DEVNOTES.txt but doesn't get lucky.
>
> 1. `./configure --enable-odbc --enable-tests` [1]
> I see
>
> "rm: cannot remove 'core': Is a directory"
>
> Is it OK?
>
> 2. `make` [2]
>
> I got following error:
>
> "src/teamcity/teamcity_boost.cpp:22:10: fatal error:
> boost/test/unit_test_suite_impl.hpp: Нет такого файла или каталога
>  #include "
>
> I've installed boost-dev - `sudo apt-get install libboost-all-dev`
> But, there is no `unit_test_suite_impl.hpp` in /usr/header/boost/test.
> Without tests it all compiles OK.
>
> What should I do to be able run tests for CPP locally?
>
> [1] https://gist.github.com/nizhikov/8a451b73db17fa05d10992ae50524b7b
> [2] https://gist.github.com/nizhikov/9d0da202c3e52f3ee1cd5bc2053e1073

[GitHub] ignite pull request #3864: IGNITE-8021 Fix test issues

[ivandasch]

GitHub user ivandasch opened a pull request:

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

IGNITE-8021 Fix test issues



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

$ git pull https://github.com/ivandasch/ignite ignite-8021-test-fix

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

https://github.com/apache/ignite/pull/3864.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3864


commit e19511bd16f8b82ac754a9f7f008c105141390fa
Author: Ivan Daschinskiy 
Date:   2018-04-18T13:04:20Z

IGNITE-8021 Fix test issues




---

[GitHub] ignite pull request #3745: IGNITE-8122 Restore partition in state OWNING

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3863: IGNITE-8134 fix service deployment from nodes out...

[dmekhanikov]

GitHub user dmekhanikov opened a pull request:

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

IGNITE-8134 fix service deployment from nodes outside of BLT



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

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

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

https://github.com/apache/ignite/pull/3863.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3863


commit a293129885eede98b282471c681b7a45e14968b7
Author: Denis Mekhanikov 
Date:   2018-04-18T11:52:10Z

IGNITE-8134 subscribe to system cache events on nodes outside BLT

commit 2f5c9fdf6ab283047d400a3fc38254ac6253882e
Author: Denis Mekhanikov 
Date:   2018-04-18T12:53:47Z

IGNITE-8134 add tests for service deployment from outside baseline




---

Can't run CPP tests locally on linux machine

[Nikolay Izhikov]

Hello, Igniters.

Is there way to run CPP tests locally on linux machine?

I'm trying to follow DEVNOTES.txt but doesn't get lucky.

1. `./configure --enable-odbc --enable-tests` [1]
I see 

"rm: cannot remove 'core': Is a directory"

Is it OK?

2. `make` [2]

I got following error:

"src/teamcity/teamcity_boost.cpp:22:10: fatal error: 
boost/test/unit_test_suite_impl.hpp: Нет такого файла или каталога
 #include "

I've installed boost-dev - `sudo apt-get install libboost-all-dev`
But, there is no `unit_test_suite_impl.hpp` in /usr/header/boost/test.
Without tests it all compiles OK.

What should I do to be able run tests for CPP locally?

[1] https://gist.github.com/nizhikov/8a451b73db17fa05d10992ae50524b7b
[2] https://gist.github.com/nizhikov/9d0da202c3e52f3ee1cd5bc2053e1073

signature.asc
Description: This is a digitally signed message part

[GitHub] ignite pull request #3862: Ignite-8082 ZK MBean

[agoncharuk]

GitHub user agoncharuk opened a pull request:

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

Ignite-8082 ZK MBean



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

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

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

https://github.com/apache/ignite/pull/3862.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3862


commit 448a627885bc99a5a1d5763893e36f38988ede85
Author: Sergey Chugunov 
Date:   2018-04-13T08:34:51Z

IGNITE-8082 generic interface for DiscoverySpi metrics is extracted

commit 14b2e3ec6b8da0c3859542081ed2eb9c82bbc87b
Author: Sergey Chugunov 
Date:   2018-04-13T16:09:28Z

IGNITE-8082 basic ZookeeperDiscoverySpi metrics are exposed through JMX 
interface

commit 8808495589f36f1d3f211c51aa0f97614b4db809
Author: Alexey Goncharuk 
Date:   2018-04-18T11:34:23Z

Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite 
into ignite-8082

commit a075cf7d36d742474fb03cc14a78eb71a9489437
Author: Alexey Goncharuk 
Date:   2018-04-18T11:53:10Z

IGNITE-8082 Zookeeper MBean




---

Please add me to contributors

[Andrew Medvedev]

Hi everybody.

Please add me to contributors
My name is Andrew Medvedev
My Jira Id is "andmed"

Best
Andrew

Re: Apache Ignite RPM packaging (Stage II)

[Ilya Kasnacheev]

Copying anything manually to anywhere /usr (excluding /usr/local) is an
example of slackwarization that package users and creators try to avoid.

> By linux file hierarchy convention, home dir should be in /usr/lib

Citation needed! I bet you're interpreting it wrong, since I've listed a
random dir in /var/lib, and:
~/w/incubator-ignite% sudo ls -al /var/lib/lightdm
drwxr-x---  6 lightdm lightdm 4096 авг 14  2017 .
drwxr-xr-x 89 rootroot4096 мар 10 22:37 ..
drwxrwxr-x  4 lightdm lightdm 4096 июл 19  2017 .cache
drwxr-xr-x  5 lightdm lightdm 4096 июл 19  2017 .config
drwx--  2 lightdm lightdm 4096 апр 11 18:25 .gconf
drwxr-xr-x  3 lightdm lightdm 4096 июл 19  2017 .local
-rw---  1 lightdm lightdm  283 апр 11 18:25 .Xauthority

...it definitely looks like a home dir. Which goes with additional benefit
of being writable by end-user.

-- 
Ilya Kasnacheev

2018-04-16 9:22 GMT+03:00 Petr Ivanov :

>
>
> > On 15 Apr 2018, at 10:19, Ilya Kasnacheev 
> wrote:
> >
> > Hello!
> >
> > With existing binary archive, user can move directories from
> > apache-ignite-fabric/libs/optional to apache-ignite-fabric/libs to
> activate
> > them.
> >
> > But with RPM, user should not contemplate moving directories from
> > /usr/lib/apache-ignite/optional to /usr/lib/apache-ignite.
>
> I always thought of that option as COPYING optional libs, not MOVING.
>
>
> >
> >
> > User lacks permissions for that operation and it would defeat the purpose
> > of having a RPM (imagine trying to upgrade Ignite RPM version with a
> setup
> > like that). "Turning distribution into Slackware" should not be an
> offering.
>
> Can’t imagine use case where Apache Ignite software is installed by one
> user, and run by another, without sudo/root permissions.
> Yet, ignite user’s login shell is disabled indeed and without sudo/root
> permissions optional libs cannot be copied.
> Also — the symlinks is a good idea, but I’ve already thought of it and I’m
> planning addition of special utility for enabling / disabling optional libs
> (like a2enable/a2disable) in next development iteration.
>
>
> >
> > How it could work: Imagine we create /var/lib/ignite, use it as
> > IGNITE_HOME, add symlinks from files in /usr/lib to /var/lib/ignite. This
> > way, we can add and remove symlinks to modules in optional/, and thus
> > enable and disable them as user sees fit.
>
> By linux file hierarchy convention, home dir should be in /usr/lib.
> /var/lib/ is currently used for working files (MySQL alike).
>
>
> >
> > This also answers the problem of "what's IGNITE_HOME for visor launched
> > from /usr/bin”
>
> That is addressed in separate task and will be fixed with minor startup
> script redesign with universal location-independent solution.
>
>
> >
> > But obviously this will require dedication and effort.
>
> No problems with efforts after final design is discussed an agreed.
>
>
> >
> >
> > --
> > Ilya Kasnacheev
> >
> > 2018-04-14 8:03 GMT+03:00 Peter Ivanov :
> >
> >> Current packages design (after installation) does not differ from binary
> >> archive - everything works (except necessity to run service instead
> >> ignite.sh) just the same way, including libs/optional.
> >>
> >> Also, there can be issues with system JDK version by default, but every
> >> problem will be in journalctl and/or  /var/log, and package has strong
> >> dependency on any implementation of JDK 1.8.
> >>
> >>
> >> I am lacking enough feedback about Apache Ignite from packages from real
> >> users, don’t know real use cases so still "moving in the dark".
> >>
> >>
> >> On Fri, 13 Apr 2018 at 22:18, Denis Magda  wrote:
> >>
> >>> Ilya,
> >>>
> >>> Thanks for your inputs. The reason why we decided to split Ignite into
> >>> several packages mimics the reason why Java community introduced
> modular
> >>> subsystem for JDK. That's all about size. Ignite distribution is too
> big,
> >>> and we're trying to separate it into several components so that people
> >> can
> >>> install only the features they need.
> >>>
> >>> The point of a package is to ship something into root file system that
> >> can
>  be used from root file system. If cpp files require compilation we
> >> should
>  not ship them, or ship them to 'examples'. Ditto with benchmarks. If
>  there's no mechanism to add optional libs to Ignite classpath, we
> >> should
>  not ship optional libs. Moreover, some of 'optional' modules such as
> >> yarn
>  don't make sense here because they're not supposed to be used with
>  standalone Ignite.
> >>>
> >>>
> >>> Agree that we need to ship the code that is ready to be run. As for the
> >>> classpath thing, if an optional package is installed into the root
> (core)
> >>> package directory, then its jars have to be added to "ignite/libs"
> >> folder.
> >>> After that, the one needs to restart a cluster node, nd it will add the
> >>> just installed optional libs to the 

[GitHub] ignite pull request #3751: IGNITE-8143: Modified fetching EXTERNAL_LIBS for ...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Docker deployment with EXTERNAL_LIBS environment variable

[Dmitry Pavlov]

Hi Petr,

I've mentioned you in the ticket. Is it obvious change so we could apply
patch?

Or could you advise maintainer/expert here?

Sincerely,
Dmitriy Pavlov

ср, 18 апр. 2018 г. в 7:27, Roman Shtykh :

> I had the same problem (pretty common not having -i option) and fixed it.
> Need a review.
> https://issues.apache.org/jira/browse/IGNITE-8143
>
> -- Roman
>
>
> On Tuesday, April 17, 2018, 7:15:25 p.m. GMT+9, Petr Ivanov <
> mr.wei...@gmail.com> wrote:
>
>
> Hi, Kseniya.
>
>
> I guess that something wrong with wget in distribution (alpine-linux). I
> will need some testing to investigate further.
>
>
>
> > On 17 Apr 2018, at 13:02, Ksenia Vazhdaeva 
> wrote:
> >
> > Hello,
> >
> > I am trying to deploy Apache Ignite 2.4.0 in docker using external libs
> as
> > described at https://apacheignite.readme.io/docs/docker-deployment
> >
> > /docker run -d --name ignite -v
> >
> /storage/ignite/ignite-server-config.xml:/etc/ignite/ignite-server-config.xml
> > \
> >-e "CONFIG_URI=file:///etc/ignite/ignite-server-config.xml" -p
> > 47500:47500 \
> >-e
> > "EXTERNAL_LIBS=
> http://central.maven.org/maven2/org/apache/ignite/ignite-schedule/1.0.0/ignite-schedule-1.0.0.jar
> "
> > \
> >apacheignite/ignite:2.4.0/
> >
> > Docker container is started but in docker logs there is an error
> >
> > /wget: unrecognized option: i
> > BusyBox v1.27.2 (2017-12-12 10:41:50 GMT) multi-call binary.
> >
> > Usage: wget [-c|--continue] [--spider] [-q|--quiet] [-O|--output-document
> > FILE]
> > [--header 'header: value'] [-Y|--proxy on/off] [-P DIR]
> > [-S|--server-response] [-U|--user-agent AGENT] [-T SEC] URL.../
> >
> > Thus the external lib is not loaded.
> > Could you, please, help me to resolve the problem or provide me with
> another
> > way to add external libraries to Ignite classpath?
> >
> > Thanks in advance,
> > Ksenia
> >
> >
> >
> > --
> > Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: MTCGA: IGNITE-7791 and GridDhtPartitionsSingleMessage

[Maxim Muzafarov]

Igniters,
especially who participated in implementaion of IEP-4. I need your advice.

I've prepeared fixes for this flaky test. Can you review my changes [1] and
share your thoughts?

In my opinion, we should not perform caches info removing from
LocalJoinCachesContext captured state on reconnect event happened.
It leads to incorrect CacheAffinityChangeMessage message processing after
client node reconnects.

I've prepeared all needs for review:
1) PR [1]
2) JIRA issue [2]
3) 100% reproducer for this case [3] (passes after changes)
4) Report [4] run testReconnectCacheDestroyedAndCreated 200 times (passes
OK)
5) Run IgniteClientNodesTestSuite [5] (passes OK)
6) Run ALL Build [6] (have some FAIL but not related to this issue)
7) My vision to these fixes in JIRA comment [7]
8) Upsource review created [8]

[1] https://github.com/apache/ignite/pull/3779
[2] https://issues.apache.org/jira/browse/IGNITE-7791
[3]
https://ci.ignite.apache.org/viewLog.html?currentGroup=test=org.apache.ignite.testsuites.IgniteClientNodesTestSuite%23teamcity%23org.apache.ignite.internal%23teamcity%23IgniteClientReconnectDelayedSpiTest=1=DURATION_DESC=20===IgniteTests24Java8_ClientNodes=1192536=testsInfo
[4]
https://ci.ignite.apache.org/viewLog.html?buildId=1196532=IgniteTests24Java8_CacheFailover1=testsInfo
[5]
https://ci.ignite.apache.org/viewLog.html?buildId=1192536=IgniteTests24Java8_ClientNodes=testsInfo
[6] https://ci.ignite.apache.org/viewLog.html?buildId=1211532
[7]
https://issues.apache.org/jira/browse/IGNITE-7791?focusedCommentId=16437292=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16437292
[8] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-558

пн, 19 мар. 2018 г. в 11:50, Alexey Goncharuk :

> Hello Maxim,
>
> SingleMessage with exchId=null is sent when a node updates local
> partitions' state and schedules a background cluster notification. In
> contrast, when a partition map exchange happends, it is completed with
> exchId != null.
>
> I need more context regarding how this message interferes with the exchange
> and what the difference between the two messages is so that during the
> regular scenario the assertion does not happen.
>
> 2018-03-13 20:58 GMT+03:00 Maxim Muzafarov :
>
> > Hi all,
> >
> > I'm working on [1] IgniteClientReconnectCacheTest class with frakly
> > test-case testReconnectCacheDestroyedAndCreated with success rate 32.4%.
> >
> > I've leaved comment in JIRA [2] and new test-case with reproducing this
> > issue.
> > Basicly, when we receiving GridDhtPartitionsSingleMessage with
> exchId=null
> > not
> > in proper time we've got this Assertion error. Ignite client instance
> > erases all it's caches after reconnect, so it has no information about
> > cache named 'static-cache' that persists on server nodes and when he
> > recieve this SignleMessage after reconnection it will have 'Failed to
> > reinitialize local partitions (preloading will be stopped)'.
> >
> > Should we perform clean-up [3] client caches in case of reconnect client
> > ignite instance?
> > Why we should clean clinent caches after node reconnects? Can't catch the
> > idea of it.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-7791
> > [2]
> > https://issues.apache.org/jira/browse/IGNITE-7791?
> > focusedCommentId=16391409=com.atlassian.jira.
> > plugin.system.issuetabpanels:comment-tabpanel#comment-16391409
> > [3]
> > https://github.com/apache/ignite/blob/master/modules/
> > core/src/main/java/org/apache/ignite/internal/processors/cache/
> > CacheAffinitySharedManager.java#L190
> >
>

[jira] [Created] (IGNITE-8309) Cannot change WAL mode from client node

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-8309:
---

 Summary: Cannot change WAL mode from client node
 Key: IGNITE-8309
 URL: https://issues.apache.org/jira/browse/IGNITE-8309
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 2.5
Reporter: Ilya Kasnacheev
Assignee: Vladimir Ozerov


I have cluster of a few nodes with persistence region, and a few clients, 
obviously without persistence region.

When I try to do disableWal(cacheName) on client node, I observe the following 
exception:

{code}
Caused by: org.apache.ignite.IgniteCheckedException: Cannot change WAL mode 
because persistence is not enabled for cache(s) [caches=[data0], 
dataRegion=null]
at 
org.apache.ignite.internal.processors.cache.WalStateManager.errorFuture(WalStateManager.java:759)
 ~[ignite-core-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
at 
org.apache.ignite.internal.processors.cache.WalStateManager.init(WalStateManager.java:292)
 ~[ignite-core-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.changeWalMode(GridCacheProcessor.java:3045)
 ~[ignite-core-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
{code}

>From server node I can disable and enable WAL without problems. Since it's a 
>cluster-wide operations, I expect it to be doable from client also.



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

[jira] [Created] (IGNITE-8308) Sporadic NPE in IgniteAtomicSequenceExample at GridDhtTxPrepareFuture.map

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-8308:
---

 Summary: Sporadic NPE in IgniteAtomicSequenceExample at 
GridDhtTxPrepareFuture.map
 Key: IGNITE-8308
 URL: https://issues.apache.org/jira/browse/IGNITE-8308
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.8
Reporter: Ksenia Rybakova


Sporadic NPE occures in IgniteAtomicSequenceExample at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map

{noformat}

java.lang.NullPointerException
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1513)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1462)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1194)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:667)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1040)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:481)
 at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:465)
 at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareTx(IgniteTxHandler.java:237)
 at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:123)
 at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:145)
 at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:143)
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:836)
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:378)
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:302)
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:96)
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:247)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1512)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1140)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:119)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1080)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)

{noformat}

 

For instance with 2 nodes:

Node1:

{noformat}

[17:17:56] Ignite node started OK (id=ac7dda5e) [17:17:56] Topology snapshot 
[ver=2, servers=2, clients=0, CPUs=32, heap=3.0GB] >>> Cache atomic sequence 
example started. Sequence initial value on local node: 0 Sequence 
[currentValue=0, afterIncrement=1] Sequence [currentValue=1, afterIncrement=2] 
Sequence [currentValue=2, afterIncrement=3] Sequence [currentValue=3, 
afterIncrement=4] Sequence [currentValue=4, afterIncrement=5] Sequence 
[currentValue=5, afterIncrement=6] Sequence [currentValue=6, afterIncrement=7] 
Sequence [currentValue=7, afterIncrement=8] Sequence [currentValue=8, 
afterIncrement=9] Sequence [currentValue=9, afterIncrement=10] Sequence 
[currentValue=10, afterIncrement=11] Sequence [currentValue=11, 
afterIncrement=12] Sequence [currentValue=12, afterIncrement=13] Sequence 
[currentValue=13, afterIncrement=14] Sequence [currentValue=14, 
afterIncrement=15] Sequence [currentValue=15, afterIncrement=16] Sequence 
[currentValue=16, afterIncrement=17] Sequence [currentValue=17, 
afterIncrement=18] Sequence [currentValue=18, afterIncrement=19] Sequence 
[currentValue=19, afterIncrement=20] Sequence after incrementing [expected=20, 
actual=20] Finished atomic sequence example... Check all nodes for output (this 
node is also part of the cluster).

{noformat}

Node2:

{noformat}

[17:17:42] Ignite node started OK (id=734c312e) [17:17:42] Topology snapshot 
[ver=1, servers=1, clients=0, CPUs=32, heap=2.0GB] [17:17:55] Topology snapshot 
[ver=2, servers=2, clients=0, CPUs=32, heap=3.0GB] 
[17:17:56,719][SEVERE][utility-#87%null%][GridCacheIoManager] Failed processing 
message [senderId=ac7dda5e-491b-43ce-aa22-d5442fb4db8c, 
msg=GridNearTxPrepareRequest 
[futId=14f91dec261-f8b65720-5df3-4f06-b1d5-f74b356049cf, 

[jira] [Created] (IGNITE-8307) Web console: panel with buttons Cancel, Save doesn't float at the bottom of the screen under Safari 11.1

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8307:
--

 Summary: Web console: panel with buttons Cancel, Save doesn't 
float at the bottom of the screen under Safari 11.1
 Key: IGNITE-8307
 URL: https://issues.apache.org/jira/browse/IGNITE-8307
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Ilya Borisov






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

[GitHub] ignite pull request #3861: IGNITE-8303: Avoided failure handler invocation w...

[andrey-kuznetsov]

GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-8303: Avoided failure handler invocation when exchange-worker …

…terminates before reconnect.

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

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

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

https://github.com/apache/ignite/pull/3861.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3861


commit 94e8cdd3602d4b1dea1ca9d0175b27602f455ebb
Author: Andrey Kuznetsov 
Date:   2018-04-18T07:41:50Z

IGNITE-8303: Avoided failure handler invocation when exchange-worker 
terminates before reconnect.




---

Re: [GitHub] ignite pull request #3719: IGNITE-8048 merge query entities for dynamic cach...

[Vladimir Ozerov]

Hi,

What is the problem being addressed by this change? We do not allow for
multiple indexes creation at a time. The only possible way to create an
index is CREATE INDEX command when only one index is created.

On Tue, Apr 17, 2018 at 10:08 PM, Manu  wrote:

> Hi!
>
> I have taken a look at this new functionality and it is very interesting.
> But I have a couple of doubts about the performance.
>
> For each modification of the same QueryEntitity, a new
> SchemaAbstractOperation is generated, in the case of adding columns the
> performance is not affected, but in the case of creating new indexes I
> think
> there is a problem:
>
> - If the modification in the QueryEntitity contains the creation of N
> indexes, N SchemaIndexCreateOperation are generated for the same table,
> this
> causes the underline cache to be scanned N times to populate each indice
> (by
> SchemaIndexCacheVisitorClosure). For caches with a few data is not a
> problem, but for caches with millions of records is not optimal.
>
> A possible solution would be to create a new type of
> SchemaAbstractOperation
> (for example SchemaUpgradeQueryEntityOperation with the new QueryEntity,
> boolean forceRebuild, boolean forceMutateQueryEntity), to register on one
> block this new QueryEntitity for:
>
> - Create new indices at same time (populate all indices with a single scan)
> (auto, like now)
> - With on demand forceMutateQueryEntity (ignore QueryEntity patch checks),
> ability to eliminate indices (and fully release resources) and columns.
> Over
> time the QueryEntity will evolve and at some point it is possible that
> certain columns and indices are not necessary any more... I think it would
> be interesting to allow trim indexed data and eliminate unused columns.
>
> Hope it helps!
>
> Regards
>
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

Re: IEP-18: Transparent Data Encryption

[Vladimir Ozerov]

Hi Nikolay,

Good rule of thumb here - the more design is discussed prior to
implementation, the better. There is no specific definition of well- or
ill-defined design, this is more about common sense and our general
experience. I would say that minimal set of things to be addressed for most
major features is (TDE-specific comments are in parantheses):
1) Algorithms (how we encrypt/decrypt, when we encrypt/decrypt, etc)
2) Protocol changes (new messages, changes to old messages)
3) Changes to persistence (where to store encrypted keys, changes to WAL)
4) Public API and usability (key management interfaces, how to
enable/disable, activation flow, etc)

Without it we are at risk of wasting time in future.

On Mon, Apr 16, 2018 at 3:24 PM, Nikolay Izhikov 
wrote:

> Hello, Vladimir.
>
> > community is not aware of concrete architecture and proposed public API
>
> Concrete architecture is described in IEP-18 [1].
> Please, tell me, what else you want to be written.
>
> I think answers to all questions have to be addressed(and discussed with
> community!) when we crack into implementation.
> Personally, I don't believe in any kind of more detailed design from eagle
> height.
> So I want to move from one part of this feature to another and make
> concrete choices just before implementation.
>
> Thoughts?
>
> Public API proposition will be part of an implementation and, of course,
> will be discussed.
> I don't think we have to do specific choices at the moment.
>
> > We need to continue discussion and come up with detailed design.
>
> Can you give me the check-list of detailed design?
> As far as I can see many of other IEP(already implemented) doesn't include
> any details you mentioned here [2], [3].
>
> Anyway, let's make this IEP some kind of "reference implementation" for
> other IEP's :).
>
> > 1) How encryption is configured - public API is needed
>
> Similarly to other SPI.
>
> > 2) How encrypted cluster is started
>
> I study links you provide.
> I asked DB administrators I know.
> Looks like we can implement automatic TDE activation.
>
> > 3) How and where encrypted cache keys are stored
>
> I want to follow your advice and store CEK's near cache.
>
> > 4) Protocol of key's exchange between nodes
> > 5) Detailed description of encryption flow - what algorithm is used?
> will> we use CBC?
> > 6) What changes would be required to WAL logic (at the very least ->
> enumerate affected types of records)?
>
> I don't have specific answers to this questions.
> Do you think we must answer this questions before starting any
> implementation?
>
> > 7) Would it be possible to enable/disable encryption on specific>
> cache/table in runtime?
>
> No, for the first implementation.
> Cache has to be created as encrypted.
> If cache created as decrypted it can't become encrypted.
>
> In the future we can extend encryption mechanism and add this feature to
> the product.
>
> > 8) Would these changes affect compression design anyhow?
>
> No.
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> 18%3A+Transparent+Data+Encryption
> [2] https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> 4+Baseline+topology+for+caches
> [3] https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> 7%3A+Ignite+internal+problems+detection
>
> В Пн, 16/04/2018 в 13:28 +0300, Vladimir Ozerov пишет:
> > Hi Nikolay,
> >
> > I noticed that some tickets have been created for this feature.
> Hopefully,
> > you haven't started implementation yet, because at this point community
> is
> > not aware of concrete architecture and proposed public API. We need to
> > continue discussion and come up with detailed design. Of most importance
> we
> > need to understand the following:
> > 1) How encryption is configured - public API is needed (how to setup key
> > providers, how to enable encryption for specific caches, etc)
> > 2) How encrypted cluster is started - normally, I do not expect any
> > additional manual actions from user once everything is configured.
> > Especially, in presence of auto-activation capability.
> > 3) How and where encrypted cache keys are stored
> > 4) Protocol of key's exchange between nodes
> > 5) Detailed description of encryption flow - what algorithm is used? will
> > we use CBC?
> > 6) What changes would be required to WAL logic (at the very least -
> > enumerate affected types of records)?
> > 7) Would it be possible to enable/disable encryption on specific
> > cache/table in runtime?
> > 8) Would these changes affect compression design anyhow?
> >
> > Vladimir.
> >
> > On Tue, Apr 10, 2018 at 5:30 PM, Vladimir Ozerov 
> > wrote:
> >
> > > Hi NIkolay,
> > >
> > > Regarding system caches, rule of thumb here - do not use them. Keys
> should
> > > be stored near cache.
> > >
> > > As far as password:
> > > 1) Oracle auto-login wallet [1]
> > > 2) MySQL- password may be set inside configuration [2]
> > >
> > > I do not think that any kind of prompts are needed here out 

Re: Apache Ignite nightly release builds

[Pavel Tupitsyn]

Great job, Petr!

FYI: myget credentials can be found in [1] (PMC only)

[1] https://svn.apache.org/repos/private/pmc/ignite/credentials/myget.org

On Mon, Apr 16, 2018 at 11:49 AM, Petr Ivanov  wrote:

> Hi, Igniters!
>
>
> I’m glad to inform that starting today Apache Ignite Nightly Builds
> provide Nuget and Maven stagings at MyGet [1].
>
> Instructions on connecting to these feeds are here:
>  — Nuget [2]
>  — Maven [3]
>
>
> Enjoy.
>
>
> [1] https://www.myget.org/gallery/apache-ignite-nightly <
> https://www.myget.org/gallery/apache-ignite-nightly>
> [2] http://docs.myget.org/docs/walkthrough/getting-started-with-nuget <
> http://docs.myget.org/docs/walkthrough/getting-started-with-nuget>
> [3] http://docs.myget.org/docs/walkthrough/getting-started-with-maven <
> http://docs.myget.org/docs/walkthrough/getting-started-with-maven>
>
> > On 24 Mar 2018, at 11:42, Dmitriy Setrakyan 
> wrote:
> >
> > Thanks, Denis. It should be added to the download page, I updated the
> ticket.
> >
> > On Sat, Mar 24, 2018 at 5:48 AM, Denis Magda > wrote:
> > Created a JIRA ticket for that:
> > https://issues.apache.org/jira/browse/IGNITE-8040 <
> https://issues.apache.org/jira/browse/IGNITE-8040>
> >
> > --
> > Denis
> >
> > On Fri, Mar 23, 2018 at 1:27 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org >
> > wrote:
> >
> > > Awesome! Finally instead of asking our users to build from the master,
> we
> > > can provide a link to the nightly build instead.
> > >
> > > Denis, can you please add these links to the website?
> > >
> > > D.
> > >
> > > On Thu, Mar 22, 2018 at 1:27 PM, Petr Ivanov  > wrote:
> > >
> > >> It works, thanks!
> > >>
> > >>
> > >> Here is updated links for Artifacts and Changes respectively with
> silent
> > >> guest login (can be added to bookmarks):
> > >> * https://ci.ignite.apache.org/viewLog.html?buildId=lastSucces <
> https://ci.ignite.apache.org/viewLog.html?buildId=lastSucces>
> > >> sful=Releases_NightlyRelease_RunApacheIgnite
> > >> NightlyRelease=artifacts=1
> > >> * https://ci.ignite.apache.org/viewLog.html?buildId=lastSucces <
> https://ci.ignite.apache.org/viewLog.html?buildId=lastSucces>
> > >> sful=Releases_NightlyRelease_RunApacheIgnite
> > >> NightlyRelease=buildChangesDiv=1
> > >>
> > >>
> > >>
> > >> > On 22 Mar 2018, at 13:06, Vitaliy Osipov  > wrote:
> > >> >
> > >> > 
> > >>
> > >>
> > >
> >
>
>