[jira] [Commented] (IGNITE-7122) Page lock status is not checked in BPlusTree.treePrinter methods

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov commented on IGNITE-7122:
--

[~kirill.shirokov], returned from {{readLock(..)}} zero doesn't mean that page 
is locked. This method will wait until whether write lock is freed or page is 
recycled, so that {{  }} output is incorrect. Such node must be just 
skipped.

> Page lock status is not checked in BPlusTree.treePrinter methods
> 
>
> Key: IGNITE-7122
> URL: https://issues.apache.org/jira/browse/IGNITE-7122
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Assignee: Kirill Shirokov
>
> The result of readLock(), which can be 0 is not checked in 
> BPlusTree.treePrinter getChildren() and formatTreeNode() calls:
> {noformat}
> java.lang.AssertionError: 0
> at 
> org.apache.ignite.internal.pagemem.PageUtils.getLong(PageUtils.java:117)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO.getPageId(PageIO.java:279)
> at 
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.checkPageId(BPlusTreeSelfTest.java:2307)
> at 
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$TestTree.onReadUnlock(BPlusTreeSelfTest.java:2445)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readUnlock(PageHandler.java:203)
> at 
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.readUnlock(DataStructure.java:186)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$400(BPlusTree.java:82)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:163)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:120)
> at 
> org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:60)
> at 
> org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:67)
> at 
> org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:32)
> at 
> org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:43)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.printTree(BPlusTree.java:1188)
> at 
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1777)
> at 
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1771)
> at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}
> ...which causes intermittent failures in the BPlusTree unit tests:
> BPlusTreePageMemoryImplTest.testPutRmvSizeSinglePageContention
> BPlusTreeReuseListPageMemoryImplTest.testPutRmvSizeSinglePageContention 



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

[jira] [Comment Edited] (IGNITE-7122) Page lock status is not checked in BPlusTree.treePrinter methods

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov edited comment on IGNITE-7122 at 12/8/17 9:15 PM:
---

[~kirill.shirokov], returned from {{readLock(..)}} zero doesn't mean that page 
is locked. This method will wait until whether write lock is freed or page is 
recycled, so that  output is incorrect. Such node must be just skipped.


was (Author: gvvinblade):
[~kirill.shirokov], returned from {{readLock(..)}} zero doesn't mean that page 
is locked. This method will wait until whether write lock is freed or page is 
recycled, so that {{  }} output is incorrect. Such node must be just 
skipped.

> Page lock status is not checked in BPlusTree.treePrinter methods
> 
>
> Key: IGNITE-7122
> URL: https://issues.apache.org/jira/browse/IGNITE-7122
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Assignee: Kirill Shirokov
>
> The result of readLock(), which can be 0 is not checked in 
> BPlusTree.treePrinter getChildren() and formatTreeNode() calls:
> {noformat}
> java.lang.AssertionError: 0
> at 
> org.apache.ignite.internal.pagemem.PageUtils.getLong(PageUtils.java:117)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO.getPageId(PageIO.java:279)
> at 
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.checkPageId(BPlusTreeSelfTest.java:2307)
> at 
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$TestTree.onReadUnlock(BPlusTreeSelfTest.java:2445)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readUnlock(PageHandler.java:203)
> at 
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.readUnlock(DataStructure.java:186)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$400(BPlusTree.java:82)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:163)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:120)
> at 
> org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:60)
> at 
> org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:67)
> at 
> org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:32)
> at 
> org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:43)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.printTree(BPlusTree.java:1188)
> at 
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1777)
> at 
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1771)
> at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}
> ...which causes intermittent failures in the BPlusTree unit tests:
> BPlusTreePageMemoryImplTest.testPutRmvSizeSinglePageContention
> BPlusTreeReuseListPageMemoryImplTest.testPutRmvSizeSinglePageContention 



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

[jira] [Assigned] (IGNITE-6948) SQL: Document new INLINE_SIZE option in CREATE INDEX command

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-6948:
---

Assignee: Denis Magda  (was: Prachi Garg)

Made minor edits.  [~dmagda], Please review.

> SQL: Document new INLINE_SIZE option in CREATE INDEX command
> 
>
> Key: IGNITE-6948
> URL: https://issues.apache.org/jira/browse/IGNITE-6948
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Kirill Shirokov
>Assignee: Denis Magda
> Fix For: 2.4
>
>
> INLINE_SIZE is optional and accepts positive integer values. To specify the 
> default inline size user should omit the option.
> The corresponding documentation page is at:
> https://apacheignite-sql.readme.io/docs/create-index



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

[jira] [Comment Edited] (IGNITE-7097) performance measurement for SparseDistributedMatrix multiplication

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko edited comment on IGNITE-7097 at 12/8/17 5:12 PM:
-

I experimented a bit with running benchmarks using ML codebase in master: the 
issue is still reproducible. Whatever causes it, apparently hasn't been fixed 
yet. Plan to check if maybe there is some kind of leak, maybe intermediate 
objects are created by {{likeMatrix}} or {{likeVector}} (possibly eg through 
{{copy}}) somewhere within multiplication without corresponding {{destroy}} 
because in past experiments it was missing destroy that caused yardstick to 
hang.

-

*Update:* upon closer investigation the issue looks more complicated than I 
initially thought and hypothesys of a simple leak doesn't seem to explain what 
I observed in experimenting with this benchmark. Specifically, benchmark seems 
to run smoothly with "SIZE" parameter 4x smaller than that of other matrices 
(that is with 16\(!) less elements in test matrices). But when SIZE increases 
by 2 it seems to run unacceptably long (possibly hang, hard to tell).

Given above my plan is as follows. After IGNITE-6123 is merged I will re-test 
the benchmark with smaller size that was proven to run well and if it stays OK 
will tune it for that size - in order to let us have at least _some_ way to 
reliably test for possible regressions. As for larger size I plan to open a 
separate task to profile and investigate what's going on there because what I 
observed looks quite worrying.


was (Author: oignatenko):
I experimented with running benchmarks using ML codebase in master: the issue 
is still reproducible. Whatever causes it, apparently hasn't been fixed yet. 
Plan to check if maybe there is some kind of leak, maybe intermediate objects 
are created by {{likeMatrix}} or {{likeVector}} (possibly eg through {{copy}}) 
somewhere within multiplication without corresponding {{destroy}} because in 
past experiments it was missing destroy that caused yardstick to hang

> performance measurement for SparseDistributedMatrix multiplication
> --
>
> Key: IGNITE-7097
> URL: https://issues.apache.org/jira/browse/IGNITE-7097
> Project: Ignite
>  Issue Type: Task
>  Components: ml, yardstick
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
> Fix For: 2.4
>
>
> We want to start tracking our performance to avoid performance degradation. 
> Also we need some performance comparison with other ml libs.
> Initial draft for this benchmark was made per IGNITE-6123 (class 
> {{IgniteSparseDistributedMatrixMulBenchmark}}) but it currently hangs so it 
> is excluded. Find a way to do it right.



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

[jira] [Comment Edited] (IGNITE-6903) Implement new JMX metrics for Indexing

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-6903 at 12/8/17 4:54 PM:
---

[~alex_pl], [~NIzhikov]
Thanks a lot, I'll review next week.


was (Author: avinogradov):
[~alex_pl] [~NIzhikov]
Thanks a lot, I'll review next week.

> Implement new JMX metrics for Indexing
> --
>
> Key: IGNITE-6903
> URL: https://issues.apache.org/jira/browse/IGNITE-6903
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: iep-6, important
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Space occupied by indexes.



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

[jira] [Commented] (IGNITE-6903) Implement new JMX metrics for Indexing

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6903:
--

[~alex_pl] [~NIzhikov]
Thanks a lot, I'll review next week.

> Implement new JMX metrics for Indexing
> --
>
> Key: IGNITE-6903
> URL: https://issues.apache.org/jira/browse/IGNITE-6903
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: iep-6, important
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Space occupied by indexes.



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

