[jira] [Commented] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-8152:
---

{panel:title=Branch: [pull/7521/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *- Run :: SQL* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5141239buildTypeId=IgniteTests24Java8_RunAllSql]

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
> Attachments: image-2020-03-19-16-01-42-979.png
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-8152:
---

{panel:title=Branch: [pull/7521/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: Basic Tests* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5141282buildTypeId=IgniteTests24Java8_RunBasicTests]

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
> Attachments: image-2020-03-19-16-01-42-979.png
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12809) Python client returns fields in wrong order since the 2 row when fields_count>10

2020-03-19 Thread Evgenii Zhuravlev (Jira)


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

Evgenii Zhuravlev updated IGNITE-12809:
---
Description: 
Reproducer attached. 

If result set is bigger than a page size(1 by default) and there are more than 
10 fields in an object, then, for all rows after the first query column order 
will be wrong. Looks like column order is being sorted as a string instead of 
number.

The reason for that is a sorting in api/sql.py: 
https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
If you remove it, everything will work fine. We need to make sure that this is 
the right solution for this issue.

Output from reproducer:

{code:java}
['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR', 
'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME', 'GOVERNMENTFORM', 
'HEADOFSTATE', 'CAPITAL', 'CODE2']
['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523, 
1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'), 'Zhongquo', 
'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman 
Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia', 
Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'), 
Decimal('430572')]
['USA', 'United States', 'United States', 'Federal Republic', 'George W. Bush', 
3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'), 1776, 
278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]

{code}


  was:
Reproducer attached. 

If result set is bigger than a page size(1 by default) and there are more than 
10 fields in an object, then, for all rows after the first query column order 
will be wrong.

The reason for that is a sorting in api/sql.py: 
https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
If you remove it, everything will work fine. We need to make sure that this is 
the right solution for this issue.

Output from reproducer:

{code:java}
['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR', 
'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME', 'GOVERNMENTFORM', 
'HEADOFSTATE', 'CAPITAL', 'CODE2']
['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523, 
1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'), 'Zhongquo', 
'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman 
Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia', 
Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'), 
Decimal('430572')]
['USA', 'United States', 'United States', 'Federal Republic', 'George W. Bush', 
3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'), 1776, 
278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]

{code}



> Python client returns fields in wrong order since the 2 row when 
> fields_count>10
> 
>
> Key: IGNITE-12809
> URL: https://issues.apache.org/jira/browse/IGNITE-12809
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.8
>Reporter: Evgenii Zhuravlev
>Priority: Major
> Attachments: reproducer.py
>
>
> Reproducer attached. 
> If result set is bigger than a page size(1 by default) and there are more 
> than 10 fields in an object, then, for all rows after the first query column 
> order will be wrong. Looks like column order is being sorted as a string 
> instead of number.
> The reason for that is a sorting in api/sql.py: 
> https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
> If you remove it, everything will work fine. We need to make sure that this 
> is the right solution for this issue.
> Output from reproducer:
> {code:java}
> ['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR', 
> 'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME', 
> 'GOVERNMENTFORM', 'HEADOFSTATE', 'CAPITAL', 'CODE2']
> ['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523, 
> 1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'), 
> 'Zhongquo', 'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
> ['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman 
> Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia', 
> Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'), 
> Decimal('430572')]
> ['USA', 'United States', 'United States', 'Federal Republic', 'George W. 
> Bush', 3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'), 
> 1776, 278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]
> {code}



--
This message was sent by 

[jira] [Created] (IGNITE-12809) Python client returns fields in wrong order since the 2 row when fields_count>10

2020-03-19 Thread Evgenii Zhuravlev (Jira)
Evgenii Zhuravlev created IGNITE-12809:
--

 Summary: Python client returns fields in wrong order since the 2 
row when fields_count>10
 Key: IGNITE-12809
 URL: https://issues.apache.org/jira/browse/IGNITE-12809
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.8
Reporter: Evgenii Zhuravlev
 Attachments: reproducer.py

Reproducer attached. 

If result set is bigger than a page size(1 by default) and there are more than 
10 fields in an object, then, for all rows after the first query column order 
will be wrong.

The reason for that is a sorting in api/sql.py: 
https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
If you remove it, everything will work fine. We need to make sure that this is 
the right solution for this issue.

Output from reproducer:

{code:java}
['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR', 
'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME', 'GOVERNMENTFORM', 
'HEADOFSTATE', 'CAPITAL', 'CODE2']
['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523, 
1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'), 'Zhongquo', 
'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman 
Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia', 
Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'), 
Decimal('430572')]
['USA', 'United States', 'United States', 'Federal Republic', 'George W. Bush', 
3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'), 1776, 
278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]

{code}




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12761) Add ability to disable check crc sums of stored pages due to invalidate_indexes.

2020-03-19 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-12761:


{panel:title=Branch: [pull/7517/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5139941buildTypeId=IgniteTests24Java8_RunAll]

> Add ability to disable check crc sums of stored pages due to 
> invalidate_indexes.
> 
>
> Key: IGNITE-12761
> URL: https://issues.apache.org/jira/browse/IGNITE-12761
> Project: Ignite
>  Issue Type: Bug
>Reporter: Philipp Masharov
>Assignee: Philipp Masharov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Add additional param to validate_indexes command
> org.apache.ignite.internal.commandline.cache.CacheSubcommands#VALIDATE_INDEXES*like
>  here: 
> org.apache.ignite.internal.commandline.cache.argument.IdleVerifyCommandArg#CHECK_CRC
> now by default this check is always enabled, need to be configurable like the 
> same one in IdleVerifyCommandArg



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (IGNITE-7609) .NET: FieldsQueryCursor should expose data types too

2020-03-19 Thread Sergey Stronchinskiy (Jira)


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

Sergey Stronchinskiy reassigned IGNITE-7609:


Assignee: Sergey Stronchinskiy

> .NET: FieldsQueryCursor should expose data types too
> 
>
> Key: IGNITE-7609
> URL: https://issues.apache.org/jira/browse/IGNITE-7609
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>Priority: Major
>  Labels: .NET
>
> See IGNITE-7607 for Java, add same thing to .NET:
> {code}
> public interface IFieldsQueryCursor
> {
> ...
> IList FieldTypes
> }
> {code}
> T could be string or Type, needs investigation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12761) Add ability to disable check crc sums of stored pages due to invalidate_indexes.

2020-03-19 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-12761:


{panel:title=Branch: [pull/7517/head] Base: [master] : Possible Blockers 
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 TIMEOUT , Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=5139905]]

{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=5139891]]

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5139941buildTypeId=IgniteTests24Java8_RunAll]

> Add ability to disable check crc sums of stored pages due to 
> invalidate_indexes.
> 
>
> Key: IGNITE-12761
> URL: https://issues.apache.org/jira/browse/IGNITE-12761
> Project: Ignite
>  Issue Type: Bug
>Reporter: Philipp Masharov
>Assignee: Philipp Masharov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Add additional param to validate_indexes command
> org.apache.ignite.internal.commandline.cache.CacheSubcommands#VALIDATE_INDEXES*like
>  here: 
> org.apache.ignite.internal.commandline.cache.argument.IdleVerifyCommandArg#CHECK_CRC
> now by default this check is always enabled, need to be configurable like the 
> same one in IdleVerifyCommandArg



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-12808) Allow create tables for existing caches

2020-03-19 Thread Mikhail Cherkasov (Jira)
Mikhail Cherkasov created IGNITE-12808:
--

 Summary: Allow create tables for existing caches
 Key: IGNITE-12808
 URL: https://issues.apache.org/jira/browse/IGNITE-12808
 Project: Ignite
  Issue Type: New Feature
  Components: sql
Reporter: Mikhail Cherkasov


If you have a big cache with a lot of data and you need to index it, right now 
you have to destroy cache and create a new one to index your data.  Or create a 
new cache with a table and reload it to  data to the new cache which definitely 
is time-consuming and super inconvenient.

I believe we can allow users to create tables for existing caches.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Alexey (Jira)


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

Alexey edited comment on IGNITE-8152 at 3/19/20, 7:18 PM:
--

h4. [Taras 
Ledkov|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=tledkov-gridgain],
 could you help me.

I don’t understand what’s wrong. All my tests work and do not affect the 
operation of other components of the application. Despite this, the TС shows 
some problems. This is normal? or do I need to run the assembly with some 
settings?

(I have done rebase, and I have actual repo)

Or I created a branch from an unstable version and get non-working tests of 
other components


was (Author: aleksei_litsov):
h4. [Taras 
Ledkov|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=tledkov-gridgain],
 could you help me.

I don’t understand what’s wrong. All my tests work and do not affect the 
operation of other components of the application. Despite this, the TС shows 
some problems. This is normal? or do I need to run the assembly with some 
settings?

(I have done rebase, and I have actual repo)

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
> Attachments: image-2020-03-19-16-01-42-979.png
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Alexey (Jira)


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

Alexey edited comment on IGNITE-8152 at 3/19/20, 7:10 PM:
--

h4. [Taras 
Ledkov|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=tledkov-gridgain],
 could you help me.

I don’t understand what’s wrong. All my tests work and do not affect the 
operation of other components of the application. Despite this, the TС shows 
some problems. This is normal? or do I need to run the assembly with some 
settings?

(I have done rebase, and I have actual repo)


was (Author: aleksei_litsov):
h4. [Taras 
Ledkov|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=tledkov-gridgain],
 could you help me.

I don’t understand what’s wrong. All my tests work and do not affect the 
operation of other components of the application. Despite this, the TС shows 
some problems. This is normal? or do I need to run the assembly with some 
settings?

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
> Attachments: image-2020-03-19-16-01-42-979.png
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Alexey (Jira)


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

Alexey commented on IGNITE-8152:


h4. [Taras 
Ledkov|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=tledkov-gridgain],
 could you help me.

I don’t understand what’s wrong. All my tests work and do not affect the 
operation of other components of the application. Despite this, the TС shows 
some problems. This is normal? or do I need to run the assembly with some 
settings?

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
> Attachments: image-2020-03-19-16-01-42-979.png
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-8152:
---

