[jira] [Closed] (IGNITE-6120) Web Console: Propagate "lazy" flag on Query screen

[Andrey Novikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Novikov closed IGNITE-6120.
--
Assignee: Alexey Kuznetsov  (was: Andrey Novikov)

> Web Console: Propagate "lazy" flag on Query screen
> --
>
> Key: IGNITE-6120
> URL: https://issues.apache.org/jira/browse/IGNITE-6120
> Project: Ignite
>  Issue Type: Task
>  Components: sql, wizards
>Affects Versions: 2.1
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6120) Web Console: Propagate "lazy" flag on Query screen

[Pavel Konstantinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Konstantinov reassigned IGNITE-6120:
--

Assignee: Andrey Novikov  (was: Pavel Konstantinov)

> Web Console: Propagate "lazy" flag on Query screen
> --
>
> Key: IGNITE-6120
> URL: https://issues.apache.org/jira/browse/IGNITE-6120
> Project: Ignite
>  Issue Type: Task
>  Components: sql, wizards
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6120) Web Console: Propagate "lazy" flag on Query screen

[Pavel Konstantinov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156432#comment-16156432
 ] 

Pavel Konstantinov commented on IGNITE-6120:


Most probably it is my mistake. [~anovikov] please merge into correct target 
branch.

> Web Console: Propagate "lazy" flag on Query screen
> --
>
> Key: IGNITE-6120
> URL: https://issues.apache.org/jira/browse/IGNITE-6120
> Project: Ignite
>  Issue Type: Task
>  Components: sql, wizards
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6053) IgniteCache.clear clears local caches with same names on all server nodes

[Roman Shtykh (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156414#comment-16156414
 ] 

Roman Shtykh commented on IGNITE-6053:
--

[~ntikhonov] Thank you for the explanation!
TC on the link you provided seems not to be triggered again. It produces 
*Snapshot dependencies failed* error, I don't know why.
However, I ran it from https://ci.ignite.apache.org/overview.html, and it seems 
to be ok.

> IgniteCache.clear clears local caches with same names on all server nodes
> -
>
> Key: IGNITE-6053
> URL: https://issues.apache.org/jira/browse/IGNITE-6053
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Roman Shtykh
> Fix For: 2.3
>
>
> Clear on LOCAL cache should clear cache on the current node only, not on all 
> nodes, that have local caches with same names.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6278) Add benchmarking page to readme.io

[Dmitriy Setrakyan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Setrakyan updated IGNITE-6278:
--
Fix Version/s: 2.3

> Add benchmarking page to readme.io
> --
>
> Key: IGNITE-6278
> URL: https://issues.apache.org/jira/browse/IGNITE-6278
> Project: Ignite
>  Issue Type: Wish
>  Components: documentation
>Reporter: Aleksei Zaitsev
>Assignee: Aleksei Zaitsev
>Priority: Minor
> Fix For: 2.3
>
>
> Add a page with information about benchmarking to 
> https://apacheignite.readme.io/docs



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6261) ODBC support for Mac OSX

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-6261:

Labels: usability  (was: )

> ODBC support for Mac OSX
> 
>
> Key: IGNITE-6261
> URL: https://issues.apache.org/jira/browse/IGNITE-6261
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc, sql
>Affects Versions: 2.1
> Environment: Analytics
>Reporter: Pranas Baliuka
>Assignee: Igor Sapego
>  Labels: usability
> Fix For: 2.3
>
>
> In order for Ignite to be useful in analytics environment (accessing data via 
> R / Most reporting engines), the ODBC access is required.
> Analyst do use Mac OSX (not only Linux/Windows).
> The current ODBC driver is not compilable on OSX due to 1-2 different kernel 
> API functions.
> Similar incompatibility issues are already resolved in similar projects using 
> conditional macros in C language. i.e. it may not be a big challenge to make 
> it work.
> Thanks for planning and considerations!
> PS:
> For my use case the issue is a Blocker, because rJAVA is dead (requires Java 
> 6 installation on Mac OSX) and even with rJAVA , the JDBC implementation is 
> not working for R (class cast exceptions).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6261) ODBC support for Mac OSX

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-6261:

Issue Type: Bug  (was: Wish)

> ODBC support for Mac OSX
> 
>
> Key: IGNITE-6261
> URL: https://issues.apache.org/jira/browse/IGNITE-6261
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc, sql
>Affects Versions: 2.1
> Environment: Analytics
>Reporter: Pranas Baliuka
>Assignee: Igor Sapego
>  Labels: usability
> Fix For: 2.3
>
>
> In order for Ignite to be useful in analytics environment (accessing data via 
> R / Most reporting engines), the ODBC access is required.
> Analyst do use Mac OSX (not only Linux/Windows).
> The current ODBC driver is not compilable on OSX due to 1-2 different kernel 
> API functions.
> Similar incompatibility issues are already resolved in similar projects using 
> conditional macros in C language. i.e. it may not be a big challenge to make 
> it work.
> Thanks for planning and considerations!
> PS:
> For my use case the issue is a Blocker, because rJAVA is dead (requires Java 
> 6 installation on Mac OSX) and even with rJAVA , the JDBC implementation is 
> not working for R (class cast exceptions).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6261) ODBC support for Mac OSX

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-6261:

Component/s: sql

> ODBC support for Mac OSX
> 
>
> Key: IGNITE-6261
> URL: https://issues.apache.org/jira/browse/IGNITE-6261
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc, sql
>Affects Versions: 2.1
> Environment: Analytics
>Reporter: Pranas Baliuka
>Assignee: Igor Sapego
>  Labels: usability
> Fix For: 2.3
>
>
> In order for Ignite to be useful in analytics environment (accessing data via 
> R / Most reporting engines), the ODBC access is required.
> Analyst do use Mac OSX (not only Linux/Windows).
> The current ODBC driver is not compilable on OSX due to 1-2 different kernel 
> API functions.
> Similar incompatibility issues are already resolved in similar projects using 
> conditional macros in C language. i.e. it may not be a big challenge to make 
> it work.
> Thanks for planning and considerations!
> PS:
> For my use case the issue is a Blocker, because rJAVA is dead (requires Java 
> 6 installation on Mac OSX) and even with rJAVA , the JDBC implementation is 
> not working for R (class cast exceptions).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6261) ODBC support for Mac OSX

[Pranas Baliuka (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156294#comment-16156294
 ] 

Pranas Baliuka commented on IGNITE-6261:


It's {{pthread_condattr_setclock(, CLOCK_MONOTONIC)}}

{quote}
Imin:odbc pranas$ glibtoolize && aclocal && autoheader && automake 
--add-missing && autoreconf
glibtoolize: putting auxiliary files in '.'.
glibtoolize: linking file './ltmain.sh'
glibtoolize: putting macros in 'm4'.
glibtoolize: linking file 'm4/libtool.m4'
glibtoolize: linking file 'm4/ltoptions.m4'
glibtoolize: linking file 'm4/ltsugar.m4'
glibtoolize: linking file 'm4/ltversion.m4'
glibtoolize: linking file 'm4/lt~obsolete.m4'
aclocal: error: 'configure.ac' is required
Imin:odbc pranas$ pwd
/Users/pranas/Downloads/ignite-ignite-2.1/modules/platforms/cpp/odbc
Imin:odbc pranas$ cd ..
Imin:cpp pranas$ glibtoolize && aclocal && autoheader && automake --add-missing 
&& autoreconf
glibtoolize: putting auxiliary files in '.'.
glibtoolize: linking file './ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
glibtoolize: linking file 'm4/libtool.m4'
glibtoolize: linking file 'm4/ltoptions.m4'
glibtoolize: linking file 'm4/ltsugar.m4'
glibtoolize: linking file 'm4/ltversion.m4'
glibtoolize: linking file 'm4/lt~obsolete.m4'
configure.ac:36: installing './ar-lib'
configure.ac:35: installing './compile'
configure.ac:24: installing './config.guess'
configure.ac:24: installing './config.sub'
configure.ac:28: installing './install-sh'
configure.ac:28: installing './missing'
binary/Makefile.am: installing './depcomp'
Imin:cpp pranas$ ./configure --enable-odbc --disable-node --disable-core
checking build system type... x86_64-apple-darwin16.7.0
checking host system type... x86_64-apple-darwin16.7.0
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... rm: core: is a directory
yes
checking whether gcc accepts -g... rm: core: is a directory
yes
checking for gcc option to accept ISO C89... rm: core: is a directory
none needed
checking whether gcc understands -c and -o together... rm: core: is a directory
yes
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for ar... ar
checking the archiver (ar) interface... rm: core: is a directory
ar
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
checking if the linker 
(/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld)
 is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking how to convert x86_64-apple-darwin16.7.0 file names to 
x86_64-apple-darwin16.7.0 format... func_convert_file_noop
checking how to convert x86_64-apple-darwin16.7.0 file names to toolchain 
format... func_convert_file_noop
checking for 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
 option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for g++... g++
checking whether we are using the GNU C++ compiler... rm: core: is a directory
yes
checking whether g++ accepts -g... rm: core: is a directory
yes
checking dependency style of g++... gcc3
checking for archiver @FILE support... rm: core: is a directory
no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for dsymutil... dsymutil
checking for 

[jira] [Updated] (IGNITE-6242) Passing custom cache and type names to CREATE TABLE

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-6242:

Description: 
Once CREATE TABLE is executed Ignite:
* will create an IgniteCache naming it SQL_PUBLIC_\{TABLE\}. So, if a Person 
table is created you’ll have SQL_PUBLIC_PERSON cache in the cluster.
* will use autogenerated names for the key and value types. For instance, this 
is how the type name might look like 
SQL_PUBLIC_CITY_3f4e9fbf_3464_4598_8394_1307b86dc4e7_KEY.

The goal of the ticket is to give a way to pass a custom cache name, key's type 
name, value's type name into WITH clause.

Refer to this discussion for more details:
http://apache-ignite-developers.2346864.n4.nabble.com/Key-value-access-to-caches-created-with-DDL-td21622.html
http://apache-ignite-developers.2346864.n4.nabble.com/Override-cache-name-created-with-CREATE-TABLE-td21456.html


  was:
CREATE TABLE automatically creates an IgniteCache naming it 
SQL_PUBLIC_\{TABLE\}. So, if a Person table is created you’ll have 
SQL_PUBLIC_PERSON cache in the cluster.

If we keep to SQL APIs the cache name is not a big deal but as soon as 
key-value, compute, service grid APIs are needed the cache name will be used 
here and there looking bizarre.

Let's give a way to pass the cache name into WITH clause parameters set


> Passing custom cache and type names to CREATE TABLE
> ---
>
> Key: IGNITE-6242
> URL: https://issues.apache.org/jira/browse/IGNITE-6242
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
>  Labels: usability
> Fix For: 2.3
>
>
> Once CREATE TABLE is executed Ignite:
> * will create an IgniteCache naming it SQL_PUBLIC_\{TABLE\}. So, if a Person 
> table is created you’ll have SQL_PUBLIC_PERSON cache in the cluster.
> * will use autogenerated names for the key and value types. For instance, 
> this is how the type name might look like 
> SQL_PUBLIC_CITY_3f4e9fbf_3464_4598_8394_1307b86dc4e7_KEY.
> The goal of the ticket is to give a way to pass a custom cache name, key's 
> type name, value's type name into WITH clause.
> Refer to this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/Key-value-access-to-caches-created-with-DDL-td21622.html
> http://apache-ignite-developers.2346864.n4.nabble.com/Override-cache-name-created-with-CREATE-TABLE-td21456.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6242) Passing custom cache and type names to CREATE TABLE

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-6242:

Summary: Passing custom cache and type names to CREATE TABLE  (was: Passing 
custom cache name to CREATE TABLE)

> Passing custom cache and type names to CREATE TABLE
> ---
>
> Key: IGNITE-6242
> URL: https://issues.apache.org/jira/browse/IGNITE-6242
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
>  Labels: usability
> Fix For: 2.3
>
>
> CREATE TABLE automatically creates an IgniteCache naming it 
> SQL_PUBLIC_\{TABLE\}. So, if a Person table is created you’ll have 
> SQL_PUBLIC_PERSON cache in the cluster.
> If we keep to SQL APIs the cache name is not a big deal but as soon as 
> key-value, compute, service grid APIs are needed the cache name will be used 
> here and there looking bizarre.
> Let's give a way to pass the cache name into WITH clause parameters set



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6261) ODBC support for Mac OSX

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156208#comment-16156208
 ] 

Denis Magda commented on IGNITE-6261:
-

[~pranas], could you name the kernet 2 functions that have to be supported 
differently?

> ODBC support for Mac OSX
> 
>
> Key: IGNITE-6261
> URL: https://issues.apache.org/jira/browse/IGNITE-6261
> Project: Ignite
>  Issue Type: Wish
>  Components: odbc
>Affects Versions: 2.1
> Environment: Analytics
>Reporter: Pranas Baliuka
>Assignee: Igor Sapego
> Fix For: 2.3
>
>
> In order for Ignite to be useful in analytics environment (accessing data via 
> R / Most reporting engines), the ODBC access is required.
> Analyst do use Mac OSX (not only Linux/Windows).
> The current ODBC driver is not compilable on OSX due to 1-2 different kernel 
> API functions.
> Similar incompatibility issues are already resolved in similar projects using 
> conditional macros in C language. i.e. it may not be a big challenge to make 
> it work.
> Thanks for planning and considerations!
> PS:
> For my use case the issue is a Blocker, because rJAVA is dead (requires Java 
> 6 installation on Mac OSX) and even with rJAVA , the JDBC implementation is 
> not working for R (class cast exceptions).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6287) CREATE TABLE doesn't work from Web Console

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-6287:

Labels: usability  (was: )

> CREATE TABLE doesn't work from Web Console
> --
>
> Key: IGNITE-6287
> URL: https://issues.apache.org/jira/browse/IGNITE-6287
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Andrey Novikov
>Priority: Critical
>  Labels: usability
>
> DDL queries like CREATE TABLE don't work in Web Console.
> First, if Ignite cluster is started with zero caches deployed then "Execute" 
> button will be disabled and there is now way to execute CREATE TABLE in 
> general.
> Second, if to create a dummy cache on cluster startup and execute this
> {code}
> CREATE TABLE City (
>   id LONG PRIMARY KEY, name VARCHAR)
>   WITH "template=replicated";
> {code}
> Then the console will generate the exception 
> {code}
> Error: class org.apache.ignite.internal.processors.query.IgniteSQLException: 
> CREATE TABLE can only be executed on PUBLIC schema.
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6287) CREATE TABLE doesn't work from Web Console

[Denis Magda (JIRA)]

Denis Magda created IGNITE-6287:
---

 Summary: CREATE TABLE doesn't work from Web Console
 Key: IGNITE-6287
 URL: https://issues.apache.org/jira/browse/IGNITE-6287
 Project: Ignite
  Issue Type: Bug
Reporter: Denis Magda
Assignee: Andrey Novikov
Priority: Critical


DDL queries like CREATE TABLE don't work in Web Console.

First, if Ignite cluster is started with zero caches deployed then "Execute" 
button will be disabled and there is now way to execute CREATE TABLE in general.

Second, if to create a dummy cache on cluster startup and execute this

{code}
CREATE TABLE City (
  id LONG PRIMARY KEY, name VARCHAR)
  WITH "template=replicated";
{code}

Then the console will generate the exception 

{code}
Error: class org.apache.ignite.internal.processors.query.IgniteSQLException: 
CREATE TABLE can only be executed on PUBLIC schema.
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4750) SQL: Support GROUP_CONCAT function