[jira] [Commented] (IGNITE-7053) S3 IP finder: support server side encryption

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-7053:
--

A scope of changes:
1. added {{SSEAlgorithm}} configuration property to {{TcpDiscoveryS3IpFinder}}
2. added {{SSEAlgorithm}} configuration property to {{S3CheckpointSpi}}
3. added tests for new property

[~ntikho...@apache.org], please review
https://github.com/apache/ignite/pull/3189

TC run: 
https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F3189%2Fhead


> S3 IP finder: support server side encryption
> 
>
> Key: IGNITE-7053
> URL: https://issues.apache.org/jira/browse/IGNITE-7053
> Project: Ignite
>  Issue Type: Improvement
>  Components: s3
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Popov
> Fix For: 2.4
>
>
> In case server side encryption [1] is used, it may be required to specify the 
> algorithm in request headers when saving information in a bucket (can be done 
> via {{ObjectMetadata#setSSEAlgorithm}} method). To support this we need to 
> add corresponding configuration property to the S3 IP finder.
> [1] http://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html 



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

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

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4750:
-

[~taras.ledkov], please make the function's documentation visible or reassign 
the ticket on me to do this once the improvement is released: 
https://apacheignite-sql.readme.io/docs/group_concat

Presently the doc is hidden and the can come across it only if he guesses the 
URL.

> SQL: Support GROUP_CONCAT function
> --
>
> Key: IGNITE-4750
> URL: https://issues.apache.org/jira/browse/IGNITE-4750
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Denis Magda
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> GROUP_CONCAT function is not supported at the moment. Makes sense to fill 
> this gap:
> http://apache-ignite-users.70518.x6.nabble.com/GROUP-CONCAT-function-is-unsupported-td10757.html
> Presently the function doc is hidden:
> https://apacheignite-sql.readme.io/docs/group_concat
> Open it up once the ticket is released.



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

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

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4750:

Description: 
GROUP_CONCAT function is not supported at the moment. Makes sense to fill this 
gap:
http://apache-ignite-users.70518.x6.nabble.com/GROUP-CONCAT-function-is-unsupported-td10757.html

Presently the function doc is hidden:
https://apacheignite-sql.readme.io/docs/group_concat

Open it up once the ticket is released.


  was:
GROUP_CONCAT function is not supported at the moment. Makes sense to fill this 
gap:
http://apache-ignite-users.70518.x6.nabble.com/GROUP-CONCAT-function-is-unsupported-td10757.html


> SQL: Support GROUP_CONCAT function
> --
>
> Key: IGNITE-4750
> URL: https://issues.apache.org/jira/browse/IGNITE-4750
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Denis Magda
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> GROUP_CONCAT function is not supported at the moment. Makes sense to fill 
> this gap:
> http://apache-ignite-users.70518.x6.nabble.com/GROUP-CONCAT-function-is-unsupported-td10757.html
> Presently the function doc is hidden:
> https://apacheignite-sql.readme.io/docs/group_concat
> Open it up once the ticket is released.



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

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

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4750:

Fix Version/s: 2.4

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



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

[jira] [Commented] (IGNITE-7109) .NET: Thin client: Async cache operations

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7109:


Done, [~vozerov], please review.

> .NET: Thin client: Async cache operations
> -
>
> Key: IGNITE-7109
> URL: https://issues.apache.org/jira/browse/IGNITE-7109
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Add async operations to {{ICacheClient}}.
> Thin client suppots asynchrony with requestId mechanism. Make sure it works 
> with .NET.



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

[jira] [Comment Edited] (IGNITE-6903) Implement new JMX metrics for Indexing

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov edited comment on IGNITE-6903 at 12/8/17 3:59 PM:
--

PR - https://github.com/apache/ignite/pull/3135
Upsource - https://reviews.ignite.apache.org/ignite/review/IGNT-CR-420
Team city - 
https://ci.ignite.apache.org/viewLog.html?buildId=984831=buildResultsDiv=Ignite20Tests_RunAll


was (Author: nizhikov):
PR - https://github.com/apache/ignite/pull/3135
Upsource - https://reviews.ignite.apache.org/ignite/review/IGNT-CR-420
Team city - https://ci.ignite.apache.org/viewQueued.html?itemId=979290

> Implement new JMX metrics for Indexing
> --
>
> Key: IGNITE-6903
> URL: https://issues.apache.org/jira/browse/IGNITE-6903
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: iep-6, important
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Space occupied by indexes.



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

[jira] [Commented] (IGNITE-7109) .NET: Thin client: Async cache operations

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7109:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-7109 .NET: Thin client: Async cache operations



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

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

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

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

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

This closes #3187


commit 434171a938d902d0229fc6c7394080f1e6d15113
Author: Pavel Tupitsyn 
Date:   2017-12-08T15:57:18Z

IGNITE-7109 .NET: Thin client: Async cache operations




> .NET: Thin client: Async cache operations
> -
>
> Key: IGNITE-7109
> URL: https://issues.apache.org/jira/browse/IGNITE-7109
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Add async operations to {{ICacheClient}}.
> Thin client suppots asynchrony with requestId mechanism. Make sure it works 
> with .NET.



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

[jira] [Commented] (IGNITE-7052) S3 IP finder: add an ability to provide endpoint address

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7052:


Github user asfgit closed the pull request at:

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


> S3 IP finder: add an ability to provide endpoint address
> 
>
> Key: IGNITE-7052
> URL: https://issues.apache.org/jira/browse/IGNITE-7052
> Project: Ignite
>  Issue Type: Improvement
>  Components: s3
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Popov
> Fix For: 2.4
>
>
> By default S3 client detects region automatically by sending special request 
> to {{us-west-1}}. In case environment is restricted to some other region, 
> this leads to connection timeout exception.
> The issue can be solved by providing a specific region endpoint via 
> {{AmazonS3Client#setEndpoint}} method. To support this we need to add 
> {{endpoint}} configuration property to the IP finder.
> List of S3 region endpoints: 
> http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region



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

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

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-4750:
--

[~vozerov], [~al.psc], [~skalashnikov] I need in primary review for the patch. 
Please take a look.

I guess tow ways to support GROUP_CONCAT in not collocated mode is
1. Use our own aggregate functions for map and reduce query.  On map step: 
accumulates values in collection and returns collection. On reduce step:  
accumulates map's collection in reduce collection and returns sorted / 
distinct. 
The problem is complex {{ORDER BY}} expression inside {{GROUP_CONCAT}} function.

2. Use H2 {{GROUP_CONCAT}} function on reduce step and not-aggregated select 
for map step.
The problem: query can support other aggregate functions.

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



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

[jira] [Comment Edited] (IGNITE-4192) SQL TX: JDBC driver support

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko edited comment on IGNITE-4192 at 12/8/17 2:55 PM:
--

[~vozerov]
My questions/clarifications:

5 - this is done already, see usages of {{IgniteH2Indexing#sqlUserTxStart()}}

{quote}
Most probably transaction should be bound to Connection object.
{quote}
This is what effectively happening now - each {{Connection}} has its own 
{{JdbcRequestHandler}} on server side which in turn has single threaded worker 
within whose scope transactions start and end. After all, it's a thin client, 
and there may be no Ignite running at all on the host owning {{Connection}} 
object. All in all, a connection may not have more than one transaction started 
as long as no single thread can.


was (Author: al.psc):
[~vozerov]
My questions/clarifications:

5 - this is done already, see usages of {{IgniteH2Indexing#sqlUserTxStart()}}

{quote}
Most probably transaction should be bound to Connection object.
{quote}
This is what effectively happening now - each {{Connection}} has its own 
{{JdbcRequestHandler}} on server side which in turn has single threaded worker 
within whose scope transactions start and end. After all, it's a thin client, 
and there may be no Ignite running at all on the host owning {{Connection}} 
object.

> SQL TX: JDBC driver support
> ---
>
> Key: IGNITE-4192
> URL: https://issues.apache.org/jira/browse/IGNITE-4192
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>  Labels: iep-3, sql
> Fix For: 2.4
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from JDBC driver side.



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

[jira] [Commented] (IGNITE-6729) Java 9: fix IgniteUtils#close(URLClassLoader, IgniteLogger)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6729:


GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-6729: Removed obsolete reflection-based workaround



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

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

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

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

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

This closes #3184


commit c41c4ae310c9531a23a3414c446112cf6a2dfd53
Author: Andrey Kuznetsov 
Date:   2017-12-08T14:54:16Z

IGNITE-6729: Removed obsolete reflection-based workaround in URLClassLoader 
closing code.




> Java 9: fix IgniteUtils#close(URLClassLoader, IgniteLogger)
> ---
>
> Key: IGNITE-6729
> URL: https://issues.apache.org/jira/browse/IGNITE-6729
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> This method use some internal API which is no longer accessible to cleanup 
> {{URLCLassLoader}} properly. The only usage of this method is in 
> {{GridUriDeploymentFileProcessor}} class.



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

[jira] [Comment Edited] (IGNITE-4192) SQL TX: JDBC driver support

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko edited comment on IGNITE-4192 at 12/8/17 2:54 PM:
--

[~vozerov]
My questions/clarifications:

5 - this is done already, see usages of {{IgniteH2Indexing#sqlUserTxStart()}}

{quote}
Most probably transaction should be bound to Connection object.
{quote}
This is what effectively happening now - each {{Connection}} has its own 
{{JdbcRequestHandler}} on server side which in turn has single threaded worker 
within whose scope transactions start and end. After all, it's a thin client, 
and there may be no Ignite running at all on the host owning {{Connection}} 
object.


was (Author: al.psc):
[~vozerov]
My questions/clarifications:

5 - this is done already, see usages of {{IgniteH2Indexing#sqlUserTxStart()}}

{{quote}}
Most probably transaction should be bound to Connection object.
{{quote}}
This is what effectively happening now - each {{Connection}} has its own 
{{JdbcRequestHandler}} on server side which in turn has single threaded worker 
within whose scope transactions start and end. After all, it's a thin client, 
and there may be no Ignite running at all on the host owning {{Connection}} 
object.

> SQL TX: JDBC driver support
> ---
>
> Key: IGNITE-4192
> URL: https://issues.apache.org/jira/browse/IGNITE-4192
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>  Labels: iep-3, sql
> Fix For: 2.4
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from JDBC driver side.



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

[jira] [Comment Edited] (IGNITE-4192) SQL TX: JDBC driver support

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-4192 at 12/8/17 2:39 PM:
--

[~al.psc], my comments:
1) {{JdbcThinConnection.ctor}} - {{autoCommit}} should be set {{true}} by 
default as per JDBC spec
2) {{JdbcThinConnection.setAutoCommit}} - user should be able to work with both 
autoCommit modes, why are we restricting this?
3) {{JdbcThinConnection.commit}} - commit with {{autoCommit=true}} should be 
no-op instead of exception
4) {{JdbcThinConnection.rollback}} - same as p.3
5) {{JdbcThinConnection}} - if {{autoCommit = false}}, transaction should be 
started on the first call to any operation
6) {{JdbcThinConnection}} - JDBC spec requirement is missing - if autoCommit 
mode is changed during transaction, it should be committed forcefully
7) {{SqlTransactionsSelfTest}} is not included into a test suite
8) Please investigate what other vendors do in case {{BEGIN}} is called on 
already existing transaction. Most probably we should commit previous TX and 
start a new one instead of throwing an exception
9) {{ROLLBACK}} on non-existing TX should be no-op


was (Author: vozerov):
[~al.psc], my comments:
1) {{JdbcThinConnection.ctor}} - {{autoCommit}} should be set {{true}} by 
default as per JDBC spec
2) {{JdbcThinConnection.setAutoCommit}} - user should be able to work with both 
autoCommit modes, why are we restricting this?
3) {{JdbcThinConnection.commit}} - commit with active transaction should be 
no-op instead of exception
4) {{JdbcThinConnection.rollback}} - same as p.3
5) {{JdbcThinConnection}} - if {{autoCommit = false}}, transaction should be 
started on the first call to any operation
6) {{JdbcThinConnection}} - JDBC spec requirement is missing - if autoCommit 
mode is changed during transaction, it should be committed forcefully
7) {{SqlTransactionsSelfTest}} is not included into a test suite
8) Please investigate what other vendors do in case {{BEGIN}} is called on 
already existing transaction. Most probably we should commit previous TX and 
start a new one instead of throwing an exception
9) {{ROLLBACK}} on non-existing TX should be no-op

