[GitHub] ignite pull request #3893: IGNITE-8342: When creating an index, unexpected n...

[shroman]

GitHub user shroman opened a pull request:

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

IGNITE-8342: When creating an index, unexpected non-default token cau…

…ses an infinite loop.

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

$ git pull https://github.com/shroman/ignite master

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

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


commit df03b3677592bd212bb2bfaea5d6b811b156fc1f
Author: shroman 
Date:   2018-04-21T05:08:11Z

IGNITE-8342: When creating an index, unexpected non-default token causes an 
infinite loop.




---

Re: Service grid redesign

[Valentin Kulichenko]

Denis,

> On the other hand, if exception is thrown from the *execute() *method,
then service won't be undeployed.

This is actually weird... What is going to happen in this case and how user
would handle this?

-Val

On Fri, Apr 20, 2018 at 1:10 AM, Denis Mekhanikov 
wrote:

> Val,
>
> *init()* method is executed before a service is considered deployed.
> If any exception is thrown from it, then it will be handled as deployment
> failure.
>
> *execute() *method is run after the service is deployed, and it can keep
> running until the service is cancelled.
> This method has its own thread, so it can perform some background work.
>
> Suppose you want to deploy HTTP server as a service on one of your nodes.
> You can place HTTP server creation logic in the *init() *method.
> If some nodes don't have a permission to listen to needed ports, then a
> corresponding exception will be propagated to the user code.
> On the other hand, if exception is thrown from the *execute() *method, then
> service won't be undeployed.
>
> Denis
>
> пт, 20 апр. 2018 г. в 2:35, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
> > Denis,
> >
> > I totally agree with you. I'm just not sure why do we need two methods
> > (init and execute) that have virtually same semantics. With the new
> design,
> > what would be the difference between these methods from user point of
> view,
> > and how one would determine what exactly should go in each of them?
> Unless
> > I'm missing something, it looks like unnecessary complication.
> >
> > -Val
> >
> > On Tue, Apr 17, 2018 at 1:00 AM, Denis Mekhanikov  >
> > wrote:
> >
> > > Val,
> > >
> > > Service initialisation is not going to happen in the discovery thread.
> > > It should be done asynchronously, and initialisation results should be
> > sent
> > > to the coordinator over communication.
> > > This is described in the IEP:
> > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > > 17%3A+Oil+Change+in+Service+Grid#IEP-17:OilChangeinServiceGrid-
> > > Successfulscenario
> > >
> > > *init()* method is a validation step, making sure, that service is
> ready
> > > for work.
> > > And deployment shouldn't be considered successful until *init()*
> methods
> > > finish their work on the assigned nodes.
> > > Also *cancel() *and *init() *methods may be useful if we decide to
> > > implement moving existing services to new nodes
> > >  > > 17%3A+Oil+Change+in+Service+Grid#IEP-17:OilChangeinServiceGrid-
> > > Movingexistingservicestonewnodes>
> > >  in
> > > future.
> > > These methods can be used to save and restore service's state from
> cache,
> > > when it is rebalanced to another node.
> > >
> > > As Denis said, if we are not going to prevent nodes from starting on
> > > service failures, then we should at least generate corresponding
> events.
> > > Otherwise there won't be any way to react to service initialization
> > > failures during nodes startup.
> > >
> > > Denis
> > >
> > > вт, 17 апр. 2018 г. в 6:59, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com>:
> > >
> > > > I agree we shouldn't do anything synchronously within discovery
> > threads.
> > > If
> > > > something goes wrong, we just need to properly notify the user,
> logging
> > > and
> > > > events seem to be right options to achieve that.
> > > >
> > > > BTW, with this design I'm not sure init() method makes sense,
> probably
> > we
> > > > should deprecate it.
> > > >
> > > > -Val
> > > >
> > > > On Mon, Apr 16, 2018 at 12:03 PM, Denis Magda 
> > wrote:
> > > >
> > > > > Denis,
> > > > >
> > > > > In general, service initialization shouldn't prevent a node from
> > > joining
> > > > > the cluster or slowing down that process. Thus, I would start the
> > > > > initialization routines only after the node is accepted by the
> > cluster.
> > > > If
> > > > > the initialization fails then we need to report a respective
> message
> > to
> > > > the
> > > > > logs and, probably, generate a system event the user can be
> > subscribed
> > > > to.
> > > > >
> > > > > Regardless, of the service initialization time, I think we still
> need
> > > to
> > > > > utilize discovery SPI to avoid problems discussed later.
> > > > >
> > > > > Val, others, what do you think about that?
> > > > >
> > > > >
> > > > > --
> > > > > Denis
> > > > >
> > > > > On Mon, Apr 16, 2018 at 10:29 AM, Denis Mekhanikov <
> > > > dmekhani...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Basically, my question is: at which moment services should be
> > > deployed
> > > > on
> > > > > > connecting nodes?
> > > > > > Should we reject a node from being included into a topology, if
> > > > services,
> > > > > > that are assigned to it, fail to deploy?
> > > > > >
> > > > > > It would be good to be sure, that all assigned services are
> > > initialised
> > > > > and
> > > > > > working, when node start is finished.
> > > 

Re: GA Grid: Can IGNITE-8242 be include in 2.5 release?

[Denis Magda]

Those are isolated changes that shouldn't affect the rest of the platform.

Andrey G., please approve the merge. I think it's fine to do.

--
Denis

On Fri, Apr 20, 2018 at 3:26 AM, Yury Babak  wrote:

> Sorry, https://issues.apache.org/jira/browse/IGNITE-7916 was done before
> 2.5 branch created.
>
> Yury Babak
> GridGain Systems
>
> On Fri, Apr 20, 2018 at 1:24 PM, Yury Babak  wrote:
>
>> Denis,
>>
>> In that case we should also add the following tickets into release:
>>
>> https://issues.apache.org/jira/browse/IGNITE-7877 (Improve code style in
>> GA part)
>> https://issues.apache.org/jira/browse/IGNITE-7916 (GA Grid examples
>> should be ready for auto run on TeamCity)
>> https://issues.apache.org/jira/browse/IGNITE-8181 (fix for javadoc)
>>
>> Andrey,
>>
>> if you ok with it I could cherry pick those tickets into 2.5 branch
>>
>> Regards,
>>
>> Yury Babak
>> GridGain Systems
>>
>> On Fri, Apr 20, 2018 at 1:48 AM, Denis Magda  wrote:
>>
>>> Yuri, Andrey,
>>>
>>> Could you have a look and include the ticket into the release?
>>>
>>> --
>>> Denis
>>>
>>>
>>> On Thu, Apr 19, 2018 at 3:23 PM, techbysample 
>>> wrote:
>>>
 Denis/Yury

 Can ticket https://issues.apache.org/jira/browse/IGNITE-8242  be
 included
 within 2.5 release?
 Upon review of my tickets today, I noticed the fixed version was updated
 from 2.5 to 2.6?

 This ticket addresses a minor bug in GA Grid.

 I have removed method GAGridUtils.getGenesForChromosome() as it is
 problematic when Chromosome contains duplicate genes.

 GAGridUtils.getGenesInOrderForChromosome() will be used instead.

 Please advise.

 Turik



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

>>>
>>>
>>
>

Re: Topology-wide notification on critical errors

[Denis Magda]

It might be useful if it's supported out of the box however usually DevOps
and admins use tools like DynaTrace or Splunk to monitor all the logs,
arrange logs in a meaningful way and set up special hooks for particular
events. It means if an event happens only on 1 node the tool will still
detect it.

Thus my question is who is a primary user of this improvement?

--
Denis

On Fri, Apr 20, 2018 at 5:12 AM, Yakov Zhdanov  wrote:

> Of course, no guarantees, but at least an effort.
>
> --Yakov
>

GA Grid Documentation for 2.5

[Denis Magda]

Hi Turik,

Are GA docs ready for 2.5 or you still working on them?
https://apacheignite.readme.io/v2.4/docs/genetic-algorithms

Please create a documentation ticket (component=documentation and
fixVersion=2.5) and assign on Akmal for final review once you're done. He
is our main ML docs editor.

Prachi will help to rearrange the content on the site: IGNITE-8349


--
Denis

[jira] [Created] (IGNITE-8349) Move GA Grid description to ML site page

[Denis Magda (JIRA)]

Denis Magda created IGNITE-8349:
---

 Summary: Move GA Grid description to ML site page
 Key: IGNITE-8349
 URL: https://issues.apache.org/jira/browse/IGNITE-8349
 Project: Ignite
  Issue Type: Task
  Components: site
Reporter: Denis Magda
Assignee: Prachi Garg
 Fix For: 2.5


Prachi, please move GA grid overview from here [1] to a dedicated section of 
the main ML page [2].

Don't forget to remove GA grid beta from the features page [3].

[1] https://ignite.apache.org/addons.html#ga-grid
[2] https://ignite.apache.org/features/machinelearning.html
[3] https://ignite.apache.org/features.html



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

[GitHub] ignite pull request #3892: Ignite-2.5.1.b5

[agoncharuk]

GitHub user agoncharuk opened a pull request:

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

Ignite-2.5.1.b5



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

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

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

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


commit 1cea80d29f4f1c61ed56ad1261b74ed42611bf64
Author: Ilya Lantukh 
Date:   2018-04-06T10:49:10Z

IGNITE-8018 Optimized GridCacheMapEntry initialValue() - Fixes #3686.

Signed-off-by: Alexey Goncharuk 

commit 37fc72542eb6baa8be8b41aecd08a194102d13c1
Author: Алексей Стельмак 
Date:   2018-04-06T15:28:22Z

IGNITE-8049 Limit the number of operation cycles in B+Tree - Fixes #3769.

Signed-off-by: dpavlov 

(cherry picked from commit e491f10)

commit 76e293654e34c927d6c9efc85a12e736b58a21f2
Author: Eduard Shangareev 
Date:   2018-04-06T16:22:07Z

IGNITE-8114 Add fail recovery mechanism to tracking pages - Fixes #3734.

Signed-off-by: dpavlov 

(cherry picked from commit 0829397)

commit 49f11db727febc83297c7f0f5de9e6f98f0197fa
Author: Alexey Kuznetsov 
Date:   2018-04-09T02:25:50Z

IGNITE-8159 control.sh: Fixed NPE on adding nodes on empty baseline and not 
active cluster.

(cherry picked from commit 834869c)

commit 9ad7be2f51b6dcdcdf43fedb298cd4e240f0adab
Author: Ilya Borisov 
Date:   2018-04-09T13:59:32Z

IGNITE-8155 Web Console: Fixed number pattern warning in browser console.

(cherry picked from commit 5d8f570)

commit 4aa56751906e5db7aad025a7193933fa929aae26
Author: Vasiliy Sisko 
Date:   2018-04-09T15:13:21Z

IGNITE-7940 Visor CMD: Added "cache -slp" and "cache -rlp" commands to show 
and reset lost partitions for specified cache.

(cherry picked from commit abfa0f5)

commit cc04c5c70af1bdbba834f73330e73277b60e23fc
Author: Eduard Shangareev 
Date:   2018-04-09T16:15:50Z

IGNITE-8114 Additional fix for Add fail recovery mechanism to tracking pages

(cherry picked from commit 961fc35)

commit c70d85aa36c702ea0f29bd8668e9bf0790f9ba11
Author: Vasiliy Sisko 
Date:   2018-04-10T08:42:24Z

IGNITE-8126 Web Console: Fixed code generation for cache load.

(cherry picked from commit a0a187b)

commit 8d3755b9c58eef12c5fc9cabfc0b1c05f6db716e
Author: Semyon Boikov 
Date:   2018-04-10T08:37:39Z