{panel:title=Branch: [pull/7521/head] Base: [master] : Possible Blockers 
(5)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 6{color} [[tests 0 Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=5140139]]

{color:#d04437}Cache 5{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=5140138]]
* IgniteCacheTestSuite5: 
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillCrdWithPersistence[ATOMIC]
 - Test has low fail rate in base branch 0,0% and is not flaky

{color:#d04437}Platform .NET{color} [[tests 
2|https://ci.ignite.apache.org/viewLog.html?buildId=5140155]]
* exe: CancellationTest.TestClosures - Test has low fail rate in base branch 
0,0% and is not flaky
* exe: CacheTest.TestCacheWithExpirationDoesNotAffectKeepBinarySettings - Test 
has low fail rate in base branch 0,0% and is not flaky

{color:#d04437}MVCC Cache 1{color} [[tests 0 TIMEOUT 
|https://ci.ignite.apache.org/viewLog.html?buildId=5140169]]

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5139431buildTypeId=IgniteTests24Java8_RunAll]

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
> Attachments: image-2020-03-19-16-01-42-979.png
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12806) Incorret usage of Class.isAssignableFrom in SystemViewLocal and SystemViewMBean classes

2020-03-19 Thread Andrey N. Gura (Jira)


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

Andrey N. Gura updated IGNITE-12806:

Environment: (was: Inverted usage )

> Incorret usage of Class.isAssignableFrom in SystemViewLocal and 
> SystemViewMBean classes
> ---
>
> Key: IGNITE-12806
> URL: https://issues.apache.org/jira/browse/IGNITE-12806
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey N. Gura
>Priority: Major
>  Labels: IEP-35
> Fix For: 2.8.1
>
>
> Classes {{SystemViewLocal}} and {{SystemViewMBean}} uses method 
> {{Class.isAssignableFrom}} in incorrect manner. I given cases relation is 
> inverted and doesn't have any sense. In most cases usages of 
> {{Class.isAssignableFrom}} could be avoided.
> See creation of {{AttributeVisitor}} and {{AttributeWithValueVisitor}} 
> instance in mentioned classes.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12772) JmxMetricExporterSpi uses log method which must not be used in production code

2020-03-19 Thread Andrey N. Gura (Jira)


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

Andrey N. Gura updated IGNITE-12772:

Labels: IEP-35  (was: )

> JmxMetricExporterSpi uses log method which must not be used in production code
> --
>
> Key: IGNITE-12772
> URL: https://issues.apache.org/jira/browse/IGNITE-12772
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey N. Gura
>Priority: Minor
>  Labels: IEP-35
> Fix For: 2.8.1
>
>
> {{JmxMetricExporterSpi.register()}} method uses {{IgniteUtils.debug()}} 
> method that log on {{INFO}} level instead of {{DEBUG}} because it needs only 
> for debug purposes. Should be replaced by explicit {{log.debug()}} invocation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12772) JmxMetricExporterSpi uses log method which must not be used in production code

2020-03-19 Thread Andrey N. Gura (Jira)


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

Andrey N. Gura updated IGNITE-12772:

Ignite Flags:   (was: Docs Required,Release Notes Required)

> JmxMetricExporterSpi uses log method which must not be used in production code
> --
>
> Key: IGNITE-12772
> URL: https://issues.apache.org/jira/browse/IGNITE-12772
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey N. Gura
>Priority: Minor
> Fix For: 2.8.1
>
>
> {{JmxMetricExporterSpi.register()}} method uses {{IgniteUtils.debug()}} 
> method that log on {{INFO}} level instead of {{DEBUG}} because it needs only 
> for debug purposes. Should be replaced by explicit {{log.debug()}} invocation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-12807) Key and Value fields with same name and SQL DML

2020-03-19 Thread Alexey Kukushkin (Jira)
Alexey Kukushkin created IGNITE-12807:
-

 Summary: Key and Value fields with same name and SQL DML
 Key: IGNITE-12807
 URL: https://issues.apache.org/jira/browse/IGNITE-12807
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


Key/Value API allows both the Key and Value have fields with same name. This is 
a very popular arrangement since most users are ready to sacrifice extra memory 
footprint for the sake of having a self-sufficient value entity.

Using SQL DML to update such an entry will update only the key field, leaving 
the value field unchanged. This is a huge usability issue for the mixed K/V and 
SQL API apps.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-12806) Incorret usage of Class.isAssignableFrom in SystemViewLocal and SystemViewMBean classes

2020-03-19 Thread Andrey N. Gura (Jira)
Andrey N. Gura created IGNITE-12806:
---

 Summary: Incorret usage of Class.isAssignableFrom in 
SystemViewLocal and SystemViewMBean classes
 Key: IGNITE-12806
 URL: https://issues.apache.org/jira/browse/IGNITE-12806
 Project: Ignite
  Issue Type: Bug
 Environment: Inverted usage 
Reporter: Andrey N. Gura
 Fix For: 2.8.1


Classes {{SystemViewLocal}} and {{SystemViewMBean}} uses method 
{{Class.isAssignableFrom}} in incorrect manner. I given cases relation is 
inverted and doesn't have any sense. In most cases usages of 
{{Class.isAssignableFrom}} could be avoided.

See creation of {{AttributeVisitor}} and {{AttributeWithValueVisitor}} instance 
in mentioned classes.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-10075) Avoid binary configurations of Ignite Java service params and result when calling it from Ignite.NET

2020-03-19 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin updated IGNITE-10075:
--
Labels: sbcf  (was: )

> Avoid binary configurations of Ignite Java service params and result when 
> calling it from Ignite.NET
> 
>
> Key: IGNITE-10075
> URL: https://issues.apache.org/jira/browse/IGNITE-10075
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: sbcf
>
> Presently if there is an Ignite Java service taking parameters of complex 
> (composite) types and returning a result of complex type then all the complex 
> types must be explicitly specified in the binary configuration.
> We need to enhance Ignite not to require binary configuration assuming that 
> we use the same type, package/namespace and field/property names on both the 
> .NET and Java sides (or provide a custom name mapper for relaxed naming 
> conventions).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-10100) No public Java API to call Ignite.NET service

2020-03-19 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin updated IGNITE-10100:
--
Labels: sbcf  (was: )

> No public Java API to call Ignite.NET service
> -
>
> Key: IGNITE-10100
> URL: https://issues.apache.org/jira/browse/IGNITE-10100
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: sbcf
>
> Ignite wraps .NET services in PlatformDotNetServiceImpl implementing 
> PlatformService interface.
> PlatformService is defined in internal Ignite package 
> apache.ignite.internal.processors.platform.services. It exposes
> {{ invokeMethod(methodName, Object[] params): Object}}
> to call any service method dynamically. Right now there is no Ignite public 
> API to call a PlatformService using static typing.
> We need to develop a public API to call PlatformDotNetServiceImpl using 
> static typing in Java.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-10073) Ignite NuGet package without embedded Ignite JARs

2020-03-19 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin updated IGNITE-10073:
--
Labels: sbcf  (was: )

> Ignite NuGet package without embedded Ignite JARs
> -
>
> Key: IGNITE-10073
> URL: https://issues.apache.org/jira/browse/IGNITE-10073
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: sbcf
>
> The existing Apache.Ignite NuGet package includes Ignite JARs deployed into 
> the "libs" directory in the .NET project output directory upon the package 
> installation.
> We prefer using external Ignite JARs from $IGNITE_HOME/libs instead of the 
> JARs in the local libs directory.
> Right now we have to manually remove local "libs" directory after every 
> Apache.Ignite package installation or upgrade.
> It would help us having another Ignite NuGet package without the embedded 
> Ignite JARs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (IGNITE-10074) Structured Exception information is lost when Ignite .NET client calls Ignite Java service

2020-03-19 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin closed IGNITE-10074.
-

> Structured Exception information is lost when Ignite .NET client calls Ignite 
> Java service
> --
>
> Key: IGNITE-10074
> URL: https://issues.apache.org/jira/browse/IGNITE-10074
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>
> Suppose an Ignite service in Java throws *new 
> ModelVerificationException(“ERROR!”)* to signal about a failure.
> An Ignite.NET client of such a Java service would receive this exception:
> Apache.Ignite.Core.Services.ServiceInvocationException
>  * *Message*: Proxy method invocation failed with an exception. Examine 
> InnerException for details.
>  * *InnerException*: Apache.Ignite.Core.Common.IgniteException
> o   *Message*: ERROR!
> o   *InnerException*: Apache.Ignite.Core.Common.JavaException
>  * *JavaClassName*: class org.apache.ignite.IgniteCheckedException
>  * *JavaMessage*: ERROR!
>  * *InnerException*: null
>  * *Message*: class org.apache.ignite.IgniteCheckedException: ERROR!
>    at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7332)
>    at 
> org.apache.ignite.internal.processors.platform.services.PlatformServices$ServiceProxyHolder.invoke(PlatformServices.java:589)
>    at 
> org.apache.ignite.internal.processors.platform.services.PlatformServices.processInObjectStreamOutObjectStream(PlatformServices.java:289)
>    at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inObjectStreamOutObjectStream(PlatformTargetProxyImpl.java:172)
> Caused by: ModelVerificationException: ERROR!
>    at ... 
> Ignite service wraps the custom ModelVerificationException in a 
> IgniteCheckedException, which we get information for on the client side. 
> There is no structured information about the custom exception in the client.
> We need to have information about the custom exception on the client.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-10074) Structured Exception information is lost when Ignite .NET client calls Ignite Java service

2020-03-19 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin resolved IGNITE-10074.
---
Resolution: Won't Fix

No more requests for this enhancement

> Structured Exception information is lost when Ignite .NET client calls Ignite 
> Java service
> --
>
> Key: IGNITE-10074
> URL: https://issues.apache.org/jira/browse/IGNITE-10074
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>
> Suppose an Ignite service in Java throws *new 
> ModelVerificationException(“ERROR!”)* to signal about a failure.
> An Ignite.NET client of such a Java service would receive this exception:
> Apache.Ignite.Core.Services.ServiceInvocationException
>  * *Message*: Proxy method invocation failed with an exception. Examine 
> InnerException for details.
>  * *InnerException*: Apache.Ignite.Core.Common.IgniteException
> o   *Message*: ERROR!
> o   *InnerException*: Apache.Ignite.Core.Common.JavaException
>  * *JavaClassName*: class org.apache.ignite.IgniteCheckedException
>  * *JavaMessage*: ERROR!
>  * *InnerException*: null
>  * *Message*: class org.apache.ignite.IgniteCheckedException: ERROR!
>    at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7332)
>    at 
> org.apache.ignite.internal.processors.platform.services.PlatformServices$ServiceProxyHolder.invoke(PlatformServices.java:589)
>    at 
> org.apache.ignite.internal.processors.platform.services.PlatformServices.processInObjectStreamOutObjectStream(PlatformServices.java:289)
>    at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inObjectStreamOutObjectStream(PlatformTargetProxyImpl.java:172)
> Caused by: ModelVerificationException: ERROR!
>    at ... 
> Ignite service wraps the custom ModelVerificationException in a 
> IgniteCheckedException, which we get information for on the client side. 
> There is no structured information about the custom exception in the client.
> We need to have information about the custom exception on the client.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12773) Reduce number of cluster deactivation methods in internal API.