[Mikhail Cherkasov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Cherkasov updated IGNITE-4750:
--
Component/s: sql

> SQL: Support GROUP_CONCAT function
> --
>
> Key: IGNITE-4750
> URL: https://issues.apache.org/jira/browse/IGNITE-4750
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Denis Magda
>
> GROUP_CONCAT function is not supported at the moment. Makes sense to fill 
> this gap:
> http://apache-ignite-users.70518.x6.nabble.com/GROUP-CONCAT-function-is-unsupported-td10757.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6193) ML profile is missing in 2.1 binary release

[Oleg Ignatenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155633#comment-16155633
 ] 

Oleg Ignatenko edited comment on IGNITE-6193 at 9/6/17 4:46 PM:


[generated examples pom at 
TC|https://ci.ignite.apache.org/repository/download/IgniteRelease_ZzzMlIgniteRelease3PrepareVote/813695:id/vote/apache-ignite-fabric-2.2.0-bin.zip%21/apache-ignite-fabric-2.2.0-bin/examples/pom.xml]
 looks as expected: ml.folder property and ml profile are present at the right 
places


was (Author: oignatenko):
(/) pull request looks and works as expected: 
https://github.com/apache/ignite/pull/2604

TC build passed: 
https://ci.ignite.apache.org/viewLog.html?buildId=813695=buildResultsDiv=IgniteRelease_ZzzMlIgniteRelease3PrepareVote

generated pom file looks as expected at TC: 
https://ci.ignite.apache.org/repository/download/IgniteRelease_ZzzMlIgniteRelease3PrepareVote/813695:id/vote/apache-ignite-fabric-2.2.0-bin.zip%21/apache-ignite-fabric-2.2.0-bin/examples/pom.xml
({{ml.folder}} property and {{ml}} profile are present at the right places)

> ML profile is missing in 2.1 binary release
> ---
>
> Key: IGNITE-6193
> URL: https://issues.apache.org/jira/browse/IGNITE-6193
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Oleg Ignatenko
>Priority: Blocker
> Fix For: 2.2
>
>
> In Apache Ignite 2.0 we added the ML profile to the binary release that 
> allowed activating this functionality and running the examples easily. The 
> getting started is written based on the profile presence:
> https://apacheignite.readme.io/docs/machine-learning#section-getting-started
> The profile is missing for 2.1 release. To reproduce the issue just download 
> 2.1 binary release and follow the getting started section, you'll stumble on 
> step 4:
> https://apacheignite.readme.io/docs/machine-learning#section-getting-started
> This has to be fixed as soon as possible and the fix should be merged both in 
> the master and in a branch of the urgent Ignite release that is discussed 
> here:
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Urgent-Ignite-bug-fix-release-td21292.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6245) ODBC: Driver should return affected rows number for non-batch DML queries as well.

[Pavel Tupitsyn (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155634#comment-16155634
 ] 

Pavel Tupitsyn commented on IGNITE-6245:


[~isapego] Looks good to me.

> ODBC: Driver should return affected rows number for non-batch DML queries as 
> well.
> --
>
> Key: IGNITE-6245
> URL: https://issues.apache.org/jira/browse/IGNITE-6245
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>Assignee: Igor Sapego
> Fix For: 2.3
>
>
> Looks like {{OdbcQueryExecuteResult}} class doesn't have {{rowAffected}} 
> field that {{OdbcQueryExecuteBatchResult}} has.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6193) ML profile is missing in 2.1 binary release

[Oleg Ignatenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155633#comment-16155633
 ] 

Oleg Ignatenko commented on IGNITE-6193:


(/) pull request looks and works as expected: 
https://github.com/apache/ignite/pull/2604

TC build passed: 
https://ci.ignite.apache.org/viewLog.html?buildId=813695=buildResultsDiv=IgniteRelease_ZzzMlIgniteRelease3PrepareVote

generated pom file looks as expected at TC: 
https://ci.ignite.apache.org/repository/download/IgniteRelease_ZzzMlIgniteRelease3PrepareVote/813695:id/vote/apache-ignite-fabric-2.2.0-bin.zip%21/apache-ignite-fabric-2.2.0-bin/examples/pom.xml
({{ml.folder}} property and {{ml}} profile are present at the right places)

> ML profile is missing in 2.1 binary release
> ---
>
> Key: IGNITE-6193
> URL: https://issues.apache.org/jira/browse/IGNITE-6193
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Oleg Ignatenko
>Priority: Blocker
> Fix For: 2.2
>
>
> In Apache Ignite 2.0 we added the ML profile to the binary release that 
> allowed activating this functionality and running the examples easily. The 
> getting started is written based on the profile presence:
> https://apacheignite.readme.io/docs/machine-learning#section-getting-started
> The profile is missing for 2.1 release. To reproduce the issue just download 
> 2.1 binary release and follow the getting started section, you'll stumble on 
> step 4:
> https://apacheignite.readme.io/docs/machine-learning#section-getting-started
> This has to be fixed as soon as possible and the fix should be merged both in 
> the master and in a branch of the urgent Ignite release that is discussed 
> here:
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Urgent-Ignite-bug-fix-release-td21292.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (IGNITE-6193) ML profile is missing in 2.1 binary release

[Oleg Ignatenko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Ignatenko updated IGNITE-6193:
---
Comment: was deleted

(was: (/) TC build passed: 
https://ci.ignite.apache.org/viewLog.html?buildId=813473=buildResultsDiv=IgniteRelease_ZzzFromMirrorIgniteRelease3PrepareVote

(/) generated pom file looks as expected at TC: 
https://ci.ignite.apache.org/repository/download/IgniteRelease_ZzzFromMirrorIgniteRelease3PrepareVote/813473:id/vote/apache-ignite-fabric-2.2.0-ML-bin.zip%21/apache-ignite-fabric-2.2.0-ML-bin/examples/pom.xml
({{ml.folder}} property and {{ml}} profile are present at the right places))

> ML profile is missing in 2.1 binary release
> ---
>
> Key: IGNITE-6193
> URL: https://issues.apache.org/jira/browse/IGNITE-6193
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Oleg Ignatenko
>Priority: Blocker
> Fix For: 2.2
>
>
> In Apache Ignite 2.0 we added the ML profile to the binary release that 
> allowed activating this functionality and running the examples easily. The 
> getting started is written based on the profile presence:
> https://apacheignite.readme.io/docs/machine-learning#section-getting-started
> The profile is missing for 2.1 release. To reproduce the issue just download 
> 2.1 binary release and follow the getting started section, you'll stumble on 
> step 4:
> https://apacheignite.readme.io/docs/machine-learning#section-getting-started
> This has to be fixed as soon as possible and the fix should be merged both in 
> the master and in a branch of the urgent Ignite release that is discussed 
> here:
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Urgent-Ignite-bug-fix-release-td21292.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6282) C++: impossible to start node with persistent store

[Igor Sapego (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Sapego reassigned IGNITE-6282:
---

Assignee: Igor Sapego

> C++: impossible to start node with persistent store
> ---
>
> Key: IGNITE-6282
> URL: https://issues.apache.org/jira/browse/IGNITE-6282
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.2
>Reporter: Irina Zaporozhtseva
>Assignee: Igor Sapego
>Priority: Blocker
>  Labels: C++
> Fix For: 2.2
>
>
> C++: impossible to start node with persistent store. 
> Add to config:
> {code}
>
>class="org.apache.ignite.configuration.PersistentStoreConfiguration"/>
> 
> {code}
> After node started, error message appears:
> {code}
> [17:42:39] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8, 
> heap=0.89GB]
> ERROR: Can not perform the operation because the cluster is inactive. Note, 
> that the cluster is considered inactive by default if Ignite Persistent Store 
> is used to let all the nodes join the cluster. To activate the cluster call 
> Ignite.activate(true).
> {code}
> and after that node is stopped



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6286) incorrect 'setObject' call

[Sergey Chernolyas (JIRA)]

Sergey Chernolyas created IGNITE-6286:
-

 Summary: incorrect 'setObject' call
 Key: IGNITE-6286
 URL: https://issues.apache.org/jira/browse/IGNITE-6286
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.1
Reporter: Sergey Chernolyas


Incorrect set value of parameter. See 
https://github.com/apache/ignite/blob/ignite-2.1/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/IgniteH2Indexing.java#L510

The code leads to problem. See explanation in  
https://groups.google.com/forum/#!topic/h2-database/fiUw3tqRb1o



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6193) ML profile is missing in 2.1 binary release

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155583#comment-16155583
 ] 

ASF GitHub Bot commented on IGNITE-6193:


GitHub user oignatenko opened a pull request:

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

IGNITE-6193 ML profile is missing in 2.1 binary release

- porting changes to standalone and lgpl pom files from regular one
-- verified with diffs overview

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

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

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

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


commit 1501011b5fff5e1ef136081a73488c870177a76a
Author: Oleg Ignatenko 
Date:   2017-09-06T15:56:23Z

IGNITE-6193 ML profile is missing in 2.1 binary release
- porting changes to standalone and lgpl pom files from regular one
-- verified with diffs overview




> ML profile is missing in 2.1 binary release
> ---
>
> Key: IGNITE-6193
> URL: https://issues.apache.org/jira/browse/IGNITE-6193
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Oleg Ignatenko
>Priority: Blocker
> Fix For: 2.2
>
>
> In Apache Ignite 2.0 we added the ML profile to the binary release that 
> allowed activating this functionality and running the examples easily. The 
> getting started is written based on the profile presence:
> https://apacheignite.readme.io/docs/machine-learning#section-getting-started
> The profile is missing for 2.1 release. To reproduce the issue just download 
> 2.1 binary release and follow the getting started section, you'll stumble on 
> step 4:
> https://apacheignite.readme.io/docs/machine-learning#section-getting-started
> This has to be fixed as soon as possible and the fix should be merged both in 
> the master and in a branch of the urgent Ignite release that is discussed 
> here:
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Urgent-Ignite-bug-fix-release-td21292.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5957) Ignite IGFS: IgfsStreamsSelfTest.testCreateFileColocated fails

[Nikolay Izhikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov reassigned IGNITE-5957:
---

Assignee: Nikolay Izhikov

> Ignite IGFS: IgfsStreamsSelfTest.testCreateFileColocated fails
> --
>
> Key: IGNITE-5957
> URL: https://issues.apache.org/jira/browse/IGNITE-5957
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Nikolay Izhikov
>  Labels: MakeTeamcityGreenAgain, test-failure
> Fix For: 2.3
>
>
> Test is flaky. Success ratio ~50%.
> Exception:
> {noformat}
> junit.framework.AssertionFailedError: expected:<1> but was:<2>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at 
> org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest.testCreateFileColocated(IgfsStreamsSelfTest.java:213)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6256) When a node becomes segmented an AssertionError is thrown during GridDhtPartitionTopologyImpl.removeNode

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov reassigned IGNITE-6256:


Assignee: Andrew Mashenkov  (was: Denis Mekhanikov)

> When a node becomes segmented an AssertionError is thrown during 
> GridDhtPartitionTopologyImpl.removeNode
> 
>
> Key: IGNITE-6256
> URL: https://issues.apache.org/jira/browse/IGNITE-6256
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.8
>Reporter: Alexandr Fedotov
>Assignee: Andrew Mashenkov
> Fix For: 2.3
>
>
> The assert is as follows:
> exception="java.lang.AssertionError: null
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.removeNode(GridDhtPartitionTopologyImpl.java:1422)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:490)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:769)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:504)
>  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1689)
>  at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>  at java.lang.Thread.run(Thread.java:745)
> Below is the sequence of steps that leads to the assertion error:
> 1) A node becomes SEGMENTED when it's determined by SegmentCheckWorker, after 
> an EVT_NODE_FAILED has been received.
> 2) It gets visibleRemoteNodes from it's TcpDiscoveryNodesRing
> 3) Clears the TcpDiscoveryNodesRing leaving only self on the list. The node 
> ring is used to determine if a node is alive
> during DiscoCache creation
> 4) After that, the node initiates removal of all the nodes read in step 2
> 5) For each node, it sends an EVT_NODE_FAILED to the corresponding 
> DiscoverySpiListener
> providing a topology containing all the nodes except already processed
> 6) This event gets into GridDiscoveryManager 
> 7) The node gets removed from alive nodes for every DiscoCache in 
> discoCacheHist
> 8) Topology change is detected
> 9) Creation of a new DiscoCache is attempted. At this moment every remote 
> node is not available due to the
> TcpDiscoveryNodesRing has been cleared, thus resulting in a DiscoCache with 
> empty alives
> 10) The event with the created DiscoCache and the new topology version is 
> passed to DiscoveryWorker
> 11) The event is eventually handled by DiscoveryWorker and is recorded by 
> DiscoveryWorker#recordEvent
> 12) The recording is handled by GridEventStorageManager which notifies every 
> listener for this event type (EVT_NODE_FAILED)
> 13) One of the listeners is GridCachePartitionExchangeManager#discoLsnr
> It creates a new GridDhtPartitionsExchangeFuture with the empty DiscoCache 
> received with the event and enqueues it
> 14) The future gets eventually handled by GridDhtPartitionsExchangeFuture and 
> initialized
> 15) updateTopologies is called, which for each GridCacheContext gets its 
> topology (GridDhtPartitionTopology)
> and calls GridDhtPartitionTopology#updateTopologyVersion
> 16) DiscoCache for GridDhtPartitionTopology is assigned from the one of the 
> GridDhtPartitionsExchangeFuture.
> The assigned DiscoCache has empty alives at the moment
> 15) A distributed exchange is handled 
> (GridDhtPartitionsExchangeFuture#distributedExchange)
> 16) For each cache context GridCacheContext, for its topology 
> (GridDhtPartitionTopologyImpl) GridDhtPartitionTopologyImpl#beforeExchange is 
> called
> 17) The fact that the node has left is determined and 
> GridDhtPartitionTopologyImpl#removeNode is called to handle it
> 18) An attempt is made to get the alive coordinator node by calling 
> DiscoCache#oldestAliveServerNode
> 19) null is returned which results in an AssertionError
> The fix should probably prevent initiating exchange futures if a node has 
> segmented.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6256) When a node becomes segmented an AssertionError is thrown during GridDhtPartitionTopologyImpl.removeNode

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155582#comment-16155582
 ] 

ASF GitHub Bot commented on IGNITE-6256:


GitHub user AMashenkov opened a pull request:

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

IGNITE-6256: DiscoCache should always contains local node.



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

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

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

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


commit 46ca1c6dcc7163a8a997cde7360d48a29c1e482d
Author: Andrey V. Mashenkov 
Date:   2017-09-06T15:33:31Z

IGNITE-6256: DiscoCache always contains local node.




> When a node becomes segmented an AssertionError is thrown during 
> GridDhtPartitionTopologyImpl.removeNode
> 
>
> Key: IGNITE-6256
> URL: https://issues.apache.org/jira/browse/IGNITE-6256
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.8
>Reporter: Alexandr Fedotov
>Assignee: Denis Mekhanikov
> Fix For: 2.3
>
>
> The assert is as follows:
> exception="java.lang.AssertionError: null
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.removeNode(GridDhtPartitionTopologyImpl.java:1422)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:490)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:769)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:504)
>  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1689)
>  at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>  at java.lang.Thread.run(Thread.java:745)
> Below is the sequence of steps that leads to the assertion error:
> 1) A node becomes SEGMENTED when it's determined by SegmentCheckWorker, after 
> an EVT_NODE_FAILED has been received.
> 2) It gets visibleRemoteNodes from it's TcpDiscoveryNodesRing
> 3) Clears the TcpDiscoveryNodesRing leaving only self on the list. The node 
> ring is used to determine if a node is alive
> during DiscoCache creation
> 4) After that, the node initiates removal of all the nodes read in step 2
> 5) For each node, it sends an EVT_NODE_FAILED to the corresponding 
> DiscoverySpiListener
> providing a topology containing all the nodes except already processed
> 6) This event gets into GridDiscoveryManager 
> 7) The node gets removed from alive nodes for every DiscoCache in 
> discoCacheHist
> 8) Topology change is detected
> 9) Creation of a new DiscoCache is attempted. At this moment every remote 
> node is not available due to the
> TcpDiscoveryNodesRing has been cleared, thus resulting in a DiscoCache with 
> empty alives
> 10) The event with the created DiscoCache and the new topology version is 
> passed to DiscoveryWorker
> 11) The event is eventually handled by DiscoveryWorker and is recorded by 
> DiscoveryWorker#recordEvent
> 12) The recording is handled by GridEventStorageManager which notifies every 
> listener for this event type (EVT_NODE_FAILED)
> 13) One of the listeners is GridCachePartitionExchangeManager#discoLsnr
> It creates a new GridDhtPartitionsExchangeFuture with the empty DiscoCache 
> received with the event and enqueues it
> 14) The future gets eventually handled by GridDhtPartitionsExchangeFuture and 
> initialized
> 15) updateTopologies is called, which for each GridCacheContext gets its 
> topology (GridDhtPartitionTopology)
> and calls GridDhtPartitionTopology#updateTopologyVersion
> 16) DiscoCache for GridDhtPartitionTopology is assigned from the one of the 
> GridDhtPartitionsExchangeFuture.
> The assigned DiscoCache has empty alives at the moment
> 15) A distributed exchange is handled 
> (GridDhtPartitionsExchangeFuture#distributedExchange)
> 16) For each cache context GridCacheContext, for its topology 
> (GridDhtPartitionTopologyImpl) GridDhtPartitionTopologyImpl#beforeExchange is 
> called
> 17) The fact that the node has left is determined and 
> GridDhtPartitionTopologyImpl#removeNode is called to handle it
> 18) An attempt is made to get the alive coordinator node by calling 

[jira] [Assigned] (IGNITE-6017) Ignite IGFS: IgfsStreamsSelfTest#testCreateFileFragmented fails