> SQL TX: JDBC driver support
> ---
>
> Key: IGNITE-4192
> URL: https://issues.apache.org/jira/browse/IGNITE-4192
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>  Labels: iep-3, sql
> Fix For: 2.4
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from JDBC driver side.



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

[jira] [Commented] (IGNITE-6915) SQL: Failed to invoke getter method (type=class java.lang.String)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6915:


GitHub user gg-shq opened a pull request:

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

IGNITE-6915: Fixed b+tree index names for non-binary marshaller case...

… Added more diagnostics to QueryXxxAccessor exceptions.

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

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

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

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

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

This closes #3183


commit 02d5a368e7dccdedb9fc393bf361446016e08ea4
Author: gg-shq 
Date:   2017-12-08T13:44:10Z

IGNITE-6915: Fixed b+tree index names for non-binary marshaller case. Added 
more diagnostics to QueryXxxAccessor exceptions.




> SQL: Failed to invoke getter method (type=class java.lang.String)
> -
>
> Key: IGNITE-6915
> URL: https://issues.apache.org/jira/browse/IGNITE-6915
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Pavel Konstantinov
>Assignee: Kirill Shirokov
> Attachments: export-query-Query123-all.csv, screenshot-1.png
>
>
> cluster configuration:
> - 2 server nodes (one with a load, OPTIMIZED marshaller)
> - cache populated with data
> Executed ' select * from "cache".Person '
> !screenshot-1.png!
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: ┬эєЄЁхээ   ю°шсър: "class 
> org.apache.ignite.IgniteCheckedException: Failed to invoke getter method 
> [type=class java.lang.String, property=firstName]"
> General error: "class org.apache.ignite.IgniteCheckedException: Failed to 
> invoke getter method [type=class java.lang.String, property=firstName]"; SQL 
> statement:
> SELECT
> __Z0.FIRSTNAME __C0_0,
> __Z0.LASTNAME __C0_1,
> __Z0.RANK __C0_2,
> __Z0.TITLE __C0_3,
> __Z0.AGE __C0_4,
> __Z0.SALARY __C0_5,
> __Z0.ID __C0_6,
> __Z0.DEPID __C0_7
> FROM "c_partitioned".PERSON __Z0 [5-195]
> at 
> org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:295)
> at 
> org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:348)
> at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:236)
> at org.h2.table.TableFilter.getValue(TableFilter.java:1083)
> at 
> org.h2.expression.ExpressionColumn.getValue(ExpressionColumn.java:186)
> at org.h2.expression.Alias.getValue(Alias.java:36)
> at 
> org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1459)
> at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
> at org.h2.result.LazyResult.next(LazyResult.java:59)
> at org.h2.command.dml.Select.queryFlat(Select.java:519)
> at org.h2.command.dml.Select.queryWithoutCache(Select.java:625)
> at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
> at org.h2.command.dml.Query.query(Query.java:352)
> at org.h2.command.dml.Query.query(Query.java:333)
> at org.h2.command.CommandContainer.query(CommandContainer.java:113)
> at org.h2.command.Command.executeQuery(Command.java:201)
> at 
> org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:111)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:967)
> ... 31 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to invoke 
> getter method [type=class java.lang.String, property=firstName]
> at 
> org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:51)
> at 
> org.apache.ignite.internal.processors.query.property.QueryClassProperty.value(QueryClassProperty.java:82)
> at 
> org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:345)
> ... 47 more
> Caused by: java.lang.IllegalArgumentException: object is not an instance of 
> declaring class
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at 