2020-03-19 Thread Nikolay Izhikov (Jira)


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

Nikolay Izhikov commented on IGNITE-12773:
--

LGTM.

[~vladsz83] Please, take a bot visa prior merge.

> Reduce number of cluster deactivation methods in internal API.
> --
>
> Key: IGNITE-12773
> URL: https://issues.apache.org/jira/browse/IGNITE-12773
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Fix For: 2.9
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> To reduce number of cluster deactivation methods in internal API we might:
> {code:java}
> 1.Remove
> GridClientClusterState#active()
> 2.Remove
> GridClientClusterState#active(boolean active)
> 3.Remove
> IGridClusterStateProcessor#changeGlobalState(
> boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 4.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 5.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 6.Remove 
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 7.Add boolean isAutoAdjust to 
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 8.Add @Override to 
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 9.  Remove, combine with #8:
> IGridClusterStateProcessor#changeGlobalState0(
> ClusterState state,
> BaselineTopology blt,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> ) 
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-10608) SpringDataExample fails with java.lang.AbstractMethodError

2020-03-19 Thread Stanislav Lukyanov (Jira)


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

Stanislav Lukyanov commented on IGNITE-10608:
-

Every change to examples/pom.xml must be reflected in 
examples/pom-standalone.xml. It's obscure, but it is what it is.

Need to apply the same change with dependency exclusions done in IGNITE-8480 to 
pom-standalone.xml.

> SpringDataExample fails with java.lang.AbstractMethodError
> --
>
> Key: IGNITE-10608
> URL: https://issues.apache.org/jira/browse/IGNITE-10608
> Project: Ignite
>  Issue Type: Bug
>  Components: examples
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Priority: Major
>
> Open example project in IDEA, compile and run {{SpringDataExample}}:
> {noformat}
> [23:18:34] Topology snapshot [ver=1, locNode=d4e3a93b, servers=1, clients=0, 
> state=ACTIVE, CPUs=4, offheap=4.8GB, heap=5.3GB]
> [23:18:34] Ignite node stopped OK [name=springDataNode, uptime=00:00:00.120]
> Exception in thread "main" 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'personRepository': Initialization of bean failed; nested exception 
> is java.lang.AbstractMethodError
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:564)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:312)
>   at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:308)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>   at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:742)
>   at 
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:867)
>   at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:543)
>   at 
> org.apache.ignite.examples.springdata.SpringDataExample.igniteSpringDataInit(SpringDataExample.java:79)
>   at 
> org.apache.ignite.examples.springdata.SpringDataExample.main(SpringDataExample.java:52)
> Caused by: java.lang.AbstractMethodError
>   at 
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:99)
>   at 
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:302)
>   at 
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:129)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1537)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1284)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:553)
>   ... 10 more
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12805) Node fails to restart

2020-03-19 Thread Sarunas Valaskevicius (Jira)


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

Sarunas Valaskevicius updated IGNITE-12805:
---
Description: 
1. nodes have default persistence false, but there is a cache region with 
persistence on.

2. a cluster starts ok with ignite data directory clean

3. but when the nodes are restarted, they fail and can never join the cluster 
again:

 
{code:java}
12:352020-03-19_13:34:30.273 [main-0] ERROR 
o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors, 
node will be stopped and close connectionsjava.lang.NullPointerException: null
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
at 
org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) 
{code}

  was:
1. nodes have default persistence false, but there is a cache region with 
persistence on.

2. a cluster starts ok with ignite data directory clean

3. but when the nodes are restarted, they fail and can never join the cluster 
again:

 
{code:java}
12:352020-03-19_13:34:30.273 [main-0] ERROR 
o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors, 
node will be stopped and close connectionsjava.lang.NullPointerException: null  
  at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
at 
org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
at 
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254)at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)   
 at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) {code}


> Node fails to restart
> -
>
> Key: IGNITE-12805
> URL: https://issues.apache.org/jira/browse/IGNITE-12805
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.8
> 

[jira] [Updated] (IGNITE-12805) Node fails to restart

2020-03-19 Thread Sarunas Valaskevicius (Jira)


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

Sarunas Valaskevicius updated IGNITE-12805:
---
Description: 
1. nodes have default persistence false, but there is a cache region with 
persistence on.

2. a cluster starts ok with ignite data directory clean

3. but when the nodes are restarted, they fail and can never join the cluster 
again:

 
{code:java}
12:352020-03-19_13:34:30.273 [main-0] ERROR 
o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors, 
node will be stopped and close connections
java.lang.NullPointerException: null
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
at 
org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) 
{code}

  was:
1. nodes have default persistence false, but there is a cache region with 
persistence on.

2. a cluster starts ok with ignite data directory clean

3. but when the nodes are restarted, they fail and can never join the cluster 
again:

 
{code:java}
12:352020-03-19_13:34:30.273 [main-0] ERROR 
o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors, 
node will be stopped and close connectionsjava.lang.NullPointerException: null
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
at 
org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) 
{code}


> Node fails to restart
> -
>
> Key: IGNITE-12805
> URL: https://issues.apache.org/jira/browse/IGNITE-12805
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.8
>   

[jira] [Commented] (IGNITE-12769) MetricRegistryMBean and OpenCensusExporterSpi have memory leak

2020-03-19 Thread Nikolay Izhikov (Jira)


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

Nikolay Izhikov commented on IGNITE-12769:
--

[~agura] Sorry, for that.

I've removed unused imports.
I also checked both OpenCensusMetricExporterSpiTest and JmxExporterSpiTest and 
it's ok.

Run all - 
https://ci.ignite.apache.org/viewQueued.html?itemId=5140069=queuedBuildOverviewTab

Do you think absence of the visa is blocking review?

> MetricRegistryMBean and OpenCensusExporterSpi have memory leak
> --
>
> Key: IGNITE-12769
> URL: https://issues.apache.org/jira/browse/IGNITE-12769
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.8.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{MetricRegistryMBean}} and {{OpenCensusExporterSpi}} have memory leak. 
> To the following maps values add but never remove (i.e. on remove 
> corresponding histogram or on change histogram buckets layout):
> * {{MetricRegistryMBean.histogramNames}}
> * {{OpenCensusMetricExporterSpi.histogramNames}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12768) MetricRegistryMBean doesn't show histogram values in case when histogram name contains underscore character

2020-03-19 Thread Andrey N. Gura (Jira)


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

Andrey N. Gura commented on IGNITE-12768:
-

[~nizhikov] [~NSAmelchev] Code could be simpler and shorter if you just change 
metric name format from "name__" to "name._". It looks 
logically and last dot in the name always split name and bounds.

> MetricRegistryMBean doesn't show histogram values in case when histogram name 
> contains underscore character
> ---
>
> Key: IGNITE-12768
> URL: https://issues.apache.org/jira/browse/IGNITE-12768
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-35
> Fix For: 2.8.1
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {{MetricRegistryMBean}} doesn't show histogram values in case when histogram 
> name contains underscore character.
> The problem in {{MetricRegistryMBean.searchHistogram()}} method which relies 
> on first underscore character in the fully qualified metric name. This method 
> also use relatively old and not effective API for string parsing (this API 
> implementation is synchronized). It should be replaced by simple 
> {{String.lastIndexOf()}} for example. 
> Reproducer:
> {code:java}
> package org.apache.ignite.spi.metric.jmx;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.internal.processors.metric.MetricRegistry;
> import org.apache.ignite.internal.util.typedef.internal.U;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.junit.Test;
> import javax.management.*;
> import java.lang.management.ManagementFactory;
> public class MetricRegistryMBeanTest extends GridCommonAbstractTest {
> private static final String REGISTRY_NAME = "test_registry";
> private static final String VALID_HISTOGRAM_NAME = "testhist";
> private static final String INVALID_HISTOGRAM_NAME = "test_hist";
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> JmxMetricExporterSpi exporterSpi = new JmxMetricExporterSpi();
> cfg.setMetricExporterSpi(exporterSpi);
> return cfg;
> }
> @Test public void testBean() throws Exception {
> Ignite ignite = startGrid();
> MetricRegistry reg = 
> ((IgniteEx)ignite).context().metric().registry(REGISTRY_NAME);
> reg.histogram(VALID_HISTOGRAM_NAME, new long[] {10, 100}, null);
> reg.histogram(INVALID_HISTOGRAM_NAME, new long[] {10, 100}, null);
> assertNotNull(mbean(ignite).getAttribute(VALID_HISTOGRAM_NAME + '_' + 
> 10 + '_' + 100));
> assertEquals(0L, mbean(ignite).getAttribute(VALID_HISTOGRAM_NAME + 
> '_' + 10 + '_' + 100));
> assertNotNull(mbean(ignite).getAttribute(INVALID_HISTOGRAM_NAME + '_' 
> + 10 + '_' + 100));
> assertEquals(0L, mbean(ignite).getAttribute(INVALID_HISTOGRAM_NAME + 
> '_' + 10 + '_' + 100));
> }
> private static DynamicMBean mbean(Ignite ignite) {
> try {
> ObjectName mbeanName = U.makeMBeanName(ignite.name(), null, 
> REGISTRY_NAME);
> MBeanServer mbeanSrv = ManagementFactory.getPlatformMBeanServer();
> if (!mbeanSrv.isRegistered(mbeanName))
> fail("MBean is not registered: " + 
> mbeanName.getCanonicalName());
> return MBeanServerInvocationHandler.newProxyInstance(mbeanSrv, 
> mbeanName, DynamicMBean.class, false);
> } catch (MalformedObjectNameException e) {
> throw new IgniteException(e);
> }
> }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12769) MetricRegistryMBean and OpenCensusExporterSpi have memory leak

2020-03-19 Thread Andrey N. Gura (Jira)


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

Andrey N. Gura commented on IGNITE-12769:
-

[~nizhikov] Could you please get TC bot visa first? At least now check style 
fails due to unused imports.

