[jira] [Updated] (IGNITE-9846) Web console: allow to $inject before function definition
[ https://issues.apache.org/jira/browse/IGNITE-9846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-9846: - Description: The issue: DI $inject property can't be set before function definition because of ESLint rules. This makes code harder to maintain and more error-prone. What to do: Loosen ESLint appropriate rules (probably no-use-before-define). What to test afterwards: Nothing really, the changes are not application code related. was: The issue: DI $inject property can't be set before function definition because of ESLint rules. This makes code harder to maintain and more error-prone. What to do: Loosen ESLint appropriate rules (probably no-use-before-define). > Web console: allow to $inject before function definition > > > Key: IGNITE-9846 > URL: https://issues.apache.org/jira/browse/IGNITE-9846 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Andrey Novikov >Priority: Minor > > The issue: > DI $inject property can't be set before function definition because of > ESLint rules. This makes code harder to maintain and more error-prone. > What to do: > Loosen ESLint appropriate rules (probably no-use-before-define). > What to test afterwards: > Nothing really, the changes are not application code related. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9846) Web console: allow to $inject before function definition
Ilya Borisov created IGNITE-9846: Summary: Web console: allow to $inject before function definition Key: IGNITE-9846 URL: https://issues.apache.org/jira/browse/IGNITE-9846 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Ilya Borisov Assignee: Andrey Novikov The issue: DI $inject property can't be set before function definition because of ESLint rules. This makes code harder to maintain and more error-prone. What to do: Loosen ESLint appropriate rules (probably no-use-before-define). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (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:all-tabpanel ] Andrey Novikov updated IGNITE-9845: --- Fix Version/s: (was: 2.7) 2.8 > 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 >Priority: Major > Fix For: 2.8 > > > 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 metrics collection task in agent. > > Example on okhttp: > https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (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:all-tabpanel ] Andrey Novikov updated IGNITE-9845: --- Description: 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 metrics collection task in agent. Example on okhttp: https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java was: 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 metrics collection task in agent. > 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 >Priority: Major > Fix For: 2.7 > > > 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 metrics collection task in agent. > > Example on okhttp: > https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9845) Web Console: Add support of two way ssl authentication in Web Console agent
Andrey Novikov created IGNITE-9845: -- Summary: 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 Fix For: 2.7 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 metrics collection task in agent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7926) Web console: demo faled to start under java >= 9
[ https://issues.apache.org/jira/browse/IGNITE-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-7926: - Component/s: wizards > Web console: demo faled to start under java >= 9 > > > Key: IGNITE-7926 > URL: https://issues.apache.org/jira/browse/IGNITE-7926 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.4 >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Minor > Fix For: 2.7 > > > We need to add support for Java 9 to web console demo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7926) Web console: demo faled to start under java >= 9
[ https://issues.apache.org/jira/browse/IGNITE-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645892#comment-16645892 ] Alexey Kuznetsov edited comment on IGNITE-7926 at 10/11/18 3:11 AM: Looks good to me. Merged to master & ignite-2.7. Warnings will be fixed in IGNITE-9836. was (Author: kuaw26): Looks good to me. Merged to master. Warnings will be fixed in IGNITE-9836. > Web console: demo faled to start under java >= 9 > > > Key: IGNITE-7926 > URL: https://issues.apache.org/jira/browse/IGNITE-7926 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Minor > Fix For: 2.7 > > > We need to add support for Java 9 to web console demo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7926) Web console: demo faled to start under java >= 9
[ https://issues.apache.org/jira/browse/IGNITE-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-7926: Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) > Web console: demo faled to start under java >= 9 > > > Key: IGNITE-7926 > URL: https://issues.apache.org/jira/browse/IGNITE-7926 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Minor > Fix For: 2.7 > > > We need to add support for Java 9 to web console demo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7926) Web console: demo faled to start under java >= 9
[ https://issues.apache.org/jira/browse/IGNITE-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-7926. -- Resolution: Fixed Looks good to me. Merged to master. Warnings will be fixed in IGNITE-9836. > Web console: demo faled to start under java >= 9 > > > Key: IGNITE-7926 > URL: https://issues.apache.org/jira/browse/IGNITE-7926 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.7 > > > We need to add support for Java 9 to web console demo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7861) Web console: invalid column on Activity details modal
[ https://issues.apache.org/jira/browse/IGNITE-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-7861: - Assignee: Pavel Konstantinov (was: Vasiliy Sisko) > Web console: invalid column on Activity details modal > - > > Key: IGNITE-7861 > URL: https://issues.apache.org/jira/browse/IGNITE-7861 > Project: Ignite > Issue Type: Bug >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > Attachments: Selection_094.png, screenshot-1.png, screenshot-2.png > > > Many items do not have right description -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9796) NPE if you call array() method on empty GridLongList
[
https://issues.apache.org/jira/browse/IGNITE-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645574#comment-16645574
]
Ignite TC Bot commented on IGNITE-9796:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2008494buildTypeId=IgniteTests24Java8_RunAll]
> NPE if you call array() method on empty GridLongList
>
>
> Key: IGNITE-9796
> URL: https://issues.apache.org/jira/browse/IGNITE-9796
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> {code}
> /**
> *
> */
> public void testArray() {
> GridLongList list = new GridLongList();
> long[] array = list.array();
> assertNotNull(array);
> assertEquals(0, array.length);
> }
> {code}
> That is it, current version of GridLongList would cause NPE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9583) PHP thin: php directory should be included in binary release
[
https://issues.apache.org/jira/browse/IGNITE-9583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645475#comment-16645475
]
ASF GitHub Bot commented on IGNITE-9583:
GitHub user vveider opened a pull request:
https://github.com/apache/ignite/pull/4951
IGNITE-9583 PHP thin: php directory should be included in binary release
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9583
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4951.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 #4951
commit d7cb94b0476514394f46b8801fdd5eb3ed1782fe
Author: Peter Ivanov
Date: 2018-10-10T19:56:29Z
IGNITE-9583 PHP thin: php directory should be included in binary release
> PHP thin: php directory should be included in binary release
>
>
> Key: IGNITE-9583
> URL: https://issues.apache.org/jira/browse/IGNITE-9583
> Project: Ignite
> Issue Type: Improvement
> Components: build, thin client
>Reporter: Igor Sapego
>Assignee: Peter Ivanov
>Priority: Blocker
> Labels: php
> Fix For: 2.7
>
>
> Currently, php directory is not generated by the {{maven install}} command.
> Need to add appropriate copy steps to {{assembly/release-fabric-base.xml}}
> file.
> The following components should be copied:
> {noformat}
> ignite/modules/platforms/php/composer.json
> ignite/modules/platforms/php/src
> ignite/modules/platforms/php/examples
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9583) PHP thin: php directory should be included in binary release
[
https://issues.apache.org/jira/browse/IGNITE-9583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645476#comment-16645476
]
Peter Ivanov commented on IGNITE-9583:
--
Done. [~isapego], please review.
> PHP thin: php directory should be included in binary release
>
>
> Key: IGNITE-9583
> URL: https://issues.apache.org/jira/browse/IGNITE-9583
> Project: Ignite
> Issue Type: Improvement
> Components: build, thin client
>Reporter: Igor Sapego
>Assignee: Peter Ivanov
>Priority: Blocker
> Labels: php
> Fix For: 2.7
>
>
> Currently, php directory is not generated by the {{maven install}} command.
> Need to add appropriate copy steps to {{assembly/release-fabric-base.xml}}
> file.
> The following components should be copied:
> {noformat}
> ignite/modules/platforms/php/composer.json
> ignite/modules/platforms/php/src
> ignite/modules/platforms/php/examples
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9833) Update Master Trends metrics: add total run time (duration), number of runs
[ https://issues.apache.org/jira/browse/IGNITE-9833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645416#comment-16645416 ] ASF GitHub Bot commented on IGNITE-9833: zzzadruga opened a new pull request #34: IGNITE-9833 Update Master Trends metrics URL: https://github.com/apache/ignite-teamcity-bot/pull/34 Update Master Trends metrics: add total run time (duration) and number of runs This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Update Master Trends metrics: add total run time (duration), number of runs > --- > > Key: IGNITE-9833 > URL: https://issues.apache.org/jira/browse/IGNITE-9833 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolai Kulagin >Assignee: Nikolai Kulagin >Priority: Minor > > Update [Master Trends|https://mtcga.gridgain.com/comparison.html] metrics on > TC Bot: add total run time (duration) and number of runs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9841) SQL take lost partitions into account when persistence is enabled
[ https://issues.apache.org/jira/browse/IGNITE-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645410#comment-16645410 ] Roman Novichenok commented on IGNITE-9841: -- Note, ScanQuery exhibits the same behavior - returns partial results when some partitions are lost. Not sure if solution would be related or needs to be tracked and fixed under a separate ticket. > SQL take lost partitions into account when persistence is enabled > - > > Key: IGNITE-9841 > URL: https://issues.apache.org/jira/browse/IGNITE-9841 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Stanislav Lukyanov >Priority: Major > Attachments: IgniteSqlQueryWithLostPartitionsTest.java > > > IGNITE-8927 changed SQL queries to honor lost partitions. However, it doesn't > work if persistence is enabled. E.g. if there are lost partitions then > `select * from T` fails for in-memory caches (good) and silently ignores the > lost partitions for persistent caches (bad). > See attached reproducer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9796) NPE if you call array() method on empty GridLongList
[
https://issues.apache.org/jira/browse/IGNITE-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645359#comment-16645359
]
Ignite TC Bot commented on IGNITE-9796:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Hadoop{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2008411]]
* IgniteHadoopFileSystemClientBasedDualAsyncSelfTest.testClientReconnect (last
started)
{color:#d04437}Cache 5{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2008475]]
* IgniteCacheTestSuite5: IgniteCachePartitionLossPolicySelfTest.testReadOnlyAll
- 0,0% fails in last 100 master runs.
{color:#d04437}Data Structures{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2008476]]
* IgniteCacheDataStructuresSelfTestSuite:
IgniteReplicatedSemaphoreSelfTest.testFailover - 0,0% fails in last 100 master
runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2008494buildTypeId=IgniteTests24Java8_RunAll]
> NPE if you call array() method on empty GridLongList
>
>
> Key: IGNITE-9796
> URL: https://issues.apache.org/jira/browse/IGNITE-9796
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> {code}
> /**
> *
> */
> public void testArray() {
> GridLongList list = new GridLongList();
> long[] array = list.array();
> assertNotNull(array);
> assertEquals(0, array.length);
> }
> {code}
> That is it, current version of GridLongList would cause NPE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[
https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645349#comment-16645349
]
Ignite TC Bot commented on IGNITE-9532:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Hadoop{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2050788]]
* IgniteHadoopFileSystemClientBasedDualAsyncSelfTest.testClientReconnect (last
started)
{color:#d04437}Client Nodes{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2050774]]
* IgniteClientReconnectApiExceptionTest.testErrorOnDisconnect (last started)
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2050819]]
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2050813]]
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testAtomicLongRetries - 0,0% fails in
last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testPutAsyncStoreEnabled - 0,0% fails
in last 100 master runs.
{color:#d04437}Queries 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2050800]]
* IgniteBinaryCacheQueryTestSuite2:
DynamicColumnsConcurrentAtomicReplicatedSelfTest.testDropColumnCoordinatorChange
- 1,0% fails in last 100 master runs.
{color:#d04437}Cache (Full API Multi JVM){color} [[tests
39|https://ci.ignite.apache.org/viewLog.html?buildId=2050843]]
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testGetAll - 0,0% fails in
last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testGetAllWithFirstNull -
0,0% fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testGetAndPutAsync - 0,0%
fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testGetAndRemove - 0,0% fails
in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testGetAsyncOld - 0,0% fails
in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testGetOutTxAsync - 0,0%
fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testGlobalClearAllAsync -
0,0% fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testGlobalClearAllAsyncOld -
0,0% fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testGlobalClearKeys - 0,0%
fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testGlobalClearKeysAsync -
0,0% fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testIgniteTransformOptimisticRepeatableRead
- 0,0% fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testInvoke - 0,0% fails in
last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testIterator - 0,0% fails in
last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testLocalClearKey - 0,0%
fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testLockInsideTransaction -
0,0% fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testOptimisticTxMissingKeyNoCommit
- 0,0% fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testOptimisticTxReadCommittedInTx
- 0,0% fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testPeekExpired - 0,0% fails
in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testPessimisticTxReadCommittedInTx
- 0,0% fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testPessimisticTxRepeatableRead
- 0,0% fails in last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
GridCachePartitionedOnheapMultiJvmFullApiSelfTest.testPutAll - 0,0% fails in
last 100 master runs.
* IgniteCacheFullApiMultiJvmSelfTestSuite:
[jira] [Updated] (IGNITE-9844) Replace action in pessimistic transaction makes value unwrap and causes ClassNotFoundException
[
https://issues.apache.org/jira/browse/IGNITE-9844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov updated IGNITE-9844:
--
Ignite Flags: (was: Docs Required)
> Replace action in pessimistic transaction makes value unwrap and causes
> ClassNotFoundException
> --
>
> Key: IGNITE-9844
> URL: https://issues.apache.org/jira/browse/IGNITE-9844
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Mikhail Cherkasov
>Priority: Major
> Attachments: SimpleTest.java
>
>
> The problem can be reproduced only if you replace the existing value in a
> cache inside pessimistic transaction and server node doesn't have the class
> for the value which the node already has in the cache.
> The reproducer is attached, please make sure that you run server node without
> model class in class path.
> Stack trace:
> {code:java}
> [2018-10-10 10:16:31,828][ERROR][pub-#52%grid_0%][GridJobWorker] Failed to
> execute job [jobId=07acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b,
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl
> [taskName=class_not_found.SimpleTest$Task, dep=GridDeployment
> [ts=1539191791633, depMode=SHARED, clsLdr=GridDeploymentClassLoader
> [id=db2aafe5661-f793ea41-94c4-4ae0-8276-8cc771e48fa9, singleNode=false,
> nodeLdrMap=HashMap
> {c681a6d3-e7ab-4516-9931-e817e77cac5b=96acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b},
> p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false],
> clsLdrId=db2aafe5661-f793ea41-94c4-4ae0-8276-8cc771e48fa9, userVer=0,
> loc=false, sampleClsName=class_not_found.SimpleTest$Task,
> pendingUndeploy=false, undeployed=false, usage=1]SharedDeployment [rmv=false,
> super=], taskClsName=class_not_found.SimpleTest$Task,
> sesId=f6acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b,
> startTime=1539191791465, endTime=9223372036854775807,
> taskNodeId=c681a6d3-e7ab-4516-9931-e817e77cac5b,
> clsLdr=GridDeploymentClassLoader
> [id=db2aafe5661-f793ea41-94c4-4ae0-8276-8cc771e48fa9, singleNode=false,
> nodeLdrMap=HashMap
> {c681a6d3-e7ab-4516-9931-e817e77cac5b=96acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b},
> p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false], closed=false,
> cpSpi=null, failSpi=null, loadSpi=null, usage=1, fullSup=false,
> internal=false, topPred=null, subjId=c681a6d3-e7ab-4516-9931-e817e77cac5b,
> mapFut=GridFutureAdapter [ignoreInterrupts=false, state=INIT, res=null,
> hash=550280323]IgniteFuture [orig=], execName=null],
> jobId=07acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b]]
> class org.apache.ignite.IgniteException:
> class_not_found.SimpleTest$MyDomainObject
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1858)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6797)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1191)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1923)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
> class_not_found.SimpleTest$MyDomainObject
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:707)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:798)
> at
>
[jira] [Created] (IGNITE-9844) Replace action in pessimistic transaction makes value unwrap and causes ClassNotFoundException
Mikhail Cherkasov created IGNITE-9844:
-
Summary: Replace action in pessimistic transaction makes value
unwrap and causes ClassNotFoundException
Key: IGNITE-9844
URL: https://issues.apache.org/jira/browse/IGNITE-9844
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.6
Reporter: Mikhail Cherkasov
Attachments: SimpleTest.java
The problem can be reproduced only if you replace the existing value in a cache
inside pessimistic transaction and server node doesn't have the class for the
value which the node already has in the cache.
The reproducer is attached, please make sure that you run server node without
model class in class path.
Stack trace:
{code:java}
[2018-10-10 10:16:31,828][ERROR][pub-#52%grid_0%][GridJobWorker] Failed to
execute job [jobId=07acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b,
ses=GridJobSessionImpl [ses=GridTaskSessionImpl
[taskName=class_not_found.SimpleTest$Task, dep=GridDeployment
[ts=1539191791633, depMode=SHARED, clsLdr=GridDeploymentClassLoader
[id=db2aafe5661-f793ea41-94c4-4ae0-8276-8cc771e48fa9, singleNode=false,
nodeLdrMap=HashMap
{c681a6d3-e7ab-4516-9931-e817e77cac5b=96acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b},
p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false],
clsLdrId=db2aafe5661-f793ea41-94c4-4ae0-8276-8cc771e48fa9, userVer=0,
loc=false, sampleClsName=class_not_found.SimpleTest$Task,
pendingUndeploy=false, undeployed=false, usage=1]SharedDeployment [rmv=false,
super=], taskClsName=class_not_found.SimpleTest$Task,
sesId=f6acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b,
startTime=1539191791465, endTime=9223372036854775807,
taskNodeId=c681a6d3-e7ab-4516-9931-e817e77cac5b,
clsLdr=GridDeploymentClassLoader
[id=db2aafe5661-f793ea41-94c4-4ae0-8276-8cc771e48fa9, singleNode=false,
nodeLdrMap=HashMap
{c681a6d3-e7ab-4516-9931-e817e77cac5b=96acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b},
p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false], closed=false,
cpSpi=null, failSpi=null, loadSpi=null, usage=1, fullSup=false, internal=false,
topPred=null, subjId=c681a6d3-e7ab-4516-9931-e817e77cac5b,
mapFut=GridFutureAdapter [ignoreInterrupts=false, state=INIT, res=null,
hash=550280323]IgniteFuture [orig=], execName=null],
jobId=07acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b]]
class org.apache.ignite.IgniteException:
class_not_found.SimpleTest$MyDomainObject
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1858)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6797)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1191)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1923)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
class_not_found.SimpleTest$MyDomainObject
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:707)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:798)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
at
org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:177)
at
org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:67)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
at
[jira] [Resolved] (IGNITE-8335) TensorFlow integration
[ https://issues.apache.org/jira/browse/IGNITE-8335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak resolved IGNITE-8335. Resolution: Done Fix Version/s: 2.7 done in other tasks > TensorFlow integration > -- > > Key: IGNITE-8335 > URL: https://issues.apache.org/jira/browse/IGNITE-8335 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Anton Dmitriev >Priority: Major > Fix For: 2.7 > > > The goal of TensorFlow on Apache Ignite is to allow users to train and > inference neural network models on a data stored in Apache Ignite distributed > database utilizing all TensorFlow functionality and Apache Ignite data > collocation abilities. > There are 8 questions we need to answer to build TensorFlow on Apache Ignite: > * How to build and maintain TensorFlow cluster on top of Apache Ignite > infrastructure utilizing Apache Ignite data collocation abilities? > * How to pass data from Apache Ignite storage into TensorFlow? > * How to organize load balancing and optimize Apache Ignite data distribution > to improve training performance? > * How to integrate TensorFlow checkpoints mechanism into Apache Ignite > ecosystem? > * How to recover after cluster node failures? > * How to deploy TensorFlow on Apache Ignite in local/cluster/cloud > environment? > * How to serve model built in TensorFlow on Apache Ignite? > * How to profile training using TensorBoard or similar tools? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9559) Node.js thin: nodejs directory should be included binary release
[
https://issues.apache.org/jira/browse/IGNITE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645247#comment-16645247
]
ASF GitHub Bot commented on IGNITE-9559:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4949
> Node.js thin: nodejs directory should be included binary release
>
>
> Key: IGNITE-9559
> URL: https://issues.apache.org/jira/browse/IGNITE-9559
> Project: Ignite
> Issue Type: Improvement
> Components: build, thin client
>Reporter: Igor Sapego
>Assignee: Peter Ivanov
>Priority: Blocker
> Labels: nodejs
> Fix For: 2.7
>
>
> Currently, nodejs directory is not generated by the {{maven install}}
> command. Need to add appropriate copy steps to
> {{assembly/release-fabric-base.xml}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9247) CPP Thin: implement operations with multiple keys and values
[ https://issues.apache.org/jira/browse/IGNITE-9247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-9247: Description: Need to implement GetAll, PutAll, ContainsKeys, RemoveAll, ClearAll in C++ Thin client. was: Need to implement GetAll in C++ Thin client. Currently, there is no way to extract values from cache via C++ Thin client without knowing the keys beforehand. GetAll would be the easiest way to do that. > CPP Thin: implement operations with multiple keys and values > > > Key: IGNITE-9247 > URL: https://issues.apache.org/jira/browse/IGNITE-9247 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Stanislav Lukyanov >Assignee: Igor Sapego >Priority: Major > > Need to implement GetAll, PutAll, ContainsKeys, RemoveAll, ClearAll in C++ > Thin client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9247) CPP Thin: implement GetAll
[ https://issues.apache.org/jira/browse/IGNITE-9247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645228#comment-16645228 ] ASF GitHub Bot commented on IGNITE-9247: GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/4950 IGNITE-9247: CPP Thin: implemented operations on multiple keys and values You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9247 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4950.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 #4950 commit 95ade4afb96b5f6acd23f8db309500dc1dd65679 Author: Igor Sapego Date: 2018-09-25T15:15:40Z IGNITE-9247: Added a test for iterator GetAll commit 7ae28d2b7f801d3708d0540e52d5f9427a7b9e61 Author: Igor Sapego Date: 2018-09-25T15:22:58Z IGNITE-9247: Added test for GetAll with containers commit d85a1ab074d390fcc0c5e68508918c67060f446b Author: Igor Sapego Date: 2018-09-25T15:37:42Z IGNITE-9247: Implemented GetAll method stubs commit a14889c4cde0f52f492c2b2338e091cd5b378aba Author: Igor Sapego Date: 2018-09-26T09:13:38Z IGNITE-9247: Implemented WritableSequenceImpl commit 1fc4a02130a7a6dcf8838e83d1bd8bfa7a8e27b8 Author: Igor Sapego Date: 2018-09-28T12:29:54Z IGNITE-9247: Implemented ReadableMapImpl commit 5ec708bc01f2bc42eb2d697300e4122ac7ee34f2 Author: Igor Sapego Date: 2018-10-09T13:04:39Z IGNITE-9247: Further progress commit 9fe6504aed85678c5325a256668ddb7a2fb5516d Author: Igor Sapego Date: 2018-10-09T17:18:11Z IGNITE-9247: Implemented GetAll commit dd9b76c5071b4680b7b42a99ca710bf23a6a8f8c Author: Igor Sapego Date: 2018-10-10T13:48:08Z IGNITE-9247: Implemented PutAll() commit 08e06d14cda70f1bada850d1e3f74c81caa8f9a8 Author: Igor Sapego Date: 2018-10-10T15:11:43Z IGNITE-9247: Implemented RemoveAll() commit c025068e7bae4400dec7286316e3ec989663c927 Author: Igor Sapego Date: 2018-10-10T15:22:58Z IGNITE-9247: Implemented ClearAll() commit af482f181c676acad1b6eee758eda5b63e98c3ff Author: Igor Sapego Date: 2018-10-10T15:58:34Z IGNITE-9247: Implemented ContainsKeys() commit 4ed373ad8ef46eaf4546f40f5557ceb7a5fb Author: Igor Sapego Date: 2018-10-10T16:29:08Z IGNITE-9247: Implemented Replace() > CPP Thin: implement GetAll > -- > > Key: IGNITE-9247 > URL: https://issues.apache.org/jira/browse/IGNITE-9247 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Stanislav Lukyanov >Assignee: Igor Sapego >Priority: Major > > Need to implement GetAll in C++ Thin client. > Currently, there is no way to extract values from cache via C++ Thin client > without knowing the keys beforehand. GetAll would be the easiest way to do > that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9247) CPP Thin: implement operations with multiple keys and values
[ https://issues.apache.org/jira/browse/IGNITE-9247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-9247: Summary: CPP Thin: implement operations with multiple keys and values (was: CPP Thin: implement GetAll) > CPP Thin: implement operations with multiple keys and values > > > Key: IGNITE-9247 > URL: https://issues.apache.org/jira/browse/IGNITE-9247 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Stanislav Lukyanov >Assignee: Igor Sapego >Priority: Major > > Need to implement GetAll in C++ Thin client. > Currently, there is no way to extract values from cache via C++ Thin client > without knowing the keys beforehand. GetAll would be the easiest way to do > that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7556) Docs should feature specifying SQL key more prominently
[
https://issues.apache.org/jira/browse/IGNITE-7556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev reassigned IGNITE-7556:
---
Assignee: Artem Budnikov (was: Ilya Kasnacheev)
> Docs should feature specifying SQL key more prominently
> ---
>
> Key: IGNITE-7556
> URL: https://issues.apache.org/jira/browse/IGNITE-7556
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Reporter: Ilya Kasnacheev
>Assignee: Artem Budnikov
>Priority: Minor
>
> Descriptions on [https://apacheignite-sql.readme.io/docs/schema-and-indexes]
> are not DML-friendly
> After reading this page and
> [https://apacheignite-sql.readme.io/docs/insert], one would likely still
> unable to write working INSERT because there won't be primary key in it.
> Their only chance is to spot _key reference in infoblock, or infer usability
> of setKeyFields() with single key type. Both are unlikely, leading to
> questions such as
> [https://stackoverflow.com/questions/48460214/how-do-i-read-data-from-ignite-kv-storage-using-jdbc]
> see {{Key is missing from query}}
> Such problems are hard to debug. They can be avoided if all examples of
> QueryEntities in docs will contain setKeyFields, and INSERT docs page will
> refer to _key field.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7556) Docs should feature specifying SQL key more prominently
[
https://issues.apache.org/jira/browse/IGNITE-7556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645222#comment-16645222
]
Ilya Kasnacheev commented on IGNITE-7556:
-
[~Artem Budnikov] I have added an edit to queryEntity configuration, but I also
suggest adding examples of INSERT query to every section.
> Docs should feature specifying SQL key more prominently
> ---
>
> Key: IGNITE-7556
> URL: https://issues.apache.org/jira/browse/IGNITE-7556
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>
> Descriptions on [https://apacheignite-sql.readme.io/docs/schema-and-indexes]
> are not DML-friendly
> After reading this page and
> [https://apacheignite-sql.readme.io/docs/insert], one would likely still
> unable to write working INSERT because there won't be primary key in it.
> Their only chance is to spot _key reference in infoblock, or infer usability
> of setKeyFields() with single key type. Both are unlikely, leading to
> questions such as
> [https://stackoverflow.com/questions/48460214/how-do-i-read-data-from-ignite-kv-storage-using-jdbc]
> see {{Key is missing from query}}
> Such problems are hard to debug. They can be avoided if all examples of
> QueryEntities in docs will contain setKeyFields, and INSERT docs page will
> refer to _key field.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9559) Node.js thin: nodejs directory should be included binary release
[
https://issues.apache.org/jira/browse/IGNITE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645204#comment-16645204
]
Peter Ivanov commented on IGNITE-9559:
--
Done. [~isapego], please review.
> Node.js thin: nodejs directory should be included binary release
>
>
> Key: IGNITE-9559
> URL: https://issues.apache.org/jira/browse/IGNITE-9559
> Project: Ignite
> Issue Type: Improvement
> Components: build, thin client
>Reporter: Igor Sapego
>Assignee: Peter Ivanov
>Priority: Blocker
> Labels: nodejs
> Fix For: 2.7
>
>
> Currently, nodejs directory is not generated by the {{maven install}}
> command. Need to add appropriate copy steps to
> {{assembly/release-fabric-base.xml}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9221) Uncomment 25 test classes in various Indexing test suites
[
https://issues.apache.org/jira/browse/IGNITE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645197#comment-16645197
]
Ilya Kasnacheev commented on IGNITE-9221:
-
[~dpavlov] please review proposed fix.
Please do not merge yet, since I will try to split this commit to make git
history prettier.
> Uncomment 25 test classes in various Indexing test suites
> -
>
> Key: IGNITE-9221
> URL: https://issues.apache.org/jira/browse/IGNITE-9221
> Project: Ignite
> Issue Type: Sub-task
> Components: binary, sql
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite.java
> {code}
> // suite.addTest(new TestSuite(QueryEntityValidationSelfTest.class));
> // suite.addTest(new TestSuite(GridH2TableSelfTest.class));
> //suite.addTestSuite(IgniteCacheUnionDuplicatesTest.class);
> //suite.addTestSuite(IgniteCacheConfigVariationsQueryTest.class);
>
> //suite.addTestSuite(IgniteCacheJoinPartitionedAndReplicatedCollocationTest.class);
>
> //suite.addTestSuite(IgniteClientReconnectCacheQueriesFailoverTest.class);
> //suite.addTestSuite(IgniteErrorOnRebalanceTest.class);
> //suite.addTestSuite(CacheQueryBuildValueTest.class);
> //suite.addTestSuite(CacheOffheapBatchIndexingMultiTypeTest.class);
> //suite.addTestSuite(CacheOffheapBatchIndexingBaseTest.class);
> //suite.addTestSuite(GridCircularQueueTest.class);
> //suite.addTestSuite(IndexingSpiQueryWithH2IndexingSelfTest.class);
> //suite.addTestSuite(H2DynamicIndexingComplexAbstractTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexClientAtomicPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexClientTransactionalPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexServerAtomicPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexServerTransactionalPartitionedNoBackupsTest.class);
> {code}
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite3.java
> {code}
>
> //suite.addTestSuite(CacheContinuousQueryCounterPartitionedAtomicTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterPartitionedTxTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterReplicatedAtomicTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterReplicatedTxTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryFailoverAtomicNearEnabledSelfSelfTest.class);
> {code}
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteBinaryCacheQueryTestSuite.java
> {code}
> //suite.addTestSuite(GridCacheBinarySwapScanQuerySelfTest.class);
> //suite.addTestSuite(IgniteSqlSchemaIndexingTest.class);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9843) IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta without losing data
Ilya Kasnacheev created IGNITE-9843: --- Summary: IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta without losing data Key: IGNITE-9843 URL: https://issues.apache.org/jira/browse/IGNITE-9843 Project: Ignite Issue Type: Bug Reporter: Ilya Kasnacheev
[jira] [Created] (IGNITE-9842) IgniteErrorOnRebalanceTest fails: errors in indexing cause grid to stall
Ilya Kasnacheev created IGNITE-9842: --- Summary: IgniteErrorOnRebalanceTest fails: errors in indexing cause grid to stall Key: IGNITE-9842 URL: https://issues.apache.org/jira/browse/IGNITE-9842 Project: Ignite Issue Type: Bug Reporter: Ilya Kasnacheev
[jira] [Created] (IGNITE-9841) SQL take lost partitions into account when persistence is enabled
Stanislav Lukyanov created IGNITE-9841: -- Summary: SQL take lost partitions into account when persistence is enabled Key: IGNITE-9841 URL: https://issues.apache.org/jira/browse/IGNITE-9841 Project: Ignite Issue Type: Bug Components: sql Reporter: Stanislav Lukyanov Attachments: IgniteSqlQueryWithLostPartitionsTest.java IGNITE-8927 changed SQL queries to honor lost partitions. However, it doesn't work if persistence is enabled. E.g. if there are lost partitions then `select * from T` fails for in-memory caches (good) and silently ignores the lost partitions for persistent caches (bad). See attached reproducer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9606) JDBC getPrimaryKeys() returns wrong value for COLUMN_NAME
[
https://issues.apache.org/jira/browse/IGNITE-9606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645133#comment-16645133
]
Pavel Kuznetsov commented on IGNITE-9606:
-
SQL tests run: https://ci.ignite.apache.org/viewQueued.html?itemId=2052728
> JDBC getPrimaryKeys() returns wrong value for COLUMN_NAME
> -
>
> Key: IGNITE-9606
> URL: https://issues.apache.org/jira/browse/IGNITE-9606
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.6
>Reporter: Pat Patterson
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> JDBC {{getPrimaryKeys()}} method returns {{_KEY}} as column name rather than
> actual column name. This breaks apps that expect a valid column name as the
> primary key.
> Trivially reproducible:
> {noformat}
> public static void main(String[] args) throws Exception {
> // Register JDBC driver.
> Class.forName("org.apache.ignite.IgniteJdbcThinDriver");
> // Open JDBC connection.
> try (Connection conn =
> DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")) {
> // Create database tables.
> try (Statement stmt = conn.createStatement()) {
> stmt.executeUpdate("CREATE TABLE TESTER (" + " ID LONG PRIMARY KEY,
> NAME VARCHAR) " + " WITH \"template=replicated\"");
> }
> // Get database metadata
> DatabaseMetaData md = conn.getMetaData();
> // Get primary keys
> ResultSet rs = md.getPrimaryKeys(conn.getCatalog(), "", "TESTER");
> //
> while (rs.next()) {
> // Column 4 is COLUMN_NAME
> System.out.println("Primary key column is " + rs.getString(4));
> }
> }
> }
> {noformat}
> Expected output is:
> {noformat}
> Primary key column is ID
> {noformat}
> Actual output is:
> {noformat}
> Primary key column is _KEY
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9606) JDBC getPrimaryKeys() returns wrong value for COLUMN_NAME
[
https://issues.apache.org/jira/browse/IGNITE-9606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645130#comment-16645130
]
Pavel Kuznetsov commented on IGNITE-9606:
-
After devozerov's review, deceided not to change QueryBinaryProperty#key() key
behaviour.
> JDBC getPrimaryKeys() returns wrong value for COLUMN_NAME
> -
>
> Key: IGNITE-9606
> URL: https://issues.apache.org/jira/browse/IGNITE-9606
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.6
>Reporter: Pat Patterson
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> JDBC {{getPrimaryKeys()}} method returns {{_KEY}} as column name rather than
> actual column name. This breaks apps that expect a valid column name as the
> primary key.
> Trivially reproducible:
> {noformat}
> public static void main(String[] args) throws Exception {
> // Register JDBC driver.
> Class.forName("org.apache.ignite.IgniteJdbcThinDriver");
> // Open JDBC connection.
> try (Connection conn =
> DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")) {
> // Create database tables.
> try (Statement stmt = conn.createStatement()) {
> stmt.executeUpdate("CREATE TABLE TESTER (" + " ID LONG PRIMARY KEY,
> NAME VARCHAR) " + " WITH \"template=replicated\"");
> }
> // Get database metadata
> DatabaseMetaData md = conn.getMetaData();
> // Get primary keys
> ResultSet rs = md.getPrimaryKeys(conn.getCatalog(), "", "TESTER");
> //
> while (rs.next()) {
> // Column 4 is COLUMN_NAME
> System.out.println("Primary key column is " + rs.getString(4));
> }
> }
> }
> {noformat}
> Expected output is:
> {noformat}
> Primary key column is ID
> {noformat}
> Actual output is:
> {noformat}
> Primary key column is _KEY
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9606) JDBC getPrimaryKeys() returns wrong value for COLUMN_NAME
[
https://issues.apache.org/jira/browse/IGNITE-9606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645121#comment-16645121
]
ASF GitHub Bot commented on IGNITE-9606:
GitHub user pavel-kuznetsov opened a pull request:
https://github.com/apache/ignite/pull/4948
IGNITE-9606: JDBC getPrimaryKeys() returns wrong value for COLUMN_NAME
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9606-simple
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4948.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 #4948
commit 5d144b2f57933b96dc4ccb68be119f7c205bb6f7
Author: Pavel Kuznetsov
Date: 2018-10-02T14:43:31Z
ignite-9606: Added test that reproduces the bug.
commit ee16f57dffe52fccaa6f2bba4e4546a343ca1581
Author: Pavel Kuznetsov
Date: 2018-10-10T14:54:49Z
ignite-9606: updated test.
commit 34d70e7135e4a1548dc6a388b68148f29039cb57
Author: Pavel Kuznetsov
Date: 2018-10-10T14:56:27Z
ignite-9606: fixed column name.
Column name now looks in the keyFieldName before returning "_KEY".
> JDBC getPrimaryKeys() returns wrong value for COLUMN_NAME
> -
>
> Key: IGNITE-9606
> URL: https://issues.apache.org/jira/browse/IGNITE-9606
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.6
>Reporter: Pat Patterson
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> JDBC {{getPrimaryKeys()}} method returns {{_KEY}} as column name rather than
> actual column name. This breaks apps that expect a valid column name as the
> primary key.
> Trivially reproducible:
> {noformat}
> public static void main(String[] args) throws Exception {
> // Register JDBC driver.
> Class.forName("org.apache.ignite.IgniteJdbcThinDriver");
> // Open JDBC connection.
> try (Connection conn =
> DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")) {
> // Create database tables.
> try (Statement stmt = conn.createStatement()) {
> stmt.executeUpdate("CREATE TABLE TESTER (" + " ID LONG PRIMARY KEY,
> NAME VARCHAR) " + " WITH \"template=replicated\"");
> }
> // Get database metadata
> DatabaseMetaData md = conn.getMetaData();
> // Get primary keys
> ResultSet rs = md.getPrimaryKeys(conn.getCatalog(), "", "TESTER");
> //
> while (rs.next()) {
> // Column 4 is COLUMN_NAME
> System.out.println("Primary key column is " + rs.getString(4));
> }
> }
> }
> {noformat}
> Expected output is:
> {noformat}
> Primary key column is ID
> {noformat}
> Actual output is:
> {noformat}
> Primary key column is _KEY
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9606) JDBC getPrimaryKeys() returns wrong value for COLUMN_NAME
[
https://issues.apache.org/jira/browse/IGNITE-9606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645119#comment-16645119
]
ASF GitHub Bot commented on IGNITE-9606:
Github user pavel-kuznetsov closed the pull request at:
https://github.com/apache/ignite/pull/4906
> JDBC getPrimaryKeys() returns wrong value for COLUMN_NAME
> -
>
> Key: IGNITE-9606
> URL: https://issues.apache.org/jira/browse/IGNITE-9606
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.6
>Reporter: Pat Patterson
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> JDBC {{getPrimaryKeys()}} method returns {{_KEY}} as column name rather than
> actual column name. This breaks apps that expect a valid column name as the
> primary key.
> Trivially reproducible:
> {noformat}
> public static void main(String[] args) throws Exception {
> // Register JDBC driver.
> Class.forName("org.apache.ignite.IgniteJdbcThinDriver");
> // Open JDBC connection.
> try (Connection conn =
> DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")) {
> // Create database tables.
> try (Statement stmt = conn.createStatement()) {
> stmt.executeUpdate("CREATE TABLE TESTER (" + " ID LONG PRIMARY KEY,
> NAME VARCHAR) " + " WITH \"template=replicated\"");
> }
> // Get database metadata
> DatabaseMetaData md = conn.getMetaData();
> // Get primary keys
> ResultSet rs = md.getPrimaryKeys(conn.getCatalog(), "", "TESTER");
> //
> while (rs.next()) {
> // Column 4 is COLUMN_NAME
> System.out.println("Primary key column is " + rs.getString(4));
> }
> }
> }
> {noformat}
> Expected output is:
> {noformat}
> Primary key column is ID
> {noformat}
> Actual output is:
> {noformat}
> Primary key column is _KEY
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9756) [Test Failed] IgniteCacheIncrementTxTest.testIncrementTxTopologyChange2 fails sometimes in master.
[
https://issues.apache.org/jira/browse/IGNITE-9756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9756:
-
Description:
IgniteCacheIncrementTxTest.testIncrementTxTopologyChange2 fails sometimes in
master with timeout.
Example of such failure:
[https://ci.ignite.apache.org/viewLog.html?buildId=1977579=buildResultsDiv=IgniteTests24Java8_Cache2#testNameId-613377372188362920]
Typical log output:
{noformat}
[2018-10-03 19:40:32,654][INFO
][sys-#438%cache.IgniteCacheIncrementTxTest1%][GridDhtPartitionDemander]
Started rebalance routine [default,
supplier=67fdbd60-24fe-4810-a6a6-41a949b3, topic=0, fullPartitions=[28, 31,
33, 40, 43, 56, 61, 63, 70, 86, 93, 107, 115, 129, 149, 153, 167, 187, 207,
215, 218, 224, 247, 279, 284, 290, 329, 332, 342, 373, 377, 383, 385-386, 423,
435, 469, 478, 494, 515, 525, 528, 537, 565, 603, 607, 610, 624, 654, 686, 707,
718, 738, 741, 746, 766, 775, 777, 797, 807, 809, 814, 822, 849, 856, 872, 876,
909, 911, 914, 925, 940, 943, 962, 983, 991, 1005, 1014], histPartitions=[]]
[2018-10-03 19:40:32,654][INFO
][sys-#175%cache.IgniteCacheIncrementTxTest0%][GridDhtPartitionSupplier]
Finished supplying rebalancing [grp=default,
demander=688062dd-508d-4ebc-9458-a48e1ba2, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], topic=0]
[2018-10-03 19:40:32,654][INFO
][sys-#185%cache.IgniteCacheIncrementTxTest3%][GridDhtPartitionSupplier]
Finished supplying rebalancing [grp=default,
demander=3f09a855-390b-40ce-b3e0-8b411db1, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], topic=0]
[2018-10-03 19:40:32,654][INFO
][sys-#179%cache.IgniteCacheIncrementTxTest0%][GridDhtPartitionSupplier]
Finished supplying rebalancing [grp=default,
demander=67fdbd60-24fe-4810-a6a6-41a949b3, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], topic=0]
[2018-10-03 19:40:32,654][INFO
][sys-#234%cache.IgniteCacheIncrementTxTest1%][GridDhtPartitionDemander]
Completed rebalancing [grp=default,
supplier=67fdbd60-24fe-4810-a6a6-41a949b3, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], progress=1/2, time=0 ms]
[2018-10-03 19:40:32,654][INFO
][sys-#237%cache.IgniteCacheIncrementTxTest3%][GridDhtPartitionDemander]
Completed (final) rebalancing [grp=default,
supplier=4b3e5c6e-cec4-4fb6-b1b2-47fd7190, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], progress=2/2, time=0 ms]
[2018-10-03 19:40:32,654][INFO
][sys-#237%cache.IgniteCacheIncrementTxTest3%][GridDhtPartitionDemander]
Completed rebalance future: RebalanceFuture [grp=CacheGroupContext
[grp=default], topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0],
rebalanceId=96, routines=2]
[2018-10-03 19:40:32,655][INFO
][sys-#162%cache.IgniteCacheIncrementTxTest2%][GridDhtPartitionDemander]
Completed (final) rebalancing [grp=default,
supplier=4b3e5c6e-cec4-4fb6-b1b2-47fd7190, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], progress=2/2, time=0 ms]
[2018-10-03 19:40:32,655][INFO
][sys-#162%cache.IgniteCacheIncrementTxTest2%][GridDhtPartitionDemander]
Completed rebalance future: RebalanceFuture [grp=CacheGroupContext
[grp=default], topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0],
rebalanceId=96, routines=2]
[2018-10-03 19:40:33,260][INFO
][exchange-worker-#38%cache.IgniteCacheIncrementTxTest0%][GridCachePartitionExchangeManager]
Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion
[topVer=45, minorTopVer=0], force=true, evt=NODE_LEFT,
node=f675cf49-5db3-45b3-83fb-7a778849]
[2018-10-03 19:40:33,261][INFO
][exchange-worker-#151%cache.IgniteCacheIncrementTxTest1%][GridDhtPartitionDemander]
Cancelled rebalancing from all nodes [grp=default,
topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0]]
[2018-10-03 19:40:33,261][INFO
][exchange-worker-#151%cache.IgniteCacheIncrementTxTest1%][GridDhtPartitionDemander]
Completed rebalance future: RebalanceFuture [grp=CacheGroupContext
[grp=default], topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0],
rebalanceId=96, routines=2]
[2018-10-03 19:40:33,261][INFO
][exchange-worker-#151%cache.IgniteCacheIncrementTxTest1%][GridCachePartitionExchangeManager]
Rebalancing scheduled [order=[default], top=AffinityTopologyVersion
[topVer=45, minorTopVer=0], force=true, evt=NODE_LEFT,
node=f675cf49-5db3-45b3-83fb-7a778849]
[2018-10-03 19:40:33,262][INFO
][exchange-worker-#151%cache.IgniteCacheIncrementTxTest1%][GridDhtPartitionDemander]
Prepared rebalancing [grp=default, mode=ASYNC,
supplier=4b3e5c6e-cec4-4fb6-b1b2-47fd7190, partitionsCount=97,
topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0], parallelism=1]
[2018-10-03 19:40:33,899][INFO
][sys-#155%cache.IgniteCacheIncrementTxTest0%][GridCachePartitionExchangeManager]
Full Message creating for AffinityTopologyVersion [topVer=45, minorTopVer=0]
performed in 1 ms.
[2018-10-03 19:40:33,903][INFO
[jira] [Updated] (IGNITE-9756) [Test Failed] IgniteCacheIncrementTxTest.testIncrementTxTopologyChange2 fails sometimes in master.
[
https://issues.apache.org/jira/browse/IGNITE-9756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9756:
-
Description:
IgniteCacheIncrementTxTest.testIncrementTxTopologyChange2 fails sometimes in
master with timeout.
Example of such failure:
[https://ci.ignite.apache.org/viewLog.html?buildId=1977579=buildResultsDiv=IgniteTests24Java8_Cache2#testNameId-613377372188362920]
Typical log output:
{noformat}
[2018-10-03 19:40:32,654][INFO
][sys-#438%cache.IgniteCacheIncrementTxTest1%][GridDhtPartitionDemander]
Started rebalance routine [default,
supplier=67fdbd60-24fe-4810-a6a6-41a949b3, topic=0, fullPartitions=[28, 31,
33, 40, 43, 56, 61, 63, 70, 86, 93, 107, 115, 129, 149, 153, 167, 187, 207,
215, 218, 224, 247, 279, 284, 290, 329, 332, 342, 373, 377, 383, 385-386, 423,
435, 469, 478, 494, 515, 525, 528, 537, 565, 603, 607, 610, 624, 654, 686, 707,
718, 738, 741, 746, 766, 775, 777, 797, 807, 809, 814, 822, 849, 856, 872, 876,
909, 911, 914, 925, 940, 943, 962, 983, 991, 1005, 1014], histPartitions=[]]
[2018-10-03 19:40:32,654][INFO
][sys-#175%cache.IgniteCacheIncrementTxTest0%][GridDhtPartitionSupplier]
Finished supplying rebalancing [grp=default,
demander=688062dd-508d-4ebc-9458-a48e1ba2, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], topic=0]
[2018-10-03 19:40:32,654][INFO
][sys-#185%cache.IgniteCacheIncrementTxTest3%][GridDhtPartitionSupplier]
Finished supplying rebalancing [grp=default,
demander=3f09a855-390b-40ce-b3e0-8b411db1, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], topic=0]
[2018-10-03 19:40:32,654][INFO
][sys-#179%cache.IgniteCacheIncrementTxTest0%][GridDhtPartitionSupplier]
Finished supplying rebalancing [grp=default,
demander=67fdbd60-24fe-4810-a6a6-41a949b3, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], topic=0]
[2018-10-03 19:40:32,654][INFO
][sys-#234%cache.IgniteCacheIncrementTxTest1%][GridDhtPartitionDemander]
Completed rebalancing [grp=default,
supplier=67fdbd60-24fe-4810-a6a6-41a949b3, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], progress=1/2, time=0 ms]
[2018-10-03 19:40:32,654][INFO
][sys-#237%cache.IgniteCacheIncrementTxTest3%][GridDhtPartitionDemander]
Completed (final) rebalancing [grp=default,
supplier=4b3e5c6e-cec4-4fb6-b1b2-47fd7190, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], progress=2/2, time=0 ms]
[2018-10-03 19:40:32,654][INFO
][sys-#237%cache.IgniteCacheIncrementTxTest3%][GridDhtPartitionDemander]
Completed rebalance future: RebalanceFuture [grp=CacheGroupContext
[grp=default], topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0],
rebalanceId=96, routines=2]
[2018-10-03 19:40:32,655][INFO
][sys-#162%cache.IgniteCacheIncrementTxTest2%][GridDhtPartitionDemander]
Completed (final) rebalancing [grp=default,
supplier=4b3e5c6e-cec4-4fb6-b1b2-47fd7190, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], progress=2/2, time=0 ms]
[2018-10-03 19:40:32,655][INFO
][sys-#162%cache.IgniteCacheIncrementTxTest2%][GridDhtPartitionDemander]
Completed rebalance future: RebalanceFuture [grp=CacheGroupContext
[grp=default], topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0],
rebalanceId=96, routines=2]
[2018-10-03 19:40:33,260][INFO
][exchange-worker-#38%cache.IgniteCacheIncrementTxTest0%][GridCachePartitionExchangeManager]
Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion
[topVer=45, minorTopVer=0], force=true, evt=NODE_LEFT,
node=f675cf49-5db3-45b3-83fb-7a778849]
[2018-10-03 19:40:33,261][INFO
][exchange-worker-#151%cache.IgniteCacheIncrementTxTest1%][GridDhtPartitionDemander]
Cancelled rebalancing from all nodes [grp=default,
topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0]]
[2018-10-03 19:40:33,261][INFO
][exchange-worker-#151%cache.IgniteCacheIncrementTxTest1%][GridDhtPartitionDemander]
Completed rebalance future: RebalanceFuture [grp=CacheGroupContext
[grp=default], topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0],
rebalanceId=96, routines=2]
[2018-10-03 19:40:33,261][INFO
][exchange-worker-#151%cache.IgniteCacheIncrementTxTest1%][GridCachePartitionExchangeManager]
Rebalancing scheduled [order=[default], top=AffinityTopologyVersion
[topVer=45, minorTopVer=0], force=true, evt=NODE_LEFT,
node=f675cf49-5db3-45b3-83fb-7a778849]
[2018-10-03 19:40:33,262][INFO
][exchange-worker-#151%cache.IgniteCacheIncrementTxTest1%][GridDhtPartitionDemander]
Prepared rebalancing [grp=default, mode=ASYNC,
supplier=4b3e5c6e-cec4-4fb6-b1b2-47fd7190, partitionsCount=97,
topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0], parallelism=1]
[2018-10-03 19:40:33,899][INFO
][sys-#155%cache.IgniteCacheIncrementTxTest0%][GridCachePartitionExchangeManager]
Full Message creating for AffinityTopologyVersion [topVer=45, minorTopVer=0]
performed in 1 ms.
[2018-10-03 19:40:33,903][INFO
[jira] [Assigned] (IGNITE-9836) Invalid check of ea java versions
[
https://issues.apache.org/jira/browse/IGNITE-9836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ivanov reassigned IGNITE-9836:
Assignee: Ilya Murchenko (was: Peter Ivanov)
> Invalid check of ea java versions
> -
>
> Key: IGNITE-9836
> URL: https://issues.apache.org/jira/browse/IGNITE-9836
> Project: Ignite
> Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Ilya Murchenko
>Priority: Major
>
> On check of '1.8.0_192-ea' java version in ignite.sh the next messages in
> console are printed:
> {code:java}
> ./include/functions.sh: line 81: [: -lt: unary operator expected
> ./ignite.sh: line 61:
> /home/vsisko/Downloads/distr/bin/include/build-classpath.sh: No such file or
> directory
> ./ignite.sh: line 152: [: -eq: unary operator expected
> ./ignite.sh: line 157: [: -gt: unary operator expected
> ./ignite.sh: line 170: [: -eq: unary operator expected{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9601) Write rollover WAL record as the last record in current segment
[
https://issues.apache.org/jira/browse/IGNITE-9601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645112#comment-16645112
]
Ignite TC Bot commented on IGNITE-9601:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2046528buildTypeId=IgniteTests24Java8_RunAll]
> Write rollover WAL record as the last record in current segment
> ---
>
> Key: IGNITE-9601
> URL: https://issues.apache.org/jira/browse/IGNITE-9601
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> Currently, rollover WAL record gets to the next segment when being logged.
> Moreover, the implementation allows data races, and rollover record is not
> necessarily the first record in the next segment. We are to add an option to
> logging facility to allow writing rollover record to the end of the current
> segment; subsequent records should get to the next segment then.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9756) [Test Failed] IgniteCacheIncrementTxTest.testIncrementTxTopologyChange2 fails sometimes in master.
[
https://issues.apache.org/jira/browse/IGNITE-9756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9756:
-
Description:
IgniteCacheIncrementTxTest.testIncrementTxTopologyChange2 fails sometimes in
master with timeout.
Example of such failure:
[https://ci.ignite.apache.org/viewLog.html?buildId=1977579=buildResultsDiv=IgniteTests24Java8_Cache2#testNameId-613377372188362920]
Typical log output:
{noformat}
[2018-10-03 19:40:32,654][INFO
][sys-#438%cache.IgniteCacheIncrementTxTest1%][GridDhtPartitionDemander]
Started rebalance routine [default,
supplier=67fdbd60-24fe-4810-a6a6-41a949b3, topic=0, fullPartitions=[28, 31,
33, 40, 43, 56, 61, 63, 70, 86, 93, 107, 115, 129, 149, 153, 167, 187, 207,
215, 218, 224, 247, 279, 284, 290, 329, 332, 342, 373, 377, 383, 385-386, 423,
435, 469, 478, 494, 515, 525, 528, 537, 565, 603, 607, 610, 624, 654, 686, 707,
718, 738, 741, 746, 766, 775, 777, 797, 807, 809, 814, 822, 849, 856, 872, 876,
909, 911, 914, 925, 940, 943, 962, 983, 991, 1005, 1014], histPartitions=[]]
[2018-10-03 19:40:32,654][INFO
][sys-#175%cache.IgniteCacheIncrementTxTest0%][GridDhtPartitionSupplier]
Finished supplying rebalancing [grp=default,
demander=688062dd-508d-4ebc-9458-a48e1ba2, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], topic=0]
[2018-10-03 19:40:32,654][INFO
][sys-#185%cache.IgniteCacheIncrementTxTest3%][GridDhtPartitionSupplier]
Finished supplying rebalancing [grp=default,
demander=3f09a855-390b-40ce-b3e0-8b411db1, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], topic=0]
[2018-10-03 19:40:32,654][INFO
][sys-#179%cache.IgniteCacheIncrementTxTest0%][GridDhtPartitionSupplier]
Finished supplying rebalancing [grp=default,
demander=67fdbd60-24fe-4810-a6a6-41a949b3, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], topic=0]
[2018-10-03 19:40:32,654][INFO
][sys-#234%cache.IgniteCacheIncrementTxTest1%][GridDhtPartitionDemander]
Completed rebalancing [grp=default,
supplier=67fdbd60-24fe-4810-a6a6-41a949b3, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], progress=1/2, time=0 ms]
[2018-10-03 19:40:32,654][INFO
][sys-#237%cache.IgniteCacheIncrementTxTest3%][GridDhtPartitionDemander]
Completed (final) rebalancing [grp=default,
supplier=4b3e5c6e-cec4-4fb6-b1b2-47fd7190, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], progress=2/2, time=0 ms]
[2018-10-03 19:40:32,654][INFO
][sys-#237%cache.IgniteCacheIncrementTxTest3%][GridDhtPartitionDemander]
Completed rebalance future: RebalanceFuture [grp=CacheGroupContext
[grp=default], topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0],
rebalanceId=96, routines=2]
[2018-10-03 19:40:32,655][INFO
][sys-#162%cache.IgniteCacheIncrementTxTest2%][GridDhtPartitionDemander]
Completed (final) rebalancing [grp=default,
supplier=4b3e5c6e-cec4-4fb6-b1b2-47fd7190, topVer=AffinityTopologyVersion
[topVer=45, minorTopVer=0], progress=2/2, time=0 ms]
[2018-10-03 19:40:32,655][INFO
][sys-#162%cache.IgniteCacheIncrementTxTest2%][GridDhtPartitionDemander]
Completed rebalance future: RebalanceFuture [grp=CacheGroupContext
[grp=default], topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0],
rebalanceId=96, routines=2]
[2018-10-03 19:40:33,260][INFO
][exchange-worker-#38%cache.IgniteCacheIncrementTxTest0%][GridCachePartitionExchangeManager]
Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion
[topVer=45, minorTopVer=0], force=true, evt=NODE_LEFT,
node=f675cf49-5db3-45b3-83fb-7a778849]
[2018-10-03 19:40:33,261][INFO
][exchange-worker-#151%cache.IgniteCacheIncrementTxTest1%][GridDhtPartitionDemander]
Cancelled rebalancing from all nodes [grp=default,
topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0]]
[2018-10-03 19:40:33,261][INFO
][exchange-worker-#151%cache.IgniteCacheIncrementTxTest1%][GridDhtPartitionDemander]
Completed rebalance future: RebalanceFuture [grp=CacheGroupContext
[grp=default], topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0],
rebalanceId=96, routines=2]
[2018-10-03 19:40:33,261][INFO
][exchange-worker-#151%cache.IgniteCacheIncrementTxTest1%][GridCachePartitionExchangeManager]
Rebalancing scheduled [order=[default], top=AffinityTopologyVersion
[topVer=45, minorTopVer=0], force=true, evt=NODE_LEFT,
node=f675cf49-5db3-45b3-83fb-7a778849]
[2018-10-03 19:40:33,262][INFO
][exchange-worker-#151%cache.IgniteCacheIncrementTxTest1%][GridDhtPartitionDemander]
Prepared rebalancing [grp=default, mode=ASYNC,
supplier=4b3e5c6e-cec4-4fb6-b1b2-47fd7190, partitionsCount=97,
topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0], parallelism=1]
[2018-10-03 19:40:33,899][INFO
][sys-#155%cache.IgniteCacheIncrementTxTest0%][GridCachePartitionExchangeManager]
Full Message creating for AffinityTopologyVersion [topVer=45, minorTopVer=0]
performed in 1 ms.
[2018-10-03 19:40:33,903][INFO
[jira] [Updated] (IGNITE-9840) Possible deadlock on transactional future on client node in case of network problems or long GC pauses
[
https://issues.apache.org/jira/browse/IGNITE-9840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Aleksandrov updated IGNITE-9840:
---
Description:
Steps to reproduce:
1)Start the server node with next timeouts. DefaultTxTimeout should be greater
than other:
{code:java}
{code}
On the server side you should create a cache with next parameters:
{code:java}
{code}
2)After that start the client with the next code:
{code:java}
IgniteCache cache = ignite.getOrCreateCache("CACHE");
try (Transaction tx = ignite.transactions().txStart()) {
cache.put("Key", new Object());
System.out.println("Stop me");
//here we will get long GC pause on server side
Thread.sleep(1);
// Commit the transaction.
tx.commitAsync().get();
}
{code}
On step "Stop me" you should suspend all the thread on the server side to
emulate the networking problem or long GC pause on the server side.
Finally, you will face in client node next:
{code:java}
[2018-10-10 16:46:10,157][ERROR][nio-acceptor-tcp-comm-#28%GRIDC1%][root]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
[type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker
[name=grid-timeout-worker, igniteInstanceName=GRIDC1, finished=false,
heartbeatTs=1539179057570]]]
{code}
Also, the similar issue could be reproduced in 2.4. In both cases looks like we
have a deadlock during trying to display the TxEntryValueHolder. Looks like
this values are already used by the transaction with long DefaultTxTimeout .
{code:java}
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Unsafe.java:-1)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata0(CacheObjectBinaryProcessorImpl.java:526)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:510)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:193)
at
org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1265)
at org.apache.ignite.internal.binary.BinaryUtils.type(BinaryUtils.java:2407)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.rawType(BinaryObjectImpl.java:302)
at
org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:205)
at
org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:186)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.toString(BinaryObjectImpl.java:919)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at
org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.toString(TxEntryValueHolder.java:161)
...{code}
On the client side, it could be looked like a hanging transaction because we
waiting on:
{code:java}
tx.commitAsync().get();{code}
was:
Steps to reproduce:
1)Start the server node with next timeouts. DefaultTxTimeout should be greater
than other:
{code:java}
{code}
On the server side you should create a cache with next parameters:
{code:java}
{code}
2)After that start the client with the next code:
{code:java}
IgniteCache cache = dr1Hub.getOrCreateCache("LITARGETINFO");
try (Transaction tx = dr1Hub.transactions().txStart()) {
cache.put("Key", new Object());
System.out.println("Stop me");
//here we will get long GC pause on server side
Thread.sleep(1);
// Commit the transaction.
tx.commitAsync().get();
}
{code}
On step "Stop me" you should suspend all the thread on the server side to
emulate the networking problem or long GC pause on the server side.
Finally, you will face in client node next:
{code:java}
[2018-10-10 16:46:10,157][ERROR][nio-acceptor-tcp-comm-#28%GRIDC1%][root]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
[type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker
[name=grid-timeout-worker, igniteInstanceName=GRIDC1, finished=false,
heartbeatTs=1539179057570]]]
{code}
Also, the similar issue could be reproduced in
[jira] [Created] (IGNITE-9840) Possible deadlock on transactional future on client node in case of network problems or long GC pauses
Andrey Aleksandrov created IGNITE-9840:
--
Summary: Possible deadlock on transactional future on client node
in case of network problems or long GC pauses
Key: IGNITE-9840
URL: https://issues.apache.org/jira/browse/IGNITE-9840
Project: Ignite
Issue Type: Bug
Components: clients
Affects Versions: 2.6
Reporter: Andrey Aleksandrov
Fix For: 2.8
Steps to reproduce:
1)Start the server node with next timeouts. DefaultTxTimeout should be greater
than other:
{code:java}
{code}
On the server side you should create a cache with next parameters:
{code:java}
{code}
2)After that start the client with the next code:
{code:java}
IgniteCache cache = dr1Hub.getOrCreateCache("LITARGETINFO");
try (Transaction tx = dr1Hub.transactions().txStart()) {
cache.put("Key", new Object());
System.out.println("Stop me");
//here we will get long GC pause on server side
Thread.sleep(1);
// Commit the transaction.
tx.commitAsync().get();
}
{code}
On step "Stop me" you should suspend all the thread on the server side to
emulate the networking problem or long GC pause on the server side.
Finally, you will face in client node next:
{code:java}
[2018-10-10 16:46:10,157][ERROR][nio-acceptor-tcp-comm-#28%GRIDC1%][root]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
[type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker
[name=grid-timeout-worker, igniteInstanceName=GRIDC1, finished=false,
heartbeatTs=1539179057570]]]
{code}
Also, the similar issue could be reproduced in 2.4. In both cases looks like we
have a deadlock during trying to display the TxEntryValueHolder. Looks like
this values are already used by the transaction with long DefaultTxTimeout .
{code:java}
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Unsafe.java:-1)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata0(CacheObjectBinaryProcessorImpl.java:526)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:510)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:193)
at
org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1265)
at org.apache.ignite.internal.binary.BinaryUtils.type(BinaryUtils.java:2407)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.rawType(BinaryObjectImpl.java:302)
at
org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:205)
at
org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:186)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.toString(BinaryObjectImpl.java:919)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at
org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.toString(TxEntryValueHolder.java:161)
...{code}
On the client side, it could be looked like a hanging transaction because we
waiting on:
{code:java}
tx.commitAsync().get();{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9652) Fix `Missorted modifiers' according inspections profile`
[ https://issues.apache.org/jira/browse/IGNITE-9652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645025#comment-16645025 ] Dmitriy Pavlov commented on IGNITE-9652: I agree, why not to improve code in other modules. We can apply these changes now and process remaining changes in a separate ticket. > Fix `Missorted modifiers' according inspections profile` > > > Key: IGNITE-9652 > URL: https://issues.apache.org/jira/browse/IGNITE-9652 > Project: Ignite > Issue Type: Bug >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Minor > Labels: inspections > Fix For: 2.8 > > > New `Code Inspections` profile can be found > \idea\ignite_inspections.xml. > We need to fix rule `Missorted modifiers` in ignite-core module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9126) Update Apache Kafka dependency
[ https://issues.apache.org/jira/browse/IGNITE-9126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645015#comment-16645015 ] Dmitriy Pavlov commented on IGNITE-9126: Folks, I sill appreciate if someday you can review, even in CTR mode :) > Update Apache Kafka dependency > -- > > Key: IGNITE-9126 > URL: https://issues.apache.org/jira/browse/IGNITE-9126 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Maxim Pudov >Priority: Major > Fix For: 2.7 > > > It is suggested to update kafka in accordance with scala update, e.g. to > https://mvnrepository.com/artifact/org.apache.kafka/kafka_2.11/1.0.2 > or to Kafka 1.1.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9126) Update Apache Kafka dependency
[ https://issues.apache.org/jira/browse/IGNITE-9126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645012#comment-16645012 ] ASF GitHub Bot commented on IGNITE-9126: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4909 > Update Apache Kafka dependency > -- > > Key: IGNITE-9126 > URL: https://issues.apache.org/jira/browse/IGNITE-9126 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Maxim Pudov >Priority: Major > Fix For: 2.7 > > > It is suggested to update kafka in accordance with scala update, e.g. to > https://mvnrepository.com/artifact/org.apache.kafka/kafka_2.11/1.0.2 > or to Kafka 1.1.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9550) Get operation returns null for a lost partition with READ_SAFE policy
[ https://issues.apache.org/jira/browse/IGNITE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644994#comment-16644994 ] ASF GitHub Bot commented on IGNITE-9550: GitHub user dgovorukhin opened a pull request: https://github.com/apache/ignite/pull/4947 IGNITE-9550 Get operation returns null for a lost partition with READ_SAFE policy You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9550-dg Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4947.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 #4947 commit 89b4fc6b56743f580a461fe699d318ad142d7012 Author: Dmitriy Govorukhin Date: 2018-10-10T13:54:16Z IGNITE-9550 Fix Get operation returns null for a lost partition with READ_SAFE policy > Get operation returns null for a lost partition with READ_SAFE policy > - > > Key: IGNITE-9550 > URL: https://issues.apache.org/jira/browse/IGNITE-9550 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Pavel Vinokurov >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.8 > > Attachments: PartitionLostReproducer.java > > > See reproduced attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9724) MVCC SQL: Test CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed hangs sporadically.
[ https://issues.apache.org/jira/browse/IGNITE-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9724: Ignite Flags: (was: Docs Required) > MVCC SQL: Test > CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed > hangs sporadically. > --- > > Key: IGNITE-9724 > URL: https://issues.apache.org/jira/browse/IGNITE-9724 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Andrew Mashenkov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.7 > > Attachments: hanging.txt > > > CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed() > hangs sporadically with PME. > Exchange thread is waiting for partition released > Query threads are waiting for TxTopologyVersionFuture. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9724) MVCC SQL: Test CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed hangs sporadically.
[ https://issues.apache.org/jira/browse/IGNITE-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644977#comment-16644977 ] Vladimir Ozerov commented on IGNITE-9724: - This appears to be purely test problem - it is organized in way when we open transaction, then start several other transactions in separate threads, and then wait for them synchronously. Is exchange is to happen between current and child transactions, test will hang (TX <- PME <- CHILD TXes <- TX). > MVCC SQL: Test > CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed > hangs sporadically. > --- > > Key: IGNITE-9724 > URL: https://issues.apache.org/jira/browse/IGNITE-9724 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Andrew Mashenkov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.7 > > Attachments: hanging.txt > > > CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed() > hangs sporadically with PME. > Exchange thread is waiting for partition released > Query threads are waiting for TxTopologyVersionFuture. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9724) MVCC SQL: Test CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed hangs sporadically.
[ https://issues.apache.org/jira/browse/IGNITE-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-9724: --- Assignee: Vladimir Ozerov (was: Igor Seliverstov) > MVCC SQL: Test > CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed > hangs sporadically. > --- > > Key: IGNITE-9724 > URL: https://issues.apache.org/jira/browse/IGNITE-9724 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Andrew Mashenkov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.7 > > Attachments: hanging.txt > > > CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed() > hangs sporadically with PME. > Exchange thread is waiting for partition released > Query threads are waiting for TxTopologyVersionFuture. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9771) Indirect SQL queries are failing
[ https://issues.apache.org/jira/browse/IGNITE-9771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644974#comment-16644974 ] Sergey Grimstad commented on IGNITE-9771: - h1. build #4946 > Indirect SQL queries are failing > > > Key: IGNITE-9771 > URL: https://issues.apache.org/jira/browse/IGNITE-9771 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Grimstad >Assignee: Sergey Grimstad >Priority: Major > Fix For: 2.8 > > > Attempt to sql query (not sql fields query ) another cache's type leads to > exception: > Caused by: class > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to > find SQL table for type: ... > IgniteH2Indexing#queryDistributedSql in the beginning of the method logic > there is check of schemaName, cacheName and type. First two parameters passed > belong to called cache while third belongs to target cache. This combination > leads to the exception mentioned. > # Create tests to reproduce the situation > # Fix problem > # Enable commented out tests with 'todo' and this ticket number reference -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9724) MVCC SQL: Test CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed hangs sporadically.
[ https://issues.apache.org/jira/browse/IGNITE-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-9724: --- Assignee: Igor Seliverstov > MVCC SQL: Test > CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed > hangs sporadically. > --- > > Key: IGNITE-9724 > URL: https://issues.apache.org/jira/browse/IGNITE-9724 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Andrew Mashenkov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > Attachments: hanging.txt > > > CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed() > hangs sporadically with PME. > Exchange thread is waiting for partition released > Query threads are waiting for TxTopologyVersionFuture. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9292) MVCC SQL: Unexpected state exception when updating backup
[
https://issues.apache.org/jira/browse/IGNITE-9292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-9292:
---
Assignee: Igor Seliverstov
> MVCC SQL: Unexpected state exception when updating backup
> -
>
> Key: IGNITE-9292
> URL: https://issues.apache.org/jira/browse/IGNITE-9292
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Ivan Pavlukhin
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.7
>
> Attachments: MvccInsertUpdateConcurrent.java
>
>
> Unexpected state exception is observed during concurrent execution insert and
> fast update for same key.
> One of observed with concurrent update and insert for the same key from the
> same node serializes as follows:
> 1. insert on primary
> 2. insert on backup
> 3. update on primary waits on lock
> 4. insert is prepared on backup
> 5. insert is prepared on primary
> 6. insert is committed on primary (before committing on backup)
> 7. update waiting on lock wakes up
> 8. update is executed on primary
> 9. update fails on backup because sees inserted row in prepared state
> It is one possible erroneous scenario. There might be others. TX log update
> procedure should be thoroughly reviewed.
> {noformat}
> [2018-08-16
> 16:32:25,452][ERROR][ForkJoinPool.commonPool-worker-2][DmlStatementsProcessor]
> Error during update [localNodeId=6709af72-2fe9-4eab-9ee5-be83eab0]
> class org.apache.ignite.IgniteCheckedException: Failed to update backup node:
> [localNodeId=6709af72-2fe9-4eab-9ee5-be83eab0,
> remoteNodeId=4ca5b185-c5d1-4756-8977-e57aec31]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:931)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2245)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1000(GridDhtTransactionalCacheAdapter.java:106)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$16.apply(GridDhtTransactionalCacheAdapter.java:237)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$16.apply(GridDhtTransactionalCacheAdapter.java:235)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:496)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Runtime failure on
> bounds: [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1047)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1887)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:523)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1080)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxRemote.mvccEnlistBatch(GridDhtTxRemote.java:451)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistRequest(GridDhtTransactionalCacheAdapter.java:2209)
> at
>
[jira] [Commented] (IGNITE-9292) MVCC SQL: Unexpected state exception when updating backup
[
https://issues.apache.org/jira/browse/IGNITE-9292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644963#comment-16644963
]
Vladimir Ozerov commented on IGNITE-9292:
-
Or alternatively - move TX log update call to later stage, when finish future
is done.
> MVCC SQL: Unexpected state exception when updating backup
> -
>
> Key: IGNITE-9292
> URL: https://issues.apache.org/jira/browse/IGNITE-9292
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.7
>
> Attachments: MvccInsertUpdateConcurrent.java
>
>
> Unexpected state exception is observed during concurrent execution insert and
> fast update for same key.
> One of observed with concurrent update and insert for the same key from the
> same node serializes as follows:
> 1. insert on primary
> 2. insert on backup
> 3. update on primary waits on lock
> 4. insert is prepared on backup
> 5. insert is prepared on primary
> 6. insert is committed on primary (before committing on backup)
> 7. update waiting on lock wakes up
> 8. update is executed on primary
> 9. update fails on backup because sees inserted row in prepared state
> It is one possible erroneous scenario. There might be others. TX log update
> procedure should be thoroughly reviewed.
> {noformat}
> [2018-08-16
> 16:32:25,452][ERROR][ForkJoinPool.commonPool-worker-2][DmlStatementsProcessor]
> Error during update [localNodeId=6709af72-2fe9-4eab-9ee5-be83eab0]
> class org.apache.ignite.IgniteCheckedException: Failed to update backup node:
> [localNodeId=6709af72-2fe9-4eab-9ee5-be83eab0,
> remoteNodeId=4ca5b185-c5d1-4756-8977-e57aec31]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:931)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2245)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1000(GridDhtTransactionalCacheAdapter.java:106)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$16.apply(GridDhtTransactionalCacheAdapter.java:237)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$16.apply(GridDhtTransactionalCacheAdapter.java:235)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:496)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Runtime failure on
> bounds: [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1047)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1887)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:523)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1080)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxRemote.mvccEnlistBatch(GridDhtTxRemote.java:451)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistRequest(GridDhtTransactionalCacheAdapter.java:2209)
> at
>
[jira] [Commented] (IGNITE-9292) MVCC SQL: Unexpected state exception when updating backup
[
https://issues.apache.org/jira/browse/IGNITE-9292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644939#comment-16644939
]
Vladimir Ozerov commented on IGNITE-9292:
-
[~Pavlukhin], [~gvvinblade],
Apparently, the problem is caused by too early waiter notification. It seems
that the fix is to move waiter remove/notification logic out of
{{MvccProcessorImpl.updateState(MvccVersion, byte, boolean)}} method into a
separate method, which should be called from finish future onDone() callback.
What do you think?
> MVCC SQL: Unexpected state exception when updating backup
> -
>
> Key: IGNITE-9292
> URL: https://issues.apache.org/jira/browse/IGNITE-9292
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.7
>
> Attachments: MvccInsertUpdateConcurrent.java
>
>
> Unexpected state exception is observed during concurrent execution insert and
> fast update for same key.
> One of observed with concurrent update and insert for the same key from the
> same node serializes as follows:
> 1. insert on primary
> 2. insert on backup
> 3. update on primary waits on lock
> 4. insert is prepared on backup
> 5. insert is prepared on primary
> 6. insert is committed on primary (before committing on backup)
> 7. update waiting on lock wakes up
> 8. update is executed on primary
> 9. update fails on backup because sees inserted row in prepared state
> It is one possible erroneous scenario. There might be others. TX log update
> procedure should be thoroughly reviewed.
> {noformat}
> [2018-08-16
> 16:32:25,452][ERROR][ForkJoinPool.commonPool-worker-2][DmlStatementsProcessor]
> Error during update [localNodeId=6709af72-2fe9-4eab-9ee5-be83eab0]
> class org.apache.ignite.IgniteCheckedException: Failed to update backup node:
> [localNodeId=6709af72-2fe9-4eab-9ee5-be83eab0,
> remoteNodeId=4ca5b185-c5d1-4756-8977-e57aec31]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:931)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2245)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1000(GridDhtTransactionalCacheAdapter.java:106)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$16.apply(GridDhtTransactionalCacheAdapter.java:237)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$16.apply(GridDhtTransactionalCacheAdapter.java:235)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:496)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Runtime failure on
> bounds: [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1047)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1887)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:523)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1080)
> at
>
[jira] [Comment Edited] (IGNITE-9824) Thin clients benches
[ https://issues.apache.org/jira/browse/IGNITE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644926#comment-16644926 ] Stepan Pilschikov edited comment on IGNITE-9824 at 10/10/18 1:09 PM: - To clerify benches results was applied new test strategy bench case: - Clear nodes work directory - Run ignite on first host (1 or 3 nodes) - Run metric collector script on first host [code|https://gist.github.com/pilshchikov/feed72bab1751d153f27a12011a86a6d] - Run on of new benches on second host: -- [NodeJS|https://gist.github.com/pilshchikov/1b4cad3bf8f933519e4724e148b1d9ac] -- [Python|https://gist.github.com/pilshchikov/397e4f740df7d981c1937ad0471a13db] -- [PHP|https://gist.github.com/pilshchikov/0240092de20064a4ffe9a14bfe267877] -- [JAVA|https://gist.github.com/pilshchikov/807176afab27293ef2d3490c653e009b] Env: - hosts located in same network - benches running several times (results are equals) and taken best one - hosts: Ubuntu 16, 16 CPU, 96 Gb RAM Results: - [^thin_clients_bench_results_v2.pdf] was (Author: spilschikov): To clerify benches results was applied new test strategy bench case: - Clear nodes work directory - Run ignite on first host (1 or 3 nodes) - Run metric collector script on first host [code|https://gist.github.com/pilshchikov/feed72bab1751d153f27a12011a86a6d] - Run on of new benches on second host: -- [NodeJS|https://gist.github.com/pilshchikov/1b4cad3bf8f933519e4724e148b1d9ac] -- [Python|https://gist.github.com/pilshchikov/397e4f740df7d981c1937ad0471a13db] -- [PHP|https://gist.github.com/pilshchikov/0240092de20064a4ffe9a14bfe267877] -- [JAVA|https://gist.github.com/pilshchikov/807176afab27293ef2d3490c653e009b] Env: - hosts located in same network - benches running several times (results are equals) and teked best one - hosts: Ubuntu 16, 16 CPU, 96 Gb RAM Results: - [^thin_clients_bench_results_v2.pdf] > Thin clients benches > > > Key: IGNITE-9824 > URL: https://issues.apache.org/jira/browse/IGNITE-9824 > Project: Ignite > Issue Type: Test > Components: thin client > Environment: Ignite 2.7 > Java 8 > NodeJS 10.+ > PHP 7.2.7 > Python 3.6 >Reporter: Stepan Pilschikov >Priority: Major > Attachments: thin_clients_bench_results.pdf, > thin_clients_bench_results_v2.pdf > > > Benchmarks for all existed ignite thin clients > Case: > - Running 1 or 3 nodes on first host > - Running code on second host > Code: > - > [NodeJS|https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447] > - [PHP|https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80] > - > [Python|https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb] > - [Java|https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce] > Results in attachments -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9685) [ML] Add ignite-tensorflow module to build artifacts
[ https://issues.apache.org/jira/browse/IGNITE-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644930#comment-16644930 ] ASF GitHub Bot commented on IGNITE-9685: GitHub user vveider opened a pull request: https://github.com/apache/ignite/pull/4945 IGNITE-9685 [ML] Add ignite-tensorflow module to build artifacts You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9685 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4945.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 #4945 commit c96dc89089dd5312234a5832d7fc1a453ec5fe9b Author: Peter Ivanov Date: 2018-10-10T12:56:54Z IGNITE-9685 [ML] Add ignite-tensorflow module to build artifacts > [ML] Add ignite-tensorflow module to build artifacts > > > Key: IGNITE-9685 > URL: https://issues.apache.org/jira/browse/IGNITE-9685 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.7 > > > We want to release Apache Ignite TensorFlow Integration Module with other > Ignite tools. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9770) Re-run possible blockers from pr.html
[ https://issues.apache.org/jira/browse/IGNITE-9770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-9770. Resolution: Fixed [~zzzadruga] thank you for contribution. Merged to master and deployed to server. > Re-run possible blockers from pr.html > - > > Key: IGNITE-9770 > URL: https://issues.apache.org/jira/browse/IGNITE-9770 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolai Kulagin >Assignee: Nikolai Kulagin >Priority: Minor > > Show button for re-run possible blockers. Also show merged button with re-run > possible blockers JIRA, so the user re-run the possible tests and > does not wait for them to complete,but learn about the completed tests from > the comment to GitHib. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9824) Thin clients benches
[ https://issues.apache.org/jira/browse/IGNITE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644926#comment-16644926 ] Stepan Pilschikov commented on IGNITE-9824: --- To clerify benches results was applied new test strategy bench case: - Clear nodes work directory - Run ignite on first host (1 or 3 nodes) - Run metric collector script on first host [code|https://gist.github.com/pilshchikov/feed72bab1751d153f27a12011a86a6d] - Run on of new benches on second host: -- [NodeJS|https://gist.github.com/pilshchikov/1b4cad3bf8f933519e4724e148b1d9ac] -- [Python|https://gist.github.com/pilshchikov/397e4f740df7d981c1937ad0471a13db] -- [PHP|https://gist.github.com/pilshchikov/0240092de20064a4ffe9a14bfe267877] -- [JAVA|https://gist.github.com/pilshchikov/807176afab27293ef2d3490c653e009b] Env: - hosts located in same network - benches running several times (results are equals) and teked best one - hosts: Ubuntu 16, 16 CPU, 96 Gb RAM Results: - [^thin_clients_bench_results_v2.pdf] > Thin clients benches > > > Key: IGNITE-9824 > URL: https://issues.apache.org/jira/browse/IGNITE-9824 > Project: Ignite > Issue Type: Test > Components: thin client > Environment: Ignite 2.7 > Java 8 > NodeJS 10.+ > PHP 7.2.7 > Python 3.6 >Reporter: Stepan Pilschikov >Priority: Major > Attachments: thin_clients_bench_results.pdf, > thin_clients_bench_results_v2.pdf > > > Benchmarks for all existed ignite thin clients > Case: > - Running 1 or 3 nodes on first host > - Running code on second host > Code: > - > [NodeJS|https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447] > - [PHP|https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80] > - > [Python|https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb] > - [Java|https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce] > Results in attachments -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9430) Add ability to override all caches's "rebalanceThrottle" option via JVM node option
[ https://issues.apache.org/jira/browse/IGNITE-9430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644925#comment-16644925 ] ASF GitHub Bot commented on IGNITE-9430: GitHub user macrergate opened a pull request: https://github.com/apache/ignite/pull/4944 IGNITE-9430 Introduce IGNITE_REBALANCE_THROTTLE_OVERRIDE system property You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9430 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4944.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 #4944 commit e6cdcd9cddb9af2de30df8399d84e2f226ac0e48 Author: macrergate Date: 2018-10-10T12:44:31Z IGNITE-9430 Introduce IGNITE_REBALANCE_THROTTLE_OVERRIDE system property > Add ability to override all caches's "rebalanceThrottle" option via JVM node > option > > > Key: IGNITE-9430 > URL: https://issues.apache.org/jira/browse/IGNITE-9430 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.5 >Reporter: ARomantsov >Assignee: Sergey Kosarev >Priority: Major > Fix For: 2.8 > > > I found ability to set rebalanceThrottle option for any cache , but can we > have JVM key for override that parameter for all caches at once -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9824) Thin clients benches
[ https://issues.apache.org/jira/browse/IGNITE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepan Pilschikov updated IGNITE-9824: -- Attachment: thin_clients_bench_results_v2.pdf > Thin clients benches > > > Key: IGNITE-9824 > URL: https://issues.apache.org/jira/browse/IGNITE-9824 > Project: Ignite > Issue Type: Test > Components: thin client > Environment: Ignite 2.7 > Java 8 > NodeJS 10.+ > PHP 7.2.7 > Python 3.6 >Reporter: Stepan Pilschikov >Priority: Major > Attachments: thin_clients_bench_results.pdf, > thin_clients_bench_results_v2.pdf > > > Benchmarks for all existed ignite thin clients > Case: > - Running 1 or 3 nodes on first host > - Running code on second host > Code: > - > [NodeJS|https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447] > - [PHP|https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80] > - > [Python|https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb] > - [Java|https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce] > Results in attachments -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9800) Ignite TC bot: Simplify initial PR search and main navigation path for checking contribution
[ https://issues.apache.org/jira/browse/IGNITE-9800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-9800. Resolution: Fixed Done in V20181010. More UI improvement may be done later for particular contribution check > Ignite TC bot: Simplify initial PR search and main navigation path for > checking contribution > > > Key: IGNITE-9800 > URL: https://issues.apache.org/jira/browse/IGNITE-9800 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > > Show list of open PRs and provide an easy way to search PR or ticket. > Show a reasonably simple index page with just a number of major use cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9550) Get operation returns null for a lost partition with READ_SAFE policy
[ https://issues.apache.org/jira/browse/IGNITE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644909#comment-16644909 ] ASF GitHub Bot commented on IGNITE-9550: Github user dgovorukhin closed the pull request at: https://github.com/apache/ignite/pull/4856 > Get operation returns null for a lost partition with READ_SAFE policy > - > > Key: IGNITE-9550 > URL: https://issues.apache.org/jira/browse/IGNITE-9550 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Pavel Vinokurov >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.8 > > Attachments: PartitionLostReproducer.java > > > See reproduced attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9550) Get operation returns null for a lost partition with READ_SAFE policy
[ https://issues.apache.org/jira/browse/IGNITE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644908#comment-16644908 ] ASF GitHub Bot commented on IGNITE-9550: Github user dgovorukhin closed the pull request at: https://github.com/apache/ignite/pull/4846 > Get operation returns null for a lost partition with READ_SAFE policy > - > > Key: IGNITE-9550 > URL: https://issues.apache.org/jira/browse/IGNITE-9550 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Pavel Vinokurov >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.8 > > Attachments: PartitionLostReproducer.java > > > See reproduced attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9829) Add validation errors distinction to TcpDiscoveryCheckFailedMessage
[ https://issues.apache.org/jira/browse/IGNITE-9829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov updated IGNITE-9829: Summary: Add validation errors distinction to TcpDiscoveryCheckFailedMessage (was: Add validation error distinction to TcpDiscoveryCheckFailedMessage) > Add validation errors distinction to TcpDiscoveryCheckFailedMessage > --- > > Key: IGNITE-9829 > URL: https://issues.apache.org/jira/browse/IGNITE-9829 > Project: Ignite > Issue Type: Improvement > Components: messaging >Reporter: Alexey Platonov >Priority: Major > Fix For: 3.0 > > > There is no way to define validation error type during joining on client side > after node validation on server side. TcpDiscoveryCheckFailedMessage just > aggregates error messages to one string. For example: if there was auth error > while joining then client receive TcpDiscoveryCheckFailedMessage instead of > TcpDiscoveryAuthFailedMessage. This is due to server validation protocol > supports just IgniteNodeValidationResult as string-wrapper without additional > information about types of validation errors. Set of enum values representing > validation errors may be good solution. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644907#comment-16644907 ] Alexey Platonov commented on IGNITE-9726: - [~SomeFire] [https://ci.ignite.apache.org/viewQueued.html?itemId=2051547] > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646=IgniteTests24Java8_CacheFailover2=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue in test > testOptimisticSerializableTxConstantTopologyChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644903#comment-16644903 ] Ryabov Dmitrii commented on IGNITE-9726: They could appear in random commit and looks like they are fixed, because they don't fail in the master. So, master refresh will remove them from [blockers|https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll==pull%2F4859%2Fhead=Latest]. > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646=IgniteTests24Java8_CacheFailover2=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue in test > testOptimisticSerializableTxConstantTopologyChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644899#comment-16644899 ] Alexey Platonov commented on IGNITE-9726: - [~SomeFire] I have pulled master but I don't understand how failed test in this suites are related with my pull-request. It seems to these fails was due to some other reasons. > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646=IgniteTests24Java8_CacheFailover2=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue in test > testOptimisticSerializableTxConstantTopologyChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9834) ClientImpl shouldn't fail JVM with 130 error code after node validation errors
[ https://issues.apache.org/jira/browse/IGNITE-9834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644854#comment-16644854 ] Alexey Platonov edited comment on IGNITE-9834 at 10/10/18 12:13 PM: It doesn't look like tests above was failed by my code. Maybe this is new errors. was (Author: aplatonov): It doesn't look like above tests was failed by my code. Maybe this is new errors. > ClientImpl shouldn't fail JVM with 130 error code after node validation errors > -- > > Key: IGNITE-9834 > URL: https://issues.apache.org/jira/browse/IGNITE-9834 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > In the current number of Ignite if client (tcp-client-disco-msg-worker) > receive validation error message represented by > TcpDiscoveryCheckFailedMessage then client fail with 130 error code. > Semantically such behavior is invalid. Client must cancel own work in normal > order. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9652) Fix `Missorted modifiers' according inspections profile`
[ https://issues.apache.org/jira/browse/IGNITE-9652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644893#comment-16644893 ] Nikolay Izhikov commented on IGNITE-9652: - [~Mmuzaf], [~dpavlov] LGTM. But, I propose to fix this issue all over the project. Not only core module. What do you think? > Fix `Missorted modifiers' according inspections profile` > > > Key: IGNITE-9652 > URL: https://issues.apache.org/jira/browse/IGNITE-9652 > Project: Ignite > Issue Type: Bug >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Minor > Labels: inspections > Fix For: 2.8 > > > New `Code Inspections` profile can be found > \idea\ignite_inspections.xml. > We need to fix rule `Missorted modifiers` in ignite-core module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9781) JDK11: SSL handshake is failed
[
https://issues.apache.org/jira/browse/IGNITE-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9781:
Fix Version/s: (was: 2.7)
2.8
> JDK11: SSL handshake is failed
> --
>
> Key: IGNITE-9781
> URL: https://issues.apache.org/jira/browse/IGNITE-9781
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
> Environment: JDK11
>Reporter: Taras Ledkov
>Priority: Major
> Labels: jdk11
> Fix For: 2.8
>
>
> The problem is reproduced on JDK11 by the test
> {{GridNioSslSelfTest.testSimpleMessages}}
> Error on the Ignite node
> {code}
> [2018-10-03 14:35:08,033][ERROR][grid-nio-worker-0-#42%nio-test-grid%][root]
> Closing NIO session because of unhandled exception.
> class org.apache.ignite.internal.util.nio.GridNioException: No value present
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2412)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2153)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1797)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.util.NoSuchElementException: No value present
> at java.base/java.util.Optional.get(Optional.java:148)
> at
> java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:551)
> at
> java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
> at
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1189)
> at
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1125)
> at
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:831)
> at
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:792)
> at
> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
> at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1065)
> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1052)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:999)
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.runTasks(GridNioSslHandler.java:624)
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.handshake(GridNioSslHandler.java:243)
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.messageReceived(GridNioSslHandler.java:321)
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.onMessageReceived(GridNioSslFilter.java:330)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3547)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1132)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2386)
> ... 4 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9781) JDK11: SSL handshake is failed
[
https://issues.apache.org/jira/browse/IGNITE-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644887#comment-16644887
]
Vladimir Ozerov commented on IGNITE-9781:
-
Moving to AI 2.8. Root cause and impact are not clear.
> JDK11: SSL handshake is failed
> --
>
> Key: IGNITE-9781
> URL: https://issues.apache.org/jira/browse/IGNITE-9781
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
> Environment: JDK11
>Reporter: Taras Ledkov
>Priority: Major
> Labels: jdk11
> Fix For: 2.8
>
>
> The problem is reproduced on JDK11 by the test
> {{GridNioSslSelfTest.testSimpleMessages}}
> Error on the Ignite node
> {code}
> [2018-10-03 14:35:08,033][ERROR][grid-nio-worker-0-#42%nio-test-grid%][root]
> Closing NIO session because of unhandled exception.
> class org.apache.ignite.internal.util.nio.GridNioException: No value present
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2412)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2153)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1797)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.util.NoSuchElementException: No value present
> at java.base/java.util.Optional.get(Optional.java:148)
> at
> java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:551)
> at
> java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
> at
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1189)
> at
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1125)
> at
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:831)
> at
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:792)
> at
> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
> at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1065)
> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1052)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:999)
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.runTasks(GridNioSslHandler.java:624)
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.handshake(GridNioSslHandler.java:243)
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.messageReceived(GridNioSslHandler.java:321)
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.onMessageReceived(GridNioSslFilter.java:330)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3547)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1132)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2386)
> ... 4 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644882#comment-16644882 ] Ryabov Dmitrii edited comment on IGNITE-9726 at 10/10/18 11:57 AM: --- [~aplatonov], please, pull the master and check [this tests|https://ci.ignite.apache.org/viewLog.html?buildId=2034563]. was (Author: somefire): [~aplatonov], check [this tests|https://ci.ignite.apache.org/viewLog.html?buildId=2034563]. > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646=IgniteTests24Java8_CacheFailover2=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue in test > testOptimisticSerializableTxConstantTopologyChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644882#comment-16644882 ] Ryabov Dmitrii commented on IGNITE-9726: [~aplatonov], check [this tests|https://ci.ignite.apache.org/viewLog.html?buildId=2034563]. > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646=IgniteTests24Java8_CacheFailover2=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue in test > testOptimisticSerializableTxConstantTopologyChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9805) Make line graphs with animation
[
https://issues.apache.org/jira/browse/IGNITE-9805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644880#comment-16644880
]
ASF GitHub Bot commented on IGNITE-9805:
asfgit closed pull request #30: IGNITE-9805 Animation v1
URL: https://github.com/apache/ignite-teamcity-bot/pull/30
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/ignite-tc-helper-web/src/main/webapp/comparison.html
b/ignite-tc-helper-web/src/main/webapp/comparison.html
index 7868f64..bc24084 100644
--- a/ignite-tc-helper-web/src/main/webapp/comparison.html
+++ b/ignite-tc-helper-web/src/main/webapp/comparison.html
@@ -4,12 +4,13 @@
Ignite Teamcity - comparison master's branch in the date
interval
-https://code.jquery.com/ui/1.12.1/themes/base/jquery-ui.css;>
-
-https://cdn.jsdelivr.net/jquery/latest/jquery.min.js";>
+https://code.jquery.com/jquery-1.12.4.js";>
+https://code.jquery.com/ui/1.12.1/jquery-ui.js";>
https://cdn.jsdelivr.net/momentjs/latest/moment.min.js";>
https://cdn.jsdelivr.net/npm/daterangepicker/daterangepicker.min.js";>
https://cdn.jsdelivr.net/npm/daterangepicker/daterangepicker.css; />
+
+https://code.jquery.com/ui/1.12.1/themes/base/jquery-ui.css;>
https://d3js.org/d3.v4.min.js";>
@@ -182,6 +183,7 @@
let statistics = {};
let dates = [];
+let buildIds = [];
for (let i = 0; i < prOcc.length; i++) {
statistics[prOcc[i]] = [];
@@ -190,6 +192,7 @@
for (let j = 0; j < map.length; j++) {
dates[j] = parseTime(map[j].startDate);
+buildIds[j] = map[j].buildId;
for (let i = 0; i < prOcc.length; i++) {
statistics[prOcc[i]][j] = map[j].totalProblems[prOcc[i]];
@@ -221,19 +224,19 @@
$('.title' + num).html('min - median - max');
for (let i = 0; i < prOcc.length; i++) {
-fillCellWithStatistics(prOcc[i], num, statistics, dates);
-fillCellWithStatistics(tOcc[i], num, statistics, dates);
+fillCellWithStatistics(prOcc[i], num, statistics, dates, buildIds);
+fillCellWithStatistics(tOcc[i], num, statistics, dates, buildIds);
}
}
-function fillCellWithStatistics(prefix, num, statistics, dates) {
+function fillCellWithStatistics(prefix, num, statistics, dates, buildIds) {
let result = getMinMaxMedian(statistics[prefix]);
$('#' + prefix + num).html(result.min + " - " + result.median + " - "
+ result.max);
compareAndHighlight(prefix, num, result.median);
-drawGraph(prefix, num, dates, statistics[prefix], prefix);
+drawGraph(prefix, num, dates, statistics[prefix], buildIds);
}
function compareAndHighlight(prefix, thisNum, thisMedian){
@@ -346,49 +349,58 @@
});
}
-function drawGraph(prefix, num, dates, counts, text) {
+function drawGraph(prefix, num, dates, counts, buildIds) {
let data = [];
for (let i = 0; i < dates.length; i++) {
data[i] = {};
data[i].date = dates[i];
-data[i].count = counts[i];
+data[i].value = counts[i];
+data[i].buildId = buildIds[i];
}
-svg = d3.select("#graph" + prefix + num).append("svg:svg");
-margin = {top: 20, right: 20, bottom: 30, left: 50};
-width = +500 - margin.left - margin.right;
-height = +200 - margin.top - margin.bottom;
-g = svg.append("g").attr("transform", "translate(" + margin.left + ","
+ margin.top + ")");
-x = d3.scaleTime().range([0, width]);
-y = d3.scaleLinear().range([height, 0]);
+let svg = d3.select("#graph" + prefix + num).append("svg:svg");
+let margin = {top: 20, right: 20, bottom: 30, left: 50};
+let width = +500 - margin.left - margin.right;
+let height = +200 - margin.top - margin.bottom;
+let g = svg.append("g").attr("transform", "translate(" + margin.left +
"," + margin.top + ")");
-line = d3.line()
-.curve(d3.curveBasis)
-.x(function(d) { return x(d.date); })
-.y(function(d) { return y(d.count); });
+let div = d3.select("body").append("div")
+.attr("class", "tooltip")
+.style("opacity", 0);
+
+let formatTime = d3.timeFormat("%d-%m-%Y %H:%M:%S");
+let max = d3.max(data, function(d){return parseInt(d.value)});
+let y = d3.scaleLinear()
+.domain([0, max])
+.range([height, 0]);
+let x = d3.scaleTime()
+.rangeRound([0, width]);
[jira] [Updated] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov updated IGNITE-9726: Fix Version/s: (was: 2.7) 2.8 > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646=IgniteTests24Java8_CacheFailover2=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue in test > testOptimisticSerializableTxConstantTopologyChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9770) Re-run possible blockers from pr.html
[
https://issues.apache.org/jira/browse/IGNITE-9770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644874#comment-16644874
]
ASF GitHub Bot commented on IGNITE-9770:
asfgit closed pull request #27: IGNITE-9770 Add 'Re-run possible blockers'
button
URL: https://github.com/apache/ignite-teamcity-bot/pull/27
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildInfo.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildInfo.java
deleted file mode 100644
index 9de4dd3..000
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildInfo.java
+++ /dev/null
@@ -1,81 +0,0 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one or more
- * contributor license agreements. See the NOTICE file distributed with
- * this work for additional information regarding copyright ownership.
- * The ASF licenses this file to You under the Apache License, Version 2.0
- * (the "License"); you may not use this file except in compliance with
- * the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-package org.apache.ignite.ci.observer;
-
-import org.apache.ignite.ci.tcmodel.result.Build;
-import org.apache.ignite.ci.user.ICredentialsProv;
-
-/**
- *
- */
-public class BuildInfo {
-/** Build. */
-public final Build build;
-
-/** Server id. */
-public final String srvId;
-
-/** */
-public final ICredentialsProv prov;
-
-/** JIRA ticket full name. */
-public final String ticket;
-
-/**
- * @param build Build.
- * @param srvId Server id.
- * @param prov Credentials.
- * @param ticket JIRA ticket name.
- */
-BuildInfo(Build build, String srvId, ICredentialsProv prov, String ticket)
{
-this.build = build;
-this.srvId = srvId;
-this.prov = prov;
-this.ticket = ticket;
-}
-
-/** {@inheritDoc} */
-@Override public boolean equals(Object o) {
-if (this == o)
-return true;
-if (o == null || getClass() != o.getClass())
-return false;
-
-BuildInfo info = (BuildInfo)o;
-
-if (!build.equals(info.build))
-return false;
-if (!srvId.equals(info.srvId))
-return false;
-if (!prov.equals(info.prov))
-return false;
-
-return ticket.equals(info.ticket);
-}
-
-/** {@inheritDoc} */
-@Override public int hashCode() {
-int res = build.hashCode();
-
-res = 31 * res + srvId.hashCode();
-res = 31 * res + prov.hashCode();
-res = 31 * res + ticket.hashCode();
-
-return res;
-}
-}
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
index 8603d34..a6d302f 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
@@ -54,12 +54,11 @@ public void stop() {
}
/**
- * @param build Build id.
* @param srvId Server id.
* @param prov Credentials.
* @param ticket JIRA ticket name.
*/
-public void observe(Build build, String srvId, ICredentialsProv prov,
String ticket) {
-observerTask.builds.add(new BuildInfo(build, srvId, prov, ticket));
+public void observe(String srvId, ICredentialsProv prov, String ticket,
Build... builds) {
+observerTask.builds.add(new BuildsInfo(srvId, prov, ticket, builds));
}
}
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildsInfo.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildsInfo.java
new file mode 100644
index 000..2dd3060
--- /dev/null
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildsInfo.java
@@ -0,0 +1,116 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the
[jira] [Created] (IGNITE-9839) Web Console: Migrate to new API of RxJS
Alexey Kuznetsov created IGNITE-9839: Summary: Web Console: Migrate to new API of RxJS Key: IGNITE-9839 URL: https://issues.apache.org/jira/browse/IGNITE-9839 Project: Ignite Issue Type: Task Components: wizards Reporter: Alexey Kuznetsov Assignee: Alexander Kalinin We are using old and new API of RxJS. Lets refactor all old usages to new API. New API is more flexible, no more issues with "missing imports" and we will be able to migrate to RxJS 6.x from 5.x. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9839) Web Console: Migrate to new API of RxJS
[ https://issues.apache.org/jira/browse/IGNITE-9839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644862#comment-16644862 ] Alexey Kuznetsov commented on IGNITE-9839: -- [~alexdel], please do refactoring and submit for review to [~Klaster_1]. > Web Console: Migrate to new API of RxJS > --- > > Key: IGNITE-9839 > URL: https://issues.apache.org/jira/browse/IGNITE-9839 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexander Kalinin >Priority: Major > > We are using old and new API of RxJS. > Lets refactor all old usages to new API. > New API is more flexible, no more issues with "missing imports" and we will > be able to migrate to RxJS 6.x from 5.x. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9838) TxStateChangeEventTest fails sometimes on TeamCity
Andrey Kuznetsov created IGNITE-9838: Summary: TxStateChangeEventTest fails sometimes on TeamCity Key: IGNITE-9838 URL: https://issues.apache.org/jira/browse/IGNITE-9838 Project: Ignite Issue Type: Test Reporter: Andrey Kuznetsov Fix For: 2.8 Both test methods may fail to acquire transaction lock. Presumably, timeout increasing can be enough to fix. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9126) Update Apache Kafka dependency
[ https://issues.apache.org/jira/browse/IGNITE-9126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644858#comment-16644858 ] Vladimir Ozerov commented on IGNITE-9126: - [~NIzhikov], [~dpavlov], [~roman_s], Igniters, Please note that today is the last day when we are ready to keep non-blocker tickets on AI 2.7. Otherwise stability of AI 2.7 might be compromised. Please make sure to either merge the ticket today, or move it to the next version. > Update Apache Kafka dependency > -- > > Key: IGNITE-9126 > URL: https://issues.apache.org/jira/browse/IGNITE-9126 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Maxim Pudov >Priority: Major > Fix For: 2.7 > > > It is suggested to update kafka in accordance with scala update, e.g. to > https://mvnrepository.com/artifact/org.apache.kafka/kafka_2.11/1.0.2 > or to Kafka 1.1.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644857#comment-16644857 ] Vladimir Ozerov commented on IGNITE-9726: - [~SomeFire], [~aplatonov], Igniters, Any news on the ticket? Today is the last day when we are ready to keep non-blocker tickets on AI 2.7. Otherwise stability of AI 2.7 might be compromised. Please make sure to either merge the ticket today, or move it to the next version. > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646=IgniteTests24Java8_CacheFailover2=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue in test > testOptimisticSerializableTxConstantTopologyChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9550) Get operation returns null for a lost partition with READ_SAFE policy
[ https://issues.apache.org/jira/browse/IGNITE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9550: Fix Version/s: (was: 2.7) 2.8 > Get operation returns null for a lost partition with READ_SAFE policy > - > > Key: IGNITE-9550 > URL: https://issues.apache.org/jira/browse/IGNITE-9550 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Pavel Vinokurov >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.8 > > Attachments: PartitionLostReproducer.java > > > See reproduced attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9606) JDBC getPrimaryKeys() returns wrong value for COLUMN_NAME
[
https://issues.apache.org/jira/browse/IGNITE-9606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644853#comment-16644853
]
Pavel Kuznetsov commented on IGNITE-9606:
-
Updated workaround and ran tests
https://ci.ignite.apache.org/viewLog.html?buildId=2044950;
https://ci.ignite.apache.org/viewLog.html?buildId=2044950;
> JDBC getPrimaryKeys() returns wrong value for COLUMN_NAME
> -
>
> Key: IGNITE-9606
> URL: https://issues.apache.org/jira/browse/IGNITE-9606
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.6
>Reporter: Pat Patterson
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> JDBC {{getPrimaryKeys()}} method returns {{_KEY}} as column name rather than
> actual column name. This breaks apps that expect a valid column name as the
> primary key.
> Trivially reproducible:
> {noformat}
> public static void main(String[] args) throws Exception {
> // Register JDBC driver.
> Class.forName("org.apache.ignite.IgniteJdbcThinDriver");
> // Open JDBC connection.
> try (Connection conn =
> DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")) {
> // Create database tables.
> try (Statement stmt = conn.createStatement()) {
> stmt.executeUpdate("CREATE TABLE TESTER (" + " ID LONG PRIMARY KEY,
> NAME VARCHAR) " + " WITH \"template=replicated\"");
> }
> // Get database metadata
> DatabaseMetaData md = conn.getMetaData();
> // Get primary keys
> ResultSet rs = md.getPrimaryKeys(conn.getCatalog(), "", "TESTER");
> //
> while (rs.next()) {
> // Column 4 is COLUMN_NAME
> System.out.println("Primary key column is " + rs.getString(4));
> }
> }
> }
> {noformat}
> Expected output is:
> {noformat}
> Primary key column is ID
> {noformat}
> Actual output is:
> {noformat}
> Primary key column is _KEY
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9834) ClientImpl shouldn't fail JVM with 130 error code after node validation errors
[ https://issues.apache.org/jira/browse/IGNITE-9834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644854#comment-16644854 ] Alexey Platonov commented on IGNITE-9834: - It doesn't look like above tests was failed by my code. Maybe this is new errors. > ClientImpl shouldn't fail JVM with 130 error code after node validation errors > -- > > Key: IGNITE-9834 > URL: https://issues.apache.org/jira/browse/IGNITE-9834 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > In the current number of Ignite if client (tcp-client-disco-msg-worker) > receive validation error message represented by > TcpDiscoveryCheckFailedMessage then client fail with 130 error code. > Semantically such behavior is invalid. Client must cancel own work in normal > order. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9133) MVCC: Proper empty DHT transactions handling.
[
https://issues.apache.org/jira/browse/IGNITE-9133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644851#comment-16644851
]
Vladimir Ozerov commented on IGNITE-9133:
-
Test run:
https://ci.ignite.apache.org/viewQueued.html?itemId=2051317=queuedBuildOverviewTab
> MVCC: Proper empty DHT transactions handling.
> -
>
> Key: IGNITE-9133
> URL: https://issues.apache.org/jira/browse/IGNITE-9133
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> In the cases when DHT transaction is empty (i.e. no keys were enlisted) after
> the enlist step, we need to rollback local DHT transaction to exclude it from
> the further transaction flow in order to performance increasing.
> An ordinary Dht tx rollback {{GridDhtTxLocal#rollbackDhtLocalAsync}} is not
> suitable in this situation because it adds tx to
> {{IgniteTxManager#completedVersHashMap}} which is unacceptable because this
> action prevents possible Dht transaction creation if the next tx statements
> enlist some keys at this node in the future. As well as direct tx map
> cleaning by means of {{IgniteTxManager#rollbackTx(tx, true, true)}} is not an
> aid because leads to grid hanging due to undiscovered reasons. In order to
> reproduce hanging you need to reapply commit d231a81 and run
> {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}. Example of hanged thread
> stack is listed below.
> Our goal is the proper Dht transaction rollback without adding it to
> {{IgniteTxManager#completedVersHashMap.}}
> {code:java}
> Thread [name="writer-2", id=2281, state=WAITING, blockCnt=40, waitCnt=10260]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:560)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:185)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:358)
> at
> o.a.i.i.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:2132)
> at
> o.a.i.i.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2083)
> at
> o.a.i.i.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> o.a.i.i.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> o.a.i.i.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> o.a.i.i.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2682)
> at
> o.a.i.i.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:668)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:619)
> at
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest.removeSql(CacheMvccAbstractTest.java:832)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest.access$400(CacheMvccAbstractTest.java:104)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$2.apply(CacheMvccAbstractTest.java:494)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$2.apply(CacheMvccAbstractTest.java:401)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1294)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1289)
> at o.a.i.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9133) MVCC: Proper empty DHT transactions handling.
[
https://issues.apache.org/jira/browse/IGNITE-9133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9133:
Ignite Flags: (was: Docs Required)
> MVCC: Proper empty DHT transactions handling.
> -
>
> Key: IGNITE-9133
> URL: https://issues.apache.org/jira/browse/IGNITE-9133
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> In the cases when DHT transaction is empty (i.e. no keys were enlisted) after
> the enlist step, we need to rollback local DHT transaction to exclude it from
> the further transaction flow in order to performance increasing.
> An ordinary Dht tx rollback {{GridDhtTxLocal#rollbackDhtLocalAsync}} is not
> suitable in this situation because it adds tx to
> {{IgniteTxManager#completedVersHashMap}} which is unacceptable because this
> action prevents possible Dht transaction creation if the next tx statements
> enlist some keys at this node in the future. As well as direct tx map
> cleaning by means of {{IgniteTxManager#rollbackTx(tx, true, true)}} is not an
> aid because leads to grid hanging due to undiscovered reasons. In order to
> reproduce hanging you need to reapply commit d231a81 and run
> {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}. Example of hanged thread
> stack is listed below.
> Our goal is the proper Dht transaction rollback without adding it to
> {{IgniteTxManager#completedVersHashMap.}}
> {code:java}
> Thread [name="writer-2", id=2281, state=WAITING, blockCnt=40, waitCnt=10260]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:560)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:185)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:358)
> at
> o.a.i.i.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:2132)
> at
> o.a.i.i.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2083)
> at
> o.a.i.i.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> o.a.i.i.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> o.a.i.i.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> o.a.i.i.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2682)
> at
> o.a.i.i.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:668)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:619)
> at
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest.removeSql(CacheMvccAbstractTest.java:832)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest.access$400(CacheMvccAbstractTest.java:104)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$2.apply(CacheMvccAbstractTest.java:494)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$2.apply(CacheMvccAbstractTest.java:401)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1294)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1289)
> at o.a.i.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9133) MVCC: Proper empty DHT transactions handling.
[
https://issues.apache.org/jira/browse/IGNITE-9133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644847#comment-16644847
]
ASF GitHub Bot commented on IGNITE-9133:
GitHub user devozerov opened a pull request:
https://github.com/apache/ignite/pull/4943
IGNITE-9133
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9133
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4943.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 #4943
commit e7e76fd91268a44539f0ae7adf9ea58caaac1b0d
Author: devozerov
Date: 2018-10-10T10:30:29Z
Test.
commit 233b2501c931b71f3551ace963b926651af47a6f
Author: devozerov
Date: 2018-10-10T10:36:37Z
WIP.
commit 1539e79319ba3fd091fa7e0e4b7601af671976ec
Author: devozerov
Date: 2018-10-10T10:37:00Z
WIP.
commit ffb2e4fb617d5af4c1f88542e79dad1f884f95f4
Author: devozerov
Date: 2018-10-10T11:26:34Z
Done.
> MVCC: Proper empty DHT transactions handling.
> -
>
> Key: IGNITE-9133
> URL: https://issues.apache.org/jira/browse/IGNITE-9133
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> In the cases when DHT transaction is empty (i.e. no keys were enlisted) after
> the enlist step, we need to rollback local DHT transaction to exclude it from
> the further transaction flow in order to performance increasing.
> An ordinary Dht tx rollback {{GridDhtTxLocal#rollbackDhtLocalAsync}} is not
> suitable in this situation because it adds tx to
> {{IgniteTxManager#completedVersHashMap}} which is unacceptable because this
> action prevents possible Dht transaction creation if the next tx statements
> enlist some keys at this node in the future. As well as direct tx map
> cleaning by means of {{IgniteTxManager#rollbackTx(tx, true, true)}} is not an
> aid because leads to grid hanging due to undiscovered reasons. In order to
> reproduce hanging you need to reapply commit d231a81 and run
> {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}. Example of hanged thread
> stack is listed below.
> Our goal is the proper Dht transaction rollback without adding it to
> {{IgniteTxManager#completedVersHashMap.}}
> {code:java}
> Thread [name="writer-2", id=2281, state=WAITING, blockCnt=40, waitCnt=10260]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:560)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:185)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:358)
> at
> o.a.i.i.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:2132)
> at
> o.a.i.i.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2083)
> at
> o.a.i.i.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> o.a.i.i.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> o.a.i.i.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> o.a.i.i.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2682)
> at
> o.a.i.i.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:668)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:619)
> at
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest.removeSql(CacheMvccAbstractTest.java:832)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest.access$400(CacheMvccAbstractTest.java:104)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$2.apply(CacheMvccAbstractTest.java:494)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$2.apply(CacheMvccAbstractTest.java:401)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1294)
>
[jira] [Assigned] (IGNITE-9836) Invalid check of ea java versions
[
https://issues.apache.org/jira/browse/IGNITE-9836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasiliy Sisko reassigned IGNITE-9836:
-
Assignee: Peter Ivanov (was: Vasiliy Sisko)
> Invalid check of ea java versions
> -
>
> Key: IGNITE-9836
> URL: https://issues.apache.org/jira/browse/IGNITE-9836
> Project: Ignite
> Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Peter Ivanov
>Priority: Major
>
> On check of '1.8.0_192-ea' java version in ignite.sh the next messages in
> console are printed:
> {code:java}
> ./include/functions.sh: line 81: [: -lt: unary operator expected
> ./ignite.sh: line 61:
> /home/vsisko/Downloads/distr/bin/include/build-classpath.sh: No such file or
> directory
> ./ignite.sh: line 152: [: -eq: unary operator expected
> ./ignite.sh: line 157: [: -gt: unary operator expected
> ./ignite.sh: line 170: [: -eq: unary operator expected{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[ https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644815#comment-16644815 ] Anton Vinogradov commented on IGNITE-9532: -- [~uday] Yes, please run it. > Binary mode for Ignite Queue > > > Key: IGNITE-9532 > URL: https://issues.apache.org/jira/browse/IGNITE-9532 > Project: Ignite > Issue Type: New Feature > Components: binary, data structures >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.8 > > > Add binary mode (withKeepBinary) to Data Structures Queue. > This will allow retrieving values in binary format when needed or when class > is not available, and will allow implementing the structures in other > platforms (.NET, C++). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[ https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644806#comment-16644806 ] Uday Kale commented on IGNITE-9532: --- [~avinogradov], Yes, I had messed up a bit. I have now rebased against master and pushed my changes. Should i now trigger the TeamCity RunAll? > Binary mode for Ignite Queue > > > Key: IGNITE-9532 > URL: https://issues.apache.org/jira/browse/IGNITE-9532 > Project: Ignite > Issue Type: New Feature > Components: binary, data structures >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.8 > > > Add binary mode (withKeepBinary) to Data Structures Queue. > This will allow retrieving values in binary format when needed or when class > is not available, and will allow implementing the structures in other > platforms (.NET, C++). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9719) Extra rebalanceThreadPoolSize check on client node.
[ https://issues.apache.org/jira/browse/IGNITE-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644797#comment-16644797 ] Luchnikov Alexander commented on IGNITE-9719: - could someone review? > Extra rebalanceThreadPoolSize check on client node. > --- > > Key: IGNITE-9719 > URL: https://issues.apache.org/jira/browse/IGNITE-9719 > Project: Ignite > Issue Type: Improvement > Components: clients >Affects Versions: 2.6 >Reporter: Stanilovsky Evgeny >Assignee: Luchnikov Alexander >Priority: Minor > Fix For: 2.8 > > > No need to check rebalance thread pool size on client side in > IgniteKernal#ackRebalanceConfiguration method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9133) MVCC: Proper empty DHT transactions handling.
[
https://issues.apache.org/jira/browse/IGNITE-9133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-9133:
---
Assignee: Vladimir Ozerov
> MVCC: Proper empty DHT transactions handling.
> -
>
> Key: IGNITE-9133
> URL: https://issues.apache.org/jira/browse/IGNITE-9133
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> In the cases when DHT transaction is empty (i.e. no keys were enlisted) after
> the enlist step, we need to rollback local DHT transaction to exclude it from
> the further transaction flow in order to performance increasing.
> An ordinary Dht tx rollback {{GridDhtTxLocal#rollbackDhtLocalAsync}} is not
> suitable in this situation because it adds tx to
> {{IgniteTxManager#completedVersHashMap}} which is unacceptable because this
> action prevents possible Dht transaction creation if the next tx statements
> enlist some keys at this node in the future. As well as direct tx map
> cleaning by means of {{IgniteTxManager#rollbackTx(tx, true, true)}} is not an
> aid because leads to grid hanging due to undiscovered reasons. In order to
> reproduce hanging you need to reapply commit d231a81 and run
> {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}. Example of hanged thread
> stack is listed below.
> Our goal is the proper Dht transaction rollback without adding it to
> {{IgniteTxManager#completedVersHashMap.}}
> {code:java}
> Thread [name="writer-2", id=2281, state=WAITING, blockCnt=40, waitCnt=10260]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:560)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:185)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:358)
> at
> o.a.i.i.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:2132)
> at
> o.a.i.i.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2083)
> at
> o.a.i.i.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> o.a.i.i.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> o.a.i.i.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> o.a.i.i.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2682)
> at
> o.a.i.i.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:668)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:619)
> at
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest.removeSql(CacheMvccAbstractTest.java:832)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest.access$400(CacheMvccAbstractTest.java:104)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$2.apply(CacheMvccAbstractTest.java:494)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$2.apply(CacheMvccAbstractTest.java:401)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1294)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1289)
> at o.a.i.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[ https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644789#comment-16644789 ] Anton Vinogradov commented on IGNITE-9532: -- [~uday] I don't see have you merged master or not since you squashed commits. Tc bot does not merge master before the check. > Binary mode for Ignite Queue > > > Key: IGNITE-9532 > URL: https://issues.apache.org/jira/browse/IGNITE-9532 > Project: Ignite > Issue Type: New Feature > Components: binary, data structures >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.8 > > > Add binary mode (withKeepBinary) to Data Structures Queue. > This will allow retrieving values in binary format when needed or when class > is not available, and will allow implementing the structures in other > platforms (.NET, C++). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9815) [TC Bot] Muted tests shouldn't considered as blocker
[
https://issues.apache.org/jira/browse/IGNITE-9815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644790#comment-16644790
]
ASF GitHub Bot commented on IGNITE-9815:
asfgit closed pull request #29: IGNITE-9815: Muted tests shouldn't considered
as blocker
URL: https://github.com/apache/ignite-teamcity-bot/pull/29
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/model/current/TestFailure.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/model/current/TestFailure.java
index dcd18fb..7e49ec0 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/model/current/TestFailure.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/model/current/TestFailure.java
@@ -241,6 +241,9 @@ public void initStat(@Nullable final Function runStatSupp
public boolean isNewFailedTest() {
FailureSummary recent = histBaseBranch.recent;
+if (!Strings.isNullOrEmpty(webIssueUrl))
+return false;
+
boolean lowFailureRate = recent != null && recent.failureRate != null
&&
Float.valueOf(recent.failureRate.replace(',', '.')) < 4.;
diff --git a/ignite-tc-helper-web/src/main/webapp/js/testfails-2.1.js
b/ignite-tc-helper-web/src/main/webapp/js/testfails-2.1.js
index b61189b..e1c995c 100644
--- a/ignite-tc-helper-web/src/main/webapp/js/testfails-2.1.js
+++ b/ignite-tc-helper-web/src/main/webapp/js/testfails-2.1.js
@@ -627,8 +627,12 @@ function isNewFailedTest(testFail) {
if(!isDefinedAndFilled(testFail.histBaseBranch))
return true;
+if (testFail.webIssueUrl)
+return false;
+
var hist = testFail.histBaseBranch;
-if(!isDefinedAndFilled(hist.recent))
+
+if (!isDefinedAndFilled(hist.recent))
return true;
var flakyCommentsInBase =
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> [TC Bot] Muted tests shouldn't considered as blocker
>
>
> Key: IGNITE-9815
> URL: https://issues.apache.org/jira/browse/IGNITE-9815
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Ryabov Dmitrii
>Priority: Major
>
> Currently, TC bot doesn't analyze stack trace of test fail [1].
> If some test failed with the link to Ignite ticket it shouldn't be considered
> as a blocker.
> Link with examples of such behaviour:
> {noformat}
> IgniteCacheMvccTestSuite: DataStreamProcessorMvccSelfTest.testColocated -
> 0,0% fails in last 100 master runs.
> IgniteCacheMvccTestSuite: DataStreamProcessorMvccSelfTest.testPartitioned -
> 0,0% fails in last 100 master runs.
> IgniteCacheMvccTestSuite: DataStreamProcessorMvccSelfTest.testReplicated -
> 0,0% fails in last 100 master runs.
> {noformat}
> stack trace:
> {noformat}
> unit.framework.AssertionFailedError:
> https://issues.apache.org/jira/browse/IGNITE-9722
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple(CacheMvccTransactionsTest.java:2387)
> {noformat}
> https://issues.apache.org/jira/browse/IGNITE-9272?focusedCommentId=16641617=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16641617
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9749) MVCC: Assertion error in JdbcThinTransactionsServerAutoCommitComplexSelfTest leading to JDBC MVCC suite hang
[
https://issues.apache.org/jira/browse/IGNITE-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov reassigned IGNITE-9749:
Assignee: Igor Seliverstov
> MVCC: Assertion error in JdbcThinTransactionsServerAutoCommitComplexSelfTest
> leading to JDBC MVCC suite hang
>
>
> Key: IGNITE-9749
> URL: https://issues.apache.org/jira/browse/IGNITE-9749
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Alexey Goncharuk
>Assignee: Igor Seliverstov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> The following assertion can be observed in master
> {code}
> [10:34:12]W: [org.apache.ignite:ignite-clients] [07:34:12] (err)
> Failed to notify listener:
> o.a.i.i.util.future.GridEmbeddedFuture$2...@4e56da7bjava.lang.AssertionError:
> localNode = 14353600-ea43-42ae-bf7c-4b467800, dhtNodes =
> [TcpDiscoveryNode [id=04134719-3eb1-4969-99dc-f520f982, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501], discPort=47501, order=3,
> intOrder=3, lastExchangeTime=1538379249752, loc=false,
> ver=2.7.0#20181001-sha1:9ab8ebd7, isClient=false]]
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.backupNodes(GridDhtTxAbstractEnlistFuture.java:867)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.addToBatch(GridDhtTxAbstractEnlistFuture.java:627)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.processEntry(GridDhtTxAbstractEnlistFuture.java:614)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.continueLoop(GridDhtTxAbstractEnlistFuture.java:501)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:363)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxQueryEnlistFuture.map(GridNearTxQueryEnlistFuture.java:212)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture.mapOnTopology(GridNearTxAbstractEnlistFuture.java:332)
> [10:34:12] : [Step 4/5] [2018-10-01 07:34:12,762][INFO
> ][exchange-worker-#2510%thin.JdbcThinTransactionsServerAutoCommitComplexSelfTest2%][GridCachePartitionExchangeManager]
> Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion
> [topVer=4, minorTopVer=16], force=false, evt=DISCOVERY_CUSTOM_EVT,
> node=14353600-ea43-42ae-bf7c-4b467800]
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture.access$000(GridNearTxAbstractEnlistFuture.java:56)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture$2.apply(GridNearTxAbstractEnlistFuture.java:340)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture$2.apply(GridNearTxAbstractEnlistFuture.java:335)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:349)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:337)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:497)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:476)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1947)
> [10:34:12]W:
[jira] [Commented] (IGNITE-9680) Web console: add component for status output
[ https://issues.apache.org/jira/browse/IGNITE-9680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644780#comment-16644780 ] ASF GitHub Bot commented on IGNITE-9680: GitHub user Klaster1 opened a pull request: https://github.com/apache/ignite/pull/4941 IGNITE-9680 Status output component [See the issue](https://issues.apache.org/jira/browse/IGNITE-9680). You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-wc-592 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4941.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 #4941 commit edf2db5b692d99774c8525794762559f01ccade3 Author: Andrey Novikov Date: 2017-11-17T11:05:41Z WC-300 WIP. commit 085d8d2c916e1cd182818dae45459f70c09025f2 Author: Andrey Novikov Date: 2017-11-20T02:59:17Z WC-300 Merge master into ignite-wc-300-2. commit 65ec87bcac21ccc8ac28b1f6b59a1d277138441f Author: Andrey Novikov Date: 2017-11-20T07:03:33Z WC-300 Added ng-message. commit 80e343dde01db8992e1bba5f6b1e3d35b6b71c17 Author: Andrey Novikov Date: 2017-11-20T08:12:13Z WC-300 Copy svg. commit 25eaeb8f1203c44a7479f1b6ef665f50ae57be9a Author: Andrey Novikov Date: 2017-11-21T03:58:11Z WC-300 Fixed plus icon. commit 7c4b38c4e03109339deafa4ffee52c3a3cf351db Author: Ilya Borisov Date: 2017-11-21T03:33:30Z WC-300 Introduce DefaultState provider/service. commit de06b61d1f5e637e9932bc2c1262c6937b3ef379 Author: Ilya Borisov Date: 2017-11-21T03:36:24Z WC-300 Use "default-state" instead of explicit default state. Do not mention default state name when redirecting to it. commit 46e53e43d923ceec68b2f381e1291eb4220f5aba Author: Ilya Borisov Date: 2017-11-22T08:18:59Z WC-300 Replace missed default-state transition. commit c7007d0ecd697c601fe65f673aae40161df6fbfa Author: Alexey Kuznetsov Date: 2017-11-22T12:28:02Z WC-300 WIP cluster name. commit 78492ba08d8b0a0710fbe792749d2829ffdc Author: Alexey Kuznetsov Date: 2017-11-22T17:17:16Z WC-300 Added support for cluster name. commit 86bdb2737a172178c481e6678cb63e6a9c156a25 Author: Andrey Novikov Date: 2017-11-22T10:21:34Z WC-300 Use account _id as agent token. commit 91d40d4a6f551b610e0d1d0a315c2cadb46dcb57 Author: Alexey Kuznetsov Date: 2017-11-23T06:13:16Z Merge branches 'ignite-wc-300-2' and 'ignite-wc-300-cluster-name'. commit 29fd82a3c42d20cbdb210a7ebe066a853f99cc23 Author: Andrey Novikov Date: 2017-11-23T11:25:53Z WC-300 Fixed uptime. commit f742502f37a5e5290e7eb3c95f71b8b7c7bf9c1d Author: Andrey Novikov Date: 2017-11-23T11:29:41Z Merge branch 'ignite-wc-300-cluster-name' of https://github.com/gridgain/apache-ignite into ignite-wc-300-2 commit f314db36d4b40f0bd624ce81cac13eba8a5260ce Author: Andrey Novikov Date: 2017-12-06T07:22:07Z WC-300 Merged master branch. commit 25a22d4dc7681e2ea3e3736c8e484b587e7dd488 Author: Ilya Borisov Date: 2017-12-01T03:41:03Z WC-361 Move breadcrumbs to Ignite. (cherry picked from commit 154177b) commit fd68f9a28778419567319e0e6a096e657163e01f Author: Ilya Borisov Date: 2017-12-06T07:25:30Z WC-361 WIP. commit e317e34da709e68b9c78aae7ee176d16871fb85e Author: Andrey Novikov Date: 2017-12-06T09:46:59Z WC-300 Merged master branch. commit 58061d7a703c25eac71e8f4ec5737c4d2ccdc4b1 Author: Dmitriy Shabalin Date: 2017-12-06T10:03:50Z WC-300 added icons commit 0c97cc64c90e6ab934b85943ce28133fc785cc33 Author: Andrey Novikov Date: 2017-12-07T03:05:23Z WC-300 Minor ui fix. commit 11411609f81e4c16e6693fb187d1dd7d7e9aff68 Author: Andrey Novikov Date: 2017-12-07T08:14:12Z Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite into ignite-wc-300-2 commit 5fa41cf7284ff99a9beef94e46de570fdad30dd3 Author: Ilya Borisov Date: 2017-12-07T10:09:34Z WC-300 Animate .ignite-form-field error messages. commit 63afe406dfcc0a21f85bd46036025bd6379f41a8 Author: Dmitriy Shabalin Date: 2017-12-07T14:24:18Z WC-300 support extern icons commit fe5db2ee18ed73b11d9fe0148dc30b0f25e5c429 Author: Ilya Borisov Date: 2017-12-12T03:17:03Z WC-300 Move page-profile component definition into separate file, use non-URL template. commit 45bfcc888057fea55197b620b85eed0e9df375e8 Author: Ilya Borisov Date: 2017-12-12T06:59:08Z WC-361 Add "home" icon. commit 526547fcbc6d6cdc5ed370aac7d2649d1637593c Author: Ilya Borisov Date: 2017-12-12T07:00:24Z WC-361 Transclude breadcrumbs "home" image into first element, use svg icon instead of an asset. commit 7be95304e0ddb87373e91fdad7e7389b528c5801 Author: Andrey Novikov Date: 2017-12-12T10:40:05Z Merge branch master into ignite-wc-300-2
[jira] [Updated] (IGNITE-9823) Create TeamCity suite for PHP thin client
[ https://issues.apache.org/jira/browse/IGNITE-9823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-9823: Ignite Flags: (was: Docs Required) > Create TeamCity suite for PHP thin client > - > > Key: IGNITE-9823 > URL: https://issues.apache.org/jira/browse/IGNITE-9823 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Igor Sapego >Assignee: Peter Ivanov >Priority: Major > Labels: php > Fix For: 2.7 > > > Implementation of PHP client is almost ready (IGNITE-7783). We need to figure > out how to integrate it with TeamCity: > 1) New suite for PHP thin client is needed along with required environment > 2) Suite should be able to run tests as described in the readme [1] > 3) Currently all tests rely on manually started external node. We need to > create a set of scripts (bash?) to start/stop nodes locally just like in > IGNITE-8463 > [1] > https://github.com/nobitlost/ignite/blob/ignite-7783-docs/modules/platforms/php/README.md#tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9823) Create TeamCity suite for PHP thin client
[ https://issues.apache.org/jira/browse/IGNITE-9823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9823: Fix Version/s: 2.7 > Create TeamCity suite for PHP thin client > - > > Key: IGNITE-9823 > URL: https://issues.apache.org/jira/browse/IGNITE-9823 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Igor Sapego >Assignee: Peter Ivanov >Priority: Major > Labels: php > Fix For: 2.7 > > > Implementation of PHP client is almost ready (IGNITE-7783). We need to figure > out how to integrate it with TeamCity: > 1) New suite for PHP thin client is needed along with required environment > 2) Suite should be able to run tests as described in the readme [1] > 3) Currently all tests rely on manually started external node. We need to > create a set of scripts (bash?) to start/stop nodes locally just like in > IGNITE-8463 > [1] > https://github.com/nobitlost/ignite/blob/ignite-7783-docs/modules/platforms/php/README.md#tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9694) Add tests to check that reading queries are not blocked on exchange events that don't change data visibility
[ https://issues.apache.org/jira/browse/IGNITE-9694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-9694: -- Description: In current implementation there might be situations where reading operation waits, for example, exchange of client join event. Such events should not block read operations. In theory - the only operation that has to block reading (except for writing) is "node left" for server (or baseline server in case of persistent setup). Table shows current state of blocking, covered by test in this ticket: Partitioned cache: || ||Start Client||Stop Client||Start Server||Stop Server||Start Baseline||Stop Baseline||Add Baseline||Start Cache||Stop Cache||Create Sql Index||Drop Sql Index|| |Get| (/)| (?)| (/)| (/)| (/)| (x)| (/)| (x)| (x)| (/)| (/)| |Get All| (/)| (?)| (/)| (/)| (/)| (x)| (/)| (x)| (x)| (/)| (/)| |Scan| (/)| (?)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| |Sql Query| (/)| (?)| (x)| (x)| (/)| (x)| (/)| (/)| (/)| (/)| (/)| Replicated cache: || ||Start Client||Stop Client||Start Server||Stop Server||Start Baseline||Stop Baseline||Add Baseline||Start Cache||Stop Cache||Create Sql Index||Drop Sql Index|| |Get| (/)| (?)| (/)| (/)| (/)| (x)| (/)| (x)| (x)| (/)| (/)| |Get All| (/)| (?)| (/)| (/)| (/)| (x)| (/)| (x)| (x)| (/)| (/)| |Scan| (/)| (?)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| |Sql Query| (/)| (?)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| was: In current implementation there might be situations where reading operation waits, for example, exchange of client join event. Such events should not block read operations. In theory - the only operation that has to block reading (except for writing) is "node left" for server (or baseline server in case of persistent setup). Table shows current state of blocking, covered by test in this ticket: || ||Start Client||Stop Client||Start Server||Stop Server||Start Baseline||Stop Baseline||Add Baseline||Start Cache||Stop Cache||Create Sql Index||Drop Sql Index|| |Get| (/)| (?)| (/)| (/)| (/)| (x)| (/)| (x)| (x)| (/)| (/)| |Get All| (/)| (?)| (/)| (/)| (/)| (x)| (/)| (x)| (x)| (/)| (/)| |Scan| (/)| (?)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| |Sql Query| (/)| (?)| (x)| (x)| (/)| (x)| (/)| (/)| (/)| (/)| (/)| > Add tests to check that reading queries are not blocked on exchange events > that don't change data visibility > > > Key: IGNITE-9694 > URL: https://issues.apache.org/jira/browse/IGNITE-9694 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > > In current implementation there might be situations where reading operation > waits, for example, exchange of client join event. Such events should not > block read operations. > In theory - the only operation that has to block reading (except for writing) > is "node left" for server (or baseline server in case of persistent setup). > Table shows current state of blocking, covered by test in this ticket: > > Partitioned cache: > || ||Start > Client||Stop > Client||Start > Server||Stop > Server||Start > Baseline||Stop > Baseline||Add > Baseline||Start > Cache||Stop > Cache||Create > Sql Index||Drop > Sql Index|| > |Get| (/)| (?)| (/)| (/)| (/)| (x)| (/)| (x)| (x)| > (/)| (/)| > |Get All| (/)| (?)| (/)| (/)| (/)| (x)| (/)| (x)| > (x)| (/)| (/)| > |Scan| (/)| (?)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| > (/)| (/)| > |Sql Query| (/)| (?)| (x)| (x)| (/)| (x)| (/)| (/)| > (/)| (/)| (/)| > Replicated cache: > || ||Start > Client||Stop > Client||Start > Server||Stop > Server||Start > Baseline||Stop > Baseline||Add > Baseline||Start > Cache||Stop > Cache||Create > Sql Index||Drop > Sql Index|| > |Get| (/)| (?)| (/)| (/)| (/)| (x)| (/)| (x)| (x)| > (/)| (/)| > |Get All| (/)| (?)| (/)| (/)| (/)| (x)| (/)| (x)| > (x)| (/)| (/)| > |Scan| (/)| (?)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| > (/)| (/)| > |Sql Query| (/)| (?)| (/)| (/)| (/)| (/)| (/)| (/)| > (/)| (/)| (/)| > -- This
[jira] [Updated] (IGNITE-9133) MVCC: Proper empty DHT transactions handling.
[
https://issues.apache.org/jira/browse/IGNITE-9133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9133:
Summary: MVCC: Proper empty DHT transactions handling. (was: SQL TX:
Proper empty DHT transactions handling.)
> MVCC: Proper empty DHT transactions handling.
> -
>
> Key: IGNITE-9133
> URL: https://issues.apache.org/jira/browse/IGNITE-9133
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Priority: Major
> Fix For: 2.7
>
>
> In the cases when DHT transaction is empty (i.e. no keys were enlisted) after
> the enlist step, we need to rollback local DHT transaction to exclude it from
> the further transaction flow in order to performance increasing.
> An ordinary Dht tx rollback {{GridDhtTxLocal#rollbackDhtLocalAsync}} is not
> suitable in this situation because it adds tx to
> {{IgniteTxManager#completedVersHashMap}} which is unacceptable because this
> action prevents possible Dht transaction creation if the next tx statements
> enlist some keys at this node in the future. As well as direct tx map
> cleaning by means of {{IgniteTxManager#rollbackTx(tx, true, true)}} is not an
> aid because leads to grid hanging due to undiscovered reasons. In order to
> reproduce hanging you need to reapply commit d231a81 and run
> {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}. Example of hanged thread
> stack is listed below.
> Our goal is the proper Dht transaction rollback without adding it to
> {{IgniteTxManager#completedVersHashMap.}}
> {code:java}
> Thread [name="writer-2", id=2281, state=WAITING, blockCnt=40, waitCnt=10260]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:560)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:185)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:358)
> at
> o.a.i.i.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:2132)
> at
> o.a.i.i.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2083)
> at
> o.a.i.i.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> o.a.i.i.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> o.a.i.i.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> o.a.i.i.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2682)
> at
> o.a.i.i.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:668)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:619)
> at
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest.removeSql(CacheMvccAbstractTest.java:832)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest.access$400(CacheMvccAbstractTest.java:104)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$2.apply(CacheMvccAbstractTest.java:494)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$2.apply(CacheMvccAbstractTest.java:401)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1294)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1289)
> at o.a.i.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