[jira] [Commented] (IGNITE-5768) Retry resolving class name from marshaller cache and .classname file

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-5768:
-

Relevant stack trace:

{code}
Caused by: org.apache.ignite.IgniteCheckedException: Failed to deserialize 
object with given class loader: sun.misc.Launcher$AppClassLoader@764c12b6
at 
org.apache.ignite.marshaller.optimized.OptimizedMarshaller.unmarshal0(OptimizedMarshaller.java:255)
at 
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
at 
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9825)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.initialize(GridJobWorker.java:432)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1108)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1894)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1224)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:852)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$2100(GridIoManager.java:109)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:792)
... 3 common frames omitted
Caused by: java.lang.NullPointerException: Ouch! Argument cannot be null: val
at 
org.apache.ignite.internal.util.GridArgumentCheck.notNull(GridArgumentCheck.java:48)
at 
org.apache.ignite.internal.util.GridArgumentCheck.notNull(GridArgumentCheck.java:61)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.tryGetAndPut(GridDhtAtomicCache.java:721)
at 
org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:160)
at 
org.apache.ignite.internal.MarshallerContextImpl.className(MarshallerContextImpl.java:228)
at 
org.apache.ignite.internal.MarshallerContextAdapter.getClass(MarshallerContextAdapter.java:174)
at 
org.apache.ignite.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:266)
at 
org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:318)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:416)
{code}

> Retry resolving class name from marshaller cache and .classname file
> 
>
> Key: IGNITE-5768
> URL: https://issues.apache.org/jira/browse/IGNITE-5768
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>




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

[jira] [Created] (IGNITE-7154) .NET: Thin client: Async queries

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7154:
--

 Summary: .NET: Thin client: Async queries
 Key: IGNITE-7154
 URL: https://issues.apache.org/jira/browse/IGNITE-7154
 Project: Ignite
  Issue Type: Improvement
  Components: platforms, thin client
Affects Versions: 2.4
Reporter: Pavel Tupitsyn


IGNITE-7109  adds async cache operations, but query methods remain synchronous.
Find a way to make query cursor asynchronous.



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

[jira] [Commented] (IGNITE-7047) NPE from org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-7047:
--

TC passed successfully.
[~avinogradov], please review again

> NPE from 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn
> 
>
> Key: IGNITE-7047
> URL: https://issues.apache.org/jira/browse/IGNITE-7047
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
> Fix For: 2.4
>
>
> NPE happens sometimes at heavy load after receiving 
> GridDhtTxOnePhaseCommitAckRequest, no more details
> ERROR 11/25/17 17:39:28 [::sys-stripe-2-#3%null%] cache.GridCacheIoManager> 
> Failed processing message [senderId=0393e394-09a9-4c02-b33e-fb4d99c3539f, 
> msg=GridDhtTxOnePhaseCommitAckRequest [vers=[GridCacheVersi
> on [topVer=123129570, order=1511649564004, nodeOrder=2]], 
> super=GridCacheMessage [msgId=95, depInfo=null, err=null, skipPrepare=false]]]
> java.lang.NullPointerException
> at 
> org.jsr166.ConcurrentLinkedHashMap.replace(ConcurrentLinkedHashMap.java:1517)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1043)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxOnePhaseCommitAckRequest(IgniteTxHandler.java:1070)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$700(IgniteTxHandler.java:95)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:183)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:181)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
> at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
> at java.lang.Thread.run(Thread.java:745)
> ERROR 11/25/17 17:39:28 [::sys-stripe-14-#15%null%] cache.GridCacheIoManager> 
> Failed processing message [senderId=52c4ced0-49f3-4075-9b2f-7d619adf6d33, 
> msg=GridDhtTxOnePhaseCommitAckRequest [vers=[GridCacheVersion 
> [topVer=123129570, order=1511649564004, nodeOrder=4]], super=GridCacheMessage 
> [msgId=97, depInfo=null, err=null, skipPrepare=false]]]
> java.lang.NullPointerException
> at 
> org.jsr166.ConcurrentLinkedHashMap.replace(ConcurrentLinkedHashMap.java:1517)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1043)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxOnePhaseCommitAckRequest(IgniteTxHandler.java:1070)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$700(IgniteTxHandler.java:95)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:183)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:181)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> 

[jira] [Assigned] (IGNITE-7053) S3 IP finder: support server side encryption

[Alexey Popov (JIRA)]

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

Alexey Popov reassigned IGNITE-7053:


Assignee: Alexey Popov

> S3 IP finder: support server side encryption
> 
>
> Key: IGNITE-7053
> URL: https://issues.apache.org/jira/browse/IGNITE-7053
> Project: Ignite
>  Issue Type: Improvement
>  Components: s3
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Popov
> Fix For: 2.4
>
>
> In case server side encryption [1] is used, it may be required to specify the 
> algorithm in request headers when saving information in a bucket (can be done 
> via {{ObjectMetadata#setSSEAlgorithm}} method). To support this we need to 
> add corresponding configuration property to the S3 IP finder.
> [1] http://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html 



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

[jira] [Assigned] (IGNITE-7136) Add JMX metric for indexing to .Net

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-7136:
--

Assignee: Nikolay Izhikov  (was: Pavel Tupitsyn)

> Add JMX metric for indexing to .Net 
> 
>
> Key: IGNITE-7136
> URL: https://issues.apache.org/jira/browse/IGNITE-7136
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>  Labels: iep-6
> Fix For: 2.4
>
>
> New JMX metric implemented in IGNITE-6903.
> We need to add support for this metric to .Net 



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

[jira] [Created] (IGNITE-7153) Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for values > 8kb

[Alexey Popov (JIRA)]

Alexey Popov created IGNITE-7153:


 Summary: Redis: BufferUnderflowException at 
GridRedisProtocolParser.readBulkStr for values > 8kb
 Key: IGNITE-7153
 URL: https://issues.apache.org/jira/browse/IGNITE-7153
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.3
 Environment: Win, PHP 7, php_redis-3.1.1-7.0
Reporter: Alexey Popov


Exception:
{noformat}
[15:03:23,690][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol] 
Failed to process selector key [ses=GridSelectorNioSessionImpl 
[worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=28 
lim=8192 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0, 
bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker 
[name=grid-nio-worker-tcp-rest-0, igniteInstanceName=null, finished=false, 
hashCode=396395638, interrupted=false, 
runner=grid-nio-worker-tcp-rest-0-#36]]], writeBuf=null, readBuf=null, 
inRecovery=null, outRecovery=null, super=GridNioSessionImpl 
[locAddr=/127.0.0.1:6380, rmtAddr=/127.0.0.1:51794, createTime=1512734602674, 
closeTime=0, bytesSent=0, bytesRcvd=8192, bytesSent0=0, bytesRcvd0=8192, 
sndSchedTime=1512734602674, lastSndTime=1512734602674, 
lastRcvTime=1512734602674, readsPaused=false, 
filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser 
[jdkMarshaller=JdkMarshaller [], routerClient=false], directMode=false]], 
accepted=true]]]
java.nio.BufferUnderflowException
at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
at 
org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
at 
org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
at 
org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:150)
at 
org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:70)
at 
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at 
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3392)
at 
org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
at 
org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1096)
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2272)
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
[15:03:23,691][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol] 
Closing NIO session because of unhandled exception.
class org.apache.ignite.internal.util.nio.GridNioException: null
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2296)
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.nio.BufferUnderflowException
at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
at 
org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
at 
org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
at 
org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:150)
at 
org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:70)
at 
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at 
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3392)
at 

[jira] [Updated] (IGNITE-7153) Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for values > 8kb

[Alexey Popov (JIRA)]

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

Alexey Popov updated IGNITE-7153:
-
Labels: redis  (was: )

> Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for 
> values > 8kb
> ---
>
> Key: IGNITE-7153
> URL: https://issues.apache.org/jira/browse/IGNITE-7153
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.3
> Environment: Win, PHP 7, php_redis-3.1.1-7.0
>Reporter: Alexey Popov
>  Labels: redis
>
> Exception:
> {noformat}
> [15:03:23,690][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol] 
> Failed to process selector key [ses=GridSelectorNioSessionImpl 
> [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=28 
> lim=8192 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0, 
> bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker 
> [name=grid-nio-worker-tcp-rest-0, igniteInstanceName=null, finished=false, 
> hashCode=396395638, interrupted=false, 
> runner=grid-nio-worker-tcp-rest-0-#36]]], writeBuf=null, readBuf=null, 
> inRecovery=null, outRecovery=null, super=GridNioSessionImpl 
> [locAddr=/127.0.0.1:6380, rmtAddr=/127.0.0.1:51794, createTime=1512734602674, 
> closeTime=0, bytesSent=0, bytesRcvd=8192, bytesSent0=0, bytesRcvd0=8192, 
> sndSchedTime=1512734602674, lastSndTime=1512734602674, 
> lastRcvTime=1512734602674, readsPaused=false, 
> filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser 
> [jdkMarshaller=JdkMarshaller [], routerClient=false], directMode=false]], 
> accepted=true]]]
> java.nio.BufferUnderflowException
>   at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
>   at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
>   at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
>   at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:150)
>   at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:70)
>   at 
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3392)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1096)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2272)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> [15:03:23,691][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol] 
> Closing NIO session because of unhandled exception.
> class org.apache.ignite.internal.util.nio.GridNioException: null
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2296)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.BufferUnderflowException
>   at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
>   at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
>   at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
>   at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:150)
>   at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:70)
>   at 

[jira] [Commented] (IGNITE-5655) Introduce pluggable string encoder/decoder

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-5655:
--

I'd like to conduct more subtle investigation on impact of this change on some 
big enough data. Until this is done I won't suggest to merge such a significant 
change to master.

> Introduce pluggable string encoder/decoder
> --
>
> Key: IGNITE-5655
> URL: https://issues.apache.org/jira/browse/IGNITE-5655
> Project: Ignite
>  Issue Type: New Feature
>  Components: binary
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Assignee: Andrey Kuznetsov
>  Labels: iep-2, important
> Fix For: 2.4
>
>
> Currently binary marshaller encodes strings in UTF-8. However, sometimes it 
> makes sense to serialize strings with different encodings to save space. 
> Let's add global property to control String encoding and customize our binary 
> protocol to support it. For instance, we can add another flag 
> {{ENCODED_STRING}}, which will write strings as follows:
> [flag][encoding_flag][str_len][str_bytes]
> First implementation should set preferred encoding for strings in 
> BinaryConfiguration. This setting is optional, default encoding is UTF-8. 
> Currently, the same BinaryConfiguration is used for all cluster nodes, thus 
> no encoding clashes are possible.



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

[jira] [Commented] (IGNITE-7085) When PDS is enabled and IGNITE_BINARY_SORT_OBJECT_FIELDS property is set and IgniteCache#put is called a node hangs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7085:


Github user asfgit closed the pull request at:

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


> When PDS is enabled and IGNITE_BINARY_SORT_OBJECT_FIELDS property is set and 
> IgniteCache#put is called a node hangs
> ---
>
> Key: IGNITE-7085
> URL: https://issues.apache.org/jira/browse/IGNITE-7085
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Assignee: Alexandr Fedotov
> Fix For: 2.4
>
>
> When PDS is enabled and IGNITE_BINARY_SORT_OBJECT_FIELDS property is set and 
> IgniteCache#put is called a node hangs.
> The root cause is that when IGNITE_BINARY_SORT_OBJECT_FIELDS flag is enabled
> BinaryMetadata#fields field is stored as TreeMap, but because 
> BinaryUtils#WRAP_TREES is
> set by default, that leads to BinaryMetadata#fields being wrapped into a 
> BinaryTreeMap.
> When an update for BinaryMetadata is initiated it ends up in a discovery 
> thread from where
> a metadata update for BinaryTreeMap is initiated. Since this update should be 
> processed by the same discovery thread, that results in a deadlock.



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

[jira] [Commented] (IGNITE-7085) When PDS is enabled and IGNITE_BINARY_SORT_OBJECT_FIELDS property is set and IgniteCache#put is called a node hangs

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-7085:
--

Thanks, Alexandr, merged your changes to master.

> When PDS is enabled and IGNITE_BINARY_SORT_OBJECT_FIELDS property is set and 
> IgniteCache#put is called a node hangs
> ---
>
> Key: IGNITE-7085
> URL: https://issues.apache.org/jira/browse/IGNITE-7085
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Assignee: Alexandr Fedotov
> Fix For: 2.4
>
>
> When PDS is enabled and IGNITE_BINARY_SORT_OBJECT_FIELDS property is set and 
> IgniteCache#put is called a node hangs.
> The root cause is that when IGNITE_BINARY_SORT_OBJECT_FIELDS flag is enabled
> BinaryMetadata#fields field is stored as TreeMap, but because 
> BinaryUtils#WRAP_TREES is
> set by default, that leads to BinaryMetadata#fields being wrapped into a 
> BinaryTreeMap.
> When an update for BinaryMetadata is initiated it ends up in a discovery 
> thread from where
> a metadata update for BinaryTreeMap is initiated. Since this update should be 
> processed by the same discovery thread, that results in a deadlock.



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

[jira] [Issue Comment Deleted] (IGNITE-6902) Implement new JMX metrics for Memory Regions

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6902:
-
Comment: was deleted

(was: [~avinogradov], then my changes are ready for review, see issue links.)

> Implement new JMX metrics for Memory Regions
> 
>
> Key: IGNITE-6902
> URL: https://issues.apache.org/jira/browse/IGNITE-6902
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Blocker
>  Labels: iep-6, important
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Bytes used per data region.
> - Size of checkpointing buffer.



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

[jira] [Updated] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6711:
-
Labels: iep-6 newbie  (was: newbie)

> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>  Labels: iep-6, newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Commented] (IGNITE-6902) Implement new JMX metrics for Memory Regions

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6902:
--

[~avinogradov], then my changes are ready for review, see issue links.

> Implement new JMX metrics for Memory Regions
> 
>
> Key: IGNITE-6902
> URL: https://issues.apache.org/jira/browse/IGNITE-6902
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Blocker
>  Labels: iep-6, important
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Bytes used per data region.
> - Size of checkpointing buffer.



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

[jira] [Updated] (IGNITE-6902) Implement new JMX metrics for Memory Regions

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6902:
-
Description: 
These additional metrics and methods should be implemented:

- Bytes used per data region.
- Size of checkpointing buffer.

  was:
These additional metrics and methods should be implemented:

- Bytes used per data region.
- Bytes used per cache.
- Size of checkpointing buffer.


> Implement new JMX metrics for Memory Regions
> 
>
> Key: IGNITE-6902
> URL: https://issues.apache.org/jira/browse/IGNITE-6902
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Blocker
>  Labels: iep-6, important
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Bytes used per data region.
> - Size of checkpointing buffer.



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

[jira] [Commented] (IGNITE-7134) Never-ending timeout in IgniteSpiOperationTimeoutHelper.nextTimeoutChunk()

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin commented on IGNITE-7134:


Actual infinite timeout reason.

> Never-ending timeout in IgniteSpiOperationTimeoutHelper.nextTimeoutChunk()
> --
>
> Key: IGNITE-7134
> URL: https://issues.apache.org/jira/browse/IGNITE-7134
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
>Priority: Critical
> Fix For: 2.4
>
>
> {noformat}
> org.apache.ignite.spi.IgniteSpiOperationTimeoutHelper#nextTimeoutChunk
> long curTs = U.currentTimeMillis();
> timeout = timeout - (curTs - lastOperStartTs);
> {noformat}
> Timeout will not be decreased at all if delay between successive calls to 
> nextTimeoutChunk() is smaller than U.currentTimeMillis() discretization. Such 
> behaviour could be easily achieved when getting an error right after the 
> nextTimeoutChunk() invocation and do the retry.
> Only rare calls (the first right before U.currentTimeMillis() and the second 
> right after that) may decrease timeout, so actual 
> IgniteSpiOperationTimeoutHelper timeout could be much bigger than the 
> failureDetectionTimeout.
> My opinion to not split failureDetectionTimeout between network operations, 
> but initialize first operation timestamp at first call to nextTimeoutChunk(), 
> and then calculate the timeout as a difference between the current timestamp 
> and the first operation timestamp.



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