> MetricRegistryMBean and OpenCensusExporterSpi have memory leak
> --
>
> Key: IGNITE-12769
> URL: https://issues.apache.org/jira/browse/IGNITE-12769
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.8.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{MetricRegistryMBean}} and {{OpenCensusExporterSpi}} have memory leak. 
> To the following maps values add but never remove (i.e. on remove 
> corresponding histogram or on change histogram buckets layout):
> * {{MetricRegistryMBean.histogramNames}}
> * {{OpenCensusMetricExporterSpi.histogramNames}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-8152:
---

{panel:title=Branch: [pull/7521/head] Base: [master] : Possible Blockers 
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 6{color} [[tests 0 Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=5139385]]

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5139431buildTypeId=IgniteTests24Java8_RunAll]

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
> Attachments: image-2020-03-19-16-01-42-979.png
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-8152:
--

Hi, I mean the run All status of TC.
See for example: IGNITE-12740
[TC Bot|https://mtcga.gridgain.com/]


> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
> Attachments: image-2020-03-19-16-01-42-979.png
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12761) Add ability to disable check crc sums of stored pages due to invalidate_indexes.

2020-03-19 Thread Philipp Masharov (Jira)


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

Philipp Masharov commented on IGNITE-12761:
---

[~slava.koptilin]Thanks! I replied to the comment.

> Add ability to disable check crc sums of stored pages due to 
> invalidate_indexes.
> 
>
> Key: IGNITE-12761
> URL: https://issues.apache.org/jira/browse/IGNITE-12761
> Project: Ignite
>  Issue Type: Bug
>Reporter: Philipp Masharov
>Assignee: Philipp Masharov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Add additional param to validate_indexes command
> org.apache.ignite.internal.commandline.cache.CacheSubcommands#VALIDATE_INDEXES*like
>  here: 
> org.apache.ignite.internal.commandline.cache.argument.IdleVerifyCommandArg#CHECK_CRC
> now by default this check is always enabled, need to be configurable like the 
> same one in IdleVerifyCommandArg



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12805) Node fails to restart

2020-03-19 Thread Sarunas Valaskevicius (Jira)


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

Sarunas Valaskevicius updated IGNITE-12805:
---
Priority: Blocker  (was: Major)

> Node fails to restart
> -
>
> Key: IGNITE-12805
> URL: https://issues.apache.org/jira/browse/IGNITE-12805
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.8
>Reporter: Sarunas Valaskevicius
>Priority: Blocker
>
> 1. nodes have default persistence false, but there is a cache region with 
> persistence on.
> 2. a cluster starts ok with ignite data directory clean
> 3. but when the nodes are restarted, they fail and can never join the cluster 
> again:
>  
> {code:java}
> 12:352020-03-19_13:34:30.273 [main-0] ERROR 
> o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors, 
> node will be stopped and close connectionsjava.lang.NullPointerException: 
> nullat 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
> at 
> org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) 
>at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) 
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12761) Add ability to disable check crc sums of stored pages due to invalidate_indexes.

2020-03-19 Thread Vyacheslav Koptilin (Jira)


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

Vyacheslav Koptilin commented on IGNITE-12761:
--

Hello [~fi1ipx],

I left one minor comment in the PR. Could you please take a look?

> Add ability to disable check crc sums of stored pages due to 
> invalidate_indexes.
> 
>
> Key: IGNITE-12761
> URL: https://issues.apache.org/jira/browse/IGNITE-12761
> Project: Ignite
>  Issue Type: Bug
>Reporter: Philipp Masharov
>Assignee: Philipp Masharov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Add additional param to validate_indexes command
> org.apache.ignite.internal.commandline.cache.CacheSubcommands#VALIDATE_INDEXES*like
>  here: 
> org.apache.ignite.internal.commandline.cache.argument.IdleVerifyCommandArg#CHECK_CRC
> now by default this check is always enabled, need to be configurable like the 
> same one in IdleVerifyCommandArg



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Alexey (Jira)


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

Alexey edited comment on IGNITE-8152 at 3/19/20, 1:02 PM:
--

[~tledkov-gridgain], the code style has already been fixed. On TC tests passed

 

!image-2020-03-19-16-01-42-979.png|width=717,height=93!


was (Author: aleksei_litsov):
[~tledkov-gridgain], the code style has already been fixed. On TC tests passed

 

!image-2020-03-19-16-01-42-979.png!

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
> Attachments: image-2020-03-19-16-01-42-979.png
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Alexey (Jira)


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

Alexey edited comment on IGNITE-8152 at 3/19/20, 1:01 PM:
--

[~tledkov-gridgain], the code style has already been fixed. On TC tests passed

 

!image-2020-03-19-16-01-42-979.png!


was (Author: aleksei_litsov):
[~tledkov-gridgain], the code style has already been fixed. On TC tests passed

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
> Attachments: image-2020-03-19-16-01-42-979.png
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-12805) Node fails to restart

2020-03-19 Thread Sarunas Valaskevicius (Jira)
Sarunas Valaskevicius created IGNITE-12805:
--

 Summary: Node fails to restart
 Key: IGNITE-12805
 URL: https://issues.apache.org/jira/browse/IGNITE-12805
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.8
Reporter: Sarunas Valaskevicius


1. nodes have default persistence false, but there is a cache region with 
persistence on.

2. a cluster starts ok with ignite data directory clean

3. but when the nodes are restarted, they fail and can never join the cluster 
again:

 
{code:java}
12:352020-03-19_13:34:30.273 [main-0] ERROR 
o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors, 
node will be stopped and close connectionsjava.lang.NullPointerException: null  
  at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
at 
org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
at 
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254)at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)   
 at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (IGNITE-10072) Install-Package Apache.Ignite disables existing conditional post-build events

2020-03-19 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin closed IGNITE-10072.
-

> Install-Package Apache.Ignite disables existing conditional post-build events
> -
>
> Key: IGNITE-10072
> URL: https://issues.apache.org/jira/browse/IGNITE-10072
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>
> Setup:
>  # A *.csproj file targeting .NET Framework with any one ore more conditional 
> post-build events specified opened in Visual Studio
> Steps to reproduce:
>  # In Visual Studio -> Package Manager Console run "Install-Package 
> Apache.Ignite"
>  # Open the csproj file in a test editor and check the post-build events 
> Expected:
>  # Package Apache.Ignite installed OK
>  # The command to copy Ignite libs from the NuGet package into target 
> directory is appended to all the existing post-build events 
> Actual:
>  # As expected
>  # A new unconditional post-build event to copy Ignite libs from the NuGet 
> package into target directory is created and added after all the initial 
> post-build events. This effectively disables all the initial post-build 
> events since MSBuild executes only the last post-build event.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-10072) Install-Package Apache.Ignite disables existing conditional post-build events

2020-03-19 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin resolved IGNITE-10072.
---
Resolution: Won't Fix

The user is OK with a workaround.

> Install-Package Apache.Ignite disables existing conditional post-build events
> -
>
> Key: IGNITE-10072
> URL: https://issues.apache.org/jira/browse/IGNITE-10072
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>
> Setup:
>  # A *.csproj file targeting .NET Framework with any one ore more conditional 
> post-build events specified opened in Visual Studio
> Steps to reproduce:
>  # In Visual Studio -> Package Manager Console run "Install-Package 
> Apache.Ignite"
>  # Open the csproj file in a test editor and check the post-build events 
> Expected:
>  # Package Apache.Ignite installed OK
>  # The command to copy Ignite libs from the NuGet package into target 
> directory is appended to all the existing post-build events 
> Actual:
>  # As expected
>  # A new unconditional post-build event to copy Ignite libs from the NuGet 
> package into target directory is created and added after all the initial 
> post-build events. This effectively disables all the initial post-build 
> events since MSBuild executes only the last post-build event.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (IGNITE-10430) Ignite.NET Data Region Metrics: PagesRead, PagesWritten, PagesReplaced, OffHeapSize, OffheapUsedSize

2020-03-19 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin closed IGNITE-10430.
-

> Ignite.NET Data Region Metrics: PagesRead, PagesWritten, PagesReplaced, 
> OffHeapSize, OffheapUsedSize
> 
>
> Key: IGNITE-10430
> URL: https://issues.apache.org/jira/browse/IGNITE-10430
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>
> Add Ignite.NET Data Region Metrics presently existing in Java but missing in 
> .NET: PagesRead, PagesWritten, PagesReplaced, OffHeapSize, OffheapUsedSize



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-10430) Ignite.NET Data Region Metrics: PagesRead, PagesWritten, PagesReplaced, OffHeapSize, OffheapUsedSize

2020-03-19 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin resolved IGNITE-10430.
---
Resolution: Duplicate

Fixed as part of IGNITE-7128

> Ignite.NET Data Region Metrics: PagesRead, PagesWritten, PagesReplaced, 
> OffHeapSize, OffheapUsedSize
> 
>
> Key: IGNITE-10430
> URL: https://issues.apache.org/jira/browse/IGNITE-10430
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>
> Add Ignite.NET Data Region Metrics presently existing in Java but missing in 
> .NET: PagesRead, PagesWritten, PagesReplaced, OffHeapSize, OffheapUsedSize



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-5551) Optimize service deployment assignments object

2020-03-19 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin resolved IGNITE-5551.
--
Resolution: Duplicate

Fixed as part of IGNITE-9607

> Optimize service deployment assignments object
> --
>
> Key: IGNITE-5551
> URL: https://issues.apache.org/jira/browse/IGNITE-5551
> Project: Ignite
>  Issue Type: Improvement
>  Components: managed services
>Affects Versions: 3.0
>Reporter: Alexey Goncharuk
>Assignee: Alexey Kukushkin
>Priority: Minor
>  Labels: iep-17
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> 1) The deployment assignment is stored using a map [node ID -> number of 
> assigned services]. However, this assignment is not very effective for cases 
> when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in 
> this case, we can avoid assignment recalculation at all. The assignment for 
> this case may look like (eachNode=N). In this case, the assignment does not 
> change and we can effectively skip it during the reassign loop.
> 2) We store zero assignment counters, which does not make sense at all - if 
> there are no service deployments for a node, there should be no corresponding 
> entry in the map at all. The size of assignments for (maxPerCluster > 0) 
> configurations is O(number of nodes in the cluster), but it should be 
> O(maxPerCluster).
> 3) If an assignment did not change, we should not commit the assignment 
> transaction - this is redundant
> 4) Perhaps, it also makes sense to calculate several assignments at once and 
> do a putAll commit instead of single puts - this should also decrease the 
> assignment calculation latency



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (IGNITE-5551) Optimize service deployment assignments object

2020-03-19 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin closed IGNITE-5551.