IGNITE-7222 Added ZooKeeper discovery SPI

commit b096a463c338565a7661f8a853a257518d872997
Author: Stanislav Lukyanov 
Date:   2018-04-09T11:33:13Z

IGNITE-7904: Changed IgniteUtils::cast not to trim exception chains. This 
closes #3683.

commit 82a4c024fe06ef8c8deeaf762f0cc20a8e481252
Author: Roman Guseinov 
Date:   2018-04-09T11:45:44Z

IGNITE-7944: Disconnected client node tries to send JOB_CANCEL message. 
Applied fix:
- Skip sending message if client disconnected;
- Throw IgniteCheckedException if a client node is disconnected and 
communication client is null.
This closes #3737.

commit c1745de37891026e0a719f0c1d1afe768dfccbf3
Author: Vasiliy Sisko 
Date:   2018-04-10T10:48:52Z

IGNITE-7927 Web Console: Fixed demo for non-collocated joins.

(cherry picked from commit 647620b)

commit b28287d1861fd841a18d0eef95eff309d21a55ef
Author: Alexey Goncharuk 
Date:   2018-04-10T13:22:28Z

IGNITE-8025 Future must fail if assertion error has been thrown in the 
worker thread

commit a832f2b2e5788c45114c3cb5529d7cf53d08f9a6
Author: Andrey Kuznetsov 
Date:   2018-04-10T14:30:12Z

ignite-7772 System workers critical failures handling

Signed-off-by: Andrey Gura 

commit 912433ba9aa113508d05930691b251eccd8f5870
Author: Aleksey Plekhanov 
Date:   2018-04-10T15:54:03Z

IGNITE-8069 IgniteOutOfMemoryException should be handled accordingly to 
provided failure handler

Signed-off-by: Andrey Gura 

commit 99feab6ace66d011b677fd4d57b44fc54da8fd4f
Author: Alexey Goncharuk 
Date:   2018-04-10T17:33:47Z

IGNITE-6430 Complete failing test early

commit 526fb0ee612ef71fde58a1274db35e8205304a63
Author: Dmitriy Sorokin 
Date:   2018-04-10T19:20:41Z

IGNITE-8101 Ability to terminate system workers by JMX for test purposes.

Signed-off-by: Andrey Gura 

commit b4cb2f0df944534743a9d73811e047eda572258c
Author: mcherkasov 
Date:   2018-04-11T00:27:20Z

IGNITE-8153 Nodes fail to connect each other when SSL is 

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

[Nikolay Izhikov]

I set one more enviromnent variable and now got success tests run.
I see following output:

*** 2 failures are detected in the test module "identity_resolver_test"

Is it OK?



В Пт, 20/04/2018 в 19:28 +0300, Nikolay Izhikov пишет:
> Hello, Igor.
> 
> As far as I can see from the Team City settings the actual command to 
> configure current master sources is
> 
> `./configure --enable-odbc --enable-tests --prefix=%env.CPP_STAGING% 
> CPPFLAGS=-I%env.CPP_STAGING%/include LDFLAGS=-L%env.CPP_STAGING%/lib`
> 
> Can you give me content of CPP_STAGING directory?
> I was able to build cpp sources with latest ubuntu boost and latest 
> teamcity_boost [1], teamcity_messages files [2].
> After that I still got error when running
> 
> export LD_LIBRARY_PATH=$JAVA_HOME/jre/lib/amd64/server
> export IGNITE_NATIVE_TEST_CLASSPATH=true
> export 
> IGNITE_NATIVE_TEST_CPP_CONFIG_PATH=/home/user/src/ignite/modules/platforms/cpp/core-test/config
> ./ignite-tests
> 
> I see Ignite start messages and after it:
> 
> ```
> [20-04-2018 16:22:51][INFO ][main][IgnitePluginProcessor]   ^-- Copyright(C) 
> Apache Software Foundation
> [20-04-2018 16:22:51][INFO ][main][IgnitePluginProcessor] 
> unknown location(0): fatal error: in 
> "BinaryIdentityResolverTestSuite/IdentityEquilityWithoutGuid": memory access 
> violation at address: 0x0008: no mapping at fault address
> src/binary_identity_resolver_test.cpp(316): last checkpoint: 
> "IdentityEquilityWithoutGuid" entry.
> ```
> 
> I'm not sure I move to the right direction.
> I just want to be able to run CPP tests locally.
> 
> [1] 
> https://github.com/JetBrains/teamcity-cpp/blob/master/boost/teamcity_boost.cpp
> [2] 
> https://github.com/JetBrains/teamcity-cpp/blob/master/common/teamcity_messages.cpp
> 
> 
> В Чт, 19/04/2018 в 14:11 +0300, Nikolay Izhikov пишет:
> > Igor.
> > 
> > Following settings helps to remove some error, but I still can't make all 
> > things works.
> > Is it right way to get things work?
> > 
> > ```
> > > export LDFLAGS='-L/usr/lib/x86_64-linux-gnu/'
> > > export LIBS='-lboost_unit_test_framework'
> > > libtoolize && aclocal && autoheader && automake --add-missing && 
> > > autoreconf
> > > ./configure --enable-odbc --enable-tests
> > > make
> > 
> > ```
> > 
> > Now, It seems that compiler can found references to boost functions.
> > The only error I see from the output is
> > 
> > make[3]: вход в каталог 
> > «/home/dragon/src/ignite/modules/platforms/cpp/odbc-test»
> >   CXXLDignite-odbc-tests
> > /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o: In 
> > function `_start':
> > (.text+0x20): undefined reference to `main'
> > collect2: error: ld returned 1 exit status
> > 
> > I work on Ubuntu linux x64:
> > 
> > ```
> > > uname -a
> > 
> > Linux host 4.13.0-38-generic #43-Ubuntu SMP Wed Mar 14 15:20:44 UTC 2018 
> > x86_64 x86_64 x86_64 GNU/Linux
> > ```
> > 
> > В Чт, 19/04/2018 в 13:40 +0300, Nikolay Izhikov пишет:
> > > Hello, Igor.
> > > 
> > > Still doesn't work.
> > > 
> > > I removed files you mentioned and got following error messages:
> > > 
> > > make[3]: вход в каталог 
> > > «/home/dragon/src/ignite/modules/platforms/cpp/odbc-test»
> > >   CXXLDignite-odbc-tests
> > > /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o: In 
> > > function `_start':
> > > (.text+0x20): undefined reference to `main'
> > > src/cursor_test.o: In function 
> > > `CheckCursorNeedUpdate(ignite::odbc::Cursor&)':
> > > /home/dragon/src/ignite/modules/platforms/cpp/odbc-test/src/cursor_test.cpp:77:
> > >  undefined reference to 
> > > `boost::unit_test::unit_test_log_t::set_checkpoint(boost::unit_test::basic_cstring > >  const>,
> > > unsigned long, boost::unit_test::basic_cstring)'
> > > 
> > > 
> > > В Чт, 19/04/2018 в 13:15 +0300, Igor Sapego пишет:
> > > > They can be executed locally, and no, you don't need any library.
> > > > It is just that Teamcity plugin depends on exact version of Boost,
> > > > as I mentioned before. You can disable it if you are going to run
> > > > tests locally.
> > > > 
> > > > For this you should remove from these files
> > > > platform/cpp/core-test/Makefile.am and
> > > > platform/cpp/odcs-test/Makefile.am
> > > > 
> > > > following lines:
> > > > src/teamcity_messages.cpp \
> > > > src/teamcity_boost.cpp \
> > > > 
> > > > 
> > > > Best Regards,
> > > > Igor
> > > > 
> > > > On Wed, Apr 18, 2018 at 6:17 PM, Nikolay Izhikov 
> > > > wrote:
> > > > 
> > > > > 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::
> > > > > 

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

[Nikolay Izhikov]

Hello, Igor.

As far as I can see from the Team City settings the actual command to configure 
current master sources is

`./configure --enable-odbc --enable-tests --prefix=%env.CPP_STAGING% 
CPPFLAGS=-I%env.CPP_STAGING%/include LDFLAGS=-L%env.CPP_STAGING%/lib`

Can you give me content of CPP_STAGING directory?
I was able to build cpp sources with latest ubuntu boost and latest 
teamcity_boost [1], teamcity_messages files [2].
After that I still got error when running

export LD_LIBRARY_PATH=$JAVA_HOME/jre/lib/amd64/server
export IGNITE_NATIVE_TEST_CLASSPATH=true
export 
IGNITE_NATIVE_TEST_CPP_CONFIG_PATH=/home/user/src/ignite/modules/platforms/cpp/core-test/config
./ignite-tests

I see Ignite start messages and after it:

```
[20-04-2018 16:22:51][INFO ][main][IgnitePluginProcessor]   ^-- Copyright(C) 
Apache Software Foundation
[20-04-2018 16:22:51][INFO ][main][IgnitePluginProcessor] 
unknown location(0): fatal error: in 
"BinaryIdentityResolverTestSuite/IdentityEquilityWithoutGuid": memory access 
violation at address: 0x0008: no mapping at fault address
src/binary_identity_resolver_test.cpp(316): last checkpoint: 
"IdentityEquilityWithoutGuid" entry.
```

I'm not sure I move to the right direction.
I just want to be able to run CPP tests locally.

[1] 
https://github.com/JetBrains/teamcity-cpp/blob/master/boost/teamcity_boost.cpp
[2] 
https://github.com/JetBrains/teamcity-cpp/blob/master/common/teamcity_messages.cpp


В Чт, 19/04/2018 в 14:11 +0300, Nikolay Izhikov пишет:
> Igor.
> 
> Following settings helps to remove some error, but I still can't make all 
> things works.
> Is it right way to get things work?
> 
> ```
> > export LDFLAGS='-L/usr/lib/x86_64-linux-gnu/'
> > export LIBS='-lboost_unit_test_framework'
> > libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> > ./configure --enable-odbc --enable-tests
> > make
> 
> ```
> 
> Now, It seems that compiler can found references to boost functions.
> The only error I see from the output is
> 
> make[3]: вход в каталог 
> «/home/dragon/src/ignite/modules/platforms/cpp/odbc-test»
>   CXXLDignite-odbc-tests
> /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o: In 
> function `_start':
> (.text+0x20): undefined reference to `main'
> collect2: error: ld returned 1 exit status
> 
> I work on Ubuntu linux x64:
> 
> ```
> > uname -a
> 
> Linux host 4.13.0-38-generic #43-Ubuntu SMP Wed Mar 14 15:20:44 UTC 2018 
> x86_64 x86_64 x86_64 GNU/Linux
> ```
> 
> В Чт, 19/04/2018 в 13:40 +0300, Nikolay Izhikov пишет:
> > Hello, Igor.
> > 
> > Still doesn't work.
> > 
> > I removed files you mentioned and got following error messages:
> > 
> > make[3]: вход в каталог 
> > «/home/dragon/src/ignite/modules/platforms/cpp/odbc-test»
> >   CXXLDignite-odbc-tests
> > /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o: In 
> > function `_start':
> > (.text+0x20): undefined reference to `main'
> > src/cursor_test.o: In function 
> > `CheckCursorNeedUpdate(ignite::odbc::Cursor&)':
> > /home/dragon/src/ignite/modules/platforms/cpp/odbc-test/src/cursor_test.cpp:77:
> >  undefined reference to 
> > `boost::unit_test::unit_test_log_t::set_checkpoint(boost::unit_test::basic_cstring >  const>,
> > unsigned long, boost::unit_test::basic_cstring)'
> > 
> > 
> > В Чт, 19/04/2018 в 13:15 +0300, Igor Sapego пишет:
> > > They can be executed locally, and no, you don't need any library.
> > > It is just that Teamcity plugin depends on exact version of Boost,
> > > as I mentioned before. You can disable it if you are going to run
> > > tests locally.
> > > 
> > > For this you should remove from these files
> > > platform/cpp/core-test/Makefile.am and
> > > platform/cpp/odcs-test/Makefile.am
> > > 
> > > following lines:
> > > src/teamcity_messages.cpp \
> > > src/teamcity_boost.cpp \
> > > 
> > > 
> > > Best Regards,
> > > Igor
> > > 
> > > On Wed, Apr 18, 2018 at 6:17 PM, Nikolay Izhikov 
> > > wrote:
> > > 
> > > > 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, 