[Nikolay Izhikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov reassigned IGNITE-6017:
---

Assignee: Nikolay Izhikov

> Ignite IGFS: IgfsStreamsSelfTest#testCreateFileFragmented fails
> ---
>
> Key: IGNITE-6017
> URL: https://issues.apache.org/jira/browse/IGNITE-6017
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Nikolay Izhikov
>Priority: Minor
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Failure is almost can't be reproduced locally.
> Suppose it is the same problem as in IGNITE-5957 .
> {noformat}
> junit.framework.AssertionFailedError: expected:<2> but was:<1>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at 
> org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest.testCreateFileFragmented(IgfsStreamsSelfTest.java:264)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> Aug 09, 2017 1:15:56 AM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: DataStreamer operation failed.
> class org.apache.ignite.IgniteCheckedException: Data streamer has been 
> cancelled: DataStreamerImpl 
> [rcvr=org.apache.ignite.internal.processors.datastreamer.DataStreamerCacheUpdaters$BatchedSorted@13c54950,
>  ioPlcRslvr=null, cacheName=igfs-internal-igfs-data, bufSize=512, 
> parallelOps=16, timeout=-1, autoFlushFreq=0, 
> bufMappings={908d1a4c-b352-4af5-b039-ded60c20=Buffer 
> [node=TcpDiscoveryNode [id=908d1a4c-b352-4af5-b039-ded60c20, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1502241356486, loc=true, 
> ver=2.2.0#19700101-sha1:, isClient=false], isLocNode=true, idGen=0, 
> sem=java.util.concurrent.Semaphore@2bdbd7f0[Permits = 16], 
> batchTopVer=AffinityTopologyVersion [topVer=6, minorTopVer=0], entriesCnt=1, 
> locFutsSize=0, reqsSize=0]}, cacheObjProc=GridProcessorAdapter [], 
> cacheObjCtx=org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryContext@6e3de40e,
>  cancelled=true, failCntr=0, activeFuts=GridConcurrentHashSet 
> [elements=[GridFutureAdapter [ignoreInterrupts=false, state=INIT, res=null, 
> hash=431192362], GridFutureAdapter [ignoreInterrupts=false, state=INIT, 
> res=null, hash=625896337], GridFutureAdapter [ignoreInterrupts=false, 
> state=INIT, res=null, hash=1440203156]]], jobPda=null, depCls=null, 
> fut=DataStreamerFuture [super=GridFutureAdapter [ignoreInterrupts=false, 
> state=DONE, res=null, hash=1612913644]], publicFut=IgniteFuture 
> [orig=DataStreamerFuture [super=GridFutureAdapter [ignoreInterrupts=false, 
> state=DONE, res=null, hash=1612913644]]], disconnectErr=null, closed=true, 
> lastFlushTime=1502241356435, skipStore=false, keepBinary=false, 
> maxRemapCnt=32, remapSem=java.util.concurrent.Semaphore@194e0ba1[Permits = 
> 2147483647], remapOwning=false]
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$5.apply(DataStreamerImpl.java:865)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$5.apply(DataStreamerImpl.java:834)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:494)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:473)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:461)
> at 
> 

[jira] [Created] (IGNITE-6285) Enhance persistent store paths logging on start

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-6285:
-

 Summary: Enhance persistent store paths logging on start
 Key: IGNITE-6285
 URL: https://issues.apache.org/jira/browse/IGNITE-6285
 Project: Ignite
  Issue Type: Improvement
Reporter: Yakov Zhdanov


As per this thread - 
http://apache-ignite-users.70518.x6.nabble.com/Specifying-location-of-persistent-storage-location-td16636i20.html

Ignite may switch storage path in case of changing DHCP lease or similar which 
can lead to consistent ID change.

In order to help user in spotting the issue Ignite may output the following to 
the logs:
# Output the store path and tell its (1) size or state that it is empty and (2) 
last data file modification date.
# Output warning if there are other non-empty storage folders under work 
directory with their sizes and dates.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6235) Add ability to handle CacheObject from DataRecord in standalone WAL iterator

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1610#comment-1610
 ] 

ASF GitHub Bot commented on IGNITE-6235:


GitHub user dspavlov opened a pull request:

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

Ignite WAL reader dev tool and related changes

IGNITE-6235: Add ability to handle CacheObject from DataRecord in sta…

IGNITE-6225: Improve tests of WAL iterator with checking DataRecord entries 
and TxRecords

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

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

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

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


commit e9e967c5cf2bfc4022ba0fe43db862c8364f63e8
Author: dpavlov 
Date:   2017-09-06T15:47:18Z

IGNITE-6235: Add ability to handle CacheObject from DataRecord in 
standalone WAL iterator
IGNITE-6225: Improve tests of WAL iterator with checking DataRecord entries 
and TxRecords




> Add ability to handle CacheObject from DataRecord in standalone WAL iterator
> 
>
> Key: IGNITE-6235
> URL: https://issues.apache.org/jira/browse/IGNITE-6235
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
> Fix For: 2.3
>
>
> There was utility class added for WAL iteration under [IGNITE-5558]
> But LazyDataEntry provided by DataRecord does not allow to touch, parse or 
> print entry values.
> It is necessary to improve iterator with ablity to handle data record entries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6284) Add IgniteCompute.withTaskNoResultCache() which should have similar effect as @ComputeTaskNoResultCache

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-6284:
-

 Summary: Add IgniteCompute.withTaskNoResultCache() which should 
have similar effect as @ComputeTaskNoResultCache
 Key: IGNITE-6284
 URL: https://issues.apache.org/jira/browse/IGNITE-6284
 Project: Ignite
  Issue Type: Improvement
  Components: compute
Reporter: Yakov Zhdanov


New method should save threadlocal context as other IgniteCompute.with...() 
methods do and have similar effect as ComputeTaskNoResultCache annotation 
attached to a class.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6130) JDBC Thin: JdbcThinResultSet must support types conversions

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155546#comment-16155546
 ] 

ASF GitHub Bot commented on IGNITE-6130:


Github user asfgit closed the pull request at:

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


> JDBC Thin: JdbcThinResultSet must support types conversions 
> 
>
> Key: IGNITE-6130
> URL: https://issues.apache.org/jira/browse/IGNITE-6130
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> Now JdbcThinResultSet  doesn't support data types transformation.
> e.g.: if the attribute type is SHORT
> all the methods below must return valid value:
> {{getByte, getShort, getInt, getLong, getFloat, getDouble, getBigDecimal, 
> getBoolean, getString, getNString}}
> See the table *B-6* at the JDBC spec (see also [8.9.5 and 
> 8.9.6|http://docs.oracle.com/javase/6/docs/technotes/guides/jdbc/getstart/mapping.html#996857]).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6283) Document ALTER TABLE ADD COLUMN command

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6283:
---

 Summary: Document ALTER TABLE ADD COLUMN command
 Key: IGNITE-6283
 URL: https://issues.apache.org/jira/browse/IGNITE-6283
 Project: Ignite
  Issue Type: Task
  Components: documentation, sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.3






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5572) DDL: Support ALTER TABLE ADD COLUMN

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155518#comment-16155518
 ] 

ASF GitHub Bot commented on IGNITE-5572:


Github user asfgit closed the pull request at:

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


> DDL: Support ALTER TABLE ADD COLUMN
> ---
>
> Key: IGNITE-5572
> URL: https://issues.apache.org/jira/browse/IGNITE-5572
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
>
> We should start gradual implementation of {{ALTER TABLE}} command. Let's 
> start with the most simple part - {{ADD COLUMN}}. Proposed design:
> 1) Send a message over a ring, similar to how we do that for create index
> 2) On local node: update relevant QueryEntity, update data strcutrues in 
> {{GridQueryProcessor}}, update {{IgniteH2Indexing}} data structures, execute 
> {{ALTER TABLE}} command on H2 database (global table lock must be acquired).
> 3) Make sure that update to {{QueryEntity}} is properly saved if persistence 
> is enabled.
> Feature should be covered with tests thoroughly:
> 1) Positive cases
> 2) Negative cases (no schema, no table, column already exists)
> 3) Test with concurrent SQL operations
> 4) Test with concurrent node restarts



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6282) C++: impossible to start node with persistent store

[Irina Zaporozhtseva (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Irina Zaporozhtseva updated IGNITE-6282:

Priority: Blocker  (was: Major)

> C++: impossible to start node with persistent store
> ---
>
> Key: IGNITE-6282
> URL: https://issues.apache.org/jira/browse/IGNITE-6282
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.2
>Reporter: Irina Zaporozhtseva
>Priority: Blocker
>  Labels: C++
> Fix For: 2.2
>
>
> C++: impossible to start node with persistent store. 
> Add to config:
> {code}
>
>class="org.apache.ignite.configuration.PersistentStoreConfiguration"/>
> 
> {code}
> After node started, error message appears:
> {code}
> [17:42:39] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8, 
> heap=0.89GB]
> ERROR: Can not perform the operation because the cluster is inactive. Note, 
> that the cluster is considered inactive by default if Ignite Persistent Store 
> is used to let all the nodes join the cluster. To activate the cluster call 
> Ignite.activate(true).
> {code}
> and after that node is stopped



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6193) ML profile is missing in 2.1 binary release

[Oleg Ignatenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155494#comment-16155494
 ] 

Oleg Ignatenko commented on IGNITE-6193:


(/) TC build passed: 
https://ci.ignite.apache.org/viewLog.html?buildId=813473=buildResultsDiv=IgniteRelease_ZzzFromMirrorIgniteRelease3PrepareVote

(/) generated pom file looks as expected at TC: 
https://ci.ignite.apache.org/repository/download/IgniteRelease_ZzzFromMirrorIgniteRelease3PrepareVote/813473:id/vote/apache-ignite-fabric-2.2.0-ML-bin.zip%21/apache-ignite-fabric-2.2.0-ML-bin/examples/pom.xml
({{ml.folder}} property and {{ml}} profile are present at the right places)

> ML profile is missing in 2.1 binary release
> ---
>
> Key: IGNITE-6193
> URL: https://issues.apache.org/jira/browse/IGNITE-6193
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Oleg Ignatenko
>Priority: Blocker
> Fix For: 2.2
>
>
> In Apache Ignite 2.0 we added the ML profile to the binary release that 
> allowed activating this functionality and running the examples easily. The 
> getting started is written based on the profile presence:
> https://apacheignite.readme.io/docs/machine-learning#section-getting-started
> The profile is missing for 2.1 release. To reproduce the issue just download 
> 2.1 binary release and follow the getting started section, you'll stumble on 
> step 4:
> https://apacheignite.readme.io/docs/machine-learning#section-getting-started
> This has to be fixed as soon as possible and the fix should be merged both in 
> the master and in a branch of the urgent Ignite release that is discussed 
> here:
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Urgent-Ignite-bug-fix-release-td21292.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5789) After client reconnects to server if server was restarted, client doesn't create caches defined in client's configuration

[vk (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

vk reassigned IGNITE-5789:
--

Assignee: vk

> After client reconnects to server if server was restarted, client doesn't 
> create caches defined in client's configuration
> -
>
> Key: IGNITE-5789
> URL: https://issues.apache.org/jira/browse/IGNITE-5789
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Evgenii Zhuravlev
>Assignee: vk
> Fix For: 2.3
>
> Attachments: ClientReconnectAfterClusterRestartTest.java
>
>
> User with this problem on SO:
> https://stackoverflow.com/questions/46053089/ignite-cache-reconnection-issue-cache-is-stopped



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6282) C++: impossible to start node with persistent store

[Irina Zaporozhtseva (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Irina Zaporozhtseva updated IGNITE-6282:

Description: 
C++: impossible to start node with persistent store. 

Add to config:

{code}
   
  

{code}


After node started, error message appears:


{code}
[17:42:39] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8, heap=0.89GB]
ERROR: Can not perform the operation because the cluster is inactive. Note, 
that the cluster is considered inactive by default if Ignite Persistent Store 
is used to let all the nodes join the cluster. To activate the cluster call 
Ignite.activate(true).
{code}


and after that node is stopped

  was:
C++: impossible to start node with persistent store. 

Add to config:
   
  


After node started, error message appears:

{{[17:42:39] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8, 
heap=0.89GB]
ERROR: Can not perform the operation because the cluster is inactive. Note, 
that the cluster is considered inactive by default if Ignite Persistent Store 
is used to let all the nodes join the cluster. To activate the cluster call 
Ignite.activate(true).}}

and after that node is stopped


> C++: impossible to start node with persistent store
> ---
>
> Key: IGNITE-6282
> URL: https://issues.apache.org/jira/browse/IGNITE-6282
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.2
>Reporter: Irina Zaporozhtseva
>  Labels: C++
> Fix For: 2.2
>
>
> C++: impossible to start node with persistent store. 
> Add to config:
> {code}
>
>class="org.apache.ignite.configuration.PersistentStoreConfiguration"/>
> 
> {code}
> After node started, error message appears:
> {code}
> [17:42:39] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8, 
> heap=0.89GB]
> ERROR: Can not perform the operation because the cluster is inactive. Note, 
> that the cluster is considered inactive by default if Ignite Persistent Store 
> is used to let all the nodes join the cluster. To activate the cluster call 
> Ignite.activate(true).
> {code}
> and after that node is stopped



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6282) C++: impossible to start node with persistent store

[Irina Zaporozhtseva (JIRA)]

Irina Zaporozhtseva created IGNITE-6282:
---

 Summary: C++: impossible to start node with persistent store
 Key: IGNITE-6282
 URL: https://issues.apache.org/jira/browse/IGNITE-6282
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.2
Reporter: Irina Zaporozhtseva
 Fix For: 2.2


C++: impossible to start node with persistent store. 

Add to config:
   
  


After node started, error message appears:

{{[17:42:39] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8, 
heap=0.89GB]
ERROR: Can not perform the operation because the cluster is inactive. Note, 
that the cluster is considered inactive by default if Ignite Persistent Store 
is used to let all the nodes join the cluster. To activate the cluster call 
Ignite.activate(true).}}

and after that node is stopped



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6120) Web Console: Propagate "lazy" flag on Query screen

[Mikhail Cherkasov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155479#comment-16155479
 ] 

Mikhail Cherkasov commented on IGNITE-6120:
---

Why was it closed if there are no changes in the master repo?

> Web Console: Propagate "lazy" flag on Query screen
> --
>
> Key: IGNITE-6120
> URL: https://issues.apache.org/jira/browse/IGNITE-6120
> Project: Ignite
>  Issue Type: Task
>  Components: sql, wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6280) Cassandra ignores AffinityKeyMapped annotation in parent classes.

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-6280:
-
Attachment: CassandraConfigTest.java

> Cassandra ignores AffinityKeyMapped annotation in parent classes.
> -
>
> Key: IGNITE-6280
> URL: https://issues.apache.org/jira/browse/IGNITE-6280
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
> Fix For: 2.3
>
> Attachments: CassandraConfigTest.java
>
>
> By default, using @AffinityKeyMapped annotation force Ignire to override user 
> _keyPersistence_ configuration that may cause confusing results.
> PFA repro attached.
> h3. Description
> 1. Let there is 2 keys A and B that has same fields with one difference. Key 
> A has affinity key in parent class. So, it looks like this.
> {code}
> class BaseKey {
> @AffinityKeyMapped
>  Object affinityKey
> }
> {code}
> {code}
> class A extends BaseKey {
>  int id;
> }
> {code}
> {code}
> class B {
> @AffinityKeyMapped
>  Object affinityKey;
>  int uid;
> }
> {code}
> 2. Let we make different affinity mapping for Cassandra store, that looks 
> like a valid case
> {code:xml}
> 
> 
>  
>  
>
> 
> {code}
> 3. We have different behavior for these similar cases that makes user 
> confused.
> For key A this will work fine and expected DDL will be generated.
> For key B we'll get different DDL as Ignite will remove "_uid_" field from 
> "_partitionKey_".
> So, we should either to not allow Ignite to override key mapping or force 
> Ignite to check if parent classes has @AffinityKeyMapped annotation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6281) Cluster Automatic Activation

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-6281:
---

 Summary: Cluster Automatic Activation
 Key: IGNITE-6281
 URL: https://issues.apache.org/jira/browse/IGNITE-6281
 Project: Ignite
  Issue Type: Improvement
Reporter: Sergey Chugunov


h2. Motivation and use cases
Existing activation functionality allows user to perform start/stop operations 
on persistent-enabled grids without excessive and unnecessary rebalancing 
operations.

Improvement for automatic actiovation simplifies activation process freeing 
user from manual grid activation after each restart (or building custom 
environment management tools).

Main use case looks like this: user provides information about target grid 
topology (number of nodes, IP addresses/ports, etc.); this information is 
stored on the first start. Later based on this  grid is activated automatically 
after restart when that topology is reached.

More information is available in [the 
discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Cluster-auto-activation-design-proposal-tt20295.html]
 in dev list.

