[jira] [Comment Edited] (IGNITE-10791) Avoid unusable network during discovery
[ https://issues.apache.org/jira/browse/IGNITE-10791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730593#comment-16730593 ] Tran Ly Vu edited comment on IGNITE-10791 at 12/30/18 5:35 AM: --- Hi, I would like to work on this issue, thanks ,[~syssoftsol] @[~slukyanov] please guide me along, which files should i look at? was (Author: tranlyvu): Hi, I would like to work on this issue, thanks ,[~syssoftsol] @[~slukyanov] please help to assign to me > Avoid unusable network during discovery > - > > Key: IGNITE-10791 > URL: https://issues.apache.org/jira/browse/IGNITE-10791 > Project: Ignite > Issue Type: Improvement >Reporter: David Harvey >Assignee: Tran Ly Vu >Priority: Major > Labels: newbie > > Problem: In some deployments, there are multiple IP addresses, and S3 > discovery tries them in some random order, and times out on the ones that > don't work, slowing down discovery unnecessarily. In many such cases, the > set of unusable address is known by humans, but is not discoverable at > runtime. For example, some IP addresses may be blocked by firewalls. On > ECS, the docker bridge network IPs are visible, but are unusable across nodes. > The node pushing IPs to S3 does not have the enough info to decide which of > its address is valid. > > [http://apache-ignite-users.70518.x6.nabble.com/Avoiding-Docker-Bridge-network-when-using-S3-discovery-td24778.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10852) [Documentation] - Add details on to public API behaviour
Alexander Gerus created IGNITE-10852: Summary: [Documentation] - Add details on to public API behaviour Key: IGNITE-10852 URL: https://issues.apache.org/jira/browse/IGNITE-10852 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 2.7, 2.6, 2.5, 2.4 Reporter: Alexander Gerus Current public API documentation has some specification gaps. In case if method was not successfully executed, it is not clear what should be done by user code. Good practice is to describe all API exceptions that can be processed by user code and recommended actions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10645) SQL properties ownership flag should be set at configuration parsing, not query execution.
[
https://issues.apache.org/jira/browse/IGNITE-10645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730793#comment-16730793
]
Ignite TC Bot commented on IGNITE-10645:
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 5{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2679781]]
* IgniteCacheWithIndexingTestSuite:
CacheBinaryKeyConcurrentQueryTest.testPutAndQueries - 0,0% fails in last 407
master runs.
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2679815&buildTypeId=IgniteTests24Java8_RunAll]
> SQL properties ownership flag should be set at configuration parsing, not
> query execution.
> --
>
> Key: IGNITE-10645
> URL: https://issues.apache.org/jira/browse/IGNITE-10645
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> At processing time, query entities are transformed and validated, table
> descriptors with properties are created.
> Now in some case (thre's no keyFields and key is of complex non-sql type),
> ownership flag of query property is calculated at execution time (for example
> at first put()):
> https://github.com/apache/ignite/blob/dcdb27a24a450f63487290360b265e1570534629/modules/core/src/main/java/org/apache/ignite/internal/processors/query/property/QueryBinaryProperty.java#L132
> So we can't access metadata, that uses this not-yet-initialized field before
> we put the data.
> But we already have all necessary info to set this field at processing time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8617) Node Discovery Using AWS Application ELB
[ https://issues.apache.org/jira/browse/IGNITE-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730783#comment-16730783 ] Uday Kale commented on IGNITE-8617: --- [~slukyanov], I have made the necessary changes. Please have a look. > Node Discovery Using AWS Application ELB > > > Key: IGNITE-8617 > URL: https://issues.apache.org/jira/browse/IGNITE-8617 > Project: Ignite > Issue Type: New Feature > Components: aws, documentation >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.8 > > > Support for Node discovery using AWS Application ELB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8617) Node Discovery Using AWS Application ELB
[ https://issues.apache.org/jira/browse/IGNITE-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uday Kale updated IGNITE-8617: -- Component/s: documentation > Node Discovery Using AWS Application ELB > > > Key: IGNITE-8617 > URL: https://issues.apache.org/jira/browse/IGNITE-8617 > Project: Ignite > Issue Type: New Feature > Components: aws, documentation >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.8 > > > Support for Node discovery using AWS Application ELB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10791) Avoid unusable network during discovery
[ https://issues.apache.org/jira/browse/IGNITE-10791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tran Ly Vu reassigned IGNITE-10791: --- Assignee: Tran Ly Vu > Avoid unusable network during discovery > - > > Key: IGNITE-10791 > URL: https://issues.apache.org/jira/browse/IGNITE-10791 > Project: Ignite > Issue Type: Improvement >Reporter: David Harvey >Assignee: Tran Ly Vu >Priority: Major > Labels: newbie > > Problem: In some deployments, there are multiple IP addresses, and S3 > discovery tries them in some random order, and times out on the ones that > don't work, slowing down discovery unnecessarily. In many such cases, the > set of unusable address is known by humans, but is not discoverable at > runtime. For example, some IP addresses may be blocked by firewalls. On > ECS, the docker bridge network IPs are visible, but are unusable across nodes. > The node pushing IPs to S3 does not have the enough info to decide which of > its address is valid. > > [http://apache-ignite-users.70518.x6.nabble.com/Avoiding-Docker-Bridge-network-when-using-S3-discovery-td24778.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10645) SQL properties ownership flag should be set at configuration parsing, not query execution.
[
https://issues.apache.org/jira/browse/IGNITE-10645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730772#comment-16730772
]
Pavel Kuznetsov commented on IGNITE-10645:
--
[~vozerov] Yes, there were 2 tests with incorrect configurations, fixed them
(python and {{CacheBinaryKeyConcurrentQueryTest.testPutAndQueries}} )
> SQL properties ownership flag should be set at configuration parsing, not
> query execution.
> --
>
> Key: IGNITE-10645
> URL: https://issues.apache.org/jira/browse/IGNITE-10645
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> At processing time, query entities are transformed and validated, table
> descriptors with properties are created.
> Now in some case (thre's no keyFields and key is of complex non-sql type),
> ownership flag of query property is calculated at execution time (for example
> at first put()):
> https://github.com/apache/ignite/blob/dcdb27a24a450f63487290360b265e1570534629/modules/core/src/main/java/org/apache/ignite/internal/processors/query/property/QueryBinaryProperty.java#L132
> So we can't access metadata, that uses this not-yet-initialized field before
> we put the data.
> But we already have all necessary info to set this field at processing time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10732) Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between nodes
[
https://issues.apache.org/jira/browse/IGNITE-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730735#comment-16730735
]
Ilya Kasnacheev commented on IGNITE-10732:
--
Blockers are probably due to old master.
> Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between
> nodes
> --
>
> Key: IGNITE-10732
> URL: https://issues.apache.org/jira/browse/IGNITE-10732
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: windows
>
> When doing
> {code}
> cache.query(new SqlFieldsQuery("SELECT _key FROM Cache"))
> {code}
> resulting Unicode values may be different when coming from Windows or Linux
> node.
> Linux nodes will mostly use UTF-8 but Windows nodes will use local Cp
> encoding to encode query results, as bizzare as it may sound.
> Windows < - > Windows and Linux < - > Linux will get correct result but
> Windows < - > Linux will get broken strings.
> Note that if cluster has Windows and Linux nodes and cache is REPLICATED,
> results will be different for subsequent queries!
> There is a workaround for this: set -Dfile.encoding=UTF-8 JVM arg on Windows.
> There is probably an underlying problem in H2 but since non-UTF-8
> file.encoding is dangerous (it affects String.getBytes()) I think we should
> peg it to UTF-8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10732) Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between nodes
[
https://issues.apache.org/jira/browse/IGNITE-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730733#comment-16730733
]
Ignite TC Bot commented on IGNITE-10732:
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2678135]]
* ZookeeperDiscoverySpiTestSuite4:
GridCacheReplicatedAtomicMultiNodeFullApiSelfTest.testTtlNoTxOldEntry - 0,0%
fails in last 422 master runs.
{color:#d04437}Cache (Restarts) 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2678099]]
* IgniteCacheRestartTestSuite:
GridCacheReplicatedNodeRestartSelfTest.testRestartWithPutFourNodesNoBackups -
0,0% fails in last 401 master runs.
{color:#d04437}Cache (Restarts) 2{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=2678100]]
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutTenNodesTwoBackups
- 0,0% fails in last 426 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithPutTenNodesTwoBackups - 0,0%
fails in last 426 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithPutFourNodesNoBackups - 0,0%
fails in last 258 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutFourNodesNoBackups
- 0,0% fails in last 426 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithTxPutAllTenNodesTwoBackups
- 0,0% fails in last 426 master runs.
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2678140&buildTypeId=IgniteTests24Java8_RunAll]
> Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between
> nodes
> --
>
> Key: IGNITE-10732
> URL: https://issues.apache.org/jira/browse/IGNITE-10732
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: windows
>
> When doing
> {code}
> cache.query(new SqlFieldsQuery("SELECT _key FROM Cache"))
> {code}
> resulting Unicode values may be different when coming from Windows or Linux
> node.
> Linux nodes will mostly use UTF-8 but Windows nodes will use local Cp
> encoding to encode query results, as bizzare as it may sound.
> Windows < - > Windows and Linux < - > Linux will get correct result but
> Windows < - > Linux will get broken strings.
> Note that if cluster has Windows and Linux nodes and cache is REPLICATED,
> results will be different for subsequent queries!
> There is a workaround for this: set -Dfile.encoding=UTF-8 JVM arg on Windows.
> There is probably an underlying problem in H2 but since non-UTF-8
> file.encoding is dangerous (it affects String.getBytes()) I think we should
> peg it to UTF-8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8223) GridNearTxLocal.clearPrepareFuture does effectively nothing
[
https://issues.apache.org/jira/browse/IGNITE-8223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rodion reassigned IGNITE-8223:
--
Assignee: Rodion
> GridNearTxLocal.clearPrepareFuture does effectively nothing
> ---
>
> Key: IGNITE-8223
> URL: https://issues.apache.org/jira/browse/IGNITE-8223
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Rodion
>Priority: Trivial
> Labels: newbie
> Fix For: 2.8
>
>
> It's unclear whether {{GridNearTxLocal.clearPrepareFuture}} is called at all,
> but the method does nothing, since its argument type is never used as target
> field value. Proposed change is to make the method no-op explicitly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10580) H2 connection and statements are reused invalid for local sql queries
[
https://issues.apache.org/jira/browse/IGNITE-10580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730708#comment-16730708
]
Taras Ledkov commented on IGNITE-10580:
---
[~vozerov]
The H2 connection leak is fixed. Unfortunately we have to add two collections
of {{Connection}} to track opened connections.
It may be cause of a little performance drop. May be it makes sense to run the
benchmarks.
Also the new class {{AbstractIndexingCommonTest}} is used as the base class for
the most tests in the *indexing* module to check all H2 connection are closed
at the end of the test.
> H2 connection and statements are reused invalid for local sql queries
> -
>
> Key: IGNITE-10580
> URL: https://issues.apache.org/jira/browse/IGNITE-10580
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
>
> The threadlocal connection & statement cache is used invalid for local
> queries.
> Steps to reproduce:
> # Open iterator for local query {{Query0}};
> # In the same thread open one more iterator for {{Query1}} (SQl statement
> must be equals to {{Query0}} and doesn't contains query parameters);
> # Fetch from the first iterator.
> The exception {{The object is already closed [90007-197]}} will be thrown.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8911) While cache is restarting it's possible to start new cache with this name
[ https://issues.apache.org/jira/browse/IGNITE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730706#comment-16730706 ] ASF GitHub Bot commented on IGNITE-8911: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5717 > While cache is restarting it's possible to start new cache with this name > - > > Key: IGNITE-8911 > URL: https://issues.apache.org/jira/browse/IGNITE-8911 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.8 > > > We have the state "restarting" for caches when we certainly now that these > caches would start at some moment in future. But we could start new cache > with the same name. > Plus, NPE is throwing when we try to get proxy for such caches (in > "restarting" state). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8911) While cache is restarting it's possible to start new cache with this name
[ https://issues.apache.org/jira/browse/IGNITE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730705#comment-16730705 ] Dmitriy Govorukhin commented on IGNITE-8911: [~EdShangGG] Looks good to me, thanks for the contribution! > While cache is restarting it's possible to start new cache with this name > - > > Key: IGNITE-8911 > URL: https://issues.apache.org/jira/browse/IGNITE-8911 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.8 > > > We have the state "restarting" for caches when we certainly now that these > caches would start at some moment in future. But we could start new cache > with the same name. > Plus, NPE is throwing when we try to get proxy for such caches (in > "restarting" state). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10732) Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between nodes
[
https://issues.apache.org/jira/browse/IGNITE-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730688#comment-16730688
]
Ilya Kasnacheev commented on IGNITE-10732:
--
[~isapego] please review C++ part of commit.
> Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between
> nodes
> --
>
> Key: IGNITE-10732
> URL: https://issues.apache.org/jira/browse/IGNITE-10732
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: windows
>
> When doing
> {code}
> cache.query(new SqlFieldsQuery("SELECT _key FROM Cache"))
> {code}
> resulting Unicode values may be different when coming from Windows or Linux
> node.
> Linux nodes will mostly use UTF-8 but Windows nodes will use local Cp
> encoding to encode query results, as bizzare as it may sound.
> Windows < - > Windows and Linux < - > Linux will get correct result but
> Windows < - > Linux will get broken strings.
> Note that if cluster has Windows and Linux nodes and cache is REPLICATED,
> results will be different for subsequent queries!
> There is a workaround for this: set -Dfile.encoding=UTF-8 JVM arg on Windows.
> There is probably an underlying problem in H2 but since non-UTF-8
> file.encoding is dangerous (it affects String.getBytes()) I think we should
> peg it to UTF-8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10851) Improve WalCompactionSwitchOnTest to rely on rollOver() instead of hardcoded values.
[ https://issues.apache.org/jira/browse/IGNITE-10851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-10851: Labels: MakeTeamcityGreenAgain (was: ) > Improve WalCompactionSwitchOnTest to rely on rollOver() instead of hardcoded > values. > > > Key: IGNITE-10851 > URL: https://issues.apache.org/jira/browse/IGNITE-10851 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Priority: Major > Labels: MakeTeamcityGreenAgain > > WalCompactionSwitchOnTest expects hardcoded number of segments after load. > This is flaky approach, we need to calculate expected size using WAL > rollOver() and archive compressed events. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10732) Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between nodes
[
https://issues.apache.org/jira/browse/IGNITE-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730689#comment-16730689
]
Ilya Kasnacheev commented on IGNITE-10732:
--
[~vveider] please review shell/bat part of commit.
> Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between
> nodes
> --
>
> Key: IGNITE-10732
> URL: https://issues.apache.org/jira/browse/IGNITE-10732
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: windows
>
> When doing
> {code}
> cache.query(new SqlFieldsQuery("SELECT _key FROM Cache"))
> {code}
> resulting Unicode values may be different when coming from Windows or Linux
> node.
> Linux nodes will mostly use UTF-8 but Windows nodes will use local Cp
> encoding to encode query results, as bizzare as it may sound.
> Windows < - > Windows and Linux < - > Linux will get correct result but
> Windows < - > Linux will get broken strings.
> Note that if cluster has Windows and Linux nodes and cache is REPLICATED,
> results will be different for subsequent queries!
> There is a workaround for this: set -Dfile.encoding=UTF-8 JVM arg on Windows.
> There is probably an underlying problem in H2 but since non-UTF-8
> file.encoding is dangerous (it affects String.getBytes()) I think we should
> peg it to UTF-8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10732) Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between nodes
[
https://issues.apache.org/jira/browse/IGNITE-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730687#comment-16730687
]
Ilya Kasnacheev commented on IGNITE-10732:
--
[~ptupitsyn] please review C# part of commit
> Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between
> nodes
> --
>
> Key: IGNITE-10732
> URL: https://issues.apache.org/jira/browse/IGNITE-10732
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: windows
>
> When doing
> {code}
> cache.query(new SqlFieldsQuery("SELECT _key FROM Cache"))
> {code}
> resulting Unicode values may be different when coming from Windows or Linux
> node.
> Linux nodes will mostly use UTF-8 but Windows nodes will use local Cp
> encoding to encode query results, as bizzare as it may sound.
> Windows < - > Windows and Linux < - > Linux will get correct result but
> Windows < - > Linux will get broken strings.
> Note that if cluster has Windows and Linux nodes and cache is REPLICATED,
> results will be different for subsequent queries!
> There is a workaround for this: set -Dfile.encoding=UTF-8 JVM arg on Windows.
> There is probably an underlying problem in H2 but since non-UTF-8
> file.encoding is dangerous (it affects String.getBytes()) I think we should
> peg it to UTF-8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10732) Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between nodes
[
https://issues.apache.org/jira/browse/IGNITE-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev reassigned IGNITE-10732:
Assignee: Ilya Kasnacheev
> Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between
> nodes
> --
>
> Key: IGNITE-10732
> URL: https://issues.apache.org/jira/browse/IGNITE-10732
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: windows
>
> When doing
> {code}
> cache.query(new SqlFieldsQuery("SELECT _key FROM Cache"))
> {code}
> resulting Unicode values may be different when coming from Windows or Linux
> node.
> Linux nodes will mostly use UTF-8 but Windows nodes will use local Cp
> encoding to encode query results, as bizzare as it may sound.
> Windows < - > Windows and Linux < - > Linux will get correct result but
> Windows < - > Linux will get broken strings.
> Note that if cluster has Windows and Linux nodes and cache is REPLICATED,
> results will be different for subsequent queries!
> There is a workaround for this: set -Dfile.encoding=UTF-8 JVM arg on Windows.
> There is probably an underlying problem in H2 but since non-UTF-8
> file.encoding is dangerous (it affects String.getBytes()) I think we should
> peg it to UTF-8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10732) Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between nodes
[
https://issues.apache.org/jira/browse/IGNITE-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730686#comment-16730686
]
Ilya Kasnacheev commented on IGNITE-10732:
--
[~dpavlov] please review proposed fix
> Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between
> nodes
> --
>
> Key: IGNITE-10732
> URL: https://issues.apache.org/jira/browse/IGNITE-10732
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: windows
>
> When doing
> {code}
> cache.query(new SqlFieldsQuery("SELECT _key FROM Cache"))
> {code}
> resulting Unicode values may be different when coming from Windows or Linux
> node.
> Linux nodes will mostly use UTF-8 but Windows nodes will use local Cp
> encoding to encode query results, as bizzare as it may sound.
> Windows < - > Windows and Linux < - > Linux will get correct result but
> Windows < - > Linux will get broken strings.
> Note that if cluster has Windows and Linux nodes and cache is REPLICATED,
> results will be different for subsequent queries!
> There is a workaround for this: set -Dfile.encoding=UTF-8 JVM arg on Windows.
> There is probably an underlying problem in H2 but since non-UTF-8
> file.encoding is dangerous (it affects String.getBytes()) I think we should
> peg it to UTF-8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10732) Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between nodes
[
https://issues.apache.org/jira/browse/IGNITE-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730685#comment-16730685
]
Ignite TC Bot commented on IGNITE-10732:
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2614888]]
* IgniteCacheTestSuite7:
TxRollbackAsyncWithPersistenceTest.testSynchronousRollback - 0,0% fails in last
406 master runs.
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2614918&buildTypeId=IgniteTests24Java8_RunAll]
> Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between
> nodes
> --
>
> Key: IGNITE-10732
> URL: https://issues.apache.org/jira/browse/IGNITE-10732
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Priority: Critical
> Labels: windows
>
> When doing
> {code}
> cache.query(new SqlFieldsQuery("SELECT _key FROM Cache"))
> {code}
> resulting Unicode values may be different when coming from Windows or Linux
> node.
> Linux nodes will mostly use UTF-8 but Windows nodes will use local Cp
> encoding to encode query results, as bizzare as it may sound.
> Windows < - > Windows and Linux < - > Linux will get correct result but
> Windows < - > Linux will get broken strings.
> Note that if cluster has Windows and Linux nodes and cache is REPLICATED,
> results will be different for subsequent queries!
> There is a workaround for this: set -Dfile.encoding=UTF-8 JVM arg on Windows.
> There is probably an underlying problem in H2 but since non-UTF-8
> file.encoding is dangerous (it affects String.getBytes()) I think we should
> peg it to UTF-8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10307) SQL: Extract partition info from JOINs
[
https://issues.apache.org/jira/browse/IGNITE-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730684#comment-16730684
]
Vladimir Ozerov commented on IGNITE-10307:
--
Run All: https://ci.ignite.apache.org/viewQueued.html?itemId=2678037
> SQL: Extract partition info from JOINs
> --
>
> Key: IGNITE-10307
> URL: https://issues.apache.org/jira/browse/IGNITE-10307
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> Currently we do not extract partitions when JOINs are involved. Let's
> implement it. We may start with relatively simple rules:
> # No subqueries
> # No GROUP BY
> Then walk through JOINed tables and extract partitions from AND clauses.
> There are some tricky things to consider:
> # Resulting model (tree) must be craefted carefully so that we can reuse it
> later in thin clients for efficient co-location.
> # Resulting model may affect how we group tables during push-down phase.
> Probably this would be huuuge thing, so may be it is better to implement it
> in separate ticket
> # When JOIN is performed partition info might be "transferred" between
> tables. E.g.:
> {code}
> a INNER JOIN b ON a.id = b.affinity_id WHERE a.id = :1
> {code}
> In this case if tables are co-located (we may infer it automatically in some
> cases), then {{a.id=:1}} partition rule can be "transferred" to
> {{b.affinity_id=:1}}.
> Very good test coverage would be needed here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10307) SQL: Extract partition info from JOINs
[ https://issues.apache.org/jira/browse/IGNITE-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730683#comment-16730683 ] ASF GitHub Bot commented on IGNITE-10307: - GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/5774 IGNITE-10307 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10307 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5774.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 #5774 commit 967a4b3d5237ebd1e3d72af497a7d8e8bb8cb129 Author: devozerov Date: 2018-12-10T12:25:27Z Experimenting. commit 1420cf54e81b6450b7fa5929d96f75093b9652e9 Author: devozerov Date: 2018-12-11T12:18:51Z Initial modelling. commit bffb5888ec7cf99d52b0319cd887b4d03ccafde8 Author: devozerov Date: 2018-12-11T13:36:44Z WIP. commit 6d51a1813539f5a030ae97f1340e363ecf944ba9 Author: devozerov Date: 2018-12-11T13:37:16Z Merge branch 'master' into prune-joins commit a510d5efdb1a87014359ed71d72300b7d01c6781 Author: devozerov Date: 2018-12-11T13:39:45Z Merge branch 'query-rewrite' into prune-joins commit 0b016d2054364d0fc254fbe6f9390851339610bc Author: devozerov Date: 2018-12-11T15:03:10Z WIP. commit dfcf0fff4c8e1818203cddf124d9a3fd04f4 Author: devozerov Date: 2018-12-12T09:50:59Z Merge branch 'master' into ignite-10307 commit ddb32af91b3eb9dfa9b3d1e12f270c7f2313d98a Author: devozerov Date: 2018-12-12T13:09:21Z Merge branch 'master' into ignite-10307 commit e4f769a4f43da05123ca6ad1ca003a64dbb10ace Author: devozerov Date: 2018-12-18T08:11:21Z Merge branch 'master' into ignite-10307 # Conflicts: # modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/affinity/PartitionExtractor.java commit e78ed0c5ce24220874bed476d5613da1057f077f Author: devozerov Date: 2018-12-18T08:12:12Z Merged with master. commit 456f3440ab3de251ff912533f6c3f1734d392b64 Author: devozerov Date: 2018-12-18T09:06:46Z Implemented strict and non-strict partition extraction logic. commit ca318d4e6f28fa121705fc8289e263a3a5ac2472 Author: devozerov Date: 2018-12-18T09:16:33Z Affinity column name resolution for model. commit 2fa20fb1c876ecfaf6059ffd292a912db5c69b71 Author: devozerov Date: 2018-12-18T10:30:17Z Affinity descriptor. commit e1ccb5af84f938f9f609724a7c7131f0a2f24e77 Author: devozerov Date: 2018-12-18T12:02:29Z Join model for single table. commit 0945c74fe71bea5cefb8678fce1ee2b59c575250 Author: devozerov Date: 2018-12-18T12:39:40Z WIP. commit 6b630f25bda2a1e1c6317a65a73d3666d7d15476 Author: devozerov Date: 2018-12-18T14:55:26Z WIP. commit 5a2c38b69e832ebf4175a36c6b7c5af9d97c5ddf Author: devozerov Date: 2018-12-20T05:00:52Z Merge branch 'master' into ignite-10307 commit babf609f0c2f0205fca83a0abe79dc2385b30782 Author: devozerov Date: 2018-12-20T05:26:07Z Table model class. commit 608ae1b6f75cae8ed8402c6e0c1755d3b3abf573 Author: devozerov Date: 2018-12-20T06:03:04Z Preparing table model. commit 6e40856de0dd4124b6b6a04395df901ebaa96fba Author: devozerov Date: 2018-12-20T09:06:46Z WIP. commit 04a5f5eaabda51ba53f6495090709a945b532a33 Author: devozerov Date: 2018-12-20T09:08:26Z WIP. commit 276b4afd153307a7940ef4947fd7eb0aa2ed1914 Author: devozerov Date: 2018-12-20T16:31:37Z Recursive disjunction. commit 0172b894dd6e16b66fce1ea74149a4b4a35b57e5 Author: devozerov Date: 2018-12-20T16:36:37Z Pass table model recursively. commit 7a4ce2b9b21c6fafd40eac1805ee39cca8f3d5b3 Author: devozerov Date: 2018-12-20T16:44:52Z Add join conditions to the model. commit 24ea3232c44cf6f733fd8e9574203028b0400c32 Author: devozerov Date: 2018-12-20T17:47:40Z Added join groups to nodes. commit 9f489363aad5118bdcc53cbae924fba27f300139 Author: devozerov Date: 2018-12-20T17:50:03Z Minors. commit c5b7a5c8ee2ec7c637e9d929f70e07c260f70c72 Author: devozerov Date: 2018-12-20T18:02:28Z Group processing. commit 3571bdb03f4492f762f32fd26298976f4f2b8a89 Author: devozerov Date: 2018-12-20T18:10:43Z Removed table descriptor. commit afff3fdfdf95687f243d3984a3d0df85906b2350 Author: devozerov Date: 2018-12-20T18:11:34Z Removing unnecessary code. commit bb2287dd5a0c4e0adbd1838470759572015a6e57 Author: devozerov Date: 2018-12-20T18:14:06Z Removing unnecessary code (PartitionResult). > SQL: Extract partition info from JOINs > -- > > Key: IGNITE-10307 > URL: https://issues.apache.org/jira/browse/IGNITE-10307 > Project: Ignite >
[jira] [Commented] (IGNITE-8911) While cache is restarting it's possible to start new cache with this name
[
https://issues.apache.org/jira/browse/IGNITE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730678#comment-16730678
]
Ignite TC Bot commented on IGNITE-8911:
---
{panel:title=--> Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2656351&buildTypeId=IgniteTests24Java8_RunAll]
> While cache is restarting it's possible to start new cache with this name
> -
>
> Key: IGNITE-8911
> URL: https://issues.apache.org/jira/browse/IGNITE-8911
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.8
>
>
> We have the state "restarting" for caches when we certainly now that these
> caches would start at some moment in future. But we could start new cache
> with the same name.
> Plus, NPE is throwing when we try to get proxy for such caches (in
> "restarting" state).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10851) Improve WalCompactionSwitchOnTest to rely on rollOver() instead of hardcoded values.
[ https://issues.apache.org/jira/browse/IGNITE-10851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-10851: Description: WalCompactionSwitchOnTest expects hardcoded number of segments after load. This is flaky approach, we need to calculate expected size using WAL rollOver() and archive compressed events. > Improve WalCompactionSwitchOnTest to rely on rollOver() instead of hardcoded > values. > > > Key: IGNITE-10851 > URL: https://issues.apache.org/jira/browse/IGNITE-10851 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Priority: Major > > WalCompactionSwitchOnTest expects hardcoded number of segments after load. > This is flaky approach, we need to calculate expected size using WAL > rollOver() and archive compressed events. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10851) Improve WalCompactionSwitchOnTest to rely on rollOver() instead of hardcoded values.
Pavel Voronkin created IGNITE-10851: --- Summary: Improve WalCompactionSwitchOnTest to rely on rollOver() instead of hardcoded values. Key: IGNITE-10851 URL: https://issues.apache.org/jira/browse/IGNITE-10851 Project: Ignite Issue Type: Improvement Reporter: Pavel Voronkin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-2) Need to implement Queries using QueryPredicate API
[ https://issues.apache.org/jira/browse/IGNITE-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730671#comment-16730671 ] ASF GitHub Bot commented on IGNITE-2: - GitHub user dmekhanikov opened a pull request: https://github.com/apache/ignite/pull/5773 IGNITE-2.4.14.b1 Created for testing. **Do not merge!** You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-2.4.14.b1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5773.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 #5773 commit 8b21e0b36d7d035ff52bcff067f002140f4b8b97 Author: Alexey Kuznetsov Date: 2018-03-23T10:53:15Z IGNITE-7119 Web Agent: Implemented support for comma-separated list of node URIs. (cherry picked from commit ee0f4c0) commit a9f63143059fc489342cadc0c89d7d8fd389fdff Author: Denis Mekhanikov Date: 2018-04-20T14:11:36Z ignite-8205 Clear list of local services in GridServiceProcessor#onKernalStop Signed-off-by: Andrey Gura (cherry picked from commit fbe24f8e3b0d9016a69670ca2bc50766865adf38) commit 2aa4d60df18e57f28814675cf37298ba952035b7 Author: Denis Mekhanikov Date: 2018-04-20T15:41:06Z IGNITE-8134 Subscribe to system cache events on nodes outside BLT Signed-off-by: Andrey Gura (cherry picked from commit c82277eb4e48f95dfec8cb0206c019820a765432) commit ef140ce1102c37295fe9c52d4fcc52b7bdd2bb09 Author: Alexey Kuznetsov Date: 2018-04-23T08:44:09Z IGNITE-8298 Web Console: Fixed tables UI issues. commit 561950f4afc37a078eefc54664f56bdff6d2dcfd Author: Anton Kurbanov Date: 2018-04-21T18:23:21Z IGNITE-8154 - Add an ability to provide ExceptionListener to JmsStreamer - Fixes #3828 Signed-off-by: Valentin Kulichenko commit 1dbd6970fd2ce611c0cbbfa9256b08a934fc8666 Author: Anton Kurbanov Date: 2018-04-23T09:24:50Z Merge branch 'ignite-2.4-master' of https://github.com/gridgain/apache-ignite into ignite-2.4-master commit cafbff336761c5464cb60b68b0f7193d5c998d9f Author: Andrey V. Mashenkov Date: 2018-04-16T17:43:36Z IGNITE-7972 Fixed NPE in TTL manager on unwindEvicts. - Fixes #3810. Signed-off-by: dpavlov (cherry picked from commit 737933e) commit 16fa0132be0cce8e2af2566fd7ad06a741b5fee0 Author: Andrey V. Mashenkov Date: 2018-02-07T15:25:25Z IGNITE-7508: Fix contention on system property access in GridKernalContextImpl::isDaemon(). This closes #3468. (cherry picked from commit d2b41a0) commit 996e3f5b39746777eecad73bc303838fe76121c2 Author: tledkov-gridgain Date: 2018-04-23T15:20:21Z IGNITE-8355 Fixed NPE on concurrent nodes start - Fixes #3899. Signed-off-by: Alexey Goncharuk (cherry picked from commit 5a981c9) commit b9bcc8d6bbcbe3d78e171d55ebedb14d21b28c26 Author: tledkov-gridgain Date: 2018-04-23T15:20:21Z IGNITE-8355 Fixed NPE on concurrent nodes start - Fixes #3899. Signed-off-by: Alexey Goncharuk (cherry picked from commit 5a981c9) commit d253282c6c1976f2279b2a7b4e887fbd46ef3e3a Author: Alexey Goncharuk Date: 2018-04-23T16:39:01Z IGNITE-6083 Null value may be passed to the entry processor on existing key commit d85c922f6c3bd11f3bd192af6ac5ce10d14534c5 Author: Ivan Daschinskiy Date: 2018-04-23T17:37:09Z IGNITE-7786 Added ping timeout and ping interval to control.sh Signed-off-by: Andrey Gura (cherry picked from commit eadc591) commit 2d268ce0c24e7e10cf8e6f41757496129e3aa0d3 Author: Stanislav Lukyanov Date: 2018-04-24T13:29:04Z Merge branch 'ignite-2.4.4' into ignite-2.4-master # Conflicts: # modules/core/src/test/java/org/apache/ignite/util/GridCommandHandlerTest.java commit 568c8718fd3f02392936bbd35b2730996942ad56 Author: Pavel Kovalenko Date: 2018-04-24T16:06:37Z IGNITE-8313 Add trace logs on exchange phases and affinity calculation. - Fixes #3881. Signed-off-by: dpavlov (cherry picked from commit f4646e44fe347711801ba48f318b00337a8a2780) commit 92d10bc9eb58f3018f5d095c17a4ffb8f5201d19 Author: Andrey V. Mashenkov Date: 2017-12-18T15:06:44Z Sanity test suite added. (cherry picked from commit 57202b7) commit 053fc7cdebdc62b735bffb7e294d2d89e04bfe94 Author: Igor Sapego Date: 2018-04-26T16:36:25Z IGNITE-8394: ODBC: Fixed async establishing of SSL connection (cherry picked from commit 1840f75) commit c1251849e2423056eac330749536401894f0b594 Author: Alexey Goncharuk Date: 2018-04-26T16:38:03Z IGNITE-8404 Fixed NPE in MappedFileMemoryProvider commit f9c7f02404e68fa92815e00869908dceca0e1938 Author: Evgeny Stanilovskiy Date: 2018-04-17T15:03:13Z GG-13718: Error
[jira] [Commented] (IGNITE-5438) JDBC thin: support query timeout
[ https://issues.apache.org/jira/browse/IGNITE-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730664#comment-16730664 ] ASF GitHub Bot commented on IGNITE-5438: GitHub user sanpwc opened a pull request: https://github.com/apache/ignite/pull/5772 IGNITE-5438 JDBC thin: support query timeout implemented. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-5438 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5772.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 #5772 commit 25c6a1d742ec7ed8bd87e828479069be45ec1bf7 Author: sanpwc Date: 2018-11-12T08:31:10Z IGNITE-5439: Initial implementation. commit 359d2c9b60730b4a9c6cc9e053d022e1f36548d9 Author: alapin Date: 2018-11-12T09:59:01Z Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite into ignite-5439 commit 423a1b2d2143fe82dd6a0c07b8541bc2a42a1c4b Author: sanpwc Date: 2018-11-13T11:07:13Z IGNITE-5439: Work in progress; commit 99dc0798d1b8a55b402e9dcd248c35320cfa3ee6 Author: sanpwc Date: 2018-11-15T15:12:06Z IGNITE-5439: Request Id addedboth to JdbcRequest and JdbcResponse, cancellation thread-safety added, minor changes; commit a2e3a010df6fad1ce2902a4c641911d44ffe2b32 Author: alapin Date: 2018-11-15T15:13:45Z Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite into ignite-5439 commit 6d12f3648aa3a7254ec42be40e9a965cc9ed9bf4 Author: sanpwc Date: 2018-11-16T12:03:12Z IGNITE-5439: Support for canceling file uploads added, few more tests added; commit 67f5f91b1f5e650943edf6c0e1e2efe7db020305 Author: alapin Date: 2018-11-16T12:04:01Z Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite into ignite-5439 commit fb7f3c7db2a04b9c89f212b3ae9e8d865404fd91 Author: sanpwc Date: 2018-11-16T12:52:22Z IGNITE-5439: bug in tests fixed; commit cfb918d672824cced7a852cb6e164e2a17ce8860 Author: sanpwc Date: 2018-11-16T12:53:15Z IGNITE-5439: warning suppresed in tests; commit 440795fa04143e35c7b09c04e2fa2fcbc9406969 Author: sanpwc Date: 2018-11-16T14:25:40Z IGNITE-5439: more tests added: multistatement and batch canceling; commit 95966c89f25d790d3b4241efce4972a630cd18fd Author: sanpwc Date: 2018-11-19T10:59:21Z IGNITE-5439: Issues fixed after review; commit 4c1ecfd0261f0a779e8aade6dd8ea5433ff570d1 Author: tledkov Date: 2018-11-19T11:15:58Z IGNITE-5439: minors commit b592040147d803d8b7acdd6534e104efc7cfe3e4 Author: tledkov Date: 2018-11-19T12:20:28Z IGNITE-5439: minors commit c7cf72c5540493f0510fa6f06ddfa6efe056a95f Author: alapin Date: 2018-11-19T13:37:06Z Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite into ignite-5439 commit ec7f979034f22498849d4f94608f3fb84686a0cd Author: alapin Date: 2018-11-19T13:42:25Z Merge branch 'ignite-5439' of https://github.com/gridgain/apache-ignite into ignite-5439 commit 33d396007c350057c6c8c9f0cb53167ffdfb6cb7 Author: sanpwc Date: 2018-11-19T13:45:20Z IGNITE-5439: Error handling, logging and security handling added within GridNioPriorityQueryFilter; commit 3ae5b07f161401607a7c71f9da02394c2e85cb30 Author: sanpwc Date: 2018-11-19T14:12:13Z IGNITE-5439: Error handling within JdbcRequestHandler#cancelQuery added; commit cdb7ab9ccc65fb2929cba1fc49de086852410d53 Author: sanpwc Date: 2018-11-19T15:00:54Z IGNITE-5439: More methods of JdbcThinStatement now throws SQLException(Query was cancelled). commit ac7635d25421bf0d7bb0d6cf85f6c1342a0ad6b6 Author: sanpwc Date: 2018-11-19T15:50:15Z IGNITE-5439: RequestToCursorsMapping cleanup implemented. commit 7615488361c13db65675ea7e06abb759d4ec46ad Author: sanpwc Date: 2018-11-19T16:07:56Z IGNITE-5439: ensureAlive() restored in several cases; commit 6254a5f91569066f902dc20e9d0c86c60709998a Author: sanpwc Date: 2018-11-20T08:55:33Z IGNITE-5439: synchronizedToCAS optimizations; commit c3e4115a4b9f47759440640820f63ba09f61a31d Author: alapin Date: 2018-11-20T08:56:13Z Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite into ignite-5439 commit 91df0d6505b59220e7293bc95b3b5e30575be040 Author: sanpwc Date: 2018-11-20T10:06:32Z IGNITE-5439: failing testExpectSQLExceptionAndAFAPControlRetrievalAfterCancelingLongRunningFileUpload because of IGNITE-10340s; commit 4dfcf5713e70a417ad44e67231bfc2bd44514202 Author: tledkov Date: 2018-11-20T14:00:10Z Merge branch '_master' into ignite-5439 commit c8d956274453e451b39642765559a64a141fb1a9 Author: sanpwc Date: 2018-11-20T14:51:29Z IGNITE-5439: changes based on review; commit 8e13019c1e01539c0dfa
[jira] [Commented] (IGNITE-10784) SQL: Create a view with list of existing tables
[
https://issues.apache.org/jira/browse/IGNITE-10784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730659#comment-16730659
]
Ignite TC Bot commented on IGNITE-10784:
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 7{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2676528]]
* IgniteCacheTestSuite7:
TxRollbackAsyncWithPersistenceTest.testSynchronousRollback - 0,0% fails in last
406 master runs.
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2676560&buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Create a view with list of existing tables
> ---
>
> Key: IGNITE-10784
> URL: https://issues.apache.org/jira/browse/IGNITE-10784
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> We need to create a system view of currently available SQL tables.
> Minimal required information:
> 1) Schema name
> 2) Table name
> 3) Owning cache name
> 4) Owning cache ID
> Other info to consider:
> 1) Affinity column name
> 2) Key/value aliases
> 3) Key/value type names
> 4) Analyse other vendors (e.g. MySQL, Postgresql) and see if any other useful
> information could be exposed (taking in count that a lot of engine properties
> are already exposed through {{CACHES}} view)
> Starting point: {{SqlSystemView}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10808) Discovery message queue may build up with TcpDiscoveryMetricsUpdateMessage
[ https://issues.apache.org/jira/browse/IGNITE-10808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730647#comment-16730647 ] ASF GitHub Bot commented on IGNITE-10808: - GitHub user dmekhanikov opened a pull request: https://github.com/apache/ignite/pull/5771 IGNITE-10808 Ensure RingMessageWorker's progress. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10808 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5771.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 #5771 commit 8ccbec84568dc4058ea27dbfbbab0fa2e34477d9 Author: Denis Mekhanikov Date: 2018-12-26T15:37:45Z IGNITE-10808 Add a metrics overflow test. commit b4ee4478f5e9819957ca52b962af42ab3d17452a Author: Denis Mekhanikov Date: 2018-12-28T16:03:20Z IGNITE-10808 Drop stale TcpDiscoveryMetricsUpdateMessage upon arrival of fresh ones. commit 1faec4bc05834dbe1ed7eaf2b5a3265ad503c385 Author: Denis Mekhanikov Date: 2018-12-29T10:39:05Z IGNITE-10808 Modify test. commit 632dad49954247e1e16f6781a0be88b7e075c399 Author: Denis Mekhanikov Date: 2018-12-29T11:26:52Z IGNITE-10808 Track RingMessageWorker's progress. > Discovery message queue may build up with TcpDiscoveryMetricsUpdateMessage > -- > > Key: IGNITE-10808 > URL: https://issues.apache.org/jira/browse/IGNITE-10808 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Stanislav Lukyanov >Assignee: Denis Mekhanikov >Priority: Major > Labels: discovery > Fix For: 2.8 > > Attachments: IgniteMetricsOverflowTest.java > > > A node receives a new metrics update message every `metricsUpdateFrequency` > milliseconds, and the message will be put at the top of the queue (because it > is a high priority message). > If processing one message takes more than `metricsUpdateFrequency` then > multiple `TcpDiscoveryMetricsUpdateMessage` will be in the queue. A long > enough delay (e.g. caused by a network glitch or GC) may lead to the queue > building up tens of metrics update messages which are essentially useless to > be processed. Finally, if processing a message on average takes a little more > than `metricsUpdateFrequency` (even for a relatively short period of time, > say, for a minute due to network issues) then the message worker will end up > processing only the metrics updates and the cluster will essentially hang. > Reproducer is attached. In the test, the queue first builds up and then very > slowly being teared down, causing "Failed to wait for PME" messages. > Need to change ServerImpl's SocketReader not to put another metrics update > message to the top of the queue if it already has one (or replace the one at > the top with new one). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9845) Web Console: Add support of two way ssl authentication in Web Console agent
[
https://issues.apache.org/jira/browse/IGNITE-9845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730650#comment-16730650
]
Alexey Kuznetsov commented on IGNITE-9845:
--
Fixed NPE.
> Web Console: Add support of two way ssl authentication in Web Console agent
> ---
>
> Key: IGNITE-9845
> URL: https://issues.apache.org/jira/browse/IGNITE-9845
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Affects Versions: 2.6
>Reporter: Andrey Novikov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Attachments: Selection_274.png, generate.bat, generate.sh, ssl.pdf
>
>
> RestExecutor should not be shared between different users requests in case of
> two way ssl authentication:
> * For each token with ssl we need create separated RestExecutor and set up
> socketFactory and trustManager.
> * RestExecutor should be removed if token expired.
> Add program arguments for passing client certificate, client password, trust
> store, trust store password for ignite node connection and web console
> backend.
> Example on okhttp:
> [https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java]
> Upgrade socket-io from 1.x to 2.x.
> Add support for SSL cipher suites
> Add tests.
> ---
> *How to do local testing:*
> On Windows
> # Download Open SSL: Download Open SSL for Windows from
> [https://wiki.openssl.org/index.php/Binaries]
> # Unpack it.
> On Linux - it is usually built-in.
> Generate keys with provided script (see attached generate.bat, it could be
> easily adapted for Linux).
>
> Add to etc/hosts:
> 127.0.0.1 localhost console.test.local
>
> After that configure SSL for:
> # Web Console back-end.
> # Web Agent.
> # Cluster.
> *Configure Web Console back-end settings:*
> "ssl": true,
> "key": "some_path/server.key",
> "cert": "some_path/server.crt",
> "ca": "some_path/ca.crt",
> "keyPassphrase": "p123456",
> *Configure Web Agent parameters (see parameters descriptions):*
> -t your_token
> -s [https://console.test.local:3000|https://console.test.local:3000/] -n
> [https://console.test.local:11443|https://console.test.local:11443/]
> -nks client.jks -nkp p123456
> -nts ca.jks -ntp p123456
> -sks client.jks -skp p123456
> -sts ca.jks -stp p123456
> *Configure cluster JETTY config:*
>
> https
> default="11443"/>
> true
> true
> class="org.eclipse.jetty.server.SecureRequestCustomizer"/>
>
> class="org.eclipse.jetty.util.ssl.SslContextFactory">
> some_path/server.jks
> p123456
> some_path/ca.jks
> p123456
> true
>
> *How to start secure web console in direct install edition in Ubuntu:*
> # Download ignite web console direct install for linux ZIP archive .
> # Unpack downloaded archive to goal folder.
> # Generate SSL certificates.
> # Copy generated certificates to folder with unpacked web console direct
> install.
> # Open terminal and navigate to folder with unpacked web console direct
> install.
> # Run web console with the next command:
> {code:java}
> ignite-web-console-linux --server:port 11443 --server:ssl true
> --server:requestCert true --server:key "server.key" --server:cert
> "server.crt" --server:ca "ca.crt" --server:passphrase "p123456"{code}
> 7. Import client.p12 certificate into your browser. See attached
> screenstot in Chrome browser.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10847) Web console: failed to download the mongodb on Ubuntu 18.04
[
https://issues.apache.org/jira/browse/IGNITE-10847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730643#comment-16730643
]
Andrey Novikov commented on IGNITE-10847:
-
For ubuntu 18.04 only mongo 4.x was released
([https://www.mongodb.org/dl/linux/x86_64)] This can be fixed in the following
ways:
# Don't support ubuntu 18.04
# Migrate to mongo 4.x
# Copy and rename ubuntu 16.04 distributive to ubuntu 18.04
I prefer 1 or 3.
> Web console: failed to download the mongodb on Ubuntu 18.04
> ---
>
> Key: IGNITE-10847
> URL: https://issues.apache.org/jira/browse/IGNITE-10847
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Konstantinov
>Priority: Major
>
> I tried to run 'web console direct install' and faced with an error
> downloading of MongoDB due to there is no corresponding version for that OS.
> {code}
> name: 'StatusCodeError',
> statusCode: 403,
> message: '403 - " encoding=\\"UTF-8\\"?>\\nAccessDeniedAccess
> Denied4B7715F9CDA5127BzuhNAWP7FGOgDLjkNJ3y71iU+wxcWKR5F5kI4LoO1SqCdt+aPeLZXnJko5S0ji2zx5zkJaCZX3g="',
> error: ' encoding="UTF-8"?>\nAccessDeniedAccess
> Denied4B7715F9CDA5127BzuhNAWP7FGOgDLjkNJ3y71iU+wxcWKR5F5kI4LoO1SqCdt+aPeLZXnJko5S0ji2zx5zkJaCZX3g=',
> options:
>{ uri:
> 'https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-ubuntu1804-3.4.7.tgz.md5',
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10850) Clarify the use of the enforceJoin flag
Artem Budnikov created IGNITE-10850: --- Summary: Clarify the use of the enforceJoin flag Key: IGNITE-10850 URL: https://issues.apache.org/jira/browse/IGNITE-10850 Project: Ignite Issue Type: Task Components: documentation Reporter: Artem Budnikov Assignee: Artem Budnikov Fix For: 2.8 Need to clarify the use of the enforceJoin flag and how it can be used to optimize queries. Add this information to [https://apacheignite-sql.readme.io/docs/performance-and-debugging] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10850) Clarify the use of the enforceJoinOrder flag
[ https://issues.apache.org/jira/browse/IGNITE-10850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov updated IGNITE-10850: Description: Need to clarify the use of the enforceJoinOrder flag and how it can be used to optimize queries. Add this information to [https://apacheignite-sql.readme.io/docs/performance-and-debugging] was: Need to clarify the use of the enforceJoin flag and how it can be used to optimize queries. Add this information to [https://apacheignite-sql.readme.io/docs/performance-and-debugging] > Clarify the use of the enforceJoinOrder flag > - > > Key: IGNITE-10850 > URL: https://issues.apache.org/jira/browse/IGNITE-10850 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Artem Budnikov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.8 > > > Need to clarify the use of the enforceJoinOrder flag and how it can be used > to optimize queries. Add this information to > [https://apacheignite-sql.readme.io/docs/performance-and-debugging] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10850) Clarify the use of the enforceJoinOrder flag
[ https://issues.apache.org/jira/browse/IGNITE-10850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov updated IGNITE-10850: Summary: Clarify the use of the enforceJoinOrder flag (was: Clarify the use of the enforceJoin flag ) > Clarify the use of the enforceJoinOrder flag > - > > Key: IGNITE-10850 > URL: https://issues.apache.org/jira/browse/IGNITE-10850 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Artem Budnikov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.8 > > > Need to clarify the use of the enforceJoin flag and how it can be used to > optimize queries. Add this information to > [https://apacheignite-sql.readme.io/docs/performance-and-debugging] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10763) MVCC: Transaction already completed error in some tests
[
https://issues.apache.org/jira/browse/IGNITE-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730630#comment-16730630
]
ASF GitHub Bot commented on IGNITE-10763:
-
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5770
IGNITE-10763: Call tm().resetContext() after each DML and SFU operation
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10763
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5770.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 #5770
commit 93f9d21ab2b38eb1b720711e68236b23e1185ad5
Author: ipavlukhin
Date: 2018-12-27T08:36:22Z
some cosmetics related checking if MVCC tx is active
commit ac86097ece9235ef3f0342bc3576afd0ce2ab859
Author: ipavlukhin
Date: 2018-12-29T10:07:44Z
call tm().resetContext() after each DML and SFU operation
> MVCC: Transaction already completed error in some tests
> ---
>
> Key: IGNITE-10763
> URL: https://issues.apache.org/jira/browse/IGNITE-10763
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain, mvcc_stabilization_stage_1,
> transactions
> Fix For: 2.8
>
>
> "Transaction is already completed" error occurs time to time in some tests.
> Reproducer:
> {{CacheMvccReplicatedSqlTxQueriesTest.testReplicatedAndPartitionedUpdateSingleTransaction}}
> {{CacheMvccPartitionedSqlTxQueriesWithReducerTest.testQueryReducerDeadlockInsertWithTxTimeout}}
>
> {noformat}
> class org.apache.ignite.internal.processors.query.IgniteSQLException:
> Transaction is already completed.
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.checkActive(MvccUtils.java:660)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:832)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:813)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:796)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.runQueryTwoStep(IgniteH2Indexing.java:1131)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunDistributedQuery(IgniteH2Indexing.java:1990)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1636)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1526)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2167)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2162)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2670)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2176)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2196)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2157)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2118)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2091)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccReplicatedSqlTxQueriesTest.runSql(CacheMvccReplicatedSqlTxQueriesTest.java:234)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccReplicatedSqlTxQueriesTest.testReplicatedAndPartitionedUpdateSingleTransaction(CacheMvccReplicatedSqlTxQueriesTest.java:202)
> 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
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>
[jira] [Commented] (IGNITE-10784) SQL: Create a view with list of existing tables
[
https://issues.apache.org/jira/browse/IGNITE-10784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730616#comment-16730616
]
Pavel Kuznetsov commented on IGNITE-10784:
--
I think It's done, [~tledkov-gridgain] would you please do a review?
> SQL: Create a view with list of existing tables
> ---
>
> Key: IGNITE-10784
> URL: https://issues.apache.org/jira/browse/IGNITE-10784
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> We need to create a system view of currently available SQL tables.
> Minimal required information:
> 1) Schema name
> 2) Table name
> 3) Owning cache name
> 4) Owning cache ID
> Other info to consider:
> 1) Affinity column name
> 2) Key/value aliases
> 3) Key/value type names
> 4) Analyse other vendors (e.g. MySQL, Postgresql) and see if any other useful
> information could be exposed (taking in count that a lot of engine properties
> are already exposed through {{CACHES}} view)
> Starting point: {{SqlSystemView}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8558) Provide an opportunity to stop grids and cancel tasks after execution all tests
[
https://issues.apache.org/jira/browse/IGNITE-8558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730613#comment-16730613
]
Rodion commented on IGNITE-8558:
I changed flag stopAllGrids(false) on true in teardown(), because it does'n
influence on tests result. And I deleted all usage of stopAllGrids(true) in
afterTestsStopped(), because it duplicates code.
> Provide an opportunity to stop grids and cancel tasks after execution all
> tests
> ---
>
> Key: IGNITE-8558
> URL: https://issues.apache.org/jira/browse/IGNITE-8558
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.6
>Reporter: Maxim Muzafarov
>Assignee: Rodion
>Priority: Minor
> Fix For: 2.8
>
>
> The -IGNITE-6842- issue provides an ability gracefully shutdown all ignite
> instances by default after execution of tests. Ignite instances are stopped
> by calling the method - {{stopAllGrids}} ({{cancel = false}} is used). You
> can refer to these lines of code for the details of how the node stopped:
> {code:java|title=GridAbstractTest.java:1789}
> if (isSafeTopology()) {
> stopAllGrids(false);
> if (stopGridErr) {
> err = new RuntimeException("Not all Ignite instances has been
> stopped. " +
> "Please, see log for details.", err);
> }
> }
> {code}
> As part of IGNITE-8266 a lot of boilerplate code have been successfully
> removed. For instance,
> {code:java}
> /** {@inheritDoc} */
> @Override protected void afterTestsStopped() throws Exception {
> super.afterTestsStopped();
> stopAllGrids();
> }
> {code}
> We need to,
> * Provide the ability to override the behaviour of gracefully instance
> shutdown and use {{stopAllGirds(true)}} after all tests execution. Assume a
> new method would be introduced like {{GridAbstractTest#isSafeTopology}}, so
> the behaviour can be overridden in subclasses.
> * Remove the other boilerplate parts of the code. For instance,
> {code:java}
> /** {@inheritDoc} */
> @Override protected void afterTestsStopped() throws Exception {
> stopAllGrids(true);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10849) [ML] Prepare a benchmark to compare Ignite ML and Spark MLeap inference performance
[ https://issues.apache.org/jira/browse/IGNITE-10849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Dmitriev updated IGNITE-10849: Priority: Minor (was: Major) > [ML] Prepare a benchmark to compare Ignite ML and Spark MLeap inference > performance > --- > > Key: IGNITE-10849 > URL: https://issues.apache.org/jira/browse/IGNITE-10849 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Anton Dmitriev >Priority: Minor > Fix For: 2.8 > > > In IGNITE-10810 we have added functionality that allows to import Spark > models saved using MLeap. Some of these models we already have in Ignite ML. > The goal of this task is to compare inference performance of Ignite ML and > Spark MLeap models in our environment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10849) [ML] Prepare a benchmark to compare Ignite ML and Spark MLeap inference performance
[ https://issues.apache.org/jira/browse/IGNITE-10849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Dmitriev updated IGNITE-10849: Description: In IGNITE-10810 we have added functionality that allows to import Spark models saved using MLeap. Some of these models we already have in Ignite ML. The goal of this task is to compare inference performance of Ignite ML and Spark MLeap models in our environment. > [ML] Prepare a benchmark to compare Ignite ML and Spark MLeap inference > performance > --- > > Key: IGNITE-10849 > URL: https://issues.apache.org/jira/browse/IGNITE-10849 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Anton Dmitriev >Priority: Major > Fix For: 2.8 > > > In IGNITE-10810 we have added functionality that allows to import Spark > models saved using MLeap. Some of these models we already have in Ignite ML. > The goal of this task is to compare inference performance of Ignite ML and > Spark MLeap models in our environment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10849) [ML] Prepare a benchmark to compare Ignite ML and Spark MLeap inference performance
Anton Dmitriev created IGNITE-10849: --- Summary: [ML] Prepare a benchmark to compare Ignite ML and Spark MLeap inference performance Key: IGNITE-10849 URL: https://issues.apache.org/jira/browse/IGNITE-10849 Project: Ignite Issue Type: Improvement Components: ml Affects Versions: 2.8 Reporter: Anton Dmitriev Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8558) Provide an opportunity to stop grids and cancel tasks after execution all tests
[
https://issues.apache.org/jira/browse/IGNITE-8558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730604#comment-16730604
]
Rodion commented on IGNITE-8558:
Maxim, could you review, plz?
> Provide an opportunity to stop grids and cancel tasks after execution all
> tests
> ---
>
> Key: IGNITE-8558
> URL: https://issues.apache.org/jira/browse/IGNITE-8558
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.6
>Reporter: Maxim Muzafarov
>Assignee: Rodion
>Priority: Minor
> Fix For: 2.8
>
>
> The -IGNITE-6842- issue provides an ability gracefully shutdown all ignite
> instances by default after execution of tests. Ignite instances are stopped
> by calling the method - {{stopAllGrids}} ({{cancel = false}} is used). You
> can refer to these lines of code for the details of how the node stopped:
> {code:java|title=GridAbstractTest.java:1789}
> if (isSafeTopology()) {
> stopAllGrids(false);
> if (stopGridErr) {
> err = new RuntimeException("Not all Ignite instances has been
> stopped. " +
> "Please, see log for details.", err);
> }
> }
> {code}
> As part of IGNITE-8266 a lot of boilerplate code have been successfully
> removed. For instance,
> {code:java}
> /** {@inheritDoc} */
> @Override protected void afterTestsStopped() throws Exception {
> super.afterTestsStopped();
> stopAllGrids();
> }
> {code}
> We need to,
> * Provide the ability to override the behaviour of gracefully instance
> shutdown and use {{stopAllGirds(true)}} after all tests execution. Assume a
> new method would be introduced like {{GridAbstractTest#isSafeTopology}}, so
> the behaviour can be overridden in subclasses.
> * Remove the other boilerplate parts of the code. For instance,
> {code:java}
> /** {@inheritDoc} */
> @Override protected void afterTestsStopped() throws Exception {
> stopAllGrids(true);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-10820) Clean up static Ignite instances in tests
[ https://issues.apache.org/jira/browse/IGNITE-10820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk resolved IGNITE-10820. --- Resolution: Fixed > Clean up static Ignite instances in tests > - > > Key: IGNITE-10820 > URL: https://issues.apache.org/jira/browse/IGNITE-10820 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.8 > > > From the recent TC OOME it can be seen that some tests contain static Ignite > instances that are not cleaned up on test end, which leads to memory leak. As > a first phase, we need to nullify them. Ultimately, we need to get rid of > static fields in tests after migration to JUnit5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10820) Clean up static Ignite instances in tests
[ https://issues.apache.org/jira/browse/IGNITE-10820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730599#comment-16730599 ] ASF GitHub Bot commented on IGNITE-10820: - Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5752 > Clean up static Ignite instances in tests > - > > Key: IGNITE-10820 > URL: https://issues.apache.org/jira/browse/IGNITE-10820 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.8 > > > From the recent TC OOME it can be seen that some tests contain static Ignite > instances that are not cleaned up on test end, which leads to memory leak. As > a first phase, we need to nullify them. Ultimately, we need to get rid of > static fields in tests after migration to JUnit5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10820) Clean up static Ignite instances in tests
[ https://issues.apache.org/jira/browse/IGNITE-10820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730598#comment-16730598 ] Alexey Goncharuk commented on IGNITE-10820: --- Merged to master. > Clean up static Ignite instances in tests > - > > Key: IGNITE-10820 > URL: https://issues.apache.org/jira/browse/IGNITE-10820 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.8 > > > From the recent TC OOME it can be seen that some tests contain static Ignite > instances that are not cleaned up on test end, which leads to memory leak. As > a first phase, we need to nullify them. Ultimately, we need to get rid of > static fields in tests after migration to JUnit5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10791) Avoid unusable network during discovery
[ https://issues.apache.org/jira/browse/IGNITE-10791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730593#comment-16730593 ] Tran Ly Vu edited comment on IGNITE-10791 at 12/29/18 8:15 AM: --- Hi, I would like to work on this issue, thanks ,[~syssoftsol] @[~slukyanov] please help to assign to me was (Author: tranlyvu): Hi, I would like to work on this issue, thanks ,[~syssoftsol] > Avoid unusable network during discovery > - > > Key: IGNITE-10791 > URL: https://issues.apache.org/jira/browse/IGNITE-10791 > Project: Ignite > Issue Type: Improvement >Reporter: David Harvey >Priority: Major > Labels: newbie > > Problem: In some deployments, there are multiple IP addresses, and S3 > discovery tries them in some random order, and times out on the ones that > don't work, slowing down discovery unnecessarily. In many such cases, the > set of unusable address is known by humans, but is not discoverable at > runtime. For example, some IP addresses may be blocked by firewalls. On > ECS, the docker bridge network IPs are visible, but are unusable across nodes. > The node pushing IPs to S3 does not have the enough info to decide which of > its address is valid. > > [http://apache-ignite-users.70518.x6.nabble.com/Avoiding-Docker-Bridge-network-when-using-S3-discovery-td24778.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10791) Avoid unusable network during discovery
[ https://issues.apache.org/jira/browse/IGNITE-10791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730593#comment-16730593 ] Tran Ly Vu edited comment on IGNITE-10791 at 12/29/18 8:14 AM: --- Hi, I would like to work on this issue, thanks ,[~syssoftsol] was (Author: tranlyvu): Hi, I would like to work on this issue, thanks > Avoid unusable network during discovery > - > > Key: IGNITE-10791 > URL: https://issues.apache.org/jira/browse/IGNITE-10791 > Project: Ignite > Issue Type: Improvement >Reporter: David Harvey >Priority: Major > Labels: newbie > > Problem: In some deployments, there are multiple IP addresses, and S3 > discovery tries them in some random order, and times out on the ones that > don't work, slowing down discovery unnecessarily. In many such cases, the > set of unusable address is known by humans, but is not discoverable at > runtime. For example, some IP addresses may be blocked by firewalls. On > ECS, the docker bridge network IPs are visible, but are unusable across nodes. > The node pushing IPs to S3 does not have the enough info to decide which of > its address is valid. > > [http://apache-ignite-users.70518.x6.nabble.com/Avoiding-Docker-Bridge-network-when-using-S3-discovery-td24778.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10791) Avoid unusable network during discovery
[ https://issues.apache.org/jira/browse/IGNITE-10791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730593#comment-16730593 ] Tran Ly Vu commented on IGNITE-10791: - Hi, I would like to work on this issue, thanks > Avoid unusable network during discovery > - > > Key: IGNITE-10791 > URL: https://issues.apache.org/jira/browse/IGNITE-10791 > Project: Ignite > Issue Type: Improvement >Reporter: David Harvey >Priority: Major > Labels: newbie > > Problem: In some deployments, there are multiple IP addresses, and S3 > discovery tries them in some random order, and times out on the ones that > don't work, slowing down discovery unnecessarily. In many such cases, the > set of unusable address is known by humans, but is not discoverable at > runtime. For example, some IP addresses may be blocked by firewalls. On > ECS, the docker bridge network IPs are visible, but are unusable across nodes. > The node pushing IPs to S3 does not have the enough info to decide which of > its address is valid. > > [http://apache-ignite-users.70518.x6.nabble.com/Avoiding-Docker-Bridge-network-when-using-S3-discovery-td24778.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10848) Add abbitlity to set default log directory by JVM key and set it by default to /var/log in *nix system
ARomantsov created IGNITE-10848: --- Summary: Add abbitlity to set default log directory by JVM key and set it by default to /var/log in *nix system Key: IGNITE-10848 URL: https://issues.apache.org/jira/browse/IGNITE-10848 Project: Ignite Issue Type: Improvement Reporter: ARomantsov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
