[jira] [Commented] (IGNITE-12754) .NET: Thin Client: Service invocation
[
https://issues.apache.org/jira/browse/IGNITE-12754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177410#comment-17177410
]
Ignite TC Bot commented on IGNITE-12754:
{panel:title=Branch: [pull/8151/head] Base: [master] : Possible Blockers
(5)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}JDBC Driver{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5538052]]
{color:#d04437}Control Utility (Zookeeper){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5538146]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5538113]]
* dll: ProjectFilesTest.TestAllCsharpFilesAreIncludedInProject - History for
base branch is absent.
{color:#d04437}Platform .NET{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5538112]]
* exe: ProjectFilesTest.TestAllCsharpFilesAreIncludedInProject - History for
base branch is absent.
{color:#d04437}Interceptor Cache (Full API Config Variations / Basic)*{color}
[[tests 1|https://ci.ignite.apache.org/viewLog.html?buildId=5538049]]
* InterceptorCacheConfigVariationsFullApiTestSuite:
InterceptorCacheConfigVariationsFullApiTest_90.testWithSkipStoreTx - Test has
low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/8151/head] Base: [master] : New Tests
(36)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#8b}Platform .NET (Core Linux){color} [[tests
18|https://ci.ignite.apache.org/viewLog.html?buildId=5538113]]
* {color:#013220}dll: ServicesClientTest.TestJavaServiceCall - PASSED{color}
* {color:#013220}dll:
ServicesClientTest.TestExceptionInServiceIsPropagatedToClient - PASSED{color}
* {color:#013220}dll: ServicesClientTest.TestEmptyClusterGroupThrowsError -
PASSED{color}
* {color:#013220}dll:
ServicesClientTest.TestClusterGroupWithoutMatchingServiceNodesThrowsError -
PASSED{color}
* {color:#013220}dll:
ServicesClientTest.TestClientKeepBinaryReturnsServiceInvocationResultInBinaryMode
- PASSED{color}
* {color:#013220}dll: ServicesClientTest.TestBasicServiceCall - PASSED{color}
* {color:#013220}dll:
ServicesClientTest.TestServerKeepBinaryPassesServerSideArgumentsInBinaryMode -
PASSED{color}
* {color:#013220}dll:
ServicesClientTest.TestServerAndClientKeepBinaryPassesBinaryObjectsOnServerAndClient
- PASSED{color}
* {color:#013220}dll: ServicesClientTest.TestPropertyCalls - PASSED{color}
* {color:#013220}dll: ServicesClientTest.TestOverloadResolution - PASSED{color}
* {color:#013220}dll: ServicesClientTest.TestObjectMethodCall - PASSED{color}
... and 7 new tests
{color:#8b}Platform .NET{color} [[tests
18|https://ci.ignite.apache.org/viewLog.html?buildId=5538112]]
* {color:#013220}exe:
ServicesClientTest.TestServicesWithCustomClusterGroupInvokeOnSpecifiedNodes -
PASSED{color}
* {color:#013220}exe:
ServicesClientTest.TestServerKeepBinaryPassesServerSideArgumentsInBinaryMode -
PASSED{color}
* {color:#013220}exe:
ServicesClientTest.TestServerAndClientKeepBinaryPassesBinaryObjectsOnServerAndClient
- PASSED{color}
* {color:#013220}exe: ServicesClientTest.TestPropertyCalls - PASSED{color}
* {color:#013220}exe: ServicesClientTest.TestOverloadResolution - PASSED{color}
* {color:#013220}exe: ServicesClientTest.TestObjectMethodCall - PASSED{color}
* {color:#013220}exe: ServicesClientTest.TestObjectArrayBinary - PASSED{color}
* {color:#8b}exe: ProjectFilesTest.TestAllCsharpFilesAreIncludedInProject -
FAILED{color}
* {color:#013220}exe: ServicesClientTest.TestVoidMethodCall - PASSED{color}
* {color:#013220}exe:
ServicesClientTest.TestClientKeepBinaryReturnsServiceInvocationResultInBinaryMode
- PASSED{color}
* {color:#013220}exe: ServicesClientTest.TestBasicServiceCall - PASSED{color}
... and 7 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5538147buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Thin Client: Service invocation
> -
>
> Key: IGNITE-12754
> URL: https://issues.apache.org/jira/browse/IGNITE-12754
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, iep-46
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Provide an API to invoke Ignite Services from Thin Clients.
> .NET API:
> {code}
> IIgniteClient.GetServices().GetServiceProxy("name").Bar();
> {code}
> See
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12754) .NET: Thin Client: Service invocation
[
https://issues.apache.org/jira/browse/IGNITE-12754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177346#comment-17177346
]
Pavel Tupitsyn commented on IGNITE-12754:
-
Thin client protocol changes were implemented in IGNITE-13033, this ticket is
only about .NET thin client changes.
> .NET: Thin Client: Service invocation
> -
>
> Key: IGNITE-12754
> URL: https://issues.apache.org/jira/browse/IGNITE-12754
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, iep-46
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Provide an API to invoke Ignite Services from Thin Clients.
> .NET API:
> {code}
> IIgniteClient.GetServices().GetServiceProxy("name").Bar();
> {code}
> See
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12754) .NET: Thin Client: Service invocation
[
https://issues.apache.org/jira/browse/IGNITE-12754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12754:
Description:
Provide an API to invoke Ignite Services from Thin Clients.
.NET API:
{code}
IIgniteClient.GetServices().GetServiceProxy("name").Bar();
{code}
See
https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
was:
Provide an API to invoke Ignite Services from Thin Clients.
.NET API:
{code}
IIgniteClient.GetServices().GetServiceProxy("name").Bar();
{code}
Thin Client protocol:
* One operation, OP_SERVICE_INVOKE
* Takes service name, method name, optionally node ids (cluster projection),
0..n args
See PlatformServices, we just have to combine OP_SERVICE_PROXY with OP_INVOKE
from there in one call.
> .NET: Thin Client: Service invocation
> -
>
> Key: IGNITE-12754
> URL: https://issues.apache.org/jira/browse/IGNITE-12754
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, iep-46
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Provide an API to invoke Ignite Services from Thin Clients.
> .NET API:
> {code}
> IIgniteClient.GetServices().GetServiceProxy("name").Bar();
> {code}
> See
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13360) .NET: Add Timeout to Thin Client services
Pavel Tupitsyn created IGNITE-13360: --- Summary: .NET: Add Timeout to Thin Client services Key: IGNITE-13360 URL: https://issues.apache.org/jira/browse/IGNITE-13360 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Pavel Tupitsyn Current Timeout implementation in Thin Client services is problematic and misleading: Timeout is passed from thin client to GridServiceProxy, and this only works *when the service is on another server node*. E.g. it will never work with deployNodeSingleton and only sometimes work in deployClusterSingleton. If we decide to add a timeout functionality, it should work in any scenario. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13359) .NET: Add GetServiceDescriptors to Thin Client Services
Pavel Tupitsyn created IGNITE-13359: --- Summary: .NET: Add GetServiceDescriptors to Thin Client Services Key: IGNITE-13359 URL: https://issues.apache.org/jira/browse/IGNITE-13359 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Add IServicesClient.GetServiceDescriptors - thin clients should be able to discover available services. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13040) Remove unused parameter from TcpDiscoverySpi.writeToSocket()
[
https://issues.apache.org/jira/browse/IGNITE-13040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177134#comment-17177134
]
Vladimir Steshin edited comment on IGNITE-13040 at 8/13/20, 5:49 PM:
-
[~Kurinov], you can check certain tests locally. Buy you should launch them on
Linux/Mac. As an example
{code:java}
TcpClientDiscoverySpiSelfTest.testReconnectSegmentedAfterJoinTimeoutNetworkError()
{code} fails in this PR and has to be fixed after the code change.
Also, you can try to update master, merge it into the ticket's branch and
re-run the tests. Then, keep re-running blockers. It should help. It could
appear you have to re-run blockers approximately up to 3-5 times. If the keep
failing, try checking the failed tests locally. They might become broken due to
the PR.
Btw., you can find me in Slack: Vladimir St.
was (Author: vladsz83):
[~Kurinov], you can check certain tests locally. Buy you should launch them on
Linux/Mac. As an example
{code:java}
TcpClientDiscoverySpiSelfTest.testReconnectSegmentedAfterJoinTimeoutNetworkError()
{code} fails in this PR and has to be fixed after the code change.
Also, you can try to update master, merge it into the ticket's branch and
re-run the tests. Then, keep re-running blockers. It should help. It could
appear you have to re-run blockers approximately up to 3-5 times. If the keep
failing, try checking the failed tests locally. They might become broken due to
the PR.
> Remove unused parameter from TcpDiscoverySpi.writeToSocket()
>
>
> Key: IGNITE-13040
> URL: https://issues.apache.org/jira/browse/IGNITE-13040
> Project: Ignite
> Issue Type: Improvement
> Environment:
>Reporter: Vladimir Steshin
>Assignee: Aleksey Kurinov
>Priority: Trivial
> Labels: newbie
>
> Unused parameter
> {code:java}
> TcpDiscoveryAbstractMessage msg{code}
> should be removed from
> {code:java}
> TcpDiscoverySpi.writeToSocket(Socket sock, TcpDiscoveryAbstractMessage msg,
> byte[] data, long timeout){code}
> This method seems to send raw data, not a message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13040) Remove unused parameter from TcpDiscoverySpi.writeToSocket()
[
https://issues.apache.org/jira/browse/IGNITE-13040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177134#comment-17177134
]
Vladimir Steshin edited comment on IGNITE-13040 at 8/13/20, 5:47 PM:
-
[~Kurinov], you can check certain tests locally. Buy you should launch them on
Linux/Mac. As an example
{code:java}
TcpClientDiscoverySpiSelfTest.testReconnectSegmentedAfterJoinTimeoutNetworkError()
{code} fails in this PR and has to be fixed after the code change.
Also, you can try to update master, merge it into the ticket's branch and
re-run the tests. Then, keep re-running blockers. It should help. It could
appear you have to re-run blockers approximately up to 3-5 times. If the keep
failing, try checking the failed tests locally. They might become broken due to
the PR.
was (Author: vladsz83):
[~Kurinov], try to update master, merge it into the ticket's branch and re-run
the tests. Then, keep re-running blockers. It should help. It could appear you
have to re-run blockers approximately up to 5 times.
Also, you can check certain tests locally. Buy you should launch them on
Linux/Mac.
> Remove unused parameter from TcpDiscoverySpi.writeToSocket()
>
>
> Key: IGNITE-13040
> URL: https://issues.apache.org/jira/browse/IGNITE-13040
> Project: Ignite
> Issue Type: Improvement
> Environment:
>Reporter: Vladimir Steshin
>Assignee: Aleksey Kurinov
>Priority: Trivial
> Labels: newbie
>
> Unused parameter
> {code:java}
> TcpDiscoveryAbstractMessage msg{code}
> should be removed from
> {code:java}
> TcpDiscoverySpi.writeToSocket(Socket sock, TcpDiscoveryAbstractMessage msg,
> byte[] data, long timeout){code}
> This method seems to send raw data, not a message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13040) Remove unused parameter from TcpDiscoverySpi.writeToSocket()
[
https://issues.apache.org/jira/browse/IGNITE-13040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177134#comment-17177134
]
Vladimir Steshin edited comment on IGNITE-13040 at 8/13/20, 5:37 PM:
-
[~Kurinov], try to update master, merge it into the ticket's branch and re-run
the tests. Then, keep re-running blockers. It should help. It could appear you
have to re-run blockers approximately up to 5 times.
Also, you can check certain tests locally. Buy you should launch them on
Linux/Mac.
was (Author: vladsz83):
[~Kurinov], try to update master, merge it into the ticket's branch and re-run
the tests. Then, keep re-running blockers. It should help. It could appear you
have to re-run blockers approximately up to 5 times.
> Remove unused parameter from TcpDiscoverySpi.writeToSocket()
>
>
> Key: IGNITE-13040
> URL: https://issues.apache.org/jira/browse/IGNITE-13040
> Project: Ignite
> Issue Type: Improvement
> Environment:
>Reporter: Vladimir Steshin
>Assignee: Aleksey Kurinov
>Priority: Trivial
> Labels: newbie
>
> Unused parameter
> {code:java}
> TcpDiscoveryAbstractMessage msg{code}
> should be removed from
> {code:java}
> TcpDiscoverySpi.writeToSocket(Socket sock, TcpDiscoveryAbstractMessage msg,
> byte[] data, long timeout){code}
> This method seems to send raw data, not a message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13040) Remove unused parameter from TcpDiscoverySpi.writeToSocket()
[
https://issues.apache.org/jira/browse/IGNITE-13040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177134#comment-17177134
]
Vladimir Steshin commented on IGNITE-13040:
---
[~Kurinov], try to update master, merge it into the ticket's branch and re-run
the tests. Then, keep re-running blockers. It should help. It could appear you
have to re-run blockers approximately up to 5 times.
> Remove unused parameter from TcpDiscoverySpi.writeToSocket()
>
>
> Key: IGNITE-13040
> URL: https://issues.apache.org/jira/browse/IGNITE-13040
> Project: Ignite
> Issue Type: Improvement
> Environment:
>Reporter: Vladimir Steshin
>Assignee: Aleksey Kurinov
>Priority: Trivial
> Labels: newbie
>
> Unused parameter
> {code:java}
> TcpDiscoveryAbstractMessage msg{code}
> should be removed from
> {code:java}
> TcpDiscoverySpi.writeToSocket(Socket sock, TcpDiscoveryAbstractMessage msg,
> byte[] data, long timeout){code}
> This method seems to send raw data, not a message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12069) Implement file rebalancing management
[
https://issues.apache.org/jira/browse/IGNITE-12069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177120#comment-17177120
]
Pavel Pereslegin edited comment on IGNITE-12069 at 8/13/20, 4:11 PM:
-
This task has been temporarily held. Testing shows the following results:
* Index rebuilding takes a very long time, in some cases, the index rebuilding
time (24 threads) exceeds the full rebalance of the index cache (24 threads).
* Most of the time is spent on rebuilding the index, the current solution can
be modified to transfer the index partition (if the distribution of partitions
on the demander matches the supplier partition distribution (affinity can be
configured for such cases on PARTITIONED caches)).
* Index rebuilding can be started earlier on a separate (single) partition
(after this mode is implemented), this should slightly smooth out the index
rebuild time.
* A critical slowdown in the transfer of partition files on hdd drives was
revealed, especially with minor concurrent cache updates (in some cases, the
speed drops tenfold and long timeouts occur, which lead to an abnormal
termination of the process).
* Single-threaded file transfer mode can be switched to multi-threaded (which
should lead to a multiple increase in file transfer speed), because hard disks
on demander are loaded slightly.
was (Author: xtern):
This task has been temporarily held because our testing shows the following
results:
* Index rebuilding takes a very long time, in some cases, the index rebuilding
time (24 threads) exceeds the full rebalance of the index cache (24 threads).
* Most of the time is spent on rebuilding the index, the current solution can
be modified to transfer the index partition (if the distribution of partitions
on the demander matches the supplier partition distribution (affinity can be
configured for such cases on PARTITIONED caches)).
* Index rebuilding can be started earlier on a separate (single) partition
(after this mode is implemented), this should slightly smooth out the index
rebuild time.
* A critical slowdown in the transfer of partition files on hdd drives was
revealed, especially with minor concurrent cache updates (in some cases, the
speed drops tenfold and long timeouts occur, which lead to an abnormal
termination of the process).
* Single-threaded file transfer mode can be switched to multi-threaded (which
should lead to a multiple increase in file transfer speed), because hard disks
on demander are loaded slightly.
> Implement file rebalancing management
> -
>
> Key: IGNITE-12069
> URL: https://issues.apache.org/jira/browse/IGNITE-12069
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maxim Muzafarov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-28
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Preloader}} should be able to do the following:
> # build the map of partitions and corresponding supplier nodes from which
> partitions will be loaded;
> # switch cache data storage to {{no-op}} and back to original (HWM must be
> fixed here for the needs of historical rebalance) under the checkpoint and
> keep the partition update counter for each partition;
> # run async the eviction indexes for the list of collected partitions;
> # send a request message to each node one by one with the list of partitions
> to load;
> # wait for files received (listening for the transmission handler);
> # run rebuild indexes async over the receiving partitions;
> # run historical rebalance from LWM to HWM collected above (LWM can be read
> from the received file meta page);
> h5. Stage 1. implement "read-only" mode for cache data store. Implement data
> store reinitialization on the updated persistence file.
> h6. Tests:
> - Switching under load.
> - Check re-initialization of partition on new file.
> - Check that in read-only mode
> ** H2 indexes are not updated
> ** update counter is updated
> ** cache entries eviction works fine
> ** tx/atomic updates on this partition works fine in cluster
> h5. Stage 2. Build Map for request partitions by node, add message that will
> be sent to the supplier. Send a demand request, handle the response, switch
> datastore when file received.
> h6. Tests:
> - Check partition consistency after receiving a file.
> - File transmission under load.
> - Failover - some of the partitions have been switched, the node has been
> restarted, rebalancing is expected to continue only for fully loaded large
> partitions through the historical rebalance, for the rest of partitions it
> should restart from the beginning.
> h5. Stage 3. Add WAL history reservation on supplier. Add historical
> rebalance triggering (LWM (partition) -
[jira] [Comment Edited] (IGNITE-12069) Implement file rebalancing management
[
https://issues.apache.org/jira/browse/IGNITE-12069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177120#comment-17177120
]
Pavel Pereslegin edited comment on IGNITE-12069 at 8/13/20, 4:09 PM:
-
This task has been temporarily held because our testing shows the following
results:
* Index rebuilding takes a very long time, in some cases, the index rebuilding
time (24 threads) exceeds the full rebalance of the index cache (24 threads).
* Most of the time is spent on rebuilding the index, the current solution can
be modified to transfer the index partition (if the distribution of partitions
on the demander matches the supplier partition distribution (affinity can be
configured for such cases on PARTITIONED caches)).
* Index rebuilding can be started earlier on a separate (single) partition
(after this mode is implemented), this should slightly smooth out the index
rebuild time.
* A critical slowdown in the transfer of partition files on hdd drives was
revealed, especially with minor concurrent cache updates (in some cases, the
speed drops tenfold and long timeouts occur, which lead to an abnormal
termination of the process).
* Single-threaded file transfer mode can be switched to multi-threaded (which
should lead to a multiple increase in file transfer speed), because hard disks
on demander are loaded slightly.
was (Author: xtern):
This task has been temporarily held because our testing shows the following
results:
* Index rebuilding takes a very long time, in some cases, the index rebuilding
time (24 threads) exceeds the full rebalance of the index cache (24 threads).
* Both in the case of load and no-load, most of the time is spent on
rebuilding the index, the current solution can be modified to transfer the
index partition (if the distribution of partitions on the demander matches the
supplier partition distribution (affinity can be configured for such cases on
PARTITIONED caches)).
* Index rebuilding can be started earlier on a separate (single) partition
(after this mode is implemented), this should slightly smooth out the index
rebuild time.
* A critical slowdown in the transfer of partition files on hdd drives was
revealed, especially with minor concurrent cache updates (in some cases, the
speed drops tenfold and long timeouts occur, which lead to an abnormal
termination of the process).
* Single-threaded file transfer mode can be switched to multi-threaded (which
should lead to a multiple increase in file transfer speed), because hard disks
on demander are loaded slightly.
> Implement file rebalancing management
> -
>
> Key: IGNITE-12069
> URL: https://issues.apache.org/jira/browse/IGNITE-12069
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maxim Muzafarov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-28
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Preloader}} should be able to do the following:
> # build the map of partitions and corresponding supplier nodes from which
> partitions will be loaded;
> # switch cache data storage to {{no-op}} and back to original (HWM must be
> fixed here for the needs of historical rebalance) under the checkpoint and
> keep the partition update counter for each partition;
> # run async the eviction indexes for the list of collected partitions;
> # send a request message to each node one by one with the list of partitions
> to load;
> # wait for files received (listening for the transmission handler);
> # run rebuild indexes async over the receiving partitions;
> # run historical rebalance from LWM to HWM collected above (LWM can be read
> from the received file meta page);
> h5. Stage 1. implement "read-only" mode for cache data store. Implement data
> store reinitialization on the updated persistence file.
> h6. Tests:
> - Switching under load.
> - Check re-initialization of partition on new file.
> - Check that in read-only mode
> ** H2 indexes are not updated
> ** update counter is updated
> ** cache entries eviction works fine
> ** tx/atomic updates on this partition works fine in cluster
> h5. Stage 2. Build Map for request partitions by node, add message that will
> be sent to the supplier. Send a demand request, handle the response, switch
> datastore when file received.
> h6. Tests:
> - Check partition consistency after receiving a file.
> - File transmission under load.
> - Failover - some of the partitions have been switched, the node has been
> restarted, rebalancing is expected to continue only for fully loaded large
> partitions through the historical rebalance, for the rest of partitions it
> should restart from the beginning.
> h5. Stage 3. Add WAL history reservation on supplier. Add
[jira] [Commented] (IGNITE-12069) Implement file rebalancing management
[
https://issues.apache.org/jira/browse/IGNITE-12069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177120#comment-17177120
]
Pavel Pereslegin commented on IGNITE-12069:
---
This task has been temporarily held because our testing shows the following
results:
* Index rebuilding takes a very long time, in some cases, the index rebuilding
time (24 threads) exceeds the full rebalance of the index cache (24 threads).
* Both in the case of load and no-load, most of the time is spent on
rebuilding the index, the current solution can be modified to transfer the
index partition (if the distribution of partitions on the demander matches the
supplier partition distribution (affinity can be configured for such cases on
PARTITIONED caches)).
* Index rebuilding can be started earlier on a separate (single) partition
(after this mode is implemented), this should slightly smooth out the index
rebuild time.
* A critical slowdown in the transfer of partition files on hdd drives was
revealed, especially with minor concurrent cache updates (in some cases, the
speed drops tenfold and long timeouts occur, which lead to an abnormal
termination of the process).
* Single-threaded file transfer mode can be switched to multi-threaded (which
should lead to a multiple increase in file transfer speed), because hard disks
on demander are loaded slightly.
> Implement file rebalancing management
> -
>
> Key: IGNITE-12069
> URL: https://issues.apache.org/jira/browse/IGNITE-12069
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maxim Muzafarov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-28
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Preloader}} should be able to do the following:
> # build the map of partitions and corresponding supplier nodes from which
> partitions will be loaded;
> # switch cache data storage to {{no-op}} and back to original (HWM must be
> fixed here for the needs of historical rebalance) under the checkpoint and
> keep the partition update counter for each partition;
> # run async the eviction indexes for the list of collected partitions;
> # send a request message to each node one by one with the list of partitions
> to load;
> # wait for files received (listening for the transmission handler);
> # run rebuild indexes async over the receiving partitions;
> # run historical rebalance from LWM to HWM collected above (LWM can be read
> from the received file meta page);
> h5. Stage 1. implement "read-only" mode for cache data store. Implement data
> store reinitialization on the updated persistence file.
> h6. Tests:
> - Switching under load.
> - Check re-initialization of partition on new file.
> - Check that in read-only mode
> ** H2 indexes are not updated
> ** update counter is updated
> ** cache entries eviction works fine
> ** tx/atomic updates on this partition works fine in cluster
> h5. Stage 2. Build Map for request partitions by node, add message that will
> be sent to the supplier. Send a demand request, handle the response, switch
> datastore when file received.
> h6. Tests:
> - Check partition consistency after receiving a file.
> - File transmission under load.
> - Failover - some of the partitions have been switched, the node has been
> restarted, rebalancing is expected to continue only for fully loaded large
> partitions through the historical rebalance, for the rest of partitions it
> should restart from the beginning.
> h5. Stage 3. Add WAL history reservation on supplier. Add historical
> rebalance triggering (LWM (partition) - HWM (read-only)).
> h6. Tests:
> - File rebalancing under load and without on atomic/tx caches. (check
> existing PDS-enabled rebalancing tests).
> - Ensure that MVCC groups use regular rebalancing.
> - The rebalancing on the unstable topology and failures of the
> supplier/demander nodes at different stages.
> - (compatibility) The old nodes should use regular rebalancing.
> h5. Stage 4 Eviction and rebuild of indexes.
> h6. Tests:
> - File rebalancing of caches with H2 indexes.
> - Check consistency of H2 indexes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization
[ https://issues.apache.org/jira/browse/IGNITE-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov reassigned IGNITE-5038: -- Assignee: Ivan Rakov (was: Mirza Aliev) > BinaryMarshaller might need to use context class loader for deserialization > --- > > Key: IGNITE-5038 > URL: https://issues.apache.org/jira/browse/IGNITE-5038 > Project: Ignite > Issue Type: Improvement > Components: binary >Affects Versions: 2.0 >Reporter: Dmitry Karachentsev >Assignee: Ivan Rakov >Priority: Major > Labels: features > Attachments: results-compound-20170802.zip, > results-compound-20170808.zip > > Time Spent: 1.5h > Remaining Estimate: 0h > > There is a special use case discussed on the dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224 > According to the use case, BinaryMarshaller might need to try to deserialize > an object using a context class loader if it failed to do so with a custom > classloader (`IgniteConfiguration.getClassLoader()`) or the system one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13356) Documentation Change needed: PluginProvider loading changed from 2.8.1
[ https://issues.apache.org/jira/browse/IGNITE-13356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis A. Magda updated IGNITE-13356: Component/s: documentation > Documentation Change needed: PluginProvider loading changed from 2.8.1 > -- > > Key: IGNITE-13356 > URL: https://issues.apache.org/jira/browse/IGNITE-13356 > Project: Ignite > Issue Type: Improvement > Components: documentation, platforms >Affects Versions: 2.8.1 >Reporter: Veena Mithare >Priority: Major > > There seems to be two conflicting documentation on loading the plugin > provider : > 1. The first way as shown in this documentation > [https://apacheignite.readme.io/docs/plugins] : > uses the Java Service Loader to load the plugin provider . It loads the > plugin configurations through the ignite configuration and hence needs to > use getPluginConfigurations to get the right configuration for the plugin. > _*Concern*_ : igniteconfiguration.getPluginConfigurations is deprecated in > 2.8.1 > 2. The second way : igniteconfiguration.getPluginConfigurations has been > deprecated in 2.8.1 . The recommended way of sending configuration is by > calling igniteconfiguration.setPluginProvider . > Please note there was no 'setPluginProvider' method in the versions prior to > 2.8.1. > ( > [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/IgniteConfiguration.html#getPluginConfigurations--] > ) > _*Concern*_ : 2.8.1 plugin documentation talks about using service loader > framework. [https://apacheignite.readme.io/docs/plugins]. If we use > setPluginProvider, there is no need to load plugin provider through java > service loader. > > As per the latest conversation on Ignite Users , it was suggested that I > raise a documentation improvement to use the approach 2 above . This Jira is > to change the documentation at [https://apacheignite.readme.io/docs/plugins > so that it reflects approach 2.|https://apacheignite.readme.io/docs/plugins] > [http://apache-ignite-users.70518.x6.nabble.com/2-8-1-Loading-Plugin-Provider-td33370.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13330) Document java thin client features implemented in 2.8 and 2.9 release
[ https://issues.apache.org/jira/browse/IGNITE-13330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177094#comment-17177094 ] Aleksey Plekhanov commented on IGNITE-13330: [~Artem Budnikov], I've fixed your comments, please have a look again. > Document java thin client features implemented in 2.8 and 2.9 release > - > > Key: IGNITE-13330 > URL: https://issues.apache.org/jira/browse/IGNITE-13330 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: important > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Document implemented in 2.8 and 2.9 release features for java thin client: > * Partition awareness > * Cluster API > * Cluster group API > * Compute > * Services -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization
[
https://issues.apache.org/jira/browse/IGNITE-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177086#comment-17177086
]
Ignite TC Bot commented on IGNITE-5038:
---
{panel:title=Branch: [pull/8146/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8146/head] Base: [master] : New Tests
(16)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 3{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5535463]]
* {color:#013220}IgniteBinaryObjectsCacheTestSuite3:
BinaryClassLoaderMultiJvmTest.testClientLoadClassFromBinary - PASSED{color}
* {color:#013220}IgniteBinaryObjectsCacheTestSuite3:
BinaryClassLoaderMultiJvmTest.testLoadClassFromBinary - PASSED{color}
* {color:#013220}IgniteBinaryObjectsCacheTestSuite3:
BinaryClassLoaderTest.testClientLoadClassFromBinary - PASSED{color}
* {color:#013220}IgniteBinaryObjectsCacheTestSuite3:
BinaryClassLoaderTest.testLoadClassFromBinary - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5535494]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=ba70143e371-1060fb3f-d8a1-44a9-8374-2460100ff1f1, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=93bb11d9-6db9-4183-8ca7-fe5bd1fc48d4, topVer=0, msgTemplate=null,
span=null, nodeId8=93bb11d9, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597245556647]], val2=AffinityTopologyVersion
[topVer=7712774926676635059, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=f569d24e-8439-493d-ae79-4cfda46347c3, topVer=0,
msgTemplate=null, span=null, nodeId8=e3036cdb, msg=, type=NODE_JOINED,
tstamp=1597245556647], val2=AffinityTopologyVersion
[topVer=4043289110866827658, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=f569d24e-8439-493d-ae79-4cfda46347c3, topVer=0,
msgTemplate=null, span=null, nodeId8=e3036cdb, msg=, type=NODE_JOINED,
tstamp=1597245556647], val2=AffinityTopologyVersion
[topVer=4043289110866827658, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=ba70143e371-1060fb3f-d8a1-44a9-8374-2460100ff1f1, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=93bb11d9-6db9-4183-8ca7-fe5bd1fc48d4, topVer=0, msgTemplate=null,
span=null, nodeId8=93bb11d9, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597245556647]], val2=AffinityTopologyVersion
[topVer=7712774926676635059, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5535495]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=9dd1727f-7188-4bc8-ba1c-a97a03757d4c, topVer=0,
msgTemplate=null, span=null, nodeId8=febf8310, msg=, type=NODE_JOINED,
tstamp=1597245604529], val2=AffinityTopologyVersion
[topVer=-532717008369219942, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=9dd1727f-7188-4bc8-ba1c-a97a03757d4c, topVer=0,
msgTemplate=null, span=null, nodeId8=febf8310, msg=, type=NODE_JOINED,
tstamp=1597245604529], val2=AffinityTopologyVersion
[topVer=-532717008369219942, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=55ccb43e371-68bc7ffc-8b12-455c-9851-4762685df930, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=9f018365-0dde-4888-9dca-ae8e0e62401f, topVer=0, msgTemplate=null,
span=null, nodeId8=9f018365, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597245604529]], val2=AffinityTopologyVersion
[topVer=347831288372854690, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=55ccb43e371-68bc7ffc-8b12-455c-9851-4762685df930, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[jira] [Commented] (IGNITE-13328) Control.sh bash script swallow return code of CommandHandler and always return 0
[
https://issues.apache.org/jira/browse/IGNITE-13328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177083#comment-17177083
]
Ivan Daschinskiy commented on IGNITE-13328:
---
[~vveider] Actually, I partially reverted IGNITE-12367 for contro.sh. So I just
preserve original formatting
> Control.sh bash script swallow return code of CommandHandler and always
> return 0
>
>
> Key: IGNITE-13328
> URL: https://issues.apache.org/jira/browse/IGNITE-13328
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Blocker
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After merging
> [IGNITE-12367|https://issues.apache.org/jira/browse/IGNITE-12367],
> control.sh always return 0, despite the fact that CommandHandler returns
> correct code.
> For example:
> Ignite 2.8.1
> {code}
> Failed to execute baseline command='collect'
> Latest topology update failed.
> Connection to cluster failed. Latest topology update failed.
> Command [BASELINE] finished with code: 2
> Control utility has completed execution at: 2020-08-05T15:01:34.123
> Execution time: 26627 ms
> >>> echo $?
> 0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13328) Control.sh bash script swallow return code of CommandHandler and always return 0
[
https://issues.apache.org/jira/browse/IGNITE-13328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177081#comment-17177081
]
Ivan Daschinskiy commented on IGNITE-13328:
---
[~vveider] I think that because we execute command in while loop. So we should
do {{set -o errexit}} at least. But other options also make sense for
control.sh. I can't understand why we disable them not only for ignite.sh?
BTW check in IF always false if we doesn't set IGNITE_SCRIPT_STRICT_MODE
(doesn't set by default)
> Control.sh bash script swallow return code of CommandHandler and always
> return 0
>
>
> Key: IGNITE-13328
> URL: https://issues.apache.org/jira/browse/IGNITE-13328
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Blocker
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After merging
> [IGNITE-12367|https://issues.apache.org/jira/browse/IGNITE-12367],
> control.sh always return 0, despite the fact that CommandHandler returns
> correct code.
> For example:
> Ignite 2.8.1
> {code}
> Failed to execute baseline command='collect'
> Latest topology update failed.
> Connection to cluster failed. Latest topology update failed.
> Command [BASELINE] finished with code: 2
> Control utility has completed execution at: 2020-08-05T15:01:34.123
> Execution time: 26627 ms
> >>> echo $?
> 0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13328) Control.sh bash script swallow return code of CommandHandler and always return 0
[
https://issues.apache.org/jira/browse/IGNITE-13328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177068#comment-17177068
]
Peter Ivanov commented on IGNITE-13328:
---
What is the reason why IF clause prevented from correct exit code in case of
error?
Also, I'd recommended to specify set options in one line, i.e. {code}
#!/usr/bin/env bash
set -o nounset; set -o errexit; set -o pipefail; set -o errtrace; set -o
functrace
...
{code}
> Control.sh bash script swallow return code of CommandHandler and always
> return 0
>
>
> Key: IGNITE-13328
> URL: https://issues.apache.org/jira/browse/IGNITE-13328
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Blocker
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After merging
> [IGNITE-12367|https://issues.apache.org/jira/browse/IGNITE-12367],
> control.sh always return 0, despite the fact that CommandHandler returns
> correct code.
> For example:
> Ignite 2.8.1
> {code}
> Failed to execute baseline command='collect'
> Latest topology update failed.
> Connection to cluster failed. Latest topology update failed.
> Command [BASELINE] finished with code: 2
> Control utility has completed execution at: 2020-08-05T15:01:34.123
> Execution time: 26627 ms
> >>> echo $?
> 0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13151) Checkpointer code refactoring: extracting classes from GridCacheDatabaseSharedManager
[ https://issues.apache.org/jira/browse/IGNITE-13151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177015#comment-17177015 ] Anton Kalashnikov commented on IGNITE-13151: [~agura] Thanks for your comment, but there are no new classes, in fact, all of these classes were extracted mostly from GridCacheDatabaseSharedManager with minimum changes. So I agree that javadocs are not perfect and I improved it a little but the further improvement I suggest to do in my next task because these classes will be changed. It is the same about naming - I left old names for easier the review but in the further, it is a high probability that I will find a more suitable name for them. [~sergey-chugunov] can you recheck these changes(there are not a lot of changes since the last time) and merge it to master. > Checkpointer code refactoring: extracting classes from > GridCacheDatabaseSharedManager > - > > Key: IGNITE-13151 > URL: https://issues.apache.org/jira/browse/IGNITE-13151 > Project: Ignite > Issue Type: Sub-task > Components: persistence >Reporter: Sergey Chugunov >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-47 > Time Spent: 10m > Remaining Estimate: 0h > > Checkpointer is at the center of Ignite persistence subsystem and more people > from the community understand it the better means it is more stable and more > efficient. > However for now checkpointer code sits inside of > GridCacheDatabaseSharedManager class and is entangled with this higher-level > and more general component. > To take a step forward to more modular checkpointer we need to do two things: > # Move checkpointer code outside database manager to a separate class. > (That's what this ticket is about.) > # Create a well-defined API of checkpointer that will allow us to create new > implementations of checkpointer in the future. An example of this is new > checkpointer implementation needed for defragmentation feature purposes. > (Should be done in a separate ticket) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13352) ScanQueryIterator needs closing or resources will leak
[ https://issues.apache.org/jira/browse/IGNITE-13352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176950#comment-17176950 ] Ilya Kasnacheev commented on IGNITE-13352: -- I'm OK with it. > ScanQueryIterator needs closing or resources will leak > -- > > Key: IGNITE-13352 > URL: https://issues.apache.org/jira/browse/IGNITE-13352 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.8.1 >Reporter: Ilya Kasnacheev >Priority: Major > > Let's document it in javadoc. > Let's override IgniteCache.iterator() and declare it to return > GridCloseableIterator > which should be moved (copied?) from internal package to public API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13328) Control.sh bash script swallow return code of CommandHandler and always return 0
[
https://issues.apache.org/jira/browse/IGNITE-13328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176949#comment-17176949
]
Ivan Daschinskiy commented on IGNITE-13328:
---
[~agura] [~vveider] Hi! Could you please look at this patch? It is quite
simple. Unfortunatelly, It is impossible to test it on TC, but I thoroughly
tested using new ducktape module. There are a few tests of control.sh
[here|https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/control_utility_test.py]
> Control.sh bash script swallow return code of CommandHandler and always
> return 0
>
>
> Key: IGNITE-13328
> URL: https://issues.apache.org/jira/browse/IGNITE-13328
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Blocker
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After merging
> [IGNITE-12367|https://issues.apache.org/jira/browse/IGNITE-12367],
> control.sh always return 0, despite the fact that CommandHandler returns
> correct code.
> For example:
> Ignite 2.8.1
> {code}
> Failed to execute baseline command='collect'
> Latest topology update failed.
> Connection to cluster failed. Latest topology update failed.
> Command [BASELINE] finished with code: 2
> Control utility has completed execution at: 2020-08-05T15:01:34.123
> Execution time: 26627 ms
> >>> echo $?
> 0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-13011) .NET: Thin client Kubernetes discovery
[
https://issues.apache.org/jira/browse/IGNITE-13011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13011:
--
Comment: was deleted
(was: [~agura] [~vveider] Hi! Could you please look at this patch? It is quite
simple. Unfortunatelly, It is impossible to test it on TC, but I thoroughly
tested using new ducktape module. There are a few tests of control.sh
[here|https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/control_utility_test.py])
> .NET: Thin client Kubernetes discovery
> --
>
> Key: IGNITE-13011
> URL: https://issues.apache.org/jira/browse/IGNITE-13011
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Thin clients should be able to discover servers from within Kubernetes pod
> through k8s API, without specifying any IP addresses.
> E.g. we can retrieve pod list from within the pod like this:
> {code}
> curl -v --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H
> "Authorization: Bearer $(cat
> /var/run/secrets/kubernetes.io/serviceaccount/token)"
> https://kubernetes.default.svc/api/v1/namespaces/MY_NAMESPACE/pods
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13358) Improvements for partition clearing related parts
Alexey Scherbakov created IGNITE-13358: -- Summary: Improvements for partition clearing related parts Key: IGNITE-13358 URL: https://issues.apache.org/jira/browse/IGNITE-13358 Project: Ignite Issue Type: Improvement Reporter: Alexey Scherbakov Assignee: Alexey Scherbakov We have several issues related to a partition clearing worth fixing. 1. PartitionsEvictManager doent's provide obvious guarantees for a correctness when a node or a cache group is stopped while partitions are concurrently clearing. 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write lock, which is deadlock prone, because we currently require write lock to destroy a partition. 3. GridDhtLocalPartition contains a lot of messy code related to partition clearing, most notably ClearFuture, but the clearing is done by PartitionsEvictManager. We should get rid of a clearing code in GridDhtLocalPartition. This should also bring better code readility and help understand what happening during a clearing. 4. Currently moving partitions are cleared before rebalancing in the order different to rebalanceOrder, breaking the contract. 5. The clearing logic for for moving partitions (before rebalancing) seems incorrect: it's possible to lost updates received during clearing. 6. To clear partitions before full rebalancing we utilize same threads as for a partition eviction. This can slow rebalancing even if we have resources. Better to clear partitions in the rebalance pool (explicitely dedicated by user). 7. It's possible to reserve a renting partition, which have absolutely no meaning. All operations with a renting partitions (except clearing) are a waste of resources. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13011) .NET: Thin client Kubernetes discovery
[
https://issues.apache.org/jira/browse/IGNITE-13011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176937#comment-17176937
]
Ivan Daschinskiy commented on IGNITE-13011:
---
[~agura] [~vveider] Hi! Could you please look at this patch? It is quite
simple. Unfortunatelly, It is impossible to test it on TC, but I thoroughly
tested using new ducktape module. There are a few tests of control.sh
[here|https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/control_utility_test.py]
> .NET: Thin client Kubernetes discovery
> --
>
> Key: IGNITE-13011
> URL: https://issues.apache.org/jira/browse/IGNITE-13011
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Thin clients should be able to discover servers from within Kubernetes pod
> through k8s API, without specifying any IP addresses.
> E.g. we can retrieve pod list from within the pod like this:
> {code}
> curl -v --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H
> "Authorization: Bearer $(cat
> /var/run/secrets/kubernetes.io/serviceaccount/token)"
> https://kubernetes.default.svc/api/v1/namespaces/MY_NAMESPACE/pods
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13357) .NET: Add includeExpired to ContinuousQuery
Pavel Tupitsyn created IGNITE-13357: --- Summary: .NET: Add includeExpired to ContinuousQuery Key: IGNITE-13357 URL: https://issues.apache.org/jira/browse/IGNITE-13357 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Add includeExpired flag to ContinuousQuery (thick and thin modes) to track entry expiration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13354) Add ClusterMetrics to the new framework
[ https://issues.apache.org/jira/browse/IGNITE-13354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita reassigned IGNITE-13354: Assignee: Amelchev Nikita (was: Nikolay Izhikov) > Add ClusterMetrics to the new framework > --- > > Key: IGNITE-13354 > URL: https://issues.apache.org/jira/browse/IGNITE-13354 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Amelchev Nikita >Priority: Major > Labels: IEP-35 > > We need to provide to the user information about cluster topology such as: > * TopologyVersion > * TotalNodes > * TotalBaselineNodes > * TotalServerNodes > * TotalClientNodes > * ActiveBaselineNodes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13356) Documentation Change needed: PluginProvider loading changed from 2.8.1
Veena Mithare created IGNITE-13356: -- Summary: Documentation Change needed: PluginProvider loading changed from 2.8.1 Key: IGNITE-13356 URL: https://issues.apache.org/jira/browse/IGNITE-13356 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.8.1 Reporter: Veena Mithare There seems to be two conflicting documentation on loading the plugin provider : 1. The first way as shown in this documentation [https://apacheignite.readme.io/docs/plugins] : uses the Java Service Loader to load the plugin provider . It loads the plugin configurations through the ignite configuration and hence needs to use getPluginConfigurations to get the right configuration for the plugin. _*Concern*_ : igniteconfiguration.getPluginConfigurations is deprecated in 2.8.1 2. The second way : igniteconfiguration.getPluginConfigurations has been deprecated in 2.8.1 . The recommended way of sending configuration is by calling igniteconfiguration.setPluginProvider . Please note there was no 'setPluginProvider' method in the versions prior to 2.8.1. ( [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/IgniteConfiguration.html#getPluginConfigurations--] ) _*Concern*_ : 2.8.1 plugin documentation talks about using service loader framework. [https://apacheignite.readme.io/docs/plugins]. If we use setPluginProvider, there is no need to load plugin provider through java service loader. As per the latest conversation on Ignite Users , it was suggested that I raise a documentation improvement to use the approach 2 above . This Jira is to change the documentation at [https://apacheignite.readme.io/docs/plugins so that it reflects approach 2.|https://apacheignite.readme.io/docs/plugins] [http://apache-ignite-users.70518.x6.nabble.com/2-8-1-Loading-Plugin-Provider-td33370.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13353) DynamicCacheChangeBatch invokes partition validation for all caches
[
https://issues.apache.org/jira/browse/IGNITE-13353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176839#comment-17176839
]
Ignite TC Bot commented on IGNITE-13353:
{panel:title=Branch: [pull/8144/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8144/head] Base: [master] : New Tests
(10)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}MVCC PDS 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5534976]]
* {color:#013220}IgnitePdsMvccTestSuite4:
NoUnnecessaryRebalancesTest.testNoRebalancesOnCacheCreation - PASSED{color}
{color:#8b}PDS 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5536513]]
* {color:#013220}IgnitePdsTestSuite4:
NoUnnecessaryRebalancesTest.testNoRebalancesOnCacheCreation - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5534962]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=3d36148e-5587-4996-8b15-cb77a9c4d92b, topVer=0,
msgTemplate=null, span=null, nodeId8=2428b790, msg=, type=NODE_JOINED,
tstamp=1597184797620], val2=AffinityTopologyVersion
[topVer=-2686011315096501745, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=3d36148e-5587-4996-8b15-cb77a9c4d92b, topVer=0,
msgTemplate=null, span=null, nodeId8=2428b790, msg=, type=NODE_JOINED,
tstamp=1597184797620], val2=AffinityTopologyVersion
[topVer=-2686011315096501745, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=5ccfbafd371-2c92b47c-6fe6-4f72-ad62-1299e80b4d1e, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=42c2de87-94ad-48a7-9524-4d6453067850, topVer=0, msgTemplate=null,
span=null, nodeId8=42c2de87, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597184797620]], val2=AffinityTopologyVersion
[topVer=1126681775562055818, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=5ccfbafd371-2c92b47c-6fe6-4f72-ad62-1299e80b4d1e, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=42c2de87-94ad-48a7-9524-4d6453067850, topVer=0, msgTemplate=null,
span=null, nodeId8=42c2de87, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597184797620]], val2=AffinityTopologyVersion
[topVer=1126681775562055818, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5534963]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=075d0afd371-4e1a6245-38c8-453f-8182-18e27a589298, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=2b44ebaf-731e-4d1e-8e59-1793a45ec863, topVer=0, msgTemplate=null,
span=null, nodeId8=2b44ebaf, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597184726380]], val2=AffinityTopologyVersion
[topVer=3149311455830838403, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=a6de11d9-e33d-4840-aa91-dab3d9c6b380, topVer=0,
msgTemplate=null, span=null, nodeId8=b61c9573, msg=, type=NODE_JOINED,
tstamp=1597184726380], val2=AffinityTopologyVersion
[topVer=-5597788594291829357, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=a6de11d9-e33d-4840-aa91-dab3d9c6b380, topVer=0,
msgTemplate=null, span=null, nodeId8=b61c9573, msg=, type=NODE_JOINED,
tstamp=1597184726380], val2=AffinityTopologyVersion
[topVer=-5597788594291829357, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=075d0afd371-4e1a6245-38c8-453f-8182-18e27a589298, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=2b44ebaf-731e-4d1e-8e59-1793a45ec863, topVer=0, msgTemplate=null,
span=null, nodeId8=2b44ebaf, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597184726380]],
[jira] [Updated] (IGNITE-13355) Now .net does not have RemoteListen,now how to is used to achieve this function?
[ https://issues.apache.org/jira/browse/IGNITE-13355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 杨鹏 updated IGNITE-13355: Issue Type: Bug (was: Improvement) > Now .net does not have RemoteListen,now how to is used to achieve this > function? > > > Key: IGNITE-13355 > URL: https://issues.apache.org/jira/browse/IGNITE-13355 > Project: Ignite > Issue Type: Bug > Components: cache > Environment: OS: Windows 10 10.0 amd64 > Version:2.8.0.5 >Reporter: 杨鹏 >Priority: Major > > Now .net does not have RemoteListen,now how to is used to achieve this > function? > https://issues.apache.org/jira/browse/IGNITE-1682 .Net: Remove RemoteListen > from Events API . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13355) Now .net does not have RemoteListen,now how to is used to achieve this function?
杨鹏 created IGNITE-13355: --- Summary: Now .net does not have RemoteListen,now how to is used to achieve this function? Key: IGNITE-13355 URL: https://issues.apache.org/jira/browse/IGNITE-13355 Project: Ignite Issue Type: Improvement Components: cache Environment: OS: Windows 10 10.0 amd64 Version:2.8.0.5 Reporter: 杨鹏 Now .net does not have RemoteListen,now how to is used to achieve this function? https://issues.apache.org/jira/browse/IGNITE-1682 .Net: Remove RemoteListen from Events API . -- This message was sent by Atlassian Jira (v8.3.4#803005)