h2. Notes
This JIRA is used as a root for more specific tickets covering particular 
aspects of the functionality.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6281) Cluster Automatic Activation

[Sergey Chugunov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Chugunov updated IGNITE-6281:

Component/s: persistence

> Cluster Automatic Activation
> 
>
> Key: IGNITE-6281
> URL: https://issues.apache.org/jira/browse/IGNITE-6281
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Sergey Chugunov
> Fix For: 2.3
>
>
> h2. Motivation and use cases
> Existing activation functionality allows user to perform start/stop 
> operations on persistent-enabled grids without excessive and unnecessary 
> rebalancing operations.
> Improvement for automatic actiovation simplifies activation process freeing 
> user from manual grid activation after each restart (or building custom 
> environment management tools).
> Main use case looks like this: user provides information about target grid 
> topology (number of nodes, IP addresses/ports, etc.); this information is 
> stored on the first start. Later based on this  grid is activated 
> automatically after restart when that topology is reached.
> More information is available in [the 
> discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Cluster-auto-activation-design-proposal-tt20295.html]
>  in dev list.
> h2. Notes
> This JIRA is used as a root for more specific tickets covering particular 
> aspects of the functionality.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6281) Cluster Automatic Activation

[Sergey Chugunov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Chugunov updated IGNITE-6281:

Fix Version/s: 2.3

> Cluster Automatic Activation
> 
>
> Key: IGNITE-6281
> URL: https://issues.apache.org/jira/browse/IGNITE-6281
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Sergey Chugunov
> Fix For: 2.3
>
>
> h2. Motivation and use cases
> Existing activation functionality allows user to perform start/stop 
> operations on persistent-enabled grids without excessive and unnecessary 
> rebalancing operations.
> Improvement for automatic actiovation simplifies activation process freeing 
> user from manual grid activation after each restart (or building custom 
> environment management tools).
> Main use case looks like this: user provides information about target grid 
> topology (number of nodes, IP addresses/ports, etc.); this information is 
> stored on the first start. Later based on this  grid is activated 
> automatically after restart when that topology is reached.
> More information is available in [the 
> discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Cluster-auto-activation-design-proposal-tt20295.html]
>  in dev list.
> h2. Notes
> This JIRA is used as a root for more specific tickets covering particular 
> aspects of the functionality.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5339) JDBC thin driver: validate compliance

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155446#comment-16155446
 ] 

ASF GitHub Bot commented on IGNITE-5339:


Github user asfgit closed the pull request at:

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


> JDBC thin driver: validate compliance
> -
>
> Key: IGNITE-5339
> URL: https://issues.apache.org/jira/browse/IGNITE-5339
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> We need to make sure that all methods of our new driver are compliant with 
> JDBC spec, namely:
> 1) Semantics of normal execution is correct
> 2) Exceptions are thrown when excepted
> I propose the following flow:
> 1) Walk through interface classes (Connection -> Statement, PreparedStatement 
> -> ResultSet)
> 2) For every method identify a set of tests to verify semantics (if any).
> 3) Write those tests, even if they fail.
> 4) Once all tests are ready, decide how to proceed with their fixes.
> NB: we should write tests even for methods which throw "not-implemented 
> exception", so that we better understand the scope of remaining work.
> Link to [JDBC 
> specification|http://download.oracle.com/otn-pub/jcp/jdbc-4_1-mrel-spec/jdbc4.1-fr-spec.pdf?AuthParam=1496141650_c2ec45f13eb8c532632bbfaede64f351]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5339) JDBC thin driver: validate compliance

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-5339:

Labels:   (was: important)

> JDBC thin driver: validate compliance
> -
>
> Key: IGNITE-5339
> URL: https://issues.apache.org/jira/browse/IGNITE-5339
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> We need to make sure that all methods of our new driver are compliant with 
> JDBC spec, namely:
> 1) Semantics of normal execution is correct
> 2) Exceptions are thrown when excepted
> I propose the following flow:
> 1) Walk through interface classes (Connection -> Statement, PreparedStatement 
> -> ResultSet)
> 2) For every method identify a set of tests to verify semantics (if any).
> 3) Write those tests, even if they fail.
> 4) Once all tests are ready, decide how to proceed with their fixes.
> NB: we should write tests even for methods which throw "not-implemented 
> exception", so that we better understand the scope of remaining work.
> Link to [JDBC 
> specification|http://download.oracle.com/otn-pub/jcp/jdbc-4_1-mrel-spec/jdbc4.1-fr-spec.pdf?AuthParam=1496141650_c2ec45f13eb8c532632bbfaede64f351]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6245) ODBC: Driver should return affected rows number for non-batch DML queries as well.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155438#comment-16155438
 ] 

ASF GitHub Bot commented on IGNITE-6245:


GitHub user isapego opened a pull request:

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

IGNITE-6245: Implemented returning of the number of affected rows for ODBC 
driver.



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

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

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

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






> ODBC: Driver should return affected rows number for non-batch DML queries as 
> well.
> --
>
> Key: IGNITE-6245
> URL: https://issues.apache.org/jira/browse/IGNITE-6245
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>Assignee: Igor Sapego
> Fix For: 2.3
>
>
> Looks like {{OdbcQueryExecuteResult}} class doesn't have {{rowAffected}} 
> field that {{OdbcQueryExecuteBatchResult}} has.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6171) Native facility to control excessive GC pauses

[Yakov Zhdanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yakov Zhdanov updated IGNITE-6171:
--
Labels: usability  (was: )

> Native facility to control excessive GC pauses
> --
>
> Key: IGNITE-6171
> URL: https://issues.apache.org/jira/browse/IGNITE-6171
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>  Labels: usability
> Fix For: 2.3
>
>
> Ignite is Java-based application. If node experiences long GC pauses it may 
> negatively affect other nodes. We need to find a way to detect long GC pauses 
> within the process and trigger some actions in response, e.g. node stop. 
> This is a kind of Inception \[1\], when you need to understand that you sleep 
> while sleeping. As all Java threads are blocked on safepoint, we cannot use 
> Java's thread to detect Java's GC. Native threads should be used instead.
> Proposed solution:
> 1) Thread 1 should periodically call dummy JNI method returning current time, 
> and set this time to shared variable;
> 2) Thread 2 should periodically check that variable. If it has not been 
> changed for some time - most likely we are in GC pause. Once certain 
> threashold is reached - trigger compensating action, whether this is a 
> warning, process kill, or what so ever.
> Justification: crossing native -> Java boundaries involves safepoints. This 
> way Thread 1 will be trapped if STW pause is in progress. Java method cannot 
> be empty, as JVM is smart enough and can deduce it to no-op. 
> \[1\] http://www.imdb.com/title/tt1375666/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6134) Need to check node local map on class loader undeploy

[Yakov Zhdanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yakov Zhdanov updated IGNITE-6134:
--
Labels: newbie  (was: )

> Need to check node local map on class loader undeploy
> -
>
> Key: IGNITE-6134
> URL: https://issues.apache.org/jira/browse/IGNITE-6134
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Yakov Zhdanov
>  Labels: newbie
>
> When deployment gets undeployed we also need to scan local map and remove 
> key-value pairs where at least key or entry are loaded with classloader being 
> undeployed.
> Please see method these methods:
> * 
> org.apache.ignite.internal.managers.deployment.GridDeploymentPerLoaderStore.IsolatedDeployment#recordUndeployed
> * 
> org.apache.ignite.internal.managers.deployment.GridDeploymentPerVersionStore.SharedDeployment#recordUndeployed



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6193) ML profile is missing in 2.1 binary release

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155417#comment-16155417
 ] 

ASF GitHub Bot commented on IGNITE-6193:


GitHub user oignatenko opened a pull request:

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

IGNITE-6193 ML profile is missing in 2.1 binary release



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

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

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

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


commit 737874f65d2aa143a79dd5f6b0d223e07a4eceee
Author: Ivan Rakov 
Date:   2017-08-29T10:24:20Z

IGNITE-6204 Backport optimizations of checkpointing algorithm into 2.2

commit abb675f3355494b1f1ab502718aa0ad2249cb78b
Author: Pavel Tupitsyn 
Date:   2017-08-29T15:35:49Z

IGNITE-6204 Backport optimizations of checkpointing algorithm into 2.2 
(hotfix)

commit c06ceba8d014ded7519a37583cb8914f2ef064d9
Author: Oleg Ignatenko 
Date:   2017-08-30T11:15:32Z

IGNITE-6193 ML profile is missing in 2.1 binary release

commit d51171f11a566d0019b7482d990afc23eccc9f05
Author: Igor Seliverstov 
Date:   2017-09-01T09:48:38Z

IGNITE-6182 Change default max memory size from 80% to 20%

commit 1fb2fe04fd5e08bac16e79f572893f2fa7a3ad38
Author: devozerov 
Date:   2017-09-04T14:41:30Z

IGNITE-6182: Improved message.

commit 94641a9313342bdb7782690f0df6f076bc400df8
Author: oleg-ostanin 
Date:   2017-09-05T10:50:55Z

IGNITE-5817 deleted deploy-ignite sources profile

commit e469ab6861202e88fc066608870e4a6ae2c3424e
Author: Igor Sapego 
Date:   2017-07-27T16:39:51Z

IGNITE-5771: Added Ignite::SetActive() for C++

(cherry picked from commit 47fea40)

commit be126e1eee4a2d6d997213d8d705733933bb0d01
Author: Oleg Ignatenko 
Date:   2017-09-06T13:57:02Z

IGNITE-6193 ML profile is missing in 2.1 binary release
- porting changes to standalone and lgpl pom files from regular one
-- verified with diffs overview




> ML profile is missing in 2.1 binary release
> ---
>
> Key: IGNITE-6193
> URL: https://issues.apache.org/jira/browse/IGNITE-6193
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Oleg Ignatenko
>Priority: Blocker
> Fix For: 2.2
>
>
> In Apache Ignite 2.0 we added the ML profile to the binary release that 
> allowed activating this functionality and running the examples easily. The 
> getting started is written based on the profile presence:
> https://apacheignite.readme.io/docs/machine-learning#section-getting-started
> The profile is missing for 2.1 release. To reproduce the issue just download 
> 2.1 binary release and follow the getting started section, you'll stumble on 
> step 4:
> https://apacheignite.readme.io/docs/machine-learning#section-getting-started
> This has to be fixed as soon as possible and the fix should be merged both in 
> the master and in a branch of the urgent Ignite release that is discussed 
> here:
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Urgent-Ignite-bug-fix-release-td21292.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5061) Add ability to enable and disable rebalancing per-node

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155418#comment-16155418
 ] 

Andrey Gura commented on IGNITE-5061:
-

Merged to master branch.

> Add ability to enable and disable rebalancing per-node
> --
>
> Key: IGNITE-5061
> URL: https://issues.apache.org/jira/browse/IGNITE-5061
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Alexander Belyak
> Fix For: 2.3
>
>
> It would be nice to have an ability to enable and disable rebalancing per 
> node. 
> First of all, we need to come up with a simple API to allow this. 
> Corresponding methods most likely should be also added to Ignite MBean.
> We need to discuss on the dev-list whether it is enough to have this setting 
> per-node, or this needs to be done on a per-cache basis.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6277) Convert WAL to human readable form

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-6277:
---
Component/s: persistence

> Convert WAL to human readable form
> --
>
> Key: IGNITE-6277
> URL: https://issues.apache.org/jira/browse/IGNITE-6277
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
> Fix For: 2.3
>
>
> Now there is no way to make wal visible or understandable without coding.
> I propose to write utility which would convert any given compatible WAL to 
> textual form.
> Something like this:
> {code}
> [W] InsertRecord [idx=19, io=H2ExtrasLeafIO[ver=1], rightId=, 
> super=PageDeltaRecord [grpId=2141373875, pageId=00020011, 
> super=WALRecord [size=61, chainSize=0, pos=FileWALPointer [idx=0, 
> fileOffset=2504497, len=61, forceFlush=false], type=BTREE_PAGE_INSERT]]]
> [W] DataRecord [writeEntries=[DataEntry [op=CREATE, writeVer=GridCacheVersion 
> [topVer=116006687, order=0, nodeOrder=1], partId=29, partCnt=33]], 
> super=WALRecord [size=171, chainSize=0, pos=FileWALPointer [idx=0, 
> fileOffset=2504558, len=171, forceFlush=false], type=DATA_RECORD]]
> [W] PagesListRemovePageRecord [rmvdPageId=0001000c002f, 
> pageId=0001000c000a, grpId=-1368047377, super=PageDeltaRecord 
> [grpId=-1368047377, pageId=0001000c000a, super=WALRecord [size=37, 
> chainSize=0, pos=FileWALPointer [idx=0, fileOffset=2504729, len=37, 
> forceFlush=false], type=PAGES_LIST_REMOVE_PAGE]]]
> [W] DataPageInsertRecord [super=PageDeltaRecord [grpId=-1368047377, 
> pageId=0001000c002f, super=WALRecord [size=76, chainSize=0, 
> pos=FileWALPointer [idx=0, fileOffset=2504766, len=76, forceFlush=false], 
> type=DATA_PAGE_INSERT_RECORD]]]
> [W] PagesListAddPageRecord [dataPageId=0001000c002f, 
> super=PageDeltaRecord [grpId=-1368047377, pageId=0001000c000b, 
> super=WALRecord [size=37, chainSize=0, pos=FileWALPointer [idx=0, 
> fileOffset=2504842, len=37, forceFlush=false], type=PAGES_LIST_ADD_PAGE]]]
> [W] DataPageSetFreeListPageRecord [freeListPage=281526516318219, 
> super=PageDeltaRecord [grpId=-1368047377, pageId=0001000c002f, 
> super=WALRecord [size=37, chainSize=0, pos=FileWALPointer [idx=0, 
> fileOffset=2504879, len=37, forceFlush=false], 
> type=DATA_PAGE_SET_FREE_LIST_PAGE]]]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6253) .NET: Replace Doxygen with DocFX for API documentation generation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155380#comment-16155380
 ] 

ASF GitHub Bot commented on IGNITE-6253:


Github user asfgit closed the pull request at:

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


> .NET: Replace Doxygen with DocFX for API documentation generation
> -
>
> Key: IGNITE-6253
> URL: https://issues.apache.org/jira/browse/IGNITE-6253
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Doxygen has recently became very slow on our code base (can take up to 30 
> minutes), and there seems to be no solution to this problem. There are other 
> issues: documentation is a bit ugly, customization possibilities are limited, 
> C# is not a first-class citizen there.
> [DocFX|https://dotnet.github.io/docfx/] looks like an obvious replacement:
> * It is a go-to documentation generator for .NET (included in .NET Foundation)
> * Documentation looks nice (MSDN-like) out of the box
> * Migration seems to be easy enough



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6277) Convert WAL to human readable form

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-6277:
---
Affects Version/s: 2.1

> Convert WAL to human readable form
> --
>
> Key: IGNITE-6277
> URL: https://issues.apache.org/jira/browse/IGNITE-6277
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
> Fix For: 2.3
>
>
> Now there is no way to make wal visible or understandable without coding.
> I propose to write utility which would convert any given compatible WAL to 
> textual form.
> Something like this:
> {code}
> [W] InsertRecord [idx=19, io=H2ExtrasLeafIO[ver=1], rightId=, 
> super=PageDeltaRecord [grpId=2141373875, pageId=00020011, 
> super=WALRecord [size=61, chainSize=0, pos=FileWALPointer [idx=0, 
> fileOffset=2504497, len=61, forceFlush=false], type=BTREE_PAGE_INSERT]]]
> [W] DataRecord [writeEntries=[DataEntry [op=CREATE, writeVer=GridCacheVersion 
> [topVer=116006687, order=0, nodeOrder=1], partId=29, partCnt=33]], 
> super=WALRecord [size=171, chainSize=0, pos=FileWALPointer [idx=0, 
> fileOffset=2504558, len=171, forceFlush=false], type=DATA_RECORD]]
> [W] PagesListRemovePageRecord [rmvdPageId=0001000c002f, 
> pageId=0001000c000a, grpId=-1368047377, super=PageDeltaRecord 
> [grpId=-1368047377, pageId=0001000c000a, super=WALRecord [size=37, 
> chainSize=0, pos=FileWALPointer [idx=0, fileOffset=2504729, len=37, 
> forceFlush=false], type=PAGES_LIST_REMOVE_PAGE]]]
> [W] DataPageInsertRecord [super=PageDeltaRecord [grpId=-1368047377, 
> pageId=0001000c002f, super=WALRecord [size=76, chainSize=0, 
> pos=FileWALPointer [idx=0, fileOffset=2504766, len=76, forceFlush=false], 
> type=DATA_PAGE_INSERT_RECORD]]]
> [W] PagesListAddPageRecord [dataPageId=0001000c002f, 
> super=PageDeltaRecord [grpId=-1368047377, pageId=0001000c000b, 
> super=WALRecord [size=37, chainSize=0, pos=FileWALPointer [idx=0, 
> fileOffset=2504842, len=37, forceFlush=false], type=PAGES_LIST_ADD_PAGE]]]
> [W] DataPageSetFreeListPageRecord [freeListPage=281526516318219, 
> super=PageDeltaRecord [grpId=-1368047377, pageId=0001000c002f, 
> super=WALRecord [size=37, chainSize=0, pos=FileWALPointer [idx=0, 
> fileOffset=2504879, len=37, forceFlush=false], 
> type=DATA_PAGE_SET_FREE_LIST_PAGE]]]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (IGNITE-6193) ML profile is missing in 2.1 binary release