[jira] [Commented] (IGNITE-6902) Implement new JMX metrics for Memory Regions

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6902:
--

[~andrey-kuznetsov],

Well, I agree with you. Let's change description and mark issue as PA.

> Implement new JMX metrics for Memory Regions
> 
>
> Key: IGNITE-6902
> URL: https://issues.apache.org/jira/browse/IGNITE-6902
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Blocker
>  Labels: iep-6, important
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Bytes used per data region.
> - Bytes used per cache.
> - Size of checkpointing buffer.



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

[jira] [Updated] (IGNITE-7152) Failure detection timeout don't work on permanent send message errors causing infinite loop

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin updated IGNITE-7152:
---
Attachment: testFailureDetectionOnReceiptError.patch

Simple reproducer

> Failure detection timeout don't work on permanent send message errors causing 
> infinite loop
> ---
>
> Key: IGNITE-7152
> URL: https://issues.apache.org/jira/browse/IGNITE-7152
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
>Priority: Critical
> Fix For: 2.4
>
> Attachments: testFailureDetectionOnReceiptError.patch
>
>
> Relative to {{RingMessageWorker.sendMessageAcrossRing}} implementation.
> {{IgniteSpiOperationTimeoutHelper}} reinitialized every time the socket 
> successfully connected.
> If any of {{IOException, IgniteCheckedException}} occurs upon message send 
> the socket will be closed and old {{IgniteSpiOperationTimeoutHelper}} will be 
> used to reconnect.
> But after successful reconnect the new one will be created and the cycle 
> repeat. With a permanent send message error this causes an infinite loop.
> The only send error which may cause to exit out of the loop and the next node 
> failure is {{IgniteSpiOperationTimeoutException, SocketTimeoutException, 
> SocketException}}.



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

[jira] [Assigned] (IGNITE-7152) Failure detection timeout don't work on permanent send message errors causing infinite loop

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin reassigned IGNITE-7152:
--

Assignee: Alexandr Kuramshin

> Failure detection timeout don't work on permanent send message errors causing 
> infinite loop
> ---
>
> Key: IGNITE-7152
> URL: https://issues.apache.org/jira/browse/IGNITE-7152
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
>Priority: Critical
> Fix For: 2.4
>
>
> Relative to {{RingMessageWorker.sendMessageAcrossRing}} implementation.
> {{IgniteSpiOperationTimeoutHelper}} reinitialized every time the socket 
> successfully connected.
> If any of {{IOException, IgniteCheckedException}} occurs upon message send 
> the socket will be closed and old {{IgniteSpiOperationTimeoutHelper}} will be 
> used to reconnect.
> But after successful reconnect the new one will be created and the cycle 
> repeat. With a permanent send message error this causes an infinite loop.
> The only send error which may cause to exit out of the loop and the next node 
> failure is {{IgniteSpiOperationTimeoutException, SocketTimeoutException, 
> SocketException}}.



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

[jira] [Created] (IGNITE-7152) Failure detection timeout don't work on permanent send message errors causing infinite loop

[Alexandr Kuramshin (JIRA)]

Alexandr Kuramshin created IGNITE-7152:
--

 Summary: Failure detection timeout don't work on permanent send 
message errors causing infinite loop
 Key: IGNITE-7152
 URL: https://issues.apache.org/jira/browse/IGNITE-7152
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.3
Reporter: Alexandr Kuramshin
Priority: Critical
 Fix For: 2.4


Relative to {{RingMessageWorker.sendMessageAcrossRing}} implementation.

{{IgniteSpiOperationTimeoutHelper}} reinitialized every time the socket 
successfully connected.

If any of {{IOException, IgniteCheckedException}} occurs upon message send the 
socket will be closed and old {{IgniteSpiOperationTimeoutHelper}} will be used 
to reconnect.

But after successful reconnect the new one will be created and the cycle 
repeat. With a permanent send message error this causes an infinite loop.

The only send error which may cause to exit out of the loop and the next node 
failure is {{IgniteSpiOperationTimeoutException, SocketTimeoutException, 
SocketException}}.



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

[jira] [Resolved] (IGNITE-7086) Backups are not updated when ReadFromBackup=true and ReadThrough happens.

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev resolved IGNITE-7086.
-
Resolution: Fixed

> Backups are not updated when ReadFromBackup=true and ReadThrough happens.
> -
>
> Key: IGNITE-7086
> URL: https://issues.apache.org/jira/browse/IGNITE-7086
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Andrew Mashenkov
>Assignee: Dmitry Karachentsev
> Fix For: 2.4
>
> Attachments: ReplicatedReadFromBackupWithStoreTest.java
>
>
> Ignite Replicated cache with CacheStore and ReadThrough=true and 
> ReadFromBackup=true works in unexpected way from user perspective.
> On backup node, get operation will always go to the primary node regardless 
> of ReadFromBackup=true and ReadThrough=true when entry doesn't exists in 
> local map.
> So, Replicated cache works like a Partitioned with no backups.



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

[jira] [Commented] (IGNITE-6902) Implement new JMX metrics for Memory Regions

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6902:
--

"Bytes used per cache" metric looks hardly possible to implement since we can 
get data at cache group level, but not for individual cache.

Two other metrics are ready, see [1].

[1] https://github.com/apache/ignite/pull/3181

> Implement new JMX metrics for Memory Regions
> 
>
> Key: IGNITE-6902
> URL: https://issues.apache.org/jira/browse/IGNITE-6902
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Blocker
>  Labels: iep-6, important
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Bytes used per data region.
> - Bytes used per cache.
> - Size of checkpointing buffer.



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

[jira] [Commented] (IGNITE-7114) CPP: C++ node can't start without java examples folder

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-7114:
-

 [~ptupitsyn], it's an inherent thing. I've created a ticket to remove code 
duplication - IGNITE-7151.

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
> Attachments: sample.png
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Created] (IGNITE-7151) CPP: Get rid of code duplication in JNI library

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-7151:
---

 Summary: CPP: Get rid of code duplication in JNI library
 Key: IGNITE-7151
 URL: https://issues.apache.org/jira/browse/IGNITE-7151
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.3
Reporter: Igor Sapego


There is a lot of code duplication in {{utils.cpp}} files, that can be removed.



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

[jira] [Commented] (IGNITE-6224) Node stoping does not wait all transactions completion

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6224:


GitHub user BiryukovVA opened a pull request:

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

IGNITE-6224: Waiting TX completion on node stop.



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

$ git pull https://github.com/BiryukovVA/ignite IGNITE-6224

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

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

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

This closes #3180


commit b2268dcfecde365e3afee45b7a3c5bf7efe56d29
Author: Vitaliy Biryukov 
Date:   2017-12-08T11:23:19Z

IGNITE-6224: Waiting TX completion on node stop.




> Node stoping does not wait all transactions completion
> --
>
> Key: IGNITE-6224
> URL: https://issues.apache.org/jira/browse/IGNITE-6224
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>Assignee: Vitaliy Biryukov
> Attachments: TransactionBehindStopNodeTest.java
>
>
> I have started grid node and executing transaction over some cache. After I 
> stopped the node in the middle execution of transaction. I got transaction 
> execution exception:
> {noformat}
> java.lang.IllegalStateException: class 
> org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to 
> perform cache operation (cache is stopped): cache
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:164)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onEnter(GatewayProtectedCacheProxy.java:1656)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:869)
>   at 
> org.apache.ignite.TransactionBehindStopNodeTest.testOneNode(TransactionBehindStopNodeTest.java:56)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> although I stopped node with _false_ {{cancel}} flag.
> {code}
> G.stop(getTestIgniteInstanceName(0), false);
> {code}



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