> Optimize service deployment assignments object
> --
>
> Key: IGNITE-5551
> URL: https://issues.apache.org/jira/browse/IGNITE-5551
> Project: Ignite
>  Issue Type: Improvement
>  Components: managed services
>Affects Versions: 3.0
>Reporter: Alexey Goncharuk
>Assignee: Alexey Kukushkin
>Priority: Minor
>  Labels: iep-17
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> 1) The deployment assignment is stored using a map [node ID -> number of 
> assigned services]. However, this assignment is not very effective for cases 
> when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in 
> this case, we can avoid assignment recalculation at all. The assignment for 
> this case may look like (eachNode=N). In this case, the assignment does not 
> change and we can effectively skip it during the reassign loop.
> 2) We store zero assignment counters, which does not make sense at all - if 
> there are no service deployments for a node, there should be no corresponding 
> entry in the map at all. The size of assignments for (maxPerCluster > 0) 
> configurations is O(number of nodes in the cluster), but it should be 
> O(maxPerCluster).
> 3) If an assignment did not change, we should not commit the assignment 
> transaction - this is redundant
> 4) Perhaps, it also makes sense to calculate several assignments at once and 
> do a putAll commit instead of single puts - this should also decrease the 
> assignment calculation latency



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (IGNITE-9204) Test org.apache.ignite.client.ReliabilityTest@testFailover fails intermittently

2020-03-19 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin closed IGNITE-9204.


> Test org.apache.ignite.client.ReliabilityTest@testFailover fails 
> intermittently
> ---
>
> Key: IGNITE-9204
> URL: https://issues.apache.org/jira/browse/IGNITE-9204
> Project: Ignite
>  Issue Type: Test
>  Components: thin client
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
> Fix For: 2.9
>
>
> According to [Apache Ignite Team 
> City|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1817609924700192054=testDetails],
>  test org.apache.ignite.client.ReliabilityTest@testFailover fails 
> intermittently with this message:
>  
> {noformat}
> java.lang.AssertionError: Ignite cluster is unavailable expected null, but 
> was: unavailable> at 
> org.apache.ignite.client.ReliabilityTest.assertOnUnstableCluster(ReliabilityTest.java:184)
>  at 
> org.apache.ignite.client.ReliabilityTest.testFailover(ReliabilityTest.java:88)
>  * Text was not loaded fully because its' size exceeds 2 MB, see full log 
> for the whole text *
> {noformat}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-9204) Test org.apache.ignite.client.ReliabilityTest@testFailover fails intermittently

2020-03-19 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin resolved IGNITE-9204.
--
Resolution: Won't Fix

Already fixed somewhere else

> Test org.apache.ignite.client.ReliabilityTest@testFailover fails 
> intermittently
> ---
>
> Key: IGNITE-9204
> URL: https://issues.apache.org/jira/browse/IGNITE-9204
> Project: Ignite
>  Issue Type: Test
>  Components: thin client
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
> Fix For: 2.9
>
>
> According to [Apache Ignite Team 
> City|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1817609924700192054=testDetails],
>  test org.apache.ignite.client.ReliabilityTest@testFailover fails 
> intermittently with this message:
>  
> {noformat}
> java.lang.AssertionError: Ignite cluster is unavailable expected null, but 
> was: unavailable> at 
> org.apache.ignite.client.ReliabilityTest.assertOnUnstableCluster(ReliabilityTest.java:184)
>  at 
> org.apache.ignite.client.ReliabilityTest.testFailover(ReliabilityTest.java:88)
>  * Text was not loaded fully because its' size exceeds 2 MB, see full log 
> for the whole text *
> {noformat}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12774) Transaction hangs after too many open files NIO exception

2020-03-19 Thread Alexey Goncharuk (Jira)


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

Alexey Goncharuk updated IGNITE-12774:
--
Ignite Flags:   (was: Release Notes Required)

> Transaction hangs after too many open files NIO exception
> -
>
> Key: IGNITE-12774
> URL: https://issues.apache.org/jira/browse/IGNITE-12774
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Transaction hung after “Open too many files” error and never been finished.
> {code:java}
> import java.net.SocketException;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.cluster.ClusterNode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.failure.StopNodeOrHaltFailureHandler;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.lang.IgniteInClosure;
> import org.apache.ignite.plugin.extensions.communication.Message;
> import org.apache.ignite.spi.IgniteSpiException;
> import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
> 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;
> import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> public class TooManyOpenFilesTest extends GridCommonAbstractTest {
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setFailureHandler(new StopNodeOrHaltFailureHandler())
> .setCommunicationSpi(new TooManyOpenFilesTcpCommunicationSpi())
> .setConsistentId(igniteInstanceName);
> }
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> stopAllGrids();
> cleanPersistenceDir();
> }
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> cleanPersistenceDir();
> super.afterTest();
> }
> public void test() throws Exception {
> IgniteEx crd = startGrids(3);
> crd.cluster().active(true);
> crd.getOrCreateCache(new 
> CacheConfiguration<>().setName(DEFAULT_CACHE_NAME).setAtomicityMode(TRANSACTIONAL).setBackups(1).setCacheMode(PARTITIONED));
> TooManyOpenFilesTcpCommunicationSpi spi = 
> (TooManyOpenFilesTcpCommunicationSpi)grid(2).context().config().getCommunicationSpi();
> try (Transaction tx = 
> grid(1).transactions().txStart(TransactionConcurrency.PESSIMISTIC, 
> TransactionIsolation.REPEATABLE_READ)) {
> IgniteCache cache = 
> grid(1).cache(DEFAULT_CACHE_NAME);
> cache.put(1, 1);
> spi.throwException.set(true);
> cache.put(2, 2);
> cache.put(3, 2);
> cache.put(4, 2);
> // hungs here.
> tx.commit();
> }
> for (int i=0; i < 3 ; i++) {
> assertEquals(1, grid(i).cache(DEFAULT_CACHE_NAME).get(1));
> assertEquals(2, grid(i).cache(DEFAULT_CACHE_NAME).get(2));
> }
> }
> private static class TooManyOpenFilesTcpCommunicationSpi extends 
> TcpCommunicationSpi {
> private final AtomicBoolean throwException = new AtomicBoolean();
> /** {@inheritDoc} */
> @Override public void sendMessage(ClusterNode node, Message msg) 
> throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg);
> }
> /** {@inheritDoc} */
> @Override public void sendMessage(
> ClusterNode node,
> Message msg,
> IgniteInClosure ackC
> ) throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg, ackC);
> }
> private IgniteSpiException getException(ClusterNode node) {
> String checkedExceptionMsg =  "Failed to connect to node (is node 
> still alive?). " +
> "Make sure that each ComputeTask and cache Transaction has a 
> timeout set " +
> "in order to prevent parties from waiting forever in case of 
> network issues " +
> "[nodeId=" + node.id() + ", addrs=null]";
> return new IgniteSpiException("Failed to send message to remote 

[jira] [Commented] (IGNITE-12774) Transaction hangs after too many open files NIO exception

2020-03-19 Thread Alexey Goncharuk (Jira)


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

Alexey Goncharuk commented on IGNITE-12774:
---

Good, will merge the ticket soon.

> Transaction hangs after too many open files NIO exception
> -
>
> Key: IGNITE-12774
> URL: https://issues.apache.org/jira/browse/IGNITE-12774
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Transaction hung after “Open too many files” error and never been finished.
> {code:java}
> import java.net.SocketException;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.cluster.ClusterNode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.failure.StopNodeOrHaltFailureHandler;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.lang.IgniteInClosure;
> import org.apache.ignite.plugin.extensions.communication.Message;
> import org.apache.ignite.spi.IgniteSpiException;
> import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
> 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;
> import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> public class TooManyOpenFilesTest extends GridCommonAbstractTest {
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setFailureHandler(new StopNodeOrHaltFailureHandler())
> .setCommunicationSpi(new TooManyOpenFilesTcpCommunicationSpi())
> .setConsistentId(igniteInstanceName);
> }
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> stopAllGrids();
> cleanPersistenceDir();
> }
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> cleanPersistenceDir();
> super.afterTest();
> }
> public void test() throws Exception {
> IgniteEx crd = startGrids(3);
> crd.cluster().active(true);
> crd.getOrCreateCache(new 
> CacheConfiguration<>().setName(DEFAULT_CACHE_NAME).setAtomicityMode(TRANSACTIONAL).setBackups(1).setCacheMode(PARTITIONED));
> TooManyOpenFilesTcpCommunicationSpi spi = 
> (TooManyOpenFilesTcpCommunicationSpi)grid(2).context().config().getCommunicationSpi();
> try (Transaction tx = 
> grid(1).transactions().txStart(TransactionConcurrency.PESSIMISTIC, 
> TransactionIsolation.REPEATABLE_READ)) {
> IgniteCache cache = 
> grid(1).cache(DEFAULT_CACHE_NAME);
> cache.put(1, 1);
> spi.throwException.set(true);
> cache.put(2, 2);
> cache.put(3, 2);
> cache.put(4, 2);
> // hungs here.
> tx.commit();
> }
> for (int i=0; i < 3 ; i++) {
> assertEquals(1, grid(i).cache(DEFAULT_CACHE_NAME).get(1));
> assertEquals(2, grid(i).cache(DEFAULT_CACHE_NAME).get(2));
> }
> }
> private static class TooManyOpenFilesTcpCommunicationSpi extends 
> TcpCommunicationSpi {
> private final AtomicBoolean throwException = new AtomicBoolean();
> /** {@inheritDoc} */
> @Override public void sendMessage(ClusterNode node, Message msg) 
> throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg);
> }
> /** {@inheritDoc} */
> @Override public void sendMessage(
> ClusterNode node,
> Message msg,
> IgniteInClosure ackC
> ) throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg, ackC);
> }
> private IgniteSpiException getException(ClusterNode node) {
> String checkedExceptionMsg =  "Failed to connect to node (is node 
> still alive?). " +
> "Make sure that each ComputeTask and cache Transaction has a 
> timeout set " +
> "in order to prevent parties from waiting forever in case of 
> network issues " +
> "[nodeId=" + node.id() + ", addrs=null]";
> return new IgniteSpiException("Failed 

[jira] [Updated] (IGNITE-12774) Transaction hangs after too many open files NIO exception

2020-03-19 Thread Alexey Goncharuk (Jira)


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

Alexey Goncharuk updated IGNITE-12774:
--
Ignite Flags: Release Notes Required

> Transaction hangs after too many open files NIO exception
> -
>
> Key: IGNITE-12774
> URL: https://issues.apache.org/jira/browse/IGNITE-12774
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Transaction hung after “Open too many files” error and never been finished.
> {code:java}
> import java.net.SocketException;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.cluster.ClusterNode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.failure.StopNodeOrHaltFailureHandler;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.lang.IgniteInClosure;
> import org.apache.ignite.plugin.extensions.communication.Message;
> import org.apache.ignite.spi.IgniteSpiException;
> import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
> 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;
> import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> public class TooManyOpenFilesTest extends GridCommonAbstractTest {
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setFailureHandler(new StopNodeOrHaltFailureHandler())
> .setCommunicationSpi(new TooManyOpenFilesTcpCommunicationSpi())
> .setConsistentId(igniteInstanceName);
> }
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> stopAllGrids();
> cleanPersistenceDir();
> }
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> cleanPersistenceDir();
> super.afterTest();
> }
> public void test() throws Exception {
> IgniteEx crd = startGrids(3);
> crd.cluster().active(true);
> crd.getOrCreateCache(new 
> CacheConfiguration<>().setName(DEFAULT_CACHE_NAME).setAtomicityMode(TRANSACTIONAL).setBackups(1).setCacheMode(PARTITIONED));
> TooManyOpenFilesTcpCommunicationSpi spi = 
> (TooManyOpenFilesTcpCommunicationSpi)grid(2).context().config().getCommunicationSpi();
> try (Transaction tx = 
> grid(1).transactions().txStart(TransactionConcurrency.PESSIMISTIC, 
> TransactionIsolation.REPEATABLE_READ)) {
> IgniteCache cache = 
> grid(1).cache(DEFAULT_CACHE_NAME);
> cache.put(1, 1);
> spi.throwException.set(true);
> cache.put(2, 2);
> cache.put(3, 2);
> cache.put(4, 2);
> // hungs here.
> tx.commit();
> }
> for (int i=0; i < 3 ; i++) {
> assertEquals(1, grid(i).cache(DEFAULT_CACHE_NAME).get(1));
> assertEquals(2, grid(i).cache(DEFAULT_CACHE_NAME).get(2));
> }
> }
> private static class TooManyOpenFilesTcpCommunicationSpi extends 
> TcpCommunicationSpi {
> private final AtomicBoolean throwException = new AtomicBoolean();
> /** {@inheritDoc} */
> @Override public void sendMessage(ClusterNode node, Message msg) 
> throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg);
> }
> /** {@inheritDoc} */
> @Override public void sendMessage(
> ClusterNode node,
> Message msg,
> IgniteInClosure ackC
> ) throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg, ackC);
> }
> private IgniteSpiException getException(ClusterNode node) {
> String checkedExceptionMsg =  "Failed to connect to node (is node 
> still alive?). " +
> "Make sure that each ComputeTask and cache Transaction has a 
> timeout set " +
> "in order to prevent parties from waiting forever in case of 
> network issues " +
> "[nodeId=" + node.id() + ", addrs=null]";
> return new IgniteSpiException("Failed to send message to remote 
> node: 

[jira] [Commented] (IGNITE-12800) SQL: local queries cursors must be closed or full read to unlock the GridH2Table.

2020-03-19 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-12800:
---

I've added the ticket for refactoring {{ConnectionManager}}: IGNITE-12804
Now It's really mess and hard to understand.

> SQL: local queries cursors must be closed or full read to unlock the 
> GridH2Table.
> -
>
> Key: IGNITE-12800
> URL: https://issues.apache.org/jira/browse/IGNITE-12800
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8.1
>
>
> *Root cause:* local queries cursors must be closed or full read to unlock the 
> GridH2Table.
> *Proposal fix:*
> - modify {{H2ResultSetIterator}} to use "paged mode": iterator reads N 
> records into internal buffer and unlock the tables (similar to 
> {{MapQueryResult}}; later we have to refactor these classes. They must use 
> one code base to fetch data and lok/unlock tables)
> - modify the state logic of the {{QueryCursorImpl}} for lazy mode. Now the 
> real query cancellation isn't called when result set is gathered. It is not 
> valid for lazy mode.
> - add wrapper for iterator at the {{RegisteredQueryCursor}} because the state 
> of query isn't tracked when results are read via Iterator at the client code.
> - fix tests that doesn't close query cursor for local queries.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12800) SQL: local queries cursors must be closed or full read to unlock the GridH2Table.

2020-03-19 Thread Taras Ledkov (Jira)


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

Taras Ledkov updated IGNITE-12800:
--
Ignite Flags:   (was: Docs Required,Release Notes Required)

> SQL: local queries cursors must be closed or full read to unlock the 
> GridH2Table.
> -
>
> Key: IGNITE-12800
> URL: https://issues.apache.org/jira/browse/IGNITE-12800
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8.1
>
>
> *Root cause:* local queries cursors must be closed or full read to unlock the 
> GridH2Table.
> *Proposal fix:*
> - modify {{H2ResultSetIterator}} to use "paged mode": iterator reads N 
> records into internal buffer and unlock the tables (similar to 
> {{MapQueryResult}}; later we have to refactor these classes. They must use 
> one code base to fetch data and lok/unlock tables)
> - modify the state logic of the {{QueryCursorImpl}} for lazy mode. Now the 
> real query cancellation isn't called when result set is gathered. It is not 
> valid for lazy mode.
> - add wrapper for iterator at the {{RegisteredQueryCursor}} because the state 
> of query isn't tracked when results are read via Iterator at the client code.
> - fix tests that doesn't close query cursor for local queries.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-12804) SQL: ConnectionManager refactoring

2020-03-19 Thread Taras Ledkov (Jira)
Taras Ledkov created IGNITE-12804:
-

 Summary: SQL: ConnectionManager refactoring
 Key: IGNITE-12804
 URL: https://issues.apache.org/jira/browse/IGNITE-12804
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.8
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


As of now ConnectionManager is a mess, really hard to understand. We should 
refactor it.

AlsoThreadLocal connection is a root cause of complicated behavior of local 
queries & map queries.

I guess we have to use simple connection pool. 
For better performance several striped by Thread ID connection pools may be 
used.




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-12577) High persistence load can trigger erroneous assert: "Page was pin when we resolve abs pointer, it can not be evicted".