[Oleg Ignatenko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Ignatenko reopened IGNITE-6193:


need to port ml-profile related changes from plain examples pom into 
pom-standalone and pom-standalone-lgpl in order to complete this task

> ML profile is missing in 2.1 binary release
> ---
>
> Key: IGNITE-6193
> URL: https://issues.apache.org/jira/browse/IGNITE-6193
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Oleg Ignatenko
>Priority: Blocker
> Fix For: 2.2
>
>
> In Apache Ignite 2.0 we added the ML profile to the binary release that 
> allowed activating this functionality and running the examples easily. The 
> getting started is written based on the profile presence:
> https://apacheignite.readme.io/docs/machine-learning#section-getting-started
> The profile is missing for 2.1 release. To reproduce the issue just download 
> 2.1 binary release and follow the getting started section, you'll stumble on 
> step 4:
> https://apacheignite.readme.io/docs/machine-learning#section-getting-started
> This has to be fixed as soon as possible and the fix should be merged both in 
> the master and in a branch of the urgent Ignite release that is discussed 
> here:
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Urgent-Ignite-bug-fix-release-td21292.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6253) .NET: Replace Doxygen with DocFX for API documentation generation

[Pavel Tupitsyn (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155376#comment-16155376
 ] 

Pavel Tupitsyn commented on IGNITE-6253:


Merged to master: {{b08eef240364f4ecf639aba36a8f59d5607a205b}}.

> .NET: Replace Doxygen with DocFX for API documentation generation
> -
>
> Key: IGNITE-6253
> URL: https://issues.apache.org/jira/browse/IGNITE-6253
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Doxygen has recently became very slow on our code base (can take up to 30 
> minutes), and there seems to be no solution to this problem. There are other 
> issues: documentation is a bit ugly, customization possibilities are limited, 
> C# is not a first-class citizen there.
> [DocFX|https://dotnet.github.io/docfx/] looks like an obvious replacement:
> * It is a go-to documentation generator for .NET (included in .NET Foundation)
> * Documentation looks nice (MSDN-like) out of the box
> * Migration seems to be easy enough



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6254) Assertion error in IgniteTxHandler.processDhtTxFinishRequest(...)

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155363#comment-16155363
 ] 

Andrey Gura commented on IGNITE-6254:
-

LGTM! Merged to master branch.

> Assertion error in IgniteTxHandler.processDhtTxFinishRequest(...)
> -
>
> Key: IGNITE-6254
> URL: https://issues.apache.org/jira/browse/IGNITE-6254
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Andrey Gura
> Fix For: 2.3
>
>
> AssertionError is thrown in the end of this method:
> {noformat}
> assert req.txState() != null || (ctx.tm().tx(req.version()) == null && 
> ctx.tm().nearTx(req.version()) == null);
> {noformat}
> This could happen only if results of calls to IgniteTxManager changed after 
> method execution started. We should re-use already aquired values:
> - replace ctx.tm().tx(...) call with dhtTx;
> - replace ctx.tml().nearTx(...) call with nearTx.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6280) Cassandra ignores AffinityKeyMapped annotation in parent classes.

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-6280:
-
Fix Version/s: 2.3

> Cassandra ignores AffinityKeyMapped annotation in parent classes.
> -
>
> Key: IGNITE-6280
> URL: https://issues.apache.org/jira/browse/IGNITE-6280
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
> Fix For: 2.3
>
>
> By default, using @AffinityKeyMapped annotation force Ignire to override user 
> _keyPersistence_ configuration that may cause confusing results.
> PFA repro attached.
> h3. Description
> 1. Let there is 2 keys A and B that has same fields with one difference. Key 
> A has affinity key in parent class. So, it looks like this.
> {code}
> class BaseKey {
> @AffinityKeyMapped
>  Object affinityKey
> }
> {code}
> {code}
> class A extends BaseKey {
>  int id;
> }
> {code}
> {code}
> class B {
> @AffinityKeyMapped
>  Object affinityKey;
>  int uid;
> }
> {code}
> 2. Let we make different affinity mapping for Cassandra store, that looks 
> like a valid case
> {code:xml}
> 
> 
>  
>  
>
> 
> {code}
> 3. We have different behavior for these similar cases that makes user 
> confused.
> For key A this will work fine and expected DDL will be generated.
> For key B we'll get different DDL as Ignite will remove "_uid_" field from 
> "_partitionKey_".
> So, we should either to not allow Ignite to override key mapping or force 
> Ignite to check if parent classes has @AffinityKeyMapped annotation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6279) .NET: Decouple AbstractQueryCursor from PlatformTarget data exchange specifics

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155324#comment-16155324
 ] 

ASF GitHub Bot commented on IGNITE-6279:


Github user asfgit closed the pull request at:

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


> .NET: Decouple AbstractQueryCursor from PlatformTarget data exchange specifics
> --
>
> Key: IGNITE-6279
> URL: https://issues.apache.org/jira/browse/IGNITE-6279
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> {{AbstractQueryCursor}} should be concerned only with iterator and cursor 
> logic. Data exchange should be factored out. This will simplify code reuse 
> for thin client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-6279) .NET: Decouple AbstractQueryCursor from PlatformTarget data exchange specifics

[Pavel Tupitsyn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn resolved IGNITE-6279.

Resolution: Fixed

> .NET: Decouple AbstractQueryCursor from PlatformTarget data exchange specifics
> --
>
> Key: IGNITE-6279
> URL: https://issues.apache.org/jira/browse/IGNITE-6279
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> {{AbstractQueryCursor}} should be concerned only with iterator and cursor 
> logic. Data exchange should be factored out. This will simplify code reuse 
> for thin client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6279) .NET: Decouple AbstractQueryCursor from PlatformTarget data exchange specifics

[Pavel Tupitsyn (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155321#comment-16155321
 ] 

Pavel Tupitsyn commented on IGNITE-6279:


Merged to master: {{e66b98b419a90ecbb255d07e17f184c1834837bd}}.

> .NET: Decouple AbstractQueryCursor from PlatformTarget data exchange specifics
> --
>
> Key: IGNITE-6279
> URL: https://issues.apache.org/jira/browse/IGNITE-6279
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> {{AbstractQueryCursor}} should be concerned only with iterator and cursor 
> logic. Data exchange should be factored out. This will simplify code reuse 
> for thin client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6280) Cassandra ignores AffinityKeyMapped annotation in parent classes.

[Andrew Mashenkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155302#comment-16155302
 ] 

Andrew Mashenkov commented on IGNITE-6280:
--

[~irudyak],

Would you please take a look at this and suggest correct way it can be fixed? 

Why we override key mapping when AffinityKeyMapped annotation is used, if
it as valid case to have alternative key affinity mapping for cassandra store
and keyPersistence configuration is mandatory.

May be I've missed smth...?




> Cassandra ignores AffinityKeyMapped annotation in parent classes.
> -
>
> Key: IGNITE-6280
> URL: https://issues.apache.org/jira/browse/IGNITE-6280
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>
> By default, using @AffinityKeyMapped annotation force Ignire to override user 
> _keyPersistence_ configuration that may cause confusing results.
> PFA repro attached.
> h3. Description
> 1. Let there is 2 keys A and B that has same fields with one difference. Key 
> A has affinity key in parent class. So, it looks like this.
> {code}
> class BaseKey {
> @AffinityKeyMapped
>  Object affinityKey
> }
> {code}
> {code}
> class A extends BaseKey {
>  int id;
> }
> {code}
> {code}
> class B {
> @AffinityKeyMapped
>  Object affinityKey;
>  int uid;
> }
> {code}
> 2. Let we make different affinity mapping for Cassandra store, that looks 
> like a valid case
> {code:xml}
> 
> 
>  
>  
>
> 
> {code}
> 3. We have different behavior for these similar cases that makes user 
> confused.
> For key A this will work fine and expected DDL will be generated.
> For key B we'll get different DDL as Ignite will remove "_uid_" field from 
> "_partitionKey_".
> So, we should either to not allow Ignite to override key mapping or force 
> Ignite to check if parent classes has @AffinityKeyMapped annotation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-2779) BinaryMarshaller caches must be cleaned during client reconnect.

[Sergey Chugunov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155301#comment-16155301
 ] 

Sergey Chugunov commented on IGNITE-2779:
-

[~avinogradov], changes look good to me as well, TC state is fine as well. We 
may proceed with merging this change.

> BinaryMarshaller caches must be cleaned during client reconnect.
> 
>
> Key: IGNITE-2779
> URL: https://issues.apache.org/jira/browse/IGNITE-2779
> Project: Ignite
>  Issue Type: Task
>  Components: cache, general
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Amelchev Nikita
>  Labels: community
> Fix For: 2.3
>
> Attachments: IgniteProblemTest.java
>
>
> The problem is originally reported by Vinay Sharma here: 
> http://apache-ignite-users.70518.x6.nabble.com/changed-cache-configuration-and-restarted-server-nodes-Getting-exception-td3064.html#none
> *Root cause*:
> When client is reconnected to topology after full topology restart (i.e. all 
> server nodes were down), it doesn't re-send binary metadata to topology. As a 
> result, {{BinaryMarshaller}} exception occurs.
> *Steps to reproduce*
> Run attached code.
> *Proposed solution*
> Clean cached binary metadata during re-connect.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6280) Cassandra ignores AffinityKeyMapped annotation in parent classes.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-6280:


 Summary: Cassandra ignores AffinityKeyMapped annotation in parent 
classes.
 Key: IGNITE-6280
 URL: https://issues.apache.org/jira/browse/IGNITE-6280
 Project: Ignite
  Issue Type: Bug
  Components: cassandra
Affects Versions: 2.1
Reporter: Andrew Mashenkov


By default, using @AffinityKeyMapped annotation force Ignire to override user 
_keyPersistence_ configuration that may cause confusing results.

PFA repro attached.

h3. Description
1. Let there is 2 keys A and B that has same fields with one difference. Key A 
has affinity key in parent class. So, it looks like this.

{code}
class BaseKey {
@AffinityKeyMapped
 Object affinityKey
}
{code}

{code}
class A extends BaseKey {
 int id;
}
{code}

{code}
class B {
@AffinityKeyMapped
 Object affinityKey;

 int uid;
}
{code}

2. Let we make different affinity mapping for Cassandra store, that looks like 
a valid case
{code:xml}


 
 
   

{code}

3. We have different behavior for these similar cases that makes user confused.
For key A this will work fine and expected DDL will be generated.
For key B we'll get different DDL as Ignite will remove "_uid_" field from 
"_partitionKey_".

So, we should either to not allow Ignite to override key mapping or force 
Ignite to check if parent classes has @AffinityKeyMapped annotation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6276) SQL: Investigate parser generators

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-6276:

Fix Version/s: 2.3

> SQL: Investigate parser generators
> --
>
> Key: IGNITE-6276
> URL: https://issues.apache.org/jira/browse/IGNITE-6276
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
> Fix For: 2.3
>
>
> Now ignite relies on H2 for SQL processing. It has been discussed many times 
> on dev list that we must start introducing our own SQL core in small 
> incremental steps. 
> Let's start with analyzing the options for implementing the parser part.
> We may begin with http://www.antlr.org/ and create a simple separate project 
> that would generate the parser for some simple DDL commands like DROP INDEX.
> This will give us a hint on the complexity and limitations of the approach.
> 1) Set up Maven/ANTLR.
> 2) Prepare lexer/parser.
> 3) Generate.
> 4) Write a test.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6014) Add transaction prepare and commit markers to WAL

[Pavel Kovalenko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Kovalenko reassigned IGNITE-6014:
---

Assignee: Ilya Lantukh  (was: Pavel Kovalenko)

> Add transaction prepare and commit markers to WAL
> -
>
> Key: IGNITE-6014
> URL: https://issues.apache.org/jira/browse/IGNITE-6014
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
> Fix For: 2.3
>
>
> This may be useful for various recovery procedures in the future



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6029) Refactor WAL Record serialization and introduce RecordV2Serializer

[Pavel Kovalenko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Kovalenko reassigned IGNITE-6029:
---

Assignee: Andrey Gura  (was: Pavel Kovalenko)

> Refactor WAL Record serialization and introduce RecordV2Serializer
> --
>
> Key: IGNITE-6029
> URL: https://issues.apache.org/jira/browse/IGNITE-6029
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Andrey Gura
> Fix For: 2.3
>
>
> Currently RecordSerializer interface and default RecordV1Serializer 
> implementation are not well extendable. We should refactor RecordSerializer 
> interface and introduce new RecordV2Serializer with very base functionality - 
> delegate everything to RecordV1Serializer.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6279) .NET: Decouple AbstractQueryCursor from PlatformTarget data exchange specifics

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155293#comment-16155293
 ] 

ASF GitHub Bot commented on IGNITE-6279:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-6279 .NET: Decouple AbstractQueryCursor from PlatformTarget data 
exchange specifics



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

$ git pull https://github.com/ptupitsyn/ignite ignite-6279

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

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


commit 94ea55dc836795efcfacfc7ca01192c33083abeb
Author: Pavel Tupitsyn 
Date:   2017-09-06T12:42:47Z

IGNITE-6279 .NET: Decouple AbstractQueryCursor from PlatformTarget data 
exchange specifics

commit fdf9727f782c1df43be99c9b91dedcb03d7cd44a
Author: Pavel Tupitsyn 
Date:   2017-09-06T12:44:27Z

wip

commit 6c653c41659c67b0618fd3b2f3fc255075f8a000
Author: Pavel Tupitsyn 
Date:   2017-09-06T12:44:43Z

Fix class naming

commit 10f8666a024bc7a32d1c4befadf9b67683f025b6
Author: Pavel Tupitsyn 
Date:   2017-09-06T12:47:37Z

cleanup




> .NET: Decouple AbstractQueryCursor from PlatformTarget data exchange specifics
> --
>
> Key: IGNITE-6279
> URL: https://issues.apache.org/jira/browse/IGNITE-6279
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> {{AbstractQueryCursor}} should be concerned only with iterator and cursor 
> logic. Data exchange should be factored out. This will simplify code reuse 
> for thin client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6279) .NET: Decouple AbstractQueryCursor from PlatformTarget data exchange specifics

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6279:
--

 Summary: .NET: Decouple AbstractQueryCursor from PlatformTarget 
data exchange specifics
 Key: IGNITE-6279
 URL: https://issues.apache.org/jira/browse/IGNITE-6279
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.3


{{AbstractQueryCursor }} should be concerned only with iterator and cursor 
logic. Data exchange should be factored out. This will simplify code reuse for 
thin client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6279) .NET: Decouple AbstractQueryCursor from PlatformTarget data exchange specifics

[Pavel Tupitsyn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-6279:
---
Description: {{AbstractQueryCursor}} should be concerned only with iterator 
and cursor logic. Data exchange should be factored out. This will simplify code 
reuse for thin client.  (was: {{AbstractQueryCursor }} should be concerned only 
with iterator and cursor logic. Data exchange should be factored out. This will 
simplify code reuse for thin client.)

> .NET: Decouple AbstractQueryCursor from PlatformTarget data exchange specifics
> --
>
> Key: IGNITE-6279
> URL: https://issues.apache.org/jira/browse/IGNITE-6279
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> {{AbstractQueryCursor}} should be concerned only with iterator and cursor 
> logic. Data exchange should be factored out. This will simplify code reuse 
> for thin client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6058) Test fail testTransformResourceInjection broken

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-6058:


Assignee: Alexey Kuznetsov

> Test fail testTransformResourceInjection broken
> ---
>
> Key: IGNITE-6058
> URL: https://issues.apache.org/jira/browse/IGNITE-6058
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Govorukhin
>Assignee: Alexey Kuznetsov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Affected tests:
> GridCachePartitionedNearDisabledMultiJvmFullApiSelfTest.testTransformResourceInjection
> 
> GridCachePartitionedNearDisabledMultiJvmP2PDisabledFullApiSelfTest.testTransformResourceInjection
>  
> GridCachePartitionedNearDisabledOnheapMultiJvmFullApiSelfTest.testTransformResourceInjection
>   
> GridCacheReplicatedMultiJvmFullApiSelfTest.testTransformResourceInjection 
> GridCacheReplicatedMultiJvmP2PDisabledFullApiSelfTest.testTransformResourceInjection
>   
> GridCacheReplicatedNearOnlyMultiJvmFullApiSelfTest.testTransformResourceInjection
>  
> GridCacheReplicatedOnheapMultiJvmFullApiSelfTest.testTransformResourceInjection



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6130) JDBC Thin: JdbcThinResultSet must support types conversions

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155265#comment-16155265
 ] 

