[jira] [Comment Edited] (IGNITE-7122) Page lock status is not checked in BPlusTree.treePrinter methods
[
https://issues.apache.org/jira/browse/IGNITE-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284224#comment-16284224
]
Igor Seliverstov edited comment on IGNITE-7122 at 12/8/17 9:17 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] [Commented] (IGNITE-7122) Page lock status is not checked in BPlusTree.treePrinter methods
[
https://issues.apache.org/jira/browse/IGNITE-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/IGNITE-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[
https://issues.apache.org/jira/browse/IGNITE-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280426#comment-16280426
]
Oleg Ignatenko edited comment on IGNITE-7097 at 12/8/17 5:23 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 I increased that SIZE param by 2 it seems to run unacceptably long.
Specifically, when three hosts were emulated on a single machine it run for 2
hours and when these were 3 real hosts, it run for over half hour. This is way
too long and additionally, generated charts didn't look OK.
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 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.
> 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-7097) performance measurement for SparseDistributedMatrix multiplication
[
https://issues.apache.org/jira/browse/IGNITE-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/IGNITE-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&branch_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-7053) S3 IP finder: support server side encryption
[
https://issues.apache.org/jira/browse/IGNITE-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283808#comment-16283808
]
Alexey Popov commented on IGNITE-7053:
--
https://github.com/apache/ignite/pull/3189
> 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
[ https://issues.apache.org/jira/browse/IGNITE-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[
https://issues.apache.org/jira/browse/IGNITE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&tab=buildResultsDiv&buildTypeId=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
[
https://issues.apache.org/jira/browse/IGNITE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/IGNITE-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/IGNITE-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (IGNITE-4750) SQL: Support GROUP_CONCAT function
[ https://issues.apache.org/jira/browse/IGNITE-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283693#comment-16283693 ] ASF GitHub Bot commented on IGNITE-4750: GitHub user tledkov-gridgain opened a pull request: https://github.com/apache/ignite/pull/3185 IGNITE-4750: support GROUP_CONCAT for collocated queries You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4750 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3185.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 #3185 commit 31ac1f2e2b51246aaf9a20a22823edc79cb2305e Author: tledkov-gridgain Date: 2017-12-08T15:00:44Z IGNITE-4750: support GROUP_CONCAT for collocated queries > 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
[
https://issues.apache.org/jira/browse/IGNITE-4192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[
https://issues.apache.org/jira/browse/IGNITE-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/IGNITE-4192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (IGNITE-4192) SQL TX: JDBC driver support
[
https://issues.apache.org/jira/browse/IGNITE-4192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283683#comment-16283683
]
Alexander Paschenko commented on IGNITE-4192:
-
[~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
[
https://issues.apache.org/jira/browse/IGNITE-4192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-4192) SQL TX: JDBC driver support
[
https://issues.apache.org/jira/browse/IGNITE-4192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283666#comment-16283666
]
Vladimir Ozerov commented on IGNITE-4192:
-
Most probably transaction should be bound to {{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-4192) SQL TX: JDBC driver support
[
https://issues.apache.org/jira/browse/IGNITE-4192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283661#comment-16283661
]
Vladimir Ozerov commented on IGNITE-4192:
-
[~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] [Comment Edited] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart
[ https://issues.apache.org/jira/browse/IGNITE-6711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281497#comment-16281497 ] Andrey Kuznetsov edited comment on IGNITE-6711 at 12/8/17 2:21 PM: --- Metric calculation is now fixed [1]. There are some unfamiliar extra allocations at very first restart with PDS enabled, but in general the metric looks consistent. CI tests are queued right now. This change also provides correct value of derived metric in [2] [1] https://github.com/apache/ignite/pull/3165 [2] https://issues.apache.org/jira/browse/IGNITE-6902 was (Author: andrey-kuznetsov): Metric calculation is now fixed [1]. There are some unfamiliar extra allocations at very first restart with PDS enabled, but in general the metric looks consistent. CI tests are queued right now. [1] https://github.com/apache/ignite/pull/3165 > 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] [Issue Comment Deleted] (IGNITE-6171) Native facility to control excessive GC pauses
[ https://issues.apache.org/jira/browse/IGNITE-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-6171: Comment: was deleted (was: [~avinogradov], review new patch, please!) > Native facility to control excessive GC pauses > -- > > Key: IGNITE-6171 > URL: https://issues.apache.org/jira/browse/IGNITE-6171 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 2.3 >Reporter: Vladimir Ozerov >Assignee: Dmitriy Sorokin > Labels: iep-7, usability > Fix For: 2.4 > > > Ignite is Java-based application. If node experiences long GC pauses it may > negatively affect other nodes. We need to find a way to detect long GC pauses > within the process and trigger some actions in response, e.g. node stop. > This is a kind of Inception \[1\], when you need to understand that you sleep > while sleeping. As all Java threads are blocked on safepoint, we cannot use > Java's thread to detect Java's GC. Native threads should be used instead. > Proposed solution: > 1) Thread 1 should periodically call dummy JNI method returning current time, > and set this time to shared variable; > 2) Thread 2 should periodically check that variable. If it has not been > changed for some time - most likely we are in GC pause. Once certain > threashold is reached - trigger compensating action, whether this is a > warning, process kill, or what so ever. > Justification: crossing native -> Java boundaries involves safepoints. This > way Thread 1 will be trapped if STW pause is in progress. Java method cannot > be empty, as JVM is smart enough and can deduce it to no-op. > \[1\] http://www.imdb.com/title/tt1375666/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart
[ https://issues.apache.org/jira/browse/IGNITE-6711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281497#comment-16281497 ] Andrey Kuznetsov edited comment on IGNITE-6711 at 12/8/17 2:11 PM: --- Metric calculation is now fixed [1]. There are some unfamiliar extra allocations at very first restart with PDS enabled, but in general the metric looks consistent. CI tests are queued right now. [1] https://github.com/apache/ignite/pull/3165 was (Author: andrey-kuznetsov): 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. > 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-6915) SQL: Failed to invoke getter method (type=class java.lang.String)
[
https://issues.apache.org/jira/browse/IGNITE-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 java.lang.reflect.Me
[jira] [Commented] (IGNITE-5768) Retry resolving class name from marshaller cache and .classname file
[
https://issues.apache.org/jira/browse/IGNITE-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/IGNITE-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > org.apache.ignite.internal.
[jira] [Assigned] (IGNITE-7053) S3 IP finder: support server side encryption
[
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
[ https://issues.apache.org/jira/browse/IGNITE-7136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-7136: --- Assignee: (was: Nikolay Izhikov) > 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 > 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] [Comment Edited] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart
[ https://issues.apache.org/jira/browse/IGNITE-6711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281497#comment-16281497 ] Andrey Kuznetsov edited comment on IGNITE-6711 at 12/8/17 12:57 PM: 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. was (Author: andrey-kuznetsov): 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? > 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] [Assigned] (IGNITE-7136) Add JMX metric for indexing to .Net
[ 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 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
[
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
[
https://issues.apache.org/jira/browse/IGNITE-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-6902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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()
[
https://issues.apache.org/jira/browse/IGNITE-7134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-6902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
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
[
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 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.
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-6902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/IGNITE-7114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[
https://issues.apache.org/jira/browse/IGNITE-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[
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 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 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
[ https://issues.apache.org/jira/browse/IGNITE-6711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-6868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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)
[ 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] [Updated] (IGNITE-7148) BinaryMetadata file store should check each file whether it is corrupted (zero length)
[ https://issues.apache.org/jira/browse/IGNITE-7148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-7148: Issue Type: Bug (was: Improvement) > 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 > > 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
[
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
[
https://issues.apache.org/jira/browse/IGNITE-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&branch_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.
[ 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.
[ https://issues.apache.org/jira/browse/IGNITE-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-7145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&tab=buildResultsDiv&buildTypeId=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
[ 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&tab=buildResultsDiv&buildTypeId=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
[
https://issues.apache.org/jira/browse/IGNITE-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/IGNITE-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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)