[GitHub] ignite pull request #3891: Ignite 8347 1

[dspavlov]

GitHub user dspavlov opened a pull request:

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

Ignite 8347 1



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

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

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

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


commit d184bdd5b2fdd5392c8abbc3067839dacd7acfcd
Author: tledkov-gridgain 
Date:   2018-04-19T09:39:52Z

IGNITE-8347: add test to reproduce memory leak

commit bfe3b63ad17d86ea5df4e74dfaebdad1ef126041
Author: dpavlov 
Date:   2018-04-20T16:08:17Z

IGNITE-8347 Memory leak fix for delayed page write




---

Re: Ticket review checklist

[Dmitry Pavlov]

Hi Igniters,

+1 to idea of checklist.

+1 to refactoring and documenting code related to ticket in +/-20 LOC at
least.

If we start to do it as part of our regular contribution, code will be
better, it would became common practice and part of Apache Ignite
development culure.

If we will hope we will have free time to submit separate patch someday and
have patience to complete patch-submission process, code will remain
undocumented and poor-readable.

Sincerely,
Dmitriy Pavlov

пт, 20 апр. 2018 г. в 18:56, Александр Меньшиков :

> 4) Metrics.
> partially +1
>
> It makes sense to have some minimal code coverage for new code in PR. IMHO.
>
> Also, we can limit the cyclomatic complexity of the new code in PR too.
>
> 6) Refactoring
> -1
>
> I understand why people want to refactor old code.
> But I think refactoring should be always a separate task.
> And it's better to remove all refactoring from PR, if it's not the sense of
> the issue.
>
>
> 2018-04-20 16:54 GMT+03:00 Andrey Kuznetsov :
>
> > What about adding the following item to the checklist: when the change
> adds
> > new functionality, then unit tests should also be provided, if it's
> > technically possible?
> >
> > As for refactorings, in fact they are strongly discouraged today for some
> > unclear reason. Let's permit to make refactorings in the checklist being
> > discussed. (Of cource, refactoring should relate to problem being
> solved.)
> >
> > 2018-04-20 16:16 GMT+03:00 Vladimir Ozerov :
> >
> > > Hi Ed,
> > >
> > > Unfortunately some of these points are not good candidates for the
> > > checklist because of these:
> > > - It must be clear and disallow *multiple interpretations*
> > > - It must be *lightweight*, otherwise Ignite development would become a
> > > nightmare
> > >
> > > We cannot have "nice to have" points here. Checklist should answer the
> > > question "is ticket eligible to be merged?"
> > >
> > > >>> 1) Code style.
> > > +1
> > >
> > > >>>  2) Documentation
> > > -1, it is impossible to define what is "well-documented". A piece of
> code
> > > could be obvious for one contributor, and non-obvious for another. In
> any
> > > case this is not a blocker for merge. Instead, during review one can
> ask
> > > implementer to add more docs, but it cannot be forced.
> > >
> > > >>>  3) Logging
> > > -1, same problem - what is "enough logging?". Enough for whom? How to
> > > understand whether it is enough or not?
> > >
> > > >>>  4) Metrics
> > > -1, no clear boundaries, and decision on whether metrics are to be
> added
> > or
> > > not should be performed during design phase. As before, it is perfectly
> > > valid to ask contributor to add metrics with clear explanation why, but
> > > this is not part of the checklist.
> > >
> > > >>> 5) TC status
> > > +1, already mentioned
> > >
> > > >>>  6) Refactoring
> > > Strong -1. OOP is a slippery slope, there are no good and bad receipts
> > for
> > > all cases, hence it cannot be used in a checklist.
> > >
> > > We can borrow useful rules from p.2, p.3 and p.4 if you provide clear
> > > definitions on how to measure them.
> > >
> > > Vladimir.
> > >
> > > On Fri, Apr 20, 2018 at 3:50 PM, Eduard Shangareev <
> > > eduard.shangar...@gmail.com> wrote:
> > >
> > > > Also, I want to add some technical requirement. Let's discuss them.
> > > >
> > > > 1) Code style.
> > > > The code needs to be formatted according to coding guidelines
> > > > <
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > >.
> > > > The
> > > > code must not contain TODOs without a ticket reference.
> > > >
> > > > It is highly recommended to make major formatting changes in existing
> > > code
> > > > as a separate commit, to make review process more practical.
> > > >
> > > > 2) Documentation.
> > > > Added code should be well-documented. Any methods that raise
> questions
> > > > regarding their code flow, invariants, synchronization, etc., must be
> > > > documented with comprehensive javadoc. Any reviewer can request that
> a
> > > > particular added method be documented. Also, it is a good practice to
> > > > document old code in a 10-20 lines region around changed code.
> > > >
> > > > 3) Logging.
> > > > Make sure that there are enough logging added in every category for
> > > > possible diagnostic in field. Check that logging messages are
> properly
> > > > spelled.
> > > >
> > > > 4) Metrics.
> > > > Are there any metrics that need to be exposed to user?
> > > >
> > > > 5) TC status.
> > > >
> > > > Recheck that there are no new failing tests
> > > >
> > > > 6) Refactoring.
> > > >
> > > > The code should be better than before:
> > > >
> > > >- extract method from big one;
> > > >- do anything else to make code clearer (don't forget about some
> > > >OOP-practise, replace if-else hell with inheritance
> > > >- split refactoring (renaming, code format) from actual changes by
> > > >separate commit
> > > >

Re: Ticket review checklist

[Александр Меньшиков]

4) Metrics.
partially +1

It makes sense to have some minimal code coverage for new code in PR. IMHO.

Also, we can limit the cyclomatic complexity of the new code in PR too.

6) Refactoring
-1

I understand why people want to refactor old code.
But I think refactoring should be always a separate task.
And it's better to remove all refactoring from PR, if it's not the sense of
the issue.


2018-04-20 16:54 GMT+03:00 Andrey Kuznetsov :

> What about adding the following item to the checklist: when the change adds
> new functionality, then unit tests should also be provided, if it's
> technically possible?
>
> As for refactorings, in fact they are strongly discouraged today for some
> unclear reason. Let's permit to make refactorings in the checklist being
> discussed. (Of cource, refactoring should relate to problem being solved.)
>
> 2018-04-20 16:16 GMT+03:00 Vladimir Ozerov :
>
> > Hi Ed,
> >
> > Unfortunately some of these points are not good candidates for the
> > checklist because of these:
> > - It must be clear and disallow *multiple interpretations*
> > - It must be *lightweight*, otherwise Ignite development would become a
> > nightmare
> >
> > We cannot have "nice to have" points here. Checklist should answer the
> > question "is ticket eligible to be merged?"
> >
> > >>> 1) Code style.
> > +1
> >
> > >>>  2) Documentation
> > -1, it is impossible to define what is "well-documented". A piece of code
> > could be obvious for one contributor, and non-obvious for another. In any
> > case this is not a blocker for merge. Instead, during review one can ask
> > implementer to add more docs, but it cannot be forced.
> >
> > >>>  3) Logging
> > -1, same problem - what is "enough logging?". Enough for whom? How to
> > understand whether it is enough or not?
> >
> > >>>  4) Metrics
> > -1, no clear boundaries, and decision on whether metrics are to be added
> or
> > not should be performed during design phase. As before, it is perfectly
> > valid to ask contributor to add metrics with clear explanation why, but
> > this is not part of the checklist.
> >
> > >>> 5) TC status
> > +1, already mentioned
> >
> > >>>  6) Refactoring
> > Strong -1. OOP is a slippery slope, there are no good and bad receipts
> for
> > all cases, hence it cannot be used in a checklist.
> >
> > We can borrow useful rules from p.2, p.3 and p.4 if you provide clear
> > definitions on how to measure them.
> >
> > Vladimir.
> >
> > On Fri, Apr 20, 2018 at 3:50 PM, Eduard Shangareev <
> > eduard.shangar...@gmail.com> wrote:
> >
> > > Also, I want to add some technical requirement. Let's discuss them.
> > >
> > > 1) Code style.
> > > The code needs to be formatted according to coding guidelines
> > >  >.
> > > The
> > > code must not contain TODOs without a ticket reference.
> > >
> > > It is highly recommended to make major formatting changes in existing
> > code
> > > as a separate commit, to make review process more practical.
> > >
> > > 2) Documentation.
> > > Added code should be well-documented. Any methods that raise questions
> > > regarding their code flow, invariants, synchronization, etc., must be
> > > documented with comprehensive javadoc. Any reviewer can request that a
> > > particular added method be documented. Also, it is a good practice to
> > > document old code in a 10-20 lines region around changed code.
> > >
> > > 3) Logging.
> > > Make sure that there are enough logging added in every category for
> > > possible diagnostic in field. Check that logging messages are properly
> > > spelled.
> > >
> > > 4) Metrics.
> > > Are there any metrics that need to be exposed to user?
> > >
> > > 5) TC status.
> > >
> > > Recheck that there are no new failing tests
> > >
> > > 6) Refactoring.
> > >
> > > The code should be better than before:
> > >
> > >- extract method from big one;
> > >- do anything else to make code clearer (don't forget about some
> > >OOP-practise, replace if-else hell with inheritance
> > >- split refactoring (renaming, code format) from actual changes by
> > >separate commit
> > >
> > >
> > >
> > >
> > > On Fri, Apr 20, 2018 at 3:23 PM, Eduard Shangareev <
> > > eduard.shangar...@gmail.com> wrote:
> > >
> > > > Hi, guys.
> > > >
> > > > I believe that we should update maintainers list before adding this
> > > review
> > > > requirement.
> > > > There should not be the situation when there is only one contributor
> > who
> > > > is responsible for a component.
> > > > We already have issues with review speed and response time.
> > > >
> > > > On Fri, Apr 20, 2018 at 2:17 PM, Anton Vinogradov 
> > wrote:
> > > >
> > > >> Vova,
> > > >>
> > > >> Everything you described sound good to me.
> > > >>
> > > >> I'd like to propose to create special page at AI Wiki and to
> describe
> > > >> checklist.
> > > >> In case we'll find something should be 

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

[dmekhanikov]

Github user dmekhanikov closed the pull request at:

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


---

[GitHub] ignite pull request #3808: ignite-8205 make services be redeployed when clus...

[dmekhanikov]

Github user dmekhanikov closed the pull request at:

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


---

[GitHub] ignite pull request #3890: IGNITE-8323 : Fixed discoveryEvent listener calls...

[ilantukh]

GitHub user ilantukh opened a pull request:

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

IGNITE-8323 : Fixed discoveryEvent listener calls.



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

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

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

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


commit 02dc5a35da7c4d5bb27b2516a38ceb4037f5a0c8
Author: Ilya Lantukh 
Date:   2018-04-20T15:00:53Z

ignite-8323 : Fixed discoveryEvent listener calls.




---

[jira] [Created] (IGNITE-8348) Debug information about discovery messages in TcpDiscoverySpiMBean

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-8348:
-

 Summary: Debug information about discovery messages in 
TcpDiscoverySpiMBean
 Key: IGNITE-8348
 URL: https://issues.apache.org/jira/browse/IGNITE-8348
 Project: Ignite
  Issue Type: Bug
Reporter: Vladislav Pyatkov


In some discovery issue, like:
1) Behavior on instable network
2) Segmentation of several nodes
or others, when the SPI works does not obviously.
Wants to know - what kind of messages has been sent (receive) from particular 
node?