Taras Ledkov edited comment on IGNITE-6130 at 9/6/17 12:13 PM:
---

All comments are fixed.
*6* and *7* not fully agreed because specification says that obly {{BINARY}}, 
{{VARBINARY}} and {{LONGVARBINARY}} are able to convert to  {{byte[]}} and only 
{{DATALINK}} is converted to {{URL}} (see table B-6).
But H2 supports conversions from numbers to byte[]. I've implemented ones too.

[~vozerov], please review the changes.


was (Author: tledkov-gridgain):
All comments are fixed.
*6* and *7* not fully agreed because specification says that obly {{BINARY}}, 
{{VARBINARY}} and {{LONGVARBINARY}} are able to convert to  {{byte[]}} and only 
{{DATALINK}} is converted to {{URL}} (see table B-6).
But H2 supports conversions from numbers to byte[]. I've implemented ones too.

> JDBC Thin: JdbcThinResultSet must support types conversions 
> 
>
> Key: IGNITE-6130
> URL: https://issues.apache.org/jira/browse/IGNITE-6130
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> Now JdbcThinResultSet  doesn't support data types transformation.
> e.g.: if the attribute type is SHORT
> all the methods below must return valid value:
> {{getByte, getShort, getInt, getLong, getFloat, getDouble, getBigDecimal, 
> getBoolean, getString, getNString}}
> See the table *B-6* at the JDBC spec (see also [8.9.5 and 
> 8.9.6|http://docs.oracle.com/javase/6/docs/technotes/guides/jdbc/getstart/mapping.html#996857]).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6130) JDBC Thin: JdbcThinResultSet must support types conversions

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155265#comment-16155265
 ] 

Taras Ledkov edited comment on IGNITE-6130 at 9/6/17 12:13 PM:
---

All comments are fixed.
*6* and *7* not fully agreed because specification says that {{BINARY}}, 
{{VARBINARY}} and {{LONGVARBINARY}} are able to convert to  {{byte[]}} and only 
{{DATALINK}} is converted to {{URL}} (see table B-6).
But H2 supports conversions from numbers to byte[]. I've implemented ones too.

[~vozerov], please review the changes.


was (Author: tledkov-gridgain):
All comments are fixed.
*6* and *7* not fully agreed because specification says that obly {{BINARY}}, 
{{VARBINARY}} and {{LONGVARBINARY}} are able to convert to  {{byte[]}} and only 
{{DATALINK}} is converted to {{URL}} (see table B-6).
But H2 supports conversions from numbers to byte[]. I've implemented ones too.

[~vozerov], please review the changes.

> JDBC Thin: JdbcThinResultSet must support types conversions 
> 
>
> Key: IGNITE-6130
> URL: https://issues.apache.org/jira/browse/IGNITE-6130
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> Now JdbcThinResultSet  doesn't support data types transformation.
> e.g.: if the attribute type is SHORT
> all the methods below must return valid value:
> {{getByte, getShort, getInt, getLong, getFloat, getDouble, getBigDecimal, 
> getBoolean, getString, getNString}}
> See the table *B-6* at the JDBC spec (see also [8.9.5 and 
> 8.9.6|http://docs.oracle.com/javase/6/docs/technotes/guides/jdbc/getstart/mapping.html#996857]).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6130) JDBC Thin: JdbcThinResultSet must support types conversions

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155265#comment-16155265
 ] 

Taras Ledkov edited comment on IGNITE-6130 at 9/6/17 12:12 PM:
---

All comments are fixed.
*6* and *7* not fully agreed because specification says that obly {{BINARY}}, 
{{VARBINARY}} and {{LONGVARBINARY}} are able to convert to  {{byte[]}} and only 
{{DATALINK}} is converted to {{URL}} (see table B-6).
But H2 supports conversions from numbers to byte[]. I've implemented ones too.


was (Author: tledkov-gridgain):
All comments are fixed.
*6* and *7* not fully agreed because specification says that obly {{BINARY}}, 
{{VARBINARY}} and {{LONGVARBINARY}} are able to convert to  {{byte[]}} and only 
{{DATALINK}} is converted to {{URL}} (see table B-6).
But H2 supports conversions from numbers to byte[]. I've implemented ones too.

> JDBC Thin: JdbcThinResultSet must support types conversions 
> 
>
> Key: IGNITE-6130
> URL: https://issues.apache.org/jira/browse/IGNITE-6130
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> Now JdbcThinResultSet  doesn't support data types transformation.
> e.g.: if the attribute type is SHORT
> all the methods below must return valid value:
> {{getByte, getShort, getInt, getLong, getFloat, getDouble, getBigDecimal, 
> getBoolean, getString, getNString}}
> See the table *B-6* at the JDBC spec (see also [8.9.5 and 
> 8.9.6|http://docs.oracle.com/javase/6/docs/technotes/guides/jdbc/getstart/mapping.html#996857]).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6130) JDBC Thin: JdbcThinResultSet must support types conversions

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155265#comment-16155265
 ] 

Taras Ledkov commented on IGNITE-6130:
--

All comments are fixed.
*6* and *7* not fully agreed because specification says that obly {{BINARY}}, 
{{VARBINARY}} and {{LONGVARBINARY}} are able to convert to  {{byte[]}} and only 
{{DATALINK}} is converted to {{URL}} (see table B-6).
But H2 supports conversions from numbers to byte[]. I've implemented ones too.

> JDBC Thin: JdbcThinResultSet must support types conversions 
> 
>
> Key: IGNITE-6130
> URL: https://issues.apache.org/jira/browse/IGNITE-6130
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> Now JdbcThinResultSet  doesn't support data types transformation.
> e.g.: if the attribute type is SHORT
> all the methods below must return valid value:
> {{getByte, getShort, getInt, getLong, getFloat, getDouble, getBigDecimal, 
> getBoolean, getString, getNString}}
> See the table *B-6* at the JDBC spec (see also [8.9.5 and 
> 8.9.6|http://docs.oracle.com/javase/6/docs/technotes/guides/jdbc/getstart/mapping.html#996857]).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6130) JDBC Thin: JdbcThinResultSet must support types conversions

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155265#comment-16155265
 ] 

Taras Ledkov edited comment on IGNITE-6130 at 9/6/17 12:12 PM:
---

All comments are fixed.
*6* and *7* not fully agreed because specification says that obly {{BINARY}}, 
{{VARBINARY}} and {{LONGVARBINARY}} are able to convert to  {{byte[]}} and only 
{{DATALINK}} is converted to {{URL}} (see table B-6).
But H2 supports conversions from numbers to byte[]. I've implemented ones too.


was (Author: tledkov-gridgain):
All comments are fixed.
*6* and *7* not fully agreed because specification says that obly {{BINARY}}, 
{{VARBINARY}} and {{LONGVARBINARY}} are able to convert to  {{byte[]}} and only 
{{DATALINK}} is converted to {{URL}} (see table B-6).
But H2 supports conversions from numbers to byte[]. I've implemented ones too.

> JDBC Thin: JdbcThinResultSet must support types conversions 
> 
>
> Key: IGNITE-6130
> URL: https://issues.apache.org/jira/browse/IGNITE-6130
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> Now JdbcThinResultSet  doesn't support data types transformation.
> e.g.: if the attribute type is SHORT
> all the methods below must return valid value:
> {{getByte, getShort, getInt, getLong, getFloat, getDouble, getBigDecimal, 
> getBoolean, getString, getNString}}
> See the table *B-6* at the JDBC spec (see also [8.9.5 and 
> 8.9.6|http://docs.oracle.com/javase/6/docs/technotes/guides/jdbc/getstart/mapping.html#996857]).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5865) TxOptimisticDeadlockDetectionTest.testDeadlocksPartitioned is failing

[Vitaliy Biryukov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16153175#comment-16153175
 ] 

Vitaliy Biryukov edited comment on IGNITE-5865 at 9/6/17 11:28 AM:
---

[~dpavlov], Fixed.
I've run some builds:
https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteCacheDeadlockDetection=buildTypeHistoryList_Ignite20Tests=pull%2F2415%2Fhead

The problem was that the test began to work incorrectly after changes in the 
BinaryMarshaler, hashes of original objects and binary became different. And 
this led to an incorrect partition of entities in the test. But in some cases, 
it had to work. I found bugs and fix them in another task. 



was (Author: vitaliyb):
[~dpavlov], Fixed.
I've run some builds:
https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteCacheDeadlockDetection=buildTypeHistoryList_Ignite20Tests=pull%2F2415%2Fhead

The problem was that the test began to work incorrectly due to changes in 
BiraryMarshaler, but in some cases, it had to work. I found bugs and fix them 
in another task. 


> TxOptimisticDeadlockDetectionTest.testDeadlocksPartitioned is failing
> -
>
> Key: IGNITE-5865
> URL: https://issues.apache.org/jira/browse/IGNITE-5865
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Vitaliy Biryukov
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-failure
> Fix For: 2.3
>
>
> Test is flaky.
> Also there is always failing test in suite: 
> TxOptimisticDeadlockDetectionTest.testDeadlocksPartitionedNear
> TC build result: 
> http://ci.ignite.apache.org/viewLog.html?buildId=744109=buildResultsDiv=Ignite20Tests_IgniteCacheDeadlockDetection
> Stacktrace: 
> {noformat}
> [2017-07-28 
> 03:31:52,827][ERROR][grid-timeout-worker-#31%transactions.TxOptimisticDeadlockDetectionTest0%][IgniteTxHandler]
>  Failed to prepare DHT transaction: GridDhtTxLocal 
> [nearNodeId=d005de76-4378-4cd5-ad7e-f00593a2, 
> nearFutId=aab9f378d51-37ca90c9-03f5-417c-9731-2c29810e3cc0, nearMiniId=1, 
> nearFinFutId=null, nearFinMiniId=0, nearXidVer=GridCacheVersion 
> [topVer=112692678, order=1501212673293, nodeOrder=3], 
> super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[], 
> dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter 
> [completedBase=null, sndTransformedVals=false, depEnabled=false, 
> txState=IgniteTxStateImpl [activeCacheIds=GridIntList [idx=1, 
> arr=[94416770]], recovery=false, txMap=[IgniteTxEntry 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=424974513, hash=-1228408719, id=1, name=KeyObject1], 
> cacheId=94416770, txKey=IgniteTxKey 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=424974513, hash=-1228408719, id=1, name=KeyObject1], 
> cacheId=94416770], val=[op=CREATE, val=CacheObjectImpl [val=null, 
> hasValBytes=true]], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null, dhtVer=null, filters=[], filtersPassed=false, 
> filtersSet=false, entry=GridDhtCacheEntry [rdrs=[], part=694, 
> super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], val=null, 
> startVer=1501212673290, ver=GridCacheVersion [topVer=112692678, 
> order=1501212673290, nodeOrder=1], hash=-1228408719, 
> extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc 
> [locs=[GridCacheMvccCandidate [nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, 
> ver=GridCacheVersion [topVer=112692678, order=1501212673287, nodeOrder=1], 
> threadId=846, id=520, topVer=AffinityTopologyVersion [topVer=8, 
> minorTopVer=8], reentry=null, 
> otherNodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, otherVer=GridCacheVersion 
> [topVer=112692678, order=1501212673287, nodeOrder=1], mappedDhtNodes=null, 
> mappedNearNodes=null, ownerVer=null, serOrder=null, 
> key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], 
> masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null], GridCacheMvccCandidate 
> [nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, ver=GridCacheVersion 
> [topVer=112692678, order=1501212673314, nodeOrder=1], threadId=847, id=521, 
> topVer=AffinityTopologyVersion [topVer=8, minorTopVer=8], reentry=null, 
> otherNodeId=d005de76-4378-4cd5-ad7e-f00593a2, otherVer=GridCacheVersion 
> 

[jira] [Updated] (IGNITE-6262) TxPessimisticDeadlockDetectionTest.testDeadlocksPartitionedNear and TxPessimisticDeadlockDetectionTest.testDeadlocksReplicated is failing flaky.

[Vitaliy Biryukov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitaliy Biryukov updated IGNITE-6262:
-
Description: 
The problem and the solution are the same with IGNITE-5865.

After changes in the BinaryMarshaler, hashes of original objects and binary 
became different. And this led to an incorrect partition of entities in a test.


  was:
The problem and the solution are the same with IGNITE-5865.

After changes in the marshaler, hashes of original objects and binary became 
different.



> TxPessimisticDeadlockDetectionTest.testDeadlocksPartitionedNear and 
> TxPessimisticDeadlockDetectionTest.testDeadlocksReplicated  is failing flaky.
> -
>
> Key: IGNITE-6262
> URL: https://issues.apache.org/jira/browse/IGNITE-6262
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>  Labels: MakeTeamcityGreenAgain
>
> The problem and the solution are the same with IGNITE-5865.
> After changes in the BinaryMarshaler, hashes of original objects and binary 
> became different. And this led to an incorrect partition of entities in a 
> test.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6262) TxPessimisticDeadlockDetectionTest.testDeadlocksPartitionedNear and TxPessimisticDeadlockDetectionTest.testDeadlocksReplicated is failing flaky.

[Vitaliy Biryukov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitaliy Biryukov updated IGNITE-6262:
-
Description: 
The problem and the solution are the same with IGNITE-5865.

After changes in the BinaryMarshaler, hashes of original objects and binary 
became different. And this led to an incorrect partition of entities in the 
test.


  was:
The problem and the solution are the same with IGNITE-5865.

After changes in the BinaryMarshaler, hashes of original objects and binary 
became different. And this led to an incorrect partition of entities in a test.



> TxPessimisticDeadlockDetectionTest.testDeadlocksPartitionedNear and 
> TxPessimisticDeadlockDetectionTest.testDeadlocksReplicated  is failing flaky.
> -
>
> Key: IGNITE-6262
> URL: https://issues.apache.org/jira/browse/IGNITE-6262
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>  Labels: MakeTeamcityGreenAgain
>
> The problem and the solution are the same with IGNITE-5865.
> After changes in the BinaryMarshaler, hashes of original objects and binary 
> became different. And this led to an incorrect partition of entities in the 
> test.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6262) TxPessimisticDeadlockDetectionTest.testDeadlocksPartitionedNear and TxPessimisticDeadlockDetectionTest.testDeadlocksReplicated is failing flaky.

[Vitaliy Biryukov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitaliy Biryukov updated IGNITE-6262:
-
Description: 
The problem and the solution are the same with IGNITE-5865.

After changes in the marshaler, hashes of original objects and binary became 
different.


  was:
The problem and the solution are the same with IGNITE-5865.

After changes in the marshaler, hashes of original objects and binary steel 
differ.



> TxPessimisticDeadlockDetectionTest.testDeadlocksPartitionedNear and 
> TxPessimisticDeadlockDetectionTest.testDeadlocksReplicated  is failing flaky.
> -
>
> Key: IGNITE-6262
> URL: https://issues.apache.org/jira/browse/IGNITE-6262
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>  Labels: MakeTeamcityGreenAgain
>
> The problem and the solution are the same with IGNITE-5865.
> After changes in the marshaler, hashes of original objects and binary became 
> different.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6262) TxPessimisticDeadlockDetectionTest.testDeadlocksPartitionedNear and TxPessimisticDeadlockDetectionTest.testDeadlocksReplicated is failing flaky.

[Vitaliy Biryukov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitaliy Biryukov updated IGNITE-6262:
-
Description: 
The problem and the solution are the same with IGNITE-5865.

After changes in the marshaler, hashes of original objects and binary steel 
differ.


  was:
The problem and the solution are the same with IGNITE-5865.




> TxPessimisticDeadlockDetectionTest.testDeadlocksPartitionedNear and 
> TxPessimisticDeadlockDetectionTest.testDeadlocksReplicated  is failing flaky.
> -
>
> Key: IGNITE-6262
> URL: https://issues.apache.org/jira/browse/IGNITE-6262
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>  Labels: MakeTeamcityGreenAgain
>
> The problem and the solution are the same with IGNITE-5865.
> After changes in the marshaler, hashes of original objects and binary steel 
> differ.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6181) Tx is not rolled back on timeout leading to potential whole grid hang

[Semen Boikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155203#comment-16155203
 ] 

Semen Boikov edited comment on IGNITE-6181 at 9/6/17 11:19 AM:
---

[~ascherbakov],

Thanks for fixes, after one more review I have more comments:
1.
{noformat}
/** Timed out local transactions are cleared in {@link 
#onLocalClose}. */
if (!tx.timedOut() || !tx.pessimistic())
threadMap.remove(tx.threadId(), tx);
{noformat}

Why optimistic/pessimistic txs are handled in different way? 

Actually I do not like these changes related to threadMap. I think more clear 
fix is completely get rid of threadMap, and replace it with ThreadLocal (anyway 
as I can see we always access threadMap using current thread's id).This 
ThreadLocal should be set after tx is created and cleared in close(). Please 
try implement this.

2. 100ms timeout can not fix race. Please provide more details what race are 
you talking about? Let' find correct way to fix it
3. TimeoutObject is not removed when 'tx.rollback' is called (I changed your 
test to reproduce it, take a look), please fix.
4. Please add tests for all tx isolation/concurrency types.
5. It seems we do not need this TimeoutObject for implicit transactions (i.e. 
just cache.put without explicit txStart call) ? Please add this check.
6. About changes in IgniteTransactionsImpl.txStart0: as I understand it is 
possible to get tx there only if tx.close() was not called? This is incorrect 
API usage and I think exception is ok in this cases, so changes in 
IgniteTransactionsImpl.txStart0 are not needed.

Thanks!



was (Author: sboikov):
[~ascherbakov]],

Thanks for fixes, after one more review I have more comments:
1.
{noformat}
/** Timed out local transactions are cleared in {@link 
#onLocalClose}. */
if (!tx.timedOut() || !tx.pessimistic())
threadMap.remove(tx.threadId(), tx);
{noformat}

Why optimistic/pessimistic txs are handled in different way? 

Actually I do not like these changes related to threadMap. I think more clear 
fix is completely get rid of threadMap, and replace it with ThreadLocal (anyway 
as I can see we always access threadMap using current thread's id).This 
ThreadLocal should be set after tx is created and cleared in close(). Please 
try implement this.

2. 100ms timeout can not fix race. Please provide more details what race are 
you talking about? Let' find correct way to fix it
3. TimeoutObject is not removed when 'tx.rollback' is called (I changed your 
test to reproduce it, take a look), please fix.
4. Please add tests for all tx isolation/concurrency types.
5. It seems we do not need this TimeoutObject for implicit transactions (i.e. 
just cache.put without explicit txStart call) ? Please add this check.
6. About changes in IgniteTransactionsImpl.txStart0: as I understand it is 
possible to get tx there only if tx.close() was not called? This is incorrect 
API usage and I think exception is ok in this cases, so changes in 
IgniteTransactionsImpl.txStart0 are not needed.

Thanks!


> Tx is not rolled back on timeout leading to potential whole grid hang
> -
>
> Key: IGNITE-6181
> URL: https://issues.apache.org/jira/browse/IGNITE-6181
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 2.3
>
>
> Unit test reproducer:
> {noformat}
> /*
>  * Licensed to the Apache Software Foundation (ASF) under one or more
>  * contributor license agreements.  See the NOTICE file distributed with
>  * this work for additional information regarding copyright ownership.
>  * The ASF licenses this file to You under the Apache License, Version 2.0
>  * (the "License"); you may not use this file except in compliance with
>  * the License.  You may obtain a copy of the License at
>  *
>  *  http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing, software
>  * distributed under the License is distributed on an "AS IS" BASIS,
>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>  * See the License for the specific language governing permissions and
>  * limitations under the License.
>  */
> package org.apache.ignite.cache;
> import java.util.concurrent.CountDownLatch;
> import java.util.concurrent.TimeUnit;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.configuration.CacheConfiguration;
> import 

[jira] [Commented] (IGNITE-6181) Tx is not rolled back on timeout leading to potential whole grid hang

[Semen Boikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155203#comment-16155203
 ] 

Semen Boikov commented on IGNITE-6181:
--

[~ascherbakov]],

Thanks for fixes, after one more review I have more comments:
1.
{noformat}
/** Timed out local transactions are cleared in {@link 
#onLocalClose}. */
if (!tx.timedOut() || !tx.pessimistic())
threadMap.remove(tx.threadId(), tx);
{noformat}

Why optimistic/pessimistic txs are handled in different way? 

Actually I do not like these changes related to threadMap. I think more clear 
fix is completely get rid of threadMap, and replace it with ThreadLocal (anyway 
as I can see we always access threadMap using current thread's id).This 
ThreadLocal should be set after tx is created and cleared in close(). Please 
try implement this.

2. 100ms timeout can not fix race. Please provide more details what race are 
you talking about? Let' find correct way to fix it
3. TimeoutObject is not removed when 'tx.rollback' is called (I changed your 
test to reproduce it, take a look), please fix.
4. Please add tests for all tx isolation/concurrency types.
5. It seems we do not need this TimeoutObject for implicit transactions (i.e. 
just cache.put without explicit txStart call) ? Please add this check.
6. About changes in IgniteTransactionsImpl.txStart0: as I understand it is 
possible to get tx there only if tx.close() was not called? This is incorrect 
API usage and I think exception is ok in this cases, so changes in 
IgniteTransactionsImpl.txStart0 are not needed.

Thanks!


> Tx is not rolled back on timeout leading to potential whole grid hang
> -
>
> Key: IGNITE-6181
> URL: https://issues.apache.org/jira/browse/IGNITE-6181
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 2.3
>
>
> Unit test reproducer:
> {noformat}
> /*
>  * Licensed to the Apache Software Foundation (ASF) under one or more
>  * contributor license agreements.  See the NOTICE file distributed with
>  * this work for additional information regarding copyright ownership.
>  * The ASF licenses this file to You under the Apache License, Version 2.0
>  * (the "License"); you may not use this file except in compliance with
>  * the License.  You may obtain a copy of the License at
>  *
>  *  http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing, software
>  * distributed under the License is distributed on an "AS IS" BASIS,
>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>  * See the License for the specific language governing permissions and
>  * limitations under the License.
>  */
> package org.apache.ignite.cache;
> import java.util.concurrent.CountDownLatch;
> import java.util.concurrent.TimeUnit;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.TransactionConfiguration;
> import org.apache.ignite.internal.IgniteInternalFuture;
> import org.apache.ignite.internal.util.typedef.internal.U;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> /**
>  * Tests ability to rollback not properly closed transaction.
>  */
> public class IgniteTxTimeoutTest extends GridCommonAbstractTest {
> /** */
> private static final long TX_TIMEOUT = 3_000L;
> /** */
> private static final String CACHE_NAME = "test";
> /** IP finder. */
> private static final TcpDiscoveryVmIpFinder IP_FINDER = new 
> TcpDiscoveryVmIpFinder(true);
> /** */
> private final CountDownLatch l = new CountDownLatch(1);
> /** */
> private final Object mux = new Object();
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(IP_FINDER));
> TransactionConfiguration txCfg = new TransactionConfiguration();
> txCfg.setDefaultTxTimeout(TX_TIMEOUT);
> 

[jira] [Updated] (IGNITE-6262) TxPessimisticDeadlockDetectionTest.testDeadlocksPartitionedNear and TxPessimisticDeadlockDetectionTest.testDeadlocksReplicated is failing flaky.

[Vitaliy Biryukov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitaliy Biryukov updated IGNITE-6262:
-
Description: 
The problem and the solution are the same with IGNITE-5865.



  was:The problem and the solution are the same with IGNITE-5865.


> TxPessimisticDeadlockDetectionTest.testDeadlocksPartitionedNear and 
> TxPessimisticDeadlockDetectionTest.testDeadlocksReplicated  is failing flaky.
> -
>
> Key: IGNITE-6262
> URL: https://issues.apache.org/jira/browse/IGNITE-6262
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>  Labels: MakeTeamcityGreenAgain
>
> The problem and the solution are the same with IGNITE-5865.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6278) Add benchmarking page to readme.io

[Aleksei Zaitsev (JIRA)]

Aleksei Zaitsev created IGNITE-6278:
---

 Summary: Add benchmarking page to readme.io
 Key: IGNITE-6278
 URL: https://issues.apache.org/jira/browse/IGNITE-6278
 Project: Ignite
  Issue Type: Wish
  Components: documentation
Reporter: Aleksei Zaitsev
Assignee: Aleksei Zaitsev
Priority: Minor


Add a page with information about benchmarking to 
https://apacheignite.readme.io/docs



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6227) Delete obsolete benchmarks for Ignite 1.9

[Anton Vinogradov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anton Vinogradov updated IGNITE-6227:
-
Fix Version/s: None

> Delete obsolete benchmarks for Ignite 1.9
> -
>
> Key: IGNITE-6227
> URL: https://issues.apache.org/jira/browse/IGNITE-6227
> Project: Ignite
>  Issue Type: Task
>  Components: yardstick
>Reporter: Aleksei Zaitsev
>Assignee: Aleksei Zaitsev
>Priority: Minor
>  Labels: benchmarks, yardstick
> Fix For: None
>
>
> Apache Ignite v2.0 and above delivers with benchmarks. So project 
> https://github.com/apacheignite/yardstick-ignite/ with benchmarks for Ignite 
> 1.9 became obsolete. To avoid confusion was decided to delete this code and 
> add direct link to new version of Ignite in the description of the repo.
> See dev-list discussion: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Yardstick-framework-for-Ignite-2-1-td21087.html#none



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-3558) Affinity task hangs when Collision SPI produces a lot of job rejections & Failover SPI produces many attempts

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155188#comment-16155188
 ] 

Taras Ledkov commented on IGNITE-3558:
--

Waits for [tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F1326%2Fhead]

> Affinity task hangs when Collision SPI produces a lot of job rejections & 
> Failover SPI produces many attempts
> -
>
> Key: IGNITE-3558
> URL: https://issues.apache.org/jira/browse/IGNITE-3558
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> The test to reproduce:
> {{IgniteCacheLockPartitionOnAffinityRunWithCollisionSpiTest.testJobFinishing}}
> *Root cause*
> {{GridJobExecuteResponse}} isn't set from target node because there is a 
> confusion with {{GridJobWorker}} instances in the {{CollisionContext}}.
> *Suggestion*
> The method {{GridJobProcessor.CollisionJobContext.cancel()}}
> use {{passiveJobs.remove(jobWorker.getJobId(), jobWorker)}}. 
> *passiveJobs* is a ConcurrentHashMap and {{GridJobWorker.equals()}} 
> implements as a equation of jobId.
> So, when two thread try to cancel the two workers with *the same jobIds* we 
> have the case:
> - thread0 remove jobWorker0 & cancel jobWorker0.
> - thread0 put jobWorker1 (because jobWorker0 already removed);
> - thread1: (has a copy of jobWorker0) and try to cancel it.
> - thread1: remove jobWorker1 instead of jobWorker0 (because jobId is used to 
> identify);
> - thread1: doesn't send ExecuteResponse because jobWorker0 has been canceled.
> *Proposal*
> Try to use system default equals for the GridJobWorker



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6262) TxPessimisticDeadlockDetectionTest.testDeadlocksPartitionedNear and TxPessimisticDeadlockDetectionTest.testDeadlocksReplicated is failing flaky.

[Vitaliy Biryukov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitaliy Biryukov updated IGNITE-6262:
-
Description: The problem and the solution are the same with IGNITE-5865.  
(was: The problem is the same with IGNITE-5865.)

> TxPessimisticDeadlockDetectionTest.testDeadlocksPartitionedNear and 
> TxPessimisticDeadlockDetectionTest.testDeadlocksReplicated  is failing flaky.
> -
>
> Key: IGNITE-6262
> URL: https://issues.apache.org/jira/browse/IGNITE-6262
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>  Labels: MakeTeamcityGreenAgain
>
> The problem and the solution are the same with IGNITE-5865.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6227) Delete obsolete benchmarks for Ignite 1.9

[Aleksei Zaitsev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155186#comment-16155186
 ] 

Aleksei Zaitsev commented on IGNITE-6227:
-

[~avinogradov], please review my changes.

PR: https://github.com/apacheignite/yardstick-ignite/pull/6

> Delete obsolete benchmarks for Ignite 1.9
> -
>
> Key: IGNITE-6227
> URL: https://issues.apache.org/jira/browse/IGNITE-6227
> Project: Ignite
>  Issue Type: Task
>  Components: yardstick
>Reporter: Aleksei Zaitsev
>Assignee: Aleksei Zaitsev
>Priority: Minor
>  Labels: benchmarks, yardstick
>
> Apache Ignite v2.0 and above delivers with benchmarks. So project 
> https://github.com/apacheignite/yardstick-ignite/ with benchmarks for Ignite 
> 1.9 became obsolete. To avoid confusion was decided to delete this code and 
> add direct link to new version of Ignite in the description of the repo.
> See dev-list discussion: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Yardstick-framework-for-Ignite-2-1-td21087.html#none



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6228) Avoid closing page store file with ClosedByInterruptException when user thread is interrupted

[Andrey Gura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura reassigned IGNITE-6228:
---

Assignee: Andrey Gura

> Avoid closing page store file with ClosedByInterruptException when user 
> thread is interrupted
> -
>
> Key: IGNITE-6228
> URL: https://issues.apache.org/jira/browse/IGNITE-6228
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Andrey Gura
> Fix For: 2.3
>
> Attachments: RestartGridTest.java
>
>
> If cache proxy is in synchronous mode, user thread may be interrupted during 
> read from file page store file. This will cause closing of partition file 
> with ClosedByInterruptException.
> Example stacktrace:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Runtime failure on lookup 
> row: 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$SearchRow@717729d
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne(BPlusTree.java:1070)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.find(IgniteCacheOffheapManagerImpl.java:1476)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.find(GridCacheOffheapManager.java:1276)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.read(IgniteCacheOffheapManagerImpl.java:394)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:371)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:2952)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
>   at 
> org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1012)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:198)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:868)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leaveNoLock(GridCacheGateway.java:240)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leave(GridCacheGateway.java:225)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onLeave(GatewayProtectedCacheProxy.java:1680)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:875)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.db.RestartGridTest$TestService.execute(RestartGridTest.java:160)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$2.run(GridServiceProcessor.java:1160)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteCheckedException: Read error
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:356)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:287)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:272)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:570)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:488)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:129)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.treeMeta(BPlusTree.java:822)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$7700(BPlusTree.java:81)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Get.init(BPlusTree.java:2392)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doFind(BPlusTree.java:1099)
>   at 
> 