2020-03-19 Thread Stanilovsky Evgeny (Jira)


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

Stanilovsky Evgeny resolved IGNITE-12577.
-
Resolution: Invalid

> High persistence load can trigger erroneous assert: "Page was pin when we 
> resolve abs pointer, it can not be evicted".
> --
>
> Key: IGNITE-12577
> URL: https://issues.apache.org/jira/browse/IGNITE-12577
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures
>Affects Versions: 2.7.6
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For now It seems erroneous assertion in checkpointer code :  "Page was pin 
> when we resolve abs pointer, it can not be evicted", need to be removed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12774) Transaction hangs after too many open files NIO exception

2020-03-19 Thread Sergey Antonov (Jira)


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

Sergey Antonov commented on IGNITE-12774:
-

[~agoncharuk] No, I don't. But I created ticket IGNITE-12803 for investigation.

> Transaction hangs after too many open files NIO exception
> -
>
> Key: IGNITE-12774
> URL: https://issues.apache.org/jira/browse/IGNITE-12774
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Transaction hung after “Open too many files” error and never been finished.
> {code:java}
> import java.net.SocketException;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.cluster.ClusterNode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.failure.StopNodeOrHaltFailureHandler;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.lang.IgniteInClosure;
> import org.apache.ignite.plugin.extensions.communication.Message;
> import org.apache.ignite.spi.IgniteSpiException;
> import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
> 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;
> import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> public class TooManyOpenFilesTest extends GridCommonAbstractTest {
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setFailureHandler(new StopNodeOrHaltFailureHandler())
> .setCommunicationSpi(new TooManyOpenFilesTcpCommunicationSpi())
> .setConsistentId(igniteInstanceName);
> }
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> stopAllGrids();
> cleanPersistenceDir();
> }
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> cleanPersistenceDir();
> super.afterTest();
> }
> public void test() throws Exception {
> IgniteEx crd = startGrids(3);
> crd.cluster().active(true);
> crd.getOrCreateCache(new 
> CacheConfiguration<>().setName(DEFAULT_CACHE_NAME).setAtomicityMode(TRANSACTIONAL).setBackups(1).setCacheMode(PARTITIONED));
> TooManyOpenFilesTcpCommunicationSpi spi = 
> (TooManyOpenFilesTcpCommunicationSpi)grid(2).context().config().getCommunicationSpi();
> try (Transaction tx = 
> grid(1).transactions().txStart(TransactionConcurrency.PESSIMISTIC, 
> TransactionIsolation.REPEATABLE_READ)) {
> IgniteCache cache = 
> grid(1).cache(DEFAULT_CACHE_NAME);
> cache.put(1, 1);
> spi.throwException.set(true);
> cache.put(2, 2);
> cache.put(3, 2);
> cache.put(4, 2);
> // hungs here.
> tx.commit();
> }
> for (int i=0; i < 3 ; i++) {
> assertEquals(1, grid(i).cache(DEFAULT_CACHE_NAME).get(1));
> assertEquals(2, grid(i).cache(DEFAULT_CACHE_NAME).get(2));
> }
> }
> private static class TooManyOpenFilesTcpCommunicationSpi extends 
> TcpCommunicationSpi {
> private final AtomicBoolean throwException = new AtomicBoolean();
> /** {@inheritDoc} */
> @Override public void sendMessage(ClusterNode node, Message msg) 
> throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg);
> }
> /** {@inheritDoc} */
> @Override public void sendMessage(
> ClusterNode node,
> Message msg,
> IgniteInClosure ackC
> ) throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg, ackC);
> }
> private IgniteSpiException getException(ClusterNode node) {
> String checkedExceptionMsg =  "Failed to connect to node (is node 
> still alive?). " +
> "Make sure that each ComputeTask and cache Transaction has a 
> timeout set " +
> "in order to prevent parties from waiting forever in case of 
> network issues " +
> "[nodeId=" + node.id() + ", addrs=null]";
>   

[jira] [Updated] (IGNITE-12803) Investigate exception message on too many open files in different OS.

2020-03-19 Thread Sergey Antonov (Jira)


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

Sergey Antonov updated IGNITE-12803:

Environment: (was: In IGNITE-12774 we introduced node failing if we got 
"too many open files" during open connection. I'm not sure that in all OS we 
will get that message. 
We need to investigate it.)

> Investigate exception message on too many open files in different OS.
> -
>
> Key: IGNITE-12803
> URL: https://issues.apache.org/jira/browse/IGNITE-12803
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergey Antonov
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12803) Investigate exception message on too many open files in different OS.

2020-03-19 Thread Sergey Antonov (Jira)


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

Sergey Antonov updated IGNITE-12803:

Description: 
In IGNITE-12774 we introduced node failing if we got "too many open files" 
during open connection. I'm not sure that in all OS we will get that message. 
We need to investigate it.

> Investigate exception message on too many open files in different OS.
> -
>
> Key: IGNITE-12803
> URL: https://issues.apache.org/jira/browse/IGNITE-12803
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergey Antonov
>Priority: Major
>
> In IGNITE-12774 we introduced node failing if we got "too many open files" 
> during open connection. I'm not sure that in all OS we will get that message. 
> We need to investigate it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-12803) Investigate exception message on too many open files in different OS.