By that reason want to add method on TcpDiscoverySpiMBean:

{code}
/**
 * Print a list of discarder messages.
 */
@MXBeanDescription("Print a list of discarded messages to log.")
public void printListOfDiscardedMessages();

/**
 * Print a list of received messages.
 */
@MXBeanDescription("Print a list of received messages to log.")
public void printListOfReceivedMessages();

/**
 * Print a list of sent messages.
 */
@MXBeanDescription("Print a list of sent messages to log.")
public void printListOfSentMessages();
{code}




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

[GitHub] ignite pull request #3889: IGNITE-8347 Memory leaks on restart Ignite node w...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-8347  Memory leaks on restart Ignite node with enabled persistence 
at ThreadLocal



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

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

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

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


commit d184bdd5b2fdd5392c8abbc3067839dacd7acfcd
Author: tledkov-gridgain 
Date:   2018-04-19T09:39:52Z

IGNITE-8347: add test to reproduce memory leak




---

[jira] [Created] (IGNITE-8347) Memory leaks on restart Ignite node with enabled persistence at ThreadLocal

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-8347:


 Summary: Memory leaks on restart Ignite node with enabled 
persistence at ThreadLocal
 Key: IGNITE-8347
 URL: https://issues.apache.org/jira/browse/IGNITE-8347
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 2.4
Reporter: Taras Ledkov
Assignee: Dmitriy Pavlov


Memory leaks on restart Ignite node with enabled persistence at ThreadLocal.



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

[GitHub] ignite pull request #3888: IGNITE-8346 Add FileDownloaderTest to PDS 2 suit

[DmitriyGovorukhin]

GitHub user DmitriyGovorukhin opened a pull request:

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

IGNITE-8346 Add FileDownloaderTest to PDS 2 suit

… + small refactoring.

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

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

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

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


commit 80d5c4e51f013d0edac0c8a8f4506f762d6926b4
Author: Dmitriy Govorukhin 
Date:   2018-04-20T14:14:37Z

IGNITE-8346 Add FileDownloaderTest to PDS 2 suit. Uncomment test body + 
small refactoring.




---

[jira] [Created] (IGNITE-8346) FileDownloaderTest is not included in the test suite

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-8346:
--

 Summary: FileDownloaderTest is not included in the test suite
 Key: IGNITE-8346
 URL: https://issues.apache.org/jira/browse/IGNITE-8346
 Project: Ignite
  Issue Type: Test
Reporter: Dmitriy Govorukhin


org.apache.ignite.internal.processors.cache.persistence.file.FileDownloaderTest 



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

Re: Ticket review checklist

[Andrey Kuznetsov]

What about adding the following item to the checklist: when the change adds
new functionality, then unit tests should also be provided, if it's
technically possible?

As for refactorings, in fact they are strongly discouraged today for some
unclear reason. Let's permit to make refactorings in the checklist being
discussed. (Of cource, refactoring should relate to problem being solved.)

2018-04-20 16:16 GMT+03:00 Vladimir Ozerov :

> Hi Ed,
>
> Unfortunately some of these points are not good candidates for the
> checklist because of these:
> - It must be clear and disallow *multiple interpretations*
> - It must be *lightweight*, otherwise Ignite development would become a
> nightmare
>
> We cannot have "nice to have" points here. Checklist should answer the
> question "is ticket eligible to be merged?"
>
> >>> 1) Code style.
> +1
>
> >>>  2) Documentation
> -1, it is impossible to define what is "well-documented". A piece of code
> could be obvious for one contributor, and non-obvious for another. In any
> case this is not a blocker for merge. Instead, during review one can ask
> implementer to add more docs, but it cannot be forced.
>
> >>>  3) Logging
> -1, same problem - what is "enough logging?". Enough for whom? How to
> understand whether it is enough or not?
>
> >>>  4) Metrics
> -1, no clear boundaries, and decision on whether metrics are to be added or
> not should be performed during design phase. As before, it is perfectly
> valid to ask contributor to add metrics with clear explanation why, but
> this is not part of the checklist.
>
> >>> 5) TC status
> +1, already mentioned
>
> >>>  6) Refactoring
> Strong -1. OOP is a slippery slope, there are no good and bad receipts for
> all cases, hence it cannot be used in a checklist.
>
> We can borrow useful rules from p.2, p.3 and p.4 if you provide clear
> definitions on how to measure them.
>
> Vladimir.
>
> On Fri, Apr 20, 2018 at 3:50 PM, Eduard Shangareev <
> eduard.shangar...@gmail.com> wrote:
>
> > Also, I want to add some technical requirement. Let's discuss them.
> >
> > 1) Code style.
> > The code needs to be formatted according to coding guidelines
> > .
> > The
> > code must not contain TODOs without a ticket reference.
> >
> > It is highly recommended to make major formatting changes in existing
> code
> > as a separate commit, to make review process more practical.
> >
> > 2) Documentation.
> > Added code should be well-documented. Any methods that raise questions
> > regarding their code flow, invariants, synchronization, etc., must be
> > documented with comprehensive javadoc. Any reviewer can request that a
> > particular added method be documented. Also, it is a good practice to
> > document old code in a 10-20 lines region around changed code.
> >
> > 3) Logging.
> > Make sure that there are enough logging added in every category for
> > possible diagnostic in field. Check that logging messages are properly
> > spelled.
> >
> > 4) Metrics.
> > Are there any metrics that need to be exposed to user?
> >
> > 5) TC status.
> >
> > Recheck that there are no new failing tests
> >
> > 6) Refactoring.
> >
> > The code should be better than before:
> >
> >- extract method from big one;
> >- do anything else to make code clearer (don't forget about some
> >OOP-practise, replace if-else hell with inheritance
> >- split refactoring (renaming, code format) from actual changes by
> >separate commit
> >
> >
> >
> >
> > On Fri, Apr 20, 2018 at 3:23 PM, Eduard Shangareev <
> > eduard.shangar...@gmail.com> wrote:
> >
> > > Hi, guys.
> > >
> > > I believe that we should update maintainers list before adding this
> > review
> > > requirement.
> > > There should not be the situation when there is only one contributor
> who
> > > is responsible for a component.
> > > We already have issues with review speed and response time.
> > >
> > > On Fri, Apr 20, 2018 at 2:17 PM, Anton Vinogradov 
> wrote:
> > >
> > >> Vova,
> > >>
> > >> Everything you described sound good to me.
> > >>
> > >> I'd like to propose to create special page at AI Wiki and to describe
> > >> checklist.
> > >> In case we'll find something should be changed/improved it will be
> easy
> > to
> > >> update the page.
> > >>
> > >> 2018-04-20 0:53 GMT+03:00 Nikolay Izhikov :
> > >>
> > >> > Hello, Vladimir.
> > >> >
> > >> > Thank you for seting up this discussion.
> > >> >
> > >> > As we discussed, I think an important part of this check list is
> > >> > compatibility rules.
> > >> >
> > >> > * What should be backward compatible?
> > >> > * How should we maintain it?
> > >> >
> > >> > > 3) If ticket changes public API or existing behavior, at least two
> > >> > commiters should approve the changes
> > >> >
> > >> > We can learn from other open source project experience.
> > >> > Apache Kafka [1], for example, requires KIP(kafka improvement
> 

[jira] [Created] (IGNITE-8345) Streamline tests' class names: mark Abstract and Load tests obviously so

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-8345:
---

 Summary: Streamline tests' class names: mark Abstract and Load 
tests obviously so
 Key: IGNITE-8345
 URL: https://issues.apache.org/jira/browse/IGNITE-8345
 Project: Ignite
  Issue Type: Bug
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev


To make support of our huge tests base easier, I propose we rename all abstract 
tests to *AbstractTest (this is already done almost always). Exceptions are 
tests whose inner classes are concrete tests.

Also, tests which are designed for stress-test and not included to regular test 
suites should be called *LoadTest or *PerformanceTest.



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

[jira] [Created] (IGNITE-8344) Remove duplicate tests and suites

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-8344:
---

 Summary: Remove duplicate tests and suites
 Key: IGNITE-8344
 URL: https://issues.apache.org/jira/browse/IGNITE-8344
 Project: Ignite
  Issue Type: Bug
  Components: general
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev


There are several tests which present in the code base as two distinct files 
with near-similar content. We should only keep one.



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

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

[Ilya Kasnacheev]

What's up with the following files:

GridActivationAtomicCacheSuit
GridActivationCacheAbstractTestSuit
GridActivationLocalAndNearCacheSuit
GridActivationPartitionedCacheSuit
GridActivationReplicatedCacheSuit

May I remove them?


-- 
Ilya Kasnacheev

2018-04-19 16:41 GMT+03:00 Ilya Kasnacheev :

> Hello!
>
> I have also noticed that we seem to miss a Cassandra test suite.
>
> We have a Cassandra module with quite a few tests, but they're not in any
> suite.
>
> Maybe we should set one up?
>
> --
> Ilya Kasnacheev
>
> 2018-04-18 16:42 GMT+03:00 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 

[GitHub] ignite pull request #3879: IGNITE-8077 implemented getTxHoldingLockNum and g...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Ticket review checklist

[Vladimir Ozerov]

Hi Ed,

Unfortunately some of these points are not good candidates for the
checklist because of these:
- It must be clear and disallow *multiple interpretations*
- It must be *lightweight*, otherwise Ignite development would become a
nightmare

We cannot have "nice to have" points here. Checklist should answer the
question "is ticket eligible to be merged?"

>>> 1) Code style.
+1

>>>  2) Documentation
-1, it is impossible to define what is "well-documented". A piece of code
could be obvious for one contributor, and non-obvious for another. In any
case this is not a blocker for merge. Instead, during review one can ask
implementer to add more docs, but it cannot be forced.

>>>  3) Logging
-1, same problem - what is "enough logging?". Enough for whom? How to
understand whether it is enough or not?

>>>  4) Metrics
-1, no clear boundaries, and decision on whether metrics are to be added or
not should be performed during design phase. As before, it is perfectly
valid to ask contributor to add metrics with clear explanation why, but
this is not part of the checklist.

>>> 5) TC status
+1, already mentioned

>>>  6) Refactoring
Strong -1. OOP is a slippery slope, there are no good and bad receipts for
all cases, hence it cannot be used in a checklist.

We can borrow useful rules from p.2, p.3 and p.4 if you provide clear
definitions on how to measure them.

Vladimir.

On Fri, Apr 20, 2018 at 3:50 PM, Eduard Shangareev <
eduard.shangar...@gmail.com> wrote:

> Also, I want to add some technical requirement. Let's discuss them.
>
> 1) Code style.
> The code needs to be formatted according to coding guidelines
> .
> The
> code must not contain TODOs without a ticket reference.
>
> It is highly recommended to make major formatting changes in existing code
> as a separate commit, to make review process more practical.
>
> 2) Documentation.
> Added code should be well-documented. Any methods that raise questions
> regarding their code flow, invariants, synchronization, etc., must be
> documented with comprehensive javadoc. Any reviewer can request that a
> particular added method be documented. Also, it is a good practice to
> document old code in a 10-20 lines region around changed code.
>
> 3) Logging.
> Make sure that there are enough logging added in every category for
> possible diagnostic in field. Check that logging messages are properly
> spelled.
>
> 4) Metrics.
> Are there any metrics that need to be exposed to user?
>
> 5) TC status.
>
> Recheck that there are no new failing tests
>
> 6) Refactoring.
>
> The code should be better than before:
>
>- extract method from big one;
>- do anything else to make code clearer (don't forget about some
>OOP-practise, replace if-else hell with inheritance
>- split refactoring (renaming, code format) from actual changes by
>separate commit
>
>
>
>
> On Fri, Apr 20, 2018 at 3:23 PM, Eduard Shangareev <
> eduard.shangar...@gmail.com> wrote:
>
> > Hi, guys.
> >
> > I believe that we should update maintainers list before adding this
> review
> > requirement.
> > There should not be the situation when there is only one contributor who
> > is responsible for a component.
> > We already have issues with review speed and response time.
> >
> > On Fri, Apr 20, 2018 at 2:17 PM, Anton Vinogradov  wrote:
> >
> >> Vova,
> >>
> >> Everything you described sound good to me.
> >>
> >> I'd like to propose to create special page at AI Wiki and to describe
> >> checklist.
> >> In case we'll find something should be changed/improved it will be easy
> to
> >> update the page.
> >>
> >> 2018-04-20 0:53 GMT+03:00 Nikolay Izhikov :
> >>
> >> > Hello, Vladimir.
> >> >
> >> > Thank you for seting up this discussion.
> >> >
> >> > As we discussed, I think an important part of this check list is
> >> > compatibility rules.
> >> >
> >> > * What should be backward compatible?
> >> > * How should we maintain it?
> >> >
> >> > > 3) If ticket changes public API or existing behavior, at least two
> >> > commiters should approve the changes
> >> >
> >> > We can learn from other open source project experience.
> >> > Apache Kafka [1], for example, requires KIP(kafka improvement
> proposal)
> >> > for *every* major change.
> >> > Major change definition includes public API.
> >> >
> >> > [1] https://cwiki.apache.org/confluence/display/KAFKA/
> >> > Kafka+Improvement+Proposals
> >> >
> >> >
> >> > В Чт, 19/04/2018 в 23:00 +0300, Vladimir Ozerov пишет:
> >> > > Hi Igniters,
> >> > >
> >> > > It's glad to see our community becomes larger every day. But as it
> >> grows
> >> > it
> >> > > becomes more and more difficult to manage review and merge processes
> >> and
> >> > > keep quality of our decisions at the proper level. More
> contributors,
> >> > more
> >> > > commits, more components interlinked with each other in subtle ways.
> >> > >
> >> > > I would like to propose to setup 

[GitHub] ignite pull request #3887: Ignite 1.8.19.b1

[slukyano]

GitHub user slukyano opened a pull request:

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

Ignite 1.8.19.b1



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

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

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

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


commit 7fbaecc67f1b204162bda4595d6c118ddd45f963
Author: Andrey V. Mashenkov 
Date:   2017-06-16T17:01:49Z

IGNITE-5527: Prevent starvation in stripe pool on unstable topology.

commit f81964f59b0ea5b8dfdc8eb2acc34d2a5b8fee07
Author: sboikov 
Date:   2017-01-10T13:59:17Z

Do not evict removed entries, otherwise removes can be lost.

(cherry picked from commit 55ac6e7)

commit 5dd74ff635de50ff9561ccdb51bdeb620f60c3db
Author: sboikov 
Date:   2017-01-10T13:59:17Z

Do not evict removed entries, otherwise removes can be lost.

(cherry picked from commit 55ac6e7)

commit 5fb5c7e3b54ae4efb7a6a1832ba647677d93e0cd
Author: Evgenii Zhuravlev 
Date:   2017-06-22T06:43:03Z

IGNITE-5399 Manual cache rebalancing feature is broken

commit 01d41b72ecc3e81dfc8966cc0e395c247037241c
Author: Evgenii Zhuravlev 
Date:   2017-06-21T10:48:15Z

GG-12256 H2Indexes are not deleted if key class implements Externalizable

commit 5ac9afc719138e37a7d97d9d9db05243eee9a942
Author: Evgenii Zhuravlev 
Date:   2017-06-22T09:36:14Z

IGNITE-5399 add test to testsuite

commit a935d40a80e2f928a84a145aba540a45b156687f
Author: Evgenii Zhuravlev 
Date:   2017-06-22T12:10:32Z

GG-12256 Minor fixes

commit 7e2468770a4eb47a4f61204d8c2000b6ab67c967
Author: nikolay_tikhonov 
Date:   2017-06-22T13:13:01Z

IGNITE-GG-12197 Fixed "Ignore events for discarded update in CLOCK mode".

Signed-off-by: nikolay_tikhonov 

commit 5858efd406bb54352de14a0a7e7f21c2ac7bf899
Author: sboikov 
Date:   2016-12-16T16:23:29Z

IGNITE-2412 - Do not acquire asyncSemaphore for synchronous operations 
(cherry-picked from master)

(cherry picked from commit 82b4073)

commit 113a1380da34ea804d68757d39926da97dee09b6
Author: Alexey Goncharuk 
Date:   2017-06-13T05:20:22Z

GG-12355: Backported IO latency test.

commit 540ca449f1bd2386d3ba0722afb21dd3a504d044
Author: Alexey Goncharuk 
Date:   2017-06-13T17:55:38Z

GG-12355: Added discovery ring latency test + made it available from MBean 
(cherry-picked from master).

commit 0fc6271d8e39125bf5ee341e50a2665a04fc8b1e
Author: Andrey V. Mashenkov 
Date:   2017-06-21T10:42:12Z

GG-12350: GridDhtAtomicSingleUpdateRequest misses topologyVersion() method 
override.

commit f8224d13cf9a6432ba65e0016370ba51bbb544e9
Author: Alexey Goncharuk 
Date:   2017-06-15T19:49:45Z

GG-12299: Make sure concurrent type registrations do not trigger multiple 
cache updates.

commit 4ffc3acfa1bc43bea8c79bfd1864787c15cfc4de
Author: Alexey Goncharuk 
Date:   2017-06-20T04:59:09Z

IGNITE-5528 - IS_EVICT_DISABLED flag is not cleared on cache store 
exception.

commit 8cd9e829380f4c91cc9bb126169863286d1cb323
Author: Andrey V. Mashenkov 
Date:   2017-06-21T12:40:14Z

GG-12353: Added local binary context flag.

Backport of IGNITE-5223 with fixes.

commit 9036ad239d68eff663bc73a81baab2826b054d9a
Author: Andrey V. Mashenkov 
Date:   2017-06-21T15:25:31Z

Added MBean for system cache executors.

commit ed34a5dc681ea8f284f4d25c5575ad46569cc600
Author: Andrey V. Mashenkov 
Date:   2017-06-21T15:33:55Z

Partial fix of IGNITE-5562.

commit d427021f329292fb69d348ba949ad1f8f1e9089e
Author: Andrey V. Mashenkov 
Date:   2017-06-21T16:30:27Z

IGNITE-5552: ServiceProcessor recalculates all service assignments even if 
there is a pending topology change.

commit f1b9cdc0716a1b23f54d68ce0fe19eb85107567d
Author: Alexey Goncharuk 
Date:   2017-06-14T18:37:54Z

GG-12354: Partial fix of IGNITE-5473: Introduce troubleshooting logger.

commit beb2409cfe2045789443d47de735d879961d371e
Author: Andrey V. Mashenkov 
Date:   2017-06-23T09:26:06Z

GG-12352: Forcible node drop makes cluster instable in some cases.
Disable forcible node drop by default.

commit 802f18fc250cbae8959192c78bb28dc525ed3cf7
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Fix compilation

commit 39d2dec85a3c571dfdb1cd6189b53ae2413a5d22
Author: Andrey V. Mashenkov 
Date:   2017-06-23T10:41:30Z

Merge branch 

[GitHub] ignite pull request #3845: IGNITE-8078 New metrics for data store

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3886: IGNITE-7910 Improve transaction debugging support

[ascherbakoff]

GitHub user ascherbakoff opened a pull request:

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

IGNITE-7910 Improve transaction debugging support



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

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

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

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


commit 99a05f50be24a6dbebe6e9a3cd57513a1dbeb4fb
Author: Aleksei Scherbakov 
Date:   2017-12-06T11:26:44Z

IGNITE-6827 wip.

commit 1e7ee0f0fd10e21b36cc57e1499358dd46c616b7
Author: Aleksei Scherbakov 
Date:   2017-12-06T14:34:25Z

IGNITE-6827 wip.

commit 0b0c0ff5f736b6cb299bf8ee32d6705d3c2adfb2
Author: Aleksei Scherbakov 
Date:   2017-12-06T14:47:13Z

IGNITE-6827 wip.

commit 2e7e7a2eca9b45ca1488403d86c28df055d215a7
Author: Aleksei Scherbakov 
Date:   2017-12-06T15:01:37Z

IGNITE-6827 wip.

commit 50dbdb8f14751f470f605884f195256531f4176f
Author: Aleksei Scherbakov 
Date:   2017-12-06T15:04:40Z

IGNITE-6827 wip.

commit 4da15f51af7302dc70fa5ee705042dec36cb120b
Author: Aleksei Scherbakov 
Date:   2017-12-06T16:46:22Z

IGNITE-6827 wip.

commit bc024837e12627a011c8a1b43f30783bb3b08f2d
Author: Aleksei Scherbakov 
Date:   2017-12-06T17:11:04Z

IGNITE-6827 wip.

commit 8f5693361b018ee78ca7b6fd9a9e4d88017a87ea
Author: ascherbakoff 
Date:   2017-12-06T21:05:42Z

IGNITE-6827 wip.

commit c4b9fab158769fb21e7dbbb641746868698a6652
Author: Aleksei Scherbakov 
Date:   2017-12-07T11:23:25Z

IGNITE-6827 wip.

commit f0a6113798df0e20e2d3b4a5573a5c722a2fd948
Author: Aleksei Scherbakov 
Date:   2017-12-07T11:27:16Z

IGNITE-6827 wip.

commit 5d9d22c7cb27c39516d0340ab72fa0a4f56e004b
Author: Aleksei Scherbakov 
Date:   2017-12-07T11:46:21Z

IGNITE-6827 wip.

commit a008c220923d95155285b3408945f6e2c94104e5
Author: Aleksei Scherbakov 
Date:   2017-12-07T13:47:40Z

IGNITE-6827 wip.

commit f0ba7bd90ab16f0933353901fd73586e998443ba
Author: Aleksei Scherbakov 
Date:   2017-12-07T14:05:14Z

IGNITE-6827 wip.

commit 7c6542553f041339f712bbde1541aa54c9418ed9
Author: Aleksei Scherbakov 
Date:   2017-12-07T17:10:24Z

IGNITE-6827 wip.

commit 91545f3bc98fc6c58d42d87fc0edd70abcb398d6
Author: Aleksei Scherbakov 
Date:   2017-12-07T17:21:46Z

IGNITE-6827 wip.

commit 663889d8c242c2681524cd11878838fb8b2f11ab
Author: Aleksei Scherbakov 
Date:   2017-12-08T10:28:49Z

IGNITE-6827 wip.

commit 7da5e9582a995c39d0fa9cc6aa7e42d44eaf2d3f
Author: Aleksei Scherbakov 
Date:   2017-12-08T16:22:23Z

IGNITE-6827 wip.

commit 65023a5b4983b871e0a8522e1493c285ab75b07d
Author: Aleksei Scherbakov 
Date:   2017-12-08T16:28:21Z

IGNITE-6827 wip.

commit 5951ff5e2a72293577392aea84582f8831c37163
Author: Aleksei Scherbakov 
Date:   2017-12-08T16:52:50Z

