[jira] [Created] (IGNITE-10772) If version look like X.X.X.X rest version return X.X.X-X
ARomantsov created IGNITE-10772:
---
Summary: If version look like X.X.X.X rest version return X.X.X-X
Key: IGNITE-10772
URL: https://issues.apache.org/jira/browse/IGNITE-10772
Project: Ignite
Issue Type: Bug
Components: rest
Affects Versions: 2.8
Reporter: ARomantsov
Fix For: 2.8
Test URL - http://localhost:8080/ignite?cmd=version
{
"result": {
"error": null,
"response": "X.X.X-X",
"sessionToken": "D372FC2DD4A24603AC39CC92C6B132EC",
"successStatus": 0
},
"status": "OK"
}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-9618) Need to be replace the data compression algorithm
[ https://issues.apache.org/jira/browse/IGNITE-9618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin resolved IGNITE-9618. Resolution: Later > Need to be replace the data compression algorithm > - > > Key: IGNITE-9618 > URL: https://issues.apache.org/jira/browse/IGNITE-9618 > Project: Ignite > Issue Type: New Feature > Components: persistence >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > > Now used zip and its speed slow > Exist alternatives and on tests in terms of performance they showed > themselves to be better > source file wal 1Gb > result > ||algoritm||time, ms||size, byte|| > |zip|18 889|79 950 283| > |[Snappy|https://github.com/xerial/snappy-java]|3 372|156 482 623| > |[lz4|https://github.com/lz4/lz4-java]|2 047|128 591 795| -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10762) migrate test suites from Junit 3 to 4
[
https://issues.apache.org/jira/browse/IGNITE-10762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko reassigned IGNITE-10762:
---
Assignee: Oleg Ignatenko
> migrate test suites from Junit 3 to 4
> -
>
> Key: IGNITE-10762
> URL: https://issues.apache.org/jira/browse/IGNITE-10762
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ivan Pavlukhin
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> It seems that {{@Ignore}} annotation is processed incorrectly when a test in
> Junit 4 style is included into Junit 3 test suite (wrapped into
> {{JUnit4TestAdapter}}). Actually such test is skipped silently when it is
> called during a suite execution. So, for full a blown usage of {{@Ignore}}
> test suites must be migrated to Junit 4 as well. Expected behavior here is
> reporting that a particular test method was ignored after tests execution.
> Ignored tests should be visible in CI.
> Apparently such unexpected behavior of {{@Ignore}} can be caused by
> {{JUnit4TestAdapter}} as it explicitly filters test method marked with this
> annotation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10648) Ignite hang to stop if node wasn't started completely. GridTcpRestNioListener hangs on latch.
[
https://issues.apache.org/jira/browse/IGNITE-10648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726492#comment-16726492
]
Ignite TC Bot commented on IGNITE-10648:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Spring{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2603779]]
* GridServiceInjectionSpringResourceTest.testDeployServiceWithSpring (last
started)
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2601298buildTypeId=IgniteTests24Java8_RunAll]
> Ignite hang to stop if node wasn't started completely. GridTcpRestNioListener
> hangs on latch.
> -
>
> Key: IGNITE-10648
> URL: https://issues.apache.org/jira/browse/IGNITE-10648
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Assignee: Vladislav Pyatkov
>Priority: Major
>
> If Ignition.start waits on rebalance then GridRestProcessor is not started
> yet then we call Ingition.stop and
> GridTcpRestNioListener hangs on
> if (marshMapLatch.getCount() > 0)
> U.awaitQuiet(marshMapLatch);
> cause wasn't counted down on start.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10739) get rid of using JUnit 3 API in IgniteConfigVariationsAbstractTest
[
https://issues.apache.org/jira/browse/IGNITE-10739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725630#comment-16725630
]
Oleg Ignatenko edited comment on IGNITE-10739 at 12/21/18 5:26 AM:
---
(i) another test which appears to strongly depend on JUnit 3 is
{{IgniteTwitterStreamerTest}}, it should be taken care of as well. Preliminary
checking suggests that WireMock version needs upgrade from 1.57 to 1.58 in
order to adopt JUnit 4.
was (Author: oignatenko):
(i) another test which appears to strongly depend on JUnit 3 is
{{IgniteTwitterStreamerTest}}, it should be taken care of as well
> get rid of using JUnit 3 API in IgniteConfigVariationsAbstractTest
> --
>
> Key: IGNITE-10739
> URL: https://issues.apache.org/jira/browse/IGNITE-10739
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain, technical_debt
>
> {{IgniteConfigVariationsAbstractTest}} and part of test framework that uses
> this class very heavily rely on JUnit 3 specific features.
> The task is to get rid of these and use newer versions instead - preferably
> JUnit 4, although JUnit 5 is also an option
> This will allow consistent JUnit framework version across Ignite tests which
> in turn is expected to simplify maintenance and development of the tests
> (including ignoring tests, workiing on Teamcity related things etc).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8911) While cache is restarting it's possible to start new cache with this name
[
https://issues.apache.org/jira/browse/IGNITE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726420#comment-16726420
]
Ignite TC Bot commented on IGNITE-8911:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests 2 TIMEOUT
|https://ci.ignite.apache.org/viewLog.html?buildId=2607262]]
* exe: PersistentStoreTestObsolete.TestCacheDataSurvivesNodeRestart - 6,2%
fails in last 340 master runs.
* exe: CacheAbstractTest.TestCacheConfigurationExpiryPolicy - 5,0% fails in
last 340 master runs.
{color:#d04437}JDBC Driver{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2607195]]
{color:#d04437}Platform C++ (Linux){color} [[tests 479 JVM CRASH , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2607212]]
* IgniteOdbcTest: SslQueriesTestSuite: TestConnectionSslSuccess - 3,5% fails in
last 868 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionFloor - 1,4%
fails in last 868 master runs.
* IgniteOdbcTest: TransactionTestSuite: TransactionVersionMismatchError - 1,4%
fails in last 868 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionLog - 1,4%
fails in last 868 master runs.
* IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate - 1,4% fails in
last 868 master runs.
* IgniteCoreTest: CacheQueryTestSuite: TestFieldsQueryByteArrayInsertSelect -
1,4% fails in last 868 master runs.
* IgniteCoreTest: ContinuousQueryTestSuite: TestBasic - 1,4% fails in last 868
master runs.
* IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryScan - 1,4% fails
in last 868 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLGetStmtAttr - 1,4% fails in
last 868 master runs.
* IgniteOdbcTest: StreamingTestSuite: TestStreamingManyObjects - 1,4% fails in
last 868 master runs.
* IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQuerySql - 1,4% fails in
last 868 master runs.
* IgniteThinClientTest: AuthTestSuite: AuthSuccess - 1,4% fails in last 868
master runs.
* IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryText - 1,4% fails
in last 868 master runs.
* IgniteThinClientTest: CacheClientTestSuite: CacheClientGetCacheExisting -
1,4% fails in last 868 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLSetStmtAttr - 1,4% fails in
last 868 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLPrimaryKeys - 1,4% fails in
last 868 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLNumParams - 1,4% fails in last
868 master runs.
* IgniteCoreTest: ContinuousQueryTestSuite: TestBasicNoExcept - 1,4% fails in
last 868 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLGetDiagField - 1,4% fails in
last 868 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionLog10 - 1,4%
fails in last 868 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLGetDiagRec - 1,4% fails in
last 868 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLGetData - 1,4% fails in last
868 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLGetEnvAttr - 1,4% fails in
last 868 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionMod - 1,4%
fails in last 868 master runs.
* IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryScanNoExcept - 1,4%
fails in last 868 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLSpecialColumns - 1,4% fails in
last 868 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionPi - 1,4%
fails in last 868 master runs.
* IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQuerySqlNoExcept - 1,4%
fails in last 868 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestFetchScrollLast - 1,4% fails in
last 868 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionPower - 1,4%
fails in last 868 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestFetchScrollPrior - 1,4% fails in
last 868 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionRadians -
1,4% fails in last 868 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestFetchScrollFirst - 1,4% fails in
last 868 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionRand - 1,4%
fails in last 868 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionRound - 1,4%
fails in last 868 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionSign - 1,4%
fails in last 868 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionSin - 1,4%
fails in last 868 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionSqrt - 1,4%
fails in last 868 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite:
[jira] [Commented] (IGNITE-9989) JDBC v2: getPrimaryKeys always returns constant COLUMN_NAME, KEY_SEQ, PK_NAME
[
https://issues.apache.org/jira/browse/IGNITE-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726374#comment-16726374
]
Ignite TC Bot commented on IGNITE-9989:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Spring{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2606864]]
{color:#d04437}Hibernate 5.1{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2606853]]
{color:#d04437}Hibernate 4.2{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2606852]]
{color:#d04437}Thin client: Python{color} [[tests 1 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2606930]]
*
tests.test_binary.test_sql_write_as_binary[0-ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+HIGH:DH+HIGH:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+HIGH:RSA+3DES:!aNULL:!eNULL:!MD5-None-None-None-False-localhost-10800-None-None-None-_SSLMethod_PROTOCOL_TLSv1_1]
{color:#d04437}Hibernate 5.3{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2606936]]
{color:#d04437}Cache 5{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=2606905]]
* IgniteCacheWithIndexingTestSuite:
CacheBinaryKeyConcurrentQueryTest.testPutAndQueries - 0,0% fails in last 326
master runs.
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests
155|https://ci.ignite.apache.org/viewLog.html?buildId=2606933]]
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testPeekPartitionedModes - 0,0%
fails in last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testPeekAsyncPartitionedModes -
0,0% fails in last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testPutDebug - 0,0% fails in last
351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testPutAllPutAll - 0,0% fails in
last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testNearDhtKeySize - 0,0% fails in
last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testUpdate - 0,0% fails in last 351
master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testPutAllRemoveAll - 0,0% fails in
last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testAffinity - 0,0% fails in last
351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testContainsKeysTx - 0,0% fails in
last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testGetAllAsyncOld - 0,0% fails in
last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testInvokeAsyncOld - 0,0% fails in
last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testTransformAllOptimisticRepeatableRead
- 0,0% fails in last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testGetAndRemoveObject - 0,0% fails
in last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testWithSkipStoreRemoveAll - 0,0%
fails in last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testPessimisticTxMissingKeyNoCommit
- 0,0% fails in last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testPeekTxRemovePessimistic - 0,0%
fails in last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testPutxNoTx - 0,0% fails in last
351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testEvictExpired - 0,0% fails in
last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testPutAsync - 0,0% fails in last
351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testTransformSequentialPessimisticWithStart
- 0,0% fails in last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testGetAsync - 0,0% fails in last
351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testGetEntry - 0,0% fails in last
351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testTransformAllOptimisticReadCommitted
- 0,0% fails in last 351 master runs.
* ZookeeperDiscoverySpiTestSuite3:
GridCachePartitionedMultiJvmFullApiSelfTest.testOptimisticTxMissingKey - 0,0%
fails in last 351 master runs.
*
[jira] [Commented] (IGNITE-10177) cleanup Junit 3 from the project
[
https://issues.apache.org/jira/browse/IGNITE-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726331#comment-16726331
]
Ignite TC Bot commented on IGNITE-10177:
{panel:title=-- Run :: All (Nightly): No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All (Nightly)*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2605919buildTypeId=IgniteTests24Java8_RunAllNightly]
> cleanup Junit 3 from the project
>
>
> Key: IGNITE-10177
> URL: https://issues.apache.org/jira/browse/IGNITE-10177
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent task for more details.
> # remove Junit3-specific parts of API of GridAbstractTest and its subclasses
> # remove dependencies from Junit 3 in Maven (if there are any)
> # migrate tests that were missed at prior steps for various reasons:
> ## untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass
> which currently conflict with Junit4 execution because of using constructors
> and make them properly use {{@Test}} annotation
> ## find out why
> {{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
> start running slow / timing out after adding Junit 4 annotations (reproduced
> this on teamcity and locally as was discovered in IGNITE-10175)
> ## find out why {{IgniteTwitterStreamerTest}} runs fine under JUnit 3 but
> starts failing after move to JUnit 4
> ## IgniteCachePartitionedQuerySelfTest,
> IgniteCacheReplicatedQueryP2PDisabledSelfTest, ComputeUtilsTest,
> CacheBasedDatasetBuilderTest, CacheBasedDatasetTest,
> GridPartitionedCacheJtaLookupClassNameSelfTest,
> GridReplicatedCacheJtaLookupClassNameSelfTest (there were problems migrating
> these at IGNITE-10176)
> ## find out why tests in logging suite failed on teamcity (not locally) when
> setup method was annotated {{@Before}}
> ## (!) note part of this work related to
> {{IgniteConfigVariationsAbstractTest}} is expected to be done separately per
> IGNITE-10739
> # in tests suite classes, change {{extends TestSuite}} to either
> {{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
> # find and update all Junit3-specific code that {{extends TestCase}}
> # execute junit related inspections of IDE and analyse results
> # remove redundant references to {{JUnit4.class}} if there are any (like in
> {{@RunWith(JUnit4.class)}})
> (i) per discussion with [~EdShangGG] plan to to do this in a separate
> ticket for smoother merges - IGNITE-10758
> Side note if for some reason it turns out critically important to keep test
> suites names (by default Junit 4 will use suite class names instead),
> approach with custom description annotation [described
> here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
> can be used to address that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8911) While cache is restarting it's possible to start new cache with this name
[ https://issues.apache.org/jira/browse/IGNITE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726330#comment-16726330 ] ASF GitHub Bot commented on IGNITE-8911: GitHub user EdShangGG opened a pull request: https://github.com/apache/ignite/pull/5717 IGNITE-8911 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8911-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5717.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 #5717 commit ec1b9175835e5ab8f34a96af3b7df88d67850def Author: Eduard Shangareev Date: 2018-12-11T09:30:06Z IGNITE-8911 commit af426af1195bb9076a41f0025abc3976ebba2e9c Author: Eduard Shangareev Date: 2018-12-20T23:39:44Z IGNITE-8911 > While cache is restarting it's possible to start new cache with this name > - > > Key: IGNITE-8911 > URL: https://issues.apache.org/jira/browse/IGNITE-8911 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.8 > > > We have the state "restarting" for caches when we certainly now that these > caches would start at some moment in future. But we could start new cache > with the same name. > Plus, NPE is throwing when we try to get proxy for such caches (in > "restarting" state). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8911) While cache is restarting it's possible to start new cache with this name
[ https://issues.apache.org/jira/browse/IGNITE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726329#comment-16726329 ] ASF GitHub Bot commented on IGNITE-8911: Github user EdShangGG closed the pull request at: https://github.com/apache/ignite/pull/4605 > While cache is restarting it's possible to start new cache with this name > - > > Key: IGNITE-8911 > URL: https://issues.apache.org/jira/browse/IGNITE-8911 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.8 > > > We have the state "restarting" for caches when we certainly now that these > caches would start at some moment in future. But we could start new cache > with the same name. > Plus, NPE is throwing when we try to get proxy for such caches (in > "restarting" state). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10177) cleanup Junit 3 from the project
[
https://issues.apache.org/jira/browse/IGNITE-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726318#comment-16726318
]
ASF GitHub Bot commented on IGNITE-10177:
-
Github user oignatenko closed the pull request at:
https://github.com/apache/ignite/pull/5678
> cleanup Junit 3 from the project
>
>
> Key: IGNITE-10177
> URL: https://issues.apache.org/jira/browse/IGNITE-10177
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent task for more details.
> # remove Junit3-specific parts of API of GridAbstractTest and its subclasses
> # remove dependencies from Junit 3 in Maven (if there are any)
> # migrate tests that were missed at prior steps for various reasons:
> ## untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass
> which currently conflict with Junit4 execution because of using constructors
> and make them properly use {{@Test}} annotation
> ## find out why
> {{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
> start running slow / timing out after adding Junit 4 annotations (reproduced
> this on teamcity and locally as was discovered in IGNITE-10175)
> ## find out why {{IgniteTwitterStreamerTest}} runs fine under JUnit 3 but
> starts failing after move to JUnit 4
> ## IgniteCachePartitionedQuerySelfTest,
> IgniteCacheReplicatedQueryP2PDisabledSelfTest, ComputeUtilsTest,
> CacheBasedDatasetBuilderTest, CacheBasedDatasetTest,
> GridPartitionedCacheJtaLookupClassNameSelfTest,
> GridReplicatedCacheJtaLookupClassNameSelfTest (there were problems migrating
> these at IGNITE-10176)
> ## find out why tests in logging suite failed on teamcity (not locally) when
> setup method was annotated {{@Before}}
> ## (!) note part of this work related to
> {{IgniteConfigVariationsAbstractTest}} is expected to be done separately per
> IGNITE-10739
> # in tests suite classes, change {{extends TestSuite}} to either
> {{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
> # find and update all Junit3-specific code that {{extends TestCase}}
> # execute junit related inspections of IDE and analyse results
> # remove redundant references to {{JUnit4.class}} if there are any (like in
> {{@RunWith(JUnit4.class)}})
> (i) per discussion with [~EdShangGG] plan to to do this in a separate
> ticket for smoother merges - IGNITE-10758
> Side note if for some reason it turns out critically important to keep test
> suites names (by default Junit 4 will use suite class names instead),
> approach with custom description annotation [described
> here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
> can be used to address that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9989) JDBC v2: getPrimaryKeys always returns constant COLUMN_NAME, KEY_SEQ, PK_NAME
[ https://issues.apache.org/jira/browse/IGNITE-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726313#comment-16726313 ] ASF GitHub Bot commented on IGNITE-9989: Github user pavel-kuznetsov closed the pull request at: https://github.com/apache/ignite/pull/5308 > JDBC v2: getPrimaryKeys always returns constant COLUMN_NAME, KEY_SEQ, PK_NAME > - > > Key: IGNITE-9989 > URL: https://issues.apache.org/jira/browse/IGNITE-9989 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Labels: jdbc > > Jdbc v2 driver has hardcoded values for meta attibutes : > COLUMN_NAME = _KEY > KEY_SEQ = 1 > PK_NAME = _KEY > But this values should be different for different tables. > how to reproduce: > 1) connect to the cluser using jdbcv2 driver > 2) CREATE TABLE TAB (ID LONG, SEC_ID LONG, VAL LONG, PRIMARY KEY(ID, SEC_ID)) > 3) check result of connection.getMetadata().getPrimaryKeys() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9989) JDBC v2: getPrimaryKeys always returns constant COLUMN_NAME, KEY_SEQ, PK_NAME
[ https://issues.apache.org/jira/browse/IGNITE-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726312#comment-16726312 ] ASF GitHub Bot commented on IGNITE-9989: GitHub user pavel-kuznetsov opened a pull request: https://github.com/apache/ignite/pull/5716 IGNITE-9989 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9989-new2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5716.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 #5716 commit 42bb29bf24ab221c4a16655cce4c098bc65535b1 Author: Pavel Kuznetsov Date: 2018-12-12T20:27:51Z ignite-10645: Removed runtime property configuration. Previously, in some cases (key is not of sql type and keyFields is null) QueryBinaryProperty was configured at runtime (at first cache.put()). Removed this logic, so now properties are configured when all binary metadata gets processed. commit 4aaaea81caa1d81ccd73b8e7b1d43ca34377b791 Author: Pavel Kuznetsov Date: 2018-12-12T20:30:55Z ignite-10645: Updated incorrect tests. These tests used non-sql KeyObject, and expected that keyFields get filled somehow (what is not supported). Added explicit keyFilds declaration. commit acfb97f0345a622bf4e2b948cdb7236ce6169b8c Author: Pavel Kuznetsov Date: 2018-12-13T10:17:45Z ignite-10645: Removed garbage; Fixed test. Removed accidentally added test class. Fixed configuration of forgotten test. commit 21045b5f0bd4f5701b92518bd1289a54107354bb Author: Pavel Kuznetsov Date: 2018-12-13T14:53:26Z ignite-10645: Updated doc. commit bed7b76ade5990f4392e1169b060ef82dc67f3fe Author: Pavel Kuznetsov Date: 2018-12-14T16:53:26Z ignite-10645: Updated comment. Simplified condition. Since we don't decide is property a "key-property" at runtime, condition for isKeyProp could be simplified. Also corrected comment about binary property creation. commit e438c5ab535924f967b0a203c3646720e9596340 Author: Pavel Kuznetsov Date: 2018-12-17T02:11:29Z ignite-10645: Added validation of insert queries. Insert query should contain all primary key columns. commit 824e7531a58abbed31250f870467f645bf324977 Author: Pavel Kuznetsov Date: 2018-12-17T02:18:24Z ignite-10645: Added tests for insert query validation. commit 681e4452e31f6f6e318e2edf7c6b4831baa6eb55 Author: Pavel Kuznetsov Date: 2018-12-17T19:37:37Z ignite-10645: Simplified validation. Updated tests. Decided validate inserts only for cases "no key columns specified" and "_key mixed with other key columns". commit 85f36b18342e82b25945c1294484082692c93f73 Author: Pavel Kuznetsov Date: 2018-12-18T12:50:03Z Merge remote-tracking branch 'origin/master' into ignite-10645 commit e4f340b55d7a8e7da0ebc2d5d7e14ba92a6f5ba2 Author: Pavel Kuznetsov Date: 2018-12-18T12:52:25Z ignite-10645: fix import after merge. commit 556d584da6a235643fb48e9fb69c0aa2794dd1df Author: Pavel Kuznetsov Date: 2018-12-18T14:13:09Z ignite-10645: Fixed test. This test fails only on teamcity due to locally it does have Indexing in the classpath. On TC it does. So in local run QueryEntity it is not validated. Since validation is not scope of these tests, just fixed QueryEntity configuration which was not correct. commit 1852e027aea67c6b822370395ddec03ab5c9e53c Author: Pavel Kuznetsov Date: 2018-11-06T14:39:11Z ignite-9989: Updated tests to work with many tables. Backported test for primary keys metadata from metadata test of jdbc thin driver. This change made IGNITE-10118 highlighted. commit 6bfa27b57b978247bfa4998e7523bb361107ed56 Author: Pavel Kuznetsov Date: 2018-12-07T15:34:57Z ignite-9989: jdbc thin metadata logic for jdbcv2 driver. Imported logic of getting primary keys from thin driver to v2 driver. commit 28a6c34748770aa97836d0452d89581f4b37b67d Author: Pavel Kuznetsov Date: 2018-12-18T18:30:01Z ignite-9989: fixed test. New table in the test setup have been added, updated the test. commit a5c85628c7829b71bcf5758766ecd48ee2f5c92d Author: Pavel Kuznetsov Date: 2018-12-18T18:47:59Z ignite-9989: Unified jdbcv2 and thin keys metadata logic. commit 1022379a9cf35f02b170b003251fd023c5b8464b Author: Pavel Kuznetsov Date: 2018-12-19T16:06:11Z ignite-9989: Unified jdbcv2 and thin getTables metadata logic. commit 69ef2deb26043823ab6e84db78c80746cf6a7f5a Author: Pavel Kuznetsov Date: 2018-12-19T16:07:30Z ignite-9989: Ensure not closed on getPKs in jdbc v2. commit d7bf5b4981598cba438fc3f8c92fedb30bb8980b Author: Pavel Kuznetsov Date: 2018-12-19T22:57:43Z
[jira] [Commented] (IGNITE-10739) get rid of using JUnit 3 API in IgniteConfigVariationsAbstractTest
[ https://issues.apache.org/jira/browse/IGNITE-10739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726297#comment-16726297 ] ASF GitHub Bot commented on IGNITE-10739: - GitHub user oignatenko opened a pull request: https://github.com/apache/ignite/pull/5715 IGNITE-10739 get rid of using JUnit 3 API in IgniteConfigVariationsAbstractTest You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10739 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5715.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 #5715 commit ff4699bebf2571cbd648cbf8bccf1e957c7547e5 Author: Oleg Ignatenko Date: 2018-12-02T23:35:51Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - added @Test -- verified with diffs overview commit a72e24ea010fd7333b7425c349e3de1373aed0fc Author: Oleg Ignatenko Date: 2018-12-03T00:24:34Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit eeeba1cc2f9d9dc02065c19c7c1079008bf73e00 Author: Oleg Ignatenko Date: 2018-12-03T00:26:13Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit 9304b5f31ef712708be7d04b68a963d8bf4b050d Author: Oleg Ignatenko Date: 2018-12-03T00:29:51Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit 7eaf7a0252fb347f19d192859c410c3c29f7c4b6 Author: Oleg Ignatenko Date: 2018-12-03T00:39:54Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit eaee42ebf611c1617993177d6466e81399c3ebdc Author: Oleg Ignatenko Date: 2018-12-03T00:48:56Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit 62738a3820d4057a9c34ad8b2c6e85959ebfc67e Author: Oleg Ignatenko Date: 2018-12-03T00:57:00Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit afb495f9e97e6e15b0c4c29f6d57dd2bbd569f1c Author: Oleg Ignatenko Date: 2018-12-03T08:39:38Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit 3b56b742b52a516a4244d2a07635a99d9abeba18 Author: Oleg Ignatenko Date: 2018-12-03T09:06:45Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit 3835772a72a99882f9d6cd2557001c9db94ed416 Author: Oleg Ignatenko Date: 2018-12-03T09:31:45Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit ac6be2c4e07748f34da5d83ce3e9f20786ead2fc Author: Oleg Ignatenko Date: 2018-12-03T10:46:59Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit 9f663a9c857f76fcb0e56c194cc2d6ec10f6888b Author: Oleg Ignatenko Date: 2018-12-03T11:13:26Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit e2eae3201a88c3d9800b9964ce9ca4096ed3d85f Author: Oleg Ignatenko Date: 2018-12-03T11:31:35Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit f9ccc80de28fb2fc64c96d695f5f906a8cd9a946 Author: Oleg Ignatenko Date: 2018-12-03T12:40:21Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit 3eadd0abf6f58a0a3d8fe8464bb08879d412bca1 Author: Oleg Ignatenko Date: 2018-12-03T13:33:00Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit 28d9f854993cb99867803cfe0126cf723e071cc5 Author: Oleg Ignatenko Date: 2018-12-03T13:54:52Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit ed54719377f694d0111740c0bbd92dcf5294e6c6 Author: Oleg Ignatenko Date: 2018-12-03T14:10:26Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit fb97a8c23881d1d1c50423dcea6ac519a36c195a Author: Oleg Ignatenko Date: 2018-12-03T14:26:19Z IGNITE-10175 migrate core module tests from Junit 3 to 4 - wip - migrating -- verified with diffs overview commit 063f7ae0164924a775b4235ebd0f704017bc2c73 Author: Oleg Ignatenko Date: 2018-12-03T14:45:00Z IGNITE-10175 migrate core module tests
[jira] [Commented] (IGNITE-10238) Intermittent Client Nodes suite hang
[
https://issues.apache.org/jira/browse/IGNITE-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726247#comment-16726247
]
Amelchev Nikita commented on IGNITE-10238:
--
[~sergey-chugunov] , [~agoncharuk] , Thanks for helping with the issue!
The problem was as Sergey described above - in marker interface. If it present
in disco thread - metadata will not await update. And deadlock will not happen.
I have [prepared PR|https://github.com/apache/ignite/pull/5439/files] to fix it
and improved reproducer (I was unable to write it using message debugging,
latches and etc). TC looks good.
Could you review changes, please?
> Intermittent Client Nodes suite hang
>
>
> Key: IGNITE-10238
> URL: https://issues.apache.org/jira/browse/IGNITE-10238
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Amelchev Nikita
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> There are occasional hangs of Client Nodes suite in master. A quick peek at
> the thread dumps reveals an interesting deadlock (only relevant parts of the
> thread dump are left):
> {code}
> "disco-notifier-worker-#634%internal.IgniteClientReconnectApiExceptionTest0%"
> #791 prio=5 os_prio=0 tid=0x7f990c12d800 nid=0x11b9 waiting on condition
> [0x7f991a0eb000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:656)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:206)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1293)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2007)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:286)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:185)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1984)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:703)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:188)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:874)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1984)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:703)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:188)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:874)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:313)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:101)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:81)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10131)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10160)
> at
> org.apache.ignite.internal.GridEventConsumeHandler.p2pUnmarshal(GridEventConsumeHandler.java:390)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1362)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:111)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:203)
> at
>
[jira] [Commented] (IGNITE-8911) While cache is restarting it's possible to start new cache with this name
[ https://issues.apache.org/jira/browse/IGNITE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726256#comment-16726256 ] Eduard Shangareev commented on IGNITE-8911: --- [~DmitriyGovorukhin], I don't think that statement in your first point is true. As I see, GridStripedReadWriteLock contains collections of java ReadWriteLock and it is all. > While cache is restarting it's possible to start new cache with this name > - > > Key: IGNITE-8911 > URL: https://issues.apache.org/jira/browse/IGNITE-8911 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.8 > > > We have the state "restarting" for caches when we certainly now that these > caches would start at some moment in future. But we could start new cache > with the same name. > Plus, NPE is throwing when we try to get proxy for such caches (in > "restarting" state). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10238) Intermittent Client Nodes suite hang
[
https://issues.apache.org/jira/browse/IGNITE-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726241#comment-16726241
]
Ignite TC Bot commented on IGNITE-10238:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2603346buildTypeId=IgniteTests24Java8_RunAll]
> Intermittent Client Nodes suite hang
>
>
> Key: IGNITE-10238
> URL: https://issues.apache.org/jira/browse/IGNITE-10238
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Amelchev Nikita
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> There are occasional hangs of Client Nodes suite in master. A quick peek at
> the thread dumps reveals an interesting deadlock (only relevant parts of the
> thread dump are left):
> {code}
> "disco-notifier-worker-#634%internal.IgniteClientReconnectApiExceptionTest0%"
> #791 prio=5 os_prio=0 tid=0x7f990c12d800 nid=0x11b9 waiting on condition
> [0x7f991a0eb000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:656)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:206)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1293)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2007)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:286)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:185)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1984)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:703)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:188)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:874)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1984)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:703)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:188)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:874)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:313)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:101)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:81)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10131)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10160)
> at
> org.apache.ignite.internal.GridEventConsumeHandler.p2pUnmarshal(GridEventConsumeHandler.java:390)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1362)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:111)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:203)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:194)
> at
>
[jira] [Commented] (IGNITE-10721) Documentation: Fix UUID thin client format description
[ https://issues.apache.org/jira/browse/IGNITE-10721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726232#comment-16726232 ] Alexey Kosenchuk commented on IGNITE-10721: --- [~isapego] In my opinion, it's not clear what is "64 most significant bits of UUID" and "64 least significant bits of UUID". Because what is UUID is not clarified. As I wrote above, if UUID here is https://tools.ietf.org/html/rfc4122 then it should be specified how it's fields (time_low, time_mid,... and all other) are binary encoded here. Or UUID here is any generic 128-bit number, not necessary RFC-4122? That should be clearly explained, I believe. In any case, an example of binary encoding may help. Also, why the current 2.7 spec is updated? I think, such update of the spec should go into the new version. > Documentation: Fix UUID thin client format description > -- > > Key: IGNITE-10721 > URL: https://issues.apache.org/jira/browse/IGNITE-10721 > Project: Ignite > Issue Type: Task > Components: documentation, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.8 > > > UUID thin client format description [1] need to be fixed. The actual format > of the UUID should be two longs, not a single 128-bit value. Two longs > written in little-endian are not equal to one 128-bit number. > [1] - > https://apacheignite.readme.io/docs/binary-client-protocol-data-format#section-uuid-guid- -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10771) Print troubleshooting hint when exchange latch got stucked
Pavel Kovalenko created IGNITE-10771:
Summary: Print troubleshooting hint when exchange latch got stucked
Key: IGNITE-10771
URL: https://issues.apache.org/jira/browse/IGNITE-10771
Project: Ignite
Issue Type: Improvement
Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Fix For: 2.8
Sometimes users face with a problem when exchange latch can't be completed:
{noformat}
2018-12-12 07:07:57:563 [exchange-worker-#42] WARN
o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture:488 - Unable to await
partitions release latch within timeout: ClientLatch
[coordinator=ZookeeperClusterNode [id=6b9fc6e4-5b6a-4a98-be4d-6bc1aa5c014c,
addrs=[172.17.0.1, 10.0.230.117, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3,
loc=false, client=false], ackSent=true, super=CompletableLatch [id=exchange,
topVer=AffinityTopologyVersion [topVer=45, minorTopVer=1]]]
{noformat}
It may indicate that some node in a cluster can' t finish partitions release
(finish all ongoing operations at the previous topology version) or it can be
silent network problem.
We should print to log a hint how to troubleshoot it to reduce the number of
questions about such problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10762) migrate test suites from Junit 3 to 4
[
https://issues.apache.org/jira/browse/IGNITE-10762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726115#comment-16726115
]
Oleg Ignatenko commented on IGNITE-10762:
-
(i) Test suites containing fixed set of classes can be easily reworked to
idiomatic JUnit 4 way with {{@SuiteClasses}} etc. If {{suite()}} method
contains some initialization code this code should probably be extracted to
separate method annotated with {{@BeforeClass}}.
For test suites that contain dynamically created sets of test classes the way
would be somewhat more complicated, options to consider are either extending
{{Suite}} class ([as shown eg
here|http://day-today-learning.blogspot.com/2014/08/dynamic-suite-for-junit-test-cases.html])
or by using {{JUnitCore}} API ([as shown eg
here|https://www.logicbig.com/tutorials/unit-testing/junit/junit-core.html]).
> migrate test suites from Junit 3 to 4
> -
>
> Key: IGNITE-10762
> URL: https://issues.apache.org/jira/browse/IGNITE-10762
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> It seems that {{@Ignore}} annotation is processed incorrectly when a test in
> Junit 4 style is included into Junit 3 test suite (wrapped into
> {{JUnit4TestAdapter}}). Actually such test is skipped silently when it is
> called during a suite execution. So, for full a blown usage of {{@Ignore}}
> test suites must be migrated to Junit 4 as well. Expected behavior here is
> reporting that a particular test method was ignored after tests execution.
> Ignored tests should be visible in CI.
> Apparently such unexpected behavior of {{@Ignore}} can be caused by
> {{JUnit4TestAdapter}} as it explicitly filters test method marked with this
> annotation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10770) MVCC: testInsertAndQueryMultipleCaches in JDBC suite is flaky
Roman Kondakov created IGNITE-10770:
---
Summary: MVCC: testInsertAndQueryMultipleCaches in JDBC suite is
flaky
Key: IGNITE-10770
URL: https://issues.apache.org/jira/browse/IGNITE-10770
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Roman Kondakov
These tests are flaky:
{{JdbcThinTransactionsServerNoAutoCommitComplexSelfTest.testInsertAndQueryMultipleCaches}}
{{JdbcThinTransactionsServerAutoCommitComplexSelfTest.testInsertAndQueryMultipleCaches}}
The cause should be investigated.
Stacktrace:
{noformat}
[2018-12-18
07:14:00,837][ERROR][jdbc-request-handler-worker-#5064%thin.JdbcThinTransactionsServerAutoCommitComplexSelfTest0%][JdbcRequestHandler]
Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest
[schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=SELECT * FROM City left
join Company on City.id = Company."cityid" left join "Person".Person p on
City.id = p.cityid WHERE p.id = 6 or company.id = 6, args=Object[] [],
stmtType=ANY_STATEMENT_TYPE, autoCommit=false]]
javax.cache.CacheException: Caches have distinct sets of data nodes
[cache1=City, cache2=Person]
at
org.apache.ignite.internal.processors.query.h2.twostep.ReducePartitionMapper.stableDataNodes(ReducePartitionMapper.java:242)
at
org.apache.ignite.internal.processors.query.h2.twostep.ReducePartitionMapper.nodesForPartitions(ReducePartitionMapper.java:119)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:515)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1143)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcQueryCursor.(JdbcQueryCursor.java:61)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:519)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:245)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandlerWorker.body(JdbcRequestHandlerWorker.java:89)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10752) MVCC: Tests invariants are violated sometimes
[
https://issues.apache.org/jira/browse/IGNITE-10752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10752:
Description:
Sometimes tests are failed by violated invariants errors. For example, when
total sum on accounts is not as expected.
Muted tests:
* {{CacheMvccPartitionedCoordinatorFailoverTest}}
**
{{testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
**
{{testUpdate_N_Objects_ClientServer_Backups1_PutGet_CoordinatorFails_Persistence}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups1_CoordinatorFails}}
** {{testAccountsTxGet_ClientServer_Backups2_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups1_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups0_CoordinatorFails}}
** {{testGetReadInProgressCoordinatorFails}}
** {{testGetReadInsideTxInProgressCoordinatorFails_ReadDelay}}
* {{CacheMvccReplicatedCoordinatorFailoverTest}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups0_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
* {{CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple}}
* {{DataStreamProcessorMvccPersistenceSelfTest.testTryFlush}}
* {{IgniteCacheGroupsTest.testCreateDestroyCachesMvccTxReplicated}}
*
{{CacheMvccReplicatedSqlCoordinatorFailoverTest.testUpdate_N_Objects_ClientServer_Backups0_Sql_Persistence}}
* {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}
** {{testUpdate_N_Objects_ClientServer_Backups2_Sql}}
** {{testUpdate_N_Objects_ClientServer_Backups1_Sql_Persistence}}
** {{testUpdate_N_Objects_SingleNode_Sql_Persistence}}
** {{testUpdate_N_Objects_ClientServer_Backups0_Sql_Persistence}}
**
{{testPutAllGetAll_ClientServer_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
** {{testPutAllGetAll_Server_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
** {{testPutAllGetAll_ClientServer_Backups3_RestartCoordinator_ScanDml}}
** {{testAccountsTxSql_Server_Backups0_CoordinatorFails}}
** {{testAccountsTxSql_Server_Backups1_CoordinatorFails_Persistence}}
{noformat}
junit.framework.AssertionFailedError: Unexpected error:
junit.framework.AssertionFailedError: expected:<0> but was:<4>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1362)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1350)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
{noformat}
was:
Sometimes tests are failed by violated invariants errors. For example, when
total sum on accounts is not as expected.
Muted tests:
* {{CacheMvccPartitionedCoordinatorFailoverTest}}
**
{{testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
**
{{testUpdate_N_Objects_ClientServer_Backups1_PutGet_CoordinatorFails_Persistence}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups1_CoordinatorFails}}
** {{testAccountsTxGet_ClientServer_Backups2_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups1_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups0_CoordinatorFails}}
** {{testGetReadInProgressCoordinatorFails}}
** {{testGetReadInsideTxInProgressCoordinatorFails_ReadDelay}}
* {{CacheMvccReplicatedCoordinatorFailoverTest}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups0_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
* {{CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple}}
* {{DataStreamProcessorMvccPersistenceSelfTest.testTryFlush}}
* {{IgniteCacheGroupsTest.testCreateDestroyCachesMvccTxReplicated}}
*
{{CacheMvccReplicatedSqlCoordinatorFailoverTest.testUpdate_N_Objects_ClientServer_Backups0_Sql_Persistence}}
* {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}
** {{testUpdate_N_Objects_ClientServer_Backups2_Sql}}
** {{testUpdate_N_Objects_ClientServer_Backups1_Sql_Persistence}}
** {{testUpdate_N_Objects_SingleNode_Sql_Persistence}}
**
{{testPutAllGetAll_ClientServer_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
** {{testPutAllGetAll_Server_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
** {{testPutAllGetAll_ClientServer_Backups3_RestartCoordinator_ScanDml}}
** {{testAccountsTxSql_Server_Backups0_CoordinatorFails}}
** {{testAccountsTxSql_Server_Backups1_CoordinatorFails_Persistence}}
{noformat}
junit.framework.AssertionFailedError: Unexpected error:
junit.framework.AssertionFailedError: expected:<0> but
[jira] [Created] (IGNITE-10769) MVCC: CacheMvccContinuousQueryClientTest.testNodeJoinsRestartQuery fails sometimes
Roman Kondakov created IGNITE-10769:
---
Summary: MVCC:
CacheMvccContinuousQueryClientTest.testNodeJoinsRestartQuery fails sometimes
Key: IGNITE-10769
URL: https://issues.apache.org/jira/browse/IGNITE-10769
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Roman Kondakov
Test {{CacheMvccContinuousQueryClientTest.testNodeJoinsRestartQuery}} fails
sometimes.
{noformat}
class org.apache.ignite.IgniteException: Unable to find 1 requied keys.
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.findKeys(GridCommonAbstractTest.java:1128)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.primaryKeys(GridCommonAbstractTest.java:1071)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.primaryKey(GridCommonAbstractTest.java:1343)
at
org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientTest.testNodeJoinsRestartQuery(IgniteCacheContinuousQueryClientTest.java:185)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:149)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2106)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2123)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10763) MVCC: Transaction already completed error in some tests
[
https://issues.apache.org/jira/browse/IGNITE-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10763:
Description:
"Transaction is already completed" error occurs time to time in some tests.
Reproducer:
{{CacheMvccReplicatedSqlTxQueriesTest.testReplicatedAndPartitionedUpdateSingleTransaction}}
{{CacheMvccPartitionedSqlTxQueriesWithReducerTest.testQueryReducerDeadlockInsertWithTxTimeout}}
{noformat}
class org.apache.ignite.internal.processors.query.IgniteSQLException:
Transaction is already completed.
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.checkActive(MvccUtils.java:660)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:832)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:813)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:796)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.runQueryTwoStep(IgniteH2Indexing.java:1131)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunDistributedQuery(IgniteH2Indexing.java:1990)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1636)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1526)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2167)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2162)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2670)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2176)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2196)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2157)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2118)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2091)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccReplicatedSqlTxQueriesTest.runSql(CacheMvccReplicatedSqlTxQueriesTest.java:234)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccReplicatedSqlTxQueriesTest.testReplicatedAndPartitionedUpdateSingleTransaction(CacheMvccReplicatedSqlTxQueriesTest.java:202)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2121)
at java.lang.Thread.run(Thread.java:748)
{noformat}
was:
"Transaction is already completed" error occurs time to time in some tests.
Reproducer:
{{CacheMvccReplicatedSqlTxQueriesTest.testReplicatedAndPartitionedUpdateSingleTransaction}}
{noformat}
class org.apache.ignite.internal.processors.query.IgniteSQLException:
Transaction is already completed.
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.checkActive(MvccUtils.java:660)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:832)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:813)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:796)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.runQueryTwoStep(IgniteH2Indexing.java:1131)
at
[jira] [Commented] (IGNITE-10730) MVCC TX: Batch WAL datarecords
[ https://issues.apache.org/jira/browse/IGNITE-10730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726067#comment-16726067 ] ASF GitHub Bot commented on IGNITE-10730: - GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/5714 IGNITE-10730: Batch mvcc wal records in tx. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10730 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5714.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 #5714 commit dfe77f6d85c28ad8ef97447105a1480ce43bee8a Author: Andrey V. Mashenkov Date: 2018-12-20T17:32:19Z IGNITE-10730: WIP. > MVCC TX: Batch WAL datarecords > -- > > Key: IGNITE-10730 > URL: https://issues.apache.org/jira/browse/IGNITE-10730 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Igor Seliverstov >Assignee: Andrew Mashenkov >Priority: Major > > on MVCC updates we make changes one by one and WAL records are written > straight after successful update under the same checkpoint lock. This > produces contention on wal flush operations and harm overall performance. But > we need only one guarantee - all the records have to be written into the log > before prepare start. That means we free to batch such writes (for example 10 > rows in one data record) it shouldn't cause memory issues but will resolve > contention. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10752) MVCC: Tests invariants are violated sometimes
[
https://issues.apache.org/jira/browse/IGNITE-10752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10752:
Description:
Sometimes tests are failed by violated invariants errors. For example, when
total sum on accounts is not as expected.
Muted tests:
* {{CacheMvccPartitionedCoordinatorFailoverTest}}
**
{{testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
**
{{testUpdate_N_Objects_ClientServer_Backups1_PutGet_CoordinatorFails_Persistence}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups1_CoordinatorFails}}
** {{testAccountsTxGet_ClientServer_Backups2_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups1_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups0_CoordinatorFails}}
** {{testGetReadInProgressCoordinatorFails}}
** {{testGetReadInsideTxInProgressCoordinatorFails_ReadDelay}}
* {{CacheMvccReplicatedCoordinatorFailoverTest}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups0_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
* {{CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple}}
* {{DataStreamProcessorMvccPersistenceSelfTest.testTryFlush}}
* {{IgniteCacheGroupsTest.testCreateDestroyCachesMvccTxReplicated}}
*
{{CacheMvccReplicatedSqlCoordinatorFailoverTest.testUpdate_N_Objects_ClientServer_Backups0_Sql_Persistence}}
* {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}
** {{testUpdate_N_Objects_ClientServer_Backups2_Sql}}
** {{testUpdate_N_Objects_ClientServer_Backups1_Sql_Persistence}}
** {{testUpdate_N_Objects_SingleNode_Sql_Persistence}}
**
{{testPutAllGetAll_ClientServer_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
** {{testPutAllGetAll_Server_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
** {{testPutAllGetAll_ClientServer_Backups3_RestartCoordinator_ScanDml}}
** {{testAccountsTxSql_Server_Backups0_CoordinatorFails}}
** {{testAccountsTxSql_Server_Backups1_CoordinatorFails_Persistence}}
{noformat}
junit.framework.AssertionFailedError: Unexpected error:
junit.framework.AssertionFailedError: expected:<0> but was:<4>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1362)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1350)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
{noformat}
was:
Sometimes tests are failed by violated invariants errors. For example, when
total sum on accounts is not as expected.
Muted tests:
* {{CacheMvccPartitionedCoordinatorFailoverTest}}
**
{{testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
**
{{testUpdate_N_Objects_ClientServer_Backups1_PutGet_CoordinatorFails_Persistence}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups1_CoordinatorFails}}
** {{testAccountsTxGet_ClientServer_Backups2_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups1_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups0_CoordinatorFails}}
** {{testGetReadInProgressCoordinatorFails}}
** {{testGetReadInsideTxInProgressCoordinatorFails_ReadDelay}}
* {{CacheMvccReplicatedCoordinatorFailoverTest}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups0_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
* {{CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple}}
* {{DataStreamProcessorMvccPersistenceSelfTest.testTryFlush}}
* {{IgniteCacheGroupsTest.testCreateDestroyCachesMvccTxReplicated}}
*
{{CacheMvccReplicatedSqlCoordinatorFailoverTest.testUpdate_N_Objects_ClientServer_Backups0_Sql_Persistence}}
* {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}
** {{testUpdate_N_Objects_ClientServer_Backups2_Sql}}
**
{{testPutAllGetAll_ClientServer_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
** {{testPutAllGetAll_Server_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
** {{testAccountsTxSql_Server_Backups0_CoordinatorFails}}
** {{testAccountsTxSql_Server_Backups1_CoordinatorFails_Persistence}}
{noformat}
junit.framework.AssertionFailedError: Unexpected error:
junit.framework.AssertionFailedError: expected:<0> but was:<4>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1362)
at
[jira] [Updated] (IGNITE-10768) MVCC: CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned may hang
[
https://issues.apache.org/jira/browse/IGNITE-10768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10768:
Ignite Flags: (was: Docs Required)
> MVCC:
> CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned
> may hang
> -
>
> Key: IGNITE-10768
> URL: https://issues.apache.org/jira/browse/IGNITE-10768
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Labels: CQ, mvcc_stabilization_stage_1
>
> Test
> {{CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned}}
> may hang sometimes.
>
> {noformat}
> Thread [name="test-runner-#209301%mvcc.CacheMvccBasicContinuousQueryTest%",
> id=228123, state=WAITING, blockCnt=5, waitCnt=89]
> 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:179)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:142)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccBasicContinuousQueryTest.checkUpdateCountersGapIsProcessedSimple(CacheMvccBasicContinuousQueryTest.java:346)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned(CacheMvccBasicContinuousQueryTest.java:257)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at
> o.a.i.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2121)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10768) MVCC: CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned may hang
[
https://issues.apache.org/jira/browse/IGNITE-10768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10768:
Labels: CQ mvcc_stabilization_stage_1 (was: )
> MVCC:
> CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned
> may hang
> -
>
> Key: IGNITE-10768
> URL: https://issues.apache.org/jira/browse/IGNITE-10768
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Labels: CQ, mvcc_stabilization_stage_1
>
> Test
> {{CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned}}
> may hang sometimes.
>
> {noformat}
> Thread [name="test-runner-#209301%mvcc.CacheMvccBasicContinuousQueryTest%",
> id=228123, state=WAITING, blockCnt=5, waitCnt=89]
> 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:179)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:142)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccBasicContinuousQueryTest.checkUpdateCountersGapIsProcessedSimple(CacheMvccBasicContinuousQueryTest.java:346)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned(CacheMvccBasicContinuousQueryTest.java:257)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at
> o.a.i.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2121)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10768) MVCC: CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned may hang
Roman Kondakov created IGNITE-10768:
---
Summary: MVCC:
CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned
may hang
Key: IGNITE-10768
URL: https://issues.apache.org/jira/browse/IGNITE-10768
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Roman Kondakov
Test
{{CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned}}
may hang sometimes.
{noformat}
Thread [name="test-runner-#209301%mvcc.CacheMvccBasicContinuousQueryTest%",
id=228123, state=WAITING, blockCnt=5, waitCnt=89]
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:179)
at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:142)
at
o.a.i.i.processors.cache.mvcc.CacheMvccBasicContinuousQueryTest.checkUpdateCountersGapIsProcessedSimple(CacheMvccBasicContinuousQueryTest.java:346)
at
o.a.i.i.processors.cache.mvcc.CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned(CacheMvccBasicContinuousQueryTest.java:257)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at
o.a.i.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2121)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10177) cleanup Junit 3 from the project
[
https://issues.apache.org/jira/browse/IGNITE-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726048#comment-16726048
]
Ignite TC Bot commented on IGNITE-10177:
{panel:title=-- Run :: All (Nightly): No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All (Nightly)*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2595352buildTypeId=IgniteTests24Java8_RunAllNightly]
> cleanup Junit 3 from the project
>
>
> Key: IGNITE-10177
> URL: https://issues.apache.org/jira/browse/IGNITE-10177
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent task for more details.
> # remove Junit3-specific parts of API of GridAbstractTest and its subclasses
> # remove dependencies from Junit 3 in Maven (if there are any)
> # migrate tests that were missed at prior steps for various reasons:
> ## untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass
> which currently conflict with Junit4 execution because of using constructors
> and make them properly use {{@Test}} annotation
> ## find out why
> {{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
> start running slow / timing out after adding Junit 4 annotations (reproduced
> this on teamcity and locally as was discovered in IGNITE-10175)
> ## find out why {{IgniteTwitterStreamerTest}} runs fine under JUnit 3 but
> starts failing after move to JUnit 4
> ## IgniteCachePartitionedQuerySelfTest,
> IgniteCacheReplicatedQueryP2PDisabledSelfTest, ComputeUtilsTest,
> CacheBasedDatasetBuilderTest, CacheBasedDatasetTest,
> GridPartitionedCacheJtaLookupClassNameSelfTest,
> GridReplicatedCacheJtaLookupClassNameSelfTest (there were problems migrating
> these at IGNITE-10176)
> ## find out why tests in logging suite failed on teamcity (not locally) when
> setup method was annotated {{@Before}}
> ## (!) note part of this work related to
> {{IgniteConfigVariationsAbstractTest}} is expected to be done separately per
> IGNITE-10739
> # in tests suite classes, change {{extends TestSuite}} to either
> {{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
> # find and update all Junit3-specific code that {{extends TestCase}}
> # execute junit related inspections of IDE and analyse results
> # remove redundant references to {{JUnit4.class}} if there are any (like in
> {{@RunWith(JUnit4.class)}})
> (i) per discussion with [~EdShangGG] plan to to do this in a separate
> ticket for smoother merges - IGNITE-10758
> Side note if for some reason it turns out critically important to keep test
> suites names (by default Junit 4 will use suite class names instead),
> approach with custom description annotation [described
> here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
> can be used to address that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10767) MVCC: Unknown page type error during scan query
Roman Kondakov created IGNITE-10767:
---
Summary: MVCC: Unknown page type error during scan query
Key: IGNITE-10767
URL: https://issues.apache.org/jira/browse/IGNITE-10767
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Roman Kondakov
Sometimes "Unknown page type: 1" error occurs during scan query execution.
Reproducer:
{{CacheMvccReplicatedSqlCoordinatorFailoverTest.testPutAllGetAll_SingleNode_RestartCoordinator_ScanDml_Persistence}}
Stack trace:
{noformat}
junit.framework.AssertionFailedError: Unexpected error:
junit.framework.AssertionFailedError: Unexpected tx exception.
java.lang.IllegalStateException: Unknown page type: 1 pageId: 00010079
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.io(BPlusTree.java:5094)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$200(BPlusTree.java:90)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage(BPlusTree.java:5366)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.next(BPlusTree.java:5602)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$6.onHasNext(IgniteCacheOffheapManagerImpl.java:989)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:2993)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2962)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter$MvccTrackingIterator.hasNext(GridCacheQueryAdapter.java:963)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:114)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest.readAllByMode(CacheMvccAbstractTest.java:1918)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$5.apply(CacheMvccAbstractTest.java:1007)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$5.apply(CacheMvccAbstractTest.java:983)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1362)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1357)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10766) MVCC: CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed fails sporadically
Roman Kondakov created IGNITE-10766:
---
Summary: MVCC:
CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed fails sporadically
Key: IGNITE-10766
URL: https://issues.apache.org/jira/browse/IGNITE-10766
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Roman Kondakov
{{CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed}} sporadically
jangs on exchange. It should be investigated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10765) MVCC: MvccReplicatedTxPessimisticOriginatingNodeFailureRecoveryTest.testManyKeysRollback fails sometimes
Roman Kondakov created IGNITE-10765:
---
Summary: MVCC:
MvccReplicatedTxPessimisticOriginatingNodeFailureRecoveryTest.testManyKeysRollback
fails sometimes
Key: IGNITE-10765
URL: https://issues.apache.org/jira/browse/IGNITE-10765
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Roman Kondakov
{{MvccReplicatedTxPessimisticOriginatingNodeFailureRecoveryTest.testManyKeysRollback}}
fails sometimes. See trace bellow.
{noformat}
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at
org.apache.ignite.internal.processors.cache.distributed.IgniteTxPessimisticOriginatingNodeFailureAbstractSelfTest.testTxOriginatingNodeFails(IgniteTxPessimisticOriginatingNodeFailureAbstractSelfTest.java:260)
at
org.apache.ignite.internal.processors.cache.distributed.IgniteTxPessimisticOriginatingNodeFailureAbstractSelfTest.testManyKeysRollback(IgniteTxPessimisticOriginatingNodeFailureAbstractSelfTest.java:111)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2121)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10764) MVCC: Transactions failed to acquire lock within timeout
Roman Kondakov created IGNITE-10764:
---
Summary: MVCC: Transactions failed to acquire lock within timeout
Key: IGNITE-10764
URL: https://issues.apache.org/jira/browse/IGNITE-10764
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Roman Kondakov
Some tests failed sporadically due to a transaction timeout though they update
unique keys and deadlocks are not expected. It should be investigated.
Reproducers:
{{CacheMvccPartitionedSqlTxQueriesTest.testQueryInsertMultithread}}
{{CacheMvccReplicatedSqlTxQueriesTest.testQueryInsertMultithread}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10752) MVCC: Tests invariants are violated sometimes
[
https://issues.apache.org/jira/browse/IGNITE-10752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10752:
Description:
Sometimes tests are failed by violated invariants errors. For example, when
total sum on accounts is not as expected.
Muted tests:
* {{CacheMvccPartitionedCoordinatorFailoverTest}}
**
{{testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
**
{{testUpdate_N_Objects_ClientServer_Backups1_PutGet_CoordinatorFails_Persistence}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups1_CoordinatorFails}}
** {{testAccountsTxGet_ClientServer_Backups2_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups1_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups0_CoordinatorFails}}
** {{testGetReadInProgressCoordinatorFails}}
** {{testGetReadInsideTxInProgressCoordinatorFails_ReadDelay}}
* {{CacheMvccReplicatedCoordinatorFailoverTest}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups0_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
* {{CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple}}
* {{DataStreamProcessorMvccPersistenceSelfTest.testTryFlush}}
* {{IgniteCacheGroupsTest.testCreateDestroyCachesMvccTxReplicated}}
*
{{CacheMvccReplicatedSqlCoordinatorFailoverTest.testUpdate_N_Objects_ClientServer_Backups0_Sql_Persistence}}
* {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}
** {{testUpdate_N_Objects_ClientServer_Backups2_Sql}}
**
{{testPutAllGetAll_ClientServer_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
** {{testPutAllGetAll_Server_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
** {{testAccountsTxSql_Server_Backups0_CoordinatorFails}}
** {{testAccountsTxSql_Server_Backups1_CoordinatorFails_Persistence}}
{noformat}
junit.framework.AssertionFailedError: Unexpected error:
junit.framework.AssertionFailedError: expected:<0> but was:<4>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1362)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1350)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
{noformat}
was:
Sometimes tests are failed by violated invariants errors. For example, when
total sum on accounts is not as expected.
Muted tests:
* {{CacheMvccPartitionedCoordinatorFailoverTest}}
**
{{testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
**
{{testUpdate_N_Objects_ClientServer_Backups1_PutGet_CoordinatorFails_Persistence}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups1_CoordinatorFails}}
** {{testAccountsTxGet_ClientServer_Backups2_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups1_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups0_CoordinatorFails}}
** {{testGetReadInProgressCoordinatorFails}}
** {{testGetReadInsideTxInProgressCoordinatorFails_ReadDelay}}
* {{CacheMvccReplicatedCoordinatorFailoverTest}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups0_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
* {{CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple}}
* {{DataStreamProcessorMvccPersistenceSelfTest.testTryFlush}}
* {{IgniteCacheGroupsTest.testCreateDestroyCachesMvccTxReplicated}}
*
{{CacheMvccReplicatedSqlCoordinatorFailoverTest.testUpdate_N_Objects_ClientServer_Backups0_Sql_Persistence}}
* {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}
** {{testUpdate_N_Objects_ClientServer_Backups2_Sql}}
**
{{testPutAllGetAll_ClientServer_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
** {{testPutAllGetAll_Server_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
** {{testAccountsTxSql_Server_Backups0_CoordinatorFails}}
{noformat}
junit.framework.AssertionFailedError: Unexpected error:
junit.framework.AssertionFailedError: expected:<0> but was:<4>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1362)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1350)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
{noformat}
> MVCC: Tests invariants are violated sometimes
>
[jira] [Created] (IGNITE-10763) MVCC: Transaction already completed error in some tests
Roman Kondakov created IGNITE-10763:
---
Summary: MVCC: Transaction already completed error in some tests
Key: IGNITE-10763
URL: https://issues.apache.org/jira/browse/IGNITE-10763
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Roman Kondakov
"Transaction is already completed" error occurs time to time in some tests.
Reproducer:
{{CacheMvccReplicatedSqlTxQueriesTest.testReplicatedAndPartitionedUpdateSingleTransaction}}
{noformat}
class org.apache.ignite.internal.processors.query.IgniteSQLException:
Transaction is already completed.
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.checkActive(MvccUtils.java:660)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:832)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:813)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:796)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.runQueryTwoStep(IgniteH2Indexing.java:1131)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunDistributedQuery(IgniteH2Indexing.java:1990)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1636)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1526)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2167)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2162)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2670)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2176)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2196)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2157)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2118)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2091)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccReplicatedSqlTxQueriesTest.runSql(CacheMvccReplicatedSqlTxQueriesTest.java:234)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccReplicatedSqlTxQueriesTest.testReplicatedAndPartitionedUpdateSingleTransaction(CacheMvccReplicatedSqlTxQueriesTest.java:202)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2121)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10752) MVCC: Tests invariants are violated sometimes
[
https://issues.apache.org/jira/browse/IGNITE-10752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10752:
Description:
Sometimes tests are failed by violated invariants errors. For example, when
total sum on accounts is not as expected.
Muted tests:
* {{CacheMvccPartitionedCoordinatorFailoverTest}}
**
{{testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
**
{{testUpdate_N_Objects_ClientServer_Backups1_PutGet_CoordinatorFails_Persistence}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups1_CoordinatorFails}}
** {{testAccountsTxGet_ClientServer_Backups2_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups1_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups0_CoordinatorFails}}
** {{testGetReadInProgressCoordinatorFails}}
** {{testGetReadInsideTxInProgressCoordinatorFails_ReadDelay}}
* {{CacheMvccReplicatedCoordinatorFailoverTest}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups0_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
* {{CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple}}
* {{DataStreamProcessorMvccPersistenceSelfTest.testTryFlush}}
* {{IgniteCacheGroupsTest.testCreateDestroyCachesMvccTxReplicated}}
*
{{CacheMvccReplicatedSqlCoordinatorFailoverTest.testUpdate_N_Objects_ClientServer_Backups0_Sql_Persistence}}
* {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}
** {{testUpdate_N_Objects_ClientServer_Backups2_Sql}}
**
{{testPutAllGetAll_ClientServer_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
** {{testPutAllGetAll_Server_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
** {{testAccountsTxSql_Server_Backups0_CoordinatorFails}}
{noformat}
junit.framework.AssertionFailedError: Unexpected error:
junit.framework.AssertionFailedError: expected:<0> but was:<4>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1362)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1350)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
{noformat}
was:
Sometimes tests are failed by violated invariants errors. For example, when
total sum on accounts is not as expected.
Muted tests:
* {{CacheMvccPartitionedCoordinatorFailoverTest}}
**
{{testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
**
{{testUpdate_N_Objects_ClientServer_Backups1_PutGet_CoordinatorFails_Persistence}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups1_CoordinatorFails}}
** {{testAccountsTxGet_ClientServer_Backups2_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups1_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups0_CoordinatorFails}}
** {{testGetReadInProgressCoordinatorFails}}
** {{testGetReadInsideTxInProgressCoordinatorFails_ReadDelay}}
* {{CacheMvccReplicatedCoordinatorFailoverTest}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups0_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
* {{CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple}}
* {{DataStreamProcessorMvccPersistenceSelfTest.testTryFlush}}
{noformat}
junit.framework.AssertionFailedError: Unexpected error:
junit.framework.AssertionFailedError: expected:<0> but was:<4>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1362)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1350)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
{noformat}
> MVCC: Tests invariants are violated sometimes
> -
>
> Key: IGNITE-10752
> URL: https://issues.apache.org/jira/browse/IGNITE-10752
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
>
> Sometimes tests are failed by violated invariants errors. For example, when
> total sum on accounts is not as expected.
> Muted tests:
> * {{CacheMvccPartitionedCoordinatorFailoverTest}}
> **
>
[jira] [Created] (IGNITE-10762) migrate test suites from Junit 3 to 4
Ivan Pavlukhin created IGNITE-10762:
---
Summary: migrate test suites from Junit 3 to 4
Key: IGNITE-10762
URL: https://issues.apache.org/jira/browse/IGNITE-10762
Project: Ignite
Issue Type: Sub-task
Reporter: Ivan Pavlukhin
It seems that {{@Ignore}} annotation is processed incorrectly when a test in
Junit 4 style is included into Junit 3 test suite (wrapped into
{{JUnit4TestAdapter}}). Actually such test is skipped silently when it is
called during a suite execution. So, for full a blown usage of {{@Ignore}} test
suites must be migrated to Junit 4 as well. Expected behavior here is reporting
that a particular test method was ignored after tests execution. Ignored tests
should be visible in CI.
Apparently such unexpected behavior of {{@Ignore}} can be caused by
{{JUnit4TestAdapter}} as it explicitly filters test method marked with this
annotation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10760) Confusing message about system worker blocking
[
https://issues.apache.org/jira/browse/IGNITE-10760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura updated IGNITE-10760:
-
Description:
System workers blocking monitoring message can confuse because print out
worker's name while references to this name as {{threadName}}:
{noformat}
[ERROR] 2018-12-18 14:58:06.811 [tcp-disco-msg-worker-#2%hermesCacheInstance%]
G - Blocked system-critical thread has been detected. This can lead to
cluster-wide undefined behaviour [threadName=partition-exchanger, blockedFor=5s]
{noformat}
It should be fixed in the following manner:
- print out {{GridWorker.runner().getName()}} for {{threadName}}
- add {{workerName}} field to the message that should contain
{{GridWorker.name()}}.
was:
System workers blocking monitoring message can confuse because print out
worker's name while references to this name as {{threadName}}:
{noformat}
ERROR] 2018-12-18 14:58:06.811 [tcp-disco-msg-worker-#2%hermesCacheInstance%] G
- Blocked system-critical thread has been detected. This can lead to
cluster-wide undefined behaviour [threadName=partition-exchanger, blockedFor=5s]
{noformat}
It should be fixed in the following manner:
- print out {{GridWorker.runner().getName()}} for {{threadName}}
- add {{workerName}} field to the message that should contain
{{GridWorker.name()}}.
> Confusing message about system worker blocking
> ---
>
> Key: IGNITE-10760
> URL: https://issues.apache.org/jira/browse/IGNITE-10760
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Andrey Gura
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
>
> System workers blocking monitoring message can confuse because print out
> worker's name while references to this name as {{threadName}}:
> {noformat}
> [ERROR] 2018-12-18 14:58:06.811
> [tcp-disco-msg-worker-#2%hermesCacheInstance%] G - Blocked system-critical
> thread has been detected. This can lead to cluster-wide undefined behaviour
> [threadName=partition-exchanger, blockedFor=5s]
> {noformat}
> It should be fixed in the following manner:
> - print out {{GridWorker.runner().getName()}} for {{threadName}}
> - add {{workerName}} field to the message that should contain
> {{GridWorker.name()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10594) Remove 'java 8' source in indexing module, add test to regular suite
[ https://issues.apache.org/jira/browse/IGNITE-10594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725956#comment-16725956 ] Ilya Kasnacheev commented on IGNITE-10594: -- [~dpavlov] please review amended fix (remove more JSR310 references, JUnit 4) > Remove 'java 8' source in indexing module, add test to regular suite > > > Key: IGNITE-10594 > URL: https://issues.apache.org/jira/browse/IGNITE-10594 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: test > > CacheQueryEntityWithJsr310Java8DateTimeApiFieldsTest to be precise -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10594) Remove 'java 8' source in indexing module, add test to regular suite
[
https://issues.apache.org/jira/browse/IGNITE-10594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725953#comment-16725953
]
Ignite TC Bot commented on IGNITE-10594:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2602458buildTypeId=IgniteTests24Java8_RunAll]
> Remove 'java 8' source in indexing module, add test to regular suite
>
>
> Key: IGNITE-10594
> URL: https://issues.apache.org/jira/browse/IGNITE-10594
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: test
>
> CacheQueryEntityWithJsr310Java8DateTimeApiFieldsTest to be precise
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10761) GridCacheProcessor should add info about cache in excecption message, if applicable.
Sergey Antonov created IGNITE-10761: --- Summary: GridCacheProcessor should add info about cache in excecption message, if applicable. Key: IGNITE-10761 URL: https://issues.apache.org/jira/browse/IGNITE-10761 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov We should add info about problem cache in exception message. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10761) GridCacheProcessor should add info about cache in excecption message, if applicable.
[ https://issues.apache.org/jira/browse/IGNITE-10761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-10761: Fix Version/s: 2.8 > GridCacheProcessor should add info about cache in excecption message, if > applicable. > - > > Key: IGNITE-10761 > URL: https://issues.apache.org/jira/browse/IGNITE-10761 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Priority: Major > Fix For: 2.8 > > > We should add info about problem cache in exception message. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10760) Confusing message about system worker blocking
[
https://issues.apache.org/jira/browse/IGNITE-10760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura updated IGNITE-10760:
-
Description:
System workers blocking monitoring message can confuse because print out
worker's name while references to this name as {{threadName}}:
{noformat}
ERROR] 2018-12-18 14:58:06.811 [tcp-disco-msg-worker-#2%hermesCacheInstance%] G
- Blocked system-critical thread has been detected. This can lead to
cluster-wide undefined behaviour [threadName=partition-exchanger, blockedFor=5s]
{noformat}
It should be fixed in the following manner:
- print out {{GridWorker.runner().getName()}} for {{threadName}}
- add {{workerName}} field to the message that should contain
{{GridWorker.name()}}.
was:
System workers blocking monitoring message can confuse because print out
worker's name while references to this name as {{threadName}}:
{noformat}
ERROR] 2018-12-18 14:58:06.811 [tcp-disco-msg-worker-#2%hermesCacheInstance%] G
- Blocked system-critical thread has been detected. This can lead to
cluster-wide undefined behaviour [threadName=partition-exchanger, blockedFor=5s]
{noformat}
It should be fixed in the following manner:
- print out {{GridWorker.runner().getName()}} for {{threadName}}
- add {{workerName}} field to the message taht should contain
{{GridWorker.name()}}
> Confusing message about system worker blocking
> ---
>
> Key: IGNITE-10760
> URL: https://issues.apache.org/jira/browse/IGNITE-10760
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Andrey Gura
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
>
> System workers blocking monitoring message can confuse because print out
> worker's name while references to this name as {{threadName}}:
> {noformat}
> ERROR] 2018-12-18 14:58:06.811 [tcp-disco-msg-worker-#2%hermesCacheInstance%]
> G - Blocked system-critical thread has been detected. This can lead to
> cluster-wide undefined behaviour [threadName=partition-exchanger,
> blockedFor=5s]
> {noformat}
> It should be fixed in the following manner:
> - print out {{GridWorker.runner().getName()}} for {{threadName}}
> - add {{workerName}} field to the message that should contain
> {{GridWorker.name()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10760) Confusing message about system worker blocking
[
https://issues.apache.org/jira/browse/IGNITE-10760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura updated IGNITE-10760:
-
Labels: newbie (was: )
> Confusing message about system worker blocking
> ---
>
> Key: IGNITE-10760
> URL: https://issues.apache.org/jira/browse/IGNITE-10760
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Andrey Gura
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
>
> System workers blocking monitoring message can confuse because print out
> worker's name while references to this name as {{threadName}}:
> {noformat}
> ERROR] 2018-12-18 14:58:06.811 [tcp-disco-msg-worker-#2%hermesCacheInstance%]
> G - Blocked system-critical thread has been detected. This can lead to
> cluster-wide undefined behaviour [threadName=partition-exchanger,
> blockedFor=5s]
> {noformat}
> It should be fixed in the following manner:
> - print out {{GridWorker.runner().getName()}} for {{threadName}}
> - add {{workerName}} field to the message taht should contain
> {{GridWorker.name()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10760) Confusing message about system worker blocking
Andrey Gura created IGNITE-10760:
Summary: Confusing message about system worker blocking
Key: IGNITE-10760
URL: https://issues.apache.org/jira/browse/IGNITE-10760
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.7
Reporter: Andrey Gura
Fix For: 2.8
System workers blocking monitoring message can confuse because print out
worker's name while references to this name as {{threadName}}:
{noformat}
ERROR] 2018-12-18 14:58:06.811 [tcp-disco-msg-worker-#2%hermesCacheInstance%] G
- Blocked system-critical thread has been detected. This can lead to
cluster-wide undefined behaviour [threadName=partition-exchanger, blockedFor=5s]
{noformat}
It should be fixed in the following manner:
- print out {{GridWorker.runner().getName()}} for {{threadName}}
- add {{workerName}} field to the message taht should contain
{{GridWorker.name()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10759) Disable implicit distributed joins when queryParallelizm>1.
Andrew Mashenkov created IGNITE-10759: - Summary: Disable implicit distributed joins when queryParallelizm>1. Key: IGNITE-10759 URL: https://issues.apache.org/jira/browse/IGNITE-10759 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 1.9 Reporter: Andrew Mashenkov Fix For: 2.8 For now, local query with queryParallelizm>1 enables joins between partitions on same even if distributedJoins flag is false. This behaviour is unexpected and can't be disabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
[
https://issues.apache.org/jira/browse/IGNITE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725924#comment-16725924
]
Andrey Gura commented on IGNITE-10003:
--
[~andrey-kuznetsov] Timeout is more specific failure. So one new failover type
{{ SYSTEM_CRITICAL_OPERATION_FAILED}} will describe wide error types.
> Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read
> lock timeout detected
>
>
> Key: IGNITE-10003
> URL: https://issues.apache.org/jira/browse/IGNITE-10003
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Trivial
> Fix For: 2.8
>
>
> {{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
> {{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
> default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10745) SQL: jdbc metadata's getColumns returns wrong value for "ORDINAL_POSITION"
[
https://issues.apache.org/jira/browse/IGNITE-10745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725813#comment-16725813
]
Pavel Kuznetsov edited comment on IGNITE-10745 at 12/20/18 3:11 PM:
-Also see the same proble with indexes metadata-
Upd: seems it's not
was (Author: pkouznet):
Also see the same proble with indexes metadata.
> SQL: jdbc metadata's getColumns returns wrong value for "ORDINAL_POSITION"
> ---
>
> Key: IGNITE-10745
> URL: https://issues.apache.org/jira/browse/IGNITE-10745
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Reporter: Pavel Kuznetsov
>Priority: Minor
> Labels: jdbc, metadata, sql
>
> Affected both thin and jdbc v2 drivers.
> jdbc spec says :
> {noformat}
> ORDINAL_POSITION int => index of column in table (starting at 1)
> {noformat}
> but in fact it is a position in the metadata table itself, not position in
> the original table.
> For example we have table
> {code:sql}
> Person(id int primary key, val1 int, val2 bigint, val3 int)
> {code}
> Oridinal number for {{val3}} is 4, but if we specified patterns that leave
> only 1 result ({{PUBLIC.Person.val3}}) returned value will be 1. If we
> select 2 columns by pattern - 2 or 1 and so on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
[
https://issues.apache.org/jira/browse/IGNITE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725922#comment-16725922
]
Andrey Kuznetsov commented on IGNITE-10003:
---
[~agura], as for new failure type name, I'd prefer
{{SYSTEM_CRITICAL_OPERATION_TIMEOUT}}.
> Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read
> lock timeout detected
>
>
> Key: IGNITE-10003
> URL: https://issues.apache.org/jira/browse/IGNITE-10003
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Trivial
> Fix For: 2.8
>
>
> {{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
> {{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
> default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
[
https://issues.apache.org/jira/browse/IGNITE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725903#comment-16725903
]
Andrey Gura edited comment on IGNITE-10003 at 12/20/18 2:40 PM:
[~andrey-kuznetsov] [~Jokser] [~agoncharuk] [~ivan.glukos]
Guys, I've thought that {{SYSTEM_WORKER_BLOCKED}} isn't valid failure type for
this case. First of all we can get into this situations from any thread. What
about adding new failure type {{SYSTEM_CRITICAL_OPERATION_FAILED}} that will
describe situations like this? If it is ok, we should add this new failure type
to {{AbstractFailureHandler.ignoredFailureTypes}} and use this failure type in
cases of checkpoint read lock acquisition was timed out. One mote thing that
should be done is providing proper error explanation in exception message. May
be we should also introduce system critical operations/error codes. But it's
topic for separate discussion.
Thoughts?
was (Author: agura):
[~andrey-kuznetsov][~Jokser][~agoncharuk][~ivan.glukos]
Guys, I've thought that {{SYSTEM_WORKER_BLOCKED}} isn't valid failure type for
this case. First of all we can get into this situations from any thread. What
about adding new failure type {{SYSTEM_CRITICAL_OPERATION_FAILED}} that will
describe situations like this? If it is ok, we should add this new failure type
to {{AbstractFailureHandler.ignoredFailureTypes}} and use this failure type in
cases of checkpoint read lock acquisition was timed out. One mote thing that
should be done is providing proper error explanation in exception message. May
be we should also introduce system critical operations/error codes. But it's
topic for separate discussion.
Thoughts?
> Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read
> lock timeout detected
>
>
> Key: IGNITE-10003
> URL: https://issues.apache.org/jira/browse/IGNITE-10003
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Trivial
> Fix For: 2.8
>
>
> {{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
> {{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
> default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10671) Double initialization of segmentAware and FileArchiver lead to race breaking file compression.
[ https://issues.apache.org/jira/browse/IGNITE-10671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725904#comment-16725904 ] Anton Kalashnikov commented on IGNITE-10671: Now it's looks good for me. I think you can merge master to your branch and restart failed tests because it already was fixed. After that it can be merged to master. > Double initialization of segmentAware and FileArchiver lead to race breaking > file compression. > -- > > Key: IGNITE-10671 > URL: https://issues.apache.org/jira/browse/IGNITE-10671 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Critical > Attachments: WalCompactionSwitchOverTest.java > > > Race is painful when you switch your cluster from walCompaction=false to > walCompaction=true. > The same FileCompressor instance will use different segmentAwares due to > start0() is called twice which leads to inconsistent behaviour and errors > during compaction, basically we will try to archive files twice concurrently. > See reproducer in attachment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
[
https://issues.apache.org/jira/browse/IGNITE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725903#comment-16725903
]
Andrey Gura edited comment on IGNITE-10003 at 12/20/18 2:39 PM:
[~andrey-kuznetsov][~Jokser][~agoncharuk][~ivan.glukos]
Guys, I've thought that {{SYSTEM_WORKER_BLOCKED}} isn't valid failure type for
this case. First of all we can get into this situations from any thread. What
about adding new failure type {{SYSTEM_CRITICAL_OPERATION_FAILED}} that will
describe situations like this? If it is ok, we should add this new failure type
to {{AbstractFailureHandler.ignoredFailureTypes}} and use this failure type in
cases of checkpoint read lock acquisition was timed out. One mote thing that
should be done is providing proper error explanation in exception message. May
be we should also introduce system critical operations/error codes. But it's
topic for separate discussion.
Thoughts?
was (Author: agura):
[~andrey-kuznetsov][~Jokser][~agoncharuk][~ivan.glukos]
Guys, I've thought that {{SYSTEM_WORKER_BLOCKED}} isn't valid failure type for
this case. First of all we can get into this situations from any thread. What
about adding new failure type {{SYSTEM_CRITICAL_OPERATION_FAILED}} that will
describe situations like this? If it is ok, we should add this new failure type
to {{AbstractFailureHandler.ignoredFailureTypes}} and use this failure type in
cases of checkpoint read lock acquisition was timed out. One mote thing that
should be done is providing proper error explanation in exception message. May
be we should also introduce system critical operations/error codes. But it
topic for separate discussion.
Thoughts?
> Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read
> lock timeout detected
>
>
> Key: IGNITE-10003
> URL: https://issues.apache.org/jira/browse/IGNITE-10003
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Trivial
> Fix For: 2.8
>
>
> {{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
> {{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
> default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
[
https://issues.apache.org/jira/browse/IGNITE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725903#comment-16725903
]
Andrey Gura commented on IGNITE-10003:
--
[~andrey-kuznetsov][~Jokser][~agoncharuk][~ivan.glukos]
Guys, I've thought that {{SYSTEM_WORKER_BLOCKED}} isn't valid failure type for
this case. First of all we can get into this situations from any thread. What
about adding new failure type {{SYSTEM_CRITICAL_OPERATION_FAILED}} that will
describe situations like this? If it is ok, we should add this new failure type
to {{AbstractFailureHandler.ignoredFailureTypes}} and use this failure type in
cases of checkpoint read lock acquisition was timed out. One mote thing that
should be done is providing proper error explanation in exception message. May
be we should also introduce system critical operations/error codes. But it
topic for separate discussion.
Thoughts?
> Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read
> lock timeout detected
>
>
> Key: IGNITE-10003
> URL: https://issues.apache.org/jira/browse/IGNITE-10003
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Trivial
> Fix For: 2.8
>
>
> {{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
> {{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
> default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10177) cleanup Junit 3 from the project
[
https://issues.apache.org/jira/browse/IGNITE-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10177:
Description:
If needed, refer parent task for more details.
# remove Junit3-specific parts of API of GridAbstractTest and its subclasses
# remove dependencies from Junit 3 in Maven (if there are any)
# migrate tests that were missed at prior steps for various reasons:
## untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass
which currently conflict with Junit4 execution because of using constructors
and make them properly use {{@Test}} annotation
## find out why
{{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
start running slow / timing out after adding Junit 4 annotations (reproduced
this on teamcity and locally as was discovered in IGNITE-10175)
## find out why {{IgniteTwitterStreamerTest}} runs fine under JUnit 3 but
starts failing after move to JUnit 4
## IgniteCachePartitionedQuerySelfTest,
IgniteCacheReplicatedQueryP2PDisabledSelfTest, ComputeUtilsTest,
CacheBasedDatasetBuilderTest, CacheBasedDatasetTest,
GridPartitionedCacheJtaLookupClassNameSelfTest,
GridReplicatedCacheJtaLookupClassNameSelfTest (there were problems migrating
these at IGNITE-10176)
## find out why tests in logging suite failed on teamcity (not locally) when
setup method was annotated {{@Before}}
## (!) note part of this work related to
{{IgniteConfigVariationsAbstractTest}} is expected to be done separately per
IGNITE-10739
# in tests suite classes, change {{extends TestSuite}} to either
{{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
# find and update all Junit3-specific code that {{extends TestCase}}
# execute junit related inspections of IDE and analyse results
# remove redundant references to {{JUnit4.class}} if there are any (like in
{{@RunWith(JUnit4.class)}})
(i) per discussion with [~EdShangGG] plan to to do this in a separate ticket
for smoother merges - IGNITE-10758
Side note if for some reason it turns out critically important to keep test
suites names (by default Junit 4 will use suite class names instead), approach
with custom description annotation [described
here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
can be used to address that.
was:
If needed, refer parent task for more details.
# remove Junit3-specific parts of API of GridAbstractTest and its subclasses
# remove dependencies from Junit 3 in Maven (if there are any)
# migrate tests that were missed at prior steps for various reasons:
## untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass
which currently conflict with Junit4 execution because of using constructors
and make them properly use {{@Test}} annotation
## find out why
{{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
start running slow / timing out after adding Junit 4 annotations (reproduced
this on teamcity and locally as was discovered in IGNITE-10175)
## find out why {{IgniteTwitterStreamerTest}} runs fine under JUnit 3 but
starts failing after move to JUnit 4
## IgniteCachePartitionedQuerySelfTest,
IgniteCacheReplicatedQueryP2PDisabledSelfTest, ComputeUtilsTest,
CacheBasedDatasetBuilderTest, CacheBasedDatasetTest,
GridPartitionedCacheJtaLookupClassNameSelfTest,
GridReplicatedCacheJtaLookupClassNameSelfTest (there were problems migrating
these at IGNITE-10176)
## find out why tests in logging suite failed on teamcity (not locally) when
setup method was annotated {{@Before}}
## (!) note part of this work related to
{{IgniteConfigVariationsAbstractTest}} is expected to be done separately per
IGNITE-10739
# in tests suite classes, change {{extends TestSuite}} to either
{{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
# find and update all Junit3-specific code that {{extends TestCase}}
# execute junit related inspections of IDE and analyse results
# remove redundant references to {{JUnit4.class}} if there are any (like in
{{@RunWith(JUnit4.class)}})
(per discussion with [~EdShangGG] it looks more convenient to do this in a
separate ticket for smoother merges)
Side note if for some reason it turns out critically important to keep test
suites names (by default Junit 4 will use suite class names instead), approach
with custom description annotation [described
here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
can be used to address that.
> cleanup Junit 3 from the project
>
>
> Key: IGNITE-10177
> URL: https://issues.apache.org/jira/browse/IGNITE-10177
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent
[jira] [Created] (IGNITE-10758) remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their respective imports
Oleg Ignatenko created IGNITE-10758:
---
Summary: remove from tests scaffolding annotations
"@RunWith(JUnit4.class)" and their respective imports
Key: IGNITE-10758
URL: https://issues.apache.org/jira/browse/IGNITE-10758
Project: Ignite
Issue Type: Sub-task
Affects Versions: 2.8
Reporter: Oleg Ignatenko
In the course of IGNITE-10175 and IGNITE-10176 many test classes were annotated
{{@RunWith(JUnit4.class)}}. This was necessary to allow gradual switching to
JUnit 4 to let classes run under the version that worked for these.
After IGNITE-10177 is over, these scaffolding annotations will be not needed
anymore (and will become even somewhat damaging by misleading readers to think
that they serve some real purpose).
The task is to remove these annotations and respective import statements after
IGNITE-10177 is merged to master. Note it was initially planned as a part of
IGNITE-10177 but per discussion with [~EdShangGG] we decided that it will be
more convenient to do this in a separate ticket because this will make changes
much easier to review, test and merge.
(!) Thing worth paying attention is that mentioned annotations should be kept
in one case - namely in root test class {{GridAbstractTest}} because over there
these are necessary until JUnit 3 dependencies are wiped out from remaining
cases listed in IGNITE-10739.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10758) remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their respective imports
[
https://issues.apache.org/jira/browse/IGNITE-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10758:
Labels: MakeTeamcityGreenAgain (was: )
> remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their
> respective imports
> ---
>
> Key: IGNITE-10758
> URL: https://issues.apache.org/jira/browse/IGNITE-10758
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> In the course of IGNITE-10175 and IGNITE-10176 many test classes were
> annotated {{@RunWith(JUnit4.class)}}. This was necessary to allow gradual
> switching to JUnit 4 to let classes run under the version that worked for
> these.
> After IGNITE-10177 is over, these scaffolding annotations will be not needed
> anymore (and will become even somewhat damaging by misleading readers to
> think that they serve some real purpose).
> The task is to remove these annotations and respective import statements
> after IGNITE-10177 is merged to master. Note it was initially planned as a
> part of IGNITE-10177 but per discussion with [~EdShangGG] we decided that it
> will be more convenient to do this in a separate ticket because this will
> make changes much easier to review, test and merge.
> (!) Thing worth paying attention is that mentioned annotations should be kept
> in one case - namely in root test class {{GridAbstractTest}} because over
> there these are necessary until JUnit 3 dependencies are wiped out from
> remaining cases listed in IGNITE-10739.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10758) remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their respective imports
[
https://issues.apache.org/jira/browse/IGNITE-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10758:
Ignite Flags: (was: Docs Required)
> remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their
> respective imports
> ---
>
> Key: IGNITE-10758
> URL: https://issues.apache.org/jira/browse/IGNITE-10758
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> In the course of IGNITE-10175 and IGNITE-10176 many test classes were
> annotated {{@RunWith(JUnit4.class)}}. This was necessary to allow gradual
> switching to JUnit 4 to let classes run under the version that worked for
> these.
> After IGNITE-10177 is over, these scaffolding annotations will be not needed
> anymore (and will become even somewhat damaging by misleading readers to
> think that they serve some real purpose).
> The task is to remove these annotations and respective import statements
> after IGNITE-10177 is merged to master. Note it was initially planned as a
> part of IGNITE-10177 but per discussion with [~EdShangGG] we decided that it
> will be more convenient to do this in a separate ticket because this will
> make changes much easier to review, test and merge.
> (!) Thing worth paying attention is that mentioned annotations should be kept
> in one case - namely in root test class {{GridAbstractTest}} because over
> there these are necessary until JUnit 3 dependencies are wiped out from
> remaining cases listed in IGNITE-10739.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10324) Disallow fallback to Scanner in control.sh when asking password
[ https://issues.apache.org/jira/browse/IGNITE-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-10324: Ignite Flags: (was: Docs Required) > Disallow fallback to Scanner in control.sh when asking password > --- > > Key: IGNITE-10324 > URL: https://issues.apache.org/jira/browse/IGNITE-10324 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Alexand Polyakov >Priority: Major > > After implementing IGNITE-9990 we still can fallback to Scanner in case of > Console is not allowed, user can easily fallback to non-secure mode by using > some java agent. We should not allow this, cause otherwise all efforts in > IGNITE-9990 are useless. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-10324) Disallow fallback to Scanner in control.sh when asking password
[ https://issues.apache.org/jira/browse/IGNITE-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin closed IGNITE-10324. --- > Disallow fallback to Scanner in control.sh when asking password > --- > > Key: IGNITE-10324 > URL: https://issues.apache.org/jira/browse/IGNITE-10324 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Alexand Polyakov >Priority: Major > > After implementing IGNITE-9990 we still can fallback to Scanner in case of > Console is not allowed, user can easily fallback to non-secure mode by using > some java agent. We should not allow this, cause otherwise all efforts in > IGNITE-9990 are useless. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10605) [ML] Add binary metrics calculations to Cross-Validation
[ https://issues.apache.org/jira/browse/IGNITE-10605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725887#comment-16725887 ] ASF GitHub Bot commented on IGNITE-10605: - GitHub user zaleslaw opened a pull request: https://github.com/apache/ignite/pull/5712 IGNITE-10605: Add binary metrics calculations to Cross-Validation You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10605 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5712.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 #5712 commit 3e4c8002870a25501bfd8508cb9073d27b9af33d Author: Zinoviev Alexey Date: 2018-12-12T15:50:25Z IGNITE-10528: Fix incorrect comparing of double values in ML examples commit 234adaa1c186fffd2c884e8f67be9f1295516540 Author: Zinoviev Alexey Date: 2018-12-14T15:19:39Z Merge branch 'master' of https://github.com/apache/ignite commit d946ef5d13596d5a799e585ca3a7b0895508a575 Author: Zinoviev Alexey Date: 2018-12-18T12:28:30Z Merge branch 'master' of https://github.com/apache/ignite commit 222bf65b73f05a48507ee4596ec2f4f0a9e2c077 Author: Zinoviev Alexey Date: 2018-12-20T12:32:21Z Merge branch 'master' of https://github.com/apache/ignite commit b59591d209cea19df3bfb02b8951ecd9e50cfa03 Author: Zinoviev Alexey Date: 2018-12-20T13:49:23Z IGNITE-10605: Add ability to use in CV individual metrics commit 87f00b7f5de7450c7e1e3e71b9c7a6a600451fb0 Author: Zinoviev Alexey Date: 2018-12-20T13:57:53Z IGNITE-10605: Added tests > [ML] Add binary metrics calculations to Cross-Validation > > > Key: IGNITE-10605 > URL: https://issues.apache.org/jira/browse/IGNITE-10605 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.8 > > > Extend and refactor CrossValidation class methods with scoreCalculator > parameter. > Refactor tests and examples and tutorial according new changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10671) Double initialization of segmentAware and FileArchiver lead to race breaking file compression.
[ https://issues.apache.org/jira/browse/IGNITE-10671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725886#comment-16725886 ] Pavel Voronkin commented on IGNITE-10671: - [~akalashnikov] thanks, i've fixed your comments. > Double initialization of segmentAware and FileArchiver lead to race breaking > file compression. > -- > > Key: IGNITE-10671 > URL: https://issues.apache.org/jira/browse/IGNITE-10671 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Critical > Attachments: WalCompactionSwitchOverTest.java > > > Race is painful when you switch your cluster from walCompaction=false to > walCompaction=true. > The same FileCompressor instance will use different segmentAwares due to > start0() is called twice which leads to inconsistent behaviour and errors > during compaction, basically we will try to archive files twice concurrently. > See reproducer in attachment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10757) Refactoring: split MvccProcessor into multiple components
Ivan Pavlukhin created IGNITE-10757: --- Summary: Refactoring: split MvccProcessor into multiple components Key: IGNITE-10757 URL: https://issues.apache.org/jira/browse/IGNITE-10757 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Ivan Pavlukhin Fix For: 2.8 In current implementation MvccProcessor has multiple responsibilities which can be extracted into separate components. Also it looks like that we do not need an independent processor here because all logic is bound to CacheProcessor. At least 3 components could be created: 1. ShapshotManager responsible for granting MVCC snapshots and handling related messages. 2. LockManager implementing (exclusive) locking for write operations and associated wait queues. Deadlock detection facilities could be also placed here. 3. VacuumManager responsible for scavenging not needed anymore row versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3269) Benchmark driver stops working when one of servers left grid and backupcount 0
[
https://issues.apache.org/jira/browse/IGNITE-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725866#comment-16725866
]
Andrey Gura commented on IGNITE-3269:
-
[~skozlov] My point here is benchmark results will not have any sense in case
of data loss. So it should be configurable behaviour of ignite-yardstick. If
you are agree with expected behaviour in description I'll merge the change.
> Benchmark driver stops working when one of servers left grid and backupcount 0
> --
>
> Key: IGNITE-3269
> URL: https://issues.apache.org/jira/browse/IGNITE-3269
> Project: Ignite
> Issue Type: Bug
> Components: yardstick
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
>Assignee: Oleg Ostanin
>Priority: Critical
> Attachments: failed_client_log.zip
>
>
> Test config: 4 hosts with 4 clients and 1 server each, backup count = 0.
> During the test one of the servers was killed. After that one of the clients
> stopped working:
> {noformat}
> [15:31:45,248][WARN ][sys-#27%null%][TcpCommunicationSpi] Connect timed out
> (consider increasing 'failureDetectionTimeout' configuration property)
> [addr=fosters-216/10.20.0.216:47100, failureDetectionTimeout=1]
> [15:31:45,256][WARN ][sys-#27%null%][TcpCommunicationSpi] Failed to connect
> to a remote node (make sure that destination node is alive and operating
> system firewall is disabled on local and remote hosts)
> [addrs=[fosters-216/10.20.0.216:4
> [15:31:45,276][WARN ][disco-event-worker-#52%null%][GridDiscoveryManager]
> Node FAILED: TcpDiscoveryNode [id=f5bcc4d3-aa56-4e51-8672-e799a42990a6,
> addrs=[10.20.0.216, 127.0.0.1], sockAddrs=[fosters-216/10.20.0.216:47500,
> /10.20.0.216:4750
> [15:31:45,324][INFO ][disco-event-worker-#52%null%][GridDiscoveryManager]
> Topology snapshot [ver=22, servers=3, clients=16, CPUs=64, heap=150.0GB]
> ERROR: The benchmark of random operation failed.
> Type '--help' for usage.
> Finishing main test [ts=1465252305413, date=Mon Jun 06 15:31:45 PDT 2016]
> [15:31:45] (err) Failed to execute compound future reducer:
> GridNearTxFinishFuture
> [futId=9c7413d2551-758034b3-0248-4d62-b901-be86d119183c, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false, colocatedLocallyMa
> Type '--help' for usage.
> [15:31:45] (err) Failed to execute compound future reducer:
> GridNearTxFinishFuture
> [futId=6f7413d2551-758034b3-0248-4d62-b901-be86d119183c, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false, colocatedLocallyMa
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:700)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:644)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:607)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:135)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:133)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:624)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:322)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:246)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:83)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:205)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:847)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:105)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:810)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> [15:31:45] (err) Failed to execute compound future reducer:
> GridNearTxFinishFuture
> [futId=ff7413d2551-758034b3-0248-4d62-b901-be86d119183c, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false, colocatedLocallyMa
> at
>
[jira] [Commented] (IGNITE-9303) PageSnapshot can contain wrong pageId tag when not dirty page is recycling
[
https://issues.apache.org/jira/browse/IGNITE-9303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725845#comment-16725845
]
Ilya Lantukh commented on IGNITE-9303:
--
[~agoncharuk], thanks for the review.
I've addressed all your remarks except {restore=true} flag. While it isn't
necessary, it is semantically correct.
> PageSnapshot can contain wrong pageId tag when not dirty page is recycling
> --
>
> Key: IGNITE-9303
> URL: https://issues.apache.org/jira/browse/IGNITE-9303
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Aleksey Plekhanov
>Assignee: Ilya Lantukh
>Priority: Major
> Fix For: 2.8
>
>
> When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
> {{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
> {{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}}
> is stored to PageSnapshot WAL record.
> This bug may lead to errors in WAL applying during crash recovery.
> Reproducer (ignite-indexing module must be in classpath):
> {code:java}
> public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
> @Override protected boolean checkPagesOnCheckpoint() {
> return true;
> }
> public final void testPutRemoveCacheDestroy() throws Exception {
> CacheConfiguration ccfg = new
> CacheConfiguration<>("cache0");
> ccfg.setIndexedTypes(Integer.class, Integer.class);
> IgniteEx ignite = startGrid(0);
> ignite.cluster().active(true);
> IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
> for (int i = 0; i < 5_000; i++)
> cache0.put(i, i);
> forceCheckpoint();
> for (int i = 1_000; i < 4_000; i++)
> cache0.remove(i);
> forceCheckpoint();
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
[
https://issues.apache.org/jira/browse/IGNITE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725865#comment-16725865
]
Pavel Kovalenko commented on IGNITE-10003:
--
[~andrey-kuznetsov] Overall looks good. But for me, the test can be written in
a much easier approach.
1) Disable automatic checkpoints by timeout.
2) You can introduce checkpointWriteLock/Unlock methods in
GridCacheDatabaseSharedManager and explicitly acquire write lock in test code.
3) Then try to acquire cp readLock and wait till it will be failed with a
timeout exception.
4) Check that the failure handler was called and failure type was as expected.
In this approach, there will be no needs to "cross fingers" :)
> Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read
> lock timeout detected
>
>
> Key: IGNITE-10003
> URL: https://issues.apache.org/jira/browse/IGNITE-10003
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Trivial
> Fix For: 2.8
>
>
> {{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
> {{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
> default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10756) MVCC: Query trackers are not released sometimes
Roman Kondakov created IGNITE-10756:
---
Summary: MVCC: Query trackers are not released sometimes
Key: IGNITE-10756
URL: https://issues.apache.org/jira/browse/IGNITE-10756
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Roman Kondakov
Sometimes query trackers are not released when error occurs during iterating
over {{QueryCursor}}. It may be already fixed in IGNITE-10448. Need to check.
Affected tests:
* {{CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedPartitioned}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10755) MVCC: Flaky continuous query tests
[
https://issues.apache.org/jira/browse/IGNITE-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10755:
Description:
Some continuous query tests are flaky when MVCC is enabled:
* {{CacheContinuousQueryConcurrentPartitionUpdateTest}}
** {{testConcurrentUpdatesAndQueryStartMvccTxCacheGroup}}
** {{testConcurrentUpdatesAndQueryStartMvccTx}}
was:
Some continuous query tests are flaky when MVCC is enabled.
> MVCC: Flaky continuous query tests
> --
>
> Key: IGNITE-10755
> URL: https://issues.apache.org/jira/browse/IGNITE-10755
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Labels: CQ, MakeTeamcityGreenAgain, mvcc_stabilization_stage_1
>
> Some continuous query tests are flaky when MVCC is enabled:
> * {{CacheContinuousQueryConcurrentPartitionUpdateTest}}
> ** {{testConcurrentUpdatesAndQueryStartMvccTxCacheGroup}}
> ** {{testConcurrentUpdatesAndQueryStartMvccTx}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10448) MVCC: NPE on data page eviction.
[
https://issues.apache.org/jira/browse/IGNITE-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725853#comment-16725853
]
Roman Kondakov commented on IGNITE-10448:
-
[~gvvinblade], tests look good. Ready for review.
> MVCC: NPE on data page eviction.
>
>
> Key: IGNITE-10448
> URL: https://issues.apache.org/jira/browse/IGNITE-10448
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, pagememory
>
> NPE occurred during page eviction process.
> Reproducer: {{PageEvictionMultinodeMixedRegionsTest}}.
> StackTrace:
>
> {noformat}
> javax.cache.CacheException: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 83e7f9a5761--093b-7d30--0005
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> at
> org.apache.ignite.internal.processors.cache.eviction.paged.PageEvictionMultinodeAbstractTest.createCacheAndTestEvcition(PageEvictionMultinodeAbstractTest.java:101)
> at
> org.apache.ignite.internal.processors.cache.eviction.paged.PageEvictionMultinodeAbstractTest.testPageEviction(PageEvictionMultinodeAbstractTest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:150)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2104)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.transactions.TransactionRollbackException:
> Transaction has been rolled back:
> 83e7f9a5761--093b-7d30--0005
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:923)
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:921)
> ... 15 more
> Caused by: class
> org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
> Transaction has been rolled back:
> 83e7f9a5761--093b-7d30--0005
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4299)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2520)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2501)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2478)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1105)
> ... 12 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update
> backup node: [localNodeId=0d817370-17fe-46f1-85ef-ea74b6f1,
> remoteNodeId=ebab34f3-abbc-47e9-90fa-a48a8260]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:1012)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2340)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1200(GridDhtTransactionalCacheAdapter.java:112)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:257)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:255)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1059)
> at
>
[jira] [Commented] (IGNITE-3269) Benchmark driver stops working when one of servers left grid and backupcount 0
[
https://issues.apache.org/jira/browse/IGNITE-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725850#comment-16725850
]
Sergey Kozlov commented on IGNITE-3269:
---
[~agura] The lost partiton logic should be covered by the policy and on the
user side. For some test cases the lost data is an expected behavior (and data
can be restored from an external source)
> Benchmark driver stops working when one of servers left grid and backupcount 0
> --
>
> Key: IGNITE-3269
> URL: https://issues.apache.org/jira/browse/IGNITE-3269
> Project: Ignite
> Issue Type: Bug
> Components: yardstick
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
>Assignee: Oleg Ostanin
>Priority: Critical
> Attachments: failed_client_log.zip
>
>
> Test config: 4 hosts with 4 clients and 1 server each, backup count = 0.
> During the test one of the servers was killed. After that one of the clients
> stopped working:
> {noformat}
> [15:31:45,248][WARN ][sys-#27%null%][TcpCommunicationSpi] Connect timed out
> (consider increasing 'failureDetectionTimeout' configuration property)
> [addr=fosters-216/10.20.0.216:47100, failureDetectionTimeout=1]
> [15:31:45,256][WARN ][sys-#27%null%][TcpCommunicationSpi] Failed to connect
> to a remote node (make sure that destination node is alive and operating
> system firewall is disabled on local and remote hosts)
> [addrs=[fosters-216/10.20.0.216:4
> [15:31:45,276][WARN ][disco-event-worker-#52%null%][GridDiscoveryManager]
> Node FAILED: TcpDiscoveryNode [id=f5bcc4d3-aa56-4e51-8672-e799a42990a6,
> addrs=[10.20.0.216, 127.0.0.1], sockAddrs=[fosters-216/10.20.0.216:47500,
> /10.20.0.216:4750
> [15:31:45,324][INFO ][disco-event-worker-#52%null%][GridDiscoveryManager]
> Topology snapshot [ver=22, servers=3, clients=16, CPUs=64, heap=150.0GB]
> ERROR: The benchmark of random operation failed.
> Type '--help' for usage.
> Finishing main test [ts=1465252305413, date=Mon Jun 06 15:31:45 PDT 2016]
> [15:31:45] (err) Failed to execute compound future reducer:
> GridNearTxFinishFuture
> [futId=9c7413d2551-758034b3-0248-4d62-b901-be86d119183c, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false, colocatedLocallyMa
> Type '--help' for usage.
> [15:31:45] (err) Failed to execute compound future reducer:
> GridNearTxFinishFuture
> [futId=6f7413d2551-758034b3-0248-4d62-b901-be86d119183c, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false, colocatedLocallyMa
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:700)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:644)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:607)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:135)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:133)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:624)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:322)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:246)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:83)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:205)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:847)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:105)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:810)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> [15:31:45] (err) Failed to execute compound future reducer:
> GridNearTxFinishFuture
> [futId=ff7413d2551-758034b3-0248-4d62-b901-be86d119183c, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false, colocatedLocallyMa
> at
>
[jira] [Commented] (IGNITE-10448) MVCC: NPE on data page eviction.
[
https://issues.apache.org/jira/browse/IGNITE-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725849#comment-16725849
]
Ignite TC Bot commented on IGNITE-10448:
{panel:title=-- Run :: All (Nightly): Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Hibernate 5.3{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2601524]]
{panel}
[TeamCity *-- Run :: All (Nightly)*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2600312buildTypeId=IgniteTests24Java8_RunAllNightly]
> MVCC: NPE on data page eviction.
>
>
> Key: IGNITE-10448
> URL: https://issues.apache.org/jira/browse/IGNITE-10448
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, pagememory
>
> NPE occurred during page eviction process.
> Reproducer: {{PageEvictionMultinodeMixedRegionsTest}}.
> StackTrace:
>
> {noformat}
> javax.cache.CacheException: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 83e7f9a5761--093b-7d30--0005
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> at
> org.apache.ignite.internal.processors.cache.eviction.paged.PageEvictionMultinodeAbstractTest.createCacheAndTestEvcition(PageEvictionMultinodeAbstractTest.java:101)
> at
> org.apache.ignite.internal.processors.cache.eviction.paged.PageEvictionMultinodeAbstractTest.testPageEviction(PageEvictionMultinodeAbstractTest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:150)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2104)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.transactions.TransactionRollbackException:
> Transaction has been rolled back:
> 83e7f9a5761--093b-7d30--0005
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:923)
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:921)
> ... 15 more
> Caused by: class
> org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
> Transaction has been rolled back:
> 83e7f9a5761--093b-7d30--0005
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4299)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2520)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2501)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2478)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1105)
> ... 12 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update
> backup node: [localNodeId=0d817370-17fe-46f1-85ef-ea74b6f1,
> remoteNodeId=ebab34f3-abbc-47e9-90fa-a48a8260]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:1012)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2340)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1200(GridDhtTransactionalCacheAdapter.java:112)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:257)
> at
>
[jira] [Comment Edited] (IGNITE-9303) PageSnapshot can contain wrong pageId tag when not dirty page is recycling
[
https://issues.apache.org/jira/browse/IGNITE-9303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725845#comment-16725845
]
Ilya Lantukh edited comment on IGNITE-9303 at 12/20/18 1:44 PM:
[~agoncharuk], thanks for the review.
I've addressed all your remarks except {{restore=true}} flag. While it isn't
necessary, it is semantically correct.
was (Author: ilantukh):
[~agoncharuk], thanks for the review.
I've addressed all your remarks except {restore=true} flag. While it isn't
necessary, it is semantically correct.
> PageSnapshot can contain wrong pageId tag when not dirty page is recycling
> --
>
> Key: IGNITE-9303
> URL: https://issues.apache.org/jira/browse/IGNITE-9303
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Aleksey Plekhanov
>Assignee: Ilya Lantukh
>Priority: Major
> Fix For: 2.8
>
>
> When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
> {{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
> {{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}}
> is stored to PageSnapshot WAL record.
> This bug may lead to errors in WAL applying during crash recovery.
> Reproducer (ignite-indexing module must be in classpath):
> {code:java}
> public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
> @Override protected boolean checkPagesOnCheckpoint() {
> return true;
> }
> public final void testPutRemoveCacheDestroy() throws Exception {
> CacheConfiguration ccfg = new
> CacheConfiguration<>("cache0");
> ccfg.setIndexedTypes(Integer.class, Integer.class);
> IgniteEx ignite = startGrid(0);
> ignite.cluster().active(true);
> IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
> for (int i = 0; i < 5_000; i++)
> cache0.put(i, i);
> forceCheckpoint();
> for (int i = 1_000; i < 4_000; i++)
> cache0.remove(i);
> forceCheckpoint();
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10671) Double initialization of segmentAware and FileArchiver lead to race breaking file compression.
[ https://issues.apache.org/jira/browse/IGNITE-10671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725838#comment-16725838 ] Anton Kalashnikov commented on IGNITE-10671: [~voropava], in general it looks good, but I have left a couple notes in [Upsource|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-994] > Double initialization of segmentAware and FileArchiver lead to race breaking > file compression. > -- > > Key: IGNITE-10671 > URL: https://issues.apache.org/jira/browse/IGNITE-10671 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Critical > Attachments: WalCompactionSwitchOverTest.java > > > Race is painful when you switch your cluster from walCompaction=false to > walCompaction=true. > The same FileCompressor instance will use different segmentAwares due to > start0() is called twice which leads to inconsistent behaviour and errors > during compaction, basically we will try to archive files twice concurrently. > See reproducer in attachment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-10704) Abbr-plugin: update list of abbreviations
[ https://issues.apache.org/jira/browse/IGNITE-10704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin closed IGNITE-10704. --- New plugin version delivered. > Abbr-plugin: update list of abbreviations > - > > Key: IGNITE-10704 > URL: https://issues.apache.org/jira/browse/IGNITE-10704 > Project: Ignite > Issue Type: Task >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > > Recently the list of abbreviation to use was revisited. Updated list is > located at > https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules > The following should be done: > * Update the list used by abbreviation plugin. > * Rebuild and publish new version of the plugin. > NOTE: New version must attached to the page containing rules. Also it could > be published on GitHub. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10755) MVCC: Flaky continuous query tests
Roman Kondakov created IGNITE-10755: --- Summary: MVCC: Flaky continuous query tests Key: IGNITE-10755 URL: https://issues.apache.org/jira/browse/IGNITE-10755 Project: Ignite Issue Type: Bug Components: mvcc Reporter: Roman Kondakov Some continuous query tests are flaky when MVCC is enabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10704) Abbr-plugin: update list of abbreviations
[ https://issues.apache.org/jira/browse/IGNITE-10704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin resolved IGNITE-10704. - Resolution: Fixed > Abbr-plugin: update list of abbreviations > - > > Key: IGNITE-10704 > URL: https://issues.apache.org/jira/browse/IGNITE-10704 > Project: Ignite > Issue Type: Task >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > > Recently the list of abbreviation to use was revisited. Updated list is > located at > https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules > The following should be done: > * Update the list used by abbreviation plugin. > * Rebuild and publish new version of the plugin. > NOTE: New version must attached to the page containing rules. Also it could > be published on GitHub. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10753) MVCC: Sometimes vacuum does not cleanup all outdated versions
[
https://issues.apache.org/jira/browse/IGNITE-10753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10753:
Description:
When mvcc test is finished, we check if there any outdated versions are left in
cache and not cleaned by vacuum. If so, an exception is thrown. There are some
tests with this problem:
* {{CacheMvccTransactionsTest.testCleanupWaitsForGet1}}
* {{CacheMvccTransactionsTest.testCleanupWaitsForGet3}}
was:
When mvcc test is finished, we check if there any outdated versions are left in
cache and not cleaned by vacuum. If so, an exception is thrown. There are some
tests with this problem:
* {{CacheMvccTransactionsTest.testCleanupWaitsForGet1}}
> MVCC: Sometimes vacuum does not cleanup all outdated versions
> -
>
> Key: IGNITE-10753
> URL: https://issues.apache.org/jira/browse/IGNITE-10753
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, mvcc_stabilization_stage_1,
> transactions
>
> When mvcc test is finished, we check if there any outdated versions are left
> in cache and not cleaned by vacuum. If so, an exception is thrown. There are
> some tests with this problem:
> * {{CacheMvccTransactionsTest.testCleanupWaitsForGet1}}
> * {{CacheMvccTransactionsTest.testCleanupWaitsForGet3}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
[
https://issues.apache.org/jira/browse/IGNITE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725824#comment-16725824
]
Andrey Kuznetsov commented on IGNITE-10003:
---
[~agura], thanks, unused field is now dropped.
> Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read
> lock timeout detected
>
>
> Key: IGNITE-10003
> URL: https://issues.apache.org/jira/browse/IGNITE-10003
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Trivial
> Fix For: 2.8
>
>
> {{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
> {{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
> default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10752) MVCC: Tests invariants are violated sometimes
[
https://issues.apache.org/jira/browse/IGNITE-10752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10752:
Description:
Sometimes tests are failed by violated invariants errors. For example, when
total sum on accounts is not as expected.
Muted tests:
* {{CacheMvccPartitionedCoordinatorFailoverTest}}
**
{{testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
**
{{testUpdate_N_Objects_ClientServer_Backups1_PutGet_CoordinatorFails_Persistence}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups1_CoordinatorFails}}
** {{testAccountsTxGet_ClientServer_Backups2_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups1_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups0_CoordinatorFails}}
** {{testGetReadInProgressCoordinatorFails}}
** {{testGetReadInsideTxInProgressCoordinatorFails_ReadDelay}}
* {{CacheMvccReplicatedCoordinatorFailoverTest}}
** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
** {{testAccountsTxGet_Server_Backups0_CoordinatorFails_Persistence}}
** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
* {{CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple}}
* {{DataStreamProcessorMvccPersistenceSelfTest.testTryFlush}}
{noformat}
junit.framework.AssertionFailedError: Unexpected error:
junit.framework.AssertionFailedError: expected:<0> but was:<4>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1362)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1350)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
{noformat}
was:
Sometimes tests are failed by violated invariants errors. For example, when
total sum on accounts is not as expected.
Muted tests:
*
{{CacheMvccPartitionedCoordinatorFailoverTest.testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
*
{{CacheMvccReplicatedCoordinatorFailoverTest.testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
*
{{CacheMvccPartitionedCoordinatorFailoverTest.testGetReadInsideTxInProgressCoordinatorFails_ReadDelay}}
*
{{CacheMvccPartitionedCoordinatorFailoverTest.testAccountsTxGet_SingleNode_CoordinatorFails}}
*
{{CacheMvccReplicatedCoordinatorFailoverTest.testAccountsTxGet_Server_Backups0_CoordinatorFails_Persistence}}
*
{{CacheMvccPartitionedCoordinatorFailoverTest.testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
*
{{CacheMvccPartitionedCoordinatorFailoverTest.testAccountsTxGet_Server_Backups1_CoordinatorFails}}
*
{{CacheMvccPartitionedCoordinatorFailoverTest.testUpdate_N_Objects_ClientServer_Backups1_PutGet_CoordinatorFails_Persistence}}
*
{{CacheMvccPartitionedCoordinatorFailoverTest.testAccountsTxScan_Server_Backups1_CoordinatorFails_Persistence}}
*
{{CacheMvccPartitionedCoordinatorFailoverTest.testAccountsTxGet_ClientServer_Backups2_CoordinatorFails_Persistence}}
{noformat}
junit.framework.AssertionFailedError: Unexpected error:
junit.framework.AssertionFailedError: expected:<0> but was:<4>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1362)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1350)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
{noformat}
> MVCC: Tests invariants are violated sometimes
> -
>
> Key: IGNITE-10752
> URL: https://issues.apache.org/jira/browse/IGNITE-10752
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
>
> Sometimes tests are failed by violated invariants errors. For example, when
> total sum on accounts is not as expected.
> Muted tests:
> * {{CacheMvccPartitionedCoordinatorFailoverTest}}
> **
> {{testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
> ** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
> **
> {{testUpdate_N_Objects_ClientServer_Backups1_PutGet_CoordinatorFails_Persistence}}
> ** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
> ** {{testAccountsTxGet_Server_Backups1_CoordinatorFails}}
> ** {{testAccountsTxGet_ClientServer_Backups2_CoordinatorFails_Persistence}}
> **
[jira] [Updated] (IGNITE-10750) MVCC: Unexpected tx state exception in multithreaded tests
[
https://issues.apache.org/jira/browse/IGNITE-10750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10750:
Description:
There is a number of tests in MVCC suite sporadically fail with the similar
{{IgniteTxMvccVersionCheckedException}}. This problem occurs both on stable and
unstable topologies.
These tests were muted on TC:
* {{CacheMvccPartitionedCoordinatorFailoverTest}}
** {{testUpdate_N_Objects_ClientServer_Backups1__PutGet_CoordinatorFails}}
** {{testAccountsTxScan_ClientServer_Backups2_CoordinatorFails}}
* {{CacheMvccReplicatedCoordinatorFailoverTest}}
**
{{testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups0_CoordinatorFails}}
* {{CacheMvccTransactionsTest}}
** {{testUpdate_N_Objects_ClientServer_Backups2_Get}}
{noformat}
junit.framework.AssertionFailedError: Unexpected error:
junit.framework.AssertionFailedError: Unexpected tx exception.
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to update backup node:
[localNodeId=fd28ba5c-6216-4aaa-a496-ba24cee1,
remoteNodeId=4198d600-48ee-4627-9802-0d157380]
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.putAll(IgniteCacheProxyImpl.java:1171)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:868)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest.writeAllByMode(CacheMvccAbstractTest.java:2021)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$7.apply(CacheMvccAbstractTest.java:1143)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$7.apply(CacheMvccAbstractTest.java:1116)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1328)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1323)
at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update
backup node: [localNodeId=fd28ba5c-6216-4aaa-a496-ba24cee1,
remoteNodeId=4198d600-48ee-4627-9802-0d157380]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:1012)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2342)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1200(GridDhtTransactionalCacheAdapter.java:112)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:257)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:255)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1127)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:391)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:317)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:108)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:307)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1568)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1196)
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:1092)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
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:1070)
at
[jira] [Commented] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
[
https://issues.apache.org/jira/browse/IGNITE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725822#comment-16725822
]
Andrey Gura commented on IGNITE-10003:
--
[~andrey-kuznetsov] [~Jokser] LGTM. Except of unused constant
{{org.apache.ignite.failure.CheckpointReadLockFailureTest#CHECKPOINT_FREQ}}.
> Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read
> lock timeout detected
>
>
> Key: IGNITE-10003
> URL: https://issues.apache.org/jira/browse/IGNITE-10003
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Trivial
> Fix For: 2.8
>
>
> {{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
> {{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
> default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10750) MVCC: Unexpected tx state exception in multithreaded tests
[
https://issues.apache.org/jira/browse/IGNITE-10750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10750:
Description:
There is a number of tests in MVCC suite sporadically fail with the similar
{{IgniteTxMvccVersionCheckedException}}. This problem occurs both on stable and
unstable topologies.
These tests were muted on TC:
* {{CacheMvccPartitionedCoordinatorFailoverTest}}
** {{testUpdate_N_Objects_ClientServer_Backups1__PutGet_CoordinatorFails}}
** {{testAccountsTxScan_ClientServer_Backups2_CoordinatorFails}}
* {{CacheMvccReplicatedCoordinatorFailoverTest}}
**
{{testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
** {{testAccountsTxScan_Server_Backups0_CoordinatorFails}}
* {{CacheMvccTransactionsTest}}
** {{testUpdate_N_Objects_ClientServer_Backups2_Get}}
{noformat}
junit.framework.AssertionFailedError: Unexpected error:
junit.framework.AssertionFailedError: Unexpected tx exception.
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to update backup node:
[localNodeId=fd28ba5c-6216-4aaa-a496-ba24cee1,
remoteNodeId=4198d600-48ee-4627-9802-0d157380]
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.putAll(IgniteCacheProxyImpl.java:1171)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:868)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest.writeAllByMode(CacheMvccAbstractTest.java:2021)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$7.apply(CacheMvccAbstractTest.java:1143)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$7.apply(CacheMvccAbstractTest.java:1116)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1328)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1323)
at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update
backup node: [localNodeId=fd28ba5c-6216-4aaa-a496-ba24cee1,
remoteNodeId=4198d600-48ee-4627-9802-0d157380]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:1012)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2342)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1200(GridDhtTransactionalCacheAdapter.java:112)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:257)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:255)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1127)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:391)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:317)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:108)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:307)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1568)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1196)
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:1092)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
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:1070)
at
[jira] [Updated] (IGNITE-10750) MVCC: Unexpected tx state exception in multithreaded tests
[
https://issues.apache.org/jira/browse/IGNITE-10750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10750:
Description:
There is a number of tests in MVCC suite sporadically fail with the similar
{{IgniteTxMvccVersionCheckedException}}. This problem occurs both on stable and
unstable topologies.
These tests were muted on TC:
*
{{CacheMvccPartitionedCoordinatorFailoverTest.testUpdate_N_Objects_ClientServer_Backups1__PutGet_CoordinatorFails}}
*
{{CacheMvccPartitionedCoordinatorFailoverTest.testAccountsTxScan_ClientServer_Backups2_CoordinatorFails}}
*
{{CacheMvccReplicatedCoordinatorFailoverTest.testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
*
{{CacheMvccReplicatedCoordinatorFailoverTest.testAccountsTxScan_Server_Backups0_CoordinatorFails}}
* {{CacheMvccTransactionsTest.testUpdate_N_Objects_ClientServer_Backups2_Get}}
{noformat}
junit.framework.AssertionFailedError: Unexpected error:
junit.framework.AssertionFailedError: Unexpected tx exception.
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to update backup node:
[localNodeId=fd28ba5c-6216-4aaa-a496-ba24cee1,
remoteNodeId=4198d600-48ee-4627-9802-0d157380]
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.putAll(IgniteCacheProxyImpl.java:1171)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:868)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest.writeAllByMode(CacheMvccAbstractTest.java:2021)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$7.apply(CacheMvccAbstractTest.java:1143)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$7.apply(CacheMvccAbstractTest.java:1116)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1328)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1323)
at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update
backup node: [localNodeId=fd28ba5c-6216-4aaa-a496-ba24cee1,
remoteNodeId=4198d600-48ee-4627-9802-0d157380]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:1012)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2342)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1200(GridDhtTransactionalCacheAdapter.java:112)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:257)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:255)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1127)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:391)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:317)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:108)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:307)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1568)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1196)
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:1092)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
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:1070)
at
[jira] [Updated] (IGNITE-10750) MVCC: Unexpected tx state exception in multithreaded tests
[
https://issues.apache.org/jira/browse/IGNITE-10750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10750:
Description:
There is a number of tests in MVCC suite sporadically fail with the similar
{{IgniteTxMvccVersionCheckedException}}. This problem occurs both on stable and
unstable topologies.
These tests were muted on TC:
*
{{CacheMvccPartitionedCoordinatorFailoverTest.testUpdate_N_Objects_ClientServer_Backups1__PutGet_CoordinatorFails}}
*
{{CacheMvccPartitionedCoordinatorFailoverTest.testAccountsTxScan_ClientServer_Backups2_CoordinatorFails}}
*
{{CacheMvccReplicatedCoordinatorFailoverTest.testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
* {{CacheMvccTransactionsTest.testUpdate_N_Objects_ClientServer_Backups2_Get }}
*
{{CacheMvccReplicatedCoordinatorFailoverTest.testAccountsTxScan_Server_Backups0_CoordinatorFails}}
{noformat}
junit.framework.AssertionFailedError: Unexpected error:
junit.framework.AssertionFailedError: Unexpected tx exception.
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to update backup node:
[localNodeId=fd28ba5c-6216-4aaa-a496-ba24cee1,
remoteNodeId=4198d600-48ee-4627-9802-0d157380]
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.putAll(IgniteCacheProxyImpl.java:1171)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:868)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest.writeAllByMode(CacheMvccAbstractTest.java:2021)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$7.apply(CacheMvccAbstractTest.java:1143)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$7.apply(CacheMvccAbstractTest.java:1116)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1328)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1323)
at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update
backup node: [localNodeId=fd28ba5c-6216-4aaa-a496-ba24cee1,
remoteNodeId=4198d600-48ee-4627-9802-0d157380]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:1012)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2342)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1200(GridDhtTransactionalCacheAdapter.java:112)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:257)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:255)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1127)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:391)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:317)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:108)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:307)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1568)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1196)
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:1092)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
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:1070)
at
[jira] [Commented] (IGNITE-10493) Refactor exchange stages time measurements
[
https://issues.apache.org/jira/browse/IGNITE-10493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725820#comment-16725820
]
Pavel Kovalenko commented on IGNITE-10493:
--
[~agoncharuk] Thank you for review. Merged to master.
> Refactor exchange stages time measurements
> --
>
> Key: IGNITE-10493
> URL: https://issues.apache.org/jira/browse/IGNITE-10493
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.7
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.8
>
>
> At the current implementation, we don't cover and measure all possible code
> executions that influence on PME time. Instead of it we just measure the
> hottest separate parts with the following hardcoded pattern:
> {noformat}
> long time = currentTime();
> ... // some code block
> print ("Stage name performed in " + (currentTime() - time));
> {noformat}
> This approach can be improved. Instead of declaring time variable and print
> the message to log immediately we can introduce a utility class (TimesBag)
> that will hold all stages and their times. The content of TimesBag can be
> printed when the exchange future is done.
> As exchange is a linear process that executes init stage by exchange-worker
> and finish stage by one of the sys thread we can easily cover all exchange
> code base by time cutoffs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10493) Refactor exchange stages time measurements
[
https://issues.apache.org/jira/browse/IGNITE-10493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kovalenko updated IGNITE-10493:
-
Ignite Flags: (was: Docs Required)
> Refactor exchange stages time measurements
> --
>
> Key: IGNITE-10493
> URL: https://issues.apache.org/jira/browse/IGNITE-10493
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.7
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.8
>
>
> At the current implementation, we don't cover and measure all possible code
> executions that influence on PME time. Instead of it we just measure the
> hottest separate parts with the following hardcoded pattern:
> {noformat}
> long time = currentTime();
> ... // some code block
> print ("Stage name performed in " + (currentTime() - time));
> {noformat}
> This approach can be improved. Instead of declaring time variable and print
> the message to log immediately we can introduce a utility class (TimesBag)
> that will hold all stages and their times. The content of TimesBag can be
> printed when the exchange future is done.
> As exchange is a linear process that executes init stage by exchange-worker
> and finish stage by one of the sys thread we can easily cover all exchange
> code base by time cutoffs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10493) Refactor exchange stages time measurements
[
https://issues.apache.org/jira/browse/IGNITE-10493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725819#comment-16725819
]
ASF GitHub Bot commented on IGNITE-10493:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5688
> Refactor exchange stages time measurements
> --
>
> Key: IGNITE-10493
> URL: https://issues.apache.org/jira/browse/IGNITE-10493
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.7
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.8
>
>
> At the current implementation, we don't cover and measure all possible code
> executions that influence on PME time. Instead of it we just measure the
> hottest separate parts with the following hardcoded pattern:
> {noformat}
> long time = currentTime();
> ... // some code block
> print ("Stage name performed in " + (currentTime() - time));
> {noformat}
> This approach can be improved. Instead of declaring time variable and print
> the message to log immediately we can introduce a utility class (TimesBag)
> that will hold all stages and their times. The content of TimesBag can be
> printed when the exchange future is done.
> As exchange is a linear process that executes init stage by exchange-worker
> and finish stage by one of the sys thread we can easily cover all exchange
> code base by time cutoffs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-3269) Benchmark driver stops working when one of servers left grid and backupcount 0
[
https://issues.apache.org/jira/browse/IGNITE-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725803#comment-16725803
]
Andrey Gura commented on IGNITE-3269:
-
[~oleg-ostanin] What is the intention of benchmarking cluster when we have lost
partitions? IMHO, ignoring situations like this is bad idea.
> Benchmark driver stops working when one of servers left grid and backupcount 0
> --
>
> Key: IGNITE-3269
> URL: https://issues.apache.org/jira/browse/IGNITE-3269
> Project: Ignite
> Issue Type: Bug
> Components: yardstick
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
>Assignee: Oleg Ostanin
>Priority: Critical
> Attachments: failed_client_log.zip
>
>
> Test config: 4 hosts with 4 clients and 1 server each, backup count = 0.
> During the test one of the servers was killed. After that one of the clients
> stopped working:
> {noformat}
> [15:31:45,248][WARN ][sys-#27%null%][TcpCommunicationSpi] Connect timed out
> (consider increasing 'failureDetectionTimeout' configuration property)
> [addr=fosters-216/10.20.0.216:47100, failureDetectionTimeout=1]
> [15:31:45,256][WARN ][sys-#27%null%][TcpCommunicationSpi] Failed to connect
> to a remote node (make sure that destination node is alive and operating
> system firewall is disabled on local and remote hosts)
> [addrs=[fosters-216/10.20.0.216:4
> [15:31:45,276][WARN ][disco-event-worker-#52%null%][GridDiscoveryManager]
> Node FAILED: TcpDiscoveryNode [id=f5bcc4d3-aa56-4e51-8672-e799a42990a6,
> addrs=[10.20.0.216, 127.0.0.1], sockAddrs=[fosters-216/10.20.0.216:47500,
> /10.20.0.216:4750
> [15:31:45,324][INFO ][disco-event-worker-#52%null%][GridDiscoveryManager]
> Topology snapshot [ver=22, servers=3, clients=16, CPUs=64, heap=150.0GB]
> ERROR: The benchmark of random operation failed.
> Type '--help' for usage.
> Finishing main test [ts=1465252305413, date=Mon Jun 06 15:31:45 PDT 2016]
> [15:31:45] (err) Failed to execute compound future reducer:
> GridNearTxFinishFuture
> [futId=9c7413d2551-758034b3-0248-4d62-b901-be86d119183c, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false, colocatedLocallyMa
> Type '--help' for usage.
> [15:31:45] (err) Failed to execute compound future reducer:
> GridNearTxFinishFuture
> [futId=6f7413d2551-758034b3-0248-4d62-b901-be86d119183c, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false, colocatedLocallyMa
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:700)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:644)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:607)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:135)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:133)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:624)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:322)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:246)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:83)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:205)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:847)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:105)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:810)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> [15:31:45] (err) Failed to execute compound future reducer:
> GridNearTxFinishFuture
> [futId=ff7413d2551-758034b3-0248-4d62-b901-be86d119183c, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false, colocatedLocallyMa
> at
>
[jira] [Commented] (IGNITE-10745) SQL: jdbc metadata's getColumns returns wrong value for "ORDINAL_POSITION"
[
https://issues.apache.org/jira/browse/IGNITE-10745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725813#comment-16725813
]
Pavel Kuznetsov commented on IGNITE-10745:
--
Also see the same proble with indexes metadata.
> SQL: jdbc metadata's getColumns returns wrong value for "ORDINAL_POSITION"
> ---
>
> Key: IGNITE-10745
> URL: https://issues.apache.org/jira/browse/IGNITE-10745
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Reporter: Pavel Kuznetsov
>Priority: Minor
> Labels: jdbc, metadata, sql
>
> Affected both thin and jdbc v2 drivers.
> jdbc spec says :
> {noformat}
> ORDINAL_POSITION int => index of column in table (starting at 1)
> {noformat}
> but in fact it is a position in the metadata table itself, not position in
> the original table.
> For example we have table
> {code:sql}
> Person(id int primary key, val1 int, val2 bigint, val3 int)
> {code}
> Oridinal number for {{val3}} is 4, but if we specified patterns that leave
> only 1 result ({{PUBLIC.Person.val3}}) returned value will be 1. If we
> select 2 columns by pattern - 2 or 1 and so on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9322) MVCC: implement deadlock detector
[ https://issues.apache.org/jira/browse/IGNITE-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725817#comment-16725817 ] Ivan Pavlukhin commented on IGNITE-9322: [~gvvinblade], your comments are addressed in updated patch, please review. > MVCC: implement deadlock detector > - > > Key: IGNITE-9322 > URL: https://issues.apache.org/jira/browse/IGNITE-9322 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Vladimir Ozerov >Assignee: Ivan Pavlukhin >Priority: Major > Labels: MakeTeamcityGreenAgain > > Deadlocks are not uncommon during SQL execution. > We need to implement distributed deadlock detection protocol for MVCC. > Essentially, nodes should exchange some map of tx wait lists, and try to find > a loop. If loop is found, then one of problematic transactions should be > rolled back. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10745) SQL: jdbc metadata's getColumns returns wrong value for "ORDINAL_POSITION"
[
https://issues.apache.org/jira/browse/IGNITE-10745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-10745:
-
Ignite Flags: (was: Docs Required)
> SQL: jdbc metadata's getColumns returns wrong value for "ORDINAL_POSITION"
> ---
>
> Key: IGNITE-10745
> URL: https://issues.apache.org/jira/browse/IGNITE-10745
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Reporter: Pavel Kuznetsov
>Priority: Minor
> Labels: jdbc, metadata, sql
>
> Affected both thin and jdbc v2 drivers.
> jdbc spec says :
> {noformat}
> ORDINAL_POSITION int => index of column in table (starting at 1)
> {noformat}
> but in fact it is a position in the metadata table itself, not position in
> the original table.
> For example we have table
> {code:sql}
> Person(id int primary key, val1 int, val2 bigint, val3 int)
> {code}
> Oridinal number for {{val3}} is 4, but if we specified patterns that leave
> only 1 result ({{PUBLIC.Person.val3}}) returned value will be 1. If we
> select 2 columns by pattern - 2 or 1 and so on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10745) SQL: jdbc metadata's getColumns returns wrong value for "ORDINAL_POSITION"
[
https://issues.apache.org/jira/browse/IGNITE-10745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-10745:
-
Labels: jdbc metadata sql (was: )
> SQL: jdbc metadata's getColumns returns wrong value for "ORDINAL_POSITION"
> ---
>
> Key: IGNITE-10745
> URL: https://issues.apache.org/jira/browse/IGNITE-10745
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Reporter: Pavel Kuznetsov
>Priority: Minor
> Labels: jdbc, metadata, sql
>
> Affected both thin and jdbc v2 drivers.
> jdbc spec says :
> {noformat}
> ORDINAL_POSITION int => index of column in table (starting at 1)
> {noformat}
> but in fact it is a position in the metadata table itself, not position in
> the original table.
> For example we have table
> {code:sql}
> Person(id int primary key, val1 int, val2 bigint, val3 int)
> {code}
> Oridinal number for {{val3}} is 4, but if we specified patterns that leave
> only 1 result ({{PUBLIC.Person.val3}}) returned value will be 1. If we
> select 2 columns by pattern - 2 or 1 and so on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10745) SQL: jdbc metadata's getColumns returns wrong value for "ORDINAL_POSITION"
[
https://issues.apache.org/jira/browse/IGNITE-10745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-10745:
-
Component/s: sql
> SQL: jdbc metadata's getColumns returns wrong value for "ORDINAL_POSITION"
> ---
>
> Key: IGNITE-10745
> URL: https://issues.apache.org/jira/browse/IGNITE-10745
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Reporter: Pavel Kuznetsov
>Priority: Minor
>
> Affected both thin and jdbc v2 drivers.
> jdbc spec says :
> {noformat}
> ORDINAL_POSITION int => index of column in table (starting at 1)
> {noformat}
> but in fact it is a position in the metadata table itself, not position in
> the original table.
> For example we have table
> {code:sql}
> Person(id int primary key, val1 int, val2 bigint, val3 int)
> {code}
> Oridinal number for {{val3}} is 4, but if we specified patterns that leave
> only 1 result ({{PUBLIC.Person.val3}}) returned value will be 1. If we
> select 2 columns by pattern - 2 or 1 and so on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10730) MVCC TX: Batch WAL datarecords
[ https://issues.apache.org/jira/browse/IGNITE-10730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-10730: - Assignee: Andrew Mashenkov > MVCC TX: Batch WAL datarecords > -- > > Key: IGNITE-10730 > URL: https://issues.apache.org/jira/browse/IGNITE-10730 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Igor Seliverstov >Assignee: Andrew Mashenkov >Priority: Major > > on MVCC updates we make changes one by one and WAL records are written > straight after successful update under the same checkpoint lock. This > produces contention on wal flush operations and harm overall performance. But > we need only one guarantee - all the records have to be written into the log > before prepare start. That means we free to batch such writes (for example 10 > rows in one data record) it shouldn't cause memory issues but will resolve > contention. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10730) MVCC TX: Batch WAL datarecords
[ https://issues.apache.org/jira/browse/IGNITE-10730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10730: -- Ignite Flags: (was: Docs Required) > MVCC TX: Batch WAL datarecords > -- > > Key: IGNITE-10730 > URL: https://issues.apache.org/jira/browse/IGNITE-10730 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > > on MVCC updates we make changes one by one and WAL records are written > straight after successful update under the same checkpoint lock. This > produces contention on wal flush operations and harm overall performance. But > we need only one guarantee - all the records have to be written into the log > before prepare start. That means we free to batch such writes (for example 10 > rows in one data record) it shouldn't cause memory issues but will resolve > contention. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10695) MVCC: Fix cache API conditional update operations.
[ https://issues.apache.org/jira/browse/IGNITE-10695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10695: -- Priority: Minor (was: Major) > MVCC: Fix cache API conditional update operations. > -- > > Key: IGNITE-10695 > URL: https://issues.apache.org/jira/browse/IGNITE-10695 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Affects Versions: 2.7 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Minor > > Operation like putIfAbsent and replace now tries to transfer Predicate > instance (filter) to remote node. > # Predicates are transferred to remote node with each update. > # Predicate should be transferred only for "replace" operation if certain > entry provided, otherwise we should send a correct operation code and use > corresponding static filter on remote side. > # This change will break protocol compatibility. Should we bother about it? > Let's fix protocol and add tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10421) MVCC: Assertion in checkpointer thread.
[
https://issues.apache.org/jira/browse/IGNITE-10421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-10421:
--
Priority: Critical (was: Major)
> MVCC: Assertion in checkpointer thread.
> ---
>
> Key: IGNITE-10421
> URL: https://issues.apache.org/jira/browse/IGNITE-10421
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, persistence
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Labels: WAL, mvcc_stabilization_stage_1
>
> Reproducers:
> * {{WalModeChangeAdvancedSelfTest#testJoin}} with enabled MVCC.
> * {{IgniteDynamicCacheStartFailWithPersistenceTest}}
> {noformat}
> [2018-11-27
> 14:56:47,548][ERROR][db-checkpoint-thread-#358%srv_3%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=SingletonSet [SYSTEM_WORKER_BLOCKED]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Compound exception for CountDownFuture.]]
> class org.apache.ignite.IgniteCheckedException: Compound exception for
> CountDownFuture.
> at
> org.apache.ignite.internal.util.future.CountDownFuture.addError(CountDownFuture.java:72)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:46)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:28)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3957)
> 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)
> Suppressed: java.lang.AssertionError: off=3000,
> allocated=1000, pageId=00020002,
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
> ... 3 more
> Suppressed: java.lang.AssertionError: off=4000,
> allocated=1000, pageId=00020003,
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
> ... 3 more
> Suppressed: java.lang.AssertionError: off=2000,
> allocated=1000, pageId=00020001,
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
> ... 3 more
> {noformat}
--
This message was sent by Atlassian JIRA
[jira] [Created] (IGNITE-10754) Query history statistics API
Yury Gerzhedovich created IGNITE-10754: -- Summary: Query history statistics API Key: IGNITE-10754 URL: https://issues.apache.org/jira/browse/IGNITE-10754 Project: Ignite Issue Type: Task Components: sql Reporter: Yury Gerzhedovich Assignee: Yury Gerzhedovich As of now we have query statistics (*_org.apache.ignite.IgniteCache#queryMetrics_*) , but have few issues. 1) Duration execution it just time between start execution and return cursor to client and doesn't include all life time of query. 2) It doesn't know about multistatement queries. Such queries participate in statistics as single query without splitting. 3) API to access the statistics expose as depend on cache, however query don't have such dependency. Need to create parallel similar realization as we already have. Use new infrastructure of tracking running queries developed under IGNITE-10621 and update statistics on unregister phase. Expose API on upper level then it placed now. Right place will be written later. Old API will be marked as deprecated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9903) Copy only actual amount of data during archiving of WAL segment
[
https://issues.apache.org/jira/browse/IGNITE-9903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725808#comment-16725808
]
Andrey Gura commented on IGNITE-9903:
-
[~astelmak] The PR has too many merge conflicts after implementation of
IGITE-9909. Could you please pull the latest changes form master branch and
resolve conflicts?
> Copy only actual amount of data during archiving of WAL segment
> ---
>
> Key: IGNITE-9903
> URL: https://issues.apache.org/jira/browse/IGNITE-9903
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Alexey Stelmak
>Priority: Major
> Fix For: 2.8
>
>
> Current WAL archiver implementation copies full WAL segment to the archive
> while actual size of the segment can be significantly less then
> {{maxWalSegmentSize}} (segment files are preallocated for max possible
> segment size).
> In order to reduce disk space consuming we need copy only actual data of
> segment using {{SWITCH_SEGMENT_RECORD}} as marker. It will require some kind
> of WAL iterator implementation that will just copy WAL records using
> information about record size without records deserialization.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10753) MVCC: Sometimes vacuum does not cleanup all outdated versions
Roman Kondakov created IGNITE-10753:
---
Summary: MVCC: Sometimes vacuum does not cleanup all outdated
versions
Key: IGNITE-10753
URL: https://issues.apache.org/jira/browse/IGNITE-10753
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Roman Kondakov
When mvcc test is finished, we check if there any outdated versions are left in
cache and not cleaned by vacuum. If so, an exception is thrown. There are some
tests with this problem:
* {{CacheMvccTransactionsTest.testCleanupWaitsForGet1}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
