[jira] [Commented] (IGNITE-10344) Speed up cleanupRestoredCaches
[
https://issues.apache.org/jira/browse/IGNITE-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819594#comment-16819594
]
Ivan Rakov commented on IGNITE-10344:
-
[~Denis Chudov], some comments:
1. FilePageStoreManager: we usually place inner classes at the bottom.
2. FilePageStoreManager: let's mention which problem we are solving with
LongOperationAsyncExecutor in javadoc. Also, let's metion contract: next
developer should somehow find out that modifications of idxCacheStores should
be protected with async executor.
3. What exactly does CleanupRestoredCachesSlowTest#testCleanupSlow test? I
anticipate that test would pass without your fix. Maybe, we should try more
definitive scenario:
- SlowFileIO close hangs on count down latch
- We start non-baseline node with non-empty LFS
- We check that join exchange completes successfully and cache.put() succeeds
when the latch is still not released
What do you think?
> Speed up cleanupRestoredCaches
> --
>
> Key: IGNITE-10344
> URL: https://issues.apache.org/jira/browse/IGNITE-10344
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> if (!cctx.kernalContext().clientNode() && !isLocalNodeInBaseline())
> { // Stop all recovered caches and groups.
> cctx.cache().onKernalStopCaches(true); cctx.cache().stopCaches(true);
> cctx.database().cleanupRestoredCaches(); // Set initial node started marker.
> cctx.database().nodeStart(null); }
> If we have 100 cache groups we spent a lot of time about 36sec to
> cleanupRestoredCaches().
> We need to speed up this phase and add metrics on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10344) Speed up cleanupRestoredCaches
[
https://issues.apache.org/jira/browse/IGNITE-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819593#comment-16819593
]
Ivan Rakov commented on IGNITE-10344:
-
[~Denis Chudov], some comments:
1. FilePageStoreManager: we usually place inner classes at the bottom.
2. FilePageStoreManager: let's mention which problem we are solving with
LongOperationAsyncExecutor in javadoc. Also, let's metion contract: next
developer should somehow find out that modifications of idxCacheStores should
be protected with async executor.
3. What exactly does CleanupRestoredCachesSlowTest#testCleanupSlow test? I
anticipate that test would pass without your fix. Maybe, we should try more
definitive scenario:
- SlowFileIO close hangs on count down latch
- We start non-baseline node with non-empty LFS
- We check that join exchange completes successfully and cache.put() succeeds
when the latch is still not released
What do you think?
> Speed up cleanupRestoredCaches
> --
>
> Key: IGNITE-10344
> URL: https://issues.apache.org/jira/browse/IGNITE-10344
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> if (!cctx.kernalContext().clientNode() && !isLocalNodeInBaseline())
> { // Stop all recovered caches and groups.
> cctx.cache().onKernalStopCaches(true); cctx.cache().stopCaches(true);
> cctx.database().cleanupRestoredCaches(); // Set initial node started marker.
> cctx.database().nodeStart(null); }
> If we have 100 cache groups we spent a lot of time about 36sec to
> cleanupRestoredCaches().
> We need to speed up this phase and add metrics on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10344) Speed up cleanupRestoredCaches
[
https://issues.apache.org/jira/browse/IGNITE-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-10344:
Comment: was deleted
(was: [~Denis Chudov], some comments:
1. FilePageStoreManager: we usually place inner classes at the bottom.
2. FilePageStoreManager: let's mention which problem we are solving with
LongOperationAsyncExecutor in javadoc. Also, let's metion contract: next
developer should somehow find out that modifications of idxCacheStores should
be protected with async executor.
3. What exactly does CleanupRestoredCachesSlowTest#testCleanupSlow test? I
anticipate that test would pass without your fix. Maybe, we should try more
definitive scenario:
- SlowFileIO close hangs on count down latch
- We start non-baseline node with non-empty LFS
- We check that join exchange completes successfully and cache.put() succeeds
when the latch is still not released
What do you think?)
> Speed up cleanupRestoredCaches
> --
>
> Key: IGNITE-10344
> URL: https://issues.apache.org/jira/browse/IGNITE-10344
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> if (!cctx.kernalContext().clientNode() && !isLocalNodeInBaseline())
> { // Stop all recovered caches and groups.
> cctx.cache().onKernalStopCaches(true); cctx.cache().stopCaches(true);
> cctx.database().cleanupRestoredCaches(); // Set initial node started marker.
> cctx.database().nodeStart(null); }
> If we have 100 cache groups we spent a lot of time about 36sec to
> cleanupRestoredCaches().
> We need to speed up this phase and add metrics on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8578) .NET: Add baseline auto-adjust parameters (definition, run-time change)
[
https://issues.apache.org/jira/browse/IGNITE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819405#comment-16819405
]
Ignite TC Bot commented on IGNITE-8578:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux Clang){color} [[tests 0 TIMEOUT , Exit Code
, Failure on metric |https://ci.ignite.apache.org/viewLog.html?buildId=3552958]]
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3552949]]
{color:#d04437}PDS (Indexing){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3552992]]
* IgnitePdsDiskErrorsRecoveringTest.testRecoveringOnWALWritingFail2 (last
started)
{color:#d04437}Queries 2{color} [[tests
11|https://ci.ignite.apache.org/viewLog.html?buildId=3552938]]
* IgniteBinaryCacheQueryTestSuite2: twostep.CacheQueryMemoryLeakTest
* IgniteBinaryCacheQueryTestSuite2: cache.QueryJoinWithDifferentNodeFiltersTest
* IgniteBinaryCacheQueryTestSuite2: twostep.NonCollocatedRetryMessageSelfTest
* IgniteBinaryCacheQueryTestSuite2: h2.CacheQueryEntityWithDateTimeApiFieldsTest
* IgniteBinaryCacheQueryTestSuite2:
twostep.DisappearedCacheCauseRetryMessageSelfTest
* IgniteBinaryCacheQueryTestSuite2: twostep.RetryCauseMessageSelfTest
* IgniteBinaryCacheQueryTestSuite2: twostep.TableViewSubquerySelfTest
* IgniteBinaryCacheQueryTestSuite2:
twostep.DisappearedCacheWasNotFoundMessageSelfTest
* IgniteBinaryCacheQueryTestSuite2:
query.IgniteCacheGroupsSqlSegmentedIndexSelfTest
* IgniteBinaryCacheQueryTestSuite2:
query.IgniteCacheGroupsSqlDistributedJoinSelfTest
* IgniteBinaryCacheQueryTestSuite2:
query.IgniteCacheGroupsSqlSegmentedIndexMultiNodeSelfTest
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3619229buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Add baseline auto-adjust parameters (definition, run-time change)
> ---
>
> Key: IGNITE-8578
> URL: https://issues.apache.org/jira/browse/IGNITE-8578
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Eduard Shangareev
>Assignee: Alexandr Shapkin
>Priority: Major
> Labels: .NET, IEP-4, Phase-2
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We would introduce at IGNITE-8571 new parameters.
> We need their support in .Net side.
> See new methods on IgniteCluster interface IGNITE-11509
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11761) Normalize encoding for Ignite .NET test file
[
https://issues.apache.org/jira/browse/IGNITE-11761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819406#comment-16819406
]
Ignite TC Bot commented on IGNITE-11761:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618825]]
{color:#d04437}Platform .NET{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618846]]
{color:#d04437}Cache (Restarts) 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618821]]
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618798]]
{color:#d04437}MVCC PDS 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618871]]
{color:#d04437}Platform C++ (Linux Clang){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618806]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618847]]
{color:#d04437}MVCC Cache 7{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618868]]
{color:#d04437}MVCC PDS 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618872]]
{color:#d04437}Platform .NET (Long Running){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618850]]
{color:#d04437}MVCC Cache{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618807]]
{color:#d04437}MVCC Queries{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618809]]
{color:#d04437}Cache (Expiry Policy){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618814]]
{color:#d04437}PDS (Compatibility){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618838]]
{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618857]]
{color:#d04437}Cache 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618826]]
{color:#d04437}MVCC PDS 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618874]]
{color:#d04437}SPI{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618791]]
{color:#d04437}Platform C++ (Linux)*{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618800]]
{color:#d04437}Scala (Visor Console){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618797]]
{color:#d04437}Cache 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618824]]
{color:#d04437}Cache (Restarts) 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618822]]
{color:#d04437}Cache 8{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618831]]
{color:#d04437}Queries 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618852]]
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618799]]
{color:#d04437}Cache 5{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618828]]
{color:#d04437}Streamers{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618789]]
{color:#d04437}PDS 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618843]]
{color:#d04437}PDS (Indexing){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618840]]
{color:#d04437}Cache 6{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618829]]
{color:#d04437}Basic 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618803]]
{color:#d04437}SPI (URI Deploy){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618792]]
{color:#d04437}Client Nodes{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618766]]
{color:#d04437}Data Structures{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618836]]
{color:#d04437}Start Nodes{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618790]]
{color:#d04437}PDS 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618842]]
{color:#d04437}Cache 7{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618830]]
{color:#d04437}MVCC PDS 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618873]]
{color:#d04437}MVCC Cache 5{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=3618866]]
{color:#d04437}Basic 3{color}
[jira] [Updated] (IGNITE-11761) Normalize encoding for Ignite .NET test file
[ https://issues.apache.org/jira/browse/IGNITE-11761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-11761: Fix Version/s: 2.8 > Normalize encoding for Ignite .NET test file > > > Key: IGNITE-11761 > URL: https://issues.apache.org/jira/browse/IGNITE-11761 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Alexandr Shapkin >Priority: Major > Fix For: 2.8 > > > It is encoded in UTF-16, but all other files are UTF-8 > Idea blocks me from changing encoding because of BOM exists. > https://stackoverflow.com/questions/32986445/remove-a-bom-character-in-a-file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11762) Test testClientStartCloseServersRestart causes hang of the whole Cache 2 suite in master
[
https://issues.apache.org/jira/browse/IGNITE-11762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-11762:
Description:
Attempt to restart server node in test hangs:
{code:java}
[2019-04-16 19:56:45,049][WARN ][restart-1][GridCachePartitionExchangeManager]
Failed to wait for initial partition map exchange. Possible reasons are:
^-- Transactions in deadlock.
^-- Long running transactions (ignore if this is the case).
^-- Unreleased explicit locks.
{code}
The reason is that previous PME (late affinity assignment) still hangs due to
pending transaction:
{code:java}
[2019-04-16 19:56:23,717][WARN
][exchange-worker-#1039%cache.IgniteClientCacheStartFailoverTest3%][diagnostic]
Pending transactions:
[2019-04-16 19:56:23,718][WARN
][exchange-worker-#1039%cache.IgniteClientCacheStartFailoverTest3%][diagnostic]
>>> [txVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], exchWait=true,
tx=GridDhtTxLocal [nearNodeId=8559bfe0-3d4a-4090-a457-6df0eba5,
nearFutId=1edc7172a61-941f9dde-2b60-4a1f-8213-7d23d738bf33, nearMiniId=1,
nearFinFutId=null, nearFinMiniId=0, nearXidVer=GridCacheVersion
[topVer=166913752, order=1555433759036, nodeOrder=6], lb=null,
super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=KeySetView
[], dhtNodes=KeySetView [9ef33532-0e4a-4561-b57e-042afe10],
explicitLock=false, super=IgniteTxLocalAdapter [completedBase=null,
sndTransformedVals=false, depEnabled=false, txState=IgniteTxStateImpl
[activeCacheIds=[-1062368467], recovery=false, mvccEnabled=true,
mvccCachingCacheIds=[], txMap=HashSet []], super=IgniteTxAdapter
[xidVer=GridCacheVersion [topVer=166913752, order=1555433759045, nodeOrder=10],
writeVer=null, implicit=false, loc=true, threadId=1210,
startTime=1555433762847, nodeId=0088e9b8-f859-4d14-8071-6388e473,
startVer=GridCacheVersion [topVer=166913752, order=1555433759045,
nodeOrder=10], endVer=null, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC,
timeout=0, sysInvalidate=false, sys=false, plc=2, commitVer=GridCacheVersion
[topVer=166913752, order=1555433759045, nodeOrder=10], finalizing=NONE,
invalidParts=null, state=MARKED_ROLLBACK, timedOut=false,
topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0],
mvccSnapshot=MvccSnapshotResponse [futId=292, crdVer=1555433741506, cntr=395,
opCntr=1, txs=[394], cleanupVer=390, tracking=0], skipCompletedVers=false,
parentTx=null, duration=20866ms, onePhaseCommit=false], size=0
{code}
However, load threads don't start any explicit transactions: they either hang
on put()/get() or on clientCache.close().
Rolling back IGNITE-10799 resolves the issue (however, test remains flaky with
~10% fail rate due to unhandled TransactionSerializationException).
was:
Attempt to restart server node in test hangs:
{code:java}
[2019-04-16 19:56:45,049][WARN ][restart-1][GridCachePartitionExchangeManager]
Failed to wait for initial partition map exchange. Possible reasons are:
^-- Transactions in deadlock.
^-- Long running transactions (ignore if this is the case).
^-- Unreleased explicit locks.
{code}
The reason is that previous PME (late affinity assignment) still hangs due to
pending transaction:
{code:java}
[2019-04-16 19:56:23,717][WARN
][exchange-worker-#1039%cache.IgniteClientCacheStartFailoverTest3%][diagnostic]
Pending transactions:
[2019-04-16 19:56:23,718][WARN
][exchange-worker-#1039%cache.IgniteClientCacheStartFailoverTest3%][diagnostic]
>>> [txVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], exchWait=true,
tx=GridDhtTxLocal [nearNodeId=8559bfe0-3d4a-4090-a457-6df0eba5,
nearFutId=1edc7172a61-941f9dde-2b60-4a1f-8213-7d23d738bf33, nearMiniId=1,
nearFinFutId=null, nearFinMiniId=0, nearXidVer=GridCacheVersion
[topVer=166913752, order=1555433759036, nodeOrder=6], lb=null,
super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=KeySetView
[], dhtNodes=KeySetView [9ef33532-0e4a-4561-b57e-042afe10],
explicitLock=false, super=IgniteTxLocalAdapter [completedBase=null,
sndTransformedVals=false, depEnabled=false, txState=IgniteTxStateImpl
[activeCacheIds=[-1062368467], recovery=false, mvccEnabled=true,
mvccCachingCacheIds=[], txMap=HashSet []], super=IgniteTxAdapter
[xidVer=GridCacheVersion [topVer=166913752, order=1555433759045, nodeOrder=10],
writeVer=null, implicit=false, loc=true, threadId=1210,
startTime=1555433762847, nodeId=0088e9b8-f859-4d14-8071-6388e473,
startVer=GridCacheVersion [topVer=166913752, order=1555433759045,
nodeOrder=10], endVer=null, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC,
timeout=0, sysInvalidate=false, sys=false, plc=2, commitVer=GridCacheVersion
[topVer=166913752, order=1555433759045, nodeOrder=10], finalizing=NONE,
invalidParts=null, state=MARKED_ROLLBACK, timedOut=false,
topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0],
mvccSnapshot=MvccSnapshotResponse [futId=292, crdVer=1555433741506,
[jira] [Created] (IGNITE-11762) Test testClientStartCloseServersRestart causes hang of the whole Cache 2 suite in master
Ivan Rakov created IGNITE-11762:
---
Summary: Test testClientStartCloseServersRestart causes hang of
the whole Cache 2 suite in master
Key: IGNITE-11762
URL: https://issues.apache.org/jira/browse/IGNITE-11762
Project: Ignite
Issue Type: Bug
Reporter: Ivan Rakov
Assignee: Pavel Kovalenko
Fix For: 2.8
Attempt to restart server node in test hangs:
{code:java}
[2019-04-16 19:56:45,049][WARN ][restart-1][GridCachePartitionExchangeManager]
Failed to wait for initial partition map exchange. Possible reasons are:
^-- Transactions in deadlock.
^-- Long running transactions (ignore if this is the case).
^-- Unreleased explicit locks.
{code}
The reason is that previous PME (late affinity assignment) still hangs due to
pending transaction:
{code:java}
[2019-04-16 19:56:23,717][WARN
][exchange-worker-#1039%cache.IgniteClientCacheStartFailoverTest3%][diagnostic]
Pending transactions:
[2019-04-16 19:56:23,718][WARN
][exchange-worker-#1039%cache.IgniteClientCacheStartFailoverTest3%][diagnostic]
>>> [txVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], exchWait=true,
tx=GridDhtTxLocal [nearNodeId=8559bfe0-3d4a-4090-a457-6df0eba5,
nearFutId=1edc7172a61-941f9dde-2b60-4a1f-8213-7d23d738bf33, nearMiniId=1,
nearFinFutId=null, nearFinMiniId=0, nearXidVer=GridCacheVersion
[topVer=166913752, order=1555433759036, nodeOrder=6], lb=null,
super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=KeySetView
[], dhtNodes=KeySetView [9ef33532-0e4a-4561-b57e-042afe10],
explicitLock=false, super=IgniteTxLocalAdapter [completedBase=null,
sndTransformedVals=false, depEnabled=false, txState=IgniteTxStateImpl
[activeCacheIds=[-1062368467], recovery=false, mvccEnabled=true,
mvccCachingCacheIds=[], txMap=HashSet []], super=IgniteTxAdapter
[xidVer=GridCacheVersion [topVer=166913752, order=1555433759045, nodeOrder=10],
writeVer=null, implicit=false, loc=true, threadId=1210,
startTime=1555433762847, nodeId=0088e9b8-f859-4d14-8071-6388e473,
startVer=GridCacheVersion [topVer=166913752, order=1555433759045,
nodeOrder=10], endVer=null, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC,
timeout=0, sysInvalidate=false, sys=false, plc=2, commitVer=GridCacheVersion
[topVer=166913752, order=1555433759045, nodeOrder=10], finalizing=NONE,
invalidParts=null, state=MARKED_ROLLBACK, timedOut=false,
topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0],
mvccSnapshot=MvccSnapshotResponse [futId=292, crdVer=1555433741506, cntr=395,
opCntr=1, txs=[394], cleanupVer=390, tracking=0], skipCompletedVers=false,
parentTx=null, duration=20866ms, onePhaseCommit=false], size=0
{code}
However, load threads don't start any explicit transactions: they either hang
on put()/get() or on clientCache.close().
Rolling back IGNITE-10799 resolves the issue (however, test remains flaky with
~10% fail rate due to unhandled TransactionSerializationException).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11456) Use separate pool for KILL QUERY command
[ https://issues.apache.org/jira/browse/IGNITE-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819257#comment-16819257 ] Yury Gerzhedovich commented on IGNITE-11456: Bot vise should be ok, Error in Scala not in scope the change, also the error reproduced on master > Use separate pool for KILL QUERY command > > > Key: IGNITE-11456 > URL: https://issues.apache.org/jira/browse/IGNITE-11456 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > As of now we use QUERY_POOL to process cancellation requests. It can lead to > unable to cancel a queries in case the pool will be overflowed. > So, need to use separate pool or MGMT pool + non-blocking processing through > futures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11456) Use separate pool for KILL QUERY command
[
https://issues.apache.org/jira/browse/IGNITE-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819255#comment-16819255
]
Ignite TC Bot commented on IGNITE-11456:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3616637]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3615322buildTypeId=IgniteTests24Java8_RunAll]
> Use separate pool for KILL QUERY command
>
>
> Key: IGNITE-11456
> URL: https://issues.apache.org/jira/browse/IGNITE-11456
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As of now we use QUERY_POOL to process cancellation requests. It can lead to
> unable to cancel a queries in case the pool will be overflowed.
> So, need to use separate pool or MGMT pool + non-blocking processing through
> futures.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11761) Normalize encoding for Ignite .NET test file
[ https://issues.apache.org/jira/browse/IGNITE-11761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin reassigned IGNITE-11761: - Assignee: Alexandr Shapkin > Normalize encoding for Ignite .NET test file > > > Key: IGNITE-11761 > URL: https://issues.apache.org/jira/browse/IGNITE-11761 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Alexandr Shapkin >Priority: Major > > It is encoded in UTF-16, but all other files are UTF-8 > Idea blocks me from changing encoding because of BOM exists. > https://stackoverflow.com/questions/32986445/remove-a-bom-character-in-a-file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11761) Normalize encoding for Ignite .NET test file
Dmitriy Pavlov created IGNITE-11761: --- Summary: Normalize encoding for Ignite .NET test file Key: IGNITE-11761 URL: https://issues.apache.org/jira/browse/IGNITE-11761 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov It is encoded in UTF-16, but all other files are UTF-8 Idea blocks me from changing encoding because of BOM exists. https://stackoverflow.com/questions/32986445/remove-a-bom-character-in-a-file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11488) GridServiceProcessorBatchDeploySelfTest test fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-11488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819244#comment-16819244
]
Ryker Zhang commented on IGNITE-11488:
--
Hi [~amashenkov],
Thanks for your reply. I split warning message into 2 parts and create a pull
request. If there is time, please help me to check if the code is correct.
> GridServiceProcessorBatchDeploySelfTest test fails sporadically
> ---
>
> Key: IGNITE-11488
> URL: https://issues.apache.org/jira/browse/IGNITE-11488
> Project: Ignite
> Issue Type: Test
> Components: managed services
>Reporter: Andrew Mashenkov
>Assignee: Ryker Zhang
>Priority: Major
> Labels: MakeTeamcityGreenAgain, newbie
> Time Spent: 10m
> Remaining Estimate: 0h
>
> GridServiceProcessorBatchDeploySelfTest.testCancelAllTopologyChange test
> fails on TC sporadically with ConcurrentModificationException.
> Let's add synchronization to certain toString method.
>
> {noformat}
> [super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
> o.a.i.IgniteException: null]]
> class org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1081)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:993)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:703)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:662)
> at
> org.apache.ignite.internal.processors.service.ServiceDeploymentTask.toString(ServiceDeploymentTask.java:854)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.service.ServiceDeploymentManager$ServicesDeploymentWorker.body(ServiceDeploymentManager.java:502)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
> at java.util.HashMap$EntryIterator.next(HashMap.java:1476)
> at java.util.HashMap$EntryIterator.next(HashMap.java:1474)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.addMap(GridToStringBuilder.java:923)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:846)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1065)
> ... 9 more{noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11760) [TC Bot] Support escaping or replacement of vertical dash in the suite name
[ https://issues.apache.org/jira/browse/IGNITE-11760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-11760: Ignite Flags: (was: Docs Required) > [TC Bot] Support escaping or replacement of vertical dash in the suite name > --- > > Key: IGNITE-11760 > URL: https://issues.apache.org/jira/browse/IGNITE-11760 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > > Usage of same special symbol in JIRA makes TC bot visa unreadable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11760) [TC Bot] Support escaping or replacement of vertical dash in the suite name
Dmitriy Pavlov created IGNITE-11760: --- Summary: [TC Bot] Support escaping or replacement of vertical dash in the suite name Key: IGNITE-11760 URL: https://issues.apache.org/jira/browse/IGNITE-11760 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov Usage of same special symbol in JIRA makes TC bot visa unreadable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-11755) Memory leak H2 connections at the ConnectionManager#detachedConns
[
https://issues.apache.org/jira/browse/IGNITE-11755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-11755:
---
Comment: was deleted
(was: [~tledkov-gridgain], please check my comment on github.)
> Memory leak H2 connections at the ConnectionManager#detachedConns
> -
>
> Key: IGNITE-11755
> URL: https://issues.apache.org/jira/browse/IGNITE-11755
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ConnectionManager#detachedConns}} leaks on mvcc transnational SELECT.
> Reproduce:
> 1. CREATE TABLE with enabled MVCC
> 2. Do SELECTs.
> 3. Each query is executed at the new JDBC thin connection. A connection is
> closed after query.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11726) SQL: must not store default precision and scale in the QueryEntity for CHAR/VARCHAR and DECIMAL types
[
https://issues.apache.org/jira/browse/IGNITE-11726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819173#comment-16819173
]
Yury Gerzhedovich commented on IGNITE-11726:
[~tledkov-gridgain], please check my comment on github.
> SQL: must not store default precision and scale in the QueryEntity for
> CHAR/VARCHAR and DECIMAL types
> -
>
> Key: IGNITE-11726
> URL: https://issues.apache.org/jira/browse/IGNITE-11726
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> If table is created by SQL query, e.g.:
> {{CREATE TABLE test (id INT, val_dec DECIMAL, val_char VARCHAR)}}
> and CHAR/VARCHAR and DECIMAL types are used with default precision (size for
> char/varchar) and scale the default precision and scale mustn't be passed
> into {{QueryEntity}} for created cache.
> This is cause of compatibility problems.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[
https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11434:
--
Fix Version/s: 2.8
> SQL: Create a view with list of existing COLUMNS
>
>
> Key: IGNITE-11434
> URL: https://issues.apache.org/jira/browse/IGNITE-11434
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Taras Ledkov
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Need to expose SQL system view with COLUMNS information.
> Need to investigate more deeper which of information should be there.
>
> As start point we can take
> [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
> Columns description:
> || Name || Type || Description||
> | SCHEMA_NAME | string | Schema name |
> | TABLE_NAME | string | Table name |
> | COLUMN_NAME | string | Column name |
> | ORDINAL_POSITION | int | Column ordinal. Starts with 1 |
> | DEFAULT VALUE | string | Defaut column's value |
> | IS_NULLABLE | boolean | Nullable flag corresponds to
> {{QueryEntity#setNotNullFields}} |
> | DATA_TYPE | string | SQL data type |
> | CHARACTER_LENGTH | int | Size for char CAHR and VARCHAR types |
> | NUMERIC_PRECISION | int | Precision for numeric types |
> | NUMERIC_SCALE | int | Scale for numeric types |
> | IS_AFFINITY_KEY | boolean | {{true}} whan the column is affinity key |
> | IS_HIDDEN | boolean | {{true}} for hidden _ley nad _val columns. {{false}}
> for all columns available by asterisk mask |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-11744) Configuration for explicit plugins providing.
[ https://issues.apache.org/jira/browse/IGNITE-11744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] PetrovMikhail resolved IGNITE-11744. Resolution: Won't Fix > Configuration for explicit plugins providing. > - > > Key: IGNITE-11744 > URL: https://issues.apache.org/jira/browse/IGNITE-11744 > Project: Ignite > Issue Type: Task >Reporter: PetrovMikhail >Assignee: PetrovMikhail >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11758) Python thin: a lot of documentation files without license header
[ https://issues.apache.org/jira/browse/IGNITE-11758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Melnichuk reassigned IGNITE-11758: - Assignee: Dmitry Melnichuk > Python thin: a lot of documentation files without license header > > > Key: IGNITE-11758 > URL: https://issues.apache.org/jira/browse/IGNITE-11758 > Project: Ignite > Issue Type: Bug > Components: documentation, thin client >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Dmitry Melnichuk >Priority: Major > Fix For: 2.8 > > > There are a lot of .rst documentation files in modules/platforms/python/docs/ > that does not contain license header. We need either delete them if they are > auto generated or add headers to them if they are not. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11277) Use maven plugin as default code style checker for project
[
https://issues.apache.org/jira/browse/IGNITE-11277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819134#comment-16819134
]
Maxim Muzafarov commented on IGNITE-11277:
--
[~DmitriyGovorukhin], [~daradurvs]
Folks, I've merged the latest changes from the master branch and re-run all
tests to check that everything works the right way. It seems to me that it is
so.
Will you have time to take a look?
> Use maven plugin as default code style checker for project
> --
>
> Key: IGNITE-11277
> URL: https://issues.apache.org/jira/browse/IGNITE-11277
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Currently, {{[Inspections] Core suite}} [1] on TC doesn't work well enough.
> The suite has a {{FAILED}} status for more than 2 months due to some issues
> on TeamCity application [2]. It confuses most of the members of the Apache
> Ignite community.
> Moreover, this suite is no longer checks configured rules. For instance, in
> the master branch, 11 {{Unused imports}} can be found (e.g. for
> {{IgniteCachePutAllRestartTest}
> [3]).
> I think the maven-checkstyle-plugin should be used as the default code style
> checker.
> _Advantages:_
> * An IDE agnostic way for code checks
> * Can be used with different CI and build tools
> * Executable from the command line
> * Single configuration
> [1]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> [2] https://youtrack.jetbrains.com/issue/TW-58504
> [3]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11755) Memory leak H2 connections at the ConnectionManager#detachedConns
[
https://issues.apache.org/jira/browse/IGNITE-11755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819135#comment-16819135
]
Yury Gerzhedovich edited comment on IGNITE-11755 at 4/16/19 3:08 PM:
-
[~tledkov-gridgain], please check my comment on github.
was (Author: jooger):
[~tledkov-gridgain], please check my comment on github.Visual
> Memory leak H2 connections at the ConnectionManager#detachedConns
> -
>
> Key: IGNITE-11755
> URL: https://issues.apache.org/jira/browse/IGNITE-11755
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ConnectionManager#detachedConns}} leaks on mvcc transnational SELECT.
> Reproduce:
> 1. CREATE TABLE with enabled MVCC
> 2. Do SELECTs.
> 3. Each query is executed at the new JDBC thin connection. A connection is
> closed after query.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11755) Memory leak H2 connections at the ConnectionManager#detachedConns
[
https://issues.apache.org/jira/browse/IGNITE-11755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819135#comment-16819135
]
Yury Gerzhedovich commented on IGNITE-11755:
[~tledkov-gridgain], please check my comment on github.Visual
> Memory leak H2 connections at the ConnectionManager#detachedConns
> -
>
> Key: IGNITE-11755
> URL: https://issues.apache.org/jira/browse/IGNITE-11755
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ConnectionManager#detachedConns}} leaks on mvcc transnational SELECT.
> Reproduce:
> 1. CREATE TABLE with enabled MVCC
> 2. Do SELECTs.
> 3. Each query is executed at the new JDBC thin connection. A connection is
> closed after query.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11277) Use maven plugin as default code style checker for project
[
https://issues.apache.org/jira/browse/IGNITE-11277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819132#comment-16819132
]
Ignite TC Bot commented on IGNITE-11277:
{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=3615564buildTypeId=IgniteTests24Java8_RunAll]
> Use maven plugin as default code style checker for project
> --
>
> Key: IGNITE-11277
> URL: https://issues.apache.org/jira/browse/IGNITE-11277
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Currently, {{[Inspections] Core suite}} [1] on TC doesn't work well enough.
> The suite has a {{FAILED}} status for more than 2 months due to some issues
> on TeamCity application [2]. It confuses most of the members of the Apache
> Ignite community.
> Moreover, this suite is no longer checks configured rules. For instance, in
> the master branch, 11 {{Unused imports}} can be found (e.g. for
> {{IgniteCachePutAllRestartTest}
> [3]).
> I think the maven-checkstyle-plugin should be used as the default code style
> checker.
> _Advantages:_
> * An IDE agnostic way for code checks
> * Can be used with different CI and build tools
> * Executable from the command line
> * Single configuration
> [1]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> [2] https://youtrack.jetbrains.com/issue/TW-58504
> [3]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819128#comment-16819128
]
Ivan Pavlukhin commented on IGNITE-11708:
-
[~ivanan.fed],
{quote}
May be add similar check that before/after JUnit methods also work, what do you
think?
{quote}
We can do it if it is simple. But I would not invest into that much if it is
not trivial.
Regarding multiple failures I think that it worth writing a message to dev-list
in order to make people aware of the subject. During discussion in community we
can develop a proper way to enable those tests safely.
> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
>
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep30
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It seems that test classes that extend from
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test
> annotation.
> It is easy to check: if throw exception in any test methods, nothing will
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1],
> maybe it destroys existing test workflow.
> [1]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11641) Server node copies a lot of WAL files in WAL archive after restart
[
https://issues.apache.org/jira/browse/IGNITE-11641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819122#comment-16819122
]
Dmitriy Govorukhin commented on IGNITE-11641:
-
Merged to master.
> Server node copies a lot of WAL files in WAL archive after restart
> --
>
> Key: IGNITE-11641
> URL: https://issues.apache.org/jira/browse/IGNITE-11641
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Pre-condition: PDS is enabled, wal_path and wal_archive_path are set in
> config file.
> 1. Cluster is up and running. Some data uploaded into caches.
> 2. Start load to generate a lot of files in wal archive (more than files in
> wal directory).
> 3. Stop some node and delete all files from wal archive.
> 4. Start node.
> In this case node copies WAL files from WAL dir into wal archive dir again
> and again until the amount of files will be the same it was in wal archive
> before stop.
> Here is information from server node log
> {code}
> 10:10:17,054][INFO][main][GridCacheDatabaseSharedManager] Restoring partition
> state for local groups.
> [10:10:18,522][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/.wal]
> [10:10:18,523][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=1, segIdx=1,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal]
> [10:10:20,631][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal]
> [10:10:20,632][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=2, segIdx=2,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal]
> [10:10:23,276][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal]
> [10:10:23,276][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=3, segIdx=3,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal]
> [10:10:23,995][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal]
> [10:10:23,996][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=4, segIdx=4,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal]
> [10:10:24,644][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal]
> [10:10:24,645][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=5, segIdx=5,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0005.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0005.wal]
> [10:10:25,301][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0005.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0005.wal]
>
[jira] [Commented] (IGNITE-11641) Server node copies a lot of WAL files in WAL archive after restart
[
https://issues.apache.org/jira/browse/IGNITE-11641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819105#comment-16819105
]
Dmitriy Govorukhin commented on IGNITE-11641:
-
[~mstepachev] Thanks for the review. I fixed your comments.
> Server node copies a lot of WAL files in WAL archive after restart
> --
>
> Key: IGNITE-11641
> URL: https://issues.apache.org/jira/browse/IGNITE-11641
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Pre-condition: PDS is enabled, wal_path and wal_archive_path are set in
> config file.
> 1. Cluster is up and running. Some data uploaded into caches.
> 2. Start load to generate a lot of files in wal archive (more than files in
> wal directory).
> 3. Stop some node and delete all files from wal archive.
> 4. Start node.
> In this case node copies WAL files from WAL dir into wal archive dir again
> and again until the amount of files will be the same it was in wal archive
> before stop.
> Here is information from server node log
> {code}
> 10:10:17,054][INFO][main][GridCacheDatabaseSharedManager] Restoring partition
> state for local groups.
> [10:10:18,522][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/.wal]
> [10:10:18,523][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=1, segIdx=1,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal]
> [10:10:20,631][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal]
> [10:10:20,632][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=2, segIdx=2,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal]
> [10:10:23,276][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal]
> [10:10:23,276][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=3, segIdx=3,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal]
> [10:10:23,995][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal]
> [10:10:23,996][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=4, segIdx=4,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal]
> [10:10:24,644][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal]
> [10:10:24,645][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=5, segIdx=5,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0005.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0005.wal]
> [10:10:25,301][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0005.wal,
>
>
[jira] [Commented] (IGNITE-11641) Server node copies a lot of WAL files in WAL archive after restart
[
https://issues.apache.org/jira/browse/IGNITE-11641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819103#comment-16819103
]
Dmitriy Govorukhin commented on IGNITE-11641:
-
This test suite flaky failed in master.
> Server node copies a lot of WAL files in WAL archive after restart
> --
>
> Key: IGNITE-11641
> URL: https://issues.apache.org/jira/browse/IGNITE-11641
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Pre-condition: PDS is enabled, wal_path and wal_archive_path are set in
> config file.
> 1. Cluster is up and running. Some data uploaded into caches.
> 2. Start load to generate a lot of files in wal archive (more than files in
> wal directory).
> 3. Stop some node and delete all files from wal archive.
> 4. Start node.
> In this case node copies WAL files from WAL dir into wal archive dir again
> and again until the amount of files will be the same it was in wal archive
> before stop.
> Here is information from server node log
> {code}
> 10:10:17,054][INFO][main][GridCacheDatabaseSharedManager] Restoring partition
> state for local groups.
> [10:10:18,522][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/.wal]
> [10:10:18,523][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=1, segIdx=1,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal]
> [10:10:20,631][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal]
> [10:10:20,632][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=2, segIdx=2,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal]
> [10:10:23,276][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal]
> [10:10:23,276][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=3, segIdx=3,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal]
> [10:10:23,995][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal]
> [10:10:23,996][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=4, segIdx=4,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal]
> [10:10:24,644][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal]
> [10:10:24,645][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=5, segIdx=5,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0005.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0005.wal]
> [10:10:25,301][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0005.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0005.wal]
>
[jira] [Commented] (IGNITE-11641) Server node copies a lot of WAL files in WAL archive after restart
[
https://issues.apache.org/jira/browse/IGNITE-11641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819101#comment-16819101
]
Ignite TC Bot commented on IGNITE-11641:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3616371]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3614923buildTypeId=IgniteTests24Java8_RunAll]
> Server node copies a lot of WAL files in WAL archive after restart
> --
>
> Key: IGNITE-11641
> URL: https://issues.apache.org/jira/browse/IGNITE-11641
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Pre-condition: PDS is enabled, wal_path and wal_archive_path are set in
> config file.
> 1. Cluster is up and running. Some data uploaded into caches.
> 2. Start load to generate a lot of files in wal archive (more than files in
> wal directory).
> 3. Stop some node and delete all files from wal archive.
> 4. Start node.
> In this case node copies WAL files from WAL dir into wal archive dir again
> and again until the amount of files will be the same it was in wal archive
> before stop.
> Here is information from server node log
> {code}
> 10:10:17,054][INFO][main][GridCacheDatabaseSharedManager] Restoring partition
> state for local groups.
> [10:10:18,522][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/.wal]
> [10:10:18,523][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=1, segIdx=1,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal]
> [10:10:20,631][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal]
> [10:10:20,632][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=2, segIdx=2,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal]
> [10:10:23,276][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal]
> [10:10:23,276][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=3, segIdx=3,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal]
> [10:10:23,995][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal]
> [10:10:23,996][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=4, segIdx=4,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal]
> [10:10:24,644][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal]
> [10:10:24,645][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=5, segIdx=5,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0005.wal,
>
>
[jira] [Assigned] (IGNITE-11759) [ML] Duplicate depenpecies for ml artifacts
[ https://issues.apache.org/jira/browse/IGNITE-11759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov reassigned IGNITE-11759: Assignee: Alexey Platonov > [ML] Duplicate depenpecies for ml artifacts > --- > > Key: IGNITE-11759 > URL: https://issues.apache.org/jira/browse/IGNITE-11759 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.7 >Reporter: Yury Babak >Assignee: Alexey Platonov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11734) IgniteCache.replace(k, v, nv) requires classes when element is null
[
https://issues.apache.org/jira/browse/IGNITE-11734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819092#comment-16819092
]
Ignite TC Bot commented on IGNITE-11734:
{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=3579706buildTypeId=IgniteTests24Java8_RunAll]
> IgniteCache.replace(k, v, nv) requires classes when element is null
> ---
>
> Key: IGNITE-11734
> URL: https://issues.apache.org/jira/browse/IGNITE-11734
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For example execute this code:
> {code}
> cache.replace(i, new Entity(), new Entity())
> {code}
> when cache have not a value by the key.
> {noformat}
> Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
> ClientP2P$Entity
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:709)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1756)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1715)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:791)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.value(GridCacheUtils.java:1328)
> at
> org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:70)
> at
> org.apache.ignite.internal.processors.cache.CacheEntryPredicateContainsValue.apply(CacheEntryPredicateContainsValue.java:33)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.isAllLocked(GridCacheContext.java:1322)
> ... 31 more
> Caused by: java.lang.ClassNotFoundException: ClientP2P$Entity
> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8643)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:374)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:700)
> ... 39 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11755) Memory leak H2 connections at the ConnectionManager#detachedConns
[
https://issues.apache.org/jira/browse/IGNITE-11755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819091#comment-16819091
]
Taras Ledkov commented on IGNITE-11755:
---
[~amashenkov], [~Pavlukhin], please review the patch.
> Memory leak H2 connections at the ConnectionManager#detachedConns
> -
>
> Key: IGNITE-11755
> URL: https://issues.apache.org/jira/browse/IGNITE-11755
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ConnectionManager#detachedConns}} leaks on mvcc transnational SELECT.
> Reproduce:
> 1. CREATE TABLE with enabled MVCC
> 2. Do SELECTs.
> 3. Each query is executed at the new JDBC thin connection. A connection is
> closed after query.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11755) Memory leak H2 connections at the ConnectionManager#detachedConns
[
https://issues.apache.org/jira/browse/IGNITE-11755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819089#comment-16819089
]
Ignite TC Bot commented on IGNITE-11755:
{panel:title=- Run :: SQL: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *- Run :: SQL*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3615577buildTypeId=IgniteTests24Java8_RunAllSql]
> Memory leak H2 connections at the ConnectionManager#detachedConns
> -
>
> Key: IGNITE-11755
> URL: https://issues.apache.org/jira/browse/IGNITE-11755
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ConnectionManager#detachedConns}} leaks on mvcc transnational SELECT.
> Reproduce:
> 1. CREATE TABLE with enabled MVCC
> 2. Do SELECTs.
> 3. Each query is executed at the new JDBC thin connection. A connection is
> closed after query.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11759) [ML] Duplicate depenpecies for ml artifacts
Yury Babak created IGNITE-11759: --- Summary: [ML] Duplicate depenpecies for ml artifacts Key: IGNITE-11759 URL: https://issues.apache.org/jira/browse/IGNITE-11759 Project: Ignite Issue Type: Improvement Components: ml Affects Versions: 2.7 Reporter: Yury Babak -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11759) [ML] Duplicate depenpecies for ml artifacts
[ https://issues.apache.org/jira/browse/IGNITE-11759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-11759: Ignite Flags: (was: Docs Required) > [ML] Duplicate depenpecies for ml artifacts > --- > > Key: IGNITE-11759 > URL: https://issues.apache.org/jira/browse/IGNITE-11759 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.7 >Reporter: Yury Babak >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11758) Python thin: a lot of documentation files without license header
Igor Sapego created IGNITE-11758: Summary: Python thin: a lot of documentation files without license header Key: IGNITE-11758 URL: https://issues.apache.org/jira/browse/IGNITE-11758 Project: Ignite Issue Type: Bug Components: documentation, thin client Affects Versions: 2.7 Reporter: Igor Sapego Fix For: 2.8 There are a lot of .rst documentation files in modules/platforms/python/docs/ that does not contain license header. We need either delete them if they are auto generated or add headers to them if they are not. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11544) Unclear behavior for cache operations using classes different from specified as indexed types
[ https://issues.apache.org/jira/browse/IGNITE-11544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818999#comment-16818999 ] Pavel Vinokurov commented on IGNITE-11544: -- [~zstan]The main issue is to throwing CorruptedTreeException by cache2.removeAll().Thus at least it's unable to perform removeAll() operation. > Unclear behavior for cache operations using classes different from specified > as indexed types > - > > Key: IGNITE-11544 > URL: https://issues.apache.org/jira/browse/IGNITE-11544 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 2.7 >Reporter: Pavel Vinokurov >Assignee: Igor Belyakov >Priority: Major > Attachments: IndexedTypesReproducer.java > > > There are a few cases presented in the attached reproducer where caches are > populated by objects of classes different from specified in > CacheConfiguration#setIndexedTypes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11757) Missed partitions during rebalancing when new blank node joins
Ilya Kasnacheev created IGNITE-11757: Summary: Missed partitions during rebalancing when new blank node joins Key: IGNITE-11757 URL: https://issues.apache.org/jira/browse/IGNITE-11757 Project: Ignite Issue Type: Bug Components: cache Reporter: Ilya Kasnacheev Assignee: Ivan Rakov Please take a look at newly added test GridCachePartitionedSupplyEventsSelfTest.testSupplyEvents There's logging of missed partitions during rebalancing, and as you can see partitions are missed even when a new node joins stable topology, with no nodes leaving. Expected behavior is that in this case no partitions will be missed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11745) Rebalancing overwhelmingly prefers some supplier nodes to others
[ https://issues.apache.org/jira/browse/IGNITE-11745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-11745: - Ignite Flags: Docs Required > Rebalancing overwhelmingly prefers some supplier nodes to others > > > Key: IGNITE-11745 > URL: https://issues.apache.org/jira/browse/IGNITE-11745 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > When cache has backups, and you add third node to cluster, Ignite will only > rebalance data from single node. > When you add n-th node, Ignite will not rebalance from some nodes and it will > pull 10x as much data from some nodes than from others. > This is because we filter static nodes list by partition availability and > then pick the first one. Overwhelmingly it is the first nodes in list and > nodes towards the end of list will never get to supply partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11698) Issue with P2P class loader
[
https://issues.apache.org/jira/browse/IGNITE-11698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818991#comment-16818991
]
Alexey Goncharuk commented on IGNITE-11698:
---
[~v.pyatkov] thanks, merged to master!
> Issue with P2P class loader
> ---
>
> Key: IGNITE-11698
> URL: https://issues.apache.org/jira/browse/IGNITE-11698
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Sometimes classes of remote query filter are incorrectly loaded.
> This happens because p2p context incorrectly matches
> {{CacheClassLoader#findClass}} with {{GridCacheDeploymentManager#p2pContext}}.
> {noformat}
> Exception in thread "main" javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Failed to execute query on node
> [query=GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN,
> clsName=null, clause=null, filter=CompositePredicate@7ba93755,
> transform=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=9223372036854775807, maxTime=0,
> sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024,
> timeout=0, incBackups=false, forceLocal=false, dedup=false, prj=null,
> keepBinary=false, subjId=f4870536-0f68-4e19-a87c-3862cbd30497, taskHash=0,
> mvccSnapshot=null, dataPageScanEnabled=null], rdc=null, trans=null],
> nodeId=40a03665-a203-4dc0-9a79-9aaede7a5dfa]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1318)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:168)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$5.onHasNext(GridCacheDistributedQueryManager.java:643)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.nextX(GridCloseableIteratorAdapter.java:38)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
> at
> org.apache.ignite.internal.processors.cache.AutoClosableCursorIterator.next(AutoClosableCursorIterator.java:59)
> at ClientP2P.query(ClientP2P.java:61)
> at ClientP2P.main(ClientP2P.java:45)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
> query on node [query=GridCacheQueryBean [qry=GridCacheQueryAdapter
> [type=SCAN, clsName=null, clause=null, filter=CompositePredicate@7ba93755,
> transform=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=9223372036854775807, maxTime=0,
> sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024,
> timeout=0, incBackups=false, forceLocal=false, dedup=false, prj=null,
> keepBinary=false, subjId=f4870536-0f68-4e19-a87c-3862cbd30497, taskHash=0,
> mvccSnapshot=null, dataPageScanEnabled=null], rdc=null, trans=null],
> nodeId=40a03665-a203-4dc0-9a79-9aaede7a5dfa]
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.onPage(GridCacheQueryFutureAdapter.java:384)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryResponse(GridCacheDistributedQueryManager.java:402)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.access$000(GridCacheDistributedQueryManager.java:64)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$1.apply(GridCacheDistributedQueryManager.java:94)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$1.apply(GridCacheDistributedQueryManager.java:92)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1126)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1691)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1561)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2753)
> at
>
[jira] [Commented] (IGNITE-11745) Rebalancing overwhelmingly prefers some supplier nodes to others
[ https://issues.apache.org/jira/browse/IGNITE-11745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818985#comment-16818985 ] Ilya Kasnacheev commented on IGNITE-11745: -- [~agoncharuk] please review proposed fix. We could truncate new events, etc, but they make spotting bugs like this one much easier. > Rebalancing overwhelmingly prefers some supplier nodes to others > > > Key: IGNITE-11745 > URL: https://issues.apache.org/jira/browse/IGNITE-11745 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > When cache has backups, and you add third node to cluster, Ignite will only > rebalance data from single node. > When you add n-th node, Ignite will not rebalance from some nodes and it will > pull 10x as much data from some nodes than from others. > This is because we filter static nodes list by partition availability and > then pick the first one. Overwhelmingly it is the first nodes in list and > nodes towards the end of list will never get to supply partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11745) Rebalancing overwhelmingly prefers some supplier nodes to others
[
https://issues.apache.org/jira/browse/IGNITE-11745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818982#comment-16818982
]
Ignite TC Bot commented on IGNITE-11745:
{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=3608384buildTypeId=IgniteTests24Java8_RunAll]
> Rebalancing overwhelmingly prefers some supplier nodes to others
>
>
> Key: IGNITE-11745
> URL: https://issues.apache.org/jira/browse/IGNITE-11745
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When cache has backups, and you add third node to cluster, Ignite will only
> rebalance data from single node.
> When you add n-th node, Ignite will not rebalance from some nodes and it will
> pull 10x as much data from some nodes than from others.
> This is because we filter static nodes list by partition availability and
> then pick the first one. Overwhelmingly it is the first nodes in list and
> nodes towards the end of list will never get to supply partitions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11756) SQL: implement a table row count statistics for the local queries
[
https://issues.apache.org/jira/browse/IGNITE-11756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov reassigned IGNITE-11756:
---
Assignee: Roman Kondakov
> SQL: implement a table row count statistics for the local queries
> -
>
> Key: IGNITE-11756
> URL: https://issues.apache.org/jira/browse/IGNITE-11756
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
>
> Row count statistics should help the H2 optimizer to select the better query
> execution plan. Currently the row count supplied to H2 engine is hardcoded
> value == 1 (see {{org.h2.index.Index#getRowCountApproximation}}). As a
> first step we can provide an actual table size in the case of local query. To
> prevent counting size on each invocation we can cache row count value and
> invalidate it in some cases:
> * Rebalancing
> * Multiple updates (after the initial loading)
> * On timeout (i.e. 1 minute)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11756) SQL: implement a table row count statistics for the local queries
Roman Kondakov created IGNITE-11756:
---
Summary: SQL: implement a table row count statistics for the local
queries
Key: IGNITE-11756
URL: https://issues.apache.org/jira/browse/IGNITE-11756
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Roman Kondakov
Row count statistics should help the H2 optimizer to select the better query
execution plan. Currently the row count supplied to H2 engine is hardcoded
value == 1 (see {{org.h2.index.Index#getRowCountApproximation}}). As a
first step we can provide an actual table size in the case of local query. To
prevent counting size on each invocation we can cache row count value and
invalidate it in some cases:
* Rebalancing
* Multiple updates (after the initial loading)
* On timeout (i.e. 1 minute)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11544) Unclear behavior for cache operations using classes different from specified as indexed types
[ https://issues.apache.org/jira/browse/IGNITE-11544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818976#comment-16818976 ] Stanilovsky Evgeny commented on IGNITE-11544: - what problem this ticket described for ? no Exception or some useful info attached here. > Unclear behavior for cache operations using classes different from specified > as indexed types > - > > Key: IGNITE-11544 > URL: https://issues.apache.org/jira/browse/IGNITE-11544 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 2.7 >Reporter: Pavel Vinokurov >Assignee: Igor Belyakov >Priority: Major > Attachments: IndexedTypesReproducer.java > > > There are a few cases presented in the attached reproducer where caches are > populated by objects of classes different from specified in > CacheConfiguration#setIndexedTypes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11748) Node.js thin: auto-generated documentation stored in Git
[ https://issues.apache.org/jira/browse/IGNITE-11748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-11748: Assignee: Igor Sapego > Node.js thin: auto-generated documentation stored in Git > > > Key: IGNITE-11748 > URL: https://issues.apache.org/jira/browse/IGNITE-11748 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.8 > > > Currently, auto-generated documentation is stored in git in > https://github.com/apache/ignite/tree/master/modules/platforms/nodejs/api_spec > Only conf.json file should be stored in git. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11748) Node.js thin: auto-generated documentation stored in Git
[ https://issues.apache.org/jira/browse/IGNITE-11748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-11748: - Description: Currently, auto-generated documentation is stored in git in https://github.com/apache/ignite/tree/master/modules/platforms/nodejs/api_spec Only conf.json file should be stored in git. was: Currently, auto-generated documentation is stored in git in https://github.com/apache/ignite/tree/master/modules/platforms/nodejs/api_spec Only conf.json file should be stored in git. Also, need to add Apache licence header to it. > Node.js thin: auto-generated documentation stored in Git > > > Key: IGNITE-11748 > URL: https://issues.apache.org/jira/browse/IGNITE-11748 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.7 >Reporter: Igor Sapego >Priority: Major > Fix For: 2.8 > > > Currently, auto-generated documentation is stored in git in > https://github.com/apache/ignite/tree/master/modules/platforms/nodejs/api_spec > Only conf.json file should be stored in git. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11699) Node can't start after forced shutdown if the wal archiver disabled
[
https://issues.apache.org/jira/browse/IGNITE-11699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-11699:
Assignee: Vyacheslav Koptilin
> Node can't start after forced shutdown if the wal archiver disabled
> ---
>
> Key: IGNITE-11699
> URL: https://issues.apache.org/jira/browse/IGNITE-11699
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
>Reporter: Pavel Vinokurov
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Attachments: disabled-wal-archive-reproducer.zip
>
>
> If a server node killed with the disabled wal archive, it could fail on start
> with following exception:
> {code:java}
> [18:37:53,887][SEVERE][sys-stripe-1-#2][G] Failed to execute runnable.
> java.lang.IllegalStateException: Failed to get page IO instance (page content
> is corrupted)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forVersion(IOVersions.java:85)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forPage(IOVersions.java:97)
> at
> org.apache.ignite.internal.pagemem.wal.record.delta.MetaPageUpdatePartitionDataRecord.applyDelta(MetaPageUpdatePartitionDataRecord.java:109)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyPageDelta(GridCacheDatabaseSharedManager.java:2532)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.lambda$performBinaryMemoryRestore$11(GridCacheDatabaseSharedManager.java:2327)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.lambda$stripedApplyPage$12(GridCacheDatabaseSharedManager.java:2441)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.lambda$stripedApply$13(GridCacheDatabaseSharedManager.java:2479)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:550)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> The reproducer is attached(works only on Linux).
> Steps to run the reproducer.
> 1. Copy config/server.xml into IGNITE_HOME/config folder;
> 2. Set IGNITE_HOME in the CorruptionReproducer class;
> 3. Launch CorruptionReproducer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11698) Issue with P2P class loader
[
https://issues.apache.org/jira/browse/IGNITE-11698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11698:
--
Fix Version/s: 2.8
> Issue with P2P class loader
> ---
>
> Key: IGNITE-11698
> URL: https://issues.apache.org/jira/browse/IGNITE-11698
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Sometimes classes of remote query filter are incorrectly loaded.
> This happens because p2p context incorrectly matches
> {{CacheClassLoader#findClass}} with {{GridCacheDeploymentManager#p2pContext}}.
> {noformat}
> Exception in thread "main" javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Failed to execute query on node
> [query=GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN,
> clsName=null, clause=null, filter=CompositePredicate@7ba93755,
> transform=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=9223372036854775807, maxTime=0,
> sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024,
> timeout=0, incBackups=false, forceLocal=false, dedup=false, prj=null,
> keepBinary=false, subjId=f4870536-0f68-4e19-a87c-3862cbd30497, taskHash=0,
> mvccSnapshot=null, dataPageScanEnabled=null], rdc=null, trans=null],
> nodeId=40a03665-a203-4dc0-9a79-9aaede7a5dfa]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1318)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:168)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$5.onHasNext(GridCacheDistributedQueryManager.java:643)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.nextX(GridCloseableIteratorAdapter.java:38)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
> at
> org.apache.ignite.internal.processors.cache.AutoClosableCursorIterator.next(AutoClosableCursorIterator.java:59)
> at ClientP2P.query(ClientP2P.java:61)
> at ClientP2P.main(ClientP2P.java:45)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
> query on node [query=GridCacheQueryBean [qry=GridCacheQueryAdapter
> [type=SCAN, clsName=null, clause=null, filter=CompositePredicate@7ba93755,
> transform=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=9223372036854775807, maxTime=0,
> sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024,
> timeout=0, incBackups=false, forceLocal=false, dedup=false, prj=null,
> keepBinary=false, subjId=f4870536-0f68-4e19-a87c-3862cbd30497, taskHash=0,
> mvccSnapshot=null, dataPageScanEnabled=null], rdc=null, trans=null],
> nodeId=40a03665-a203-4dc0-9a79-9aaede7a5dfa]
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.onPage(GridCacheQueryFutureAdapter.java:384)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryResponse(GridCacheDistributedQueryManager.java:402)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.access$000(GridCacheDistributedQueryManager.java:64)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$1.apply(GridCacheDistributedQueryManager.java:94)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$1.apply(GridCacheDistributedQueryManager.java:92)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1126)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1691)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1561)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2753)
> at
>
[jira] [Updated] (IGNITE-11698) Issue with P2P class loader
[
https://issues.apache.org/jira/browse/IGNITE-11698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11698:
--
Ignite Flags: (was: Docs Required)
> Issue with P2P class loader
> ---
>
> Key: IGNITE-11698
> URL: https://issues.apache.org/jira/browse/IGNITE-11698
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Sometimes classes of remote query filter are incorrectly loaded.
> This happens because p2p context incorrectly matches
> {{CacheClassLoader#findClass}} with {{GridCacheDeploymentManager#p2pContext}}.
> {noformat}
> Exception in thread "main" javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Failed to execute query on node
> [query=GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN,
> clsName=null, clause=null, filter=CompositePredicate@7ba93755,
> transform=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=9223372036854775807, maxTime=0,
> sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024,
> timeout=0, incBackups=false, forceLocal=false, dedup=false, prj=null,
> keepBinary=false, subjId=f4870536-0f68-4e19-a87c-3862cbd30497, taskHash=0,
> mvccSnapshot=null, dataPageScanEnabled=null], rdc=null, trans=null],
> nodeId=40a03665-a203-4dc0-9a79-9aaede7a5dfa]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1318)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:168)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$5.onHasNext(GridCacheDistributedQueryManager.java:643)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.nextX(GridCloseableIteratorAdapter.java:38)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
> at
> org.apache.ignite.internal.processors.cache.AutoClosableCursorIterator.next(AutoClosableCursorIterator.java:59)
> at ClientP2P.query(ClientP2P.java:61)
> at ClientP2P.main(ClientP2P.java:45)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
> query on node [query=GridCacheQueryBean [qry=GridCacheQueryAdapter
> [type=SCAN, clsName=null, clause=null, filter=CompositePredicate@7ba93755,
> transform=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=9223372036854775807, maxTime=0,
> sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024,
> timeout=0, incBackups=false, forceLocal=false, dedup=false, prj=null,
> keepBinary=false, subjId=f4870536-0f68-4e19-a87c-3862cbd30497, taskHash=0,
> mvccSnapshot=null, dataPageScanEnabled=null], rdc=null, trans=null],
> nodeId=40a03665-a203-4dc0-9a79-9aaede7a5dfa]
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.onPage(GridCacheQueryFutureAdapter.java:384)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryResponse(GridCacheDistributedQueryManager.java:402)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.access$000(GridCacheDistributedQueryManager.java:64)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$1.apply(GridCacheDistributedQueryManager.java:94)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$1.apply(GridCacheDistributedQueryManager.java:92)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1126)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1691)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1561)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2753)
> at
>
[jira] [Commented] (IGNITE-11470) Views don't show in Dbeaver
[
https://issues.apache.org/jira/browse/IGNITE-11470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818968#comment-16818968
]
Ignite TC Bot commented on IGNITE-11470:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3614606]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3614685buildTypeId=IgniteTests24Java8_RunAll]
> Views don't show in Dbeaver
> ---
>
> Key: IGNITE-11470
> URL: https://issues.apache.org/jira/browse/IGNITE-11470
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At Database navigator tab we can see no a views. As of now we should see at
> least SQL system views.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818759#comment-16818759
]
Ivan Fedotov edited comment on IGNITE-11708 at 4/16/19 12:26 PM:
-
[~Pavlukhin], I added test for check {{IgniteConfigVariationsAbstractTest}}
execution according to your suggestions. May be add similar check that
before/after JUnit methods also work, what do you think?
According to fix {{IgniteConfigVariationsAbstractTest}} rules workflow. I
decided to simplify code and remove outer rule and ruleChain from
{{IgniteConfigVariationsAbstractTest}} [1]. We can implement the same idea if
we just put {{testCfg}} initilization in {{beforeTestsStarted}}. Now all tests
work - you can try to start
{{InterceptorCacheConfigVariationsFullApiTestSuite}} [2] and see that methods
work indeed (it takes time unlike the master branch).
But now TeamCity bot shows us a lot of failures [3]. I tried to figure out and
it seems that failures are related to what tests check, but not JUnit error. I
mean that in master tests are green just because nothing happens, but indeed
tests can fail. I can not figure out in each test quickly, but in nutshell,
according to logs the failures are caused errors in tests functionality.
Moreover, 450 failures on 15_000 tests are just 3%, so it could be true.
[1] [https://github.com/apache/ignite/pull/6434/files]
[2]
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java]
[3]
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest]
was (Author: ivanan.fed):
[~Pavlukhin], I added test for check {{IgniteConfigVariationsAbstractTest}}
execution according to your suggestions. May be add similar check that
before/after JUnit methods also work, what do you think?
According to fix {{IgniteConfigVariationsAbstractTest}} rules workflow. I
decided to simplify code and remove outer rule and ruleChain from
{{IgniteConfigVariationsAbstractTest}} [1]. We can implement the same idea if
we just put {{testCfg}} initilization in {{beforeTestsStarted}}. Now all tests
work - you can try to start
{{InterceptorCacheConfigVariationsFullApiTestSuite}} [2] and see that methods
work indeed (it takes time unlike the master branch).
But now TeamCity bot shows us a lot of failures [3]. I tried to figure out and
it seems that failures are related to what tests check, but not JUnit error. I
mean that in master tests are green just because nothing happens, but indeed
tests can fail. I can not figure out in each tests quickly, but in nutshell,
according to logs the failures are caused errors in tests functionality.
Moreover, 450 failures on 15_000 tests are just 3%, so it could be true.
[1] [https://github.com/apache/ignite/pull/6434/files]
[2]
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java]
[3]
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest]
> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
>
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep30
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It seems that test classes that extend from
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test
> annotation.
> It is easy to check: if throw exception in any test methods, nothing will
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1],
> maybe it destroys existing test workflow.
> [1]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11504) [ML] Preprocessor trainers should support new feature-label extraction API
[ https://issues.apache.org/jira/browse/IGNITE-11504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818950#comment-16818950 ] Yury Babak commented on IGNITE-11504: - Reviewed, [~zaleslaw] please check examples compilation after IGNITE-11328, all other - LGTM > [ML] Preprocessor trainers should support new feature-label extraction API > -- > > Key: IGNITE-11504 > URL: https://issues.apache.org/jira/browse/IGNITE-11504 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Aleksey Zinoviev >Priority: Blocker > Labels: stability > Time Spent: 10m > Remaining Estimate: 0h > > Problem is same as feature extractors serialization bug. We should narrow our > API. (see parent task) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11328) Ignite binary build is too big
[
https://issues.apache.org/jira/browse/IGNITE-11328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11328:
--
Ignite Flags: (was: Docs Required)
> Ignite binary build is too big
> --
>
> Key: IGNITE-11328
> URL: https://issues.apache.org/jira/browse/IGNITE-11328
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Sergey Kozlov
>Assignee: Alexey Platonov
>Priority: Blocker
> Fix For: 2.7.5
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I built Apache Ignite and get zip file is ~ 800MB.
> +400MB added by 4 ML modules in {{libs/optional}}
> Looks like it should be redesigned (join in a single module and at least it
> will remove same deps)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11754) Memory leak on the GridCacheTxFinishSync#threadMap
[
https://issues.apache.org/jira/browse/IGNITE-11754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov reassigned IGNITE-11754:
-
Assignee: Taras Ledkov
> Memory leak on the GridCacheTxFinishSync#threadMap
> --
>
> Key: IGNITE-11754
> URL: https://issues.apache.org/jira/browse/IGNITE-11754
> Project: Ignite
> Issue Type: Bug
> Components: general, mvcc
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
>
> The {{GridCacheTxFinishSync#threadMap}} is not cleared when tx thread is
> terminated.
> So, memory leak happens when transactions are executed inside new
> start/stopped threads.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11751) Javadoc broken
[
https://issues.apache.org/jira/browse/IGNITE-11751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818873#comment-16818873
]
Dmitriy Pavlov commented on IGNITE-11751:
-
steps to reproduce:
{noformat}
mvn clean install -Pall-java,all-scala,licenses -DskipTests
mvn initialize -Pjavadoc
{noformat}
> Javadoc broken
> --
>
> Key: IGNITE-11751
> URL: https://issues.apache.org/jira/browse/IGNITE-11751
> Project: Ignite
> Issue Type: Task
>Reporter: Peter Ivanov
>Priority: Blocker
> Fix For: 2.8
>
>
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:aggregate (core-javadoc)
> on project apache-ignite: An error has occurred in Javadoc report generation:
> [ERROR] Exit code: 1 -
> ignite/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/serializer/package-info.java:21:
> warning: a package-info.java file has already been seen for package
> org.apache.ignite.cache.store.cassandra.serializer
> [ERROR] package org.apache.ignite.cache.store.cassandra.serializer;
> [ERROR]^
> [ERROR] javadoc: warning - Multiple sources of package comments found for
> package "org.apache.ignite.cache.store.cassandra.serializer"
> [ERROR] javadoc: error - Error - Exception java.lang.ClassNotFoundException
> thrown while trying to register Taglet
> org.apache.ignite.tools.javadoc.IgniteLinkTaglet...
> [ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
> warning - @ignitelink is an unknown tag.
> [ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
> warning - @ignitelink is an unknown tag.
> [ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
> warning - @ignitelink is an unknown tag.
> [ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java:828:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java:828:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStore.java:71:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStore.java:71:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/transactions/Transaction.java:120:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/transactions/Transaction.java:120:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/checkpoint/CheckpointSpi.java:60:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/checkpoint/CheckpointSpi.java:60:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java:233:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java:233:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/deployment/DeploymentSpi.java:61:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/deployment/DeploymentSpi.java:61:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/compute/gridify/GridifySetToSet.java:154:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/compute/gridify/GridifySetToSet.java:154:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/compute/gridify/GridifySetToValue.java:152:
> warning - @ignitelink is an unknown tag.
> [ERROR]
>
[jira] [Updated] (IGNITE-11755) Memory leak H2 connections at the ConnectionManager#detachedConns
[
https://issues.apache.org/jira/browse/IGNITE-11755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-11755:
--
Priority: Critical (was: Major)
> Memory leak H2 connections at the ConnectionManager#detachedConns
> -
>
> Key: IGNITE-11755
> URL: https://issues.apache.org/jira/browse/IGNITE-11755
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ConnectionManager#detachedConns}} leaks on mvcc transnational SELECT.
> Reproduce:
> 1. CREATE TABLE with enabled MVCC
> 2. Do SELECTs.
> 3. Each query is executed at the new JDBC thin connection. A connection is
> closed after query.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[
https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818814#comment-16818814
]
Taras Ledkov commented on IGNITE-11434:
---
[~Pavlukhin], [~jooger], [~amashenkov] please review the patch.
> SQL: Create a view with list of existing COLUMNS
>
>
> Key: IGNITE-11434
> URL: https://issues.apache.org/jira/browse/IGNITE-11434
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Taras Ledkov
>Priority: Major
> Labels: iep-29
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Need to expose SQL system view with COLUMNS information.
> Need to investigate more deeper which of information should be there.
>
> As start point we can take
> [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
> Columns description:
> || Name || Type || Description||
> | SCHEMA_NAME | string | Schema name |
> | TABLE_NAME | string | Table name |
> | COLUMN_NAME | string | Column name |
> | ORDINAL_POSITION | int | Column ordinal. Starts with 1 |
> | DEFAULT VALUE | string | Defaut column's value |
> | IS_NULLABLE | boolean | Nullable flag corresponds to
> {{QueryEntity#setNotNullFields}} |
> | DATA_TYPE | string | SQL data type |
> | CHARACTER_LENGTH | int | Size for char CAHR and VARCHAR types |
> | NUMERIC_PRECISION | int | Precision for numeric types |
> | NUMERIC_SCALE | int | Scale for numeric types |
> | IS_AFFINITY_KEY | boolean | {{true}} whan the column is affinity key |
> | IS_HIDDEN | boolean | {{true}} for hidden _ley nad _val columns. {{false}}
> for all columns available by asterisk mask |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11499) SQL: DML should not use batches by default
[
https://issues.apache.org/jira/browse/IGNITE-11499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818811#comment-16818811
]
Taras Ledkov commented on IGNITE-11499:
---
[~amashenkov], [~Pavlukhin] please review the patch.
> SQL: DML should not use batches by default
> --
>
> Key: IGNITE-11499
> URL: https://issues.apache.org/jira/browse/IGNITE-11499
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently DML apply updates in batches equal to {{SqlFieldsQuery.pageSize}}.
> This is prone to deadlocks. Instead, we should apply updates one-by-one by
> default. Proposal:
> # Introduce {{SqlFieldsQuery.updateBatchSize}} property, set it to {{1}} by
> default
> # Print a warning about deadlock to log if it is greater than 1
> # Add it to JDBC and ODBC drivers
> # Add it to other languages
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11726) SQL: must not store default precision and scale in the QueryEntity for CHAR/VARCHAR and DECIMAL types
[
https://issues.apache.org/jira/browse/IGNITE-11726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818810#comment-16818810
]
Taras Ledkov commented on IGNITE-11726:
---
[~amashenkov], [~jooger], [~Pavlukhin] please review the patch.
> SQL: must not store default precision and scale in the QueryEntity for
> CHAR/VARCHAR and DECIMAL types
> -
>
> Key: IGNITE-11726
> URL: https://issues.apache.org/jira/browse/IGNITE-11726
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If table is created by SQL query, e.g.:
> {{CREATE TABLE test (id INT, val_dec DECIMAL, val_char VARCHAR)}}
> and CHAR/VARCHAR and DECIMAL types are used with default precision (size for
> char/varchar) and scale the default precision and scale mustn't be passed
> into {{QueryEntity}} for created cache.
> This is cause of compatibility problems.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11726) SQL: must not store default precision and scale in the QueryEntity for CHAR/VARCHAR and DECIMAL types
[
https://issues.apache.org/jira/browse/IGNITE-11726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818808#comment-16818808
]
Ignite TC Bot commented on IGNITE-11726:
{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=3570536buildTypeId=IgniteTests24Java8_RunAll]
> SQL: must not store default precision and scale in the QueryEntity for
> CHAR/VARCHAR and DECIMAL types
> -
>
> Key: IGNITE-11726
> URL: https://issues.apache.org/jira/browse/IGNITE-11726
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If table is created by SQL query, e.g.:
> {{CREATE TABLE test (id INT, val_dec DECIMAL, val_char VARCHAR)}}
> and CHAR/VARCHAR and DECIMAL types are used with default precision (size for
> char/varchar) and scale the default precision and scale mustn't be passed
> into {{QueryEntity}} for created cache.
> This is cause of compatibility problems.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11755) Memory leak H2 connections at the ConnectionManager#detachedConns
Taras Ledkov created IGNITE-11755:
-
Summary: Memory leak H2 connections at the
ConnectionManager#detachedConns
Key: IGNITE-11755
URL: https://issues.apache.org/jira/browse/IGNITE-11755
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.7
Reporter: Taras Ledkov
Assignee: Taras Ledkov
Fix For: 2.8
{{ConnectionManager#detachedConns}} leaks on mvcc transnational SELECT.
Reproduce:
1. CREATE TABLE with enabled MVCC
2. Do SELECTs.
3. Each query is executed at the new JDBC thin connection. A connection is
closed after query.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11754) Memory leak on the GridCacheTxFinishSync#threadMap
Taras Ledkov created IGNITE-11754:
-
Summary: Memory leak on the GridCacheTxFinishSync#threadMap
Key: IGNITE-11754
URL: https://issues.apache.org/jira/browse/IGNITE-11754
Project: Ignite
Issue Type: Bug
Components: general, mvcc
Affects Versions: 2.7
Reporter: Taras Ledkov
Fix For: 2.8
The {{GridCacheTxFinishSync#threadMap}} is not cleared when tx thread is
terminated.
So, memory leak happens when transactions are executed inside new start/stopped
threads.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11753) control.sh improve error message in case of connection to secured cluster without credentials.
Sergey Antonov created IGNITE-11753:
---
Summary: control.sh improve error message in case of connection to
secured cluster without credentials.
Key: IGNITE-11753
URL: https://issues.apache.org/jira/browse/IGNITE-11753
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
If control.sh tries to connect to secured cluster without login/password now we
got:
{noformat}
./control.sh --state
Failed to get cluster state.
Authentication error, try connection again.
user:
{noformat}
We should print info about attempt to connect to secured cluster and request
login/password if it isn't set. I.e.
{noformat}
./control.sh --state
Failed to get cluster state.
Cluster required authentication.
user:
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818759#comment-16818759
]
Ivan Fedotov edited comment on IGNITE-11708 at 4/16/19 8:23 AM:
[~Pavlukhin], I added test for check {{IgniteConfigVariationsAbstractTest}}
execution according to your suggestions. May be add similar check that
before/after JUnit methods also work, what do you think?
According to fix {{IgniteConfigVariationsAbstractTest}} rules workflow. I
decided to simplify code and remove outer rule and ruleChain from
{{IgniteConfigVariationsAbstractTest}} [1]. We can implement the same idea if
we just put {{testCfg}} initilization in {{beforeTestsStarted}}. Now all tests
work - you can try to start
{{InterceptorCacheConfigVariationsFullApiTestSuite}} [2] and see that methods
work indeed (it takes time unlike the master branch).
But now TeamCity bot shows us a lot of failures [3]. I tried to figure out and
it seems that failures are related to what tests check, but not JUnit error. I
mean that in master tests are green just because nothing happens, but indeed
tests can fail. I can not figure out in each tests quickly, but in nutshell,
according to logs the failures are caused errors in tests functionality.
Moreover, 450 failures on 15_000 tests are just 3%, so it could be true.
[1] [https://github.com/apache/ignite/pull/6434/files]
[2]
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java]
[3]
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest]
was (Author: ivanan.fed):
[~Pavlukhin], I added test for check {{IgniteConfigVariationsAbstractTest}}
execution according to your suggestions. May be add similar check that
before/after JUnit methods also work, what do you think?
According to fix {{IgniteConfigVariationsAbstractTest}} rules workflow. I
decided to simplify code and remove outer rule and ruleChain from
{{IgniteConfigVariationsAbstractTest}} [1]. We can implement the same idea if
we just put {{testCfg}} initilization in {{beforeTestsStarted}}. Now all tests
work - you can try to start
{{InterceptorCacheConfigVariationsFullApiTestSuite}} [2] and see that methods
work indeed (it takes time unlike the master branch).
But now TeamCity bot shows us a lot of failures [3]. I tried to figure out and
it seems that failures are related to what tests check, but not JUnit error. I
mean that in master tests are green just because nothing happens, but indeed
tests can fail. I can not figure out in each tests quickly, but in nutshell,
according to logs the failures are caused errors in tests functionality.
Moreover, 300 failures on 15_000 tests are just 2%, so it could be true.
[1] https://github.com/apache/ignite/pull/6434
[2]
https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java
[3]
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest
> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
>
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep30
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It seems that test classes that extend from
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test
> annotation.
> It is easy to check: if throw exception in any test methods, nothing will
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1],
> maybe it destroys existing test workflow.
> [1]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11745) Rebalancing overwhelmingly prefers some supplier nodes to others
[
https://issues.apache.org/jira/browse/IGNITE-11745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818760#comment-16818760
]
Ignite TC Bot commented on IGNITE-11745:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3608333]]
* IgniteClientCacheStartFailoverTest.testClientStartCloseServersRestart (last
started)
{color:#d04437}Cache 6{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3608337]]
* ClientFastReplyCoordinatorFailureTest.testClientFastReply (last started)
{color:#d04437}MVCC Cache 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3608371]]
* IgniteCacheMvccTestSuite2:
IgniteCacheEntryProcessorNodeJoinTest.testEntryProcessorNodeLeave - 0,0% fails
in last 146 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3608384buildTypeId=IgniteTests24Java8_RunAll]
> Rebalancing overwhelmingly prefers some supplier nodes to others
>
>
> Key: IGNITE-11745
> URL: https://issues.apache.org/jira/browse/IGNITE-11745
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When cache has backups, and you add third node to cluster, Ignite will only
> rebalance data from single node.
> When you add n-th node, Ignite will not rebalance from some nodes and it will
> pull 10x as much data from some nodes than from others.
> This is because we filter static nodes list by partition availability and
> then pick the first one. Overwhelmingly it is the first nodes in list and
> nodes towards the end of list will never get to supply partitions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818759#comment-16818759
]
Ivan Fedotov commented on IGNITE-11708:
---
[~Pavlukhin], I added test for check {{IgniteConfigVariationsAbstractTest}}
execution according to your suggestions. May be add similar check that
before/after JUnit methods also work, what do you think?
According to fix {{IgniteConfigVariationsAbstractTest}} rules workflow. I
decided to simplify code and remove outer rule and ruleChain from
{{IgniteConfigVariationsAbstractTest}} [1]. We can implement the same idea if
we just put {{testCfg}} initilization in {{beforeTestsStarted}}. Now all tests
work - you can try to start
{{InterceptorCacheConfigVariationsFullApiTestSuite}} [2] and see that methods
work indeed (it takes time unlike the master branch).
But now TeamCity bot shows us a lot of failures [3]. I tried to figure out and
it seems that failures are related to what tests check, but not JUnit error. I
mean that in master tests are green just because nothing happens, but indeed
tests can fail. I can not figure out in each tests quickly, but in nutshell,
according to logs the failures are caused errors in tests functionality.
Moreover, 300 failures on 15_000 tests are just 2%, so it could be true.
[1] https://github.com/apache/ignite/pull/6434
[2]
https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java
[3]
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest
> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
>
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep30
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It seems that test classes that extend from
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test
> annotation.
> It is easy to check: if throw exception in any test methods, nothing will
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1],
> maybe it destroys existing test workflow.
> [1]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11752) Refactor usages of "System.getenv(key)" to IgniteSystemProperties.getString(key)
Alexey Kuznetsov created IGNITE-11752: - Summary: Refactor usages of "System.getenv(key)" to IgniteSystemProperties.getString(key) Key: IGNITE-11752 URL: https://issues.apache.org/jira/browse/IGNITE-11752 Project: Ignite Issue Type: Improvement Components: general Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov IgniteSystemProperties.getString(key) implemented as: 1. Try to get property from System.properties. 2. If not found - try to get from System.getenv In Java you could easily override System.properties from code, for testing purposes, for example, but it is almost impossible to do the same for environment variables. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10847) Web console: failed to download the mongodb on Ubuntu 18.04
[
https://issues.apache.org/jira/browse/IGNITE-10847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818748#comment-16818748
]
Vasiliy Sisko commented on IGNITE-10847:
Failed to run backend tests:
{code:java}
fireUp# ERROR Loading the module through
require('/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/test/app/mockgoose.js')
failed: Cannot find module 'mockgoose'
Error: Cannot find module 'mockgoose'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:581:15)
at Function.Module._load (internal/modules/cjs/loader.js:507:25)
at Module.require (internal/modules/cjs/loader.js:637:17)
at require (internal/modules/cjs/helpers.js:22:18)
at Object.
(/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/test/app/mockgoose.js:21:19)
at Module._compile (internal/modules/cjs/loader.js:689:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
at Module.load (internal/modules/cjs/loader.js:599:32)
at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
at Function.Module._load (internal/modules/cjs/loader.js:530:3)
at Module.require (internal/modules/cjs/loader.js:637:17)
at require (internal/modules/cjs/helpers.js:22:18)
at registerModulesFromPaths
(/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/node_modules/fire-up/lib/core/loader.js:63:18)
at Object.registerModules
(/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/node_modules/fire-up/lib/core/loader.js:24:5)
at Object.createNewInjector
(/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/node_modules/fire-up/lib/core/core.js:70:18)
at Object.newInjector
(/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/node_modules/fire-up/lib/index.js:9:17)
at Object.
(/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/test/injector.js:21:25)
at Module._compile (internal/modules/cjs/loader.js:689:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
at Module.load (internal/modules/cjs/loader.js:599:32)
at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
at Function.Module._load (internal/modules/cjs/loader.js:530:3)
at Module.require (internal/modules/cjs/loader.js:637:17)
at require (internal/modules/cjs/helpers.js:22:18)
at Object.
(/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/test/unit/ActivitiesService.test.js:19:18)
at Module._compile (internal/modules/cjs/loader.js:689:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
at Module.load (internal/modules/cjs/loader.js:599:32)
{ err:
{ ModuleLoadingError: Loading the module through
require('/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/test/app/mockgoose.js')
failed: Cannot find module 'mockgoose'
at new ModuleLoadingError
(/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/node_modules/fire-up/lib/definitions/errors.js:25:9)
at registerModulesFromPaths
(/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/node_modules/fire-up/lib/core/loader.js:69:26)
at Object.registerModules
(/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/node_modules/fire-up/lib/core/loader.js:24:5)
at Object.createNewInjector
(/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/node_modules/fire-up/lib/core/core.js:70:18)
at Object.newInjector
(/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/node_modules/fire-up/lib/index.js:9:17)
at Object.
(/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/test/injector.js:21:25)
at Module._compile (internal/modules/cjs/loader.js:689:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
at Module.load (internal/modules/cjs/loader.js:599:32)
at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
at Function.Module._load (internal/modules/cjs/loader.js:530:3)
at Module.require (internal/modules/cjs/loader.js:637:17)
at require (internal/modules/cjs/helpers.js:22:18)
at Object.
(/home/vsisko/gridgain/incubator-ignite/modules/web-console/backend/test/unit/ActivitiesService.test.js:19:18)
at Module._compile (internal/modules/cjs/loader.js:689:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
at Module.load (internal/modules/cjs/loader.js:599:32)
at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
at Function.Module._load (internal/modules/cjs/loader.js:530:3)
at Module.require (internal/modules/cjs/loader.js:637:17)
at require (internal/modules/cjs/helpers.js:22:18)
at
[jira] [Updated] (IGNITE-11504) [ML] Preprocessor trainers should support new feature-label extraction API
[ https://issues.apache.org/jira/browse/IGNITE-11504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-11504: -- Priority: Blocker (was: Major) > [ML] Preprocessor trainers should support new feature-label extraction API > -- > > Key: IGNITE-11504 > URL: https://issues.apache.org/jira/browse/IGNITE-11504 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Aleksey Zinoviev >Priority: Blocker > Labels: stability > Time Spent: 10m > Remaining Estimate: 0h > > Problem is same as feature extractors serialization bug. We should narrow our > API. (see parent task) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11750) Implement locked pages info dump for long-running B+Tree operations
[
https://issues.apache.org/jira/browse/IGNITE-11750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11750:
--
Summary: Implement locked pages info dump for long-running B+Tree
operations (was: Implement locked pages info for long-running B+Tree
operations)
> Implement locked pages info dump for long-running B+Tree operations
> ---
>
> Key: IGNITE-11750
> URL: https://issues.apache.org/jira/browse/IGNITE-11750
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
>
> I've stumbled upon an incident where a batch of Ignite threads were hanging
> on BPlusTree operations trying to acquire read or write lock on pages. From
> the thread dump it is impossible to check if there is an issue with
> {{OffheapReadWriteLock}} or there is a subtle deadlock in the tree.
> I suggest we implement a timeout for page lock acquire and tracking of locked
> pages. This should be relatively easy to implement in {{PageHandler}} (the
> only thing to consider is performance degradation). If a timeout occurs, we
> should print all the locks currently owned by a thread. This way we should be
> able to determine if there is a deadlock in the {{BPlusTree}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11751) Javadoc broken
Peter Ivanov created IGNITE-11751:
-
Summary: Javadoc broken
Key: IGNITE-11751
URL: https://issues.apache.org/jira/browse/IGNITE-11751
Project: Ignite
Issue Type: Task
Reporter: Peter Ivanov
Fix For: 2.8
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:aggregate (core-javadoc) on
project apache-ignite: An error has occurred in Javadoc report generation:
[ERROR] Exit code: 1 -
ignite/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/serializer/package-info.java:21:
warning: a package-info.java file has already been seen for package
org.apache.ignite.cache.store.cassandra.serializer
[ERROR] package org.apache.ignite.cache.store.cassandra.serializer;
[ERROR]^
[ERROR] javadoc: warning - Multiple sources of package comments found for
package "org.apache.ignite.cache.store.cassandra.serializer"
[ERROR] javadoc: error - Error - Exception java.lang.ClassNotFoundException
thrown while trying to register Taglet
org.apache.ignite.tools.javadoc.IgniteLinkTaglet...
[ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
warning - @ignitelink is an unknown tag.
[ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
warning - @ignitelink is an unknown tag.
[ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
warning - @ignitelink is an unknown tag.
[ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java:828:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java:828:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStore.java:71:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStore.java:71:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/transactions/Transaction.java:120:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/transactions/Transaction.java:120:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/spi/checkpoint/CheckpointSpi.java:60:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/spi/checkpoint/CheckpointSpi.java:60:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java:233:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java:233:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/spi/deployment/DeploymentSpi.java:61:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/spi/deployment/DeploymentSpi.java:61:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/compute/gridify/GridifySetToSet.java:154:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/compute/gridify/GridifySetToSet.java:154:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/compute/gridify/GridifySetToValue.java:152:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/core/src/main/java/org/apache/ignite/compute/gridify/GridifySetToValue.java:152:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/spring/src/main/java/org/apache/ignite/cache/spring/SpringCacheManager.java:145:
warning - @ignitelink is an unknown tag.
[ERROR]
ignite/modules/spring/src/main/java/org/apache/ignite/cache/spring/SpringCacheManager.java:145:
warning - @ignitelink is an unknown tag.
[ERROR]
[jira] [Updated] (IGNITE-11749) Implement automatic pages history dump on CorruptedTreeException
[
https://issues.apache.org/jira/browse/IGNITE-11749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11749:
--
Ignite Flags: (was: Docs Required)
> Implement automatic pages history dump on CorruptedTreeException
>
>
> Key: IGNITE-11749
> URL: https://issues.apache.org/jira/browse/IGNITE-11749
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
>
> Currently, the only way to debug possible bugs in checkpointer/recovery
> mechanics is to manually parse WAL files after the corruption happened. This
> is not practical for several reasons. First, it requires manual actions which
> depend on the content of the exception. Second, it is not always possible to
> obtain WAL files (it may contain sensitive data).
> We need to add a mechanics which will dump all information required for
> primary analysis of the corruption to the exception handler. For example, if
> an exception happened when materializing a link {{0xabcd}} written on an
> index page {{0xdcba}}, we need to dump history of both pages changes,
> checkpoint records on the analysis interval. Possibly, we should include
> FreeList pages to which the aforementioned pages were included to.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11750) Implement locked pages info for long-running B+Tree operations
[
https://issues.apache.org/jira/browse/IGNITE-11750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11750:
--
Ignite Flags: (was: Docs Required)
> Implement locked pages info for long-running B+Tree operations
> --
>
> Key: IGNITE-11750
> URL: https://issues.apache.org/jira/browse/IGNITE-11750
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
>
> I've stumbled upon an incident where a batch of Ignite threads were hanging
> on BPlusTree operations trying to acquire read or write lock on pages. From
> the thread dump it is impossible to check if there is an issue with
> {{OffheapReadWriteLock}} or there is a subtle deadlock in the tree.
> I suggest we implement a timeout for page lock acquire and tracking of locked
> pages. This should be relatively easy to implement in {{PageHandler}} (the
> only thing to consider is performance degradation). If a timeout occurs, we
> should print all the locks currently owned by a thread. This way we should be
> able to determine if there is a deadlock in the {{BPlusTree}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11750) Implement locked pages info for long-running B+Tree operations
Alexey Goncharuk created IGNITE-11750:
-
Summary: Implement locked pages info for long-running B+Tree
operations
Key: IGNITE-11750
URL: https://issues.apache.org/jira/browse/IGNITE-11750
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Goncharuk
I've stumbled upon an incident where a batch of Ignite threads were hanging on
BPlusTree operations trying to acquire read or write lock on pages. From the
thread dump it is impossible to check if there is an issue with
{{OffheapReadWriteLock}} or there is a subtle deadlock in the tree.
I suggest we implement a timeout for page lock acquire and tracking of locked
pages. This should be relatively easy to implement in {{PageHandler}} (the only
thing to consider is performance degradation). If a timeout occurs, we should
print all the locks currently owned by a thread. This way we should be able to
determine if there is a deadlock in the {{BPlusTree}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11749) Implement automatic pages history dump on CorruptedTreeException
Alexey Goncharuk created IGNITE-11749:
-
Summary: Implement automatic pages history dump on
CorruptedTreeException
Key: IGNITE-11749
URL: https://issues.apache.org/jira/browse/IGNITE-11749
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Goncharuk
Currently, the only way to debug possible bugs in checkpointer/recovery
mechanics is to manually parse WAL files after the corruption happened. This is
not practical for several reasons. First, it requires manual actions which
depend on the content of the exception. Second, it is not always possible to
obtain WAL files (it may contain sensitive data).
We need to add a mechanics which will dump all information required for primary
analysis of the corruption to the exception handler. For example, if an
exception happened when materializing a link {{0xabcd}} written on an index
page {{0xdcba}}, we need to dump history of both pages changes, checkpoint
records on the analysis interval. Possibly, we should include FreeList pages to
which the aforementioned pages were included to.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