2020-03-19 Thread Sergey Antonov (Jira)
Sergey Antonov created IGNITE-12803:
---

 Summary: Investigate exception message on too many open files in 
different OS.
 Key: IGNITE-12803
 URL: https://issues.apache.org/jira/browse/IGNITE-12803
 Project: Ignite
  Issue Type: Task
 Environment: In IGNITE-12774 we introduced node failing if we got "too 
many open files" during open connection. I'm not sure that in all OS we will 
get that message. 
We need to investigate it.
Reporter: Sergey Antonov






--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Alexey (Jira)


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

Alexey commented on IGNITE-8152:


[~tledkov-gridgain], the code style has already been fixed. On TC tests passed

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12793) Deadlock in the System Pool on Metadata processing

2020-03-19 Thread Sergey Kosarev (Jira)


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

Sergey Kosarev commented on IGNITE-12793:
-

[~sergey-chugunov], actually I've used gidgain community-edition 8.7.10

> Deadlock in the System Pool on Metadata processing
> --
>
> Key: IGNITE-12793
> URL: https://issues.apache.org/jira/browse/IGNITE-12793
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: Sergey Kosarev
>Priority: Major
>
> I've recently tried to apply Ilya's idea 
> (https://issues.apache.org/jira/browse/IGNITE-12663) of minimizing thread 
> pools and tried to set system pool to 3 in my own tests.
>  It caused deadlock on a client node and I think it can happen not only on 
> such small pool values.
> Details are following:
>  I'm not using persistence currently (if it matters).
>  On the client note I use ignite compute to call a job on every server node 
> (there are 3 server nodes in the tests).
> Then I've found in logs:
>  {{[10:55:21] : [Step 1/1] [2020-03-13 10:55:21,773] {grid-timeout-worker-#8} 
> [WARN] [o.a.i.i.IgniteKernal] - Possible thread pool starvation detected (no 
> task completed in last 3ms, is system thread pool size large enough?)
>  [10:55:21] : [Step 1/1] ^-- System thread pool [active=3, idle=0, qSize=9]}}
> I see in threaddumps that all 3 system pool workers do the same - processing 
> of job responses:
>  {{ "sys-#26" #605 daemon prio=5 os_prio=0 tid=0x64a0a800 nid=0x1f34 
> waiting on condition [0x7b91d000]
>  java.lang.Thread.State: WAITING (parking)
>  at sun.misc.Unsafe.park(Native Method)
>  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
>  at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:749)
>  at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:250)
>  at 
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1169)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:285)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:184)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
>  at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
>  at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
>  at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>  at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:306)
>  at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:100)
>  at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
>  at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10493)
>  at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:828)
>  at 
> 

[jira] [Updated] (IGNITE-12761) Add ability to disable check crc sums of stored pages due to invalidate_indexes.

2020-03-19 Thread Sergey Antonov (Jira)


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

Sergey Antonov updated IGNITE-12761:

Fix Version/s: 2.9

> Add ability to disable check crc sums of stored pages due to 
> invalidate_indexes.
> 
>
> Key: IGNITE-12761
> URL: https://issues.apache.org/jira/browse/IGNITE-12761
> Project: Ignite
>  Issue Type: Bug
>Reporter: Philipp Masharov
>Assignee: Philipp Masharov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add additional param to validate_indexes command
> org.apache.ignite.internal.commandline.cache.CacheSubcommands#VALIDATE_INDEXES*like
>  here: 
> org.apache.ignite.internal.commandline.cache.argument.IdleVerifyCommandArg#CHECK_CRC
> now by default this check is always enabled, need to be configurable like the 
> same one in IdleVerifyCommandArg



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-7136) .NET: IndexesAllocatedPages metrics

2020-03-19 Thread Pavel Tupitsyn (Jira)


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

Pavel Tupitsyn commented on IGNITE-7136:


[~GuruStron] closed this one too, thanks.

> .NET: IndexesAllocatedPages metrics
> ---
>
> Key: IGNITE-7136
> URL: https://issues.apache.org/jira/browse/IGNITE-7136
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Nikolay Izhikov
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, iep-6
> Fix For: 2.9
>
>
> New JMX metric implemented in IGNITE-6903.
> We need to add support for this metric to .Net 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (IGNITE-7136) .NET: IndexesAllocatedPages metrics

2020-03-19 Thread Pavel Tupitsyn (Jira)


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

Pavel Tupitsyn closed IGNITE-7136.
--

> .NET: IndexesAllocatedPages metrics
> ---
>
> Key: IGNITE-7136
> URL: https://issues.apache.org/jira/browse/IGNITE-7136
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Nikolay Izhikov
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, iep-6
> Fix For: 2.9
>
>
> New JMX metric implemented in IGNITE-6903.
> We need to add support for this metric to .Net 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12799) Set right SpEL at Spring Data tests

2020-03-19 Thread Vyacheslav Koptilin (Jira)


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

Vyacheslav Koptilin commented on IGNITE-12799:
--

Hello [~schernolyas],

I have merged your fix. Thank you for your efforts!

> Set right SpEL at Spring Data tests
> ---
>
> Key: IGNITE-12799
> URL: https://issues.apache.org/jira/browse/IGNITE-12799
> Project: Ignite
>  Issue Type: Bug
>  Components: spring
>Affects Versions: 2.8.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>Priority: Trivial
> Fix For: 2.8.1
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> PersonExpressionRepository uses  SpEL "@cacheNames.personCacheName". It is 
> wrong. SpEL "#\{cacheNames.personCacheName}" must be used.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-12799) Set right SpEL at Spring Data tests

2020-03-19 Thread Vyacheslav Koptilin (Jira)


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

Vyacheslav Koptilin resolved IGNITE-12799.
--
Resolution: Fixed

> Set right SpEL at Spring Data tests
> ---
>
> Key: IGNITE-12799
> URL: https://issues.apache.org/jira/browse/IGNITE-12799
> Project: Ignite
>  Issue Type: Bug
>  Components: spring
>Affects Versions: 2.8.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>Priority: Trivial
> Fix For: 2.8.1
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> PersonExpressionRepository uses  SpEL "@cacheNames.personCacheName". It is 
> wrong. SpEL "#\{cacheNames.personCacheName}" must be used.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-7136) .NET: IndexesAllocatedPages metrics

2020-03-19 Thread Pavel Tupitsyn (Jira)


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

Pavel Tupitsyn resolved IGNITE-7136.

  Assignee: Pavel Tupitsyn
Resolution: Won't Fix

> .NET: IndexesAllocatedPages metrics
> ---
>
> Key: IGNITE-7136
> URL: https://issues.apache.org/jira/browse/IGNITE-7136
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Nikolay Izhikov
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, iep-6
> Fix For: 2.9
>
>
> New JMX metric implemented in IGNITE-6903.
> We need to add support for this metric to .Net 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12532) .NET: Recognize fields with KeyAttribute and set QueryField.IsKeyField

2020-03-19 Thread Pavel Tupitsyn (Jira)


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

Pavel Tupitsyn updated IGNITE-12532:

Description: 
Populate QueryField.IsKeyField automatically when 
System.ComponentModel.DataAnnotations.KeyAttribute is present. See 
{{QueryEntity.ScanAttributes}}.

This:
{code}
class Person
{
[QuerySqlField]
[Key]
public string EntityId {get; set;}
}

...
new QueryEntity(typeof(string), typeof(Person))
{code}

Should be equivalent to this:
{code}

  

  

{code}

  was:
Populate QueryEntity.KeyFieldName automatically when 
System.ComponentModel.DataAnnotations.KeyAttribute is present. See 
{{QueryEntity.ScanAttributes}}.

This:
{code}
class Person
{
[QuerySqlField]
[Key]
public string EntityId {get; set;}
}

...
new QueryEntity(typeof(string), typeof(Person))
{code}

Should be equivalent to this:
{code}

  

  

{code}


> .NET: Recognize fields with KeyAttribute and set QueryField.IsKeyField
> --
>
> Key: IGNITE-12532
> URL: https://issues.apache.org/jira/browse/IGNITE-12532
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, newbie
>
> Populate QueryField.IsKeyField automatically when 
> System.ComponentModel.DataAnnotations.KeyAttribute is present. See 
> {{QueryEntity.ScanAttributes}}.
> This:
> {code}
> class Person
> {
> [QuerySqlField]
> [Key]
> public string EntityId {get; set;}
> }
> ...
> new QueryEntity(typeof(string), typeof(Person))
> {code}
> Should be equivalent to this:
> {code}
> 
>   
>  isKeyField="true" />
>   
> 
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12532) .NET: Recognize fields with KeyAttribute and set QueryField.IsKeyField

2020-03-19 Thread Pavel Tupitsyn (Jira)


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

Pavel Tupitsyn updated IGNITE-12532:

Summary: .NET: Recognize fields with KeyAttribute and set 
QueryField.IsKeyField  (was: .NET: Recognize fields with KeyAttribute and set 
QueryEntity.KeyFieldName)

> .NET: Recognize fields with KeyAttribute and set QueryField.IsKeyField
> --
>
> Key: IGNITE-12532
> URL: https://issues.apache.org/jira/browse/IGNITE-12532
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, newbie
>
> Populate QueryEntity.KeyFieldName automatically when 
> System.ComponentModel.DataAnnotations.KeyAttribute is present. See 
> {{QueryEntity.ScanAttributes}}.
> This:
> {code}
> class Person
> {
> [QuerySqlField]
> [Key]
> public string EntityId {get; set;}
> }
> ...
> new QueryEntity(typeof(string), typeof(Person))
> {code}
> Should be equivalent to this:
> {code}
>  tableName="ENTITIESTABLEINFO" valueType="ENTITIESTABLEINFO">
>   
> 
>   
> 
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12774) Transaction hangs after too many open files NIO exception

2020-03-19 Thread Alexey Goncharuk (Jira)


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

Alexey Goncharuk commented on IGNITE-12774:
---

[~antonovsergey93], do you know which platforms throw exactly this message? 
Should we add more error message cases for Windows or BSD/zOS, for example?