[jira] [Resolved] (IGNITE-5218) Decision trees

[Yury Babak (JIRA)]

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

Yury Babak resolved IGNITE-5218.

Resolution: Done

merged

> Decision trees
> --
>
> Key: IGNITE-5218
> URL: https://issues.apache.org/jira/browse/IGNITE-5218
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>Assignee: Artem Malykh
>  Labels: important
> Fix For: 2.4
>
>
> We want to implement Decision trees for Ignite ML because it's really common 
> one for ML.



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

[jira] [Assigned] (IGNITE-6814) Detailed memory consumption on start and OOM reporting

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov reassigned IGNITE-6814:


Assignee: Alexandr Fedotov

> Detailed memory consumption on start and OOM reporting
> --
>
> Key: IGNITE-6814
> URL: https://issues.apache.org/jira/browse/IGNITE-6814
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Alexandr Fedotov
>Priority: Blocker
>  Labels: iep-6, usability
> Fix For: 2.4
>
>
> Presently Ignite allocates 20% of RAM on a node startup, however, the user 
> doesn't see automatically chosen memory settings. Also, if there a node runs 
> out of RAM and throws an OOM error there are no hints on why this happened 
> and how to fix it.
> Suggestions: 
> * Add {{off-heap}} field to {{Topology Snapshot}} message. The field will 
> accumulate maximum size of all the data regions defined cluster-wide:
> {code}
> Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, off-heap={N}, 
> heap=1.8GB, ]
> {code}
> * Print detailed memory configuration below {{Topology Snapshot}} message 
> following this format:
> {code}
> Data Regions Configured:
> ^-- Data_Region_Name [initSize=N, maxSize=N, persistenceEnabled={true|false}]
> {code}
> Example:
> {code}
> Data Regions Configured:
>^-- Default [initSize=100MB, maxSize=5.0 GB, persistenceEnabled=true]
>^-- RegionalMetrics [initSize=500MB, maxSize=15.0 GB, 
> persistenceEnabled=false]
> {code}
> * Provide guidelines on how to overcome OOM when it happens. Specify a data 
> region name with all its current parameters and suggest three possible things 
> - tweak maximum memory, setup eviction policies or enable Ignite persistence.
> {code}
> Out of memory in data region Region_Name [initSize=N, maxSize=N, 
> persistenceEnabled={true|false}]. Do one of the following:
>^-- Increase maximum size (DataRegionConfiguration.maxSize)
>^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled) 
> or
>^-- Enable eviction or expiration policies.
> {code}



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

[jira] [Created] (IGNITE-7150) Gradient boosting for lin regression

[Yury Babak (JIRA)]

Yury Babak created IGNITE-7150:
--

 Summary: Gradient boosting for lin regression
 Key: IGNITE-7150
 URL: https://issues.apache.org/jira/browse/IGNITE-7150
 Project: Ignite
  Issue Type: New Feature
  Components: ml
Reporter: Yury Babak


Currently for linreg we have only the analytical trainer (via QR 
decomposition). We want to add new trainer(implementation of Trainer interface) 
based on gradient boosting.



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

[jira] [Created] (IGNITE-7149) Gradient boosting for decision tree

[Yury Babak (JIRA)]

Yury Babak created IGNITE-7149:
--

 Summary: Gradient boosting for decision tree
 Key: IGNITE-7149
 URL: https://issues.apache.org/jira/browse/IGNITE-7149
 Project: Ignite
  Issue Type: New Feature
  Components: ml
Reporter: Yury Babak


We want to implement gradient boosting for decision trees. It should be new 
implementation of Trainer interface and we should keep possibility to choose 
which trainer we want to use for our tree.



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

[jira] [Comment Edited] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov edited comment on IGNITE-6711 at 12/8/17 10:50 AM:


Metric calculation is now fixed. There are some unfamiliar extra allocations at 
very first restart with PDS enabled, but in general the metric looks consistent.

[~avinogradov], could you please review the fix?


was (Author: andrey-kuznetsov):
[~avinogradov], could you please review the fix?

> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>  Labels: newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Commented] (IGNITE-6871) Implement new JMX metrics for partitions map monitoring

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6871:
--

[~alex_pl]
Looks good to me. 


> Implement new JMX metrics for partitions map monitoring
> ---
>
> Key: IGNITE-6871
> URL: https://issues.apache.org/jira/browse/IGNITE-6871
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>  Labels: iep-6, jmx
> Fix For: 2.4
>
>
> These additional metrics should be implemented to monitor partitions map per 
> each cache group:
> * Total primary partitions count located on the current node
> * Total backup partitions count located on the current node
> * Min/max partition backups left in the cluster for cache group
> * Maybe some methods to show partitions map/partition distribution statistics 
> in the cluster



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

[jira] [Issue Comment Deleted] (IGNITE-6867) Implement new JMX metrics for topology monitoring

[Max Shonichev (JIRA)]

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

Max Shonichev updated IGNITE-6867:
--
Comment: was deleted

(was: How come this merged to 2.4.1-p2?)

> Implement new JMX metrics for topology monitoring
> -
>
> Key: IGNITE-6867
> URL: https://issues.apache.org/jira/browse/IGNITE-6867
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>  Labels: iep-6, jmx
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> * Current topology version
> * Total server nodes count
> * Total client nodes count
> * Method to count nodes filtered by some node attribute
> * Method to count nodes grouped by some node attribute
>  
> There is already a ticket to implement first 2 metrics from this list 
> (IGNITE-6844)



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

[jira] [Commented] (IGNITE-6868) Implement new JMX metrics for TcpCommunicationSpi monitoring

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6868:
--

[~alex_pl]
Looks good to me. 

> Implement new JMX metrics for TcpCommunicationSpi monitoring
> 
>
> Key: IGNITE-6868
> URL: https://issues.apache.org/jira/browse/IGNITE-6868
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>  Labels: iep-6, jmx
> Fix For: 2.4
>
>
> These additional metrics should be implemented in TcpCommunicationSpi MBean:
> * Received messages count grouped by message type
> * Received messages count grouped by sender node
> * Sent messages count grouped by message type
> * Sent messages count grouped by receiver node



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

[jira] [Created] (IGNITE-7148) BinaryMetadata file store should check each file whether it is corrupted (zero length)

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-7148:
---

 Summary: BinaryMetadata file store should check each file whether 
it is corrupted (zero length)
 Key: IGNITE-7148
 URL: https://issues.apache.org/jira/browse/IGNITE-7148
 Project: Ignite
  Issue Type: Improvement
Reporter: Sergey Chugunov


If some binary metadata file from binary_meta directory is corrupted (e.g. 
because of node crash) it leads to errors during startup procedure. Node cannot 
be started without user intervention (manual deleting corrupted file).

BinaryMetadataFileStore should check this situation and delete corrupted files 
automatically as corresponding BinaryMetadata will be synchronized with other 
nodes as part of node join process.



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

[jira] [Updated] (IGNITE-7148) BinaryMetadata file store should check each file whether it is corrupted (zero length)

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov updated IGNITE-7148:

Priority: Critical  (was: Major)

> BinaryMetadata file store should check each file whether it is corrupted 
> (zero length)
> --
>
> Key: IGNITE-7148
> URL: https://issues.apache.org/jira/browse/IGNITE-7148
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Priority: Critical
>
> If some binary metadata file from binary_meta directory is corrupted (e.g. 
> because of node crash) it leads to errors during startup procedure. Node 
> cannot be started without user intervention (manual deleting corrupted file).
> BinaryMetadataFileStore should check this situation and delete corrupted 
> files automatically as corresponding BinaryMetadata will be synchronized with 
> other nodes as part of node join process.



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

[jira] [Assigned] (IGNITE-7052) S3 IP finder: add an ability to provide endpoint address

[Alexey Popov (JIRA)]

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