[jira] [Commented] (IGNITE-3558) Affinity task hangs when Collision SPI produces a lot of job rejections & Failover SPI produces many attempts

[Yakov Zhdanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155176#comment-16155176
 ] 

Yakov Zhdanov commented on IGNITE-3558:
---

I am ok with the changes.

[~tledkov-gridgain] please rerun team city and let's proceed.

> Affinity task hangs when Collision SPI produces a lot of job rejections & 
> Failover SPI produces many attempts
> -
>
> Key: IGNITE-3558
> URL: https://issues.apache.org/jira/browse/IGNITE-3558
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> The test to reproduce:
> {{IgniteCacheLockPartitionOnAffinityRunWithCollisionSpiTest.testJobFinishing}}
> *Root cause*
> {{GridJobExecuteResponse}} isn't set from target node because there is a 
> confusion with {{GridJobWorker}} instances in the {{CollisionContext}}.
> *Suggestion*
> The method {{GridJobProcessor.CollisionJobContext.cancel()}}
> use {{passiveJobs.remove(jobWorker.getJobId(), jobWorker)}}. 
> *passiveJobs* is a ConcurrentHashMap and {{GridJobWorker.equals()}} 
> implements as a equation of jobId.
> So, when two thread try to cancel the two workers with *the same jobIds* we 
> have the case:
> - thread0 remove jobWorker0 & cancel jobWorker0.
> - thread0 put jobWorker1 (because jobWorker0 already removed);
> - thread1: (has a copy of jobWorker0) and try to cancel it.
> - thread1: remove jobWorker1 instead of jobWorker0 (because jobId is used to 
> identify);
> - thread1: doesn't send ExecuteResponse because jobWorker0 has been canceled.
> *Proposal*
> Try to use system default equals for the GridJobWorker



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5572) DDL: Support ALTER TABLE ADD COLUMN

[Alexander Paschenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155161#comment-16155161
 ] 

Alexander Paschenko commented on IGNITE-5572:
-

[~vozerov]
made fixes per all comments, please advise.