IGNITE-6827 wip.

commit 35aeeb2bf0f671569979e1782832a1371c479791
Author: Aleksei Scherbakov 
Date:   2017-12-08T17:19:12Z

IGNITE-6827 wip.

commit fb9779e12ecaa27a1a00a2eac97747f2e7175c32
Author: ascherbakoff 
Date:   2017-12-09T13:31:29Z

IGNITE-6827 wip.

commit 327eb805aad6f2608e6af8032a9a5e7c67c47c20
Author: ascherbakoff 
Date:   2017-12-09T13:32:03Z

IGNITE-6827 wip.

commit 00f9b695d46886c89087b0061701a42429abb05e
Author: ascherbakoff 
Date:   2017-12-09T14:06:07Z

IGNITE-6827 wip.

commit 5cd8fa0a34c34529cde58f859a6fd82955c3d57c
Author: ascherbakoff 
Date:   2017-12-09T14:29:38Z

IGNITE-6827 wip.

commit 27f38f24992e2eb2d1418e503a3cd39b581dd2e0
Author: ascherbakoff 
Date:   2017-12-09T14:54:04Z

IGNITE-6827 wip.

commit 9d47569d4a28125fefb4781c70855ca14a2c1c6c
Author: ascherbakoff 
Date:   2017-12-09T15:09:04Z

IGNITE-6827 wip.

commit 50a545a01cb1d7a3c015196dd4384d77010fdee3
Author: ascherbakoff 
Date:   2017-12-09T15:25:07Z

IGNITE-6827 wip.

commit 0b90e453bd6036528ccf6723340220dc4acde4be
Author: ascherbakoff 
Date:   2017-12-10T13:16:31Z

IGNITE-6827 wip.

commit b1e0900110c4b4d815f238289c0bb0777591d953
Author: ascherbakoff 
Date:   2017-12-10T16:30:12Z

IGNITE-6827 wip.

commit 3fdfb2698acf526b5db8e5697ec263d8da219145
Author: ascherbakoff 

Re: Ticket review checklist

[Eduard Shangareev]

Also, I want to add some technical requirement. Let's discuss them.

1) Code style.
The code needs to be formatted according to coding guidelines
. The
code must not contain TODOs without a ticket reference.

It is highly recommended to make major formatting changes in existing code
as a separate commit, to make review process more practical.

2) Documentation.
Added code should be well-documented. Any methods that raise questions
regarding their code flow, invariants, synchronization, etc., must be
documented with comprehensive javadoc. Any reviewer can request that a
particular added method be documented. Also, it is a good practice to
document old code in a 10-20 lines region around changed code.

3) Logging.
Make sure that there are enough logging added in every category for
possible diagnostic in field. Check that logging messages are properly
spelled.

4) Metrics.
Are there any metrics that need to be exposed to user?

5) TC status.

Recheck that there are no new failing tests

6) Refactoring.

The code should be better than before:

   - extract method from big one;
   - do anything else to make code clearer (don't forget about some
   OOP-practise, replace if-else hell with inheritance
   - split refactoring (renaming, code format) from actual changes by
   separate commit




On Fri, Apr 20, 2018 at 3:23 PM, Eduard Shangareev <
eduard.shangar...@gmail.com> wrote:

> Hi, guys.
>
> I believe that we should update maintainers list before adding this review
> requirement.
> There should not be the situation when there is only one contributor who
> is responsible for a component.
> We already have issues with review speed and response time.
>
> On Fri, Apr 20, 2018 at 2:17 PM, Anton Vinogradov  wrote:
>
>> Vova,
>>
>> Everything you described sound good to me.
>>
>> I'd like to propose to create special page at AI Wiki and to describe
>> checklist.
>> In case we'll find something should be changed/improved it will be easy to
>> update the page.
>>
>> 2018-04-20 0:53 GMT+03:00 Nikolay Izhikov :
>>
>> > Hello, Vladimir.
>> >
>> > Thank you for seting up this discussion.
>> >
>> > As we discussed, I think an important part of this check list is
>> > compatibility rules.
>> >
>> > * What should be backward compatible?
>> > * How should we maintain it?
>> >
>> > > 3) If ticket changes public API or existing behavior, at least two
>> > commiters should approve the changes
>> >
>> > We can learn from other open source project experience.
>> > Apache Kafka [1], for example, requires KIP(kafka improvement proposal)
>> > for *every* major change.
>> > Major change definition includes public API.
>> >
>> > [1] https://cwiki.apache.org/confluence/display/KAFKA/
>> > Kafka+Improvement+Proposals
>> >
>> >
>> > В Чт, 19/04/2018 в 23:00 +0300, Vladimir Ozerov пишет:
>> > > Hi Igniters,
>> > >
>> > > It's glad to see our community becomes larger every day. But as it
>> grows
>> > it
>> > > becomes more and more difficult to manage review and merge processes
>> and
>> > > keep quality of our decisions at the proper level. More contributors,
>> > more
>> > > commits, more components interlinked with each other in subtle ways.
>> > >
>> > > I would like to propose to setup a formal review checklist. This would
>> > be a
>> > > set of actions every reviewer needs to check before approving merge
>> of a
>> > > certain feature. Passing the checklist would be *necessary but not
>> > > sufficient* phase before commit could be added to the main branch. The
>> > > checklist would help us to detect a lot of common problems such a
>> broken
>> > > tests or bad UX earlier, and would help contributors lead their pull
>> > > requests to merge.
>> > >
>> > > Hallmarks of a good checklist:
>> > > - It must be followed be everyone without exceptions
>> > > - It must be clear and disallow multiple interpretations
>> > > - It must be lightweight, otherwise Ignite development would become a
>> > > nightmare
>> > > - It must be non-blocking, i.e. inacessibility of a single contributor
>> > > should not block ticket progress forever.
>> > >
>> > > Please let me know if you think the idea makes sense. If we agree on
>> it,
>> > > let's start defining action items for the checklist. My 2 cents:
>> > > 1) All unit tests pass on TC without new failures
>> > > 2) If ticket targets specific component, it should be reviewed by
>> > > component's maintainer*
>> > > 3) If ticket changes public API or existing behavior, at least two
>> > > commiters should approve the changes **
>> > >
>> > > Thoughts?
>> > >
>> > > Vladimir.
>> > >
>> > > * TBD: Review component list and define maintainers; define what to
>> do if
>> > > maintainer is unavailable
>> > > ** TBD: Define what is "public API"
>> >
>>
>
>

[jira] [Created] (IGNITE-8343) InetSocketAddress.getAddress() returns null, should check it in TcpCommunicationSpi

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-8343:
---

 Summary: InetSocketAddress.getAddress() returns null, should check 
it in TcpCommunicationSpi
 Key: IGNITE-8343
 URL: https://issues.apache.org/jira/browse/IGNITE-8343
 Project: Ignite
  Issue Type: Bug
  Components: general
Reporter: Ilya Kasnacheev


This is especially notorious in the following scenario:
{code}
// -Djava.net.preferIPv4Stack=true
System.err.println(new InetSocketAddress("0:0:0:0:0:0:0:1%lo", 
12345).getAddress()); // null
{code}

Yes we already warn if different nodes have differing preferIPv4Stack, still 
this is warning not a error, and there may be other cases where getAddress() 
returns null. Should make a check.





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

[GitHub] ignite pull request #3821: IGNITE-8258 Fixed page acquire/write unlock order...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Ticket review checklist

[Eduard Shangareev]

Hi, guys.

I believe that we should update maintainers list before adding this review
requirement.
There should not be the situation when there is only one contributor who is
responsible for a component.
We already have issues with review speed and response time.

On Fri, Apr 20, 2018 at 2:17 PM, Anton Vinogradov  wrote:

> Vova,
>
> Everything you described sound good to me.
>
> I'd like to propose to create special page at AI Wiki and to describe
> checklist.
> In case we'll find something should be changed/improved it will be easy to
> update the page.
>
> 2018-04-20 0:53 GMT+03:00 Nikolay Izhikov :
>
> > Hello, Vladimir.
> >
> > Thank you for seting up this discussion.
> >
> > As we discussed, I think an important part of this check list is
> > compatibility rules.
> >
> > * What should be backward compatible?
> > * How should we maintain it?
> >
> > > 3) If ticket changes public API or existing behavior, at least two
> > commiters should approve the changes
> >
> > We can learn from other open source project experience.
> > Apache Kafka [1], for example, requires KIP(kafka improvement proposal)
> > for *every* major change.
> > Major change definition includes public API.
> >
> > [1] https://cwiki.apache.org/confluence/display/KAFKA/
> > Kafka+Improvement+Proposals
> >
> >
> > В Чт, 19/04/2018 в 23:00 +0300, Vladimir Ozerov пишет:
> > > Hi Igniters,
> > >
> > > It's glad to see our community becomes larger every day. But as it
> grows
> > it
> > > becomes more and more difficult to manage review and merge processes
> and
> > > keep quality of our decisions at the proper level. More contributors,
> > more
> > > commits, more components interlinked with each other in subtle ways.
> > >
> > > I would like to propose to setup a formal review checklist. This would
> > be a
> > > set of actions every reviewer needs to check before approving merge of
> a
> > > certain feature. Passing the checklist would be *necessary but not
> > > sufficient* phase before commit could be added to the main branch. The
> > > checklist would help us to detect a lot of common problems such a
> broken
> > > tests or bad UX earlier, and would help contributors lead their pull
> > > requests to merge.
> > >
> > > Hallmarks of a good checklist:
> > > - It must be followed be everyone without exceptions
> > > - It must be clear and disallow multiple interpretations
> > > - It must be lightweight, otherwise Ignite development would become a
> > > nightmare
> > > - It must be non-blocking, i.e. inacessibility of a single contributor
> > > should not block ticket progress forever.
> > >
> > > Please let me know if you think the idea makes sense. If we agree on
> it,
> > > let's start defining action items for the checklist. My 2 cents:
> > > 1) All unit tests pass on TC without new failures
> > > 2) If ticket targets specific component, it should be reviewed by
> > > component's maintainer*
> > > 3) If ticket changes public API or existing behavior, at least two
> > > commiters should approve the changes **
> > >
> > > Thoughts?
> > >
> > > Vladimir.
> > >
> > > * TBD: Review component list and define maintainers; define what to do
> if
> > > maintainer is unavailable
> > > ** TBD: Define what is "public API"
> >
>

Re: Topology-wide notification on critical errors

[Yakov Zhdanov]

Of course, no guarantees, but at least an effort.

--Yakov

[jira] [Created] (IGNITE-8342) Semi colon in CREATE INDEX causes infinite loop execution

[Pavel Kuznetsov (JIRA)]

Pavel Kuznetsov created IGNITE-8342:
---

 Summary: Semi colon in CREATE INDEX causes infinite loop execution
 Key: IGNITE-8342
 URL: https://issues.apache.org/jira/browse/IGNITE-8342
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Pavel Kuznetsov


Given created table in cache
{noformat}
cache.query(new SqlFieldsQuery("CREATE INDEX AgeIndex ON Employee 
(age);")).getAll();
{noformat}

seems to cause infinite loop

jstack :
{noformat}
"main" #1 prio=5 os_prio=0 tid=0x7fa1a800d000 nid=0x4b7c runnable 
[0x7fa1b1932000]
   java.lang.Thread.State: RUNNABLE
at org.apache.ignite.internal.sql.SqlLexer.lookAhead(SqlLexer.java:73)
at 
org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parseIndexProperties(SqlCreateIndexCommand.java:250)
at 
org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parse(SqlCreateIndexCommand.java:172)
at 
org.apache.ignite.internal.sql.SqlParser.processCreate(SqlParser.java:207)
at 
org.apache.ignite.internal.sql.SqlParser.nextCommand0(SqlParser.java:106)
at 
org.apache.ignite.internal.sql.SqlParser.nextCommand(SqlParser.java:76)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.tryQueryDistributedSqlFieldsNative(IgniteH2Indexing.java:1509)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1599)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2035)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2030)
at 
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2578)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2044)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:664)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:615)
at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:356)
at 
org.apache.ignite.sqltests.BaseSqlTest.fillCommonData(BaseSqlTest.java:107)
{noformat}



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

