[jira] [Commented] (IGNITE-11512) Add counter left partition for index rebuild in CacheGroupMetricsMXBean
[
https://issues.apache.org/jira/browse/IGNITE-11512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805413#comment-16805413
]
Ignite TC Bot commented on IGNITE-11512:
{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=3446980buildTypeId=IgniteTests24Java8_RunAll]
> Add counter left partition for index rebuild in CacheGroupMetricsMXBean
> ---
>
> Key: IGNITE-11512
> URL: https://issues.apache.org/jira/browse/IGNITE-11512
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.7
>Reporter: Alexand Polyakov
>Assignee: Alexand Polyakov
>Priority: Major
>
> Now, if ran rebuild indexes, this can determined only on load CPU and thread
> dump. The presence of the "how many partitions left to index" metric will
> help determine whether the rebuilding is going on and on which cache, as well
> as the percentage of completion.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11629) Cassandra dependencies missing from deliverable
[
https://issues.apache.org/jira/browse/IGNITE-11629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805407#comment-16805407
]
Ignite TC Bot commented on IGNITE-11629:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Thin client: Python{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3456407]]
{color:#d04437}PDS 4{color} [[tests 0 TIMEOUT , Exit Code , [Artifacts
publishing failed] |https://ci.ignite.apache.org/viewLog.html?buildId=3456399]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3456430buildTypeId=IgniteTests24Java8_RunAll]
> Cassandra dependencies missing from deliverable
> ---
>
> Key: IGNITE-11629
> URL: https://issues.apache.org/jira/browse/IGNITE-11629
> Project: Ignite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: easyfix
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After IGNITE-9046 we lack an explicit netty-resolver dependency for
> ignite-cassandra-store module. This means that tests still run, project can
> be made working by fixing dependencies, but apache-ignite-bin deliverable's
> libs/optional/ignite-cassandra-store does not contain all required
> depencencies since we only put explicit ones there.
> Need to add this dependency explicitly, check that it works.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805298#comment-16805298
]
Ignite TC Bot commented on IGNITE-10663:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests 0 Exit Code , Compilation Error
|https://ci.ignite.apache.org/viewLog.html?buildId=3455486]]
{color:#d04437}Platform .NET (Long Running){color} [[tests 0 Exit Code ,
Compilation Error |https://ci.ignite.apache.org/viewLog.html?buildId=3455340]]
{color:#d04437}MVCC Queries{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3455299]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code ,
TC_SERVICE_MESSAGE |https://ci.ignite.apache.org/viewLog.html?buildId=3455337]]
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3455346]]
{color:#d04437}Thin client: PHP{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3455300]]
{color:#d04437}Thin client: Node.js{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3455292]]
{color:#d04437}Platform .NET (Integrations){color} [[tests 0 Exit Code ,
Compilation Error |https://ci.ignite.apache.org/viewLog.html?buildId=3455339]]
{color:#d04437}Thin client: Python{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3455343]]
{color:#d04437}Platform .NET (NuGet)*{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3455341]]
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Exit Code ,
Compilation Error , Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=3455338]]
{color:#d04437}MVCC PDS 2{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=3455362]]
* IgnitePdsMvccTestSuite2:
LocalWalModeChangeDuringRebalancingSelfTest.testWalNotDisabledIfParameterSetToFalse
- 0,0% fails in last 353 master runs.
{color:#d04437}Queries 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3455342]]
* IgniteBinaryCacheQueryTestSuite:
IndexingCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodesWithDelay[ATOMIC]
- 0,0% fails in last 171 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3455366buildTypeId=IgniteTests24Java8_RunAll]
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8828) Detecting and stopping unresponsive nodes during Partition Map Exchange
[ https://issues.apache.org/jira/browse/IGNITE-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805255#comment-16805255 ] Ilya Lantukh commented on IGNITE-8828: -- Hi [~agoncharuk] , Thanks for the review! I don't think I will be able to address your remarks in the nearest future. Feel free to take over this ticket. > Detecting and stopping unresponsive nodes during Partition Map Exchange > --- > > Key: IGNITE-8828 > URL: https://issues.apache.org/jira/browse/IGNITE-8828 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Assignee: Ilya Lantukh >Priority: Major > Labels: iep-25 > Fix For: 2.8 > > Original Estimate: 264h > Remaining Estimate: 264h > > During PME process coordinator (1) gathers local partition maps from all > nodes and (2) sends calculated full partition map back to all nodes in the > topology. > However if one or more nodes fail to send local information on step 1 for any > reason, PME process hangs blocking all operations. The only solution will be > to manually identify and stop nodes which failed to send info to coordinator. > This should be done by coordinator itself: in case it didn't receive in time > local partition maps from any nodes, it should check that stopping these > nodes won't lead to data loss and then stop them forcibly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8828) Detecting and stopping unresponsive nodes during Partition Map Exchange
[ https://issues.apache.org/jira/browse/IGNITE-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Lantukh reassigned IGNITE-8828: Assignee: (was: Ilya Lantukh) > Detecting and stopping unresponsive nodes during Partition Map Exchange > --- > > Key: IGNITE-8828 > URL: https://issues.apache.org/jira/browse/IGNITE-8828 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Priority: Major > Labels: iep-25 > Fix For: 2.8 > > Original Estimate: 264h > Remaining Estimate: 264h > > During PME process coordinator (1) gathers local partition maps from all > nodes and (2) sends calculated full partition map back to all nodes in the > topology. > However if one or more nodes fail to send local information on step 1 for any > reason, PME process hangs blocking all operations. The only solution will be > to manually identify and stop nodes which failed to send info to coordinator. > This should be done by coordinator itself: in case it didn't receive in time > local partition maps from any nodes, it should check that stopping these > nodes won't lead to data loss and then stop them forcibly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11600) Fix launch script for Java 12 - clearly state that version is not supported
[ https://issues.apache.org/jira/browse/IGNITE-11600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-11600: Summary: Fix launch script for Java 12 - clearly state that version is not supported (was: Fix launch script for Java 12) > Fix launch script for Java 12 - clearly state that version is not supported > --- > > Key: IGNITE-11600 > URL: https://issues.apache.org/jira/browse/IGNITE-11600 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Critical > Labels: important > Fix For: 2.8, 2.7.5 > > Time Spent: 40m > Remaining Estimate: 0h > > bin/ignite.bat:251 > if "%MAJOR_JAVA_VER%" == "11" ( > need to change to "%MAJOR_JAVA_VER%" GEQ "11" ( -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions
[ https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-5714: --- Assignee: Nikolay Izhikov (was: Alexey Kuznetsov) > Implementation of suspend/resume for pessimistic transactions > - > > Key: IGNITE-5714 > URL: https://issues.apache.org/jira/browse/IGNITE-5714 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Alexey Kuznetsov >Assignee: Nikolay Izhikov >Priority: Major > > Support transaction suspend()\resume() operations for pessimistic > transactions. Resume can be called in another thread. >_+But there is a problem+_: Imagine, we started pessimistic transaction in > thread T1 and then perform put operation, which leads to sending > GridDistributedLockRequest to another node. Lock request contains thread id > of the transaction. Then we call suspend, resume in another thread and we > also must send messages to other nodes to change thread id. > It seems complicated task.It’s better to get rid of sending thread id to the > nodes. > We can use transaction xid on other nodes instead of thread id. Xid is sent > to nodes in GridDistributedLockRequest#nearXidVer >_+Proposed solution+_ : On remote nodes instead of thread id of near > transaction GridDistributedLockRequest#threadId use its xid > GridDistributedLockRequest#nearXidVer. > Remove usages of near transaction's thread id on remote nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions
[ https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805181#comment-16805181 ] Nikolay Izhikov edited comment on IGNITE-5714 at 3/29/19 4:32 PM: -- Hello, [~agoncharuk] Thanks for the update. If [~Alexey Kuznetsov] don't mind I'll take care of this ticket. was (Author: nizhikov): Hello, [~agoncharuk] Thanks for the update. If [~Alexey Kuznetsov] don't mind I take care of this ticket. > Implementation of suspend/resume for pessimistic transactions > - > > Key: IGNITE-5714 > URL: https://issues.apache.org/jira/browse/IGNITE-5714 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > > Support transaction suspend()\resume() operations for pessimistic > transactions. Resume can be called in another thread. >_+But there is a problem+_: Imagine, we started pessimistic transaction in > thread T1 and then perform put operation, which leads to sending > GridDistributedLockRequest to another node. Lock request contains thread id > of the transaction. Then we call suspend, resume in another thread and we > also must send messages to other nodes to change thread id. > It seems complicated task.It’s better to get rid of sending thread id to the > nodes. > We can use transaction xid on other nodes instead of thread id. Xid is sent > to nodes in GridDistributedLockRequest#nearXidVer >_+Proposed solution+_ : On remote nodes instead of thread id of near > transaction GridDistributedLockRequest#threadId use its xid > GridDistributedLockRequest#nearXidVer. > Remove usages of near transaction's thread id on remote nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions
[ https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805181#comment-16805181 ] Nikolay Izhikov commented on IGNITE-5714: - Hello, [~agoncharuk] Thanks for the update. If [~Alexey Kuznetsov] don't mind I take care of this ticket. > Implementation of suspend/resume for pessimistic transactions > - > > Key: IGNITE-5714 > URL: https://issues.apache.org/jira/browse/IGNITE-5714 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > > Support transaction suspend()\resume() operations for pessimistic > transactions. Resume can be called in another thread. >_+But there is a problem+_: Imagine, we started pessimistic transaction in > thread T1 and then perform put operation, which leads to sending > GridDistributedLockRequest to another node. Lock request contains thread id > of the transaction. Then we call suspend, resume in another thread and we > also must send messages to other nodes to change thread id. > It seems complicated task.It’s better to get rid of sending thread id to the > nodes. > We can use transaction xid on other nodes instead of thread id. Xid is sent > to nodes in GridDistributedLockRequest#nearXidVer >_+Proposed solution+_ : On remote nodes instead of thread id of near > transaction GridDistributedLockRequest#threadId use its xid > GridDistributedLockRequest#nearXidVer. > Remove usages of near transaction's thread id on remote nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10078) Node failure during concurrent partition updates may cause partition desync between primary and backup.
[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805178#comment-16805178
]
Alexey Goncharuk commented on IGNITE-10078:
---
[~ascherbakov], can you elaborate on the {{dataStore().reserve(cntr)}} logic?
I think we can improve code organization, the following line, for example,
bothers me:
{code}
msg.add(p, mvcc ? part.getAndIncrementUpdateCounter(cntr) :
part.dataStore().reserve(cntr), cntr);
{code}
We can safely rely on the fact that a transaction cannot transact between MVCC
and non-MVCC caches. Thus, no need to pass a flag to
{{calculatePartitionUpdateCounters}}. Also, it is confusing to obtain partition
counters either from {{GridDhtLocalPartition}} or from {{part.dataStore()}}.
The distinction can be done inside the partition based on MVCC or non-MVCC
cache context.
I think we should unify partition counters acquire logic in transactional code
as much as possible.
> Node failure during concurrent partition updates may cause partition desync
> between primary and backup.
> ---
>
> Key: IGNITE-10078
> URL: https://issues.apache.org/jira/browse/IGNITE-10078
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
>
> This is possible if some updates are not written to WAL before node failure.
> They will be not applied by rebalancing due to same partition counters in
> certain scenario:
> 1. Start grid with 3 nodes, 2 backups.
> 2. Preload some data to partition P.
> 3. Start two concurrent transactions writing single key to the same partition
> P, keys are different
> {noformat}
> try(Transaction tx = client.transactions().txStart(PESSIMISTIC,
> REPEATABLE_READ, 0, 1)) {
> client.cache(DEFAULT_CACHE_NAME).put(k, v);
> tx.commit();
> }
> {noformat}
> 4. Order updates on backup in the way such update with max partition counter
> is written to WAL and update with lesser partition counter failed due to
> triggering of FH before it's added to WAL
> 5. Return failed node to grid, observe no rebalancing due to same partition
> counters.
> Possible solution: detect gaps in update counters on recovery and force
> rebalance from a node without gaps if detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11043) CPP Thin: Improve Best Effort Affinity for C++ thin client
[ https://issues.apache.org/jira/browse/IGNITE-11043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805142#comment-16805142 ] Igor Sapego commented on IGNITE-11043: -- [~vozerov] fixed points 1-4. You are right, ClientCacheAffinityAwarenessGroup needs re-factoring. I was in a rush trying to implement working prototype as soon as possible. Will review and rework this part. > CPP Thin: Improve Best Effort Affinity for C++ thin client > -- > > Key: IGNITE-11043 > URL: https://issues.apache.org/jira/browse/IGNITE-11043 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] > was updated recently, and we need to implement described changes in C++ > thin client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8828) Detecting and stopping unresponsive nodes during Partition Map Exchange
[
https://issues.apache.org/jira/browse/IGNITE-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805136#comment-16805136
]
Alexey Goncharuk commented on IGNITE-8828:
--
I think the change requires a bit more work.
* First, I think we need to add {{InitNewCoordinatorFuture}} hang handling
(see IGNITE-11626 - it is currently not even being diagnosed as a hang source)
* Second, the timeouts and minimal number of owners should be changed at
runtime similarly to baseline auto-adjust timeout
* I think we should also have an ability to kick pending nodes out of topology
via a command even if timeout is set to 0
* Additionally, it would be great to collect all debug information via the
command line utility to understand the cause of the exchange hang
> Detecting and stopping unresponsive nodes during Partition Map Exchange
> ---
>
> Key: IGNITE-8828
> URL: https://issues.apache.org/jira/browse/IGNITE-8828
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Sergey Chugunov
>Assignee: Ilya Lantukh
>Priority: Major
> Labels: iep-25
> Fix For: 2.8
>
> Original Estimate: 264h
> Remaining Estimate: 264h
>
> During PME process coordinator (1) gathers local partition maps from all
> nodes and (2) sends calculated full partition map back to all nodes in the
> topology.
> However if one or more nodes fail to send local information on step 1 for any
> reason, PME process hangs blocking all operations. The only solution will be
> to manually identify and stop nodes which failed to send info to coordinator.
> This should be done by coordinator itself: in case it didn't receive in time
> local partition maps from any nodes, it should check that stopping these
> nodes won't lead to data loss and then stop them forcibly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8828) Detecting and stopping unresponsive nodes during Partition Map Exchange
[ https://issues.apache.org/jira/browse/IGNITE-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805138#comment-16805138 ] Alexey Goncharuk commented on IGNITE-8828: -- [~ilantukh] Are you still going to work on this issue? > Detecting and stopping unresponsive nodes during Partition Map Exchange > --- > > Key: IGNITE-8828 > URL: https://issues.apache.org/jira/browse/IGNITE-8828 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Assignee: Ilya Lantukh >Priority: Major > Labels: iep-25 > Fix For: 2.8 > > Original Estimate: 264h > Remaining Estimate: 264h > > During PME process coordinator (1) gathers local partition maps from all > nodes and (2) sends calculated full partition map back to all nodes in the > topology. > However if one or more nodes fail to send local information on step 1 for any > reason, PME process hangs blocking all operations. The only solution will be > to manually identify and stop nodes which failed to send info to coordinator. > This should be done by coordinator itself: in case it didn't receive in time > local partition maps from any nodes, it should check that stopping these > nodes won't lead to data loss and then stop them forcibly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10344) Speed up cleanupRestoredCaches
[
https://issues.apache.org/jira/browse/IGNITE-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov reassigned IGNITE-10344:
-
Assignee: Denis Chudov
> 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
>
> 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-9720) Initialize partition free lists lazily
[
https://issues.apache.org/jira/browse/IGNITE-9720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805123#comment-16805123
]
Alexey Goncharuk commented on IGNITE-9720:
--
Multiple test fails and JVM crashes need to be investigated.
> Initialize partition free lists lazily
> --
>
> Key: IGNITE-9720
> URL: https://issues.apache.org/jira/browse/IGNITE-9720
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Goncharuk
>Assignee: Semen Boikov
>Priority: Major
> Labels: performance
> Fix For: 2.8
>
>
> When persistence is enabled, partition free lists metadata may take quite a
> lot of pages.
> This results in a very long start time because
> {{GridCacheOffheapManager.GridCacheDataStore#init0}} will read all metadata
> for free list in each partition on exchange start (this is done in the
> {{CacheFreeListImpl}} constructor)
> We should only read required information on exchange and defer actual free
> list initialization to the first access.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9720) Initialize partition free lists lazily
[
https://issues.apache.org/jira/browse/IGNITE-9720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805122#comment-16805122
]
Ignite TC Bot commented on IGNITE-9720:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC PDS 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3384183]]
* IgnitePdsMvccTestSuite2: CheckpointFreeListTest.testFreeListRestoredCorrectly
- 0,0% fails in last 354 master runs.
{color:#d04437}MVCC PDS 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3384187]]
* IgnitePdsMvccTestSuite4: FreeListLazyInitializationTest.initializationError
{color:#d04437}PDS 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3384189]]
* IgnitePdsTestSuite2: CheckpointFreeListTest.testFreeListRestoredCorrectly -
0,0% fails in last 393 master runs.
{color:#d04437}PDS 4{color} [[tests
31|https://ci.ignite.apache.org/viewLog.html?buildId=3384193]]
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionAtomicPrimaryAsync - 0,0%
fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionAtomicNodeFilteredAsync -
0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testLocalPreloadPartitionPrimary - 0,0% fails in
last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionTransactionalBackupSync -
0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testLocalPreloadPartitionBackup - 0,0% fails in
last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionAtomicBackupAsync - 0,0%
fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionTransactionalBackupAsync -
0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionTransactionalClientSync -
0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4: FreeListLazyInitializationTest.initializationError
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionTransactionalPrimaryAsync -
0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionTransactionalNodeFilteredSync
- 0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionTransactionalPrimarySync -
0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadLocalTransactionalSync - 0,0% fails in
last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionTransactionalClientAsyncMvcc
- 0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionTransactionalClientSyncMvcc -
0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionTransactionalPrimarySyncMvcc
- 0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionAtomicNodeFilteredSync - 0,0%
fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionTransactionalBackupSyncMvcc -
0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testLocalPreloadPartitionBackupMvcc - 0,0% fails
in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionTransactionalNodeFilteredSyncMvcc
- 0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testLocalPreloadPartitionPrimaryMvcc - 0,0% fails
in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionAtomicClientSync - 0,0% fails
in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionTransactionalPrimaryAsyncMvcc
- 0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionTransactionalNodeFilteredAsyncMvcc
- 0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionTransactionalClientAsync -
0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionTransactionalBackupAsyncMvcc
- 0,0% fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionAtomicClientAsync - 0,0%
fails in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadLocalTransactionalAsync - 0,0% fails
in last 395 master runs.
* IgnitePdsTestSuite4:
IgnitePdsPartitionPreloadTest.testPreloadPartitionAtomicBackupSync - 0,0% fails
in last 395 master runs.
* IgnitePdsTestSuite4:
[jira] [Commented] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions
[ https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805119#comment-16805119 ] Alexey Goncharuk commented on IGNITE-5714: -- I believe we should either remove thread ID from the code altogether, or replace it somehow with some random unique value so that there is no need to update it when thread is switched. > Implementation of suspend/resume for pessimistic transactions > - > > Key: IGNITE-5714 > URL: https://issues.apache.org/jira/browse/IGNITE-5714 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > > Support transaction suspend()\resume() operations for pessimistic > transactions. Resume can be called in another thread. >_+But there is a problem+_: Imagine, we started pessimistic transaction in > thread T1 and then perform put operation, which leads to sending > GridDistributedLockRequest to another node. Lock request contains thread id > of the transaction. Then we call suspend, resume in another thread and we > also must send messages to other nodes to change thread id. > It seems complicated task.It’s better to get rid of sending thread id to the > nodes. > We can use transaction xid on other nodes instead of thread id. Xid is sent > to nodes in GridDistributedLockRequest#nearXidVer >_+Proposed solution+_ : On remote nodes instead of thread id of near > transaction GridDistributedLockRequest#threadId use its xid > GridDistributedLockRequest#nearXidVer. > Remove usages of near transaction's thread id on remote nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11606) Index could not contain all values from cache after index full rebuild
[
https://issues.apache.org/jira/browse/IGNITE-11606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805118#comment-16805118
]
Alexey Goncharuk commented on IGNITE-11606:
---
[~EdShangGG], thanks, merged to master.
> Index could not contain all values from cache after index full rebuild
> --
>
> Key: IGNITE-11606
> URL: https://issues.apache.org/jira/browse/IGNITE-11606
> Project: Ignite
> Issue Type: Bug
> Components: cache, persistence, sql
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If index.bin was deleted, we would rebuild it on node start.
> But it could cause to the situation when a key is in the cache but SQL query
> doesn't return it.
> {code}
> [18:29:07][:363] idle_verify check has finished, found 1194 conflict
> partitions: [counterConflicts=0, hashConflicts=1194]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11586) Update platforms/cpp/DEVNOTES.txt: OpenSSL
[
https://issues.apache.org/jira/browse/IGNITE-11586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington reassigned IGNITE-11586:
---
Assignee: Stephen Darlington
> Update platforms/cpp/DEVNOTES.txt: OpenSSL
> ---
>
> Key: IGNITE-11586
> URL: https://issues.apache.org/jira/browse/IGNITE-11586
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10 Pro, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Stephen Darlington
>Priority: Major
> Fix For: 2.8
>
>
> ODBC compilation required OpenSSL headers and the project compilation fails
> due to unable to open {{include/openssl/ssl.h}}. I suggest to add the
> requirement to install OpenSSL and set the corresponding environment variable:
> {noformat}
> Building on Windows with Visual Studio (tm)
> --
> Common Requirements:
> ...
> * OPENSSL_HOME environment variable must be set pointing to OpenSSL
> installation directory.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11586) Update platforms/cpp/DEVNOTES.txt: OpenSSL
[
https://issues.apache.org/jira/browse/IGNITE-11586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805108#comment-16805108
]
Stephen Darlington commented on IGNITE-11586:
-
I added the check for OpenSSL as part of the Mac port:
https://issues.apache.org/jira/browse/IGNITE-1436
> Update platforms/cpp/DEVNOTES.txt: OpenSSL
> ---
>
> Key: IGNITE-11586
> URL: https://issues.apache.org/jira/browse/IGNITE-11586
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10 Pro, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Priority: Major
> Fix For: 2.8
>
>
> ODBC compilation required OpenSSL headers and the project compilation fails
> due to unable to open {{include/openssl/ssl.h}}. I suggest to add the
> requirement to install OpenSSL and set the corresponding environment variable:
> {noformat}
> Building on Windows with Visual Studio (tm)
> --
> Common Requirements:
> ...
> * OPENSSL_HOME environment variable must be set pointing to OpenSSL
> installation directory.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11043) CPP Thin: Improve Best Effort Affinity for C++ thin client
[ https://issues.apache.org/jira/browse/IGNITE-11043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804118#comment-16804118 ] Igor Sapego edited comment on IGNITE-11043 at 3/29/19 3:25 PM: --- I've added new test for topology update and found new issue: currently client does not re-connects to cluster nodes, when new node is joining cluster. Not sure how to handle it properly. Trying to reconnect synchronously every time when when major affinity version is changed looks like a big overhead to me. Thinking about adding background connection thread - this it does not look like a lot of work to me. was (Author: isapego): I've added new test for topology update and find new issue: currently client does not re-connects to cluster nodes, when new node is joining cluster. Not sure how to handle it properly. Trying to reconnect synchronously every time when when major affinity version is changed looks like a big overhead to me. Thinking about adding background connection thread - this it does not look like a lot of work to me. > CPP Thin: Improve Best Effort Affinity for C++ thin client > -- > > Key: IGNITE-11043 > URL: https://issues.apache.org/jira/browse/IGNITE-11043 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] > was updated recently, and we need to implement described changes in C++ > thin client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11606) Index could not contain all values from cache after index full rebuild
[
https://issues.apache.org/jira/browse/IGNITE-11606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11606:
--
Fix Version/s: 2.8
> Index could not contain all values from cache after index full rebuild
> --
>
> Key: IGNITE-11606
> URL: https://issues.apache.org/jira/browse/IGNITE-11606
> Project: Ignite
> Issue Type: Bug
> Components: cache, persistence, sql
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If index.bin was deleted, we would rebuild it on node start.
> But it could cause to the situation when a key is in the cache but SQL query
> doesn't return it.
> {code}
> [18:29:07][:363] idle_verify check has finished, found 1194 conflict
> partitions: [counterConflicts=0, hashConflicts=1194]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7101) .NET: IIgnite.GetVersion
[
https://issues.apache.org/jira/browse/IGNITE-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805091#comment-16805091
]
Alexandr Shapkin commented on IGNITE-7101:
--
PR ready, [~ptupitsyn] please have a look
> .NET: IIgnite.GetVersion
>
>
> Key: IGNITE-7101
> URL: https://issues.apache.org/jira/browse/IGNITE-7101
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Shapkin
>Priority: Trivial
> Labels: .NET, newbie
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Add {{IIgnite.GetVersion}} method and {{IClusterNode.Version}} property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
[
https://issues.apache.org/jira/browse/IGNITE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-10003:
Fix Version/s: 2.7.5
> Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read
> lock timeout detected
>
>
> Key: IGNITE-10003
> URL: https://issues.apache.org/jira/browse/IGNITE-10003
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Trivial
> Fix For: 2.8, 2.7.5
>
>
> {{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
> {{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
> default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7101) .NET: IIgnite.GetVersion
[
https://issues.apache.org/jira/browse/IGNITE-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805087#comment-16805087
]
Ignite TC Bot commented on IGNITE-7101:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Thin client: Node.js{color} [[tests 42 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3454610]]
* cache put get test suite : put get primitive values of different types -
1,0% fails in last 391 master runs.
* cache put get test suite : put get arrays of different types - 1,0% fails
in last 391 master runs.
* complex object test suite : put get binary objects from objects - 1,0%
fails in last 391 master runs.
* cache put get test suite : put enum items - 0,8% fails in last 391 master
runs.
* complex object test suite : put get complex objects with one byte offset
- 0,8% fails in last 391 master runs.
* cache put get test suite : put get maps of different key/value types -
0,8% fails in last 391 master runs.
* cache put get test suite : put get maps with arrays of different types -
0,8% fails in last 391 master runs.
* cache put get test suite : put get sets of different key/value types -
0,8% fails in last 391 master runs.
* cache put get test suite : put get lists of different key/value types -
0,8% fails in last 391 master runs.
* execute examples : SqlExample - 0,8% fails in last 391 master runs.
* cache put get test suite : put get object array of maps - 0,8% fails in
last 391 master runs.
* cache put get test suite : put get object array of primitive types - 0,8%
fails in last 391 master runs.
* cache put get test suite : put get object array of primitive arrays -
0,8% fails in last 391 master runs.
* complex object test suite : put get complex objects with two bytes offset
- 0,8% fails in last 391 master runs.
* cache put get test suite : put get object array of sets - 0,8% fails in
last 391 master runs.
* cache put get test suite : put get object array of lists - 0,8% fails in
last 391 master runs.
* complex object test suite : put get complex objects with four bytes
offset - 0,8% fails in last 391 master runs.
* cache put get test suite : put get object array of complex objects - 0,8%
fails in last 391 master runs.
* cache put get test suite : put get object array of complex objects with
default field types - 0,8% fails in last 391 master runs.
* complex object test suite : put get complex objects without schema - 0,8%
fails in last 391 master runs.
* cache put get test suite : put get object array of binary objects - 0,8%
fails in last 391 master runs.
* cache put get test suite : put get object array of object arrays - 0,8%
fails in last 391 master runs.
* complex object test suite : put get complex objects with arrays - 0,8%
fails in last 391 master runs.
* complex object test suite : put get complex objects with maps - 0,8%
fails in last 391 master runs.
* sql query test suite : get all - 0,5% fails in last 391 master runs.
* sql query test suite : get all with page size - 0,5% fails in last 391
master runs.
* sql query test suite : get value - 0,5% fails in last 391 master runs.
* sql query test suite : get value with page size - 0,5% fails in last 391
master runs.
* sql query test suite : close cursor - 0,5% fails in last 391 master runs.
* sql fields query test suite : get all with page size lazy false - 0,5%
fails in last 391 master runs.
* sql query test suite : close cursor after get all - 0,5% fails in last
391 master runs.
* sql query test suite : sql query settings - 0,5% fails in last 391 master
runs.
* sql query test suite : get values from empty cache - 0,5% fails in last
391 master runs.
* sql fields query test suite : get all with page size lazy true - 0,5%
fails in last 391 master runs.
* sql fields query test suite : get all - 0,5% fails in last 391 master
runs.
* sql fields query test suite : get value - 0,5% fails in last 391 master
runs.
* sql fields query test suite : get value with page size - 0,5% fails in
last 391 master runs.
* sql fields query test suite : close cursor - 0,5% fails in last 391
master runs.
* sql fields query test suite : close cursor after get all - 0,5% fails in
last 391 master runs.
* sql fields query test suite : sql fields query settings - 0,5% fails in
last 391 master runs.
* sql fields query test suite : get empty results - 0,5% fails in last 391
master runs.
* scan query test suite : scan empty cache - 0,3% fails in last 391 master
runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3445665buildTypeId=IgniteTests24Java8_RunAll]
> .NET: IIgnite.GetVersion
>
>
> Key: IGNITE-7101
> URL: https://issues.apache.org/jira/browse/IGNITE-7101
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>
[jira] [Commented] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
[
https://issues.apache.org/jira/browse/IGNITE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805089#comment-16805089
]
Dmitriy Pavlov commented on IGNITE-10003:
-
Cherry-picked to 2.7.5
> Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read
> lock timeout detected
>
>
> Key: IGNITE-10003
> URL: https://issues.apache.org/jira/browse/IGNITE-10003
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Trivial
> Fix For: 2.8, 2.7.5
>
>
> {{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
> {{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
> default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10799) Optimize affinity initialization/re-calculation
[
https://issues.apache.org/jira/browse/IGNITE-10799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805080#comment-16805080
]
Alexey Goncharuk commented on IGNITE-10799:
---
[~Jokser] a few comments on
{{onServerLeftWithExchangeMergeProtocolLightweight}}:
1) Can we split the internals of the closure inside
{{forAllRegisteredCacheGroups}} call into several methods? Currently it's hard
to follow on what is going on in two loops
2) Let's make {{aliveNodes}} a hash set - otherwise multiple {{contains}} calls
on this collection for each cache group and for each partition may consume
significant time on large topologies and {{REPLICATED}} caches
3) In {{GridAffinityAssignmentV2}} there is an unnecessary check for
{{idealPrimary == null}}
Otherwise looks good.
> Optimize affinity initialization/re-calculation
> ---
>
> Key: IGNITE-10799
> URL: https://issues.apache.org/jira/browse/IGNITE-10799
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In case of persistence enabled and a baseline is set we have 2 main
> approaches to recalculate affinity:
> {noformat}
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#onServerJoinWithExchangeMergeProtocol
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#onServerLeftWithExchangeMergeProtocol
> {noformat}
> Both of them following the same approach of recalculating:
> 1) Take a current baseline (ideal assignment).
> 2) Filter out offline nodes from it.
> 3) Choose new primary nodes if previous went away.
> 4) Place temporal primary nodes to late affinity assignment set.
> Looking at implementation details we may notice that we do a lot of
> unnecessary online nodes cache lookups and array list copies. The performance
> becomes too slow if we do recalculate affinity for replicated caches (It
> takes P * N on each node, where P - partitions count, N - the number of nodes
> in the cluster). In case of large partitions count or large cluster, it may
> take few seconds, which is unacceptable, because this process happens during
> PME and freezes ongoing cluster operations.
> We should investigate possible bottlenecks and improve the performance of
> affinity recalculation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7101) .NET: IIgnite.GetVersion
[
https://issues.apache.org/jira/browse/IGNITE-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805071#comment-16805071
]
Ignite TC Bot commented on IGNITE-7101:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Thin client: Node.js{color} [[tests 42 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3454610]]
* cache put get test suite : put get primitive values of different types -
1,0% fails in last 391 master runs.
* cache put get test suite : put get arrays of different types - 1,0% fails
in last 391 master runs.
* complex object test suite : put get binary objects from objects - 1,0%
fails in last 391 master runs.
* cache put get test suite : put enum items - 0,8% fails in last 391 master
runs.
* complex object test suite : put get complex objects with one byte offset
- 0,8% fails in last 391 master runs.
* cache put get test suite : put get maps of different key/value types -
0,8% fails in last 391 master runs.
* cache put get test suite : put get maps with arrays of different types -
0,8% fails in last 391 master runs.
* cache put get test suite : put get sets of different key/value types -
0,8% fails in last 391 master runs.
* cache put get test suite : put get lists of different key/value types -
0,8% fails in last 391 master runs.
* execute examples : SqlExample - 0,8% fails in last 391 master runs.
* cache put get test suite : put get object array of maps - 0,8% fails in
last 391 master runs.
* cache put get test suite : put get object array of primitive types - 0,8%
fails in last 391 master runs.
* cache put get test suite : put get object array of primitive arrays -
0,8% fails in last 391 master runs.
* complex object test suite : put get complex objects with two bytes offset
- 0,8% fails in last 391 master runs.
* cache put get test suite : put get object array of sets - 0,8% fails in
last 391 master runs.
* cache put get test suite : put get object array of lists - 0,8% fails in
last 391 master runs.
* complex object test suite : put get complex objects with four bytes
offset - 0,8% fails in last 391 master runs.
* cache put get test suite : put get object array of complex objects - 0,8%
fails in last 391 master runs.
* cache put get test suite : put get object array of complex objects with
default field types - 0,8% fails in last 391 master runs.
* complex object test suite : put get complex objects without schema - 0,8%
fails in last 391 master runs.
* cache put get test suite : put get object array of binary objects - 0,8%
fails in last 391 master runs.
* cache put get test suite : put get object array of object arrays - 0,8%
fails in last 391 master runs.
* complex object test suite : put get complex objects with arrays - 0,8%
fails in last 391 master runs.
* complex object test suite : put get complex objects with maps - 0,8%
fails in last 391 master runs.
* sql query test suite : get all - 0,5% fails in last 391 master runs.
* sql query test suite : get all with page size - 0,5% fails in last 391
master runs.
* sql query test suite : get value - 0,5% fails in last 391 master runs.
* sql query test suite : get value with page size - 0,5% fails in last 391
master runs.
* sql query test suite : close cursor - 0,5% fails in last 391 master runs.
* sql fields query test suite : get all with page size lazy false - 0,5%
fails in last 391 master runs.
* sql query test suite : close cursor after get all - 0,5% fails in last
391 master runs.
* sql query test suite : sql query settings - 0,5% fails in last 391 master
runs.
* sql query test suite : get values from empty cache - 0,5% fails in last
391 master runs.
* sql fields query test suite : get all with page size lazy true - 0,5%
fails in last 391 master runs.
* sql fields query test suite : get all - 0,5% fails in last 391 master
runs.
* sql fields query test suite : get value - 0,5% fails in last 391 master
runs.
* sql fields query test suite : get value with page size - 0,5% fails in
last 391 master runs.
* sql fields query test suite : close cursor - 0,5% fails in last 391
master runs.
* sql fields query test suite : close cursor after get all - 0,5% fails in
last 391 master runs.
* sql fields query test suite : sql fields query settings - 0,5% fails in
last 391 master runs.
* sql fields query test suite : get empty results - 0,5% fails in last 391
master runs.
* scan query test suite : scan empty cache - 0,3% fails in last 391 master
runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3445665buildTypeId=IgniteTests24Java8_RunAll]
> .NET: IIgnite.GetVersion
>
>
> Key: IGNITE-7101
> URL: https://issues.apache.org/jira/browse/IGNITE-7101
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>
[jira] [Created] (IGNITE-11657) Stripe Threads Deadlock on Cache.putAll(Map)
Gaurav Aggarwal created IGNITE-11657:
Summary: Stripe Threads Deadlock on Cache.putAll(Map)
Key: IGNITE-11657
URL: https://issues.apache.org/jira/browse/IGNITE-11657
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.5
Reporter: Gaurav Aggarwal
We have been seeing some consistent Deadlocks with Ignite Latest versions, as
putAll tries to lock all the keys before updating them.
As per the documentation (below) putAll should be Equivalent to individual
iterative puts and these individual puts should behave atomically but not the
entire pull, But the error logs pasted further below seem to suggest otherwise
*putAll Documentation*
h5. void javax.cache.Cache.putAll(Map map)
Copies all of the entries from the specified map to the {{Cache}}.
The effect of this call is equivalent to that of calling {{put(k, v)}} on this
cache once for each mapping from key {{k}} to value {{v}} in the specified map.
The order in which the individual puts occur is undefined.
The behavior of this operation is undefined if entries in the cache
corresponding to entries in the map are modified or removed while this
operation is in progress. or if map is modified while the operation is in
progress.
In Default Consistency mode, individual puts occur atomically but not the
entire putAll. Listeners may observe individual updates.
*Error Log suggesting otherwise*
Deadlock: true
Completed: 12808
Thread [name="sys-stripe-3-#4%VPS%", id=27, state=WAITING, blockCnt=3,
waitCnt=121340]
Lock [object=java.util.concurrent.locks.ReentrantLock$NonfairSync@138205af,
ownerName=sys-stripe-26-#27%VPS%, ownerId=50]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
at
o.a.i.i.processors.cache.GridCacheMapEntry.lockEntry(GridCacheMapEntry.java:4272)
at
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.lockEntries(GridDhtAtomicCache.java:2848)
at
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1706)
at
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
at
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3056)
at
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:130)
at
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:266)
at
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:261)
at
o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
at
o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at
o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at
o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at
o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at
o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at
o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at o.a.i.i.util.StripedExecutor$Stripe.run(StripedExecutor.java:511)
at java.lang.Thread.run(Thread.java:748)
I have tried sorting my keys but the same doesn't helps
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11651) Add cluster (de)activation events documentation
[
https://issues.apache.org/jira/browse/IGNITE-11651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-11651:
-
Ignite Flags: (was: Docs Required)
> Add cluster (de)activation events documentation
> ---
>
> Key: IGNITE-11651
> URL: https://issues.apache.org/jira/browse/IGNITE-11651
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Igor Belyakov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.8
>
>
> {{Add information regarding cluster activation events to
> [https://apacheignite.readme.io/docs/baseline-topology#section-activating-the-cluster]}}
>
> After cluster activation/deactivation local event will be raised.
> (EVT_CLUSTER_ACTIVATED/EVT_CLUSTER_DEACTIVATED)
> Subscribing for local events described here:
> [https://apacheignite.readme.io/docs/events#section-local-events]
> Example:
> ignite.events().localListen((evt) -> {
> // Do something.
> return true;
> }, EventType.EVT_CLUSTER_ACTIVATED);
> Cluster event types:
> {{EVT_CLUSTER_ACTIVATED - Invoked after Ignite cluster activation.}}
> {{EVT_CLUSTER_DEACTIVATED - Invoked after Ignite cluster deactivation.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11656) The GridCacheMapEntry#lockEntry cannot be interrupted
Taras Ledkov created IGNITE-11656:
-
Summary: The GridCacheMapEntry#lockEntry cannot be interrupted
Key: IGNITE-11656
URL: https://issues.apache.org/jira/browse/IGNITE-11656
Project: Ignite
Issue Type: Improvement
Components: cache
Affects Versions: 2.7
Reporter: Taras Ledkov
Now the method {{GridCacheMapEntry#lockEntry}} use {{ReentrantLock#lock}} to
lock the entry. So, when deadlock happens the locked threads cannot be
interrupted by {{Thread.interrupt()}}.
In this case a test and the grid cannot be stoped without kill the process.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11256) Implement read-only mode for grid
[ https://issues.apache.org/jira/browse/IGNITE-11256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov reassigned IGNITE-11256: --- Assignee: Sergey Antonov > Implement read-only mode for grid > - > > Key: IGNITE-11256 > URL: https://issues.apache.org/jira/browse/IGNITE-11256 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.8 > > > Should be triggered from control.sh utility. > Useful for maintenance work, for example checking partition consistency > (idle_verify) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11654) ML: Memory leak in KNNClassificationModel
[ https://issues.apache.org/jira/browse/IGNITE-11654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-11654: -- Priority: Critical (was: Major) > ML: Memory leak in KNNClassificationModel > - > > Key: IGNITE-11654 > URL: https://issues.apache.org/jira/browse/IGNITE-11654 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.7 >Reporter: Anton Dmitriev >Assignee: Aleksey Zinoviev >Priority: Critical > > KNNClassificationModel acquires datasets which keeps resources within the > cluster, but doesn't close it. As result of that we have a memory leak > because resources allocated for dataset are not collected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11655) ML: OneHotEncoder returns more columns than expected
[
https://issues.apache.org/jira/browse/IGNITE-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Zinoviev updated IGNITE-11655:
--
Priority: Critical (was: Major)
> ML: OneHotEncoder returns more columns than expected
>
>
> Key: IGNITE-11655
> URL: https://issues.apache.org/jira/browse/IGNITE-11655
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.7
>Reporter: Anton Dmitriev
>Assignee: Aleksey Zinoviev
>Priority: Critical
>
> OneHotEncoder returns more columns than expected (two values that might be
> encoded using two columns encoded using 3 columns). The following example
> demonstrates the problem:
> {code:java}
> Map training = new HashMap<>();
> training.put(0, new Object[]{42.0});
> training.put(1, new Object[]{43.0});
> training.put(2, new Object[]{42.0});
> EncoderTrainer trainer = new EncoderTrainer Object[]>()
> .withEncoderType(EncoderType.ONE_HOT_ENCODER)
> .withEncodedFeature(0);
> IgniteBiFunction processor = trainer.fit(training,
> 1, (k, v) -> v);
> Vector res = processor.apply(1, new Object[]{42.0});
> System.out.println(Arrays.toString(res.asArray()));
> >>> [0.0, 1.0, 0.0]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5962) Increase max length of index name
[
https://issues.apache.org/jira/browse/IGNITE-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804908#comment-16804908
]
Ignite TC Bot commented on IGNITE-5962:
---
{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=3446506buildTypeId=IgniteTests24Java8_RunAll]
> Increase max length of index name
> -
>
> Key: IGNITE-5962
> URL: https://issues.apache.org/jira/browse/IGNITE-5962
> Project: Ignite
> Issue Type: Improvement
> Components: general, sql
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Pavel Kuznetsov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In https://issues.apache.org/jira/browse/IGNITE-5941 max index name length
> was reduced from 768 to 256 bytes. If we need to support longer names, we
> need to change format of metastore data pages.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (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:all-tabpanel ] Igor Belyakov reassigned IGNITE-11544: -- Assignee: Igor Belyakov > 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] [Commented] (IGNITE-9991) thin clients: can't use array as cache key for PHP, JS and Python clients
[
https://issues.apache.org/jira/browse/IGNITE-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804884#comment-16804884
]
Pavel Petroshenko commented on IGNITE-9991:
---
Until the issue is fixed on the Ignite side, there is nothing to be done with
the Thin clients.
> thin clients: can't use array as cache key for PHP, JS and Python clients
> -
>
> Key: IGNITE-9991
> URL: https://issues.apache.org/jira/browse/IGNITE-9991
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Priority: Minor
>
> Trying to put cache with key as values array
> Put Py code
> {code}
> cache = client.get_or_create_cache("PY_BOOLEAN_ARRAY")
> cache.put([True, False], 1, key_hint=BoolArrayObject, value_hint=IntObject)
> {code}
> Get
> {code}
> cache = client.get_or_create_cache("PY_BOOLEAN_ARRAY")
> print(cache.get([True, False] key_hint=BoolArrayObject))
> {code}
> output: null
> Same thing with PHP, JS clients and all others array data types
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-6440) Flaky failures in DynamicColumnsAbstractConcurrentSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-6440:
---
Assignee: Pavel Kuznetsov
> Flaky failures in DynamicColumnsAbstractConcurrentSelfTest
> --
>
> Key: IGNITE-6440
> URL: https://issues.apache.org/jira/browse/IGNITE-6440
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, sql-stability
>
> Multiple failures are observed in concrete implementations of
> {{DynamicColumnsAbstractConcurrentSelfTest}}. Specifically:
> {code}
> testQueryConsistencyMultithreaded
> testClientReconnect
> testConcurrentRebalance
> testCoordinatorChange
> testConcurrentPutRemove
> {code}
> Apparently there are some bugs in the test itself, as the following root
> causes could be observed in logs:
> {code}
> junit.framework.AssertionFailedError: Found nodes from different clusters,
> probable some test does not stop nodes
> [allNodes=[index.DynamicColumnsConcurrentTransactionalReplicatedSelfTest3,
> index.DynamicColumnsConcurrentTransactionalReplicatedSelfTest2,
> index.DynamicColumnsConcurrentTransactionalReplicatedSelfTest1]]
> {code}
> {code}
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest$3.call(DynamicColumnsAbstractConcurrentSelfTest.java:565)
> at
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest$3.call(DynamicColumnsAbstractConcurrentSelfTest.java:560)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
> Please see TeamCity, history of "Queries 2" suite in master branch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11563) DELETE WHERE does not work in prepared statements
[
https://issues.apache.org/jira/browse/IGNITE-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-11563:
Assignee: Pavel Kuznetsov
> DELETE WHERE does not work in prepared statements
> -
>
> Key: IGNITE-11563
> URL: https://issues.apache.org/jira/browse/IGNITE-11563
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Stefan
>Assignee: Pavel Kuznetsov
>Priority: Minor
>
> With SQL I cannot delete a row using a prepared statement. The following
> statement is simply ignored:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = ?}}
> This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets
> the correct data but handles it wrong. By adding an always-true-condition it
> works as expected:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = id AND}} {{id = ?}}
> I tested with a very simple table that was created with:
> {{CREATE TABLE testtable (}}
> {{ "ID" NUMBER(19,0),}}
> {{ "VALUE" VARCHAR2(255 CHAR),}}
> {{ PRIMARY KEY (ID)}}
> {{) WITH "template=replicated,cache_name=testtable"}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8588) .NET: Serialization issue when derived type hides base type member
[
https://issues.apache.org/jira/browse/IGNITE-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804851#comment-16804851
]
Alexandr Shapkin edited comment on IGNITE-8588 at 3/29/19 11:39 AM:
PR ready, [~ptupitsyn] please have a look
was (Author: ashapkin):
PR ready, @ptupitsyn please have a look
> .NET: Serialization issue when derived type hides base type member
> --
>
> Key: IGNITE-8588
> URL: https://issues.apache.org/jira/browse/IGNITE-8588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Shapkin
>Priority: Major
> Labels: .NET
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following class structure causes an exception that is hard to understand
> (when putting instance of B into Ignite cache):
> {code}
> public class A
> {
> public int bob;
> }
> public class B : A
> {
> public int bob;
> }
> {code}
> Exception:
> {code}
> Apache.Ignite.Core.Binary.BinaryObjectException: Conflicting field IDs
> [type=SubGridsRequestArgument, field1=Filters, field2=Filters,
> fieldId=-854547461]
> at
> Apache.Ignite.Core.Impl.Binary.BinaryReflectiveSerializerInternal.Register(Type
> type, Int32 typeId, IBinaryNameMapper converter, IBinaryIdMapper idMapper,
> Boolean forceTimestamp)
> at
> Apache.Ignite.Core.Impl.Binary.Marshaller.GetSerializer(BinaryConfiguration
> cfg, BinaryTypeConfiguration typeCfg, Type type, Int32 typeId,
> IBinaryNameMapper nameMapper, IBinaryIdMapper idMapper, ILogger log)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.AddUserType(Type type, Int32
> typeId, String typeName, Boolean registered, BinaryFullTypeDescriptor desc)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.RegisterType(Type type,
> BinaryFullTypeDescriptor desc)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type type)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at
> Apache.Ignite.Core.Impl.Deployment.PeerLoadingExtensions.WriteWithPeerDeployment(BinaryWriter
> writer, Object o)
> at
> Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1
> obj, BinaryWriter writer)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at
> Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1
> obj, BinaryWriter writer)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.WriteObjectDetached[T](T o)
> at Apache.Ignite.Core.Impl.Compute.ComputeImpl.WriteJob(IComputeJob job,
> BinaryWriter writer)
> at
> Apache.Ignite.Core.Impl.Compute.ComputeImpl.<>c__DisplayClass1d`3.b__1a(BinaryWriter
> writer)
> at Apache.Ignite.Core.Impl.PlatformTargetAdapter.WriteToStream(Action`1
> action, IBinaryStream stream, Marshaller marsh)
> at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutObject(Int32 type,
> Action`1 writeAction)
> at
> Apache.Ignite.Core.Impl.Compute.ComputeImpl.ExecuteClosures0[TArg,TJobRes,TReduceRes](IComputeTask`3
> task, IComputeJob job, IEnumerable`1 jobs, Int32 opId, Int32 jobsCount,
> Action`1 writeAction)
> --- End of inner exception stack trace ---
> at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean
> includeTaskCanceledExceptions)
> at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout,
> CancellationToken cancellationToken)
> at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout)
> at VSS.TRex.GridFabric.Requests.SubGridRequestsProgressive`2.Execute() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\GridFabric\Requests\SubGridRequestsProgressive.cs:line
> 107
> at VSS.TRex.Pipelines.SubGridPipelineBase`3.Initiate() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Pipelines\SubGridPipelineBase.cs:line
> 241
> at VSS.TRex.Rendering.PlanViewTileRenderer.ExecutePipeline() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Rendering\PlanViewTileRenderer.cs:line
> 262
> ---> (Inner Exception #0) Apache.Ignite.Core.Binary.BinaryObjectException:
> Conflicting field IDs [type=SubGridsRequestArgument, field1=Filters,
> field2=Filters, fieldId=-854547461]
> at
> Apache.Ignite.Core.Impl.Binary.BinaryReflectiveSerializerInternal.Register(Type
> type, Int32 typeId, IBinaryNameMapper converter, IBinaryIdMapper idMapper,
> Boolean forceTimestamp)
> at
> Apache.Ignite.Core.Impl.Binary.Marshaller.GetSerializer(BinaryConfiguration
> cfg, BinaryTypeConfiguration typeCfg, Type type, Int32 typeId,
> IBinaryNameMapper nameMapper, IBinaryIdMapper idMapper, ILogger log)
> at
[jira] [Commented] (IGNITE-8588) .NET: Serialization issue when derived type hides base type member
[
https://issues.apache.org/jira/browse/IGNITE-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804851#comment-16804851
]
Alexandr Shapkin commented on IGNITE-8588:
--
PR ready, @ptupitsyn please have a look
> .NET: Serialization issue when derived type hides base type member
> --
>
> Key: IGNITE-8588
> URL: https://issues.apache.org/jira/browse/IGNITE-8588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Shapkin
>Priority: Major
> Labels: .NET
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following class structure causes an exception that is hard to understand
> (when putting instance of B into Ignite cache):
> {code}
> public class A
> {
> public int bob;
> }
> public class B : A
> {
> public int bob;
> }
> {code}
> Exception:
> {code}
> Apache.Ignite.Core.Binary.BinaryObjectException: Conflicting field IDs
> [type=SubGridsRequestArgument, field1=Filters, field2=Filters,
> fieldId=-854547461]
> at
> Apache.Ignite.Core.Impl.Binary.BinaryReflectiveSerializerInternal.Register(Type
> type, Int32 typeId, IBinaryNameMapper converter, IBinaryIdMapper idMapper,
> Boolean forceTimestamp)
> at
> Apache.Ignite.Core.Impl.Binary.Marshaller.GetSerializer(BinaryConfiguration
> cfg, BinaryTypeConfiguration typeCfg, Type type, Int32 typeId,
> IBinaryNameMapper nameMapper, IBinaryIdMapper idMapper, ILogger log)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.AddUserType(Type type, Int32
> typeId, String typeName, Boolean registered, BinaryFullTypeDescriptor desc)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.RegisterType(Type type,
> BinaryFullTypeDescriptor desc)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type type)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at
> Apache.Ignite.Core.Impl.Deployment.PeerLoadingExtensions.WriteWithPeerDeployment(BinaryWriter
> writer, Object o)
> at
> Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1
> obj, BinaryWriter writer)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at
> Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1
> obj, BinaryWriter writer)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.WriteObjectDetached[T](T o)
> at Apache.Ignite.Core.Impl.Compute.ComputeImpl.WriteJob(IComputeJob job,
> BinaryWriter writer)
> at
> Apache.Ignite.Core.Impl.Compute.ComputeImpl.<>c__DisplayClass1d`3.b__1a(BinaryWriter
> writer)
> at Apache.Ignite.Core.Impl.PlatformTargetAdapter.WriteToStream(Action`1
> action, IBinaryStream stream, Marshaller marsh)
> at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutObject(Int32 type,
> Action`1 writeAction)
> at
> Apache.Ignite.Core.Impl.Compute.ComputeImpl.ExecuteClosures0[TArg,TJobRes,TReduceRes](IComputeTask`3
> task, IComputeJob job, IEnumerable`1 jobs, Int32 opId, Int32 jobsCount,
> Action`1 writeAction)
> --- End of inner exception stack trace ---
> at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean
> includeTaskCanceledExceptions)
> at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout,
> CancellationToken cancellationToken)
> at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout)
> at VSS.TRex.GridFabric.Requests.SubGridRequestsProgressive`2.Execute() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\GridFabric\Requests\SubGridRequestsProgressive.cs:line
> 107
> at VSS.TRex.Pipelines.SubGridPipelineBase`3.Initiate() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Pipelines\SubGridPipelineBase.cs:line
> 241
> at VSS.TRex.Rendering.PlanViewTileRenderer.ExecutePipeline() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Rendering\PlanViewTileRenderer.cs:line
> 262
> ---> (Inner Exception #0) Apache.Ignite.Core.Binary.BinaryObjectException:
> Conflicting field IDs [type=SubGridsRequestArgument, field1=Filters,
> field2=Filters, fieldId=-854547461]
> at
> Apache.Ignite.Core.Impl.Binary.BinaryReflectiveSerializerInternal.Register(Type
> type, Int32 typeId, IBinaryNameMapper converter, IBinaryIdMapper idMapper,
> Boolean forceTimestamp)
> at
> Apache.Ignite.Core.Impl.Binary.Marshaller.GetSerializer(BinaryConfiguration
> cfg, BinaryTypeConfiguration typeCfg, Type type, Int32 typeId,
> IBinaryNameMapper nameMapper, IBinaryIdMapper idMapper, ILogger log)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.AddUserType(Type type, Int32
> typeId, String typeName, Boolean registered, BinaryFullTypeDescriptor desc)
> at
[jira] [Commented] (IGNITE-8588) .NET: Serialization issue when derived type hides base type member
[
https://issues.apache.org/jira/browse/IGNITE-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804848#comment-16804848
]
Ignite TC Bot commented on IGNITE-8588:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3446240]]
* ZookeeperDiscoverySpiTestSuite4:
IgniteCachePutRetryTransactionalSelfTest.testExplicitTransactionRetriesStoreEnabled
- 0,0% fails in last 385 master runs.
{color:#d04437}PDS 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3446226]]
*
ClientAffinityAssignmentWithBaselineTest.testClientJoinCacheLongTransactionNodeStart
(last started)
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3446259buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Serialization issue when derived type hides base type member
> --
>
> Key: IGNITE-8588
> URL: https://issues.apache.org/jira/browse/IGNITE-8588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Shapkin
>Priority: Major
> Labels: .NET
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following class structure causes an exception that is hard to understand
> (when putting instance of B into Ignite cache):
> {code}
> public class A
> {
> public int bob;
> }
> public class B : A
> {
> public int bob;
> }
> {code}
> Exception:
> {code}
> Apache.Ignite.Core.Binary.BinaryObjectException: Conflicting field IDs
> [type=SubGridsRequestArgument, field1=Filters, field2=Filters,
> fieldId=-854547461]
> at
> Apache.Ignite.Core.Impl.Binary.BinaryReflectiveSerializerInternal.Register(Type
> type, Int32 typeId, IBinaryNameMapper converter, IBinaryIdMapper idMapper,
> Boolean forceTimestamp)
> at
> Apache.Ignite.Core.Impl.Binary.Marshaller.GetSerializer(BinaryConfiguration
> cfg, BinaryTypeConfiguration typeCfg, Type type, Int32 typeId,
> IBinaryNameMapper nameMapper, IBinaryIdMapper idMapper, ILogger log)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.AddUserType(Type type, Int32
> typeId, String typeName, Boolean registered, BinaryFullTypeDescriptor desc)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.RegisterType(Type type,
> BinaryFullTypeDescriptor desc)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type type)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at
> Apache.Ignite.Core.Impl.Deployment.PeerLoadingExtensions.WriteWithPeerDeployment(BinaryWriter
> writer, Object o)
> at
> Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1
> obj, BinaryWriter writer)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at
> Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1
> obj, BinaryWriter writer)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.WriteObjectDetached[T](T o)
> at Apache.Ignite.Core.Impl.Compute.ComputeImpl.WriteJob(IComputeJob job,
> BinaryWriter writer)
> at
> Apache.Ignite.Core.Impl.Compute.ComputeImpl.<>c__DisplayClass1d`3.b__1a(BinaryWriter
> writer)
> at Apache.Ignite.Core.Impl.PlatformTargetAdapter.WriteToStream(Action`1
> action, IBinaryStream stream, Marshaller marsh)
> at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutObject(Int32 type,
> Action`1 writeAction)
> at
> Apache.Ignite.Core.Impl.Compute.ComputeImpl.ExecuteClosures0[TArg,TJobRes,TReduceRes](IComputeTask`3
> task, IComputeJob job, IEnumerable`1 jobs, Int32 opId, Int32 jobsCount,
> Action`1 writeAction)
> --- End of inner exception stack trace ---
> at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean
> includeTaskCanceledExceptions)
> at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout,
> CancellationToken cancellationToken)
> at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout)
> at VSS.TRex.GridFabric.Requests.SubGridRequestsProgressive`2.Execute() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\GridFabric\Requests\SubGridRequestsProgressive.cs:line
> 107
> at VSS.TRex.Pipelines.SubGridPipelineBase`3.Initiate() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Pipelines\SubGridPipelineBase.cs:line
> 241
> at VSS.TRex.Rendering.PlanViewTileRenderer.ExecutePipeline() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Rendering\PlanViewTileRenderer.cs:line
> 262
> ---> (Inner Exception #0) Apache.Ignite.Core.Binary.BinaryObjectException:
>
[jira] [Commented] (IGNITE-11127) GridDhtInvalidPartitionException not handled by GridCacheTtlManager
[
https://issues.apache.org/jira/browse/IGNITE-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804830#comment-16804830
]
Vyacheslav Daradur commented on IGNITE-11127:
-
[~roman_s], I'm a bit late :) The fix looks good to me.
One minor comment for future contributions: related to test, there is no need
to define static field {{TcpDiscoveryVmIpFinder(true)}} directly since it's set
by default in abstract class.
Thanks for your contributions!
> GridDhtInvalidPartitionException not handled by GridCacheTtlManager
> ---
>
> Key: IGNITE-11127
> URL: https://issues.apache.org/jira/browse/IGNITE-11127
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4, 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Roman Shtykh
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Leading to either message processing problems:
> {code}
> [2019-01-27 16:57:45,474][ERROR][sys-stripe-2-#3][GridCacheIoManager] Failed
> to process message [senderId=4839b5a2-a295-44cf-8a44-f0cb932b689e,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.atomic.GridNearAtomicFullUpdateRequest]
> class
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException
> [part=381, msg=Adding entry to partition that is concurrently evicted
> [grp=, part=381, shouldBeMoving=, belongs=false,
> topVer=AffinityTopologyVersion [topVer=818, minorTopVer=0],
> curTopVer=AffinityTopologyVersion [topVer=818, minorTopVer=0]]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:917)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:794)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:69)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:88)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:952)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:525)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:943)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1047)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:835)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessageProcessed(GridCacheIoManager.java:1093)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1066)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:505)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> or unhandled unspecified exceptions in user code (possibly violating JCache):
> {code}
> [2019-01-27 10:23:35,451][ERROR][pub-#840058][ComputeJobProcess] class
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException
> [part=485, msg=Adding entry to partition that is concurrently evicted
> [grp=, part=485,
[jira] [Commented] (IGNITE-9497) [ML] Add Pipeline support to Cross-Validation process
[ https://issues.apache.org/jira/browse/IGNITE-9497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804826#comment-16804826 ] Yury Babak commented on IGNITE-9497: Reviewed, LGTM. > [ML] Add Pipeline support to Cross-Validation process > - > > Key: IGNITE-9497 > URL: https://issues.apache.org/jira/browse/IGNITE-9497 > Project: Ignite > Issue Type: New Feature > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Change API of ParamGrid.addHyperParam to support meta-information about > Pipeline Stage > Add to Cross-Validation method to support evaluate the whole Pipeline Process > and inject hyper-parameters from the ParamGrid -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11653) Remove warnings which appear during CPP compiling
[
https://issues.apache.org/jira/browse/IGNITE-11653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804817#comment-16804817
]
Igor Sapego commented on IGNITE-11653:
--
I can remove first type of warnings ({{comparison between signed and unsigned
integer expressions}}) but not the second one.
> Remove warnings which appear during CPP compiling
> -
>
> Key: IGNITE-11653
> URL: https://issues.apache.org/jira/browse/IGNITE-11653
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.7
>Reporter: Roman Guseinov
>Priority: Minor
> Attachments: CPPWarnings.log
>
>
> There are two types of warnings:
>
> {code:java}
> src/impl/binary/binary_utils.cpp:92:41: warning: comparison between signed
> and unsigned integer expressions [-Wsign-compare]
> ../common/include/ignite/common/shared_state.h:343:67: warning: 'auto_ptr' is
> deprecated (declared at /usr/include/c++/4.8.2/backward/auto_ptr.h:87)
> [-Wdeprecated-declarations]
> {code}
> The full log is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11366) python thin client: add python examples in release build
[ https://issues.apache.org/jira/browse/IGNITE-11366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804803#comment-16804803 ] Dmitriy Pavlov commented on IGNITE-11366: - Cherry picked to 2.7.5. > python thin client: add python examples in release build > > > Key: IGNITE-11366 > URL: https://issues.apache.org/jira/browse/IGNITE-11366 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Stepan Pilschikov >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.8, 2.7.5 > > Time Spent: 20m > Remaining Estimate: 0h > > Examples directory should be added in release build because they exists in > sources and they really help to understand how to work with this client > I think they understandable enough for end user > Also they have readme.md which is contain link on examples documentation > > What should be in release build in /ignite/platforms/python > * examples (dir) > * pyignite (dir) > * requirements (dir) > * LICENSE > * README.md > * setup.py -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IGNITE-11600) Fix launch script for Java 12
[ https://issues.apache.org/jira/browse/IGNITE-11600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov reopened IGNITE-11600: - Launch under Java 12 fails, so correct fix will be - in case java 12 is not supported, print an error - in case java 12 supported, current fix is correct > Fix launch script for Java 12 > - > > Key: IGNITE-11600 > URL: https://issues.apache.org/jira/browse/IGNITE-11600 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Critical > Labels: important > Fix For: 2.8, 2.7.5 > > Time Spent: 40m > Remaining Estimate: 0h > > bin/ignite.bat:251 > if "%MAJOR_JAVA_VER%" == "11" ( > need to change to "%MAJOR_JAVA_VER%" GEQ "11" ( -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11598) Add possibility to have different rebalance thread pool size for nodes in the cluster
[ https://issues.apache.org/jira/browse/IGNITE-11598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11598: -- Fix Version/s: 2.8 > Add possibility to have different rebalance thread pool size for nodes in the > cluster > - > > Key: IGNITE-11598 > URL: https://issues.apache.org/jira/browse/IGNITE-11598 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > It can be used for changing this property without downtime when rebalance is > slow -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11598) Add possibility to have different rebalance thread pool size for nodes in the cluster
[ https://issues.apache.org/jira/browse/IGNITE-11598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11598: -- Ignite Flags: (was: Docs Required) > Add possibility to have different rebalance thread pool size for nodes in the > cluster > - > > Key: IGNITE-11598 > URL: https://issues.apache.org/jira/browse/IGNITE-11598 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > It can be used for changing this property without downtime when rebalance is > slow -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11643) Optimize GC pressure on GridDhtPartitionTopologyImpl#updateRebalanceVersion
[
https://issues.apache.org/jira/browse/IGNITE-11643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804761#comment-16804761
]
Ignite TC Bot commented on IGNITE-11643:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=3444508]]
* IgniteSpiTestSuite: GridTcpCommunicationSpiRecoveryAckSelfTest.testAckOnIdle
- 0,0% fails in last 387 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3444593buildTypeId=IgniteTests24Java8_RunAll]
> Optimize GC pressure on GridDhtPartitionTopologyImpl#updateRebalanceVersion
> ---
>
> Key: IGNITE-11643
> URL: https://issues.apache.org/jira/browse/IGNITE-11643
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Have surplused HashMap in the method
> {{GridDhtPartitionTopologyImpl#updateRebalanceVersion}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9276) Multi-Get from NodeJS platform return empty or partial result
[ https://issues.apache.org/jira/browse/IGNITE-9276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804757#comment-16804757 ] Igor Sapego commented on IGNITE-9276: - [~pavel.petroshenko], agree > Multi-Get from NodeJS platform return empty or partial result > - > > Key: IGNITE-9276 > URL: https://issues.apache.org/jira/browse/IGNITE-9276 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Eran Betzalel >Priority: Major > > The same test run with the JAVA client and it worked flawlessly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9276) Multi-Get from NodeJS platform return empty or partial result
[ https://issues.apache.org/jira/browse/IGNITE-9276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego resolved IGNITE-9276. - Resolution: Cannot Reproduce > Multi-Get from NodeJS platform return empty or partial result > - > > Key: IGNITE-9276 > URL: https://issues.apache.org/jira/browse/IGNITE-9276 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Eran Betzalel >Priority: Major > > The same test run with the JAVA client and it worked flawlessly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11655) ML: OneHotEncoder returns more columns than expected
[
https://issues.apache.org/jira/browse/IGNITE-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Zinoviev reassigned IGNITE-11655:
-
Assignee: Aleksey Zinoviev
> ML: OneHotEncoder returns more columns than expected
>
>
> Key: IGNITE-11655
> URL: https://issues.apache.org/jira/browse/IGNITE-11655
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.7
>Reporter: Anton Dmitriev
>Assignee: Aleksey Zinoviev
>Priority: Major
>
> OneHotEncoder returns more columns than expected (two values that might be
> encoded using two columns encoded using 3 columns). The following example
> demonstrates the problem:
> {code:java}
> Map training = new HashMap<>();
> training.put(0, new Object[]{42.0});
> training.put(1, new Object[]{43.0});
> training.put(2, new Object[]{42.0});
> EncoderTrainer trainer = new EncoderTrainer Object[]>()
> .withEncoderType(EncoderType.ONE_HOT_ENCODER)
> .withEncodedFeature(0);
> IgniteBiFunction processor = trainer.fit(training,
> 1, (k, v) -> v);
> Vector res = processor.apply(1, new Object[]{42.0});
> System.out.println(Arrays.toString(res.asArray()));
> >>> [0.0, 1.0, 0.0]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11655) ML: OneHotEncoder returns more columns than expected
[
https://issues.apache.org/jira/browse/IGNITE-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Dmitriev updated IGNITE-11655:
Description:
OneHotEncoder returns more columns than expected (two values that might be
encoded using two columns encoded using 3 columns). The following example
demonstrates the problem:
{code:java}
Map training = new HashMap<>();
training.put(0, new Object[]{42.0});
training.put(1, new Object[]{43.0});
training.put(2, new Object[]{42.0});
EncoderTrainer trainer = new EncoderTrainer()
.withEncoderType(EncoderType.ONE_HOT_ENCODER)
.withEncodedFeature(0);
IgniteBiFunction processor = trainer.fit(training,
1, (k, v) -> v);
Vector res = processor.apply(1, new Object[]{42.0});
System.out.println(Arrays.toString(res.asArray()));
>>> [0.0, 1.0, 0.0]
{code}
was:
OneHotEncoder returns more columns than expected (two values that might be
encoded using two columns encoded using 3 columns). The following example
demonstrates the problem:
{code:java}
Map training = new HashMap<>();
training.put(0, new Object[]{42.0});
training.put(1, new Object[]{43.0});
training.put(2, new Object[]{42.0});
EncoderTrainer trainer = new EncoderTrainer()
.withEncoderType(EncoderType.ONE_HOT_ENCODER)
.withEncodedFeature(0);
IgniteBiFunction processor = trainer.fit(training,
1, (k, v) -> v);
Vector res = processor.apply(1, new Object[]{42.0});
System.out.println(Arrays.toString(res.asArray()));
>>> [0.0, 1.0, 0.0]
{code}
> ML: OneHotEncoder returns more columns than expected
>
>
> Key: IGNITE-11655
> URL: https://issues.apache.org/jira/browse/IGNITE-11655
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.7
>Reporter: Anton Dmitriev
>Priority: Major
>
> OneHotEncoder returns more columns than expected (two values that might be
> encoded using two columns encoded using 3 columns). The following example
> demonstrates the problem:
> {code:java}
> Map training = new HashMap<>();
> training.put(0, new Object[]{42.0});
> training.put(1, new Object[]{43.0});
> training.put(2, new Object[]{42.0});
> EncoderTrainer trainer = new EncoderTrainer Object[]>()
> .withEncoderType(EncoderType.ONE_HOT_ENCODER)
> .withEncodedFeature(0);
> IgniteBiFunction processor = trainer.fit(training,
> 1, (k, v) -> v);
> Vector res = processor.apply(1, new Object[]{42.0});
> System.out.println(Arrays.toString(res.asArray()));
> >>> [0.0, 1.0, 0.0]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11655) ML: OneHotEncoder returns more columns than expected
[
https://issues.apache.org/jira/browse/IGNITE-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Dmitriev updated IGNITE-11655:
Description:
OneHotEncoder returns more columns than expected (two values that might be
encoded using two columns encoded using 3 columns). The following example
demonstrates the problem:
{code:java}
Map training = new HashMap<>();
training.put(0, new Object[]{42.0});
training.put(1, new Object[]{43.0});
training.put(2, new Object[]{42.0});
EncoderTrainer trainer = new EncoderTrainer()
.withEncoderType(EncoderType.ONE_HOT_ENCODER)
.withEncodedFeature(0);
IgniteBiFunction processor = trainer.fit(training,
1, (k, v) -> v);
Vector res = processor.apply(1, new Object[]{42.0});
System.out.println(Arrays.toString(res.asArray()));
>>> [0.0, 1.0, 0.0]
{code}
was:
OneHotEncoder returns more columns than expected (two values that might be
encoded using two columns encoded using 3 columns). The following example
demonstrates the problem:
{code:java}
Map training = new HashMap<>();
training.put(0, new Object[]{42.0});
training.put(1, new Object[]{43.0});
training.put(2, new Object[]{42.0});
EncoderTrainer trainer = new EncoderTrainer()
.withEncoderType(EncoderType.ONE_HOT_ENCODER)
.withEncodedFeature(0);
IgniteBiFunction processor = trainer.fit(training,
1, (k, v) -> v);
Vector res = processor.apply(1, new Object[]{42.0});
System.out.println(Arrays.toString(res.asArray()));
>>> [0.0, 1.0, 0.0]
{code}
> ML: OneHotEncoder returns more columns than expected
>
>
> Key: IGNITE-11655
> URL: https://issues.apache.org/jira/browse/IGNITE-11655
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.7
>Reporter: Anton Dmitriev
>Priority: Major
>
> OneHotEncoder returns more columns than expected (two values that might be
> encoded using two columns encoded using 3 columns). The following example
> demonstrates the problem:
> {code:java}
> Map training = new HashMap<>();
> training.put(0, new Object[]{42.0});
> training.put(1, new Object[]{43.0});
> training.put(2, new Object[]{42.0});
> EncoderTrainer trainer = new EncoderTrainer Object[]>()
> .withEncoderType(EncoderType.ONE_HOT_ENCODER)
> .withEncodedFeature(0);
> IgniteBiFunction processor = trainer.fit(training,
> 1, (k, v) -> v);
> Vector res = processor.apply(1, new Object[]{42.0});
> System.out.println(Arrays.toString(res.asArray()));
> >>> [0.0, 1.0, 0.0]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11654) ML: Memory leak in KNNClassificationModel
[ https://issues.apache.org/jira/browse/IGNITE-11654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev reassigned IGNITE-11654: - Assignee: Aleksey Zinoviev > ML: Memory leak in KNNClassificationModel > - > > Key: IGNITE-11654 > URL: https://issues.apache.org/jira/browse/IGNITE-11654 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.7 >Reporter: Anton Dmitriev >Assignee: Aleksey Zinoviev >Priority: Major > > KNNClassificationModel acquires datasets which keeps resources within the > cluster, but doesn't close it. As result of that we have a memory leak > because resources allocated for dataset are not collected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11655) ML: OneHotEncoder returns more columns than expected
[
https://issues.apache.org/jira/browse/IGNITE-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Dmitriev updated IGNITE-11655:
Description:
OneHotEncoder returns more columns than expected (two values that might be
encoded using two columns encoded using 3 columns). The following example
demonstrates the problem:
{code:java}
Map training = new HashMap<>();
training.put(0, new Object[]{42.0});
training.put(1, new Object[]{43.0});
training.put(2, new Object[]{42.0});
EncoderTrainer trainer = new EncoderTrainer()
.withEncoderType(EncoderType.ONE_HOT_ENCODER)
.withEncodedFeature(0);
IgniteBiFunction processor = trainer.fit(training,
1, (k, v) -> v);
Vector res = processor.apply(1, new Object[]{42.0});
System.out.println(Arrays.toString(res.asArray()));
>>> [0.0, 1.0, 0.0]
{code}
was:
OneHotEncoder returns more columns than expected (two values that might be
encoded using two columns encoded using 3 columns). The following example
demonstrates the problem:
{code:java}
Map training = new HashMap<>();
training.put(0, new Object[]{42.0});
training.put(1, new Object[]{43.0});
training.put(2, new Object[]{42.0});
EncoderTrainer trainer = new EncoderTrainer()
.withEncoderType(EncoderType.ONE_HOT_ENCODER)
.withEncodedFeature(0);
IgniteBiFunction processor = trainer.fit(training,
1, (k, v) -> v);
Vector res = processor.apply(1, new Object[]{42.0});
System.out.println(Arrays.toString(res.asArray()));
>>> [0.0, 1.0, 0.0]
{code}
> ML: OneHotEncoder returns more columns than expected
>
>
> Key: IGNITE-11655
> URL: https://issues.apache.org/jira/browse/IGNITE-11655
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.7
>Reporter: Anton Dmitriev
>Priority: Major
>
> OneHotEncoder returns more columns than expected (two values that might be
> encoded using two columns encoded using 3 columns). The following example
> demonstrates the problem:
> {code:java}
> Map training = new HashMap<>();
> training.put(0, new Object[]{42.0});
> training.put(1, new Object[]{43.0});
> training.put(2, new Object[]{42.0});
> EncoderTrainer trainer = new EncoderTrainer Object[]>()
> .withEncoderType(EncoderType.ONE_HOT_ENCODER)
> .withEncodedFeature(0);
> IgniteBiFunction processor = trainer.fit(training,
> 1, (k, v) -> v);
> Vector res = processor.apply(1, new Object[]{42.0});
> System.out.println(Arrays.toString(res.asArray()));
> >>> [0.0, 1.0, 0.0]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11655) ML: OneHotEncoder returns more columns than expected
[
https://issues.apache.org/jira/browse/IGNITE-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Dmitriev updated IGNITE-11655:
Description:
OneHotEncoder returns more columns than expected (two values that might be
encoded using two columns encoded using 3 columns). The following example
demonstrates the problem:
{code:java}
Map training = new HashMap<>();
training.put(0, new Object[]{42.0});
training.put(1, new Object[]{43.0});
training.put(2, new Object[]{42.0});
EncoderTrainer trainer = new EncoderTrainer()
.withEncoderType(EncoderType.ONE_HOT_ENCODER)
.withEncodedFeature(0);
IgniteBiFunction processor = trainer.fit(training,
1, (k, v) -> v);
Vector res = processor.apply(1, new Object[]{42.0});
System.out.println(Arrays.toString(res.asArray()));
>>> [0.0, 1.0, 0.0]
{code}
was:
OneHotEncoder returns more columns than expected (two values that might be
encoded using two columns encoded using 3 columns). The following example
demonstrates the problem:
Map training = new HashMap<>();
training.put(0, new Object[]{42.0});
training.put(1, new Object[]{43.0});
training.put(2, new Object[]{42.0});
EncoderTrainer trainer = new EncoderTrainer()
.withEncoderType(EncoderType.ONE_HOT_ENCODER)
.withEncodedFeature(0);
IgniteBiFunction processor =
trainer.fit(training, 1, (k, v) -> v);
Vector res = processor.apply(1, new Object[]{42.0});
System.out.println(Arrays.toString(res.asArray()));
>>> [0.0, 1.0, 0.0]
> ML: OneHotEncoder returns more columns than expected
>
>
> Key: IGNITE-11655
> URL: https://issues.apache.org/jira/browse/IGNITE-11655
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.7
>Reporter: Anton Dmitriev
>Priority: Major
>
> OneHotEncoder returns more columns than expected (two values that might be
> encoded using two columns encoded using 3 columns). The following example
> demonstrates the problem:
> {code:java}
> Map training = new HashMap<>();
> training.put(0, new Object[]{42.0});
> training.put(1, new Object[]{43.0});
> training.put(2, new Object[]{42.0});
> EncoderTrainer trainer = new EncoderTrainer Object[]>()
> .withEncoderType(EncoderType.ONE_HOT_ENCODER)
> .withEncodedFeature(0);
> IgniteBiFunction processor = trainer.fit(training,
> 1, (k, v) -> v);
> Vector res = processor.apply(1, new Object[]{42.0});
> System.out.println(Arrays.toString(res.asArray()));
> >>> [0.0, 1.0, 0.0]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11655) ML: OneHotEncoder returns more columns than expected
[
https://issues.apache.org/jira/browse/IGNITE-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Dmitriev updated IGNITE-11655:
Description:
OneHotEncoder returns more columns than expected (two values that might be
encoded using two columns encoded using 3 columns). The following example
demonstrates the problem:
{code:java}
Map training = new HashMap<>();
training.put(0, new Object[]{42.0});
training.put(1, new Object[]{43.0});
training.put(2, new Object[]{42.0});
EncoderTrainer trainer = new EncoderTrainer()
.withEncoderType(EncoderType.ONE_HOT_ENCODER)
.withEncodedFeature(0);
IgniteBiFunction processor = trainer.fit(training,
1, (k, v) -> v);
Vector res = processor.apply(1, new Object[]{42.0});
System.out.println(Arrays.toString(res.asArray()));
>>> [0.0, 1.0, 0.0]
{code}
was:
OneHotEncoder returns more columns than expected (two values that might be
encoded using two columns encoded using 3 columns). The following example
demonstrates the problem:
{code:java}
Map training = new HashMap<>();
training.put(0, new Object[]{42.0});
training.put(1, new Object[]{43.0});
training.put(2, new Object[]{42.0});
EncoderTrainer trainer = new EncoderTrainer()
.withEncoderType(EncoderType.ONE_HOT_ENCODER)
.withEncodedFeature(0);
IgniteBiFunction processor = trainer.fit(training,
1, (k, v) -> v);
Vector res = processor.apply(1, new Object[]{42.0});
System.out.println(Arrays.toString(res.asArray()));
>>> [0.0, 1.0, 0.0]
{code}
> ML: OneHotEncoder returns more columns than expected
>
>
> Key: IGNITE-11655
> URL: https://issues.apache.org/jira/browse/IGNITE-11655
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.7
>Reporter: Anton Dmitriev
>Priority: Major
>
> OneHotEncoder returns more columns than expected (two values that might be
> encoded using two columns encoded using 3 columns). The following example
> demonstrates the problem:
> {code:java}
> Map training = new HashMap<>();
> training.put(0, new Object[]{42.0});
> training.put(1, new Object[]{43.0});
> training.put(2, new Object[]{42.0});
> EncoderTrainer trainer = new EncoderTrainer Object[]>()
> .withEncoderType(EncoderType.ONE_HOT_ENCODER)
> .withEncodedFeature(0);
> IgniteBiFunction processor = trainer.fit(training,
> 1, (k, v) -> v);
> Vector res = processor.apply(1, new Object[]{42.0});
> System.out.println(Arrays.toString(res.asArray()));
> >>> [0.0, 1.0, 0.0]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11655) ML: OneHotEncoder returns more columns than expected
[
https://issues.apache.org/jira/browse/IGNITE-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Dmitriev updated IGNITE-11655:
Ignite Flags: (was: Docs Required)
> ML: OneHotEncoder returns more columns than expected
>
>
> Key: IGNITE-11655
> URL: https://issues.apache.org/jira/browse/IGNITE-11655
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Reporter: Anton Dmitriev
>Priority: Major
>
> OneHotEncoder returns more columns than expected (two values that might be
> encoded using two columns encoded using 3 columns). The following example
> demonstrates the problem:
> Map training = new HashMap<>();
> training.put(0, new Object[]{42.0});
> training.put(1, new Object[]{43.0});
> training.put(2, new Object[]{42.0});
> EncoderTrainer trainer = new
> EncoderTrainer()
> .withEncoderType(EncoderType.ONE_HOT_ENCODER)
> .withEncodedFeature(0);
> IgniteBiFunction processor =
> trainer.fit(training, 1, (k, v) -> v);
> Vector res = processor.apply(1, new Object[]{42.0});
> System.out.println(Arrays.toString(res.asArray()));
> >>> [0.0, 1.0, 0.0]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11655) ML: OneHotEncoder returns more columns than expected
[
https://issues.apache.org/jira/browse/IGNITE-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Dmitriev updated IGNITE-11655:
Affects Version/s: 2.7
> ML: OneHotEncoder returns more columns than expected
>
>
> Key: IGNITE-11655
> URL: https://issues.apache.org/jira/browse/IGNITE-11655
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.7
>Reporter: Anton Dmitriev
>Priority: Major
>
> OneHotEncoder returns more columns than expected (two values that might be
> encoded using two columns encoded using 3 columns). The following example
> demonstrates the problem:
> Map training = new HashMap<>();
> training.put(0, new Object[]{42.0});
> training.put(1, new Object[]{43.0});
> training.put(2, new Object[]{42.0});
> EncoderTrainer trainer = new
> EncoderTrainer()
> .withEncoderType(EncoderType.ONE_HOT_ENCODER)
> .withEncodedFeature(0);
> IgniteBiFunction processor =
> trainer.fit(training, 1, (k, v) -> v);
> Vector res = processor.apply(1, new Object[]{42.0});
> System.out.println(Arrays.toString(res.asArray()));
> >>> [0.0, 1.0, 0.0]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11655) ML: OneHotEncoder returns more columns than expected
[
https://issues.apache.org/jira/browse/IGNITE-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Dmitriev updated IGNITE-11655:
Component/s: ml
> ML: OneHotEncoder returns more columns than expected
>
>
> Key: IGNITE-11655
> URL: https://issues.apache.org/jira/browse/IGNITE-11655
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Reporter: Anton Dmitriev
>Priority: Major
>
> OneHotEncoder returns more columns than expected (two values that might be
> encoded using two columns encoded using 3 columns). The following example
> demonstrates the problem:
> Map training = new HashMap<>();
> training.put(0, new Object[]{42.0});
> training.put(1, new Object[]{43.0});
> training.put(2, new Object[]{42.0});
> EncoderTrainer trainer = new
> EncoderTrainer()
> .withEncoderType(EncoderType.ONE_HOT_ENCODER)
> .withEncodedFeature(0);
> IgniteBiFunction processor =
> trainer.fit(training, 1, (k, v) -> v);
> Vector res = processor.apply(1, new Object[]{42.0});
> System.out.println(Arrays.toString(res.asArray()));
> >>> [0.0, 1.0, 0.0]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11655) ML: OneHotEncoder returns more columns than expected
Anton Dmitriev created IGNITE-11655:
---
Summary: ML: OneHotEncoder returns more columns than expected
Key: IGNITE-11655
URL: https://issues.apache.org/jira/browse/IGNITE-11655
Project: Ignite
Issue Type: Bug
Reporter: Anton Dmitriev
OneHotEncoder returns more columns than expected (two values that might be
encoded using two columns encoded using 3 columns). The following example
demonstrates the problem:
Map training = new HashMap<>();
training.put(0, new Object[]{42.0});
training.put(1, new Object[]{43.0});
training.put(2, new Object[]{42.0});
EncoderTrainer trainer = new EncoderTrainer()
.withEncoderType(EncoderType.ONE_HOT_ENCODER)
.withEncodedFeature(0);
IgniteBiFunction processor =
trainer.fit(training, 1, (k, v) -> v);
Vector res = processor.apply(1, new Object[]{42.0});
System.out.println(Arrays.toString(res.asArray()));
>>> [0.0, 1.0, 0.0]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11654) ML: Memory leak in KNNClassificationModel
Anton Dmitriev created IGNITE-11654: --- Summary: ML: Memory leak in KNNClassificationModel Key: IGNITE-11654 URL: https://issues.apache.org/jira/browse/IGNITE-11654 Project: Ignite Issue Type: Bug Components: ml Affects Versions: 2.7 Reporter: Anton Dmitriev KNNClassificationModel acquires datasets which keeps resources within the cluster, but doesn't close it. As result of that we have a memory leak because resources allocated for dataset are not collected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-10663:
--
Comment: was deleted
(was: {panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests 0 Exit Code , Compilation Error
|https://ci.ignite.apache.org/viewLog.html?buildId=3445518]]
{color:#d04437}Platform .NET (Long Running){color} [[tests 0 Exit Code ,
Compilation Error |https://ci.ignite.apache.org/viewLog.html?buildId=3445522]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code ,
TC_SERVICE_MESSAGE |https://ci.ignite.apache.org/viewLog.html?buildId=3445519]]
{color:#d04437}PDS (Indexing){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3445512]]
{color:#d04437}Spring{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3445459]]
{color:#d04437}Platform C++ (Linux Clang){color} [[tests 0 TIMEOUT , Exit Code
, Failure on metric |https://ci.ignite.apache.org/viewLog.html?buildId=3445478]]
{color:#d04437}Platform C++ (Linux){color} [[tests 0 TIMEOUT , Exit Code ,
Failure on metric |https://ci.ignite.apache.org/viewLog.html?buildId=3445472]]
{color:#d04437}Platform .NET (Integrations){color} [[tests 0 Exit Code ,
Compilation Error |https://ci.ignite.apache.org/viewLog.html?buildId=3445521]]
{color:#d04437}Platform .NET (NuGet)*{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3445523]]
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Exit Code ,
Compilation Error , Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=3445520]]
{color:#d04437}SPI (URI Deploy){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=3445464]]
* IgniteUriDeploymentTestSuite:
GridUriDeploymentClassLoaderSelfTest.testNestedJarClassloading - 0,2% fails in
last 403 master runs.
* IgniteUriDeploymentTestSuite:
GridUriDeploymentClassLoaderSelfTest.testClasspathResourceLoading - 0,2% fails
in last 403 master runs.
* IgniteUriDeploymentTestSuite:
GridUriDeploymentMultiScannersSelfTest.testDeployment - 0,2% fails in last 403
master runs.
{color:#d04437}PDS 4{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=3445517]]
* IgnitePdsTestSuite4:
IgniteRebalanceOnCachesStoppingOrDestroyingTest.testDestroySpecificCacheAndCacheGroupFirstGroup
- 0,0% fails in last 400 master runs.
* IgnitePdsTestSuite4:
IgniteRebalanceOnCachesStoppingOrDestroyingTest.testDestroySpecificCachesInDifferentCacheGroupsFirstGroup
- 0,0% fails in last 400 master runs.
* IgnitePdsTestSuite4:
IgniteRebalanceOnCachesStoppingOrDestroyingTest.testDestroySpecificCachesInDifferentCacheGroupsSecondGroup
- 0,0% fails in last 400 master runs.
* IgnitePdsTestSuite4:
IgniteRebalanceOnCachesStoppingOrDestroyingTest.testStopCachesOnDeactivationFirstGroup
- 0,0% fails in last 400 master runs.
* IgnitePdsTestSuite4:
ResetLostPartitionTest.testReactivateGridBeforeResetLostPartitions - 0,0% fails
in last 400 master runs.
* IgnitePdsTestSuite4: ResetLostPartitionTest.testResetLostPartitions - 0,0%
fails in last 400 master runs.
* IgnitePdsTestSuite4:
IgniteRebalanceOnCachesStoppingOrDestroyingTest.testStopCachesOnDeactivationSecondGroup
- 0,0% fails in last 400 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3445548buildTypeId=IgniteTests24Java8_RunAll])
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804726#comment-16804726
]
Ignite TC Bot commented on IGNITE-10663:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests 0 Exit Code , Compilation Error
|https://ci.ignite.apache.org/viewLog.html?buildId=3452450]]
{color:#d04437}Platform .NET (Long Running){color} [[tests 0 Exit Code ,
Compilation Error |https://ci.ignite.apache.org/viewLog.html?buildId=3452453]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code ,
TC_SERVICE_MESSAGE |https://ci.ignite.apache.org/viewLog.html?buildId=3452457]]
{color:#d04437}Platform .NET (Integrations){color} [[tests 0 Exit Code ,
Compilation Error |https://ci.ignite.apache.org/viewLog.html?buildId=3452467]]
{color:#d04437}Platform .NET (NuGet)*{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3452471]]
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Exit Code ,
Compilation Error , Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=3452473]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3445548buildTypeId=IgniteTests24Java8_RunAll]
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11598) Add possibility to have different rebalance thread pool size for nodes in the cluster
[
https://issues.apache.org/jira/browse/IGNITE-11598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804721#comment-16804721
]
Ignite TC Bot commented on IGNITE-11598:
{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=3445191buildTypeId=IgniteTests24Java8_RunAll]
> Add possibility to have different rebalance thread pool size for nodes in the
> cluster
> -
>
> Key: IGNITE-11598
> URL: https://issues.apache.org/jira/browse/IGNITE-11598
> Project: Ignite
> Issue Type: Improvement
>Reporter: Evgenii Zhuravlev
>Assignee: Stepachev Maksim
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It can be used for changing this property without downtime when rebalance is
> slow
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9913) Prevent data updates blocking in case of backup BLT server node leave
[ https://issues.apache.org/jira/browse/IGNITE-9913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804711#comment-16804711 ] Alexey Goncharuk commented on IGNITE-9913: -- [~NSAmelchev], I see that your optimization is disabled when there are in-memory caches present in the cluster. However, this will no longer be the case when IGNITE-11188 is merged. I think we need to coordinate these two changes to make most out of both. [~DmitriyGovorukhin], [~ibessonov], can you take a look at this change and coordinate with Nikita on merge order? > Prevent data updates blocking in case of backup BLT server node leave > - > > Key: IGNITE-9913 > URL: https://issues.apache.org/jira/browse/IGNITE-9913 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Ivan Rakov >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.8 > > Attachments: 9913_yardstick.png, master_yardstick.png > > Time Spent: 50m > Remaining Estimate: 0h > > Ignite cluster performs distributed partition map exchange when any server > node leaves or joins the topology. > Distributed PME blocks all updates and may take a long time. If all > partitions are assigned according to the baseline topology and server node > leaves, there's no actual need to perform distributed PME: every cluster node > is able to recalculate new affinity assigments and partition states locally. > If we'll implement such lightweight PME and handle mapping and lock requests > on new topology version correctly, updates won't be stopped (except updates > of partitions that lost their primary copy). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11354) Web console: Actualize grid configurator discovery, store, atomic, communication
[ https://issues.apache.org/jira/browse/IGNITE-11354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-11354: --- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web console: Actualize grid configurator discovery, store, atomic, > communication > > > Key: IGNITE-11354 > URL: https://issues.apache.org/jira/browse/IGNITE-11354 > Project: Ignite > Issue Type: Improvement >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: image-2019-03-20-13-15-22-387.png > > > Result for class: org.apache.ignite.configuration.DataStorageConfiguration > Missed > maxWalArchiveSize > checkpointReadLockTimeout > walCompactionLevel > Result for class: org.apache.ignite.configuration.AtomicConfiguration > Missed > groupName > Result for class: org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi > Missed > nodeAttributes > connectionRecoveryTimeout > reconnectDelay > soLinger > Result for class: org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi > Missed > usePairedConnections > connectionsPerNode > selectorSpins > filterReachableAddresses > Removed > discoveryStartupDelay -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11283) Web console: Actualize grid configuration. Check deprecated fields
[ https://issues.apache.org/jira/browse/IGNITE-11283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-11283: --- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web console: Actualize grid configuration. Check deprecated fields > -- > > Key: IGNITE-11283 > URL: https://issues.apache.org/jira/browse/IGNITE-11283 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: screenshot-1.png > > > Result for class: > org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction > Deprecated > backupFilter > Result for class: org.apache.ignite.configuration.PersistentStoreConfiguration > Deprecated > walBufferSize > writeThrottlingEnabled > checkpointWriteOrder > fileIOFactory > walMode > walAutoArchiveAfterInactivity > Result for class: org.apache.ignite.configuration.TransactionConfiguration > Missed > deadlockTimeout > useJtaSynchronization > txTimeoutOnPartitionMapExchange > Deprecated > txSerializableEnabled > txManagerLookupClassName > Result for class: org.apache.ignite.configuration.ConnectorConfiguration > Deprecated > sslContextFactory -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11283) Web console: Actualize grid configuration. Check deprecated fields
[ https://issues.apache.org/jira/browse/IGNITE-11283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804700#comment-16804700 ] Pavel Konstantinov edited comment on IGNITE-11283 at 3/29/19 8:42 AM: -- Tested on the dev-branch was (Author: pkonstantinov): Tested on the dev-barnch > Web console: Actualize grid configuration. Check deprecated fields > -- > > Key: IGNITE-11283 > URL: https://issues.apache.org/jira/browse/IGNITE-11283 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > Attachments: screenshot-1.png > > > Result for class: > org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction > Deprecated > backupFilter > Result for class: org.apache.ignite.configuration.PersistentStoreConfiguration > Deprecated > walBufferSize > writeThrottlingEnabled > checkpointWriteOrder > fileIOFactory > walMode > walAutoArchiveAfterInactivity > Result for class: org.apache.ignite.configuration.TransactionConfiguration > Missed > deadlockTimeout > useJtaSynchronization > txTimeoutOnPartitionMapExchange > Deprecated > txSerializableEnabled > txManagerLookupClassName > Result for class: org.apache.ignite.configuration.ConnectorConfiguration > Deprecated > sslContextFactory -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11354) Web console: Actualize grid configurator discovery, store, atomic, communication
[ https://issues.apache.org/jira/browse/IGNITE-11354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804701#comment-16804701 ] Pavel Konstantinov commented on IGNITE-11354: - Tested on the dev-branch > Web console: Actualize grid configurator discovery, store, atomic, > communication > > > Key: IGNITE-11354 > URL: https://issues.apache.org/jira/browse/IGNITE-11354 > Project: Ignite > Issue Type: Improvement >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > Attachments: image-2019-03-20-13-15-22-387.png > > > Result for class: org.apache.ignite.configuration.DataStorageConfiguration > Missed > maxWalArchiveSize > checkpointReadLockTimeout > walCompactionLevel > Result for class: org.apache.ignite.configuration.AtomicConfiguration > Missed > groupName > Result for class: org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi > Missed > nodeAttributes > connectionRecoveryTimeout > reconnectDelay > soLinger > Result for class: org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi > Missed > usePairedConnections > connectionsPerNode > selectorSpins > filterReachableAddresses > Removed > discoveryStartupDelay -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11361) Web console: Actualize grid configurator IgniteConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-11361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804699#comment-16804699 ] Pavel Konstantinov commented on IGNITE-11361: - Tested on the dev-branch > Web console: Actualize grid configurator IgniteConfiguration > > > Key: IGNITE-11361 > URL: https://issues.apache.org/jira/browse/IGNITE-11361 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > Attachments: image-2019-03-21-13-10-03-170.png, screenshot-1.png > > > Result for class: org.apache.ignite.configuration.IgniteConfiguration > Missed > failureHandler IGNITE-11385 > authenticationEnabled > autoActivationEnabled > sqlQueryHistorySize > lifecycleBeans > sqlSchemas > igniteInstanceName > addressResolver > igniteHome > localEventListeners IGNITE-11386 > mBeanServer > networkCompressionLevel > communicationFailureResolver > systemWorkerBlockedTimeout > platformConfiguration > includeProperties > cacheStoreSessionListenerFactories > encryptionSpi IGNITE-11387 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11283) Web console: Actualize grid configuration. Check deprecated fields
[ https://issues.apache.org/jira/browse/IGNITE-11283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804700#comment-16804700 ] Pavel Konstantinov commented on IGNITE-11283: - Tested on the dev-barnch > Web console: Actualize grid configuration. Check deprecated fields > -- > > Key: IGNITE-11283 > URL: https://issues.apache.org/jira/browse/IGNITE-11283 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > Attachments: screenshot-1.png > > > Result for class: > org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction > Deprecated > backupFilter > Result for class: org.apache.ignite.configuration.PersistentStoreConfiguration > Deprecated > walBufferSize > writeThrottlingEnabled > checkpointWriteOrder > fileIOFactory > walMode > walAutoArchiveAfterInactivity > Result for class: org.apache.ignite.configuration.TransactionConfiguration > Missed > deadlockTimeout > useJtaSynchronization > txTimeoutOnPartitionMapExchange > Deprecated > txSerializableEnabled > txManagerLookupClassName > Result for class: org.apache.ignite.configuration.ConnectorConfiguration > Deprecated > sslContextFactory -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11361) Web console: Actualize grid configurator IgniteConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-11361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-11361: --- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web console: Actualize grid configurator IgniteConfiguration > > > Key: IGNITE-11361 > URL: https://issues.apache.org/jira/browse/IGNITE-11361 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: image-2019-03-21-13-10-03-170.png, screenshot-1.png > > > Result for class: org.apache.ignite.configuration.IgniteConfiguration > Missed > failureHandler IGNITE-11385 > authenticationEnabled > autoActivationEnabled > sqlQueryHistorySize > lifecycleBeans > sqlSchemas > igniteInstanceName > addressResolver > igniteHome > localEventListeners IGNITE-11386 > mBeanServer > networkCompressionLevel > communicationFailureResolver > systemWorkerBlockedTimeout > platformConfiguration > includeProperties > cacheStoreSessionListenerFactories > encryptionSpi IGNITE-11387 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10078) Node failure during concurrent partition updates may cause partition desync between primary and backup.
[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804696#comment-16804696
]
Roman Kondakov commented on IGNITE-10078:
-
[~ascherbakov], it seems there is no need to log {{RollbackRecord}} for MVCC
caches. Everything else looks acceptable to me.
> Node failure during concurrent partition updates may cause partition desync
> between primary and backup.
> ---
>
> Key: IGNITE-10078
> URL: https://issues.apache.org/jira/browse/IGNITE-10078
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
>
> This is possible if some updates are not written to WAL before node failure.
> They will be not applied by rebalancing due to same partition counters in
> certain scenario:
> 1. Start grid with 3 nodes, 2 backups.
> 2. Preload some data to partition P.
> 3. Start two concurrent transactions writing single key to the same partition
> P, keys are different
> {noformat}
> try(Transaction tx = client.transactions().txStart(PESSIMISTIC,
> REPEATABLE_READ, 0, 1)) {
> client.cache(DEFAULT_CACHE_NAME).put(k, v);
> tx.commit();
> }
> {noformat}
> 4. Order updates on backup in the way such update with max partition counter
> is written to WAL and update with lesser partition counter failed due to
> triggering of FH before it's added to WAL
> 5. Return failed node to grid, observe no rebalancing due to same partition
> counters.
> Possible solution: detect gaps in update counters on recovery and force
> rebalance from a node without gaps if detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-10663:
--
Comment: was deleted
(was: {panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests 0 Exit Code , Compilation Error
|https://ci.ignite.apache.org/viewLog.html?buildId=3441587]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code ,
TC_SERVICE_MESSAGE |https://ci.ignite.apache.org/viewLog.html?buildId=3441590]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3433512buildTypeId=IgniteTests24Java8_RunAll])
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11521) Lifecycle event just before joining the cluster
[ https://issues.apache.org/jira/browse/IGNITE-11521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804660#comment-16804660 ] Lukas Polacek commented on IGNITE-11521: Make sense, feel free to close the ticket (I don't seem to have rights to do that). > Lifecycle event just before joining the cluster > --- > > Key: IGNITE-11521 > URL: https://issues.apache.org/jira/browse/IGNITE-11521 > Project: Ignite > Issue Type: New Feature >Reporter: Lukas Polacek >Priority: Major > > Add a new lifecycle event just before joining the cluster. At this point the > node is partially initialized and can already register event listeners, etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11653) Remove warnings which appear during CPP compiling
[
https://issues.apache.org/jira/browse/IGNITE-11653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Guseinov updated IGNITE-11653:
Attachment: CPPWarnings.log
> Remove warnings which appear during CPP compiling
> -
>
> Key: IGNITE-11653
> URL: https://issues.apache.org/jira/browse/IGNITE-11653
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.7
>Reporter: Roman Guseinov
>Priority: Minor
> Attachments: CPPWarnings.log
>
>
> There is two types of warnings:
>
> {code:java}
> src/impl/binary/binary_utils.cpp:92:41: warning: comparison between signed
> and unsigned integer expressions [-Wsign-compare]
> ../common/include/ignite/common/shared_state.h:343:67: warning: 'auto_ptr' is
> deprecated (declared at /usr/include/c++/4.8.2/backward/auto_ptr.h:87)
> [-Wdeprecated-declarations]
> {code}
> The full log is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11653) Remove warnings which appear during CPP compiling
Roman Guseinov created IGNITE-11653:
---
Summary: Remove warnings which appear during CPP compiling
Key: IGNITE-11653
URL: https://issues.apache.org/jira/browse/IGNITE-11653
Project: Ignite
Issue Type: Improvement
Components: platforms
Affects Versions: 2.7
Reporter: Roman Guseinov
Attachments: CPPWarnings.log
There is two types of warnings:
{code:java}
src/impl/binary/binary_utils.cpp:92:41: warning: comparison between signed and
unsigned integer expressions [-Wsign-compare]
../common/include/ignite/common/shared_state.h:343:67: warning: 'auto_ptr' is
deprecated (declared at /usr/include/c++/4.8.2/backward/auto_ptr.h:87)
[-Wdeprecated-declarations]
{code}
The full log is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11653) Remove warnings which appear during CPP compiling
[
https://issues.apache.org/jira/browse/IGNITE-11653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Guseinov updated IGNITE-11653:
Description:
There are two types of warnings:
{code:java}
src/impl/binary/binary_utils.cpp:92:41: warning: comparison between signed and
unsigned integer expressions [-Wsign-compare]
../common/include/ignite/common/shared_state.h:343:67: warning: 'auto_ptr' is
deprecated (declared at /usr/include/c++/4.8.2/backward/auto_ptr.h:87)
[-Wdeprecated-declarations]
{code}
The full log is attached.
was:
There is two types of warnings:
{code:java}
src/impl/binary/binary_utils.cpp:92:41: warning: comparison between signed and
unsigned integer expressions [-Wsign-compare]
../common/include/ignite/common/shared_state.h:343:67: warning: 'auto_ptr' is
deprecated (declared at /usr/include/c++/4.8.2/backward/auto_ptr.h:87)
[-Wdeprecated-declarations]
{code}
The full log is attached.
> Remove warnings which appear during CPP compiling
> -
>
> Key: IGNITE-11653
> URL: https://issues.apache.org/jira/browse/IGNITE-11653
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.7
>Reporter: Roman Guseinov
>Priority: Minor
> Attachments: CPPWarnings.log
>
>
> There are two types of warnings:
>
> {code:java}
> src/impl/binary/binary_utils.cpp:92:41: warning: comparison between signed
> and unsigned integer expressions [-Wsign-compare]
> ../common/include/ignite/common/shared_state.h:343:67: warning: 'auto_ptr' is
> deprecated (declared at /usr/include/c++/4.8.2/backward/auto_ptr.h:87)
> [-Wdeprecated-declarations]
> {code}
> The full log is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11598) Add possibility to have different rebalance thread pool size for nodes in the cluster
[
https://issues.apache.org/jira/browse/IGNITE-11598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804656#comment-16804656
]
Ignite TC Bot commented on IGNITE-11598:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}_Javadoc_{color} [[tests 0 BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=3445126]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3445191buildTypeId=IgniteTests24Java8_RunAll]
> Add possibility to have different rebalance thread pool size for nodes in the
> cluster
> -
>
> Key: IGNITE-11598
> URL: https://issues.apache.org/jira/browse/IGNITE-11598
> Project: Ignite
> Issue Type: Improvement
>Reporter: Evgenii Zhuravlev
>Assignee: Stepachev Maksim
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It can be used for changing this property without downtime when rebalance is
> slow
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9801) Change style of export buttons to new one.
[ https://issues.apache.org/jira/browse/IGNITE-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804647#comment-16804647 ] Ilya Borisov commented on IGNITE-9801: -- [~kuaw26] I approve. > Change style of export buttons to new one. > -- > > Key: IGNITE-9801 > URL: https://issues.apache.org/jira/browse/IGNITE-9801 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Minor > Attachments: image-2018-10-05-17-04-54-354.png > > Original Estimate: 1h > Time Spent: 1h 10m > Remaining Estimate: 0h > > Currenlty buttons are the following. > !https://snag.gy/NHT13u.jpg! > We need to update styling. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file
[ https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-10214: -- Component/s: wizards > Web console: dependency to open source JDBC driver is not generated in the > project's pom file > - > > Key: IGNITE-10214 > URL: https://issues.apache.org/jira/browse/IGNITE-10214 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Attachments: mysql-connector-java-8.0.13.jar, screenshot-1.png, > screenshot-2.png > > > Steps to reproduce: > # import caches from for example MySql DB > # check generated pom file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file
[ https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-10214: -- Fix Version/s: 2.8 > Web console: dependency to open source JDBC driver is not generated in the > project's pom file > - > > Key: IGNITE-10214 > URL: https://issues.apache.org/jira/browse/IGNITE-10214 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Attachments: mysql-connector-java-8.0.13.jar, screenshot-1.png, > screenshot-2.png > > > Steps to reproduce: > # import caches from for example MySql DB > # check generated pom file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9801) Change style of export buttons to new one.
[ https://issues.apache.org/jira/browse/IGNITE-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804638#comment-16804638 ] Alexey Kuznetsov commented on IGNITE-9801: -- [~Klaster_1] Could you review this PR: https://github.com/apache/ignite/pull/6372/files > Change style of export buttons to new one. > -- > > Key: IGNITE-9801 > URL: https://issues.apache.org/jira/browse/IGNITE-9801 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Minor > Attachments: image-2018-10-05-17-04-54-354.png > > Original Estimate: 1h > Time Spent: 1h 10m > Remaining Estimate: 0h > > Currenlty buttons are the following. > !https://snag.gy/NHT13u.jpg! > We need to update styling. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11259) Web console: Actualize grid configurator BinaryTypeConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-11259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-11259: -- Fix Version/s: 2.8 > Web console: Actualize grid configurator BinaryTypeConfiguration > > > Key: IGNITE-11259 > URL: https://issues.apache.org/jira/browse/IGNITE-11259 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Attachments: screenshot-1.png > > > Result for class: org.apache.ignite.binary.BinaryTypeConfiguration > Missed > enumValues -- This message was sent by Atlassian JIRA (v7.6.3#76005)