> DDL: Support ALTER TABLE ADD COLUMN
> ---
>
> Key: IGNITE-5572
> URL: https://issues.apache.org/jira/browse/IGNITE-5572
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
>
> We should start gradual implementation of {{ALTER TABLE}} command. Let's 
> start with the most simple part - {{ADD COLUMN}}. Proposed design:
> 1) Send a message over a ring, similar to how we do that for create index
> 2) On local node: update relevant QueryEntity, update data strcutrues in 
> {{GridQueryProcessor}}, update {{IgniteH2Indexing}} data structures, execute 
> {{ALTER TABLE}} command on H2 database (global table lock must be acquired).
> 3) Make sure that update to {{QueryEntity}} is properly saved if persistence 
> is enabled.
> Feature should be covered with tests thoroughly:
> 1) Positive cases
> 2) Negative cases (no schema, no table, column already exists)
> 3) Test with concurrent SQL operations
> 4) Test with concurrent node restarts



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6271) .NET: Propagate ServiceDeploymentException

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155157#comment-16155157
 ] 

ASF GitHub Bot commented on IGNITE-6271:


Github user asfgit closed the pull request at:

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


> .NET: Propagate ServiceDeploymentException
> --
>
> Key: IGNITE-6271
> URL: https://issues.apache.org/jira/browse/IGNITE-6271
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Denis Mekhanikov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> IGNITE-5145 causes failures of some tests in ServiceTest class. The reason is 
> changed services API and a new type of exception thrown from deployment 
> methods.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-6271) .NET: Propagate ServiceDeploymentException

[Pavel Tupitsyn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn resolved IGNITE-6271.

Resolution: Fixed

> .NET: Propagate ServiceDeploymentException
> --
>
> Key: IGNITE-6271
> URL: https://issues.apache.org/jira/browse/IGNITE-6271
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Denis Mekhanikov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> IGNITE-5145 causes failures of some tests in ServiceTest class. The reason is 
> changed services API and a new type of exception thrown from deployment 
> methods.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6271) .NET: Propagate ServiceDeploymentException

[Pavel Tupitsyn (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155154#comment-16155154
 ] 

Pavel Tupitsyn commented on IGNITE-6271:


Merged to master: {{56860d22b4f74fce70aeead84e1ca59df38d3ef9}}.

> .NET: Propagate ServiceDeploymentException
> --
>
> Key: IGNITE-6271
> URL: https://issues.apache.org/jira/browse/IGNITE-6271
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Denis Mekhanikov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> IGNITE-5145 causes failures of some tests in ServiceTest class. The reason is 
> changed services API and a new type of exception thrown from deployment 
> methods.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6256) When a node becomes segmented an AssertionError is thrown during GridDhtPartitionTopologyImpl.removeNode

[Denis Mekhanikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Mekhanikov reassigned IGNITE-6256:


Assignee: Denis Mekhanikov  (was: Andrew Mashenkov)

> When a node becomes segmented an AssertionError is thrown during 
> GridDhtPartitionTopologyImpl.removeNode
> 
>
> Key: IGNITE-6256
> URL: https://issues.apache.org/jira/browse/IGNITE-6256
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.8
>Reporter: Alexandr Fedotov
>Assignee: Denis Mekhanikov
> Fix For: 2.3
>
>
> The assert is as follows:
> exception="java.lang.AssertionError: null
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.removeNode(GridDhtPartitionTopologyImpl.java:1422)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:490)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:769)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:504)
>  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1689)
>  at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>  at java.lang.Thread.run(Thread.java:745)
> Below is the sequence of steps that leads to the assertion error:
> 1) A node becomes SEGMENTED when it's determined by SegmentCheckWorker, after 
> an EVT_NODE_FAILED has been received.
> 2) It gets visibleRemoteNodes from it's TcpDiscoveryNodesRing
> 3) Clears the TcpDiscoveryNodesRing leaving only self on the list. The node 
> ring is used to determine if a node is alive
> during DiscoCache creation
> 4) After that, the node initiates removal of all the nodes read in step 2
> 5) For each node, it sends an EVT_NODE_FAILED to the corresponding 
> DiscoverySpiListener
> providing a topology containing all the nodes except already processed
> 6) This event gets into GridDiscoveryManager 
> 7) The node gets removed from alive nodes for every DiscoCache in 
> discoCacheHist
> 8) Topology change is detected
> 9) Creation of a new DiscoCache is attempted. At this moment every remote 
> node is not available due to the
> TcpDiscoveryNodesRing has been cleared, thus resulting in a DiscoCache with 
> empty alives
> 10) The event with the created DiscoCache and the new topology version is 
> passed to DiscoveryWorker
> 11) The event is eventually handled by DiscoveryWorker and is recorded by 
> DiscoveryWorker#recordEvent
> 12) The recording is handled by GridEventStorageManager which notifies every 
> listener for this event type (EVT_NODE_FAILED)
> 13) One of the listeners is GridCachePartitionExchangeManager#discoLsnr
> It creates a new GridDhtPartitionsExchangeFuture with the empty DiscoCache 
> received with the event and enqueues it
> 14) The future gets eventually handled by GridDhtPartitionsExchangeFuture and 
> initialized
> 15) updateTopologies is called, which for each GridCacheContext gets its 
> topology (GridDhtPartitionTopology)
> and calls GridDhtPartitionTopology#updateTopologyVersion
> 16) DiscoCache for GridDhtPartitionTopology is assigned from the one of the 
> GridDhtPartitionsExchangeFuture.
> The assigned DiscoCache has empty alives at the moment
> 15) A distributed exchange is handled 
> (GridDhtPartitionsExchangeFuture#distributedExchange)
> 16) For each cache context GridCacheContext, for its topology 
> (GridDhtPartitionTopologyImpl) GridDhtPartitionTopologyImpl#beforeExchange is 
> called
> 17) The fact that the node has left is determined and 
> GridDhtPartitionTopologyImpl#removeNode is called to handle it
> 18) An attempt is made to get the alive coordinator node by calling 
> DiscoCache#oldestAliveServerNode
> 19) null is returned which results in an AssertionError
> The fix should probably prevent initiating exchange futures if a node has 
> segmented.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6277) Convert WAL to human readable form

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-6277:
-

 Summary: Convert WAL to human readable form
 Key: IGNITE-6277
 URL: https://issues.apache.org/jira/browse/IGNITE-6277
 Project: Ignite
  Issue Type: Bug
Reporter: Eduard Shangareev
Assignee: Eduard Shangareev
 Fix For: 2.3


Now there is no way to make wal visible or understandable without coding.

I propose to write utility which would convert any given compatible WAL to 
textual form.

Something like this:
{code}
[W] InsertRecord [idx=19, io=H2ExtrasLeafIO[ver=1], rightId=, 
super=PageDeltaRecord [grpId=2141373875, pageId=00020011, 
super=WALRecord [size=61, chainSize=0, pos=FileWALPointer [idx=0, 
fileOffset=2504497, len=61, forceFlush=false], type=BTREE_PAGE_INSERT]]]
[W] DataRecord [writeEntries=[DataEntry [op=CREATE, writeVer=GridCacheVersion 
[topVer=116006687, order=0, nodeOrder=1], partId=29, partCnt=33]], 
super=WALRecord [size=171, chainSize=0, pos=FileWALPointer [idx=0, 
fileOffset=2504558, len=171, forceFlush=false], type=DATA_RECORD]]
[W] PagesListRemovePageRecord [rmvdPageId=0001000c002f, 
pageId=0001000c000a, grpId=-1368047377, super=PageDeltaRecord 
[grpId=-1368047377, pageId=0001000c000a, super=WALRecord [size=37, 
chainSize=0, pos=FileWALPointer [idx=0, fileOffset=2504729, len=37, 
forceFlush=false], type=PAGES_LIST_REMOVE_PAGE]]]
[W] DataPageInsertRecord [super=PageDeltaRecord [grpId=-1368047377, 
pageId=0001000c002f, super=WALRecord [size=76, chainSize=0, 
pos=FileWALPointer [idx=0, fileOffset=2504766, len=76, forceFlush=false], 
type=DATA_PAGE_INSERT_RECORD]]]
[W] PagesListAddPageRecord [dataPageId=0001000c002f, super=PageDeltaRecord 
[grpId=-1368047377, pageId=0001000c000b, super=WALRecord [size=37, 
chainSize=0, pos=FileWALPointer [idx=0, fileOffset=2504842, len=37, 
forceFlush=false], type=PAGES_LIST_ADD_PAGE]]]
[W] DataPageSetFreeListPageRecord [freeListPage=281526516318219, 
super=PageDeltaRecord [grpId=-1368047377, pageId=0001000c002f, 
super=WALRecord [size=37, chainSize=0, pos=FileWALPointer [idx=0, 
fileOffset=2504879, len=37, forceFlush=false], 
type=DATA_PAGE_SET_FREE_LIST_PAGE]]]

{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5339) JDBC thin driver: validate compliance

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155136#comment-16155136
 ] 

Taras Ledkov commented on IGNITE-5339:
--

Fixed. 
[Tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2112%2Fhead]
 are OK with me.

> JDBC thin driver: validate compliance
> -
>
> Key: IGNITE-5339
> URL: https://issues.apache.org/jira/browse/IGNITE-5339
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>  Labels: important
> Fix For: 2.3
>
>
> We need to make sure that all methods of our new driver are compliant with 
> JDBC spec, namely:
> 1) Semantics of normal execution is correct
> 2) Exceptions are thrown when excepted
> I propose the following flow:
> 1) Walk through interface classes (Connection -> Statement, PreparedStatement 
> -> ResultSet)
> 2) For every method identify a set of tests to verify semantics (if any).
> 3) Write those tests, even if they fail.
> 4) Once all tests are ready, decide how to proceed with their fixes.
> NB: we should write tests even for methods which throw "not-implemented 
> exception", so that we better understand the scope of remaining work.
> Link to [JDBC 
> specification|http://download.oracle.com/otn-pub/jcp/jdbc-4_1-mrel-spec/jdbc4.1-fr-spec.pdf?AuthParam=1496141650_c2ec45f13eb8c532632bbfaede64f351]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6248) Check Java 7 builds for compatibility with Ignite and update documentation

[Dmitry Karachentsev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Karachentsev reassigned IGNITE-6248:
---

Assignee: Dmitry Karachentsev

> Check Java 7 builds for compatibility with Ignite and update documentation
> --
>
> Key: IGNITE-6248
> URL: https://issues.apache.org/jira/browse/IGNITE-6248
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Dmitry Karachentsev
>  Labels: usability
> Fix For: 2.3
>
>
> According to these threads on SO and user list, some old Java 7 versions 
> doesn't compatible with Ignite since version 2.1 anymore:
> http://apache-ignite-users.70518.x6.nabble.com/Caused-by-org-h2-jdbc-JdbcSQLException-General-error-quot-java-lang-IllegalMonitorStateException-Attt-td15684.html
> https://stackoverflow.com/questions/45911616/datastreamer-does-not-work-well/45972341#45972341



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (IGNITE-6252) Cassandra Cache Store Session does not retry if prepare statement failed

[Sunny Chan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sunny Chan updated IGNITE-6252:
---
Comment: was deleted

(was: https://github.com/apache/ignite/pull/2583)

> Cassandra Cache Store Session does not retry if prepare statement failed
> 
>
> Key: IGNITE-6252
> URL: https://issues.apache.org/jira/browse/IGNITE-6252
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.0, 2.1
>Reporter: Sunny Chan
>
> During our testing, we have found that certain warning about prepared 
> statement:
> 2017-08-31 11:27:19.479 
> org.apache.ignite.cache.store.cassandra.CassandraCacheStore 
> flusher-0-#265%% WARN CassandraCacheStore - Prepared statement cluster 
> error detected, refreshing Cassandra session
> com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute 
> unknown prepared query : 0xc7647611fd755386ef63478ee7de577b. You may have 
> used a PreparedStatement that was created with another Cluster instance.
> We notice that after this warning occurs some of the data didn't persist 
> properly in cassandra cache. After further examining the Ignite's 
> CassandraSessionImpl code in method 
> execute(BatchExecutionAssistance,Iterable), we found that at around [line 
> 283|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L283],
>  if the prepare statement fails in the asnyc call, it will not retry the 
> operation as the error is stored in [line 
> 269|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L269]
>  and cleared in [line 
> 277|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L277]
>  but it was not checked again after going through the [ResultSetFuture 
> |https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L307].
> I believe in line 307 you should check for error != null such that any 
> failure will be retry.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6256) When a node becomes segmented an AssertionError is thrown during GridDhtPartitionTopologyImpl.removeNode

[Andrew Mashenkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155099#comment-16155099
 ] 

Andrew Mashenkov commented on IGNITE-6256:
--

Seems, this bug was introduced by IGNITE-4779.

> When a node becomes segmented an AssertionError is thrown during 
> GridDhtPartitionTopologyImpl.removeNode
> 
>
> Key: IGNITE-6256
> URL: https://issues.apache.org/jira/browse/IGNITE-6256
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.8
>Reporter: Alexandr Fedotov
>Assignee: Andrew Mashenkov
> Fix For: 2.3
>
>
> The assert is as follows:
> exception="java.lang.AssertionError: null
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.removeNode(GridDhtPartitionTopologyImpl.java:1422)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:490)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:769)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:504)
>  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1689)
>  at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>  at java.lang.Thread.run(Thread.java:745)
> Below is the sequence of steps that leads to the assertion error:
> 1) A node becomes SEGMENTED when it's determined by SegmentCheckWorker, after 
> an EVT_NODE_FAILED has been received.
> 2) It gets visibleRemoteNodes from it's TcpDiscoveryNodesRing
> 3) Clears the TcpDiscoveryNodesRing leaving only self on the list. The node 
> ring is used to determine if a node is alive
> during DiscoCache creation
> 4) After that, the node initiates removal of all the nodes read in step 2
> 5) For each node, it sends an EVT_NODE_FAILED to the corresponding 
> DiscoverySpiListener
> providing a topology containing all the nodes except already processed
> 6) This event gets into GridDiscoveryManager 
> 7) The node gets removed from alive nodes for every DiscoCache in 
> discoCacheHist
> 8) Topology change is detected
> 9) Creation of a new DiscoCache is attempted. At this moment every remote 
> node is not available due to the
> TcpDiscoveryNodesRing has been cleared, thus resulting in a DiscoCache with 
> empty alives
> 10) The event with the created DiscoCache and the new topology version is 
> passed to DiscoveryWorker
> 11) The event is eventually handled by DiscoveryWorker and is recorded by 
> DiscoveryWorker#recordEvent
> 12) The recording is handled by GridEventStorageManager which notifies every 
> listener for this event type (EVT_NODE_FAILED)
> 13) One of the listeners is GridCachePartitionExchangeManager#discoLsnr
> It creates a new GridDhtPartitionsExchangeFuture with the empty DiscoCache 
> received with the event and enqueues it
> 14) The future gets eventually handled by GridDhtPartitionsExchangeFuture and 
> initialized
> 15) updateTopologies is called, which for each GridCacheContext gets its 
> topology (GridDhtPartitionTopology)
> and calls GridDhtPartitionTopology#updateTopologyVersion
> 16) DiscoCache for GridDhtPartitionTopology is assigned from the one of the 
> GridDhtPartitionsExchangeFuture.
> The assigned DiscoCache has empty alives at the moment
> 15) A distributed exchange is handled 
> (GridDhtPartitionsExchangeFuture#distributedExchange)
> 16) For each cache context GridCacheContext, for its topology 
> (GridDhtPartitionTopologyImpl) GridDhtPartitionTopologyImpl#beforeExchange is 
> called
> 17) The fact that the node has left is determined and 
> GridDhtPartitionTopologyImpl#removeNode is called to handle it
> 18) An attempt is made to get the alive coordinator node by calling 
> DiscoCache#oldestAliveServerNode
> 19) null is returned which results in an AssertionError
> The fix should probably prevent initiating exchange futures if a node has 
> segmented.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-2779) BinaryMarshaller caches must be cleaned during client reconnect.

[Anton Vinogradov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155097#comment-16155097
 ] 

Anton Vinogradov commented on IGNITE-2779:
--

[~sergey-chugunov],
Vova recommended you to make a review, please do it.

> BinaryMarshaller caches must be cleaned during client reconnect.
> 
>
> Key: IGNITE-2779
> URL: https://issues.apache.org/jira/browse/IGNITE-2779
> Project: Ignite
>  Issue Type: Task
>  Components: cache, general
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Amelchev Nikita
>  Labels: community
> Fix For: 2.3
>
> Attachments: IgniteProblemTest.java
>
>
> The problem is originally reported by Vinay Sharma here: 
> http://apache-ignite-users.70518.x6.nabble.com/changed-cache-configuration-and-restarted-server-nodes-Getting-exception-td3064.html#none
> *Root cause*:
> When client is reconnected to topology after full topology restart (i.e. all 
> server nodes were down), it doesn't re-send binary metadata to topology. As a 
> result, {{BinaryMarshaller}} exception occurs.
> *Steps to reproduce*
> Run attached code.
> *Proposed solution*
> Clean cached binary metadata during re-connect.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)