[jira] [Created] (IGNITE-8341) .NET: Add new metrics for data storage

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-8341:
--

 Summary: .NET: Add new metrics for data storage
 Key: IGNITE-8341
 URL: https://issues.apache.org/jira/browse/IGNITE-8341
 Project: Ignite
  Issue Type: New Feature
Reporter: Dmitriy Govorukhin






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

Re: Topology-wide notification on critical errors

[Anton Vinogradov]

P.s. Andrey Kuznetsov, corrected me that we have no warranty that failed
node able to notify cluster.

But,

try{
   sendDiscoveryMessageWithFail(...);
} catch(){
   // No-op;
}

is better than nothing, I think.

2018-04-20 14:22 GMT+03:00 Anton Vinogradov :

> Sounds helpful and easy to implement.
>
> 2018-04-20 5:39 GMT+03:00 Dmitriy Setrakyan :
>
>> On Thu, Apr 19, 2018 at 8:19 AM, Yakov Zhdanov 
>> wrote:
>>
>> > Guys,
>> >
>> > We have activity to implement a set of mechanisms to handle critical
>> issues
>> > on nodes (IEP-14 - [1]).
>> >
>> > I have an idea to spread message about critical issues to nodes through
>> > entire topology and put it to logs of all nodes. In my view this will
>> add
>> > much more clarity. Imagine all nodes output message to log - "Critical
>> > system thread failed on node XXX [details=...]". This should help a lot
>> > with investigations.
>> >
>> > Andrey Gura, Alex Goncharuk what do you think?
>> >
>>
>> Yakov, even though you did not ask me what I think, but I really like the
>> idea :)
>>
>
>

[jira] [Created] (IGNITE-8340) .NET Implement new JMX metrics for transactions

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-8340:
--

 Summary: .NET Implement new JMX metrics for transactions
 Key: IGNITE-8340
 URL: https://issues.apache.org/jira/browse/IGNITE-8340
 Project: Ignite
  Issue Type: New Feature
Reporter: Dmitriy Govorukhin






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

[GitHub] ignite pull request #3885: IGNITE-8339 Do not log to WAL partition own durin...

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-8339 Do not log to WAL partition own during activation.



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

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

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

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


commit c8b64bb3a1f3a6c37c00e8406be7bf20fd72b606
Author: Pavel Kovalenko 
Date:   2018-04-20T11:40:41Z

IGNITE-8339 Do not log to WAL partition own during activation.




---

Re: Topology-wide notification on critical errors

[Anton Vinogradov]

Sounds helpful and easy to implement.

2018-04-20 5:39 GMT+03:00 Dmitriy Setrakyan :

> On Thu, Apr 19, 2018 at 8:19 AM, Yakov Zhdanov 
> wrote:
>
> > Guys,
> >
> > We have activity to implement a set of mechanisms to handle critical
> issues
> > on nodes (IEP-14 - [1]).
> >
> > I have an idea to spread message about critical issues to nodes through
> > entire topology and put it to logs of all nodes. In my view this will add
> > much more clarity. Imagine all nodes output message to log - "Critical
> > system thread failed on node XXX [details=...]". This should help a lot
> > with investigations.
> >
> > Andrey Gura, Alex Goncharuk what do you think?
> >
>
> Yakov, even though you did not ask me what I think, but I really like the
> idea :)
>

Re: Ticket review checklist

[Anton Vinogradov]

Vova,

Everything you described sound good to me.

I'd like to propose to create special page at AI Wiki and to describe
checklist.
In case we'll find something should be changed/improved it will be easy to
update the page.

2018-04-20 0:53 GMT+03:00 Nikolay Izhikov :

> Hello, Vladimir.
>
> Thank you for seting up this discussion.
>
> As we discussed, I think an important part of this check list is
> compatibility rules.
>
> * What should be backward compatible?
> * How should we maintain it?
>
> > 3) If ticket changes public API or existing behavior, at least two
> commiters should approve the changes
>
> We can learn from other open source project experience.
> Apache Kafka [1], for example, requires KIP(kafka improvement proposal)
> for *every* major change.
> Major change definition includes public API.
>
> [1] https://cwiki.apache.org/confluence/display/KAFKA/
> Kafka+Improvement+Proposals
>
>
> В Чт, 19/04/2018 в 23:00 +0300, Vladimir Ozerov пишет:
> > Hi Igniters,
> >
> > It's glad to see our community becomes larger every day. But as it grows
> it
> > becomes more and more difficult to manage review and merge processes and
> > keep quality of our decisions at the proper level. More contributors,
> more
> > commits, more components interlinked with each other in subtle ways.
> >
> > I would like to propose to setup a formal review checklist. This would
> be a
> > set of actions every reviewer needs to check before approving merge of a
> > certain feature. Passing the checklist would be *necessary but not
> > sufficient* phase before commit could be added to the main branch. The
> > checklist would help us to detect a lot of common problems such a broken
> > tests or bad UX earlier, and would help contributors lead their pull
> > requests to merge.
> >
> > Hallmarks of a good checklist:
> > - It must be followed be everyone without exceptions
> > - It must be clear and disallow multiple interpretations
> > - It must be lightweight, otherwise Ignite development would become a
> > nightmare
> > - It must be non-blocking, i.e. inacessibility of a single contributor
> > should not block ticket progress forever.
> >
> > Please let me know if you think the idea makes sense. If we agree on it,
> > let's start defining action items for the checklist. My 2 cents:
> > 1) All unit tests pass on TC without new failures
> > 2) If ticket targets specific component, it should be reviewed by
> > component's maintainer*
> > 3) If ticket changes public API or existing behavior, at least two
> > commiters should approve the changes **
> >
> > Thoughts?
> >
> > Vladimir.
> >
> > * TBD: Review component list and define maintainers; define what to do if
> > maintainer is unavailable
> > ** TBD: Define what is "public API"
>

[jira] [Created] (IGNITE-8339) After cluster activation actual partition state restored from WAL may be lost

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8339:
---

 Summary: After cluster activation actual partition state restored 
from WAL may be lost
 Key: IGNITE-8339
 URL: https://issues.apache.org/jira/browse/IGNITE-8339
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.5


On cluster activation we restore partition states from checkpoint and WAL. But 
before that action we pre-create partitions by ideal assignment on 
"beforeExchange" phase and own it in case of first or next activation. This 
partition state change is logged to WAL and override actual last state of 
partition during restore.

Possible solutions:
1) Pre-create partitions after actual restore.
2) Do not log to WAL partition own on pre-create phase.



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

[jira] [Created] (IGNITE-8338) Cache operations hang after cluster deactivation and activation again

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8338:
---

 Summary: Cache operations hang after cluster deactivation and 
activation again
 Key: IGNITE-8338
 URL: https://issues.apache.org/jira/browse/IGNITE-8338
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.4
Reporter: Pavel Kovalenko
 Fix For: 2.6


Problem:
1) Start several nodes
2) Activate cluster
3) Run cache load
4) Deactivate cluster
5) Activate again

After second activation cache operations hang with following stacktrace:

{noformat}
"cache-load-2" #210 prio=5 os_prio=0 tid=0x7efbb401b800 nid=0x602b waiting 
on condition [0x7efb809b3000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.publicJCache(GridCacheProcessor.java:3782)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.publicJCache(GridCacheProcessor.java:3753)
at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.checkProxyIsValid(GatewayProtectedCacheProxy.java:1486)
at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onEnter(GatewayProtectedCacheProxy.java:1508)
at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:785)
at 
org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTestWithPersistence.lambda$testDeactivateDuringEviction$0(IgniteClusterActivateDeactivateTestWithPersistence.java:316)
at 
org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTestWithPersistence$$Lambda$39/832408842.run(Unknown
 Source)
at 
org.apache.ignite.testframework.GridTestUtils$6.call(GridTestUtils.java:1254)
at 
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
{noformat}

It seems, dynamicStartCache future never completes after second activation.



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

Re: Deprecate CacheRebalanceMode.NONE

[Anton Vinogradov]

+1

2018-04-17 19:29 GMT+03:00 Dmitry Pavlov :

> +1
>
> вт, 17 апр. 2018 г. в 19:14, Pavel Kovalenko :
>
> > +1
> > I also agree to remove this option in 3.0
> >
> > 2018-04-17 19:00 GMT+03:00 Yakov Zhdanov :
> >
> > > +1 here
> > >
> > > Always wanted to remove ForceKeysRequest =)
> > >
> > > --Yakov
> > >
> >
>

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Nikolay Izhikov]

Hello, Manu

Thanks. I will take a look.

В Пт, 20/04/2018 в 03:17 -0700, Manu пишет:
> Hi,
> 
> Have you think about implementing TDE per DataRegion instead of per Cache?
> 
> And using a transparent encrypted java  file system?  
> This GitHub project is interesting  https://github.com/usrflo/encfs4j
>   .
> 
> Hope it helps!
> 
> Regards!
> 
> 
> 
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

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

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Manu]

Hi,

Have you think about implementing TDE per DataRegion instead of per Cache?

And using a transparent encrypted java  file system?  
This GitHub project is interesting  https://github.com/usrflo/encfs4j
  .

Hope it helps!

Regards!



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

[jira] [Created] (IGNITE-8337) Java ThinClient benchmark for yardstick

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-8337:
-

 Summary: Java ThinClient benchmark for yardstick
 Key: IGNITE-8337
 URL: https://issues.apache.org/jira/browse/IGNITE-8337
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.4
Reporter: Sergey Kozlov
 Fix For: 2.5


Version 2.4 introduced new binary protocol thus we need to add put, put-get, 
put-all benchmarks for Yardstick for both atomic, tx caches.
Take the data models, the load profiles from regular benchmarks



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

[jira] [Created] (IGNITE-8336) Web console: fix failing E2E notebooks test

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-8336:


 Summary: Web console: fix failing E2E notebooks test
 Key: IGNITE-8336
 URL: https://issues.apache.org/jira/browse/IGNITE-8336
 Project: Ignite
  Issue Type: Test
  Components: wizards
Reporter: Ilya Borisov
Assignee: Alexander Kalinin
 Attachments: image-2018-04-20-16-27-36-653.png, 
image-2018-04-20-16-31-46-185.png

The all notebooks removal E2E test fails in master branch:
!image-2018-04-20-16-27-36-653.png!

At the same time, there's an UI regression of row selection column:
 !image-2018-04-20-16-31-46-185.png! 

I think those two are related and test fails because the code that clicks 
"select all rows" checkbox can't work around the regression.



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

Re: [IGNITE-5714] Design proposal of suspend/resume for pessimistic tx

[Кузнецов Алексей Львович]

PR for this issue is ready to be reviewed.
Changes are relatively small.

1. No network messages have been changed.
2. Thread id usage replaced with xid usage when we work with candidates.
3. All current tests are passed [3]

Please, review. [1], [2]

[1] https://issues.apache.org/jira/browse/IGNITE-5714
[2] https://github.com/apache/ignite/pull/2789
[3] 
https://ci.ignite.apache.org/viewLog.html?buildId=1229177=buildResultsDiv=IgniteTests24Java8_RunAll


