[jira] [Updated] (IGNITE-10417) notifyDiscoveryListener() call can be lost.
[ https://issues.apache.org/jira/browse/IGNITE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-10417: Summary: notifyDiscoveryListener() call can be lost. (was: notifyDiscoveryListener() call can be lost) > notifyDiscoveryListener() call can be lost. > --- > > Key: IGNITE-10417 > URL: https://issues.apache.org/jira/browse/IGNITE-10417 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > > 1) ServerImpl:5455 notifyDiscoveryListener can not be called in case of > spiState != CONNECTED, for example DISCONNECTING which is valid state > nevetheless inside notifyDiscoveryListener we check spiState == CONNECTED || > spiState == DISCONNECTING, also we need to improve logging in > notifyDiscoveryListener(). > 2) Improve logging on duplicated custom discovery event. > 3) Add assert if msg.creatorNodeId() doesn't exist in topology this is bad > behaviour taht should lead to node fail. > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10442) Failed checks on successful tasks canceling
[ https://issues.apache.org/jira/browse/IGNITE-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708335#comment-16708335 ] Ivan Fedotov commented on IGNITE-10442: --- I increased size of thread pool in the test and run it 100 times on TC [1]. Results look good, [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Pds4=buildTypeStatusDiv_IgniteTests24Java8=pull%2F5548%2Fhead > Failed checks on successful tasks canceling > --- > > Key: IGNITE-10442 > URL: https://issues.apache.org/jira/browse/IGNITE-10442 > Project: Ignite > Issue Type: Test >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Trivial > > Test on checks that tasks canceling does not lead to node failure > [testFailNodesOnCanceledTask|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1511425443970810161=testDetails_IgniteTests24Java8=%3Cdefault%3E] > seems flaky. > One of the reason - "Possible thread pool starvation detected". > It is necessary to investigate test and fix it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10242) NPE in GridDhtPartitionDemander#handleSupplyMessage when concurrently rebalancing and stopping cache in same cache group.
[
https://issues.apache.org/jira/browse/IGNITE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708329#comment-16708329
]
Vladislav Pyatkov commented on IGNITE-10242:
Looks good to me.
> NPE in GridDhtPartitionDemander#handleSupplyMessage when concurrently
> rebalancing and stopping cache in same cache group.
> -
>
> Key: IGNITE-10242
> URL: https://issues.apache.org/jira/browse/IGNITE-10242
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5, 2.6
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.8
>
> Attachments: IgniteDemanderOnStoppingCacheTest.java
>
>
> NPE in GridDhtPartitionDemander#handleSupplyMessage occurs when concurrently
> rebalancing and stopping cache in same cache group. Reproducer is attached
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.preloadEntry(GridDhtPartitionDemander.java:893)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:772)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:331)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:411)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:401)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:583)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:101)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10514) Cache validation on the primary node may result in AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-10514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-10514:
---
Labels: MakeTeamcityGreenAgain (was: )
> Cache validation on the primary node may result in AssertionError
> -
>
> Key: IGNITE-10514
> URL: https://issues.apache.org/jira/browse/IGNITE-10514
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Cache validation on the primary node, that was introduced by IGNITE-10413,
> may lead to the following AssertionError.
> {code:java}
> java.lang.AssertionError: GridDhtPartitionsExchangeFuture
> [firstDiscoEvt=DiscoveryCustomEvent [customMsg=CacheAffinityChangeMessage
> [...]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1788)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3184)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:138)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1059)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:383)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:299)
> 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)
> {code}
> Let's consider the following scenario:
> * Start one node and upload data.
> * Start a new node (note that this step triggers rebalancing).
> * Start explicit transaction and try to update atomic cache (it is assumed
> that atomic operation are allowed for use inside transactions, see Ignite
> system property DFLT_ALLOW_ATOMIC_OPS_IN_TX)
> {code:java}
> IgniteTransactions txs = ignite.transactions();
> try (Transaction tx = txs.txStart()) {
> atomicCache.put();
> tx.commit();
> }
> {code}
> Let's assume that the transaction mapped on the topology version that is
> related to {{NODE_JOIN}} event,
> on the other hand, the corresponding request
> {{GridNearAtomicAbstractUpdateRequest}} can be validated on the primary node
> using the next topology version, triggered by {{CacheAffinityMessage}}.
> {code:java|title=GridDhtAtomicCache.java}
> private void updateAllAsyncInternal0() {
> ...
> if (validateCache) {
> GridDhtTopologyFuture topFut = top.topologyVersionFuture();
> // There is a chance that the topFut is not done yet!
> assert topFut.isDone() : topFut;
> Throwable err = topFut.validateCache(ctx, req.recovery(), false,
> null, null);
> ...
> }
> }{code}
> That is the root cause of the {{AssertionError}} mentioned above.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10461) MVCC: Create "PDS 1" test suite for MVCC mode.
[ https://issues.apache.org/jira/browse/IGNITE-10461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708318#comment-16708318 ] ASF GitHub Bot commented on IGNITE-10461: - GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/5564 IGNITE-10461: Create Mvcc PDS test suite. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10461 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5564.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 #5564 commit b806f3b4d73f16c0c3e30f255700b4cde415c3b4 Author: Andrey V. Mashenkov Date: 2018-12-04T07:39:36Z IGNITE-10461: Create Mvcc PDS test suite. > MVCC: Create "PDS 1" test suite for MVCC mode. > -- > > Key: IGNITE-10461 > URL: https://issues.apache.org/jira/browse/IGNITE-10461 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > > Create MVCC version of IgnitePdsTestSuite and add it to TC. > All non-relevant tests should be marked as ignored. > Failed tests should be muted and tickets should be created for unknown > failure reasons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10461) MVCC: Create "PDS 1" test suite for MVCC mode.
[ https://issues.apache.org/jira/browse/IGNITE-10461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-10461: - Assignee: Andrew Mashenkov > MVCC: Create "PDS 1" test suite for MVCC mode. > -- > > Key: IGNITE-10461 > URL: https://issues.apache.org/jira/browse/IGNITE-10461 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > > Create MVCC version of IgnitePdsTestSuite and add it to TC. > All non-relevant tests should be marked as ignored. > Failed tests should be muted and tickets should be created for unknown > failure reasons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10511) disco-event-worker can be deadlocked by BinaryContext.metadata running is sys striped pool waiting for cache entry lock
[
https://issues.apache.org/jira/browse/IGNITE-10511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708292#comment-16708292
]
ASF GitHub Bot commented on IGNITE-10511:
-
GitHub user voropava opened a pull request:
https://github.com/apache/ignite/pull/5563
IGNITE-10511 removeExplicitNodeLocks() removed.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10511
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5563.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 #5563
commit b657b8231677b3e9b80ef7b72e1bd7f87e59a69d
Author: Pavel Voronkin
Date: 2018-12-04T07:11:42Z
IGNITE-10511 removeExplicitNodeLocks() removed.
> disco-event-worker can be deadlocked by BinaryContext.metadata running is sys
> striped pool waiting for cache entry lock
> ---
>
> Key: IGNITE-10511
> URL: https://issues.apache.org/jira/browse/IGNITE-10511
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Priority: Major
> Attachments: race.txt
>
>
> See attached thread dump:
> disco-event-worker hangs on removeExplicitNodeLocks() on GridCacheMapEntry
> which is held by GridDistributedTxRemoteAdapter acquired in
> GridCacheMapEntry.innerSet().
> CacheObjectBinaryProcessorImpl is waiting on metadata message on discovery,
> which can be processed due to disco-event-worker is stuck.
> Possible fix:
> {code:java}
> public void onNodeLeft(final ClusterNode node) {
> if (isDone() || !enterBusy())
> return;
> cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
> try {
> onDiscoveryEvent(new IgniteRunnable() {
> @Override public void run() {
> if (isDone() || !enterBusy())
> return;
>
> ...
> }
> });
> }
> finally {
> ...
> }
> }
> {code}
> As we can see most of the processing is done async in IgniteRunnable() in
> exchange-worker.
>
> We can move
> {code:java}
> cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
> {code}
> inside this Runnable's body.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10205) add to utility command - ./control.sh --cache idle_verify --dump abbility to exclude cache from output file
[
https://issues.apache.org/jira/browse/IGNITE-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708255#comment-16708255
]
Ignite TC Bot commented on IGNITE-10205:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Hibernate 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2450517]]
* HibernateL2CacheTransactionalSelfTest.testRegionClear (last started)
{color:#d04437}JDBC Driver{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2450525]]
*
JdbcThinTransactionsServerNoAutoCommitComplexSelfTest.testBatchDmlStatementsIntermediateFailure
(last started)
{color:#d04437}Cache (Restarts) 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2450564]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2450601buildTypeId=IgniteTests24Java8_RunAll]
> add to utility command - ./control.sh --cache idle_verify --dump abbility to
> exclude cache from output file
>
>
> Key: IGNITE-10205
> URL: https://issues.apache.org/jira/browse/IGNITE-10205
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: ARomantsov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10242) NPE in GridDhtPartitionDemander#handleSupplyMessage when concurrently rebalancing and stopping cache in same cache group.
[
https://issues.apache.org/jira/browse/IGNITE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708239#comment-16708239
]
Ignite TC Bot commented on IGNITE-10242:
{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=2455583buildTypeId=IgniteTests24Java8_RunAll]
> NPE in GridDhtPartitionDemander#handleSupplyMessage when concurrently
> rebalancing and stopping cache in same cache group.
> -
>
> Key: IGNITE-10242
> URL: https://issues.apache.org/jira/browse/IGNITE-10242
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5, 2.6
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.8
>
> Attachments: IgniteDemanderOnStoppingCacheTest.java
>
>
> NPE in GridDhtPartitionDemander#handleSupplyMessage occurs when concurrently
> rebalancing and stopping cache in same cache group. Reproducer is attached
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.preloadEntry(GridDhtPartitionDemander.java:893)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:772)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:331)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:411)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:401)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:583)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:101)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10356) JDBC thin driver returns wrong data type for Date and Decimal SQL type
[
https://issues.apache.org/jira/browse/IGNITE-10356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708104#comment-16708104
]
Ray commented on IGNITE-10356:
--
[~vozerov]
I have expanded imports.
Please take a look.
> JDBC thin driver returns wrong data type for Date and Decimal SQL type
> --
>
> Key: IGNITE-10356
> URL: https://issues.apache.org/jira/browse/IGNITE-10356
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.6, 2.7
>Reporter: Ray
>Assignee: Ray
>Priority: Critical
> Fix For: 2.8
>
>
> JDBC thin driver will return wrong metadata for column type when user creates
> a table with Date and Decimal type.
>
> Steps to reproduce.
> 1. Start one node and create table using this command
> create table a(a varchar, b decimal,c date, primary key(a));
> 2. Run "!desc a" to show the metadata of table a
> This results is as follows:
> TABLE_CAT
> TABLE_SCHEM PUBLIC
> TABLE_NAME A
> COLUMN_NAME A
> DATA_TYPE 12
> TYPE_NAME VARCHAR
> COLUMN_SIZE null
> BUFFER_LENGTH null
> DECIMAL_DIGITS null
> NUM_PREC_RADIX 10
> NULLABLE 1
> REMARKS
> COLUMN_DEF
> SQL_DATA_TYPE 12
> SQL_DATETIME_SUB null
> CHAR_OCTET_LENGTH 2147483647
> ORDINAL_POSITION 1
> IS_NULLABLE YES
> SCOPE_CATLOG
> SCOPE_SCHEMA
> SCOPE_TABLE
> SOURCE_DATA_TYPE null
> IS_AUTOINCREMENT NO
> IS_GENERATEDCOLUMN NO
> TABLE_CAT
> TABLE_SCHEM PUBLIC
> TABLE_NAME A
> COLUMN_NAME B
> {color:#d04437}DATA_TYPE {color}
> {color:#d04437}TYPE_NAME OTHER{color}
> COLUMN_SIZE null
> BUFFER_LENGTH null
> DECIMAL_DIGITS null
> NUM_PREC_RADIX 10
> NULLABLE 1
> REMARKS
> COLUMN_DEF
> {color:#d04437}SQL_DATA_TYPE {color}
> SQL_DATETIME_SUB null
> CHAR_OCTET_LENGTH 2147483647
> ORDINAL_POSITION 2
> IS_NULLABLE YES
> SCOPE_CATLOG
> SCOPE_SCHEMA
> SCOPE_TABLE
> SOURCE_DATA_TYPE null
> IS_AUTOINCREMENT NO
> IS_GENERATEDCOLUMN NO
> TABLE_CAT
> TABLE_SCHEM PUBLIC
> TABLE_NAME A
> COLUMN_NAME C
> {color:#d04437}DATA_TYPE {color}
> {color:#d04437}TYPE_NAME OTHER{color}
> COLUMN_SIZE null
> BUFFER_LENGTH null
> DECIMAL_DIGITS null
> NUM_PREC_RADIX 10
> NULLABLE 1
> REMARKS
> {color:#33}COLUMN_DEF{color}
> {color:#d04437} SQL_DATA_TYPE {color}
> SQL_DATETIME_SUB null
> CHAR_OCTET_LENGTH 2147483647
> ORDINAL_POSITION 3
> IS_NULLABLE YES
> SCOPE_CATLOG
> SCOPE_SCHEMA
> SCOPE_TABLE
> SOURCE_DATA_TYPE null
> IS_AUTOINCREMENT NO
> IS_GENERATEDCOLUMN NO
>
> Column b and c has the wrong DATA_TYPE and TYPE_NAME.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10514) Cache validation on the primary node may result in AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-10514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708086#comment-16708086
]
Ignite TC Bot commented on IGNITE-10514:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}JDBC Driver{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2456507]]
{color:#d04437}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2454441]]
* IgniteBasicTestSuite: GridServiceReassignmentSelfTest.testNodeSingleton -
1,0% fails in last 100 master runs.
{color:#d04437}Cache (Failover SSL){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2456539]]
* IgniteCacheFailoverTestSuiteSsl: IgniteCacheSslStartStopSelfTest.testInvoke -
0,0% fails in last 100 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2454496buildTypeId=IgniteTests24Java8_RunAll]
> Cache validation on the primary node may result in AssertionError
> -
>
> Key: IGNITE-10514
> URL: https://issues.apache.org/jira/browse/IGNITE-10514
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
>
> Cache validation on the primary node, that was introduced by IGNITE-10413,
> may lead to the following AssertionError.
> {code:java}
> java.lang.AssertionError: GridDhtPartitionsExchangeFuture
> [firstDiscoEvt=DiscoveryCustomEvent [customMsg=CacheAffinityChangeMessage
> [...]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1788)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3184)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:138)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1059)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:383)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:299)
> 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)
> {code}
> Let's consider the following scenario:
> * Start one node and upload data.
> * Start a new node (note that this step triggers rebalancing).
> * Start explicit transaction and try to update atomic cache (it is assumed
> that atomic operation are allowed for use inside transactions, see Ignite
> system property DFLT_ALLOW_ATOMIC_OPS_IN_TX)
> {code:java}
> IgniteTransactions txs = ignite.transactions();
> try (Transaction tx = txs.txStart()) {
> atomicCache.put();
> tx.commit();
> }
> {code}
> Let's assume that the transaction mapped on the topology version that is
> related to {{NODE_JOIN}} event,
> on the other hand, the corresponding request
> {{GridNearAtomicAbstractUpdateRequest}} can be validated on the primary node
> using the next topology version, triggered by {{CacheAffinityMessage}}.
>
[jira] [Updated] (IGNITE-10175) migrate core module tests from Junit 3 to 4
[ https://issues.apache.org/jira/browse/IGNITE-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko updated IGNITE-10175: Labels: MakeTeamcityGreenAgain (was: ) > migrate core module tests from Junit 3 to 4 > --- > > Key: IGNITE-10175 > URL: https://issues.apache.org/jira/browse/IGNITE-10175 > Project: Ignite > Issue Type: Sub-task >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > > If needed, refer parent task for more details. > Migrate using new API introduced at prior step. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10175) migrate core module tests from Junit 3 to 4
[ https://issues.apache.org/jira/browse/IGNITE-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707992#comment-16707992 ] ASF GitHub Bot commented on IGNITE-10175: - GitHub user oignatenko opened a pull request: https://github.com/apache/ignite/pull/5562 IGNITE-10175 migrate core module tests from Junit 3 to 4 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10175 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5562.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 #5562 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 from Junit 3 to 4 - wip
[jira] [Comment Edited] (IGNITE-10406) .NET Failed to run ScanQuery with custom filter after server node restart
[ https://issues.apache.org/jira/browse/IGNITE-10406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707742#comment-16707742 ] Pavel Tupitsyn edited comment on IGNITE-10406 at 12/3/18 8:29 PM: -- GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/5561 IGNITE-10406 .NET: Reset writer structures on reconnect You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-10406 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5561.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 #5561 was (Author: githubbot): GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/5561 IGNITE-10406 .NET: Reset writer structures on reconnect You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-10406 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5561.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 #5561 commit 083fef611d35f78ca0a7bdfa3f7cf8ab1f25d314 Author: Pavel Tupitsyn Date: 2018-11-27T14:37:24Z IGNITE-10406 .NET Failed to run ScanQuery with custom filter after server node restart - add test commit c3d48ebf25e46b1b18c5b3c69f50250898c12958 Author: Pavel Tupitsyn Date: 2018-12-01T14:30:11Z TODOs commit ac52623248183b294e4b1d3e0b35304680a8286a Author: Pavel Tupitsyn Date: 2018-12-01T14:35:13Z TODOs commit ca9c0c4a985ccf24a3fc93d68bb9cc861f829708 Author: Pavel Tupitsyn Date: 2018-12-01T14:45:16Z Add test for non-empty filter commit 53137ad302cea7fb01677f582b914daf5c4acb53 Author: Pavel Tupitsyn Date: 2018-12-01T14:46:52Z Add test for non-empty filter commit 194a3316e23d502a1bb8fa3942a788450c44a579 Author: Pavel Tupitsyn Date: 2018-12-01T14:51:00Z Add test for non-empty filter commit 431aa95a3f88a0163888cbfcbad9edbf323fd614 Author: Pavel Tupitsyn Date: 2018-12-03T17:57:26Z update TODOs commit 5dd95b5d8ed94335ae0f63047c73622dbfae691d Author: Pavel Tupitsyn Date: 2018-12-03T18:27:15Z update TODOs commit 439cf575070c78aa2bac052197c14545c37408b7 Author: Pavel Tupitsyn Date: 2018-12-03T18:37:22Z Add TODO commit 5bca7238233a0e269d836c66081c7a9b5a5f9fa8 Author: Pavel Tupitsyn Date: 2018-12-03T18:40:10Z Cleanup test code commit 7f5c5d50e2d25543295b8a168ba855a9da4b5715 Author: Pavel Tupitsyn Date: 2018-12-03T18:40:51Z Revert unrelated changes commit 6488156700c5fd44c1cf74d4671394f40c51074b Author: Pavel Tupitsyn Date: 2018-12-03T18:48:41Z Cleanup commit 0c5a43b12918e8089ad37ad2fcd897b7cab8fbd6 Author: Pavel Tupitsyn Date: 2018-12-03T19:00:14Z Implement writer structure reset commit 0892d9e97bccdf41a38fe01a42354e78f903aae9 Author: Pavel Tupitsyn Date: 2018-12-03T19:05:32Z Implement writer structure reset commit ad80b6a9ac803eabd28b098fea61f86720158058 Author: Pavel Tupitsyn Date: 2018-12-03T19:07:25Z Implement writer structure reset commit 3b77263c72692e6930e74eb11be59181d6f0c3d6 Author: Pavel Tupitsyn Date: 2018-12-03T19:09:56Z Fix tests commit a5b20c139ad8216dac735cb846a5e4c3562808df Author: Pavel Tupitsyn Date: 2018-12-03T19:10:37Z Fix tests commit cf912013547f128e84c17dbafb0f327549c6d4a7 Author: Pavel Tupitsyn Date: 2018-12-03T19:41:49Z TODOs commit d5faccd7d8b6055581649a9717e867cd76974d21 Author: Pavel Tupitsyn Date: 2018-12-03T19:49:29Z TODOs and cleanup commit 4606c7f55233f4005a8c2f75552e2ac1df292f4c Author: Pavel Tupitsyn Date: 2018-12-03T19:56:33Z Adding concurrency test commit eea92638bf64dc2aa1013e041e5635c938ec2198 Author: Pavel Tupitsyn Date: 2018-12-03T20:00:56Z Adding concurrency test commit eda2a0a256b44e8a6dc0ed28498e677fd3159d48 Author: Pavel Tupitsyn Date: 2018-12-03T20:01:14Z Adding concurrency test commit 1c73a3fe9c70cb28fb1a7b36e56711f20fb57925 Author: Pavel Tupitsyn Date: 2018-12-03T20:03:01Z Adding concurrency test commit 4ce52f7f6a46eba00bc8eeb79a3256b67f307644 Author: Pavel Tupitsyn Date: 2018-12-03T20:03:48Z Adding concurrency test commit f46cc5cd01b96ead5136c8e3380766abcc5c303d Author: Pavel Tupitsyn Date: 2018-12-03T20:15:00Z Adding concurrency test commit 244229cfd4d1be52670ccb32097515e06fc8da38 Author: Pavel Tupitsyn Date: 2018-12-03T20:25:46Z Add concurrency assumptions commit f104a6e419445adea972b9f300730bf9094109be Author: Pavel Tupitsyn Date: 2018-12-03T20:27:30Z Merge remote-tracking branch
[jira] [Commented] (IGNITE-10406) .NET Failed to run ScanQuery with custom filter after server node restart
[ https://issues.apache.org/jira/browse/IGNITE-10406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707742#comment-16707742 ] ASF GitHub Bot commented on IGNITE-10406: - GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/5561 IGNITE-10406 .NET: Reset writer structures on reconnect You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-10406 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5561.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 #5561 commit 083fef611d35f78ca0a7bdfa3f7cf8ab1f25d314 Author: Pavel Tupitsyn Date: 2018-11-27T14:37:24Z IGNITE-10406 .NET Failed to run ScanQuery with custom filter after server node restart - add test commit c3d48ebf25e46b1b18c5b3c69f50250898c12958 Author: Pavel Tupitsyn Date: 2018-12-01T14:30:11Z TODOs commit ac52623248183b294e4b1d3e0b35304680a8286a Author: Pavel Tupitsyn Date: 2018-12-01T14:35:13Z TODOs commit ca9c0c4a985ccf24a3fc93d68bb9cc861f829708 Author: Pavel Tupitsyn Date: 2018-12-01T14:45:16Z Add test for non-empty filter commit 53137ad302cea7fb01677f582b914daf5c4acb53 Author: Pavel Tupitsyn Date: 2018-12-01T14:46:52Z Add test for non-empty filter commit 194a3316e23d502a1bb8fa3942a788450c44a579 Author: Pavel Tupitsyn Date: 2018-12-01T14:51:00Z Add test for non-empty filter commit 431aa95a3f88a0163888cbfcbad9edbf323fd614 Author: Pavel Tupitsyn Date: 2018-12-03T17:57:26Z update TODOs commit 5dd95b5d8ed94335ae0f63047c73622dbfae691d Author: Pavel Tupitsyn Date: 2018-12-03T18:27:15Z update TODOs commit 439cf575070c78aa2bac052197c14545c37408b7 Author: Pavel Tupitsyn Date: 2018-12-03T18:37:22Z Add TODO commit 5bca7238233a0e269d836c66081c7a9b5a5f9fa8 Author: Pavel Tupitsyn Date: 2018-12-03T18:40:10Z Cleanup test code commit 7f5c5d50e2d25543295b8a168ba855a9da4b5715 Author: Pavel Tupitsyn Date: 2018-12-03T18:40:51Z Revert unrelated changes commit 6488156700c5fd44c1cf74d4671394f40c51074b Author: Pavel Tupitsyn Date: 2018-12-03T18:48:41Z Cleanup commit 0c5a43b12918e8089ad37ad2fcd897b7cab8fbd6 Author: Pavel Tupitsyn Date: 2018-12-03T19:00:14Z Implement writer structure reset commit 0892d9e97bccdf41a38fe01a42354e78f903aae9 Author: Pavel Tupitsyn Date: 2018-12-03T19:05:32Z Implement writer structure reset commit ad80b6a9ac803eabd28b098fea61f86720158058 Author: Pavel Tupitsyn Date: 2018-12-03T19:07:25Z Implement writer structure reset commit 3b77263c72692e6930e74eb11be59181d6f0c3d6 Author: Pavel Tupitsyn Date: 2018-12-03T19:09:56Z Fix tests commit a5b20c139ad8216dac735cb846a5e4c3562808df Author: Pavel Tupitsyn Date: 2018-12-03T19:10:37Z Fix tests commit cf912013547f128e84c17dbafb0f327549c6d4a7 Author: Pavel Tupitsyn Date: 2018-12-03T19:41:49Z TODOs commit d5faccd7d8b6055581649a9717e867cd76974d21 Author: Pavel Tupitsyn Date: 2018-12-03T19:49:29Z TODOs and cleanup commit 4606c7f55233f4005a8c2f75552e2ac1df292f4c Author: Pavel Tupitsyn Date: 2018-12-03T19:56:33Z Adding concurrency test commit eea92638bf64dc2aa1013e041e5635c938ec2198 Author: Pavel Tupitsyn Date: 2018-12-03T20:00:56Z Adding concurrency test commit eda2a0a256b44e8a6dc0ed28498e677fd3159d48 Author: Pavel Tupitsyn Date: 2018-12-03T20:01:14Z Adding concurrency test commit 1c73a3fe9c70cb28fb1a7b36e56711f20fb57925 Author: Pavel Tupitsyn Date: 2018-12-03T20:03:01Z Adding concurrency test commit 4ce52f7f6a46eba00bc8eeb79a3256b67f307644 Author: Pavel Tupitsyn Date: 2018-12-03T20:03:48Z Adding concurrency test commit f46cc5cd01b96ead5136c8e3380766abcc5c303d Author: Pavel Tupitsyn Date: 2018-12-03T20:15:00Z Adding concurrency test commit 244229cfd4d1be52670ccb32097515e06fc8da38 Author: Pavel Tupitsyn Date: 2018-12-03T20:25:46Z Add concurrency assumptions commit f104a6e419445adea972b9f300730bf9094109be Author: Pavel Tupitsyn Date: 2018-12-03T20:27:30Z Merge remote-tracking branch 'origin/master' into ignite-10406 > .NET Failed to run ScanQuery with custom filter after server node restart > - > > Key: IGNITE-10406 > URL: https://issues.apache.org/jira/browse/IGNITE-10406 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.5, 2.6 >Reporter: Ivan Daschinskiy >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .net > Fix For: 2.8 > > Attachments: CacheQueriesWithRestartServerTest.cs > > >
[jira] [Commented] (IGNITE-10516) Storage is corrupted after CREATE INDEX IF NOT EXISTS on different tables
[
https://issues.apache.org/jira/browse/IGNITE-10516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707724#comment-16707724
]
ASF GitHub Bot commented on IGNITE-10516:
-
GitHub user slukyano opened a pull request:
https://github.com/apache/ignite/pull/5560
IGNITE-10516: Storage is corrupted after CREATE INDEX IF NOT EXISTS on
different tables
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10516
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5560.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 #5560
commit dfcaaa9374c289deedb0ef1921dd645fd077531c
Author: Stanislav Lukyanov
Date: 2018-12-03T20:06:27Z
IGNITE-10516: Add test.
> Storage is corrupted after CREATE INDEX IF NOT EXISTS on different tables
> -
>
> Key: IGNITE-10516
> URL: https://issues.apache.org/jira/browse/IGNITE-10516
> Project: Ignite
> Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Priority: Major
>
> Given two tables in the same schema, we can't create an index with the same
> name for both tables. In other words, the following code leads to an error -
> which is good.
> {code}
> CREATE INDEX IDX on T1 (COL);
> CREATE INDEX IDX on T2 (COL);
> {code}
> If used with `IF NOT EXISTS`, the queries pass. It might be OK or not - one
> needs to look into SQL spec to check if the second operation should be a
> no-op (because IDX exists) or fail (because IDX exists for a different table,
> so the caller is probably doing something wrong)
> {code}
> CREATE INDEX IDX on T1 (COL);
> CREATE INDEX IF NOT EXISTS IDX on T2 (COL);
> {code}
> However, if persistence is enabled, the node will fail to restart complaining
> about duplicate index names.
> {code}
> class org.apache.ignite.IgniteCheckedException: Duplicate index name
> [cache=SQL_PUBLIC_T2, schemaName=PUBLIC, idxName=IDX, existingTable=T,
> table=T2]
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1183)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:959)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:900)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:888)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:854)
> at
> org.apache.ignite.IndexWithSameNameTest.test(IndexWithSameNameTest.java:77)
> 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.IgniteException: Duplicate index name
> [cache=SQL_PUBLIC_T2, schemaName=PUBLIC, idxName=IDX, existingTable=T,
> table=T2]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1650)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:803)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:866)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2595)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1400(GridCacheProcessor.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5481)
> at
>
[jira] [Commented] (IGNITE-10516) Storage is corrupted after CREATE INDEX IF NOT EXISTS on different tables
[
https://issues.apache.org/jira/browse/IGNITE-10516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707725#comment-16707725
]
Stanislav Lukyanov commented on IGNITE-10516:
-
Added a reproducer as a test in https://github.com/apache/ignite/pull/5560.
> Storage is corrupted after CREATE INDEX IF NOT EXISTS on different tables
> -
>
> Key: IGNITE-10516
> URL: https://issues.apache.org/jira/browse/IGNITE-10516
> Project: Ignite
> Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Priority: Major
>
> Given two tables in the same schema, we can't create an index with the same
> name for both tables. In other words, the following code leads to an error -
> which is good.
> {code}
> CREATE INDEX IDX on T1 (COL);
> CREATE INDEX IDX on T2 (COL);
> {code}
> If used with `IF NOT EXISTS`, the queries pass. It might be OK or not - one
> needs to look into SQL spec to check if the second operation should be a
> no-op (because IDX exists) or fail (because IDX exists for a different table,
> so the caller is probably doing something wrong)
> {code}
> CREATE INDEX IDX on T1 (COL);
> CREATE INDEX IF NOT EXISTS IDX on T2 (COL);
> {code}
> However, if persistence is enabled, the node will fail to restart complaining
> about duplicate index names.
> {code}
> class org.apache.ignite.IgniteCheckedException: Duplicate index name
> [cache=SQL_PUBLIC_T2, schemaName=PUBLIC, idxName=IDX, existingTable=T,
> table=T2]
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1183)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:959)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:900)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:888)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:854)
> at
> org.apache.ignite.IndexWithSameNameTest.test(IndexWithSameNameTest.java:77)
> 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.IgniteException: Duplicate index name
> [cache=SQL_PUBLIC_T2, schemaName=PUBLIC, idxName=IDX, existingTable=T,
> table=T2]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1650)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:803)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:866)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2595)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1400(GridCacheProcessor.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5481)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:947)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1922)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1050)
> ... 18 more
> {code}
> It looks like the second index (on T2) is partially created after all.
> Need to either block index creation by `CREATE INDEX IF NOT EXISTS`
> completely, or just fail that query when the table names don't match (if SQL
> spec allows it).
--
This message was sent by
[jira] [Updated] (IGNITE-10516) Storage is corrupted after CREATE INDEX IF NOT EXISTS on different tables
[
https://issues.apache.org/jira/browse/IGNITE-10516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov updated IGNITE-10516:
Description:
Given two tables in the same schema, we can't create an index with the same
name for both tables. In other words, the following code leads to an error -
which is good.
{code}
CREATE INDEX IDX on T1 (COL);
CREATE INDEX IDX on T2 (COL);
{code}
If used with `IF NOT EXISTS`, the queries pass. It might be OK or not - one
needs to look into SQL spec to check if the second operation should be a no-op
(because IDX exists) or fail (because IDX exists for a different table, so the
caller is probably doing something wrong)
{code}
CREATE INDEX IDX on T1 (COL);
CREATE INDEX IF NOT EXISTS IDX on T2 (COL);
{code}
However, if persistence is enabled, the node will fail to restart complaining
about duplicate index names.
{code}
class org.apache.ignite.IgniteCheckedException: Duplicate index name
[cache=SQL_PUBLIC_T2, schemaName=PUBLIC, idxName=IDX, existingTable=T, table=T2]
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1183)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:959)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:900)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:888)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:854)
at
org.apache.ignite.IndexWithSameNameTest.test(IndexWithSameNameTest.java:77)
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.IgniteException: Duplicate index name
[cache=SQL_PUBLIC_T2, schemaName=PUBLIC, idxName=IDX, existingTable=T, table=T2]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1650)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:803)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:866)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2595)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1400(GridCacheProcessor.java:204)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5481)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:947)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1922)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1050)
... 18 more
{code}
It looks like the second index (on T2) is partially created after all.
Need to either block index creation by `CREATE INDEX IF NOT EXISTS` completely,
or just fail that query when the table names don't match (if SQL spec allows
it).
was:
Given two tables in the same schema, we can't create an index with the same
name for both tables. In other words, the following code leads to an error -
which is good
{code}
CREATE INDEX IDX on T1 (COL);
CREATE INDEX IDX on T2 (COL);
{code}
If used with `IF NOT EXISTS`, the queries pass. It might be OK or not - one
needs to look into SQL spec to check if the second operation should be a no-op
(because IDX exists) or fail (because IDX exists for a different table, so the
caller is probably doing something wrong)
{code}
CREATE INDEX IDX on T1 (COL);
CREATE INDEX IF NOT EXISTS IDX on T2 (COL);
{code}
However,
[jira] [Created] (IGNITE-10516) Storage is corrupted after CREATE INDEX IF NOT EXISTS on different tables
Stanislav Lukyanov created IGNITE-10516:
---
Summary: Storage is corrupted after CREATE INDEX IF NOT EXISTS on
different tables
Key: IGNITE-10516
URL: https://issues.apache.org/jira/browse/IGNITE-10516
Project: Ignite
Issue Type: Bug
Reporter: Stanislav Lukyanov
Given two tables in the same schema, we can't create an index with the same
name for both tables. In other words, the following code leads to an error -
which is good
{code}
CREATE INDEX IDX on T1 (COL);
CREATE INDEX IDX on T2 (COL);
{code}
If used with `IF NOT EXISTS`, the queries pass. It might be OK or not - one
needs to look into SQL spec to check if the second operation should be a no-op
(because IDX exists) or fail (because IDX exists for a different table, so the
caller is probably doing something wrong)
{code}
CREATE INDEX IDX on T1 (COL);
CREATE INDEX IF NOT EXISTS IDX on T2 (COL);
{code}
However, if persistence is enabled, the node will fail to restart complaining
about duplicate index names.
{code}
class org.apache.ignite.IgniteCheckedException: Duplicate index name
[cache=SQL_PUBLIC_T2, schemaName=PUBLIC, idxName=IDX, existingTable=T, table=T2]
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1183)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:959)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:900)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:888)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:854)
at
org.apache.ignite.IndexWithSameNameTest.test(IndexWithSameNameTest.java:77)
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.IgniteException: Duplicate index name
[cache=SQL_PUBLIC_T2, schemaName=PUBLIC, idxName=IDX, existingTable=T, table=T2]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1650)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:803)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:866)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2595)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1400(GridCacheProcessor.java:204)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5481)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:947)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1922)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1050)
... 18 more
{code}
It looks like the second index (on T2) is partially created after all.
Need to either block index creation by `CREATE INDEX IF NOT EXISTS` completely,
or just fail that query when the table names don't match (if SQL spec allows
it).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10135) Documentation link to ClusterNodeAttributeAffinityBackupFilter
[ https://issues.apache.org/jira/browse/IGNITE-10135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg reassigned IGNITE-10135: Assignee: Denis Magda (was: Prachi Garg) > Documentation link to ClusterNodeAttributeAffinityBackupFilter > -- > > Key: IGNITE-10135 > URL: https://issues.apache.org/jira/browse/IGNITE-10135 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: David Harvey >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > > IGNITE-9365 adds ClusterNodeAttributeAffinityBackupFilter to allow > "Crash-safe Affinity" > ([https://apacheignite.readme.io/docs/affinity-collocation|https://apacheignite.readme.io/docs/affinity-collocation_]) > to be configured from spring. > The class should have an adequate description of how to set this up, but the > above section should link to or otherwise flag that such a procedure exist. > [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeAffinityBackupFilter.java] > > Note: the implementation is generic, allowing any node attribute (or > environment variable) to be configured so that primary and backup's are > always forced to not be on the same node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10135) Documentation link to ClusterNodeAttributeAffinityBackupFilter
[ https://issues.apache.org/jira/browse/IGNITE-10135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707711#comment-16707711 ] Prachi Garg commented on IGNITE-10135: -- [~dma...@apache.org], please review the 3rd paragraph in the in "Crash-safe Affinity" callout - [https://apacheignite.readme.io/v2.6/docs/affinity-collocation-27#section-affinity-function|https://apacheignite.readme.io/v2.6/docs/affinity-collocation-27#section-affinity-function.] > Documentation link to ClusterNodeAttributeAffinityBackupFilter > -- > > Key: IGNITE-10135 > URL: https://issues.apache.org/jira/browse/IGNITE-10135 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: David Harvey >Assignee: Prachi Garg >Priority: Major > Fix For: 2.7 > > > IGNITE-9365 adds ClusterNodeAttributeAffinityBackupFilter to allow > "Crash-safe Affinity" > ([https://apacheignite.readme.io/docs/affinity-collocation|https://apacheignite.readme.io/docs/affinity-collocation_]) > to be configured from spring. > The class should have an adequate description of how to set this up, but the > above section should link to or otherwise flag that such a procedure exist. > [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeAffinityBackupFilter.java] > > Note: the implementation is generic, allowing any node attribute (or > environment variable) to be configured so that primary and backup's are > always forced to not be on the same node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10242) NPE in GridDhtPartitionDemander#handleSupplyMessage when concurrently rebalancing and stopping cache in same cache group.
[
https://issues.apache.org/jira/browse/IGNITE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707708#comment-16707708
]
Ignite TC Bot commented on IGNITE-10242:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Hibernate 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2454389]]
* HibernateL2CacheTransactionalSelfTest.testRegionClear (last started)
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2453385buildTypeId=IgniteTests24Java8_RunAll]
> NPE in GridDhtPartitionDemander#handleSupplyMessage when concurrently
> rebalancing and stopping cache in same cache group.
> -
>
> Key: IGNITE-10242
> URL: https://issues.apache.org/jira/browse/IGNITE-10242
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5, 2.6
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.8
>
> Attachments: IgniteDemanderOnStoppingCacheTest.java
>
>
> NPE in GridDhtPartitionDemander#handleSupplyMessage occurs when concurrently
> rebalancing and stopping cache in same cache group. Reproducer is attached
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.preloadEntry(GridDhtPartitionDemander.java:893)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:772)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:331)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:411)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:401)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:583)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:101)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10380) [ML] Drop Multi-label Classification for Logistic Regression and SVM
[ https://issues.apache.org/jira/browse/IGNITE-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707691#comment-16707691 ] ASF GitHub Bot commented on IGNITE-10380: - GitHub user zaleslaw opened a pull request: https://github.com/apache/ignite/pull/5559 IGNITE-10380: Drop Multi-label Classification for LogReg and SVM You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10380 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5559.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 #5559 commit 668caf5d25a1ba74828cdeb7085022472429aaac Author: Zinoviev Alexey Date: 2018-11-29T13:10:19Z IGNITE-10380: Drop Multi-label Classification for Logistic Regression and SVM > [ML] Drop Multi-label Classification for Logistic Regression and SVM > > > Key: IGNITE-10380 > URL: https://issues.apache.org/jira/browse/IGNITE-10380 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.8 > > > After One-vs-Rest implementation these separate algorithms could be dropped > both. > Also, rename BinaryClassification LogReg -> LogReg > BinarySVM -> SVM > NOTE: Appropriate Docs should be dropped in release 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10510) [ML] Use OneVsRest for SVMLinearMultiClassClassificationTrainer
[ https://issues.apache.org/jira/browse/IGNITE-10510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev resolved IGNITE-10510. --- Resolution: Duplicate > [ML] Use OneVsRest for SVMLinearMultiClassClassificationTrainer > --- > > Key: IGNITE-10510 > URL: https://issues.apache.org/jira/browse/IGNITE-10510 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10510) [ML] Use OneVsRest for SVMLinearMultiClassClassificationTrainer
[ https://issues.apache.org/jira/browse/IGNITE-10510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev reassigned IGNITE-10510: - Assignee: Aleksey Zinoviev (was: Alexey Platonov) > [ML] Use OneVsRest for SVMLinearMultiClassClassificationTrainer > --- > > Key: IGNITE-10510 > URL: https://issues.apache.org/jira/browse/IGNITE-10510 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10515) In JDBC thick driver streaming mode, INSERTs ignored silently when trying to insert into wrong table
Ilya Kasnacheev created IGNITE-10515: Summary: In JDBC thick driver streaming mode, INSERTs ignored silently when trying to insert into wrong table Key: IGNITE-10515 URL: https://issues.apache.org/jira/browse/IGNITE-10515 Project: Ignite Issue Type: Bug Components: jdbc Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev Attachments: JdbcStreamingSelfTest.java It is not uncommon to do all your SQL from cache=default JDBC url and forget about that. But, if you try to use streaming=true with that, your INSERTs will be ignored when the destination cache is different. There should be some kind of error message if you try to stream to a different cache than the one you are connected to. Please see reproducer in maillist or the attached test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10410) MVCC: Create "Cache 7" test suite for MVCC mode.
[ https://issues.apache.org/jira/browse/IGNITE-10410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707640#comment-16707640 ] Andrew Mashenkov commented on IGNITE-10410: --- [~rkondakov], PR looks good, can be merged. Please, mute tests on TC properly to avoid failures on master after merge. > MVCC: Create "Cache 7" test suite for MVCC mode. > > > Key: IGNITE-10410 > URL: https://issues.apache.org/jira/browse/IGNITE-10410 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Roman Kondakov >Assignee: Roman Kondakov >Priority: Major > > Create MVCC version of IgniteCacheTestSuite7 and add it to TC. > All non-relevant tests should be marked as ignored. > Failed tests should be muted and tickets should be created for unknown > failure reasons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10049) MVCC: Create "Cache 4" test suite for MVCC mode.
[ https://issues.apache.org/jira/browse/IGNITE-10049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707615#comment-16707615 ] Andrew Mashenkov commented on IGNITE-10049: --- Let's remove next tests from ignore, mute failed tests related to known issues and then rerun related TC suites. IgniteCacheReadFromBackupTest IgniteCacheSingleGetMessageTest Please, take a look to a known issues related to these tests: IGNITE-10274 IGNITE-7371 > MVCC: Create "Cache 4" test suite for MVCC mode. > > > Key: IGNITE-10049 > URL: https://issues.apache.org/jira/browse/IGNITE-10049 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Roman Kondakov >Priority: Major > > Create MVCC version of IgniteCacheTestSuite4 and add it to TC. > All non-relevant tests should be marked as ignored. > Failed tests should be muted and tickets should be created for unknown > failure reasons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10457) MVCC TX: GridIndexRebuildWithMvccEnabledSelfTest fails
[
https://issues.apache.org/jira/browse/IGNITE-10457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707608#comment-16707608
]
Ignite TC Bot commented on IGNITE-10457:
{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=2431175buildTypeId=IgniteTests24Java8_RunAll]
> MVCC TX: GridIndexRebuildWithMvccEnabledSelfTest fails
> --
>
> Key: IGNITE-10457
> URL: https://issues.apache.org/jira/browse/IGNITE-10457
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.8
>
>
> See the log below:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Runtime failure on bounds: [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow
> []]
> 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.query.h2.GridIndexRebuildSelfTest.putData(GridIndexRebuildSelfTest.java:191)
> at
> org.apache.ignite.internal.processors.query.h2.GridIndexRebuildWithMvccEnabledSelfTest.testIndexRebuild(GridIndexRebuildWithMvccEnabledSelfTest.java:76)
> 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.IgniteCheckedException: Runtime failure on
> bounds: [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1061)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1968)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccUpdate(GridCacheOffheapManager.java:2032)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:543)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1142)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.continueLoop(GridDhtTxAbstractEnlistFuture.java:463)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:363)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.enlistLocal(GridNearTxEnlistFuture.java:525)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.sendBatch(GridNearTxEnlistFuture.java:420)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.sendNextBatches(GridNearTxEnlistFuture.java:167)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.map(GridNearTxEnlistFuture.java:143)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture.mapOnTopology(GridNearTxAbstractEnlistFuture.java:331)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture.init(GridNearTxAbstractEnlistFuture.java:246)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.updateAsync(GridNearTxLocal.java:2076)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.mvccPutAllAsync0(GridNearTxLocal.java:785)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:580)
> at
>
[jira] [Commented] (IGNITE-10514) Cache validation on the primary node may result in AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-10514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707596#comment-16707596
]
ASF GitHub Bot commented on IGNITE-10514:
-
GitHub user sk0x50 opened a pull request:
https://github.com/apache/ignite/pull/5558
IGNITE-10514: Cache validation on the primary node may result in
AssertionError
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10514
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5558.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 #5558
commit c15dac80bdad2e7001b74897ba87093203eb5047
Author: Slava Koptilin
Date: 2018-12-03T17:50:42Z
IGNITE-10514 Cache validation has to use top ver from the update request in
case of topology version was locked on near node
commit 0a2a63962907e38ff13b38bb383a1aaa0e92e591
Author: Slava Koptilin
Date: 2018-12-03T17:58:03Z
IGNITE-10514 fixed race between GridDhtTopologyFuture.exchangeDone() and
GridDhtTopologyFuture.validateCache()
> Cache validation on the primary node may result in AssertionError
> -
>
> Key: IGNITE-10514
> URL: https://issues.apache.org/jira/browse/IGNITE-10514
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
>
> Cache validation on the primary node, that was introduced by IGNITE-10413,
> may lead to the following AssertionError.
> {code:java}
> java.lang.AssertionError: GridDhtPartitionsExchangeFuture
> [firstDiscoEvt=DiscoveryCustomEvent [customMsg=CacheAffinityChangeMessage
> [...]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1788)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3184)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:138)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1059)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:383)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:299)
> 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)
> {code}
> Let's consider the following scenario:
> * Start one node and upload data.
> * Start a new node (note that this step triggers rebalancing).
> * Start explicit transaction and try to update atomic cache (it is assumed
> that atomic operation are allowed for use inside transactions, see Ignite
> system property DFLT_ALLOW_ATOMIC_OPS_IN_TX)
> {code:java}
> IgniteTransactions txs = ignite.transactions();
> try (Transaction tx = txs.txStart()) {
> atomicCache.put();
> tx.commit();
> }
> {code}
> Let's assume that the transaction mapped on the topology version that is
>
[jira] [Updated] (IGNITE-10514) Cache validation on the primary node may result in AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-10514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-10514:
-
Description:
Cache validation on the primary node, that was introduced by IGNITE-10413, may
lead to the following AssertionError.
{code:java}
java.lang.AssertionError: GridDhtPartitionsExchangeFuture
[firstDiscoEvt=DiscoveryCustomEvent [customMsg=CacheAffinityChangeMessage [...]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1788)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3184)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:138)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1059)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:383)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:309)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:299)
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)
{code}
Let's consider the following scenario:
* Start one node and upload data.
* Start a new node (note that this step triggers rebalancing).
* Start explicit transaction and try to update atomic cache (it is assumed
that atomic operation are allowed for use inside transactions, see Ignite
system property DFLT_ALLOW_ATOMIC_OPS_IN_TX)
{code:java}
IgniteTransactions txs = ignite.transactions();
try (Transaction tx = txs.txStart()) {
atomicCache.put();
tx.commit();
}
{code}
Let's assume that the transaction mapped on the topology version that is
related to {{NODE_JOIN}} event,
on the other hand, the corresponding request
{{GridNearAtomicAbstractUpdateRequest}} can be validated on the primary node
using the next top version, triggered by {{CacheAffinityMessage}}.
{code:title=GridDhtAtomicCache.java}
private void updateAllAsyncInternal0() {
...
if (validateCache) {
GridDhtTopologyFuture topFut = top.topologyVersionFuture();
// There is a chance that the topFut is not done yet!
assert topFut.isDone() : topFut;
Throwable err = topFut.validateCache(ctx, req.recovery(), false, null,
null);
...
}
}{code}
That is the root cause of the {{AssertionError}} mentioned above.
was:
Cache validation on the primary node, that was introduced by IGNITE-10413, may
lead to the following AssertionError.
{code:java}
java.lang.AssertionError: GridDhtPartitionsExchangeFuture
[firstDiscoEvt=DiscoveryCustomEvent [customMsg=CacheAffinityChangeMessage [...]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1788)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3184)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:138)
at
[jira] [Updated] (IGNITE-10514) Cache validation on the primary node may result in AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-10514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-10514:
-
Description:
Cache validation on the primary node, that was introduced by IGNITE-10413, may
lead to the following AssertionError.
{code:java}
java.lang.AssertionError: GridDhtPartitionsExchangeFuture
[firstDiscoEvt=DiscoveryCustomEvent [customMsg=CacheAffinityChangeMessage [...]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1788)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3184)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:138)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1059)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:383)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:309)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:299)
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)
{code}
Let's consider the following scenario:
* Start one node and upload data.
* Start a new node (note that this step triggers rebalancing).
* Start explicit transaction and try to update atomic cache (it is assumed
that atomic operation are allowed for use inside transactions, see Ignite
system property DFLT_ALLOW_ATOMIC_OPS_IN_TX)
{code:java}
IgniteTransactions txs = ignite.transactions();
try (Transaction tx = txs.txStart()) {
atomicCache.put();
tx.commit();
}
{code}
Let's assume that the transaction mapped on the topology version that is
related to {{NODE_JOIN}} event,
on the other hand, the corresponding request
{{GridNearAtomicAbstractUpdateRequest}} can be validated on the primary node
using the next top version, triggered by {{CacheAffinityMessage}}.
{code:java}
if (validateCache) {
GridDhtTopologyFuture topFut = top.topologyVersionFuture();
// There is a chance that the topFut is not done yet!
assert topFut.isDone() : topFut;
Throwable err = topFut.validateCache(ctx, req.recovery(), false, null,
null);
...
}{code}
That is the root cause of the {{AssertionError}} mentioned above.
was:
Cache validation on the primary node, that was introduced by IGNITE-10413, may
lead to the following AssertionError.
{code:java}
java.lang.AssertionError: GridDhtPartitionsExchangeFuture
[firstDiscoEvt=DiscoveryCustomEvent [customMsg=CacheAffinityChangeMessage [...]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1788)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3184)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:138)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
at
[jira] [Updated] (IGNITE-10514) Cache validation on the primary node may result in AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-10514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-10514:
-
Description:
Cache validation on the primary node, that was introduced by IGNITE-10413, may
lead to the following AssertionError.
{code:java}
java.lang.AssertionError: GridDhtPartitionsExchangeFuture
[firstDiscoEvt=DiscoveryCustomEvent [customMsg=CacheAffinityChangeMessage [...]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1788)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3184)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:138)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1059)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:383)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:309)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:299)
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)
{code}
Let's consider the following scenario:
* Start one node and upload data.
* Start a new node (note that this step triggers rebalancing).
* Start explicit transaction and try to update atomic cache (it is assumed
that atomic operation are allowed for use inside transactions, see Ignite
system property DFLT_ALLOW_ATOMIC_OPS_IN_TX)
{code:java}
IgniteTransactions txs = ignite.transactions();
try (Transaction tx = txs.txStart()) {
atomicCache.put();
tx.commit();
}
{code}
Let's assume that the transaction mapped on the topology version that is
related to {{NODE_JOIN}} event,
on the other hand, the corresponding request
{{GridNearAtomicAbstractUpdateRequest}} can be validated on the primary node
using the next topology version, triggered by {{CacheAffinityMessage}}.
{code:java|title=GridDhtAtomicCache.java}
private void updateAllAsyncInternal0() {
...
if (validateCache) {
GridDhtTopologyFuture topFut = top.topologyVersionFuture();
// There is a chance that the topFut is not done yet!
assert topFut.isDone() : topFut;
Throwable err = topFut.validateCache(ctx, req.recovery(), false, null,
null);
...
}
}{code}
That is the root cause of the {{AssertionError}} mentioned above.
was:
Cache validation on the primary node, that was introduced by IGNITE-10413, may
lead to the following AssertionError.
{code:java}
java.lang.AssertionError: GridDhtPartitionsExchangeFuture
[firstDiscoEvt=DiscoveryCustomEvent [customMsg=CacheAffinityChangeMessage [...]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1788)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3184)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:138)
at
[jira] [Updated] (IGNITE-10514) Cache validation on the primary node may result in AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-10514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-10514:
-
Ignite Flags: (was: Docs Required)
> Cache validation on the primary node may result in AssertionError
> -
>
> Key: IGNITE-10514
> URL: https://issues.apache.org/jira/browse/IGNITE-10514
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
>
> Cache validation on the primary node, that was introduced by IGNITE-10413,
> may lead to the following AssertionError.
> {code:java}
> java.lang.AssertionError: GridDhtPartitionsExchangeFuture
> [firstDiscoEvt=DiscoveryCustomEvent [customMsg=CacheAffinityChangeMessage
> [...]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1788)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3184)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:138)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1059)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:383)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:299)
> 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)
> {code}
> Let's consider the following scenario:
> * Start one node and upload data.
> * Start a new node (note that this step triggers rebalancing).
> * Start explicit transaction and try to update atomic cache (it is assumed
> that atomic operation are allowed for use inside transactions, see Ignite
> system property DFLT_ALLOW_ATOMIC_OPS_IN_TX)
> {code:java}
> IgniteTransactions txs = ignite.transactions();
> try (Transaction tx = txs.txStart()) {
> atomicCache.put();
> tx.commit();
> }
> {code}
> Let's assume that the transaction mapped on the topology version that is
> related to {{NODE_JOIN}} event,
> on the other hand, the corresponding request
> {{GridNearAtomicAbstractUpdateRequest}} can be validated on the primary node
> using the next top version, triggered by {{CacheAffinityMessage}}.
> {code:title=GridDhtAtomicCache.java}
> private void updateAllAsyncInternal0() {
> ...
> if (validateCache) {
> GridDhtTopologyFuture topFut = top.topologyVersionFuture();
> // There is a chance that the topFut is not done yet!
> assert topFut.isDone() : topFut;
> Throwable err = topFut.validateCache(ctx, req.recovery(), false,
> null, null);
> ...
> }
> }{code}
> That is the root cause of the {{AssertionError}} mentioned above.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10514) Cache validation on the primary node may result in AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-10514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-10514:
-
Component/s: cache
> Cache validation on the primary node may result in AssertionError
> -
>
> Key: IGNITE-10514
> URL: https://issues.apache.org/jira/browse/IGNITE-10514
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
>
> Cache validation on the primary node, that was introduced by IGNITE-10413,
> may lead to the following AssertionError.
> {code:java}
> java.lang.AssertionError: GridDhtPartitionsExchangeFuture
> [firstDiscoEvt=DiscoveryCustomEvent [customMsg=CacheAffinityChangeMessage
> [...]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1788)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3184)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:138)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1059)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:383)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:299)
> 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)
> {code}
> Let's consider the following scenario:
> * Start one node and upload data.
> * Start a new node (note that this step triggers rebalancing).
> * Start explicit transaction and try to update atomic cache (it is assumed
> that atomic operation are allowed for use inside transactions, see Ignite
> system property DFLT_ALLOW_ATOMIC_OPS_IN_TX)
> {code:java}
> IgniteTransactions txs = ignite.transactions();
> try (Transaction tx = txs.txStart()) {
> atomicCache.put();
> tx.commit();
> }
> {code}
> Let's assume that the transaction mapped on the topology version that is
> related to {{NODE_JOIN}} event,
> on the other hand, the corresponding request
> {{GridNearAtomicAbstractUpdateRequest}} can be validated on the primary node
> using the next top version, triggered by {{CacheAffinityMessage}}.
> {code:title=GridDhtAtomicCache.java}
> private void updateAllAsyncInternal0() {
> ...
> if (validateCache) {
> GridDhtTopologyFuture topFut = top.topologyVersionFuture();
> // There is a chance that the topFut is not done yet!
> assert topFut.isDone() : topFut;
> Throwable err = topFut.validateCache(ctx, req.recovery(), false,
> null, null);
> ...
> }
> }{code}
> That is the root cause of the {{AssertionError}} mentioned above.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10376) Failed to touch in CacheOffheapEvictionManager
[
https://issues.apache.org/jira/browse/IGNITE-10376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Fedotov updated IGNITE-10376:
--
Affects Version/s: (was: 2.7)
> Failed to touch in CacheOffheapEvictionManager
> --
>
> Key: IGNITE-10376
> URL: https://issues.apache.org/jira/browse/IGNITE-10376
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Blocker
> Labels: MakeTeamcityGreenAgain, stability, test-fail
> Fix For: 2.8
>
> Attachments: IGNITE-10376 log.txt
>
>
> BinaryObjectException exception sometimes appears in
> [testAtomicOnheapTwoBackupAsyncFullSync|https://ci.ignite.apache.org/viewLog.html?buildId=2398013=buildResultsDiv=IgniteTests24Java8_ContinuousQuery4#testNameId3300126853696550025]
> at the
> [moment|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/query/continuous/CacheContinuousQueryOrderingEventTest.java#L371]
> of CacheEntryProcessor invocation.
> {code}class org.apache.ignite.binary.BinaryObjectException: Failed to update
> meta data for type:
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryOrderingEventTest$QueryTestValue
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:516)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.addMeta(CacheObjectBinaryProcessorImpl.java:194)
> at
> org.apache.ignite.internal.binary.BinaryContext.updateMetadata(BinaryContext.java:1332)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1815)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1150)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke0(GridDhtAtomicCache.java:831)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke(GridDhtAtomicCache.java:787)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1438)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1482)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1228)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryOrderingEventTest$1.run(CacheContinuousQueryOrderingEventTest.java:373)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1300)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84){code}
> It can be because of absence of locks in
> GridCacheMapEntry#touch(GridCacheMapEntry.java:5063).
> It seems that test does not work after integration MVCC in Continuous Query.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10514) Cache validation on the primary node may result in AssertionError
Vyacheslav Koptilin created IGNITE-10514:
Summary: Cache validation on the primary node may result in
AssertionError
Key: IGNITE-10514
URL: https://issues.apache.org/jira/browse/IGNITE-10514
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
Fix For: 2.8
Cache validation on the primary node, that was introduced by IGNITE-10413, may
lead to the following AssertionError.
{code:java}
java.lang.AssertionError: GridDhtPartitionsExchangeFuture
[firstDiscoEvt=DiscoveryCustomEvent [customMsg=CacheAffinityChangeMessage [...]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1788)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3184)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:138)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1059)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:383)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:309)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:299)
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)
{code}
Let's consider the following scenario:
* Start one node and upload data.
* Start a new node (note that this step triggers rebalancing).
* Start explicit transaction and try to update atomic cache (it is assumed
that atomic operation are allowed for use inside transactions, see Ignite
system property DFLT_ALLOW_ATOMIC_OPS_IN_TX)
{code:java}
IgniteTransactions txs = ignite.transactions();
try (Transaction tx = txs.txStart()) {
atomicCache.put();
tx.commit();
}
{code}
Let's assume that the transaction mapped on the topology version that is
related to {{NODE_JOIN}} event,
on the other hand, the corresponding request
{{GridNearAtomicAbstractUpdateRequest}} can be validated on the primary node
using the next top version, triggered by \{{CacheAffinityMessage}}.
That is the root cause of the {{AssertionError}} mentioned above.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10376) Failed to touch in CacheOffheapEvictionManager
[
https://issues.apache.org/jira/browse/IGNITE-10376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Fedotov updated IGNITE-10376:
--
Priority: Major (was: Blocker)
> Failed to touch in CacheOffheapEvictionManager
> --
>
> Key: IGNITE-10376
> URL: https://issues.apache.org/jira/browse/IGNITE-10376
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, stability, test-fail
> Fix For: 2.8
>
> Attachments: IGNITE-10376 log.txt
>
>
> BinaryObjectException exception sometimes appears in
> [testAtomicOnheapTwoBackupAsyncFullSync|https://ci.ignite.apache.org/viewLog.html?buildId=2398013=buildResultsDiv=IgniteTests24Java8_ContinuousQuery4#testNameId3300126853696550025]
> at the
> [moment|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/query/continuous/CacheContinuousQueryOrderingEventTest.java#L371]
> of CacheEntryProcessor invocation.
> {code}class org.apache.ignite.binary.BinaryObjectException: Failed to update
> meta data for type:
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryOrderingEventTest$QueryTestValue
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:516)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.addMeta(CacheObjectBinaryProcessorImpl.java:194)
> at
> org.apache.ignite.internal.binary.BinaryContext.updateMetadata(BinaryContext.java:1332)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1815)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1150)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke0(GridDhtAtomicCache.java:831)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke(GridDhtAtomicCache.java:787)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1438)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1482)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1228)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryOrderingEventTest$1.run(CacheContinuousQueryOrderingEventTest.java:373)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1300)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84){code}
> It can be because of absence of locks in
> GridCacheMapEntry#touch(GridCacheMapEntry.java:5063).
> It seems that test does not work after integration MVCC in Continuous Query.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10376) Failed to touch in CacheOffheapEvictionManager
[
https://issues.apache.org/jira/browse/IGNITE-10376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Fedotov updated IGNITE-10376:
--
Fix Version/s: 2.8
> Failed to touch in CacheOffheapEvictionManager
> --
>
> Key: IGNITE-10376
> URL: https://issues.apache.org/jira/browse/IGNITE-10376
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Blocker
> Labels: MakeTeamcityGreenAgain, stability, test-fail
> Fix For: 2.8
>
> Attachments: IGNITE-10376 log.txt
>
>
> BinaryObjectException exception sometimes appears in
> [testAtomicOnheapTwoBackupAsyncFullSync|https://ci.ignite.apache.org/viewLog.html?buildId=2398013=buildResultsDiv=IgniteTests24Java8_ContinuousQuery4#testNameId3300126853696550025]
> at the
> [moment|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/query/continuous/CacheContinuousQueryOrderingEventTest.java#L371]
> of CacheEntryProcessor invocation.
> {code}class org.apache.ignite.binary.BinaryObjectException: Failed to update
> meta data for type:
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryOrderingEventTest$QueryTestValue
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:516)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.addMeta(CacheObjectBinaryProcessorImpl.java:194)
> at
> org.apache.ignite.internal.binary.BinaryContext.updateMetadata(BinaryContext.java:1332)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1815)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1150)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke0(GridDhtAtomicCache.java:831)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke(GridDhtAtomicCache.java:787)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1438)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1482)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1228)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryOrderingEventTest$1.run(CacheContinuousQueryOrderingEventTest.java:373)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1300)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84){code}
> It can be because of absence of locks in
> GridCacheMapEntry#touch(GridCacheMapEntry.java:5063).
> It seems that test does not work after integration MVCC in Continuous Query.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10483) MVCC: Enlist request deserialization failure causes grid hanging.
[
https://issues.apache.org/jira/browse/IGNITE-10483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707551#comment-16707551
]
Andrew Mashenkov commented on IGNITE-10483:
---
We have to merge IGNITE-10366 at first, and then verify test are fixed with
this patch.
> MVCC: Enlist request deserialization failure causes grid hanging.
> -
>
> Key: IGNITE-10483
> URL: https://issues.apache.org/jira/browse/IGNITE-10483
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.8
>
>
> Looks like remote serialization issues are not propagated back to near node
> and user request hangs forever.
> We should add error handling for all mvcc Enlist requests into
> GridCacheIoManager
>
> {noformat}
> [19:11:49]W: [org.apache.ignite:ignite-core] class
> org.apache.ignite.IgniteCheckedException: Failed to send response to node.
> Unsupported direct type [message=GridNearTxEnlistRequest [threadId
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:1048)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:582)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:383)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:309)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:299)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1568)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1196)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1092)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [19:11:49]W: [org.apache.ignite:ignite-core] Caused by: class
> org.apache.ignite.IgniteCheckedException: Failed to unmarshal object with
> optimized marshaller
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9997)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10049)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridInvokeValue.finishUnmarshal(GridInvokeValue.java:108)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistRequest.finishUnmarshal(GridNearTxEnlistRequest.java:359)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1538)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> [19:11:49]W: [org.apache.ignite:ignite-core] ... 11 more
> [19:11:49]W: [org.apache.ignite:ignite-core] Caused by: class
> org.apache.ignite.binary.BinaryObjectException: Failed to unmarshal object
> with optimized marshaller
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1789)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1964)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
>
[jira] [Commented] (IGNITE-10417) notifyDiscoveryListener() call can be lost
[ https://issues.apache.org/jira/browse/IGNITE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707516#comment-16707516 ] Denis Mekhanikov commented on IGNITE-10417: --- Pavel, I posted some comments on GitHub. Please address. > notifyDiscoveryListener() call can be lost > -- > > Key: IGNITE-10417 > URL: https://issues.apache.org/jira/browse/IGNITE-10417 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > > 1) ServerImpl:5455 notifyDiscoveryListener can not be called in case of > spiState != CONNECTED, for example DISCONNECTING which is valid state > nevetheless inside notifyDiscoveryListener we check spiState == CONNECTED || > spiState == DISCONNECTING, also we need to improve logging in > notifyDiscoveryListener(). > 2) Improve logging on duplicated custom discovery event. > 3) Add assert if msg.creatorNodeId() doesn't exist in topology this is bad > behaviour taht should lead to node fail. > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10513) Java client stucks when connects to server with slow disk
[
https://issues.apache.org/jira/browse/IGNITE-10513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707509#comment-16707509
]
ASF GitHub Bot commented on IGNITE-10513:
-
GitHub user laz2 opened a pull request:
https://github.com/apache/ignite/pull/5557
IGNITE-10513 Fix NullPointerException on reconnect
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/laz2/ignite ignite-10513
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5557.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 #5557
commit 6d59979f40fc5307b229708d740768e39f996b1b
Author: Dmitry Lazurkin
Date: 2018-12-03T16:46:10Z
IGNITE-10513 Fix NullPointerException on reconnect
> Java client stucks when connects to server with slow disk
> -
>
> Key: IGNITE-10513
> URL: https://issues.apache.org/jira/browse/IGNITE-10513
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.6
>Reporter: Dmitry Lazurkin
>Priority: Major
> Attachments: ignite-client.log
>
>
> For emulating slow disk add _sleep_ to partitions cycle in
> _GridCacheDatabaseSharedManager#restorePartitionStates_:
> {noformat}
> //...
> for (int i = 0; i < grp.affinity().partitions(); i++) {
> try {
> log.error("Wait");
> Thread.sleep(1);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> //...
> {noformat}
> My server has 1024 partitions.
> Steps to reproduce:
> * Start server
> * Start client
> * On client wait message "Join cluster while cluster state transition is in
> progress, waiting when transition finish."
> * Kill server
> * On client wait repeatable java.net.ConnectException: Connection refused
> (Connection refused)
> * Start server (I have 100% chance to reproduce issue on my computer)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10513) Java client stucks when connects to server with slow disk
Dmitry Lazurkin created IGNITE-10513:
Summary: Java client stucks when connects to server with slow disk
Key: IGNITE-10513
URL: https://issues.apache.org/jira/browse/IGNITE-10513
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.6
Reporter: Dmitry Lazurkin
Attachments: ignite-client.log
For emulating slow disk add _sleep_ to partitions cycle in
_GridCacheDatabaseSharedManager#restorePartitionStates_:
{noformat}
//...
for (int i = 0; i < grp.affinity().partitions(); i++) {
try {
log.error("Wait");
Thread.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
//...
{noformat}
My server has 1024 partitions.
Steps to reproduce:
* Start server
* Start client
* On client wait message "Join cluster while cluster state transition is in
progress, waiting when transition finish."
* Kill server
* On client wait repeatable java.net.ConnectException: Connection refused
(Connection refused)
* Start server (I have 100% chance to reproduce issue on my computer)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10422) Make {{ignite_inspection.xml}} configuration default on the project level
[
https://issues.apache.org/jira/browse/IGNITE-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707500#comment-16707500
]
ASF GitHub Bot commented on IGNITE-10422:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5540
> Make {{ignite_inspection.xml}} configuration default on the project level
> -
>
> Key: IGNITE-10422
> URL: https://issues.apache.org/jira/browse/IGNITE-10422
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
>
> IntelliJ IDEA can perform static code analysis by applying _inspections_ to
> the project code. The inspection analysis process can be easily run from both
> the IDE and the command line. The command line usage of IntelliJ IDEA
> inspections already configured as daily [Inspections(Core)
> TeamCity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv]
> suite. This approach has proven its convenience and efficiency as part of
> the _TC.Bot_.
> As for the next step, I propose to improve personal productivity of writing
> code by making *{{ignite_inspection.xml}}* configuration default on the
> project level.
> According to [IntelliJ IDEA
> documentation|https://www.jetbrains.com/help/idea/code-inspection.html], the
> inspection profile is recommended to be placed to
> *{{/.idea/inspectionProfiles}}* with name *{{Project_Default.xml}}*.
> This project profile will be shared and accessible for the team members via
> VCS by default.
> Note.
> The build and test procedure of Apache Ignite project will remain IDE
> independent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10422) Make {{ignite_inspection.xml}} configuration default on the project level
[
https://issues.apache.org/jira/browse/IGNITE-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-10422:
Fix Version/s: 2.8
> Make {{ignite_inspection.xml}} configuration default on the project level
> -
>
> Key: IGNITE-10422
> URL: https://issues.apache.org/jira/browse/IGNITE-10422
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
>
> IntelliJ IDEA can perform static code analysis by applying _inspections_ to
> the project code. The inspection analysis process can be easily run from both
> the IDE and the command line. The command line usage of IntelliJ IDEA
> inspections already configured as daily [Inspections(Core)
> TeamCity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv]
> suite. This approach has proven its convenience and efficiency as part of
> the _TC.Bot_.
> As for the next step, I propose to improve personal productivity of writing
> code by making *{{ignite_inspection.xml}}* configuration default on the
> project level.
> According to [IntelliJ IDEA
> documentation|https://www.jetbrains.com/help/idea/code-inspection.html], the
> inspection profile is recommended to be placed to
> *{{/.idea/inspectionProfiles}}* with name *{{Project_Default.xml}}*.
> This project profile will be shared and accessible for the team members via
> VCS by default.
> Note.
> The build and test procedure of Apache Ignite project will remain IDE
> independent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10355) Tx rollback failure on put operations with caches whose topology fails validation
[
https://issues.apache.org/jira/browse/IGNITE-10355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707486#comment-16707486
]
Ignite TC Bot commented on IGNITE-10355:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Queries{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2429612]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlTxQueriesTest.testQueryInsertMultithread - 0,0% fails in
last 100 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2429661buildTypeId=IgniteTests24Java8_RunAll]
> Tx rollback failure on put operations with caches whose topology fails
> validation
> -
>
> Key: IGNITE-10355
> URL: https://issues.apache.org/jira/browse/IGNITE-10355
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6, 2.7
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> The issue may occur as stacktrace below:
> {noformat}
> [2018-10-12 18:47:28,351][ERROR][test-runner-#1][GridDhtColocatedCache]
> Failed to rollback transaction (cache may contain stale locks):
> GridNearTxLocal[xid=95ce5f86661--08fd-9fc9--0002,
> xidVersion=GridCacheVersion [topVer=150839241, order=1539359239257,
> nodeOrder=2], concurrency=OPTIMISTIC, isolation=READ_COMMITTED,
> state=ROLLED_BACK, invalidate=false, rollbackOnly=true,
> nodeId=108e38a0-64e2-4da6-ab06-6db7e6ae9001, timeout=0, duration=0,
> label=null]
> class org.apache.ignite.IgniteCheckedException: Failed to rollback
> transaction:
> GridNearTxLocal[xid=95ce5f86661--08fd-9fc9--0002,
> xidVersion=GridCacheVersion [topVer=150839241, order=1539359239257,
> nodeOrder=2], concurrency=OPTIMISTIC, isolation=READ_COMMITTED,
> state=ROLLED_BACK, invalidate=false, rollbackOnly=true,
> nodeId=108e38a0-64e2-4da6-ab06-6db7e6ae9001, timeout=0, duration=0,
> label=null]
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:514)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$27.apply(GridNearTxLocal.java:3962)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$27.apply(GridNearTxLocal.java:3950)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.chainFinishFuture(GridNearTxLocal.java:3950)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3864)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3833)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$18.applyx(GridNearTxLocal.java:2966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$18.applyx(GridNearTxLocal.java:2948)
> at
> org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter$ChainFuture.(GridFutureAdapter.java:574)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.chain(GridFutureAdapter.java:360)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.optimisticPutFuture(GridNearTxLocal.java:2947)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:693)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync(GridNearTxLocal.java:447)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2470)
> at
>
[jira] [Comment Edited] (IGNITE-10422) Make {{ignite_inspection.xml}} configuration default on the project level
[
https://issues.apache.org/jira/browse/IGNITE-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706296#comment-16706296
]
Oleg Ignatenko edited comment on IGNITE-10422 at 12/3/18 4:31 PM:
--
[~Mmuzaf] thanks - I re-checked final version of your changes and it looks
perfect to me. [~dmitry.pavlov], I would appreciate if you take a look too.
was (Author: oignatenko):
[~Mmuzaf] thanks - I re-checked final version of your changes and it looks
perfect to me. [~dmitry.pavlov]], I would appreciate if you take a look too.
> Make {{ignite_inspection.xml}} configuration default on the project level
> -
>
> Key: IGNITE-10422
> URL: https://issues.apache.org/jira/browse/IGNITE-10422
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
>
> IntelliJ IDEA can perform static code analysis by applying _inspections_ to
> the project code. The inspection analysis process can be easily run from both
> the IDE and the command line. The command line usage of IntelliJ IDEA
> inspections already configured as daily [Inspections(Core)
> TeamCity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv]
> suite. This approach has proven its convenience and efficiency as part of
> the _TC.Bot_.
> As for the next step, I propose to improve personal productivity of writing
> code by making *{{ignite_inspection.xml}}* configuration default on the
> project level.
> According to [IntelliJ IDEA
> documentation|https://www.jetbrains.com/help/idea/code-inspection.html], the
> inspection profile is recommended to be placed to
> *{{/.idea/inspectionProfiles}}* with name *{{Project_Default.xml}}*.
> This project profile will be shared and accessible for the team members via
> VCS by default.
> Note.
> The build and test procedure of Apache Ignite project will remain IDE
> independent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10422) Make {{ignite_inspection.xml}} configuration default on the project level
[
https://issues.apache.org/jira/browse/IGNITE-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706296#comment-16706296
]
Oleg Ignatenko edited comment on IGNITE-10422 at 12/3/18 4:31 PM:
--
[~Mmuzaf] thanks - I re-checked final version of your changes and it looks
perfect to me. [~dmitry.pavlov]], I would appreciate if you take a look too.
was (Author: oignatenko):
[~Mmuzaf] thanks - I re-checked final version of your changes and it looks
perfect to me. [~dop], I would appreciate if you take a look too.
> Make {{ignite_inspection.xml}} configuration default on the project level
> -
>
> Key: IGNITE-10422
> URL: https://issues.apache.org/jira/browse/IGNITE-10422
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
>
> IntelliJ IDEA can perform static code analysis by applying _inspections_ to
> the project code. The inspection analysis process can be easily run from both
> the IDE and the command line. The command line usage of IntelliJ IDEA
> inspections already configured as daily [Inspections(Core)
> TeamCity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv]
> suite. This approach has proven its convenience and efficiency as part of
> the _TC.Bot_.
> As for the next step, I propose to improve personal productivity of writing
> code by making *{{ignite_inspection.xml}}* configuration default on the
> project level.
> According to [IntelliJ IDEA
> documentation|https://www.jetbrains.com/help/idea/code-inspection.html], the
> inspection profile is recommended to be placed to
> *{{/.idea/inspectionProfiles}}* with name *{{Project_Default.xml}}*.
> This project profile will be shared and accessible for the team members via
> VCS by default.
> Note.
> The build and test procedure of Apache Ignite project will remain IDE
> independent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9859) add debug logging on refreshPartitions cause
[ https://issues.apache.org/jira/browse/IGNITE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707482#comment-16707482 ] Dmitriy Pavlov commented on IGNITE-9859: [~mshonichev] friendly remainder. I doubt that unassigned issue can be in a filter of all committers. > add debug logging on refreshPartitions cause > > > Key: IGNITE-9859 > URL: https://issues.apache.org/jira/browse/IGNITE-9859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Major > Fix For: 2.8 > > Attachments: > IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch > > > Need some additional log messages for debugging PME issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10071) [TC Bot] Background upload of a build and simultaneous bot restart may result in a queued build persisted but actually build is finished
[ https://issues.apache.org/jira/browse/IGNITE-10071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707412#comment-16707412 ] ASF GitHub Bot commented on IGNITE-10071: - asfgit closed pull request #86: IGNITE-10071 Queued and running builds hang in the TC bot URL: https://github.com/apache/ignite-teamcity-bot/pull/86 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > [TC Bot] Background upload of a build and simultaneous bot restart may result > in a queued build persisted but actually build is finished > > > Key: IGNITE-10071 > URL: https://issues.apache.org/jira/browse/IGNITE-10071 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Critical > > TC bot new persistence based on continuous uploading builds from the TC > server may become outdated during bot server restart. > E.g. Run all which became completed in TC Bot's base may include > queued/running builds, which may lead to missed test failures (As running > build may not have these failures). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10386) Add mode when WAL won't be disabled during rebalancing caused by BLT change
[
https://issues.apache.org/jira/browse/IGNITE-10386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707438#comment-16707438
]
Ignite TC Bot commented on IGNITE-10386:
{panel:title=PDS 2: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *PDS 2*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2453487buildTypeId=IgniteTests24Java8_Pds2]
> Add mode when WAL won't be disabled during rebalancing caused by BLT change
> ---
>
> Key: IGNITE-10386
> URL: https://issues.apache.org/jira/browse/IGNITE-10386
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> Enabling IgniteSystemProperties#IGNITE_DISABLE_WAL_DURING_REBALANCING
> disables WAL for cache group during rebalancing in case local node has no
> OWNING partitions for this group.
> We should add mode when in specific case (after BaselineTopology change) WAL
> won't be disabled even if this property is switched on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10366) MVCC: Create "Cache 1" test suite for MVCC mode.
[
https://issues.apache.org/jira/browse/IGNITE-10366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707429#comment-16707429
]
Ignite TC Bot commented on IGNITE-10366:
{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=2450943buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Create "Cache 1" test suite for MVCC mode.
>
>
> Key: IGNITE-10366
> URL: https://issues.apache.org/jira/browse/IGNITE-10366
> Project: Ignite
> Issue Type: Sub-task
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
> Fix For: 2.8
>
>
> Create MVCC version of IgniteCacheTestSuite and add it to TC.
> All non-relevant tests should be marked as ignored.
> Failed tests should be muted and tickets should be created for unknown
> failure reasons.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-10436) [TC Bot] Add ticket and PR links on report TC Bot page
[ https://issues.apache.org/jira/browse/IGNITE-10436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-10436. - Resolution: Fixed [~PetrovMikhail] thank you for the contribution, I appreciate you've added clickable JIRA to main PRs table and you've started JIRA integration refactoring to be a separate guice module > [TC Bot] Add ticket and PR links on report TC Bot page > --- > > Key: IGNITE-10436 > URL: https://issues.apache.org/jira/browse/IGNITE-10436 > Project: Ignite > Issue Type: Task >Reporter: PetrovMikhail >Assignee: PetrovMikhail >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (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 reassigned IGNITE-10493:
Assignee: Pavel Kovalenko
> 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-9470) MVCC TX: Mvcc transactions should throw proper exception when rolled back.
[
https://issues.apache.org/jira/browse/IGNITE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-9470:
-
Description:
When MVCC transaction is rolled back due to a write conflict it throws
{{CacheException}} with "Mvcc version mismatch" message. This behavior violates
Ignite transactions API. Instead it should throw
{{TransactionRollbackException}} with a clear message like a "Transaction has
been aborted due to a write conflict (Please try again.)"
It is also need to propogate this changes to JDBC and ODBC components and fix
mvcc tests.
In some tests we have to repeat tx operation in case of version conflict. Most
likely, we can rely to caused-exception with some meaningful type (e.g.
MvccVersionMismatchException) to repeat operation.
was:
When MVCC transaction is rolled back due to a write conflict it throws
{{CacheException}} with "Mvcc version mismatch" message. This behavior violates
Ignite transactions API. Instead it should throw
{{TransactionRollbackException}} with a clear message like a "Transaction has
been aborted due to a write conflict (Please try again.)"
It is also need to propogate this changes to JDBC and ODBC components and fix
mvcc tests.
> MVCC TX: Mvcc transactions should throw proper exception when rolled back.
> --
>
> Key: IGNITE-9470
> URL: https://issues.apache.org/jira/browse/IGNITE-9470
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, mvcc, odbc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
>
> When MVCC transaction is rolled back due to a write conflict it throws
> {{CacheException}} with "Mvcc version mismatch" message. This behavior
> violates Ignite transactions API. Instead it should throw
> {{TransactionRollbackException}} with a clear message like a "Transaction has
> been aborted due to a write conflict (Please try again.)"
> It is also need to propogate this changes to JDBC and ODBC components and fix
> mvcc tests.
>
> In some tests we have to repeat tx operation in case of version conflict.
> Most likely, we can rely to caused-exception with some meaningful type (e.g.
> MvccVersionMismatchException) to repeat operation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10436) [TC Bot] Add ticket and PR links on report TC Bot page
[
https://issues.apache.org/jira/browse/IGNITE-10436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707410#comment-16707410
]
ASF GitHub Bot commented on IGNITE-10436:
-
asfgit closed pull request #85: IGNITE-10436 Add ticket and PR links on report
TC Bot page
URL: https://github.com/apache/ignite-teamcity-bot/pull/85
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/conf/apache.auth.properties b/conf/apache.auth.properties
index da84ef6c..a022bf70 100644
--- a/conf/apache.auth.properties
+++ b/conf/apache.auth.properties
@@ -5,6 +5,7 @@ logs=apache_logs
git.api_url=https://api.github.com/repos/apache/ignite/
jira.api_url=https://issues.apache.org/jira/rest/api/2/
+jira.url=https://issues.apache.org/jira/
#specify JIRA Auth token (if needed)
jira.auth_token=
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/HelperConfig.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/HelperConfig.java
index 0b6b0a84..a39d779f 100644
--- a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/HelperConfig.java
+++ b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/HelperConfig.java
@@ -60,6 +60,9 @@
/** JIRA authorization token property name. */
public static final String JIRA_API_URL = "jira.api_url";
+/** */
+public static final String JIRA_URL = "jira.url";
+
/** Slack authorization token property name. */
public static final String SLACK_AUTH_TOKEN = "slack.auth_token";
public static final String SLACK_CHANNEL = "slack.channel";
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
index 9832d2a5..eb66f302 100644
--- a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
+++ b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
@@ -53,7 +53,7 @@
* TC Bot implementation. To be migrated to smaller injected classes
*/
@Deprecated
-public class TcHelper implements ITcHelper, IJiraIntegration {
+public class TcHelper implements ITcHelper {
/** Logger. */
private static final Logger logger =
LoggerFactory.getLogger(TcHelper.class);
@@ -199,7 +199,7 @@ private BranchesTracked getTrackedBranches() {
return new Visa("JIRA wasn't commented - " + errMsg);
}
-return new Visa(JIRA_COMMENTED, res, blockers);
+return new Visa(IJiraIntegration.JIRA_COMMENTED, res, blockers);
}
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/di/IgniteTcBotModule.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/di/IgniteTcBotModule.java
index e61e2bd0..d714b998 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/di/IgniteTcBotModule.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/di/IgniteTcBotModule.java
@@ -24,7 +24,6 @@
import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;
-import javax.inject.Inject;
import javax.inject.Provider;
import org.apache.ignite.Ignite;
import org.apache.ignite.ci.ITcHelper;
@@ -34,16 +33,14 @@
import org.apache.ignite.ci.di.scheduler.SchedulerModule;
import org.apache.ignite.ci.github.ignited.GitHubIgnitedModule;
import org.apache.ignite.ci.issue.IssueDetector;
-import org.apache.ignite.ci.jira.IJiraIntegration;
+import org.apache.ignite.ci.jira.JiraIntegrationModule;
import org.apache.ignite.ci.observer.BuildObserver;
import org.apache.ignite.ci.observer.ObserverTask;
import org.apache.ignite.ci.tcbot.trends.MasterTrendsService;
import org.apache.ignite.ci.teamcity.ignited.TeamcityIgnitedModule;
-import org.apache.ignite.ci.user.ICredentialsProv;
import org.apache.ignite.ci.util.ExceptionUtil;
import org.apache.ignite.ci.web.BackgroundUpdater;
import org.apache.ignite.ci.web.TcUpdatePool;
-import org.apache.ignite.ci.web.model.Visa;
import org.apache.ignite.ci.web.model.hist.VisasHistoryStorage;
import org.apache.ignite.ci.web.rest.exception.ServiceStartingException;
@@ -80,27 +77,15 @@
bind(BuildObserver.class).in(new SingletonScope());
bind(VisasHistoryStorage.class).in(new SingletonScope());
bind(ITcHelper.class).to(TcHelper.class).in(new SingletonScope());
-
-bind(IJiraIntegration.class).to(Jira.class).in(new SingletonScope());
-
bind(BackgroundUpdater.class).in(new SingletonScope());
bind(MasterTrendsService.class).in(new SingletonScope());
install(new TeamcityIgnitedModule());
+install(new JiraIntegrationModule());
install(new GitHubIgnitedModule());
install(new
[jira] [Commented] (IGNITE-10369) PDS 4 hangs on TC
[ https://issues.apache.org/jira/browse/IGNITE-10369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707387#comment-16707387 ] Pavel Kovalenko commented on IGNITE-10369: -- [~ibessonov] Thank you for contribution. I've reviewed your changes. There is a little concern. It's not a good idea to skip exceptions in waitForLastCustomEventListenerFuture methods. Instead of this, I suggest to wrap and rethrow checked exception as unchecked (IgniteException) and nullify future in "finally" section. The rest looks good. > PDS 4 hangs on TC > - > > Key: IGNITE-10369 > URL: https://issues.apache.org/jira/browse/IGNITE-10369 > Project: Ignite > Issue Type: Test >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > [https://ci.ignite.apache.org/viewLog.html?buildId=2365697=buildResultsDiv=IgniteTests24Java8_Pds4] > org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse#testClientJoinsWhenActivationIsInProgress > hangs on client connection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10508) Need to support the new checkpoint feature not wait for the previous operation to complete
[ https://issues.apache.org/jira/browse/IGNITE-10508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-10508: -- Ignite Flags: (was: Docs Required) > Need to support the new checkpoint feature not wait for the previous > operation to complete > -- > > Key: IGNITE-10508 > URL: https://issues.apache.org/jira/browse/IGNITE-10508 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.8 > > > There are cases we should trigger the checkpoint, some operations will be > sure that all operation finished before the checkpoint. It is necessary to > support the possibility of run checkpoint without waiting for the completion > of the previous checkpoint. > Solution: > Merge checkpoint pages and append write new dirty pages to a current > checkpoint. > Restrictions: > Trigger new checkpoint should not wait for the previous checkpoint operation > completed. > - It should not break crash recovery mechanisms > - Only one merged is allow in the first implementation (potentially OOM, if > we will try to merge many checkpoint operations) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5759) IgniteCache 6 suite timed out by GridCachePartitionEvictionDuringReadThroughSelfTest.testPartitionRent
[
https://issues.apache.org/jira/browse/IGNITE-5759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707363#comment-16707363
]
ASF GitHub Bot commented on IGNITE-5759:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5531
> IgniteCache 6 suite timed out by
> GridCachePartitionEvictionDuringReadThroughSelfTest.testPartitionRent
> --
>
> Key: IGNITE-5759
> URL: https://issues.apache.org/jira/browse/IGNITE-5759
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Anton Kalashnikov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, test-fail
> Fix For: 2.8
>
> Attachments: threadDumpFromLogs.log
>
>
> Test history:
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests20=-7061194995222816963=testDetails
> There is no 'Test has been timed out' message in logs.
> Last 'Starting test:' message was
> GridCachePartitionEvictionDuringReadThroughSelfTest#testPartitionRent
> Latest exception from working test was as follows;
> {noformat}
> [23:19:11]W: [org.apache.ignite:ignite-core] [2017-07-14
> 20:19:11,392][ERROR][tcp-comm-worker-#8980%distributed.GridCachePartitionEvictionDuringReadThroughSelfTest4%][TcpCommunicationSpi]
> TcpCommunicationSpi failed to establish connection to node, node will be
> dropped from cluster [rmtNode=TcpDiscoveryNode
> [id=a93fce57-6b2d-4947-8c23-8a677b93, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1500063443391, loc=false, ver=2.1.0#19700101-sha1:,
> isClient=false]]
> [23:19:11]W: [org.apache.ignite:ignite-core] class
> org.apache.ignite.IgniteCheckedException: Failed to connect to node (is node
> still alive?). Make sure that each ComputeTask and cache Transaction has a
> timeout set in order to prevent parties from waiting forever in case of
> network issues [nodeId=a93fce57-6b2d-4947-8c23-8a677b93,
> addrs=[/127.0.0.1:45273]]
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3173)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2757)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2649)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$5900(TcpCommunicationSpi.java:245)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.processDisconnect(TcpCommunicationSpi.java:4065)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.body(TcpCommunicationSpi.java:3891)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [23:19:11]W: [org.apache.ignite:ignite-core]Suppressed:
> class org.apache.ignite.IgniteCheckedException: Failed to connect to address
> [addr=/127.0.0.1:45273, err=Connection refused]
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3178)
> [23:19:11]W: [org.apache.ignite:ignite-core]... 6
> more
> [23:19:11]W: [org.apache.ignite:ignite-core]Caused by:
> java.net.ConnectException: Connection refused
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:117)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3024)
> [23:19:11]W: [org.apache.ignite:ignite-core]... 6
> more
> {noformat}
> and then
> {noformat}
> [23:19:11]W: [org.apache.ignite:ignite-core] [2017-07-14
> 20:19:11,895][WARN ][main][root] Interrupting threads started so far: 5
> [23:19:11] : [Step 4/5]
[jira] [Comment Edited] (IGNITE-5759) IgniteCache 6 suite timed out by GridCachePartitionEvictionDuringReadThroughSelfTest.testPartitionRent
[
https://issues.apache.org/jira/browse/IGNITE-5759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707360#comment-16707360
]
Dmitriy Pavlov edited comment on IGNITE-5759 at 12/3/18 3:25 PM:
-
Merged to master
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=commit;h=66d8ac64dc0cd6f83bbfc45560cd08f38d8a92ff
Umuted test
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7061194995222816963=testDetails
[~akalashnikov] thank you for research and for finding that this failure is not
actual anymore.
was (Author: dpavlov):
Merged to master
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=commit;h=66d8ac64dc0cd6f83bbfc45560cd08f38d8a92ff
Umuted test
https://ci.ignite.apache.org/viewLog.html?buildId=2450128=buildResultsDiv=IgniteTests24Java8_Cache6#testNameId-7061194995222816963
[~akalashnikov] thank you for research and for finding that this failure is not
actual anymore.
> IgniteCache 6 suite timed out by
> GridCachePartitionEvictionDuringReadThroughSelfTest.testPartitionRent
> --
>
> Key: IGNITE-5759
> URL: https://issues.apache.org/jira/browse/IGNITE-5759
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Anton Kalashnikov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, test-fail
> Fix For: 2.8
>
> Attachments: threadDumpFromLogs.log
>
>
> Test history:
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests20=-7061194995222816963=testDetails
> There is no 'Test has been timed out' message in logs.
> Last 'Starting test:' message was
> GridCachePartitionEvictionDuringReadThroughSelfTest#testPartitionRent
> Latest exception from working test was as follows;
> {noformat}
> [23:19:11]W: [org.apache.ignite:ignite-core] [2017-07-14
> 20:19:11,392][ERROR][tcp-comm-worker-#8980%distributed.GridCachePartitionEvictionDuringReadThroughSelfTest4%][TcpCommunicationSpi]
> TcpCommunicationSpi failed to establish connection to node, node will be
> dropped from cluster [rmtNode=TcpDiscoveryNode
> [id=a93fce57-6b2d-4947-8c23-8a677b93, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1500063443391, loc=false, ver=2.1.0#19700101-sha1:,
> isClient=false]]
> [23:19:11]W: [org.apache.ignite:ignite-core] class
> org.apache.ignite.IgniteCheckedException: Failed to connect to node (is node
> still alive?). Make sure that each ComputeTask and cache Transaction has a
> timeout set in order to prevent parties from waiting forever in case of
> network issues [nodeId=a93fce57-6b2d-4947-8c23-8a677b93,
> addrs=[/127.0.0.1:45273]]
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3173)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2757)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2649)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$5900(TcpCommunicationSpi.java:245)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.processDisconnect(TcpCommunicationSpi.java:4065)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.body(TcpCommunicationSpi.java:3891)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [23:19:11]W: [org.apache.ignite:ignite-core]Suppressed:
> class org.apache.ignite.IgniteCheckedException: Failed to connect to address
> [addr=/127.0.0.1:45273, err=Connection refused]
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3178)
> [23:19:11]W: [org.apache.ignite:ignite-core]... 6
> more
> [23:19:11]W: [org.apache.ignite:ignite-core]Caused by:
> java.net.ConnectException: Connection refused
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
>
[jira] [Updated] (IGNITE-10512) Fix javadoc for public Query classes.
[ https://issues.apache.org/jira/browse/IGNITE-10512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10512: -- Labels: javadoc (was: full-text-search javadoc) > Fix javadoc for public Query classes. > - > > Key: IGNITE-10512 > URL: https://issues.apache.org/jira/browse/IGNITE-10512 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 1.9 >Reporter: Andrew Mashenkov >Priority: Major > Labels: javadoc > Fix For: 2.8 > > > CacheQuery javadoc looks outdated and useless to used as it is resides in > internal package and we omit javadocs building for 'internal' package. > Let's update javadoc for SqlQuery, SqlFieldsQuery, ScanQuery, SpiQuery with > next info: > - short query type description > - usage example (how to create and run) > - detailed query flags description > - known limitations > - additional features (e.g. geo-spatial support with LGPL package) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10512) Fix javadoc for public Query classes.
[ https://issues.apache.org/jira/browse/IGNITE-10512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-10512: - Assignee: (was: Andrew Mashenkov) > Fix javadoc for public Query classes. > - > > Key: IGNITE-10512 > URL: https://issues.apache.org/jira/browse/IGNITE-10512 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 1.9 >Reporter: Andrew Mashenkov >Priority: Major > Labels: javadoc > Fix For: 2.8 > > > CacheQuery javadoc looks outdated and useless to used as it is resides in > internal package and we omit javadocs building for 'internal' package. > Let's update javadoc for SqlQuery, SqlFieldsQuery, ScanQuery, SpiQuery with > next info: > - short query type description > - usage example (how to create and run) > - detailed query flags description > - known limitations > - additional features (e.g. geo-spatial support with LGPL package) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10512) Fix javadoc for public Query classes.
Andrew Mashenkov created IGNITE-10512:
-
Summary: Fix javadoc for public Query classes.
Key: IGNITE-10512
URL: https://issues.apache.org/jira/browse/IGNITE-10512
Project: Ignite
Issue Type: Improvement
Components: documentation, sql
Affects Versions: 1.9
Reporter: Andrew Mashenkov
Assignee: Andrew Mashenkov
Fix For: 2.8
The documentation for Full TEXT Queries is thin at best:
* What syntax does it use?
* ...is it the full [Lucene Classic Query Parser
Syntax|https://lucene.apache.org/core/6_3_0/queryparser/org/apache/lucene/queryparser/classic/package-summary.html]?
* ...if so how does the syntax map to the {{@QueryTextField}} annotation?
* How is Lucene analyser customisation performed?
* What version is supported? (looks like 3.5.0 which is pretty old, latest is
6.4.1)
* The
[{{@QueryTextField}}|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/query/annotations/QueryTextField.html]
JavaDoc refers to
[{{CacheQuery}}|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/internal/processors/cache/query/CacheQuery.html]
but strangely this doesn't even appear in the official JavaDoc. It is because
it's an 'internal' class?
It's mentioned multiple times as a feature, but doesn't look like much of
Lucene can actually be utilised so clarifications would help greatly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-4841) Improve TEXT Query Documentation
[
https://issues.apache.org/jira/browse/IGNITE-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707358#comment-16707358
]
Andrew Mashenkov commented on IGNITE-4841:
--
[~vozerov],
I've reverted unrelated changes and create a new ticket IGNITE-10512 for them.
> Improve TEXT Query Documentation
>
>
> Key: IGNITE-4841
> URL: https://issues.apache.org/jira/browse/IGNITE-4841
> Project: Ignite
> Issue Type: Improvement
> Components: documentation, sql
>Affects Versions: 1.9
>Reporter: Daniel Siviter
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: full-text-search, javadoc
> Fix For: 2.8
>
>
> The documentation for Full TEXT Queries is thin at best:
> * What syntax does it use?
> * ...is it the full [Lucene Classic Query Parser
> Syntax|https://lucene.apache.org/core/6_3_0/queryparser/org/apache/lucene/queryparser/classic/package-summary.html]?
> * ...if so how does the syntax map to the {{@QueryTextField}} annotation?
> * How is Lucene analyser customisation performed?
> * What version is supported? (looks like 3.5.0 which is pretty old, latest is
> 6.4.1)
> * The
> [{{@QueryTextField}}|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/query/annotations/QueryTextField.html]
> JavaDoc refers to
> [{{CacheQuery}}|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/internal/processors/cache/query/CacheQuery.html]
> but strangely this doesn't even appear in the official JavaDoc. It is
> because it's an 'internal' class?
> It's mentioned multiple times as a feature, but doesn't look like much of
> Lucene can actually be utilised so clarifications would help greatly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10512) Fix javadoc for public Query classes.
[ https://issues.apache.org/jira/browse/IGNITE-10512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10512: -- Component/s: (was: documentation) > Fix javadoc for public Query classes. > - > > Key: IGNITE-10512 > URL: https://issues.apache.org/jira/browse/IGNITE-10512 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 1.9 >Reporter: Andrew Mashenkov >Priority: Major > Labels: javadoc > Fix For: 2.8 > > > CacheQuery javadoc looks outdated and useless to used as it is resides in > internal package and we omit javadocs building for 'internal' package. > Let's update javadoc for SqlQuery, SqlFieldsQuery, ScanQuery, SpiQuery with > next info: > - short query type description > - usage example (how to create and run) > - detailed query flags description > - known limitations > - additional features (e.g. geo-spatial support with LGPL package) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10512) Fix javadoc for public Query classes.
[
https://issues.apache.org/jira/browse/IGNITE-10512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-10512:
--
Description:
CacheQuery javadoc looks outdated and useless to used as it is resides in
internal package and we omit javadocs building for 'internal' package.
Let's update javadoc for SqlQuery, SqlFieldsQuery, ScanQuery, SpiQuery with
next info:
- short query type description
- usage example (how to create and run)
- detailed query flags description
- known limitations
- additional features (e.g. geo-spatial support with LGPL package)
was:
The documentation for Full TEXT Queries is thin at best:
* What syntax does it use?
* ...is it the full [Lucene Classic Query Parser
Syntax|https://lucene.apache.org/core/6_3_0/queryparser/org/apache/lucene/queryparser/classic/package-summary.html]?
* ...if so how does the syntax map to the {{@QueryTextField}} annotation?
* How is Lucene analyser customisation performed?
* What version is supported? (looks like 3.5.0 which is pretty old, latest is
6.4.1)
* The
[{{@QueryTextField}}|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/query/annotations/QueryTextField.html]
JavaDoc refers to
[{{CacheQuery}}|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/internal/processors/cache/query/CacheQuery.html]
but strangely this doesn't even appear in the official JavaDoc. It is because
it's an 'internal' class?
It's mentioned multiple times as a feature, but doesn't look like much of
Lucene can actually be utilised so clarifications would help greatly.
> Fix javadoc for public Query classes.
> -
>
> Key: IGNITE-10512
> URL: https://issues.apache.org/jira/browse/IGNITE-10512
> Project: Ignite
> Issue Type: Improvement
> Components: documentation, sql
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: full-text-search, javadoc
> Fix For: 2.8
>
>
> CacheQuery javadoc looks outdated and useless to used as it is resides in
> internal package and we omit javadocs building for 'internal' package.
> Let's update javadoc for SqlQuery, SqlFieldsQuery, ScanQuery, SpiQuery with
> next info:
> - short query type description
> - usage example (how to create and run)
> - detailed query flags description
> - known limitations
> - additional features (e.g. geo-spatial support with LGPL package)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10507) VisorIdleVerifyTask should return exceptions from all nodes if they are occurred
[ https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-10507: Summary: VisorIdleVerifyTask should return exceptions from all nodes if they are occurred (was: VisorIdleVerifyTask should return exceptions from all nodes if they are occured) > VisorIdleVerifyTask should return exceptions from all nodes if they are > occurred > > > Key: IGNITE-10507 > URL: https://issues.apache.org/jira/browse/IGNITE-10507 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.6 >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Critical > Fix For: 2.8 > > > We should return exceptions from all nodes, if they are occurred. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10507) VisorIdleVerifyTaskV2 should return exceptions from all nodes if they are occurred
[ https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-10507: Summary: VisorIdleVerifyTaskV2 should return exceptions from all nodes if they are occurred (was: VisorIdleVerifyTask should return exceptions from all nodes if they are occurred) > VisorIdleVerifyTaskV2 should return exceptions from all nodes if they are > occurred > -- > > Key: IGNITE-10507 > URL: https://issues.apache.org/jira/browse/IGNITE-10507 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.6 >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Critical > Fix For: 2.8 > > > We should return exceptions from all nodes, if they are occurred. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10417) notifyDiscoveryListener() call can be lost
[ https://issues.apache.org/jira/browse/IGNITE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707346#comment-16707346 ] Ivan Daschinskiy commented on IGNITE-10417: --- [~voropava] Hi, Pavel. Your fix looks good for me. And TC results is also ok. > notifyDiscoveryListener() call can be lost > -- > > Key: IGNITE-10417 > URL: https://issues.apache.org/jira/browse/IGNITE-10417 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > > 1) ServerImpl:5455 notifyDiscoveryListener can not be called in case of > spiState != CONNECTED, for example DISCONNECTING which is valid state > nevetheless inside notifyDiscoveryListener we check spiState == CONNECTED || > spiState == DISCONNECTING, also we need to improve logging in > notifyDiscoveryListener(). > 2) Improve logging on duplicated custom discovery event. > 3) Add assert if msg.creatorNodeId() doesn't exist in topology this is bad > behaviour taht should lead to node fail. > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10291) Unable to find row by index created on partial baseline topology
[ https://issues.apache.org/jira/browse/IGNITE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707340#comment-16707340 ] ASF GitHub Bot commented on IGNITE-10291: - Github user devozerov closed the pull request at: https://github.com/apache/ignite/pull/5525 > Unable to find row by index created on partial baseline topology > > > Key: IGNITE-10291 > URL: https://issues.apache.org/jira/browse/IGNITE-10291 > Project: Ignite > Issue Type: Bug > Components: cache, persistence, sql >Affects Versions: 2.4, 2.5, 2.6 >Reporter: Pavel Vinokurov >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 2.8 > > Attachments: Reproducer.java > > > Steps to reproduce: > 1. Start two nodes cluster with persistence. > 2. Create table > CREATE TABLE PERSON ( > FIRST_NAME VARCHAR, > LAST_NAME VARCHAR, > ADDRESS VARCHAR, > LANG VARCHAR, > BIRTH_DATE TIMESTAMP, > CONSTRAINT PK_PESON PRIMARY KEY (FIRST_NAME,LAST_NAME,ADDRESS,LANG) > ) WITH "key_type=PersonKeyType, CACHE_NAME=PersonCache, > value_type=PersonValueType, > AFFINITY_KEY=FIRST_NAME,template=PARTITIONED,backups=1" > Insert 1000 rows. > 3. Stop the second node. > 4. Create index > create index PERSON_FIRST_NAME_IDX on PERSON(FIRST_NAME) > 5. Start the second node > 6. Perform select query for each row: > select * from PERSON use index(PERSON_FIRST_NAME_IDX) > where > FIRST_NAME=? > and LAST_NAME=? > and ADDRESS=? > and LANG = ? > Result: The select doesn't return row in half of cases. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10507) VisorIdleVerifyTask should return exceptions from all nodes if they are occured
[ https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-10507: Description: We should return exceptions from all nodes, if they are occurred. (was: We should return exceptions from all nodes, if they are occured.) > VisorIdleVerifyTask should return exceptions from all nodes if they are > occured > --- > > Key: IGNITE-10507 > URL: https://issues.apache.org/jira/browse/IGNITE-10507 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.6 >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Critical > Fix For: 2.8 > > > We should return exceptions from all nodes, if they are occurred. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10386) Add mode when WAL won't be disabled during rebalancing caused by BLT change
[
https://issues.apache.org/jira/browse/IGNITE-10386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707302#comment-16707302
]
Ignite TC Bot commented on IGNITE-10386:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2450687]]
*
WalRolloverTypesTest.testCurrentSegmentTypeWithCacheActivityFsyncModeArchiveOn
(last started)
{color:#d04437}Cache 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2450669]]
* IgniteCacheTestSuite2:
IgniteCacheIncrementTxTest.testIncrementTxTopologyChange2 - 0,0% fails in last
100 master runs.
* IgniteCacheTestSuite2:
IgniteCacheIncrementTxTest.testIncrementTxTopologyChange1 - 0,0% fails in last
100 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2450702buildTypeId=IgniteTests24Java8_RunAll]
> Add mode when WAL won't be disabled during rebalancing caused by BLT change
> ---
>
> Key: IGNITE-10386
> URL: https://issues.apache.org/jira/browse/IGNITE-10386
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> Enabling IgniteSystemProperties#IGNITE_DISABLE_WAL_DURING_REBALANCING
> disables WAL for cache group during rebalancing in case local node has no
> OWNING partitions for this group.
> We should add mode when in specific case (after BaselineTopology change) WAL
> won't be disabled even if this property is switched on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10511) disco-event-worker can be deadlocked by BinaryContext.metadata running is sys striped pool waiting for cache entry lock
[
https://issues.apache.org/jira/browse/IGNITE-10511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-10511:
-
Description:
See attached thread dump:
disco-event-worker hangs on removeExplicitNodeLocks() on GridCacheMapEntry
which is held by GridDistributedTxRemoteAdapter acquired in
GridCacheMapEntry.innerSet().
CacheObjectBinaryProcessorImpl is waiting on metadata message on discovery,
which can be processed due to disco-event-worker is stuck.
Possible fix:
{code:java}
public void onNodeLeft(final ClusterNode node) {
if (isDone() || !enterBusy())
return;
cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
try {
onDiscoveryEvent(new IgniteRunnable() {
@Override public void run() {
if (isDone() || !enterBusy())
return;
...
}
});
}
finally {
...
}
}
{code}
As we can see most of the processing is done async in IgniteRunnable() in
exchange-worker.
We can move
{code:java}
cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
{code}
inside this Runnable's body.
was:
See attached thread dump:
disco-event-worker hangs on removeExplicitNodeLocks() on GridCacheMapEntry
which is held by GridDistributedTxRemoteAdapter acquired in
GridCacheMapEntry.innerSet().
CacheObjectBinaryProcessorImpl is waiting on metadata message on discovery,
which can be processed due to disco-event-worker is stuck.
Possible fix:
{quote}public void onNodeLeft(final ClusterNode node) {
if (isDone() || !enterBusy())
return;
cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
try {
onDiscoveryEvent(new IgniteRunnable() {
@Override public void run() {
if (isDone() || !enterBusy())
return;
...
{quote}
As we can see most of the processing is done async in IgniteRunnable() in
exchange-worker.
We can move
{quote}cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
{quote}
inside this Runnable's body.
> disco-event-worker can be deadlocked by BinaryContext.metadata running is sys
> striped pool waiting for cache entry lock
> ---
>
> Key: IGNITE-10511
> URL: https://issues.apache.org/jira/browse/IGNITE-10511
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Priority: Major
> Attachments: race.txt
>
>
> See attached thread dump:
> disco-event-worker hangs on removeExplicitNodeLocks() on GridCacheMapEntry
> which is held by GridDistributedTxRemoteAdapter acquired in
> GridCacheMapEntry.innerSet().
> CacheObjectBinaryProcessorImpl is waiting on metadata message on discovery,
> which can be processed due to disco-event-worker is stuck.
> Possible fix:
> {code:java}
> public void onNodeLeft(final ClusterNode node) {
> if (isDone() || !enterBusy())
> return;
> cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
> try {
> onDiscoveryEvent(new IgniteRunnable() {
> @Override public void run() {
> if (isDone() || !enterBusy())
> return;
>
> ...
> }
> });
> }
> finally {
> ...
> }
> }
> {code}
> As we can see most of the processing is done async in IgniteRunnable() in
> exchange-worker.
>
> We can move
> {code:java}
> cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
> {code}
> inside this Runnable's body.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10511) disco-event-worker can be deadlocked by BinaryContext.metadata running is sys striped pool waiting for cache entry lock
[
https://issues.apache.org/jira/browse/IGNITE-10511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Voronkin updated IGNITE-10511:
Description:
See attached thread dump:
disco-event-worker hangs on removeExplicitNodeLocks() on GridCacheMapEntry
which is held by GridDistributedTxRemoteAdapter acquired in
GridCacheMapEntry.innerSet().
CacheObjectBinaryProcessorImpl is waiting on metadata message on discovery,
which can be processed due to disco-event-worker is stuck.
Possible fix:
{quote}public void onNodeLeft(final ClusterNode node) {
if (isDone() || !enterBusy())
return;
cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
try {
onDiscoveryEvent(new IgniteRunnable() {
@Override public void run() {
if (isDone() || !enterBusy())
return;
...
{quote}
As we can see most of the processing is done async in IgniteRunnable() in
exchange-worker.
We can move
{quote}cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
{quote}
inside this Runnable's body.
was:
See attached thread dump:
disco-event-worker hangs on removeExplicitNodeLocks() on GridCacheMapEntry
which is held by GridDistributedTxRemoteAdapter acquired in
GridCacheMapEntry.innerSet().
CacheObjectBinaryProcessorImpl is waiting on metadata message on discovery,
which can be processed due to disco-event-worker is stuck.
Possible fix:
public void onNodeLeft(final ClusterNode node) {
if (isDone() || !enterBusy())
return;
cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
try {
onDiscoveryEvent(new IgniteRunnable() {
@Override public void run() {
if (isDone() || !enterBusy())
return;
As we can see most of the processing is done async in IgniteRunnable() in
exchange-worker.
We can move
{quote}cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
{quote}
inside this Runnable's body.
> disco-event-worker can be deadlocked by BinaryContext.metadata running is sys
> striped pool waiting for cache entry lock
> ---
>
> Key: IGNITE-10511
> URL: https://issues.apache.org/jira/browse/IGNITE-10511
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Priority: Major
> Attachments: race.txt
>
>
> See attached thread dump:
> disco-event-worker hangs on removeExplicitNodeLocks() on GridCacheMapEntry
> which is held by GridDistributedTxRemoteAdapter acquired in
> GridCacheMapEntry.innerSet().
> CacheObjectBinaryProcessorImpl is waiting on metadata message on discovery,
> which can be processed due to disco-event-worker is stuck.
> Possible fix:
>
> {quote}public void onNodeLeft(final ClusterNode node) {
> if (isDone() || !enterBusy())
> return;
> cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
> try {
> onDiscoveryEvent(new IgniteRunnable() {
> @Override public void run() {
> if (isDone() || !enterBusy())
> return;
> ...
> {quote}
>
> As we can see most of the processing is done async in IgniteRunnable() in
> exchange-worker.
>
> We can move
> {quote}cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
> {quote}
> inside this Runnable's body.
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10291) Unable to find row by index created on partial baseline topology
[ https://issues.apache.org/jira/browse/IGNITE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707300#comment-16707300 ] Vladimir Ozerov commented on IGNITE-10291: -- Same failures observed in master, so it is not related to current ticket. > Unable to find row by index created on partial baseline topology > > > Key: IGNITE-10291 > URL: https://issues.apache.org/jira/browse/IGNITE-10291 > Project: Ignite > Issue Type: Bug > Components: cache, persistence, sql >Affects Versions: 2.4, 2.5, 2.6 >Reporter: Pavel Vinokurov >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 2.8 > > Attachments: Reproducer.java > > > Steps to reproduce: > 1. Start two nodes cluster with persistence. > 2. Create table > CREATE TABLE PERSON ( > FIRST_NAME VARCHAR, > LAST_NAME VARCHAR, > ADDRESS VARCHAR, > LANG VARCHAR, > BIRTH_DATE TIMESTAMP, > CONSTRAINT PK_PESON PRIMARY KEY (FIRST_NAME,LAST_NAME,ADDRESS,LANG) > ) WITH "key_type=PersonKeyType, CACHE_NAME=PersonCache, > value_type=PersonValueType, > AFFINITY_KEY=FIRST_NAME,template=PARTITIONED,backups=1" > Insert 1000 rows. > 3. Stop the second node. > 4. Create index > create index PERSON_FIRST_NAME_IDX on PERSON(FIRST_NAME) > 5. Start the second node > 6. Perform select query for each row: > select * from PERSON use index(PERSON_FIRST_NAME_IDX) > where > FIRST_NAME=? > and LAST_NAME=? > and ADDRESS=? > and LANG = ? > Result: The select doesn't return row in half of cases. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10291) Unable to find row by index created on partial baseline topology
[
https://issues.apache.org/jira/browse/IGNITE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707298#comment-16707298
]
Ignite TC Bot commented on IGNITE-10291:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Hibernate 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2451320]]
* HibernateL2CacheTransactionalUseSyncSelfTest.testRegionClear (last started)
{color:#d04437}Cache (Restarts) 1{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2450348]]
* IgniteCacheRestartTestSuite:
GridCacheReplicatedNodeRestartSelfTest.testRestartWithPutEightNodesTwoBackups -
0,0% fails in last 100 master runs.
{color:#d04437}Compute (Grid){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2450294]]
* IgniteBinaryObjectsComputeGridTestSuite:
GridEventStorageCheckAllEventsSelfTest.testFailoverJobTask - 0,0% fails in last
100 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2450385buildTypeId=IgniteTests24Java8_RunAll]
> Unable to find row by index created on partial baseline topology
>
>
> Key: IGNITE-10291
> URL: https://issues.apache.org/jira/browse/IGNITE-10291
> Project: Ignite
> Issue Type: Bug
> Components: cache, persistence, sql
>Affects Versions: 2.4, 2.5, 2.6
>Reporter: Pavel Vinokurov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 2.8
>
> Attachments: Reproducer.java
>
>
> Steps to reproduce:
> 1. Start two nodes cluster with persistence.
> 2. Create table
> CREATE TABLE PERSON (
> FIRST_NAME VARCHAR,
> LAST_NAME VARCHAR,
> ADDRESS VARCHAR,
> LANG VARCHAR,
> BIRTH_DATE TIMESTAMP,
> CONSTRAINT PK_PESON PRIMARY KEY (FIRST_NAME,LAST_NAME,ADDRESS,LANG)
> ) WITH "key_type=PersonKeyType, CACHE_NAME=PersonCache,
> value_type=PersonValueType,
> AFFINITY_KEY=FIRST_NAME,template=PARTITIONED,backups=1"
> Insert 1000 rows.
> 3. Stop the second node.
> 4. Create index
> create index PERSON_FIRST_NAME_IDX on PERSON(FIRST_NAME)
> 5. Start the second node
> 6. Perform select query for each row:
> select * from PERSON use index(PERSON_FIRST_NAME_IDX)
> where
> FIRST_NAME=?
> and LAST_NAME=?
> and ADDRESS=?
> and LANG = ?
> Result: The select doesn't return row in half of cases.
> The reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10511) disco-event-worker can be deadlocked by BinaryContext.metadata running is sys striped pool waiting for cache entry lock
[
https://issues.apache.org/jira/browse/IGNITE-10511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Voronkin updated IGNITE-10511:
Description:
See attached thread dump:
disco-event-worker hangs on removeExplicitNodeLocks() on GridCacheMapEntry
which is held by GridDistributedTxRemoteAdapter acquired in
GridCacheMapEntry.innerSet().
CacheObjectBinaryProcessorImpl is waiting on metadata message on discovery,
which can be processed due to disco-event-worker is stuck.
Possible fix:
public void onNodeLeft(final ClusterNode node) {
if (isDone() || !enterBusy())
return;
cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
try {
onDiscoveryEvent(new IgniteRunnable() {
@Override public void run() {
if (isDone() || !enterBusy())
return;
As we can see most of the processing is done async in IgniteRunnable() in
exchange-worker.
We can move
{quote}cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
{quote}
inside this Runnable's body.
was:
See attached thread dump:
disco-event-worker hangs on removeExplicitNodeLocks() on GridCacheMapEntry
which is held by GridDistributedTxRemoteAdapter acquired in
GridCacheMapEntry.innerSet().
CacheObjectBinaryProcessorImpl is waiting on metadata message on discovery,
which can be processed due to disco-event-worker is stuck.
> disco-event-worker can be deadlocked by BinaryContext.metadata running is sys
> striped pool waiting for cache entry lock
> ---
>
> Key: IGNITE-10511
> URL: https://issues.apache.org/jira/browse/IGNITE-10511
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Priority: Major
> Attachments: race.txt
>
>
> See attached thread dump:
> disco-event-worker hangs on removeExplicitNodeLocks() on GridCacheMapEntry
> which is held by GridDistributedTxRemoteAdapter acquired in
> GridCacheMapEntry.innerSet().
> CacheObjectBinaryProcessorImpl is waiting on metadata message on discovery,
> which can be processed due to disco-event-worker is stuck.
> Possible fix:
>
> public void onNodeLeft(final ClusterNode node) {
> if (isDone() || !enterBusy())
> return;
> cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
> try {
> onDiscoveryEvent(new IgniteRunnable() {
> @Override public void run() {
> if (isDone() || !enterBusy())
> return;
>
> As we can see most of the processing is done async in IgniteRunnable() in
> exchange-worker.
>
> We can move
> {quote}cctx.mvcc().removeExplicitNodeLocks(node.id(), initialVersion());
> {quote}
> inside this Runnable's body.
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10291) Unable to find row by index created on partial baseline topology
[ https://issues.apache.org/jira/browse/IGNITE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707299#comment-16707299 ] Vladimir Ozerov commented on IGNITE-10291: -- Consistent hangs in Hibernate 2. Investigating. > Unable to find row by index created on partial baseline topology > > > Key: IGNITE-10291 > URL: https://issues.apache.org/jira/browse/IGNITE-10291 > Project: Ignite > Issue Type: Bug > Components: cache, persistence, sql >Affects Versions: 2.4, 2.5, 2.6 >Reporter: Pavel Vinokurov >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 2.8 > > Attachments: Reproducer.java > > > Steps to reproduce: > 1. Start two nodes cluster with persistence. > 2. Create table > CREATE TABLE PERSON ( > FIRST_NAME VARCHAR, > LAST_NAME VARCHAR, > ADDRESS VARCHAR, > LANG VARCHAR, > BIRTH_DATE TIMESTAMP, > CONSTRAINT PK_PESON PRIMARY KEY (FIRST_NAME,LAST_NAME,ADDRESS,LANG) > ) WITH "key_type=PersonKeyType, CACHE_NAME=PersonCache, > value_type=PersonValueType, > AFFINITY_KEY=FIRST_NAME,template=PARTITIONED,backups=1" > Insert 1000 rows. > 3. Stop the second node. > 4. Create index > create index PERSON_FIRST_NAME_IDX on PERSON(FIRST_NAME) > 5. Start the second node > 6. Perform select query for each row: > select * from PERSON use index(PERSON_FIRST_NAME_IDX) > where > FIRST_NAME=? > and LAST_NAME=? > and ADDRESS=? > and LANG = ? > Result: The select doesn't return row in half of cases. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10511) disco-event-worker can be deadlocked by BinaryContext.metadata running is sys striped pool waiting for cache entry lock
[ https://issues.apache.org/jira/browse/IGNITE-10511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-10511: Description: See attached thread dump: disco-event-worker hangs on removeExplicitNodeLocks() on GridCacheMapEntry which is held by GridDistributedTxRemoteAdapter acquired in GridCacheMapEntry.innerSet(). CacheObjectBinaryProcessorImpl is waiting on metadata message on discovery, which can be processed due to disco-event-worker is stuck. > disco-event-worker can be deadlocked by BinaryContext.metadata running is sys > striped pool waiting for cache entry lock > --- > > Key: IGNITE-10511 > URL: https://issues.apache.org/jira/browse/IGNITE-10511 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Priority: Major > Attachments: race.txt > > > See attached thread dump: > disco-event-worker hangs on removeExplicitNodeLocks() on GridCacheMapEntry > which is held by GridDistributedTxRemoteAdapter acquired in > GridCacheMapEntry.innerSet(). > CacheObjectBinaryProcessorImpl is waiting on metadata message on discovery, > which can be processed due to disco-event-worker is stuck. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10130) Add option for disable triggering cache interceptor in case of conflicts.
[ https://issues.apache.org/jira/browse/IGNITE-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707284#comment-16707284 ] Sergey Antonov edited comment on IGNITE-10130 at 12/3/18 2:42 PM: -- [~amashenkov] I reran the build. It's ok. https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite_IgniteTests24Java8=pull%2F5251%2Fhead=buildTypeStatusDiv was (Author: antonovsergey93): [~amashenkov] I reran build. It's ok. https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite_IgniteTests24Java8=pull%2F5251%2Fhead=buildTypeStatusDiv > Add option for disable triggering cache interceptor in case of conflicts. > - > > Key: IGNITE-10130 > URL: https://issues.apache.org/jira/browse/IGNITE-10130 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.8 > > > It's needed for our proprietary plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10511) disco-event-worker can be deadlocked by BinaryContext.metadata running is sys striped pool waiting for cache entry lock
[ https://issues.apache.org/jira/browse/IGNITE-10511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-10511: Attachment: race.txt > disco-event-worker can be deadlocked by BinaryContext.metadata running is sys > striped pool waiting for cache entry lock > --- > > Key: IGNITE-10511 > URL: https://issues.apache.org/jira/browse/IGNITE-10511 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Priority: Major > Attachments: race.txt > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10511) disco-event-worker can be deadlocked by BinaryContext.metadata running is sys striped pool waiting for cache entry lock
Pavel Voronkin created IGNITE-10511: --- Summary: disco-event-worker can be deadlocked by BinaryContext.metadata running is sys striped pool waiting for cache entry lock Key: IGNITE-10511 URL: https://issues.apache.org/jira/browse/IGNITE-10511 Project: Ignite Issue Type: Bug Reporter: Pavel Voronkin Attachments: race.txt -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10130) Add option for disable triggering cache interceptor in case of conflicts.
[ https://issues.apache.org/jira/browse/IGNITE-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707284#comment-16707284 ] Sergey Antonov commented on IGNITE-10130: - [~amashenkov] I reran build. It's ok. https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite_IgniteTests24Java8=pull%2F5251%2Fhead=buildTypeStatusDiv > Add option for disable triggering cache interceptor in case of conflicts. > - > > Key: IGNITE-10130 > URL: https://issues.apache.org/jira/browse/IGNITE-10130 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.8 > > > It's needed for our proprietary plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10417) notifyDiscoveryListener() call can be lost
[
https://issues.apache.org/jira/browse/IGNITE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707282#comment-16707282
]
Ignite TC Bot commented on IGNITE-10417:
{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=2423040buildTypeId=IgniteTests24Java8_RunAll]
> notifyDiscoveryListener() call can be lost
> --
>
> Key: IGNITE-10417
> URL: https://issues.apache.org/jira/browse/IGNITE-10417
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Pavel Voronkin
>Assignee: Pavel Voronkin
>Priority: Major
> Fix For: 2.8
>
>
> 1) ServerImpl:5455 notifyDiscoveryListener can not be called in case of
> spiState != CONNECTED, for example DISCONNECTING which is valid state
> nevetheless inside notifyDiscoveryListener we check spiState == CONNECTED ||
> spiState == DISCONNECTING, also we need to improve logging in
> notifyDiscoveryListener().
> 2) Improve logging on duplicated custom discovery event.
> 3) Add assert if msg.creatorNodeId() doesn't exist in topology this is bad
> behaviour taht should lead to node fail.
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[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=16707262#comment-16707262
]
Ilya Lantukh commented on IGNITE-9303:
--
I don't see any problem in PageMemory code, only in PageMemoryTracker (which is
just a testing utility).
> 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] [Assigned] (IGNITE-10507) VisorIdleVerifyTask should return exceptions from all nodes if they are occured
[ https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov reassigned IGNITE-10507: --- Assignee: Sergey Antonov > VisorIdleVerifyTask should return exceptions from all nodes if they are > occured > --- > > Key: IGNITE-10507 > URL: https://issues.apache.org/jira/browse/IGNITE-10507 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.6 >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Critical > Fix For: 2.8 > > > We should return exceptions from all nodes, if they are occured. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10507) VisorIdleVerifyTask should return exceptions from all nodes if they are occured
[ https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov reassigned IGNITE-10507: --- Assignee: (was: Sergey Antonov) > VisorIdleVerifyTask should return exceptions from all nodes if they are > occured > --- > > Key: IGNITE-10507 > URL: https://issues.apache.org/jira/browse/IGNITE-10507 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.6 >Reporter: Sergey Antonov >Priority: Critical > Fix For: 2.8 > > > We should return exceptions from all nodes, if they are occured. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10510) [ML] Use OneVsRest for SVMLinearMultiClassClassificationTrainer
Yury Babak created IGNITE-10510: --- Summary: [ML] Use OneVsRest for SVMLinearMultiClassClassificationTrainer Key: IGNITE-10510 URL: https://issues.apache.org/jira/browse/IGNITE-10510 Project: Ignite Issue Type: Improvement Components: ml Reporter: Yury Babak Assignee: Alexey Platonov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10434) MVCC: Transaction asynchronous rollback bug.
[
https://issues.apache.org/jira/browse/IGNITE-10434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov reassigned IGNITE-10434:
-
Assignee: Igor Seliverstov
> MVCC: Transaction asynchronous rollback bug.
>
>
> Key: IGNITE-10434
> URL: https://issues.apache.org/jira/browse/IGNITE-10434
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Igor Seliverstov
>Priority: Major
>
> There is some bug in mvcc tx asynchronous rollback flow. Sometimes
> transaction is not rolled back completely: Remote transactions remain alive
> while Near and Dht transactions are terminated locally and on MVCC
> coordinator.
> Reproducer: {{MvccTxRollbackAsyncTest#testMixedAsyncRollbackTypes}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10368) MVCC: Create "Cache 9" test suite for MVCC mode.
[ https://issues.apache.org/jira/browse/IGNITE-10368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707256#comment-16707256 ] ASF GitHub Bot commented on IGNITE-10368: - GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/5556 IGNITE-10368: Add mvcc cache test suite 9. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10368 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5556.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 #5556 commit 6ff64debbf943384641f93cf6c60605abf3278b0 Author: Andrey V. Mashenkov Date: 2018-12-03T13:40:31Z IGNITE-10368: Add mvcc cache test suite 9. > MVCC: Create "Cache 9" test suite for MVCC mode. > > > Key: IGNITE-10368 > URL: https://issues.apache.org/jira/browse/IGNITE-10368 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > > Create MVCC version of IgniteCacheTestSuite9 and add it to TC. > All non-relevant tests should be marked as ignored. > Failed tests should be muted and tickets should be created for unknown > failure reasons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10369) PDS 4 hangs on TC
[
https://issues.apache.org/jira/browse/IGNITE-10369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707252#comment-16707252
]
Ignite TC Bot commented on IGNITE-10369:
{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=2432016buildTypeId=IgniteTests24Java8_RunAll]
> PDS 4 hangs on TC
> -
>
> Key: IGNITE-10369
> URL: https://issues.apache.org/jira/browse/IGNITE-10369
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> [https://ci.ignite.apache.org/viewLog.html?buildId=2365697=buildResultsDiv=IgniteTests24Java8_Pds4]
> org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse#testClientJoinsWhenActivationIsInProgress
> hangs on client connection.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10457) MVCC TX: GridIndexRebuildWithMvccEnabledSelfTest fails
[
https://issues.apache.org/jira/browse/IGNITE-10457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707249#comment-16707249
]
Ignite TC Bot commented on IGNITE-10457:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2431107]]
* TcpCommunicationSpiDropNodesTest.testTwoNodesEachOther (last started)
{color:#d04437}PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2431159]]
* IgnitePdsTestSuite: BPlusTreePageMemoryImplTest.testMassiveRemove2_false -
0,0% fails in last 100 master runs.
{color:#d04437}PDS 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2431162]]
* IgnitePdsTestSuite4:
ResetLostPartitionTest.testReactivateGridBeforeResetLostPartitions - 0,0% fails
in last 100 master runs.
{color:#d04437}Platform C++ (Windows x64){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=2431117]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2431175buildTypeId=IgniteTests24Java8_RunAll]
> MVCC TX: GridIndexRebuildWithMvccEnabledSelfTest fails
> --
>
> Key: IGNITE-10457
> URL: https://issues.apache.org/jira/browse/IGNITE-10457
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.8
>
>
> See the log below:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Runtime failure on bounds: [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow
> []]
> 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.query.h2.GridIndexRebuildSelfTest.putData(GridIndexRebuildSelfTest.java:191)
> at
> org.apache.ignite.internal.processors.query.h2.GridIndexRebuildWithMvccEnabledSelfTest.testIndexRebuild(GridIndexRebuildWithMvccEnabledSelfTest.java:76)
> 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.IgniteCheckedException: Runtime failure on
> bounds: [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1061)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1968)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccUpdate(GridCacheOffheapManager.java:2032)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:543)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1142)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.continueLoop(GridDhtTxAbstractEnlistFuture.java:463)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:363)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.enlistLocal(GridNearTxEnlistFuture.java:525)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.sendBatch(GridNearTxEnlistFuture.java:420)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.sendNextBatches(GridNearTxEnlistFuture.java:167)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.map(GridNearTxEnlistFuture.java:143)
>
[jira] [Assigned] (IGNITE-10468) MVCC TX: Failover
[ https://issues.apache.org/jira/browse/IGNITE-10468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-10468: - Assignee: Igor Seliverstov > MVCC TX: Failover > - > > Key: IGNITE-10468 > URL: https://issues.apache.org/jira/browse/IGNITE-10468 > Project: Ignite > Issue Type: Task >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > > There is several problems in mvcc failover scenarios. > The task is an umbrella ticket for currently known issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10417) notifyDiscoveryListener() call can be lost
[ https://issues.apache.org/jira/browse/IGNITE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-10417: -- Affects Version/s: 2.7 > notifyDiscoveryListener() call can be lost > -- > > Key: IGNITE-10417 > URL: https://issues.apache.org/jira/browse/IGNITE-10417 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > > 1) ServerImpl:5455 notifyDiscoveryListener can not be called in case of > spiState != CONNECTED, for example DISCONNECTING which is valid state > nevetheless inside notifyDiscoveryListener we check spiState == CONNECTED || > spiState == DISCONNECTING, also we need to improve logging in > notifyDiscoveryListener(). > 2) Improve logging on duplicated custom discovery event. > 3) Add assert if msg.creatorNodeId() doesn't exist in topology this is bad > behaviour taht should lead to node fail. > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10417) notifyDiscoveryListener() call can be lost
[ https://issues.apache.org/jira/browse/IGNITE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-10417: -- Ignite Flags: (was: Docs Required) > notifyDiscoveryListener() call can be lost > -- > > Key: IGNITE-10417 > URL: https://issues.apache.org/jira/browse/IGNITE-10417 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > > 1) ServerImpl:5455 notifyDiscoveryListener can not be called in case of > spiState != CONNECTED, for example DISCONNECTING which is valid state > nevetheless inside notifyDiscoveryListener we check spiState == CONNECTED || > spiState == DISCONNECTING, also we need to improve logging in > notifyDiscoveryListener(). > 2) Improve logging on duplicated custom discovery event. > 3) Add assert if msg.creatorNodeId() doesn't exist in topology this is bad > behaviour taht should lead to node fail. > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10483) MVCC: Enlist request deserialization failure causes grid hanging.
[
https://issues.apache.org/jira/browse/IGNITE-10483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707234#comment-16707234
]
Ignite TC Bot commented on IGNITE-10483:
{panel:title=- Run :: IntelliJ IDEA Inspections: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *- Run :: IntelliJ IDEA Inspections*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2451050buildTypeId=IgniteTests24Java8_RunIntelliJIdeaInspections]
> MVCC: Enlist request deserialization failure causes grid hanging.
> -
>
> Key: IGNITE-10483
> URL: https://issues.apache.org/jira/browse/IGNITE-10483
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.8
>
>
> Looks like remote serialization issues are not propagated back to near node
> and user request hangs forever.
> We should add error handling for all mvcc Enlist requests into
> GridCacheIoManager
>
> {noformat}
> [19:11:49]W: [org.apache.ignite:ignite-core] class
> org.apache.ignite.IgniteCheckedException: Failed to send response to node.
> Unsupported direct type [message=GridNearTxEnlistRequest [threadId
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:1048)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:582)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:383)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:309)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:299)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1568)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1196)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1092)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [19:11:49]W: [org.apache.ignite:ignite-core] Caused by: class
> org.apache.ignite.IgniteCheckedException: Failed to unmarshal object with
> optimized marshaller
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9997)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10049)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridInvokeValue.finishUnmarshal(GridInvokeValue.java:108)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistRequest.finishUnmarshal(GridNearTxEnlistRequest.java:359)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1538)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> [19:11:49]W: [org.apache.ignite:ignite-core] ... 11 more
> [19:11:49]W: [org.apache.ignite:ignite-core] Caused by: class
> org.apache.ignite.binary.BinaryObjectException: Failed to unmarshal object
> with optimized marshaller
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1789)
> [19:11:49]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1964)
>
[jira] [Commented] (IGNITE-10509) Rollback exception instead of timeout exception
[ https://issues.apache.org/jira/browse/IGNITE-10509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707220#comment-16707220 ] ASF GitHub Bot commented on IGNITE-10509: - GitHub user akalash opened a pull request: https://github.com/apache/ignite/pull/ IGNITE-10509 reordered setting of timeout flag and transaction state You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10509 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/.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 # commit ada8fc9cb664e70f975312007f9d5003ca6a82b0 Author: Anton Kalashnikov Date: 2018-12-03T13:49:24Z IGNITE-10509 reordered setting of timeout flag and transaction state > Rollback exception instead of timeout exception > --- > > Key: IGNITE-10509 > URL: https://issues.apache.org/jira/browse/IGNITE-10509 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > > Looks like we have race on changing transaction state between timedOut and > state set > Reproducer - TxRollbackOnTimeoutNearCacheTest.testEnlistManyWrite -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10417) notifyDiscoveryListener() call can be lost
[ https://issues.apache.org/jira/browse/IGNITE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-10417: -- Fix Version/s: 2.8 > notifyDiscoveryListener() call can be lost > -- > > Key: IGNITE-10417 > URL: https://issues.apache.org/jira/browse/IGNITE-10417 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > > 1) ServerImpl:5455 notifyDiscoveryListener can not be called in case of > spiState != CONNECTED, for example DISCONNECTING which is valid state > nevetheless inside notifyDiscoveryListener we check spiState == CONNECTED || > spiState == DISCONNECTING, also we need to improve logging in > notifyDiscoveryListener(). > 2) Improve logging on duplicated custom discovery event. > 3) Add assert if msg.creatorNodeId() doesn't exist in topology this is bad > behaviour taht should lead to node fail. > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10509) Rollback exception instead of timeout exception
Anton Kalashnikov created IGNITE-10509: -- Summary: Rollback exception instead of timeout exception Key: IGNITE-10509 URL: https://issues.apache.org/jira/browse/IGNITE-10509 Project: Ignite Issue Type: Bug Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov Looks like we have race on changing transaction state between timedOut and state set Reproducer - TxRollbackOnTimeoutNearCacheTest.testEnlistManyWrite -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10437) GridCacheWriteBehindStoreMultithreadedSelfTest.testFlushFromTheSameThreadWithCoalescing is flaky
[
https://issues.apache.org/jira/browse/IGNITE-10437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707196#comment-16707196
]
Ryabov Dmitrii commented on IGNITE-10437:
-
Good idea, I'll do it.
> GridCacheWriteBehindStoreMultithreadedSelfTest.testFlushFromTheSameThreadWithCoalescing
> is flaky
>
>
> Key: IGNITE-10437
> URL: https://issues.apache.org/jira/browse/IGNITE-10437
> Project: Ignite
> Issue Type: Test
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Minor
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Fails periodically on
> [TeamCity|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2991182438861864832=testDetails_IgniteTests24Java8=%3Cdefault%3E].
> {code:java}
> junit.framework.AssertionFailedError: No cache overflows detected (a bug or
> too few keys or too few delay?)
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at
> org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStoreMultithreadedSelfTest.testFlushFromTheSameThread(GridCacheWriteBehindStoreMultithreadedSelfTest.java:215)
> at
> org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStoreMultithreadedSelfTest.testFlushFromTheSameThreadWithCoalescing(GridCacheWriteBehindStoreMultithreadedSelfTest.java:166)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