> Transaction hangs after too many open files NIO exception
> -
>
> Key: IGNITE-12774
> URL: https://issues.apache.org/jira/browse/IGNITE-12774
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Transaction hung after “Open too many files” error and never been finished.
> {code:java}
> import java.net.SocketException;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.cluster.ClusterNode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.failure.StopNodeOrHaltFailureHandler;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.lang.IgniteInClosure;
> import org.apache.ignite.plugin.extensions.communication.Message;
> import org.apache.ignite.spi.IgniteSpiException;
> import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
> 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;
> import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> public class TooManyOpenFilesTest extends GridCommonAbstractTest {
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setFailureHandler(new StopNodeOrHaltFailureHandler())
> .setCommunicationSpi(new TooManyOpenFilesTcpCommunicationSpi())
> .setConsistentId(igniteInstanceName);
> }
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> stopAllGrids();
> cleanPersistenceDir();
> }
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> cleanPersistenceDir();
> super.afterTest();
> }
> public void test() throws Exception {
> IgniteEx crd = startGrids(3);
> crd.cluster().active(true);
> crd.getOrCreateCache(new 
> CacheConfiguration<>().setName(DEFAULT_CACHE_NAME).setAtomicityMode(TRANSACTIONAL).setBackups(1).setCacheMode(PARTITIONED));
> TooManyOpenFilesTcpCommunicationSpi spi = 
> (TooManyOpenFilesTcpCommunicationSpi)grid(2).context().config().getCommunicationSpi();
> try (Transaction tx = 
> grid(1).transactions().txStart(TransactionConcurrency.PESSIMISTIC, 
> TransactionIsolation.REPEATABLE_READ)) {
> IgniteCache cache = 
> grid(1).cache(DEFAULT_CACHE_NAME);
> cache.put(1, 1);
> spi.throwException.set(true);
> cache.put(2, 2);
> cache.put(3, 2);
> cache.put(4, 2);
> // hungs here.
> tx.commit();
> }
> for (int i=0; i < 3 ; i++) {
> assertEquals(1, grid(i).cache(DEFAULT_CACHE_NAME).get(1));
> assertEquals(2, grid(i).cache(DEFAULT_CACHE_NAME).get(2));
> }
> }
> private static class TooManyOpenFilesTcpCommunicationSpi extends 
> TcpCommunicationSpi {
> private final AtomicBoolean throwException = new AtomicBoolean();
> /** {@inheritDoc} */
> @Override public void sendMessage(ClusterNode node, Message msg) 
> throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg);
> }
> /** {@inheritDoc} */
> @Override public void sendMessage(
> ClusterNode node,
> Message msg,
> IgniteInClosure ackC
> ) throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg, ackC);
> }
> private IgniteSpiException getException(ClusterNode node) {
> String checkedExceptionMsg =  "Failed to connect to node (is node 
> still alive?). " +
> "Make sure that each ComputeTask and cache Transaction has a 
> timeout set " +
> "in order to prevent parties from waiting forever in case of 
> network 

[jira] [Updated] (IGNITE-7792) IgniteDatabaseSharedManager refactoring

2020-03-19 Thread Alexey Goncharuk (Jira)


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

Alexey Goncharuk updated IGNITE-7792:
-
Release Note:   (was: Improvement in checkpointing machinery.)

> IgniteDatabaseSharedManager refactoring
> ---
>
> Key: IGNITE-7792
> URL: https://issues.apache.org/jira/browse/IGNITE-7792
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 2.8
>Reporter: Igor Seliverstov
>Assignee: Stanilovsky Evgeny
>Priority: Minor
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently there is no mapping of cacheId to page memory which prevents adding 
> custom persistent structures 
> ({{GridCacheDatabaseSharedManager.WriteCheckpointPages#run}}).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-7792) IgniteDatabaseSharedManager refactoring

2020-03-19 Thread Alexey Goncharuk (Jira)


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

Alexey Goncharuk commented on IGNITE-7792:
--

[~zstan] looks good, thanks! I created a follow-up ticket for further 
refactoring of the class, feel free to pick it up :)
Will merge to master shortly.

> IgniteDatabaseSharedManager refactoring
> ---
>
> Key: IGNITE-7792
> URL: https://issues.apache.org/jira/browse/IGNITE-7792
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 2.8
>Reporter: Igor Seliverstov
>Assignee: Stanilovsky Evgeny
>Priority: Minor
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently there is no mapping of cacheId to page memory which prevents adding 
> custom persistent structures 
> ({{GridCacheDatabaseSharedManager.WriteCheckpointPages#run}}).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-12802) Move checkpoint state fields to CheckpointProgress

2020-03-19 Thread Alexey Goncharuk (Jira)
Alexey Goncharuk created IGNITE-12802:
-

 Summary: Move checkpoint state fields to CheckpointProgress
 Key: IGNITE-12802
 URL: https://issues.apache.org/jira/browse/IGNITE-12802
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Goncharuk


This is a review follow-up for IGNITE-7792. I've noticed that quite a few 
fields in {{GridCacheDatabaseSharedManager}} are related to the state of 
current checkpoint:
{code}
writtenPagesCntr
syncedPagesCntr
evictedPagesCntr
currCheckpointPagesCnt
{code}

After checkpoint is completed, these fields are reset. On the other hand, we 
have a separate class to track the state of current checkpoint: 
{{CheckpointProgressImpl}}. I believe it makes sense to move these fields to 
the separate class. Perhaps, it also makes sense to make this class a top-level 
class.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (IGNITE-12749) Unsupported operation exception on node stop if collisionspi not null

2020-03-19 Thread Yaroslav Molochkov (Jira)


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

Yaroslav Molochkov reassigned IGNITE-12749:
---

Assignee: Yaroslav Molochkov

> Unsupported operation exception on node stop if collisionspi not null
> -
>
> Key: IGNITE-12749
> URL: https://issues.apache.org/jira/browse/IGNITE-12749
> Project: Ignite
>  Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Yaroslav Molochkov
>Priority: Major
>  Labels: newbie
>
> If collision spi specified then on the node stop there are exception:
> {noformat}
> java.lang.UnsupportedOperationException
>   at 
> org.jsr166.ConcurrentLinkedHashMap.clear(ConcurrentLinkedHashMap.java:1542)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.stop(GridJobProcessor.java:376)
>   at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2697)
>   at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2569)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2660)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2623)
>   at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:339)
>   at org.apache.ignite.Ignition.stop(Ignition.java:223)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1316)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1361)
>  {noformat}
> The issue in the next line:
> {code:java}
> public GridJobProcessor(GridKernalContext ctx) {
> // Collision manager is already started and is fully functional.
> jobAlwaysActivate = !ctx.collision().enabled();
> activeJobs = jobAlwaysActivate ? new ConcurrentHashMap GridJobWorker>() :
> new JobsMap(1024, 0.75f, 256);
> {code}
> We need replace JobsMap with the correct implementation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12797) Add command line option to CommandHandler to be able to see full stack trace and cause exception in log in case of error.

2020-03-19 Thread Ilya Kasnacheev (Jira)


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

Ilya Kasnacheev commented on IGNITE-12797:
--

Something akin to
{code}
./control.sh --print-err-stack-trace --status
{code}

Also a non-parameter error should be checked, such as
{code}
./control.sh --print-err-stack-trace --host unresponsive-host --status
{code}

> Add command line option to CommandHandler to be able to see full stack trace 
> and cause exception in log in case of error.
> -
>
> Key: IGNITE-12797
> URL: https://issues.apache.org/jira/browse/IGNITE-12797
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In case of error control.sh can print common error message without any 
> information about root cause of error. Printing full stack trace and cause 
> can ease the analysis. User should be able to turn it on when launching 
> control.sh with specific option.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12799) Set right SpEL at Spring Data tests

2020-03-19 Thread Vyacheslav Koptilin (Jira)


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

Vyacheslav Koptilin commented on IGNITE-12799:
--

Hi [~schernolyas],

Thank you for the added test. I will take a look.

> Set right SpEL at Spring Data tests
> ---
>
> Key: IGNITE-12799
> URL: https://issues.apache.org/jira/browse/IGNITE-12799
> Project: Ignite
>  Issue Type: Bug
>  Components: spring
>Affects Versions: 2.8.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>Priority: Trivial
> Fix For: 2.8.1
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> PersonExpressionRepository uses  SpEL "@cacheNames.personCacheName". It is 
> wrong. SpEL "#\{cacheNames.personCacheName}" must be used.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Taras Ledkov (Jira)


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

Taras Ledkov edited comment on IGNITE-8152 at 3/19/20, 8:26 AM:


[~Aleksei_Litsov], the patch is OK with me. Please fix minor codestyle:
1. {{H2ConnectionWrapper#connection(java.lang.String)}} empty string
2. javadoc for {{BaseSqlTest#executeFrom(java.lang.String, 
org.apache.ignite.Ignite, java.lang.String)}}

What about tests visa from TC Bot?


was (Author: tledkov-gridgain):
[~Aleksei_Litsov], the patch is OK with me. Please fix minor codestyle:
1. {{H2ConnectionWrapper#connection(java.lang.String)}} empty string
2. javadoc for {{BaseSqlTest#executeFrom(java.lang.String, 
org.apache.ignite.Ignite, java.lang.String)}}

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-8152) Forbid empty sql schema name

2020-03-19 Thread Taras Ledkov (Jira)


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

Taras Ledkov commented on IGNITE-8152:
--

[~Aleksei_Litsov], the patch is OK with me. Please fix minor codestyle:
1. {{H2ConnectionWrapper#connection(java.lang.String)}} empty string
2. javadoc for {{BaseSqlTest#executeFrom(java.lang.String, 
org.apache.ignite.Ignite, java.lang.String)}}

> Forbid empty sql schema name
> 
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexey
>Priority: Major
>  Labels: newbie
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should 
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-7792) IgniteDatabaseSharedManager refactoring

2020-03-19 Thread Alexey Goncharuk (Jira)


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

Alexey Goncharuk updated IGNITE-7792:
-
Fix Version/s: 2.9

> IgniteDatabaseSharedManager refactoring
> ---
>
> Key: IGNITE-7792
> URL: https://issues.apache.org/jira/browse/IGNITE-7792
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 2.8
>Reporter: Igor Seliverstov
>Assignee: Stanilovsky Evgeny
>Priority: Minor
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently there is no mapping of cacheId to page memory which prevents adding 
> custom persistent structures 
> ({{GridCacheDatabaseSharedManager.WriteCheckpointPages#run}}).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12797) Add command line option to CommandHandler to be able to see full stack trace and cause exception in log in case of error.

2020-03-19 Thread Kirill Tkalenko (Jira)


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

Kirill Tkalenko commented on IGNITE-12797:
--

[~ilyak] Can you give me an example?

> Add command line option to CommandHandler to be able to see full stack trace 
> and cause exception in log in case of error.
> -
>
> Key: IGNITE-12797
> URL: https://issues.apache.org/jira/browse/IGNITE-12797
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In case of error control.sh can print common error message without any 
> information about root cause of error. Printing full stack trace and cause 
> can ease the analysis. User should be able to turn it on when launching 
> control.sh with specific option.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)