Alexey Popov reassigned IGNITE-7052:


Assignee: Alexey Popov

> S3 IP finder: add an ability to provide endpoint address
> 
>
> Key: IGNITE-7052
> URL: https://issues.apache.org/jira/browse/IGNITE-7052
> Project: Ignite
>  Issue Type: Improvement
>  Components: s3
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Popov
> Fix For: 2.4
>
>
> By default S3 client detects region automatically by sending special request 
> to {{us-west-1}}. In case environment is restricted to some other region, 
> this leads to connection timeout exception.
> The issue can be solved by providing a specific region endpoint via 
> {{AmazonS3Client#setEndpoint}} method. To support this we need to add 
> {{endpoint}} configuration property to the IP finder.
> List of S3 region endpoints: 
> http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region



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

[jira] [Commented] (IGNITE-7052) S3 IP finder: add an ability to provide endpoint address

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-7052:
--

A scope of changes:
1. added {{bucketEndpoint}} configuration property to {{TcpDiscoveryS3IpFinder}}
2. added {{bucketEndpoint}} configuration property to {{S3CheckpointSpi}}
3. added tests for new property
4. updated existent tests to avoid bucket name conflicts

[~ntikho...@apache.org], please review

TC run:
https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F3179%2Fhead

> S3 IP finder: add an ability to provide endpoint address
> 
>
> Key: IGNITE-7052
> URL: https://issues.apache.org/jira/browse/IGNITE-7052
> Project: Ignite
>  Issue Type: Improvement
>  Components: s3
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
> Fix For: 2.4
>
>
> By default S3 client detects region automatically by sending special request 
> to {{us-west-1}}. In case environment is restricted to some other region, 
> this leads to connection timeout exception.
> The issue can be solved by providing a specific region endpoint via 
> {{AmazonS3Client#setEndpoint}} method. To support this we need to add 
> {{endpoint}} configuration property to the IP finder.
> List of S3 region endpoints: 
> http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region



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

[jira] [Assigned] (IGNITE-6976) Visor CMD: Add ability to put/get/remove data to caches via command line Visor.

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-6976:
-

Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

> Visor CMD: Add ability to put/get/remove data to caches via command line 
> Visor.
> ---
>
> Key: IGNITE-6976
> URL: https://issues.apache.org/jira/browse/IGNITE-6976
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>




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

[jira] [Commented] (IGNITE-6976) Visor CMD: Add ability to put/get/remove data to caches via command line Visor.

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-6976:
---

Updated documentation for modify command.
Implemented possibility to use short class name in kt and vt arguments. 
Fixed check of active state for modify command.



> Visor CMD: Add ability to put/get/remove data to caches via command line 
> Visor.
> ---
>
> Key: IGNITE-6976
> URL: https://issues.apache.org/jira/browse/IGNITE-6976
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Vasiliy Sisko
> Fix For: 2.4
>
>




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

[jira] [Assigned] (IGNITE-7147) Implemente connected clusters component

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin reassigned IGNITE-7147:


Assignee: Alexey Kuznetsov  (was: Dmitriy Shabalin)

[~kuaw26] added, pls review it

> Implemente connected clusters component
> ---
>
> Key: IGNITE-7147
> URL: https://issues.apache.org/jira/browse/IGNITE-7147
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
>




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

[jira] [Commented] (IGNITE-7145) Visor CMD: Fix tests for: Ignite Visor Console

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7145:


Tested.

> Visor CMD: Fix tests for: Ignite Visor Console
> --
>
> Key: IGNITE-7145
> URL: https://issues.apache.org/jira/browse/IGNITE-7145
> Project: Ignite
>  Issue Type: Test
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>
> https://ci.ignite.apache.org/viewLog.html?buildId=984720=buildResultsDiv=Ignite20Tests_IgniteVisorConsoleTestDetach



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

[jira] [Assigned] (IGNITE-7145) Visor CMD: Fix tests for: Ignite Visor Console

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-7145:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Visor CMD: Fix tests for: Ignite Visor Console
> --
>
> Key: IGNITE-7145
> URL: https://issues.apache.org/jira/browse/IGNITE-7145
> Project: Ignite
>  Issue Type: Test
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>
> https://ci.ignite.apache.org/viewLog.html?buildId=984720=buildResultsDiv=Ignite20Tests_IgniteVisorConsoleTestDetach



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

[jira] [Commented] (IGNITE-7052) S3 IP finder: add an ability to provide endpoint address

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7052:


GitHub user apopovgg opened a pull request:

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

IGNITE-7052 S3 IP finder: add an ability to provide endpoint address



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

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

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

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

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

This closes #3179


commit b2fef64ae69af259d17953ed11038d3c82981aa5
Author: apopov 
Date:   2017-12-08T08:54:18Z

IGNITE-7052 S3 IP finder: add an ability to provide endpoint address




> S3 IP finder: add an ability to provide endpoint address
> 
>
> Key: IGNITE-7052
> URL: https://issues.apache.org/jira/browse/IGNITE-7052
> Project: Ignite
>  Issue Type: Improvement
>  Components: s3
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
> Fix For: 2.4
>
>
> By default S3 client detects region automatically by sending special request 
> to {{us-west-1}}. In case environment is restricted to some other region, 
> this leads to connection timeout exception.
> The issue can be solved by providing a specific region endpoint via 
> {{AmazonS3Client#setEndpoint}} method. To support this we need to add 
> {{endpoint}} configuration property to the IP finder.
> List of S3 region endpoints: 
> http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region



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

[jira] [Commented] (IGNITE-7135) IgniteCluster.startNodes() returns successful ClusterStartNodeResult even though the remote process fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7135:


GitHub user akuramshingg opened a pull request:

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

IGNITE-7135 IgniteCluster.startNodes() returns successful 
ClusterStartNodeResult even though the remote process fails.

Fix windows startup scripts. Add startNodes() Windows support through task 
scheduling.
Check successful node startup by reading the output log.

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

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

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

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

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

This closes #3178


commit 8efb48f51f7e33dfc760657527957d3bf5138fb6
Author: Alexandr Kuramshin 
Date:   2017-12-07T20:42:47Z

IGNITE-7135 IgniteCluster.startNodes() returns successful 
ClusterStartNodeResult even though the remote process fails.

Fix windows startup scripts. Add startNodes() Windows support through task 
scheduling.

commit e5319d57310c0fab1f22ae279f0db18a6150b243
Author: Alexandr Kuramshin 
Date:   2017-12-08T08:46:53Z

IGNITE-7135 IgniteCluster.startNodes() returns successful 
ClusterStartNodeResult even though the remote process fails.

Check successful node startup by reading the output log.




> IgniteCluster.startNodes() returns successful ClusterStartNodeResult even 
> though the remote process fails
> -
>
> Key: IGNITE-7135
> URL: https://issues.apache.org/jira/browse/IGNITE-7135
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
>  Labels: test
> Fix For: 2.4
>
>
> After unsuccessful start of three remote nodes with 
> {{IgniteCluster#startNodes(Collection>, 
> Map, boolean, int, int)}} we get 
> {{Collection}} with three elements, each has 
> {{isSuccess()}} is true.
> But the remote node startup log was
> {noformat}
> nohup: ignoring input
> /data/teamcity/work/820be461cd64b574/bin/ignite.sh, ERROR:
> The version of JAVA installed in JAVA_HOME=/usr/lib/jvm/java-9-oracle is 
> incorrect.
> Please point JAVA_HOME variable to installation of JDK 1.7 or JDK 1.8.
> You can also download latest JDK at http://java.com/download
> {noformat}



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

[jira] [Created] (IGNITE-7147) Implemente connected clusters component

[Dmitriy Shabalin (JIRA)]

Dmitriy Shabalin created IGNITE-7147:


 Summary: Implemente connected clusters component
 Key: IGNITE-7147
 URL: https://issues.apache.org/jira/browse/IGNITE-7147
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Dmitriy Shabalin
Assignee: Dmitriy Shabalin






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