28.02.2018 19:10, Aleksey Kuznetsov пишет:
> What if originating(or primary, or couple of primaries) node(s) 
fails when tx is suspended?


Thanks for advice, I've added a couple of failover tests. With the 
following scenarios :


Started transaction, perform some put, suspend it and primary node 
fails. Works as expected : tx rollbacks.
In another scenario, the originating node fails. Works as expected : 
tx rollbacks.


> Do we have tests for this feature?

yeah,we do.

ср, 28 февр. 2018 г. в 14:45, Nikolay Izhikov >:


Hello, Aleksey.

> Tests were added for suspending/resuming optimistic transaction
earlier for parent task.
> I adopted them for pessimistic mode. Also tx rollback tests were
aded.

I think, at least, we need new failover tests.

What if originating(or primary, or couple of primaries) node(s)
fails when tx is suspended?

> Note, that if user suspends transaction and forgets to resume it,
> transaction would be rolled back once timeout has occurred.

Do we have tests for this feature?

В Ср, 28/02/2018 в 10:29 +, Aleksey Kuznetsov пишет:
> Thanx for the answer!
>
> > Can we remove thread id completely from code?
> > Can you estimate how much effort do we need?
>
> I haven't removed thread id completely from the code because we
tightly
> coupled to it in some parts.
> For instance, look at the following scenario :
>
> "When we suspend transaction, we must make sure only thread started
> transaction can suspend it. So we compare thread id in
> `GridNearTxLocal#suspend()`."
>
> Note that cache locks also make use of thread id, consider the
following
> scenario:
>
> "We create cache lock and perform put operation in the same
thread, which
> create implicit transaction. Transaction would compare both
therad ids in
> tx and cache lock and can apply the optimisation: tx would take
advantage
> of cache lock, and would not create its own lock on key."
>
> If we really needed to remove it completely from the code,
significant
> changes are required both to transactions and cache locks.
>
> It could take several weeks to completely remove thread id.
>
> > As far as I can see from parent task [1] we need some complex
tests to be
>
> implemented.
> > Are they presented in prototype?
>
> Tests were added for suspending/resuming optimistic transaction
earlier for
> parent task.
> I adopted them for pessimistic mode.
> Also tx rollback tests were aded.  They check whether timeout
metrics are
> correctly calculated for suspended transactions. You can find
them in
> `GridCacheTransactionalAbstractMetricsSelfTest`.
>
> Please, feel free to propose additional tests for the ticket.
>
>
> вт, 27 февр. 2018 г. в 17:27, Nikolay Izhikov
>:
>
> > Hello, Alexey.
> >
> > Great mail, by the way.
> > I think, it would be great to have this feature in Ignite.
> >
> > > I haven't removed thread id completely from code.
> >
> > Can we remove thread id completely from code?
> > Can you estimate how much effort do we need?
> >
> > As far as I can see from parent task [1] we need some complex
tests to be
> > implemented.
> > Are they presented in prototype?
> >
> > [1]
> >

https://issues.apache.org/jira/browse/IGNITE-4887?focusedCommentId=16069655=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16069655
> >
> > В Пн, 26/02/2018 в 10:59 +, Aleksey Kuznetsov пишет:
> > > Hello Igniters!
> > >
> > > Currently we have suspension/resuming implemented for optimistic
> > > transactions [1].
> > > Unless suspend/resume isn't supported for pessimistic tx JTA
isn't fully
> > > supported [4].
> > >
> > > I’m working on a ticket "Suspension/resuming for pessimistic
> >
> > transactions"
> > > [2].
> > > Goal of the ticket is to support transaction suspend/resume for
> >
> > pessimistic
> > > transactions.
> > >
> > > # Benefits of suspending/resuming transaction.
> > >
> > >   1. Full JTA standart support.
> > >   2. Increase of throughput in high-load scenarios.
> > >       Suspend operation would allow to release Ignite

[GitHub] ignite pull request #3397: IGNITE-7077: Implementation of Spark query optimi...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3884: Ignite 8322

[oleg-ostanin]

GitHub user oleg-ostanin opened a pull request:

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

Ignite 8322



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

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

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

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


commit 328d84cf25c0c607e0b37aeb82f83938f09a838a
Author: oleg-ostanin 
Date:   2018-03-28T13:43:35Z

added method for data preload

commit e84aba963b704b26a1270a2f1eb327debe6d8d24
Author: oleg-ostanin 
Date:   2018-03-28T14:26:56Z

added option for enabling preload

commit 6a8a877ae2d500ef61a0d9fe372bdaffdf058c5f
Author: oleg-ostanin 
Date:   2018-03-29T08:47:27Z

added preloader class

commit e7fb9c1a4e09de29d4fbe5b4c733d7efa1b0eabc
Author: oleg-ostanin 
Date:   2018-03-29T09:04:19Z

removed default dataregion config

commit 5f48d8cf11fcd61c3f4ec596e6814eb181c7774a
Author: oleg-ostanin 
Date:   2018-03-29T11:56:43Z

added waiting for preload for clients

commit 9cbab5287c6dc4576867c984b03767751d1c8921
Author: oleg-ostanin 
Date:   2018-03-30T10:21:05Z

added semaphore on preload for clients

commit 4f13833108fb58a6c9f366150bb51158abb9879e
Author: oleg-ostanin 
Date:   2018-04-19T11:52:08Z

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

commit 49f4730327126c7ac22ac095edec0434122983b4
Author: oleg-ostanin 
Date:   2018-04-19T12:14:21Z

IGNITE-8322 added some comments

commit 5137a4810a6ef57d1fd2a095b06c0db1a0ffcfe4
Author: oleg-ostanin 
Date:   2018-04-19T12:20:25Z

IGNITE-8322 fixed format




---

[jira] [Created] (IGNITE-8335) TensorFlow integration

[Yury Babak (JIRA)]

Yury Babak created IGNITE-8335:
--

 Summary: TensorFlow integration
 Key: IGNITE-8335
 URL: https://issues.apache.org/jira/browse/IGNITE-8335
 Project: Ignite
  Issue Type: New Feature
  Components: ml
Reporter: Yury Babak
Assignee: Yury Babak


We want to have a integration with TensorFlow. Currently we think that we will 
implement our own parameter server(our wrap it) and distribute python code to 
local nodes with data.

This solution should use our datasets and python thin client in local python 
tasks.



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

[jira] [Created] (IGNITE-8334) Web console: add ability to show/hide password field value

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-8334:


 Summary: Web console: add ability to show/hide password field value
 Key: IGNITE-8334
 URL: https://issues.apache.org/jira/browse/IGNITE-8334
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Ilya Borisov
Assignee: Ilya Borisov
 Attachments: eye-icon-close.svg, eye-icon-open.svg

The ability to toggle password inputs value visibility will improve the UX of 
several forms. Since most of password inputs are located on sign-in and profile 
pages, for now it'll be enough to update inputs used on these pages only.

The button should:
1. Has opened eye icon when password value is visible.
2. Has closed eye icon when password value is hidden (i.e. default dots).
3. Be placed at the right side of the input and to the right of validation 
error message. That means that error message will be place a bit more to the 
left compared to text inputs.



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

Re: Service grid redesign

[Denis Mekhanikov]

Val,

*init()* method is executed before a service is considered deployed.
If any exception is thrown from it, then it will be handled as deployment
failure.

*execute() *method is run after the service is deployed, and it can keep
running until the service is cancelled.
This method has its own thread, so it can perform some background work.

Suppose you want to deploy HTTP server as a service on one of your nodes.
You can place HTTP server creation logic in the *init() *method.
If some nodes don't have a permission to listen to needed ports, then a
corresponding exception will be propagated to the user code.
On the other hand, if exception is thrown from the *execute() *method, then
service won't be undeployed.

Denis

пт, 20 апр. 2018 г. в 2:35, Valentin Kulichenko <
valentin.kuliche...@gmail.com>:

> Denis,
>
> I totally agree with you. I'm just not sure why do we need two methods
> (init and execute) that have virtually same semantics. With the new design,
> what would be the difference between these methods from user point of view,
> and how one would determine what exactly should go in each of them? Unless
> I'm missing something, it looks like unnecessary complication.
>
> -Val
>
> On Tue, Apr 17, 2018 at 1:00 AM, Denis Mekhanikov 
> wrote:
>
> > Val,
> >
> > Service initialisation is not going to happen in the discovery thread.
> > It should be done asynchronously, and initialisation results should be
> sent
> > to the coordinator over communication.
> > This is described in the IEP:
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > 17%3A+Oil+Change+in+Service+Grid#IEP-17:OilChangeinServiceGrid-
> > Successfulscenario
> >
> > *init()* method is a validation step, making sure, that service is ready
> > for work.
> > And deployment shouldn't be considered successful until *init()* methods
> > finish their work on the assigned nodes.
> > Also *cancel() *and *init() *methods may be useful if we decide to
> > implement moving existing services to new nodes
> >  > 17%3A+Oil+Change+in+Service+Grid#IEP-17:OilChangeinServiceGrid-
> > Movingexistingservicestonewnodes>
> >  in
> > future.
> > These methods can be used to save and restore service's state from cache,
> > when it is rebalanced to another node.
> >
> > As Denis said, if we are not going to prevent nodes from starting on
> > service failures, then we should at least generate corresponding events.
> > Otherwise there won't be any way to react to service initialization
> > failures during nodes startup.
> >
> > Denis
> >
> > вт, 17 апр. 2018 г. в 6:59, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com>:
> >
> > > I agree we shouldn't do anything synchronously within discovery
> threads.
> > If
> > > something goes wrong, we just need to properly notify the user, logging
> > and
> > > events seem to be right options to achieve that.
> > >
> > > BTW, with this design I'm not sure init() method makes sense, probably
> we
> > > should deprecate it.
> > >
> > > -Val
> > >
> > > On Mon, Apr 16, 2018 at 12:03 PM, Denis Magda 
> wrote:
> > >
> > > > Denis,
> > > >
> > > > In general, service initialization shouldn't prevent a node from
> > joining
> > > > the cluster or slowing down that process. Thus, I would start the
> > > > initialization routines only after the node is accepted by the
> cluster.
> > > If
> > > > the initialization fails then we need to report a respective message
> to
> > > the
> > > > logs and, probably, generate a system event the user can be
> subscribed
> > > to.
> > > >
> > > > Regardless, of the service initialization time, I think we still need
> > to
> > > > utilize discovery SPI to avoid problems discussed later.
> > > >
> > > > Val, others, what do you think about that?
> > > >
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On Mon, Apr 16, 2018 at 10:29 AM, Denis Mekhanikov <
> > > dmekhani...@gmail.com>
> > > > wrote:
> > > >
> > > > > Basically, my question is: at which moment services should be
> > deployed
> > > on
> > > > > connecting nodes?
> > > > > Should we reject a node from being included into a topology, if
> > > services,
> > > > > that are assigned to it, fail to deploy?
> > > > >
> > > > > It would be good to be sure, that all assigned services are
> > initialised
> > > > and
> > > > > working, when node start is finished.
> > > > > Otherwise it's unclear, how to notify a user about failures in
> > service
> > > > > initialisation on new nodes.
> > > > >
> > > > > If we decide to provide such guarantee, then how are we going to do
> > > that?
> > > > > Is procedure, that I described, viable?
> > > > > It requires hacking through the discovery protocol, which is a
> thing,
> > > > that
> > > > > should be avoided.
> > > > > So, maybe there is another way to achieve the same thing?
> > > > >
> > > > > Denis
> > > > >
> > > > > сб, 14 апр. 2018 г. в 1:48, Denis Magda :
> > >