[jira] [Commented] (IGNITE-12080) Add extended logging for rebalance
[ https://issues.apache.org/jira/browse/IGNITE-12080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181621#comment-17181621 ] Kirill Tkalenko commented on IGNITE-12080: -- [~ascherbakov] I made new edits by comments and got a visa ^ > Add extended logging for rebalance > -- > > Key: IGNITE-12080 > URL: https://issues.apache.org/jira/browse/IGNITE-12080 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > > We should log information about finished rebalance on demander node. > I'd have in log: > h3. Total information: > # Rebalance duration, rebalance start time/rebalance finish time > # How many nodes were suppliers in rebalance (nodeId, number of supplied > paritions, number of supplied entries, number of bytes, duraton of getting > and processing partitions from supplier) > h3. Information per cache group: > # Rebalance duration, rebalance start time/rebalance finish time > # How many nodes were suppliers in rebalance (nodeId, number of supplied > paritions, list of partition ids with PRIMARY/BACKUP flag, number of supplied > entries, number of bytes, duraton of getting and processing partitions from > supplier) > # Information about each partition distribution (list of nodeIds with > primary/backup flag and marked supplier nodeId) > h3. Information per supplier node: > # How many paritions were requested: > ** Total number > ** Primary/backup distribution (number of primary partitions, number of > backup partitions) > ** Total number of entries > ** Total size partitions in bytes > # How many paritions were requested per cache group: > ** Number of requested partitions > ** Number of entries in partitions > ** Total size of partitions in bytes > ** List of requested partitions with size in bytes, count entries, primary > or backup partition flag -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12080) Add extended logging for rebalance
[
https://issues.apache.org/jira/browse/IGNITE-12080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181619#comment-17181619
]
Ignite TC Bot commented on IGNITE-12080:
{panel:title=Branch: [pull/7705/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7705/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}MVCC Cache 9{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=695]]
* {color:#013220}IgniteCacheMvccTestSuite9:
RebalanceStatisticsTest.testRebalanceStatistics - PASSED{color}
{color:#8b}Cache 9{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=660]]
* {color:#013220}IgniteCacheTestSuite9:
RebalanceStatisticsTest.testRebalanceStatistics - PASSED{color}
{color:#8b}Basic 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5557211]]
* {color:#013220}IgniteBasicTestSuite:
IgniteUtilsSelfTest.testHumanReadableDuration - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
IgniteUtilsSelfTest.testHumanReadableByteCount - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=708buildTypeId=IgniteTests24Java8_RunAll]
> Add extended logging for rebalance
> --
>
> Key: IGNITE-12080
> URL: https://issues.apache.org/jira/browse/IGNITE-12080
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> We should log information about finished rebalance on demander node.
> I'd have in log:
> h3. Total information:
> # Rebalance duration, rebalance start time/rebalance finish time
> # How many nodes were suppliers in rebalance (nodeId, number of supplied
> paritions, number of supplied entries, number of bytes, duraton of getting
> and processing partitions from supplier)
> h3. Information per cache group:
> # Rebalance duration, rebalance start time/rebalance finish time
> # How many nodes were suppliers in rebalance (nodeId, number of supplied
> paritions, list of partition ids with PRIMARY/BACKUP flag, number of supplied
> entries, number of bytes, duraton of getting and processing partitions from
> supplier)
> # Information about each partition distribution (list of nodeIds with
> primary/backup flag and marked supplier nodeId)
> h3. Information per supplier node:
> # How many paritions were requested:
> ** Total number
> ** Primary/backup distribution (number of primary partitions, number of
> backup partitions)
> ** Total number of entries
> ** Total size partitions in bytes
> # How many paritions were requested per cache group:
> ** Number of requested partitions
> ** Number of entries in partitions
> ** Total size of partitions in bytes
> ** List of requested partitions with size in bytes, count entries, primary
> or backup partition flag
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13109) Skip distributed metastorage entries that can not be unmarshalled
[
https://issues.apache.org/jira/browse/IGNITE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-13109:
-
Ignite Flags: Docs Required,Release Notes Required
> Skip distributed metastorage entries that can not be unmarshalled
> -
>
> Key: IGNITE-13109
> URL: https://issues.apache.org/jira/browse/IGNITE-13109
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to skip distributed metastorage entries that can not be unmarshalled
> (created by the old cluster). It leads that nodes can't join to the first
> started node:
> {noformat}
> [SEVERE][main][PersistenceBasicCompatibilityTest1] Got exception while
> starting (will rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2035)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1314)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2063)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1116)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:636)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:562)
> at org.apache.ignite.Ignition.start(Ignition.java:328)
> at
> org.apache.ignite.testframework.junits.multijvm.IgniteNodeRunner.main(IgniteNodeRunner.java:74)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000,
> marsh=JdkMarshaller
> [clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@77b14724],
> reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=5,
> forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
> skipAddrsRandomization=false]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:302)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:948)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2030)
> ... 8 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Unable to
> unmarshal key=ignite.testOldKey
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:2009)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1116)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:427)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2111)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:299)
> ... 10 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13109) Skip distributed metastorage entries that can not be unmarshalled
[
https://issues.apache.org/jira/browse/IGNITE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-13109:
-
Fix Version/s: 2.10
> Skip distributed metastorage entries that can not be unmarshalled
> -
>
> Key: IGNITE-13109
> URL: https://issues.apache.org/jira/browse/IGNITE-13109
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to skip distributed metastorage entries that can not be unmarshalled
> (created by the old cluster). It leads that nodes can't join to the first
> started node:
> {noformat}
> [SEVERE][main][PersistenceBasicCompatibilityTest1] Got exception while
> starting (will rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2035)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1314)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2063)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1116)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:636)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:562)
> at org.apache.ignite.Ignition.start(Ignition.java:328)
> at
> org.apache.ignite.testframework.junits.multijvm.IgniteNodeRunner.main(IgniteNodeRunner.java:74)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000,
> marsh=JdkMarshaller
> [clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@77b14724],
> reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=5,
> forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
> skipAddrsRandomization=false]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:302)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:948)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2030)
> ... 8 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Unable to
> unmarshal key=ignite.testOldKey
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:2009)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1116)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:427)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2111)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:299)
> ... 10 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13109) Skip distributed metastorage entries that can not be unmarshalled
[
https://issues.apache.org/jira/browse/IGNITE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-13109:
-
Summary: Skip distributed metastorage entries that can not be unmarshalled
(was: Skip metastorage entries that can not be unmarshalled)
> Skip distributed metastorage entries that can not be unmarshalled
> -
>
> Key: IGNITE-13109
> URL: https://issues.apache.org/jira/browse/IGNITE-13109
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to skip distributed metastorage entries that can not be unmarshalled
> (created by the old cluster). It leads that nodes can't join to the first
> started node:
> {noformat}
> [SEVERE][main][PersistenceBasicCompatibilityTest1] Got exception while
> starting (will rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2035)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1314)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2063)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1116)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:636)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:562)
> at org.apache.ignite.Ignition.start(Ignition.java:328)
> at
> org.apache.ignite.testframework.junits.multijvm.IgniteNodeRunner.main(IgniteNodeRunner.java:74)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000,
> marsh=JdkMarshaller
> [clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@77b14724],
> reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=5,
> forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
> skipAddrsRandomization=false]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:302)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:948)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2030)
> ... 8 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Unable to
> unmarshal key=ignite.testOldKey
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:2009)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1116)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:427)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2111)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:299)
> ... 10 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13109) Skip metastorage entries that can not be unmarshalled
[
https://issues.apache.org/jira/browse/IGNITE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-13109:
-
Description:
Need to skip distributed metastorage entries that can not be unmarshalled
(created by the old cluster). It leads that nodes can't join to the first
started node:
{noformat}
[SEVERE][main][PersistenceBasicCompatibilityTest1] Got exception while starting
(will rollback startup routine).
class org.apache.ignite.IgniteCheckedException: Failed to start manager:
GridManagerAdapter [enabled=true,
name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2035)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1314)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2063)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1116)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:636)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:562)
at org.apache.ignite.Ignition.start(Ignition.java:328)
at
org.apache.ignite.testframework.junits.multijvm.IgniteNodeRunner.main(IgniteNodeRunner.java:74)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start SPI:
TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000,
marsh=JdkMarshaller
[clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@77b14724],
reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=5,
forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
skipAddrsRandomization=false]
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:302)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:948)
at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2030)
... 8 more
Caused by: class org.apache.ignite.spi.IgniteSpiException: Unable to unmarshal
key=ignite.testOldKey
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:2009)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1116)
at org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:427)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2111)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:299)
... 10 more
{noformat}
was:
Need to skip metastorage entries that can not be unmarshalled (created by the
old cluster). It leads that nodes can't join to the first started node:
{noformat}
[SEVERE][main][PersistenceBasicCompatibilityTest1] Got exception while starting
(will rollback startup routine).
class org.apache.ignite.IgniteCheckedException: Failed to start manager:
GridManagerAdapter [enabled=true,
name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2035)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1314)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2063)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1116)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:636)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:562)
at org.apache.ignite.Ignition.start(Ignition.java:328)
at
org.apache.ignite.testframework.junits.multijvm.IgniteNodeRunner.main(IgniteNodeRunner.java:74)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start SPI:
TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000,
marsh=JdkMarshaller
[clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@77b14724],
reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=5,
forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
skipAddrsRandomization=false]
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:302)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:948)
at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2030)
... 8 more
Caused by: class org.apache.ignite.spi.IgniteSpiException: Unable to unmarshal
key=ignite.testOldKey
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:2009)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1116)
at org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:427)
at
[jira] [Commented] (IGNITE-13174) C++: Add Windows support to CMake build system
[ https://issues.apache.org/jira/browse/IGNITE-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181423#comment-17181423 ] Ivan Daschinskiy commented on IGNITE-13174: --- [~isapego] Igor, is there any progress with TC build on win32 agents? Why this task got stuck? Is any help needed from me? > C++: Add Windows support to CMake build system > -- > > Key: IGNITE-13174 > URL: https://issues.apache.org/jira/browse/IGNITE-13174 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.8.1 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > Ticket IGNITE-13078 adds CMake build system support, but only for Linux. Need > make sure it works on Windows and create TC job for it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10592) [ML] DatasetTrainer#update should be thought over.
[ https://issues.apache.org/jira/browse/IGNITE-10592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-10592: - Reporter: Alexey Zinoviev (was: Artem Malykh) > [ML] DatasetTrainer#update should be thought over. > -- > > Key: IGNITE-10592 > URL: https://issues.apache.org/jira/browse/IGNITE-10592 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Major > Fix For: 3.0 > > > DatasetTrainer#update was designed to contain skeleton for updating models, > whereas concrete behaviour of update is implemented in subclasses by > overriding this skeletons protected components, namely > DatasetTrainer#checkState and DatasetTrainer#updateModel. > We have a problem here: if we retain skeleton method, then it should be > final. But making it final will cut the possibility to write wrappers around > some given DatasetTrainer, because in that case we will not be able to > implement Wrapper#checkState and Wrapper#updateModel by delegation to wrapped > object (this methods have protected access). We need wrappers for stacking > and for bagging for example. > Now in wrappers we have ability to > 1. Override skeleton method, but (maybe) it seems not very clean solution, > since it is no more skeleton method and we loose guarantees that checkState > and updateModel will be used at all; > 2. place wrapper in the same package as DatasetTrainer, but this forces > not-so-good classes structure. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11192) [ML] Use nd4j for matrix inversions and determinants
[ https://issues.apache.org/jira/browse/IGNITE-11192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-11192: - Reporter: Alexey Zinoviev (was: Alexey Platonov) > [ML] Use nd4j for matrix inversions and determinants > > > Key: IGNITE-11192 > URL: https://issues.apache.org/jira/browse/IGNITE-11192 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Major > > From optimization point of view we should use matrix inversions and > determinant computations of dl4j instead of own realization. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11192) [ML] Use nd4j for matrix inversions and determinants
[ https://issues.apache.org/jira/browse/IGNITE-11192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-11192: - Fix Version/s: (was: 3.0) > [ML] Use nd4j for matrix inversions and determinants > > > Key: IGNITE-11192 > URL: https://issues.apache.org/jira/browse/IGNITE-11192 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Alexey Zinoviev >Priority: Major > > From optimization point of view we should use matrix inversions and > determinant computations of dl4j instead of own realization. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10441) Fluent API refactoring.
[
https://issues.apache.org/jira/browse/IGNITE-10441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zinoviev updated IGNITE-10441:
-
Reporter: Alexey Zinoviev (was: Artem Malykh)
> Fluent API refactoring.
> ---
>
> Key: IGNITE-10441
> URL: https://issues.apache.org/jira/browse/IGNITE-10441
> Project: Ignite
> Issue Type: Improvement
> Components: ml
>Reporter: Alexey Zinoviev
>Assignee: Alexey Zinoviev
>Priority: Major
>
> In many classes we have fluent API ("with*" methods). We have following
> problem: these methods should return exactly instance of it's own class
> (otherwise we'll have problems with subclasses, more precisely, if with
> method is declared in class A and we have class B extending A, with method
> (if we do not override it) will return A). Currently we opted to override
> "with" methods in subclasses. There is one solution which is probably more
> elegant, but involves relatively complex generics construction which reduces
> readability:
>
> {code:java}
> class A> {
> Self withX(X x) {
> this.x = x;
>
> return (Self)this;
> }
> class B> extends A {
>// No need to override "withX" here
>Self withY(Y y) {
> this.y = y;
>
> return(Self)this;
>}
> }
> class C> extends B {
>// No need to override "withX" and "withY" methods here.
> }
> //... etc
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10746) [ML] Participate in TensorFlow 2.0 preparation
[ https://issues.apache.org/jira/browse/IGNITE-10746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-10746: - Fix Version/s: (was: 3.0) > [ML] Participate in TensorFlow 2.0 preparation > -- > > Key: IGNITE-10746 > URL: https://issues.apache.org/jira/browse/IGNITE-10746 > Project: Ignite > Issue Type: Task > Components: ml, tensorflow >Affects Versions: 2.7 >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Major > > The next TensorFlow releases starting from 2.0 introduce significant > structure changes: all code from contribution module will be moved into > separate sub-projects. Our "TensorFlow on Apache Ignite" integration code in > contribution module is also moving into so called "tensorflow/io" sub-project > (see [https://github.com/tensorflow/io]). > Almost all things related to this movement is already done by community > members. We need to check that "TensorFlow on Apache Ignite" is still working > after the movement, clarify details about "tensorflow/io" > review/build/publish procedures including Windows build which is not > supported so far. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6707) .NET: Machine learning APIs
[
https://issues.apache.org/jira/browse/IGNITE-6707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zinoviev updated IGNITE-6707:
Fix Version/s: (was: 3.0)
> .NET: Machine learning APIs
> ---
>
> Key: IGNITE-6707
> URL: https://issues.apache.org/jira/browse/IGNITE-6707
> Project: Ignite
> Issue Type: Improvement
> Components: ml, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Zinoviev
>Priority: Major
> Labels: .NET
>
> Propagate ML APIs to .NET (see {{modules\ml\}} in Java).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11871) [ML] IP resolver in TensorFlow cluster manager doesn't work properly
[ https://issues.apache.org/jira/browse/IGNITE-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-11871: - Fix Version/s: (was: 3.0) > [ML] IP resolver in TensorFlow cluster manager doesn't work properly > > > Key: IGNITE-11871 > URL: https://issues.apache.org/jira/browse/IGNITE-11871 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.7, 2.8 >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Critical > > TensorFlow cluster manager requires NodeId to be resolved into IP address or > hostname to pass the address/name to TensorFlow worker. Currently, it uses > strategy "return first" and returns the first available address/name. As a > result of that, in the case when the server has more than one interface > cluster resolver might work incorrectly and return different addresses/names > for the same server. > To fix this problem we need to update > [TensorFlowServerAddressSpec|https://github.com/apache/ignite/blob/master/modules/tensorflow/src/main/java/org/apache/ignite/tensorflow/cluster/spec/TensorFlowServerAddressSpec.java] > so that it returns the same address/name for the same server all the time. > If a server has multiple network interfaces we need to find a "GCD", a > network with all Ignite nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11342) [ML] Umbrella: Create a Python API for Ignite ML
[ https://issues.apache.org/jira/browse/IGNITE-11342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-11342: - Priority: Minor (was: Major) > [ML] Umbrella: Create a Python API for Ignite ML > > > Key: IGNITE-11342 > URL: https://issues.apache.org/jira/browse/IGNITE-11342 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Minor > Fix For: 3.0 > > > Currently Apache Ignite ML provides only Java API. The most popular language > of data analysts is Python. To allow data analysts work with Ignite ML we > need to provide Python API. > The architecture of this Python API should be based on > [Py4J|https://www.py4j.org/] library. This library allows to starts a simple > server of Java side and then translate all calls from Python API into calls > of corresponding Java API and interact with the server via TCP. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11871) [ML] IP resolver in TensorFlow cluster manager doesn't work properly
[ https://issues.apache.org/jira/browse/IGNITE-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-11871: - Priority: Minor (was: Critical) > [ML] IP resolver in TensorFlow cluster manager doesn't work properly > > > Key: IGNITE-11871 > URL: https://issues.apache.org/jira/browse/IGNITE-11871 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.7, 2.8 >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Minor > > TensorFlow cluster manager requires NodeId to be resolved into IP address or > hostname to pass the address/name to TensorFlow worker. Currently, it uses > strategy "return first" and returns the first available address/name. As a > result of that, in the case when the server has more than one interface > cluster resolver might work incorrectly and return different addresses/names > for the same server. > To fix this problem we need to update > [TensorFlowServerAddressSpec|https://github.com/apache/ignite/blob/master/modules/tensorflow/src/main/java/org/apache/ignite/tensorflow/cluster/spec/TensorFlowServerAddressSpec.java] > so that it returns the same address/name for the same server all the time. > If a server has multiple network interfaces we need to find a "GCD", a > network with all Ignite nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13265) Historical iterator for atomic group should transfer few more rows than required
[ https://issues.apache.org/jira/browse/IGNITE-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-13265: --- Reviewer: Alexey Scherbakov > Historical iterator for atomic group should transfer few more rows than > required > > > Key: IGNITE-13265 > URL: https://issues.apache.org/jira/browse/IGNITE-13265 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > On a historical rebalance some updates move from one node to another wherein > this update may have various order in nodes. Reordering can happen in smell > interval, but it cannot avoid at all in current implementation atomic > protocol. > This mean we will reduce a probably of loosing update if we make a margin > from initial counter for the historical iterator on atomic cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13377) WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator is flaky
[ https://issues.apache.org/jira/browse/IGNITE-13377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-13377: --- Summary: WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator is flaky (was: WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator) > WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator is flaky > --- > > Key: IGNITE-13377 > URL: https://issues.apache.org/jira/browse/IGNITE-13377 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13377) WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator
Vladislav Pyatkov created IGNITE-13377: -- Summary: WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator Key: IGNITE-13377 URL: https://issues.apache.org/jira/browse/IGNITE-13377 Project: Ignite Issue Type: Improvement Reporter: Vladislav Pyatkov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13377) WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator
[ https://issues.apache.org/jira/browse/IGNITE-13377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-13377: -- Assignee: Vladislav Pyatkov > WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator > - > > Key: IGNITE-13377 > URL: https://issues.apache.org/jira/browse/IGNITE-13377 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13265) Historical iterator for atomic group should transfer few more rows than required
[
https://issues.apache.org/jira/browse/IGNITE-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181166#comment-17181166
]
Ignite TC Bot commented on IGNITE-13265:
{panel:title=Branch: [pull/8048/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8048/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}MVCC PDS 4{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=384]]
* {color:#013220}IgnitePdsMvccTestSuite4:
SupplyPartitionHistoricallyWithReorderedUpdates.testLoosingUpdateSupplyLatestUpdates
- PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
SupplyPartitionHistoricallyWithReorderedUpdates.testLoosingCreateSupplyLatestUpdates
- PASSED{color}
{color:#8b}PDS 4{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=357]]
* {color:#013220}IgnitePdsTestSuite4:
SupplyPartitionHistoricallyWithReorderedUpdates.testLoosingCreateSupplyLatestUpdates
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
SupplyPartitionHistoricallyWithReorderedUpdates.testLoosingUpdateSupplyLatestUpdates
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=393buildTypeId=IgniteTests24Java8_RunAll]
> Historical iterator for atomic group should transfer few more rows than
> required
>
>
> Key: IGNITE-13265
> URL: https://issues.apache.org/jira/browse/IGNITE-13265
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> On a historical rebalance some updates move from one node to another wherein
> this update may have various order in nodes. Reordering can happen in smell
> interval, but it cannot avoid at all in current implementation atomic
> protocol.
> This mean we will reduce a probably of loosing update if we make a margin
> from initial counter for the historical iterator on atomic cache.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13373) WAL segmentns do not released on releaseHistoryForPreloading()
[ https://issues.apache.org/jira/browse/IGNITE-13373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181159#comment-17181159 ] Ivan Rakov commented on IGNITE-13373: - [~alapin] Merged to master. > WAL segmentns do not released on releaseHistoryForPreloading() > -- > > Key: IGNITE-13373 > URL: https://issues.apache.org/jira/browse/IGNITE-13373 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > * Reserve/releaseHistoryForPreloading() was reworked, now we store oldest > WALPointer that was reserved during reserveHistoryForPreloading in > reservedForPreloading field. As a result it's possible to release wall > reservation on releaseHIstoryForPreloading(). > * searchAndReserveCheckpoints() was slightly refactored: now it returns not > only an earliestValidCheckpoints but also an oldest reservedCheckpoint, so > that there’s no need to recalculate it within reserveHistoryForExchange(). > * -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13345) Warming up strategy
[
https://issues.apache.org/jira/browse/IGNITE-13345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181140#comment-17181140
]
Kirill Tkalenko commented on IGNITE-13345:
--
[~akalashnikov] Get it ^
> Warming up strategy
> ---
>
> Key: IGNITE-13345
> URL: https://issues.apache.org/jira/browse/IGNITE-13345
> Project: Ignite
> Issue Type: New Feature
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: IEP-40
> Fix For: 2.10
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Summary of
> [Dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Cache-warmup-td48582.html]
> # Adding a marker interface
> *org.apache.ignite.configuration.WarmUpConfiguration*;
> # Adding a configuration to
> ##
> *org.apache.ignite.configuration.DataRegionConfiguration#setWarmUpConfiguration*
> ##
> *org.apache.ignite.configuration.DataStorageConfiguration#setDefaultWarmUpConfiguration*
> # Add an internal warm-up interface that will start in [1] after [2] (after
> recovery);
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.configuration.WarmUpConfiguration;
> import org.apache.ignite.internal.GridKernalContext;
> import org.apache.ignite.internal.processors.cache.persistence.DataRegion;
> /**
> * Interface for warming up.
> */
> public interface WarmUpStrategy {
> /**
> * Returns configuration class for mapping to strategy.
> *
> * @return Configuration class.
> */
> Class configClass();
> /**
> * Warm up.
> *
> * @param kernalCtx Kernal context.
> * @param cfg Warm-up configuration.
> * @param regionData region.
> * @throws IgniteCheckedException if faild.
> */
> void warmUp(GridKernalContext kernalCtx, T cfg, DataRegion region) throws
> IgniteCheckedException;
> /**
> * Closing warm up.
> *
> * @throws IgniteCheckedException if faild.
> */
> void close() throws IgniteCheckedException;
> }
> {code}
> # Adding an internal plugin extension for add own strategies;
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
>
> import java.util.Collection;
> import org.apache.ignite.plugin.Extension;
>
> /**
> * Interface for getting warm-up strategies from plugins.
> */
> public interface WarmUpStrategySupplier extends Extension {
> /**
> * Getting warm-up strategies.
> *
> * @return Warm-up strategies.
> */
> Collection strategies();
> }
> {code}
> # Adding strategies:
> ## Without implementation, for the possibility of disabling the warm-up: NoOP
> ## Loading everything while there is RAM with priority to indexes: LoadAll
> # Add a command to "control.sh", to stop current warm-up and cancel all
> others: --warm-up stop in IGNITE-13362
> [1] -
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#afterLogicalUpdatesApplied
> [2] -
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#restorePartitionStates
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13363) GridDhtCacheEntry::toString locks
[
https://issues.apache.org/jira/browse/IGNITE-13363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181137#comment-17181137
]
Ignite TC Bot commented on IGNITE-13363:
{panel:title=Branch: [pull/8153/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8153/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache (Deadlock Detection){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=431]]
* {color:#013220}TxDeadlockDetectionTestSuite:
TxDeadlockOnEntryToStringTest.testDeadlockOnTimeoutWorkerAndToString -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5550180buildTypeId=IgniteTests24Java8_RunAll]
> GridDhtCacheEntry::toString locks
> -
>
> Key: IGNITE-13363
> URL: https://issues.apache.org/jira/browse/IGNITE-13363
> Project: Ignite
> Issue Type: Bug
> Components: networking
>Affects Versions: 2.8.1
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> `GridDhtCacheEntry::toString` locks the entry which may lead to dead locks
> and, I assume, even performance issues.
> We, naturally, call `toString` on everything all the time and it needs to be
> the safest and the lightest possible operation.
> Example of a hang with locking toString:
>
> {{Thread [name="grid-timeout-worker-#71%GRIDC1%", id=98, state=WAITING,
> blockCnt=2, waitCnt=14196]
> Lock
> [object=java.util.concurrent.locks.ReentrantLock$NonfairSync@20c96143,
> ownerName=exchange-worker-#188%GRIDC1%, ownerId=265]
> at java.base@11.0.2/jdk.internal.misc.Unsafe.park(Native Method)
> at
> java.base@11.0.2/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
> at
> java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885)
> at
> java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:917)
> at
> java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1240)
> at
> java.base@11.0.2/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:267)
> at
> app//o.a.i.i.processors.cache.GridCacheMapEntry.lockEntry(GridCacheMapEntry.java:5051)
> at
> app//o.a.i.i.processors.cache.distributed.dht.GridDhtCacheEntry.toString(GridDhtCacheEntry.java:819)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783)
> at
> app//o.a.i.i.processors.cache.transactions.IgniteTxEntry.toString(IgniteTxEntry.java:1273)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at
> java.base@11.0.2/java.lang.StringBuilder.append(StringBuilder.java:168)
> at
> java.base@11.0.2/java.util.AbstractCollection.toString(AbstractCollection.java:473)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783)
> at
> app//o.a.i.i.processors.cache.distributed.GridDistributedTxMapping.toString(GridDistributedTxMapping.java:319)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
>
[jira] [Commented] (IGNITE-13345) Warming up strategy
[
https://issues.apache.org/jira/browse/IGNITE-13345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181134#comment-17181134
]
Ignite TC Bot commented on IGNITE-13345:
{panel:title=Branch: [pull/8148/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8148/head] Base: [master] : New Tests
(18)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}MVCC PDS 4{color} [[tests
9|https://ci.ignite.apache.org/viewLog.html?buildId=257]]
* {color:#013220}IgnitePdsMvccTestSuite4: WarmUpSelfTest.testStopWarmUpByMXBean
- PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testNonPersistentDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testUnknownDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testUnknownDefaultWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testExecutionStrategies - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testAvailableWarmUpStrategies - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4: WarmUpSelfTest.testStopWarmUp -
PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4: LoadAllWarmUpSelfTest.testSimple -
PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
LoadAllWarmUpSelfTest.testMemoryLessPds - PASSED{color}
{color:#8b}PDS 4{color} [[tests
9|https://ci.ignite.apache.org/viewLog.html?buildId=230]]
* {color:#013220}IgnitePdsTestSuite4: LoadAllWarmUpSelfTest.testSimple -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: LoadAllWarmUpSelfTest.testMemoryLessPds -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testNonPersistentDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testUnknownDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testUnknownDefaultWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: WarmUpSelfTest.testExecutionStrategies -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testAvailableWarmUpStrategies - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: WarmUpSelfTest.testStopWarmUp -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: WarmUpSelfTest.testStopWarmUpByMXBean -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5538575buildTypeId=IgniteTests24Java8_RunAll]
> Warming up strategy
> ---
>
> Key: IGNITE-13345
> URL: https://issues.apache.org/jira/browse/IGNITE-13345
> Project: Ignite
> Issue Type: New Feature
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: IEP-40
> Fix For: 2.10
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Summary of
> [Dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Cache-warmup-td48582.html]
> # Adding a marker interface
> *org.apache.ignite.configuration.WarmUpConfiguration*;
> # Adding a configuration to
> ##
> *org.apache.ignite.configuration.DataRegionConfiguration#setWarmUpConfiguration*
> ##
> *org.apache.ignite.configuration.DataStorageConfiguration#setDefaultWarmUpConfiguration*
> # Add an internal warm-up interface that will start in [1] after [2] (after
> recovery);
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.configuration.WarmUpConfiguration;
> import org.apache.ignite.internal.GridKernalContext;
> import org.apache.ignite.internal.processors.cache.persistence.DataRegion;
> /**
> * Interface for warming up.
> */
> public interface WarmUpStrategy {
> /**
> * Returns configuration class for mapping to strategy.
> *
> * @return Configuration class.
> */
> Class configClass();
> /**
> * Warm up.
> *
> * @param kernalCtx Kernal context.
> * @param cfg Warm-up configuration.
> * @param regionData region.
> * @throws IgniteCheckedException if faild.
> */
> void warmUp(GridKernalContext kernalCtx, T cfg, DataRegion region) throws
> IgniteCheckedException;
> /**
> * Closing warm up.
> *
> * @throws IgniteCheckedException if faild.
> */
> void close() throws IgniteCheckedException;
> }
> {code}
> # Adding an internal plugin extension for add own strategies;
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
>
> import java.util.Collection;
> import org.apache.ignite.plugin.Extension;
>
> /**
> * Interface for getting warm-up strategies from plugins.
> */
> public
[jira] [Comment Edited] (IGNITE-13280) Improper index usage, fields enumeration not used with pk index creation.
[
https://issues.apache.org/jira/browse/IGNITE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181128#comment-17181128
]
Stanilovsky Evgeny edited comment on IGNITE-13280 at 8/20/20, 11:40 AM:
[~tledkov-gridgain] looks like TC ok, H2TreeClientIndex already inherit this
behavior as i see.
was (Author: zstan):
[~tledkov-gridgain] looks like TC ok, H2TreeClientIndex already inherit this
behavior s i see.
> Improper index usage, fields enumeration not used with pk index creation.
> -
>
> Key: IGNITE-13280
> URL: https://issues.apache.org/jira/browse/IGNITE-13280
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For example:
> {code:java}
> CREATE TABLE PUBLIC.TEST_TABLE (FIRST_NAME VARCHAR, LAST_NAME VARCHAR,
> ADDRESS VARCHAR, LANG VARCHAR, CONSTRAINT PK_PERSON PRIMARY KEY (FIRST_NAME,
> LAST_NAME));
> CREATE INDEX "idx2" ON PUBLIC.TEST_TABLE (LANG, ADDRESS);
> {code}
> and further explain:
> {code:java}
> SELECT
> "__Z0"."FIRST_NAME" AS "__C0_0",
> "__Z0"."LAST_NAME" AS "__C0_1",
> "__Z0"."ADDRESS" AS "__C0_2",
> "__Z0"."LANG" AS "__C0_3"
> FROM "PUBLIC"."TEST_TABLE" "__Z0"
> /* PUBLIC.IDX2: ADDRESS > 0 */
> WHERE "__Z0"."ADDRESS" > 0
> {code}
> this is erroneous to use "idx2" here, because first index field LANG not
> equals to predicate ADDRESS.
> Looks like this bug brings this ticket [1]
> [1] https://issues.apache.org/jira/browse/IGNITE-10217
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13345) Warming up strategy
[
https://issues.apache.org/jira/browse/IGNITE-13345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181129#comment-17181129
]
Ignite TC Bot commented on IGNITE-13345:
{panel:title=Branch: [pull/8148/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8148/head] Base: [master] : New Tests
(18)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}MVCC PDS 4{color} [[tests
9|https://ci.ignite.apache.org/viewLog.html?buildId=257]]
* {color:#013220}IgnitePdsMvccTestSuite4: WarmUpSelfTest.testStopWarmUpByMXBean
- PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testNonPersistentDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testUnknownDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testUnknownDefaultWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testExecutionStrategies - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testAvailableWarmUpStrategies - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4: WarmUpSelfTest.testStopWarmUp -
PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4: LoadAllWarmUpSelfTest.testSimple -
PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
LoadAllWarmUpSelfTest.testMemoryLessPds - PASSED{color}
{color:#8b}PDS 4{color} [[tests
9|https://ci.ignite.apache.org/viewLog.html?buildId=230]]
* {color:#013220}IgnitePdsTestSuite4: LoadAllWarmUpSelfTest.testSimple -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: LoadAllWarmUpSelfTest.testMemoryLessPds -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testNonPersistentDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testUnknownDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testUnknownDefaultWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: WarmUpSelfTest.testExecutionStrategies -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testAvailableWarmUpStrategies - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: WarmUpSelfTest.testStopWarmUp -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: WarmUpSelfTest.testStopWarmUpByMXBean -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5538575buildTypeId=IgniteTests24Java8_RunAll]
> Warming up strategy
> ---
>
> Key: IGNITE-13345
> URL: https://issues.apache.org/jira/browse/IGNITE-13345
> Project: Ignite
> Issue Type: New Feature
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: IEP-40
> Fix For: 2.10
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Summary of
> [Dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Cache-warmup-td48582.html]
> # Adding a marker interface
> *org.apache.ignite.configuration.WarmUpConfiguration*;
> # Adding a configuration to
> ##
> *org.apache.ignite.configuration.DataRegionConfiguration#setWarmUpConfiguration*
> ##
> *org.apache.ignite.configuration.DataStorageConfiguration#setDefaultWarmUpConfiguration*
> # Add an internal warm-up interface that will start in [1] after [2] (after
> recovery);
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.configuration.WarmUpConfiguration;
> import org.apache.ignite.internal.GridKernalContext;
> import org.apache.ignite.internal.processors.cache.persistence.DataRegion;
> /**
> * Interface for warming up.
> */
> public interface WarmUpStrategy {
> /**
> * Returns configuration class for mapping to strategy.
> *
> * @return Configuration class.
> */
> Class configClass();
> /**
> * Warm up.
> *
> * @param kernalCtx Kernal context.
> * @param cfg Warm-up configuration.
> * @param regionData region.
> * @throws IgniteCheckedException if faild.
> */
> void warmUp(GridKernalContext kernalCtx, T cfg, DataRegion region) throws
> IgniteCheckedException;
> /**
> * Closing warm up.
> *
> * @throws IgniteCheckedException if faild.
> */
> void close() throws IgniteCheckedException;
> }
> {code}
> # Adding an internal plugin extension for add own strategies;
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
>
> import java.util.Collection;
> import org.apache.ignite.plugin.Extension;
>
> /**
> * Interface for getting warm-up strategies from plugins.
> */
> public
[jira] [Commented] (IGNITE-13280) Improper index usage, fields enumeration not used with pk index creation.
[
https://issues.apache.org/jira/browse/IGNITE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181128#comment-17181128
]
Stanilovsky Evgeny commented on IGNITE-13280:
-
[~tledkov-gridgain] looks like TC ok, H2TreeClientIndex already inherit this
behavior s i see.
> Improper index usage, fields enumeration not used with pk index creation.
> -
>
> Key: IGNITE-13280
> URL: https://issues.apache.org/jira/browse/IGNITE-13280
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For example:
> {code:java}
> CREATE TABLE PUBLIC.TEST_TABLE (FIRST_NAME VARCHAR, LAST_NAME VARCHAR,
> ADDRESS VARCHAR, LANG VARCHAR, CONSTRAINT PK_PERSON PRIMARY KEY (FIRST_NAME,
> LAST_NAME));
> CREATE INDEX "idx2" ON PUBLIC.TEST_TABLE (LANG, ADDRESS);
> {code}
> and further explain:
> {code:java}
> SELECT
> "__Z0"."FIRST_NAME" AS "__C0_0",
> "__Z0"."LAST_NAME" AS "__C0_1",
> "__Z0"."ADDRESS" AS "__C0_2",
> "__Z0"."LANG" AS "__C0_3"
> FROM "PUBLIC"."TEST_TABLE" "__Z0"
> /* PUBLIC.IDX2: ADDRESS > 0 */
> WHERE "__Z0"."ADDRESS" > 0
> {code}
> this is erroneous to use "idx2" here, because first index field LANG not
> equals to predicate ADDRESS.
> Looks like this bug brings this ticket [1]
> [1] https://issues.apache.org/jira/browse/IGNITE-10217
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13280) Improper index usage, fields enumeration not used with pk index creation.
[
https://issues.apache.org/jira/browse/IGNITE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181127#comment-17181127
]
Ignite TC Bot commented on IGNITE-13280:
{panel:title=Branch: [pull/8067/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8067/head] Base: [master] : New Tests
(14)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 1{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=5553674]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BasicIndexMultinodeTest.testConditionsWithoutIndexes - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BasicIndexTest.testConditionsWithoutIndexes - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BasicIndexMultinodeTest.testConditionsWithoutIndexesUseProxy - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BasicIndexTest.testConditionsWithoutIndexesUseProxy - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BasicIndexMultinodeTest.testCheckThreeFieldsInPk - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BasicIndexTest.testCheckThreeFieldsInPk - PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5553681]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=64bf00c4-e712-4505-add8-7a6fd95167fa, topVer=0,
msgTemplate=null, span=null, nodeId8=c4750e94, msg=, type=NODE_JOINED,
tstamp=1597851419903], val2=AffinityTopologyVersion [topVer=-65794973751089851,
minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=64bf00c4-e712-4505-add8-7a6fd95167fa, topVer=0,
msgTemplate=null, span=null, nodeId8=c4750e94, msg=, type=NODE_JOINED,
tstamp=1597851419903], val2=AffinityTopologyVersion [topVer=-65794973751089851,
minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=7b9b7670471-e45b3f62-1f3c-4ef1-819c-a2d1699ca4de, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=5ad9fbf2-f260-4add-95c4-6965cf3f78ef, topVer=0, msgTemplate=null,
span=null, nodeId8=5ad9fbf2, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597851419903]], val2=AffinityTopologyVersion
[topVer=-2235269353933157706, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=7b9b7670471-e45b3f62-1f3c-4ef1-819c-a2d1699ca4de, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=5ad9fbf2-f260-4add-95c4-6965cf3f78ef, topVer=0, msgTemplate=null,
span=null, nodeId8=5ad9fbf2, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597851419903]], val2=AffinityTopologyVersion
[topVer=-2235269353933157706, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5553680]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=f5ad5670471-cb6ca029-6274-41bf-af9a-4ec0ab642620, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=76b18b79-ac16-4bde-8267-4b8d7d54b525, topVer=0, msgTemplate=null,
span=null, nodeId8=76b18b79, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597851293896]], val2=AffinityTopologyVersion
[topVer=-7957148310194363136, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=e24c6d69-cc8d-4e1d-8301-caa00b06d2dd, topVer=0,
msgTemplate=null, span=null, nodeId8=42673d37, msg=, type=NODE_JOINED,
tstamp=1597851293896], val2=AffinityTopologyVersion
[topVer=3906886151728009981, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=e24c6d69-cc8d-4e1d-8301-caa00b06d2dd, topVer=0,
msgTemplate=null, span=null, nodeId8=42673d37, msg=, type=NODE_JOINED,
tstamp=1597851293896], val2=AffinityTopologyVersion
[topVer=3906886151728009981, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[jira] [Commented] (IGNITE-13367) meta --remove command usage improvements
[ https://issues.apache.org/jira/browse/IGNITE-13367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181119#comment-17181119 ] Anton Kalashnikov commented on IGNITE-13367: [~sergeychugunov] yes, I took a look at it already. It looks good to me. > meta --remove command usage improvements > > > Key: IGNITE-13367 > URL: https://issues.apache.org/jira/browse/IGNITE-13367 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > Command for removing metadata has the following issues: > # In 'Type not found' scenario it prints long stack traces to console instead > of short information about requested type. > # When used it registers some internal classes which are not supposed to go > through binary metadata registration protocol. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13367) meta --remove command usage improvements
[ https://issues.apache.org/jira/browse/IGNITE-13367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181118#comment-17181118 ] Sergey Chugunov commented on IGNITE-13367: -- [~akalashnikov], Could you take a look at code change and share your thoughts on it? > meta --remove command usage improvements > > > Key: IGNITE-13367 > URL: https://issues.apache.org/jira/browse/IGNITE-13367 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > Command for removing metadata has the following issues: > # In 'Type not found' scenario it prints long stack traces to console instead > of short information about requested type. > # When used it registers some internal classes which are not supposed to go > through binary metadata registration protocol. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13367) meta --remove command usage improvements
[ https://issues.apache.org/jira/browse/IGNITE-13367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-13367: - Component/s: control.sh > meta --remove command usage improvements > > > Key: IGNITE-13367 > URL: https://issues.apache.org/jira/browse/IGNITE-13367 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > Command for removing metadata has the following issues: > # In 'Type not found' scenario it prints long stack traces to console instead > of short information about requested type. > # When used it registers some internal classes which are not supposed to go > through binary metadata registration protocol. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7623) Thin client Java API - async API
[ https://issues.apache.org/jira/browse/IGNITE-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-7623: --- Description: Implement Async version of all the Java thin client APIs: * Cache * Compute * IgniteClient (applicable methods like createCache, destroyCache) was:Implement Async version of all the Java thin client APIs. > Thin client Java API - async API > > > Key: IGNITE-7623 > URL: https://issues.apache.org/jira/browse/IGNITE-7623 > Project: Ignite > Issue Type: Task > Components: clients >Reporter: Alexey Kukushkin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: data, java, thin > Attachments: Screenshot from 2018-10-08 08-46-38.png, Screenshot from > 2018-10-08 08-49-22.png > > Original Estimate: 0.4h > Remaining Estimate: 0.4h > > Implement Async version of all the Java thin client APIs: > * Cache > * Compute > * IgniteClient (applicable methods like createCache, destroyCache) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10789) CacheInterceptor on server node get BinaryObject if put was invoked by ClientCache.
[
https://issues.apache.org/jira/browse/IGNITE-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181091#comment-17181091
]
Stanilovsky Evgeny commented on IGNITE-10789:
-
[~ptupitsyn] thanks fr review , i partially fix and wait your new comments.
> CacheInterceptor on server node get BinaryObject if put was invoked by
> ClientCache.
> ---
>
> Key: IGNITE-10789
> URL: https://issues.apache.org/jira/browse/IGNITE-10789
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Sergey Antonov
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Cache interceptor on server node expects deserialized object, but gets
> BinaryObject in case of put was from thin client.
> The exception is following:
> {noformat}
> [2018-12-21
> 17:25:08,213][ERROR][client-connector-#53%cache.Test20%][ClientListenerNioListener]
> Failed to process client request
> [req=o.a.i.i.processors.platform.client.cache.ClientCachePutRequest@72009659]
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [key]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1313)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1754)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1107)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> at
> org.apache.ignite.internal.processors.platform.client.cache.ClientCachePutRequest.process(ClientCachePutRequest.java:40)
> at
> org.apache.ignite.internal.processors.platform.client.ClientRequestHandler.handle(ClientRequestHandler.java:52)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:174)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:48)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [key]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:252)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:304)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:301)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:394)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1942)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:300)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:482)
> at
>
[jira] [Commented] (IGNITE-12080) Add extended logging for rebalance
[ https://issues.apache.org/jira/browse/IGNITE-12080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181088#comment-17181088 ] Alexey Scherbakov commented on IGNITE-12080: [~ktkale...@gridgain.com] I left a few new comments. Overall looks good. > Add extended logging for rebalance > -- > > Key: IGNITE-12080 > URL: https://issues.apache.org/jira/browse/IGNITE-12080 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > > We should log information about finished rebalance on demander node. > I'd have in log: > h3. Total information: > # Rebalance duration, rebalance start time/rebalance finish time > # How many nodes were suppliers in rebalance (nodeId, number of supplied > paritions, number of supplied entries, number of bytes, duraton of getting > and processing partitions from supplier) > h3. Information per cache group: > # Rebalance duration, rebalance start time/rebalance finish time > # How many nodes were suppliers in rebalance (nodeId, number of supplied > paritions, list of partition ids with PRIMARY/BACKUP flag, number of supplied > entries, number of bytes, duraton of getting and processing partitions from > supplier) > # Information about each partition distribution (list of nodeIds with > primary/backup flag and marked supplier nodeId) > h3. Information per supplier node: > # How many paritions were requested: > ** Total number > ** Primary/backup distribution (number of primary partitions, number of > backup partitions) > ** Total number of entries > ** Total size partitions in bytes > # How many paritions were requested per cache group: > ** Number of requested partitions > ** Number of entries in partitions > ** Total size of partitions in bytes > ** List of requested partitions with size in bytes, count entries, primary > or backup partition flag -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10789) CacheInterceptor on server node get BinaryObject if put was invoked by ClientCache.
[
https://issues.apache.org/jira/browse/IGNITE-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181061#comment-17181061
]
Pavel Tupitsyn commented on IGNITE-10789:
-
[~zstan] please see my comments on GitHub
> CacheInterceptor on server node get BinaryObject if put was invoked by
> ClientCache.
> ---
>
> Key: IGNITE-10789
> URL: https://issues.apache.org/jira/browse/IGNITE-10789
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Sergey Antonov
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Cache interceptor on server node expects deserialized object, but gets
> BinaryObject in case of put was from thin client.
> The exception is following:
> {noformat}
> [2018-12-21
> 17:25:08,213][ERROR][client-connector-#53%cache.Test20%][ClientListenerNioListener]
> Failed to process client request
> [req=o.a.i.i.processors.platform.client.cache.ClientCachePutRequest@72009659]
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [key]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1313)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1754)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1107)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> at
> org.apache.ignite.internal.processors.platform.client.cache.ClientCachePutRequest.process(ClientCachePutRequest.java:40)
> at
> org.apache.ignite.internal.processors.platform.client.ClientRequestHandler.handle(ClientRequestHandler.java:52)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:174)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:48)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [key]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:252)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:304)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:301)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:394)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1942)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:300)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:482)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:442)
> at
[jira] [Commented] (IGNITE-13345) Warming up strategy
[
https://issues.apache.org/jira/browse/IGNITE-13345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180994#comment-17180994
]
Kirill Tkalenko commented on IGNITE-13345:
--
[~akalashnikov] I made edits by comments, waiting for a new visa.
> Warming up strategy
> ---
>
> Key: IGNITE-13345
> URL: https://issues.apache.org/jira/browse/IGNITE-13345
> Project: Ignite
> Issue Type: New Feature
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: IEP-40
> Fix For: 2.10
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Summary of
> [Dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Cache-warmup-td48582.html]
> # Adding a marker interface
> *org.apache.ignite.configuration.WarmUpConfiguration*;
> # Adding a configuration to
> ##
> *org.apache.ignite.configuration.DataRegionConfiguration#setWarmUpConfiguration*
> ##
> *org.apache.ignite.configuration.DataStorageConfiguration#setDefaultWarmUpConfiguration*
> # Add an internal warm-up interface that will start in [1] after [2] (after
> recovery);
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.configuration.WarmUpConfiguration;
> import org.apache.ignite.internal.GridKernalContext;
> import org.apache.ignite.internal.processors.cache.persistence.DataRegion;
> /**
> * Interface for warming up.
> */
> public interface WarmUpStrategy {
> /**
> * Returns configuration class for mapping to strategy.
> *
> * @return Configuration class.
> */
> Class configClass();
> /**
> * Warm up.
> *
> * @param kernalCtx Kernal context.
> * @param cfg Warm-up configuration.
> * @param regionData region.
> * @throws IgniteCheckedException if faild.
> */
> void warmUp(GridKernalContext kernalCtx, T cfg, DataRegion region) throws
> IgniteCheckedException;
> /**
> * Closing warm up.
> *
> * @throws IgniteCheckedException if faild.
> */
> void close() throws IgniteCheckedException;
> }
> {code}
> # Adding an internal plugin extension for add own strategies;
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
>
> import java.util.Collection;
> import org.apache.ignite.plugin.Extension;
>
> /**
> * Interface for getting warm-up strategies from plugins.
> */
> public interface WarmUpStrategySupplier extends Extension {
> /**
> * Getting warm-up strategies.
> *
> * @return Warm-up strategies.
> */
> Collection strategies();
> }
> {code}
> # Adding strategies:
> ## Without implementation, for the possibility of disabling the warm-up: NoOP
> ## Loading everything while there is RAM with priority to indexes: LoadAll
> # Add a command to "control.sh", to stop current warm-up and cancel all
> others: --warm-up stop in IGNITE-13362
> [1] -
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#afterLogicalUpdatesApplied
> [2] -
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#restorePartitionStates
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13375) Operations started on client nodes are not traced.
[
https://issues.apache.org/jira/browse/IGNITE-13375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180993#comment-17180993
]
Ignite TC Bot commented on IGNITE-13375:
{panel:title=Branch: [pull/8170/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8170/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5554734buildTypeId=IgniteTests24Java8_RunAll]
> Operations started on client nodes are not traced.
> --
>
> Key: IGNITE-13375
> URL: https://issues.apache.org/jira/browse/IGNITE-13375
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Root spans should be created on client node like it’s done on server node. I
> suppose that to already existent node join span creation we should add:
> * addMessage
> * node stop
> * custom event
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13204) Java Thin client Kubernetes discovery
[ https://issues.apache.org/jira/browse/IGNITE-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180992#comment-17180992 ] Vladimir Pligin commented on IGNITE-13204: -- Hi [~timonin.maksim]! It's a real pleasure to hear that. Thanks for the update, I'll keep watching the ticket. > Java Thin client Kubernetes discovery > - > > Key: IGNITE-13204 > URL: https://issues.apache.org/jira/browse/IGNITE-13204 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Alexandr >Assignee: Maksim Timonin >Priority: Major > Labels: java > > Thin clients should be able to discover servers from within Kubernetes pod > through k8s API, without specifying any IP addresses. -- This message was sent by Atlassian Jira (v8.3.4#803005)
