[jira] [Closed] (IGNITE-12364) Migrate JMS module to ignite-extensions
[ https://issues.apache.org/jira/browse/IGNITE-12364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saikat Maitra closed IGNITE-12364. -- > Migrate JMS module to ignite-extensions > --- > > Key: IGNITE-12364 > URL: https://issues.apache.org/jira/browse/IGNITE-12364 > Project: Ignite > Issue Type: Sub-task > Components: streaming >Reporter: Saikat Maitra >Assignee: Saikat Maitra >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Migrate JMS module to ignite-extensions > [https://github.com/apache/ignite-extensions] > Details: > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations] > Discussion : > [http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Proposal-for-Ignite-Extensions-as-a-separate-Bahir-module-or-Incubator-project-td44064.html#a44107] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12718) Python Thin Client: add an ability to specify keyfile password
[
https://issues.apache.org/jira/browse/IGNITE-12718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12718:
---
Fix Version/s: (was: 2.10)
2.9
> Python Thin Client: add an ability to specify keyfile password
> --
>
> Key: IGNITE-12718
> URL: https://issues.apache.org/jira/browse/IGNITE-12718
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.8
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Minor
> Labels: Python, SSL, TLS
> Fix For: 2.9
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In pyignite, there is no way to specify password for keyfile being used to
> establish TLS connection to Ignite cluster. If keyfile is encrypted, then
> OpenSSL library prompts for password interactively.
> In order to add configurable password, one can set up explicit {{SSLContext}}
> instead of {{ssl.wrap_socket}} call.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13369) .NET: Local node info is not updated on client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-13369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17187828#comment-17187828
]
Aleksey Plekhanov commented on IGNITE-13369:
Cherry-picked to 2.9
> .NET: Local node info is not updated on client reconnect
>
>
> Key: IGNITE-13369
> URL: https://issues.apache.org/jira/browse/IGNITE-13369
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{Ignite._locNode}} field caches local node information, and this cache info
> is not updated on client reconnect. We should remove cached info on every
> disconnect.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12718) Python Thin Client: add an ability to specify keyfile password
[
https://issues.apache.org/jira/browse/IGNITE-12718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17187825#comment-17187825
]
Aleksey Plekhanov commented on IGNITE-12718:
Cherry-picked to 2.9
> Python Thin Client: add an ability to specify keyfile password
> --
>
> Key: IGNITE-12718
> URL: https://issues.apache.org/jira/browse/IGNITE-12718
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.8
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Minor
> Labels: Python, SSL, TLS
> Fix For: 2.9
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In pyignite, there is no way to specify password for keyfile being used to
> establish TLS connection to Ignite cluster. If keyfile is encrypted, then
> OpenSSL library prompts for password interactively.
> In order to add configurable password, one can set up explicit {{SSLContext}}
> instead of {{ssl.wrap_socket}} call.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13369) .NET: Local node info is not updated on client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-13369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13369:
---
Fix Version/s: (was: 2.10)
2.9
> .NET: Local node info is not updated on client reconnect
>
>
> Key: IGNITE-13369
> URL: https://issues.apache.org/jira/browse/IGNITE-13369
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{Ignite._locNode}} field caches local node information, and this cache info
> is not updated on client reconnect. We should remove cached info on every
> disconnect.
--
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=17187792#comment-17187792 ] Alexey Scherbakov commented on IGNITE-13265: [~v.pyatkov] Overall the approach looks good. I've left several minor comments. Fix them and we are good for merging. > 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: 2h 20m > 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. > The final algorithm of choosing correct WAL pointer for atomic cache with the > margin is: > 1) Find a checkpoint which contains a counter, that necessary for history > rebalance (just like a transactional cache) > 2) If the checkpoint starts with a counter less than which is necessary with > margin, we are taking it. > 3) If we are going out of WAL reservation, we are taking current. > 4) Otherwise we are looking of a previous checkpoint and taking it if it > starts from a counter less than next checkpoint (from the point 2). > 5) Else we are still taking the checkpoint from the point 2. > Other words (points 3-5) the algorithm tries to check only one previous > checkpoint and takes it if that has different counter. > *UPD:* > After a discussion I found a bug connected with using a WAL which was not > reserved before for preloading. > I added an explicitly checking this and an appropriate test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13308) C++: Thin client transactions
[ https://issues.apache.org/jira/browse/IGNITE-13308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17187775#comment-17187775 ] Igor Sapego commented on IGNITE-13308: -- Great, merging to master... > C++: Thin client transactions > - > > Key: IGNITE-13308 > URL: https://issues.apache.org/jira/browse/IGNITE-13308 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Ivan Daschinskiy >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: C++, iep-34 > Fix For: 2.10 > > Time Spent: 4.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13308) C++: Thin client transactions
[
https://issues.apache.org/jira/browse/IGNITE-13308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17187737#comment-17187737
]
Ignite TC Bot commented on IGNITE-13308:
{panel:title=Branch: [pull/8118/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8118/head] Base: [master] : New Tests
(18)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5535186]]
* {color:#013220}IgniteRestHandlerTestSuite:
GridQueryCommandHandlerTest.testNullCache - PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5535220]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=0d4c214a-0a29-4e5c-aed9-afe1501b69c1, topVer=0,
msgTemplate=null, span=null, nodeId8=4bb32685, msg=, type=NODE_JOINED,
tstamp=1597212247090], val2=AffinityTopologyVersion
[topVer=-346328448263174824, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=0d4c214a-0a29-4e5c-aed9-afe1501b69c1, topVer=0,
msgTemplate=null, span=null, nodeId8=4bb32685, msg=, type=NODE_JOINED,
tstamp=1597212247090], val2=AffinityTopologyVersion
[topVer=-346328448263174824, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=c7ede41e371-8f914aa7-634a-470a-8047-67af042f51c2, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=e793e599-948d-46b4-8f1c-23a50dbcafcb, topVer=0, msgTemplate=null,
span=null, nodeId8=e793e599, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597212247090]], val2=AffinityTopologyVersion
[topVer=-9190901870636014568, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=c7ede41e371-8f914aa7-634a-470a-8047-67af042f51c2, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=e793e599-948d-46b4-8f1c-23a50dbcafcb, topVer=0, msgTemplate=null,
span=null, nodeId8=e793e599, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597212247090]], val2=AffinityTopologyVersion
[topVer=-9190901870636014568, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5535219]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=bed0715c-0e9b-41b9-8732-f6f277c9073c, topVer=0,
msgTemplate=null, span=null, nodeId8=16670220, msg=, type=NODE_JOINED,
tstamp=1597212260080], val2=AffinityTopologyVersion
[topVer=8094284346878037296, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=9b4ce41e371-df862fe8-e79a-4148-93c1-9c25ceae3357, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=6e4a3032-01d1-48d3-bedf-95f6dcdac7b2, topVer=0, msgTemplate=null,
span=null, nodeId8=6e4a3032, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597212260080]], val2=AffinityTopologyVersion
[topVer=3572399462961787821, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=9b4ce41e371-df862fe8-e79a-4148-93c1-9c25ceae3357, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=6e4a3032-01d1-48d3-bedf-95f6dcdac7b2, topVer=0, msgTemplate=null,
span=null, nodeId8=6e4a3032, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597212260080]], val2=AffinityTopologyVersion
[topVer=3572399462961787821, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=bed0715c-0e9b-41b9-8732-f6f277c9073c, topVer=0,
msgTemplate=null, span=null, nodeId8=16670220, msg=, type=NODE_JOINED,
tstamp=1597212260080], val2=AffinityTopologyVersion
[topVer=8094284346878037296, minorTopVer=0]]] - PASSED{color}
{color:#8b}Platform C++ CMake (Linux){color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=5574726]]
*
[jira] [Commented] (IGNITE-13308) C++: Thin client transactions
[ https://issues.apache.org/jira/browse/IGNITE-13308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17187738#comment-17187738 ] Stanilovsky Evgeny commented on IGNITE-13308: - [~isapego] last run is ok https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCWinX64Release_IgniteTests24Java8=pull%2F8118%2Fhead=buildTypeStatusDiv > C++: Thin client transactions > - > > Key: IGNITE-13308 > URL: https://issues.apache.org/jira/browse/IGNITE-13308 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Ivan Daschinskiy >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: C++, iep-34 > Fix For: 2.10 > > Time Spent: 4.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13308) C++: Thin client transactions
[ https://issues.apache.org/jira/browse/IGNITE-13308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17187659#comment-17187659 ] Igor Sapego commented on IGNITE-13308: -- [~zstan] 2 last comments, after they are fixed we can proceed with merge I believe. > C++: Thin client transactions > - > > Key: IGNITE-13308 > URL: https://issues.apache.org/jira/browse/IGNITE-13308 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Ivan Daschinskiy >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: C++, iep-34 > Fix For: 2.10 > > Time Spent: 4.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-12894:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Cannot use IgniteAtomicSequence in Ignite services
> --
>
> Key: IGNITE-12894
> URL: https://issues.apache.org/jira/browse/IGNITE-12894
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: sbcf
> Fix For: 2.9
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> h2. Repro Steps
> Execute the below steps in default service deployment mode and in
> discovery-based service deployment mode.
> Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to
> switch to the discovery-based service deployment mode.
> * Create a service initializing an {{IgniteAtomicService}} in method
> {{Service#init()}} and using the {{IgniteAtomicService}} in a business method.
> * Start an Ignite node with the service specified in the IgniteConfiguration
> * Invoke the service's business method on the Ignite node
> h3. Actual Result
> h4. In Default Service Deployment Mode
> Deadlock on the business method invocation
> h4. In Discovery-Based Service Deployment Mode
> The method invocation fails with {{IgniteException: Failed to find deployed
> service: IgniteTestService}}
> h2. Reproducer
> h3. Test.java
> {code:java}
> public interface Test {
> String sayHello(String name);
> }
> {code}
> h3. IgniteTestService.java
> {code:java}
> public class IgniteTestService implements Test, Service {
> private @IgniteInstanceResource Ignite ignite;
> private IgniteAtomicSequence seq;
> @Override public void cancel(ServiceContext ctx) {
> }
> @Override public void init(ServiceContext ctx) throws
> InterruptedException {
> seq = ignite.atomicSequence("TestSeq", 0, true);
> }
> @Override public void execute(ServiceContext ctx) {
> }
> @Override public String sayHello(String name) {
> return "Hello, " + name + "! #" + seq.getAndIncrement();
> }
> }
> {code}
> h3. Reproducer.java
> {code:java}
> public class Reproducer {
> public static void main(String[] args) {
> IgniteConfiguration igniteCfg = new IgniteConfiguration()
> .setServiceConfiguration(
> new ServiceConfiguration()
> .setName(IgniteTestService.class.getSimpleName())
> .setMaxPerNodeCount(1)
> .setTotalCount(0)
> .setService(new IgniteTestService())
> )
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(new
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
> );
> try (Ignite ignite = Ignition.start(igniteCfg)) {
>
> ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(),
> Test.class, false)
> .sayHello("World");
> }
> }
> }
> {code}
> h2. Workaround
> Specifying a service wait timeout solves the problem in the discovery-based
> service deployment mode (but not in the default deployment mode):
> {code:java}
>
> ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(),
> Test.class, false, 1_000)
> .sayHello("World");
> {code}
> This workaround cannot be used in Ignite.NET clients since .NET
> {{GetServiceProxy}} API does not support the service wait timeout, which is
> hard-coded to 0 on the server side.
> h2. Full Exception in Discovery-Based Service Deployment Mode
> {noformat}
> [01:08:54,653][SEVERE][services-deployment-worker-#52][IgniteServiceProcessor]
> Failed to initialize service (service will not be deployed):
> IgniteTestService
> class org.apache.ignite.IgniteInterruptedException: Got interrupted while
> waiting for future to complete.
> at
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:888)
> at
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:886)
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1062)
> at
> org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3999)
> at
> org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3985)
> at Sandbox.Net.IgniteTestService.init(IgniteTestService.java:17)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.redeploy(IgniteServiceProcessor.java:1188)
> at
>
[jira] [Updated] (IGNITE-13366) Special mode for maintenance of Ignite node. Employing Maintenance Mode for clearing corrupted PDS files.
[ https://issues.apache.org/jira/browse/IGNITE-13366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-13366: - Summary: Special mode for maintenance of Ignite node. Employing Maintenance Mode for clearing corrupted PDS files. (was: Prohibit unconditional automatic deletion of data files if WAL was disabled prior to node's shutdown) > Special mode for maintenance of Ignite node. Employing Maintenance Mode for > clearing corrupted PDS files. > - > > Key: IGNITE-13366 > URL: https://issues.apache.org/jira/browse/IGNITE-13366 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.8.1 >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Critical > Fix For: 2.10 > > Original Estimate: 168h > Time Spent: 10m > Remaining Estimate: 167h 50m > > If node with persistence is stopped when WAL was disabled for a cache (no > matters because of rebalancing in progress or by explicit user request) on > next node start all data files of that cache are removed automatically and > unconditionally. > This behavior may be unexpected for users as they may not understand all > consequences of disabling WAL locally (for rebalancing) or globally (via > IgniteCluster API call). Also it is not smart enough as there is no point in > deleting consistent data files. > We should change this behavior to the following list: no automatic deletions > whatsoever. If data files are consistent (equivalent to: no checkpoint was > running when node was stopped) start up normally. If data files are > corrupted, don't let the node start. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13366) Special mode for maintenance of Ignite node. Employing Maintenance Mode for clearing corrupted PDS files.
[ https://issues.apache.org/jira/browse/IGNITE-13366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-13366: - Labels: IEP-53 (was: ) > Special mode for maintenance of Ignite node. Employing Maintenance Mode for > clearing corrupted PDS files. > - > > Key: IGNITE-13366 > URL: https://issues.apache.org/jira/browse/IGNITE-13366 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.8.1 >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Critical > Labels: IEP-53 > Fix For: 2.10 > > Original Estimate: 168h > Time Spent: 10m > Remaining Estimate: 167h 50m > > If node with persistence is stopped when WAL was disabled for a cache (no > matters because of rebalancing in progress or by explicit user request) on > next node start all data files of that cache are removed automatically and > unconditionally. > This behavior may be unexpected for users as they may not understand all > consequences of disabling WAL locally (for rebalancing) or globally (via > IgniteCluster API call). Also it is not smart enough as there is no point in > deleting consistent data files. > We should change this behavior to the following list: no automatic deletions > whatsoever. If data files are consistent (equivalent to: no checkpoint was > running when node was stopped) start up normally. If data files are > corrupted, don't let the node start. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13366) Prohibit unconditional automatic deletion of data files if WAL was disabled prior to node's shutdown
[ https://issues.apache.org/jira/browse/IGNITE-13366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-13366: - Issue Type: New Feature (was: Task) > Prohibit unconditional automatic deletion of data files if WAL was disabled > prior to node's shutdown > > > Key: IGNITE-13366 > URL: https://issues.apache.org/jira/browse/IGNITE-13366 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.8.1 >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Critical > Fix For: 2.10 > > Original Estimate: 168h > Time Spent: 10m > Remaining Estimate: 167h 50m > > If node with persistence is stopped when WAL was disabled for a cache (no > matters because of rebalancing in progress or by explicit user request) on > next node start all data files of that cache are removed automatically and > unconditionally. > This behavior may be unexpected for users as they may not understand all > consequences of disabling WAL locally (for rebalancing) or globally (via > IgniteCluster API call). Also it is not smart enough as there is no point in > deleting consistent data files. > We should change this behavior to the following list: no automatic deletions > whatsoever. If data files are consistent (equivalent to: no checkpoint was > running when node was stopped) start up normally. If data files are > corrupted, don't let the node start. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13358) Improvements for partition clearing related parts
[ https://issues.apache.org/jira/browse/IGNITE-13358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17187494#comment-17187494 ] Alexey Scherbakov commented on IGNITE-13358: [~agoncharuk] Can you look at this ? > 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 >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > 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. Better to submit such > partitions for clearing to the rebalancing pool before each group starts to > rebalance. This will allow faster rebalancing (accoring to configured > rebalance pool size) and will provide rebalanceOrder guarantees. > 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. > 8. Partition eviction causes system pool tasks starvation if a number of > threads in system pool=1. This can break crucial functionality. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13358) Improvements for partition clearing related parts
[
https://issues.apache.org/jira/browse/IGNITE-13358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17187491#comment-17187491
]
Ignite TC Bot commented on IGNITE-13358:
{panel:title=Branch: [pull/8186/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8186/head] Base: [master] : New Tests
(33)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}MVCC Cache 7{color} [[tests
16|https://ci.ignite.apache.org/viewLog.html?buildId=5573494]]
* {color:#013220}IgniteCacheMvccTestSuite7:
BlockedEvictionsTest.testStopNodeDuringEviction_2 - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7:
BlockedEvictionsTest.testStopCache_Volatile - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7:
BlockedEvictionsTest.testStopNodeDuringEviction - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7:
BlockedEvictionsTest.testStopCache_Persistence - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7:
BlockedEvictionsTest.testCacheGroupDestroy_Volatile - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7:
EvictionWhilePartitionGroupIsReservedTest.testGroupReservationStartClient -
PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7:
EvictionWhilePartitionGroupIsReservedTest.testGroupReservationStartClient_2 -
PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7:
EvictionWhilePartitionGroupIsReservedTest.testGroupReservation - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7:
EvictionWhilePartitionGroupIsReservedTest.testGroupReservation_2 - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7:
BlockedEvictionsTest.testDeactivation_Persistence - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite7:
BlockedEvictionsTest.testFailureHandler - PASSED{color}
... and 5 new tests
{color:#8b}Cache 7{color} [[tests
16|https://ci.ignite.apache.org/viewLog.html?buildId=5573290]]
* {color:#013220}IgniteCacheTestSuite7:
BlockedEvictionsTest.testStopNodeDuringEviction_2 - PASSED{color}
* {color:#013220}IgniteCacheTestSuite7:
EvictionWhilePartitionGroupIsReservedTest.testGroupReservationStartClient -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite7:
EvictionWhilePartitionGroupIsReservedTest.testGroupReservationStartClient_2 -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite7:
BlockedEvictionsTest.testCacheGroupDestroy_Volatile - PASSED{color}
* {color:#013220}IgniteCacheTestSuite7:
EvictionWhilePartitionGroupIsReservedTest.testGroupReservation - PASSED{color}
* {color:#013220}IgniteCacheTestSuite7:
EvictionWhilePartitionGroupIsReservedTest.testGroupReservation_2 - PASSED{color}
* {color:#013220}IgniteCacheTestSuite7:
BlockedEvictionsTest.testStopCache_Volatile - PASSED{color}
* {color:#013220}IgniteCacheTestSuite7:
BlockedEvictionsTest.testStopNodeDuringEviction - PASSED{color}
* {color:#013220}IgniteCacheTestSuite7:
BlockedEvictionsTest.testStopCache_Persistence - PASSED{color}
* {color:#013220}IgniteCacheTestSuite7:
BlockedEvictionsTest.testDeactivation_Persistence - PASSED{color}
* {color:#013220}IgniteCacheTestSuite7: BlockedEvictionsTest.testFailureHandler
- PASSED{color}
... and 5 new tests
{color:#8b}Cache 6{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5573289]]
* {color:#013220}IgniteCacheTestSuite6:
IgniteExchangeLatchManagerCoordinatorFailTest.testCoordinatorFailoverDuringPMEAfterServerLatchCompleted
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5573340buildTypeId=IgniteTests24Java8_RunAll]
> 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
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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
[jira] [Commented] (IGNITE-13308) C++: Thin client transactions
[
https://issues.apache.org/jira/browse/IGNITE-13308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17187465#comment-17187465
]
Ignite TC Bot commented on IGNITE-13308:
{panel:title=Branch: [pull/8118/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8118/head] Base: [master] : New Tests
(18)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5535186]]
* {color:#013220}IgniteRestHandlerTestSuite:
GridQueryCommandHandlerTest.testNullCache - PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5535220]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=0d4c214a-0a29-4e5c-aed9-afe1501b69c1, topVer=0,
msgTemplate=null, span=null, nodeId8=4bb32685, msg=, type=NODE_JOINED,
tstamp=1597212247090], val2=AffinityTopologyVersion
[topVer=-346328448263174824, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=0d4c214a-0a29-4e5c-aed9-afe1501b69c1, topVer=0,
msgTemplate=null, span=null, nodeId8=4bb32685, msg=, type=NODE_JOINED,
tstamp=1597212247090], val2=AffinityTopologyVersion
[topVer=-346328448263174824, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=c7ede41e371-8f914aa7-634a-470a-8047-67af042f51c2, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=e793e599-948d-46b4-8f1c-23a50dbcafcb, topVer=0, msgTemplate=null,
span=null, nodeId8=e793e599, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597212247090]], val2=AffinityTopologyVersion
[topVer=-9190901870636014568, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=c7ede41e371-8f914aa7-634a-470a-8047-67af042f51c2, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=e793e599-948d-46b4-8f1c-23a50dbcafcb, topVer=0, msgTemplate=null,
span=null, nodeId8=e793e599, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597212247090]], val2=AffinityTopologyVersion
[topVer=-9190901870636014568, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5535219]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=bed0715c-0e9b-41b9-8732-f6f277c9073c, topVer=0,
msgTemplate=null, span=null, nodeId8=16670220, msg=, type=NODE_JOINED,
tstamp=1597212260080], val2=AffinityTopologyVersion
[topVer=8094284346878037296, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=9b4ce41e371-df862fe8-e79a-4148-93c1-9c25ceae3357, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=6e4a3032-01d1-48d3-bedf-95f6dcdac7b2, topVer=0, msgTemplate=null,
span=null, nodeId8=6e4a3032, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597212260080]], val2=AffinityTopologyVersion
[topVer=3572399462961787821, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=9b4ce41e371-df862fe8-e79a-4148-93c1-9c25ceae3357, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=6e4a3032-01d1-48d3-bedf-95f6dcdac7b2, topVer=0, msgTemplate=null,
span=null, nodeId8=6e4a3032, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597212260080]], val2=AffinityTopologyVersion
[topVer=3572399462961787821, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=bed0715c-0e9b-41b9-8732-f6f277c9073c, topVer=0,
msgTemplate=null, span=null, nodeId8=16670220, msg=, type=NODE_JOINED,
tstamp=1597212260080], val2=AffinityTopologyVersion
[topVer=8094284346878037296, minorTopVer=0]]] - PASSED{color}
{color:#8b}Platform C++ CMake (Linux Clang){color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=5569120]]
*
[jira] [Commented] (IGNITE-13308) C++: Thin client transactions
[ https://issues.apache.org/jira/browse/IGNITE-13308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17187466#comment-17187466 ] Stanilovsky Evgeny commented on IGNITE-13308: - [~isapego] TC looks ok. > C++: Thin client transactions > - > > Key: IGNITE-13308 > URL: https://issues.apache.org/jira/browse/IGNITE-13308 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Ivan Daschinskiy >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: C++, iep-34 > Fix For: 2.10 > > Time Spent: 4h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13389) Add possibility to obtain full stack trace on thin client side.
[
https://issues.apache.org/jira/browse/IGNITE-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17187462#comment-17187462
]
Ignite TC Bot commented on IGNITE-13389:
{panel:title=Branch: [pull/8195/head] Base: [master] : Possible Blockers
(23)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5569279]]
{color:#d04437}MVCC Cache 7{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5569351]]
{color:#d04437}RDD{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5569273]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests
10|https://ci.ignite.apache.org/viewLog.html?buildId=5569332]]
* dll: CreateCacheTest.TestCreateFromConfiguration - Test has low fail rate in
base branch 0,0% and is not flaky
* dll: CreateCacheTest.TestCreateFromTemplate - Test has low fail rate in base
branch 0,0% and is not flaky
* dll: ScanQueryTest.TestMultipleCursors - Test has low fail rate in base
branch 0,0% and is not flaky
* dll: ClientClusterTests.TestInvalidCacheNameTriggersIgniteClientException -
Test has low fail rate in base branch 0,0% and is not flaky
* dll:
ComputeClientDisabledTests.TestComputeThrowsCorrectExceptionWhenNotEnabledOnServer
- Test has low fail rate in base branch 0,0% and is not flaky
* dll: ComputeClientTests.TestExecuteJavaTaskWithExceededTaskLimit - Test has
low fail rate in base branch 0,0% and is not flaky
* dll: ComputeClientTests.TestExecuteJavaTaskWithUnknownClass - Test has low
fail rate in base branch 0,0% and is not flaky
* dll:
ComputeClientTests.TestExecuteJavaTaskWithFailedResultDeserializationProducesBinaryObjectException
- Test has low fail rate in base branch 0,0% and is not flaky
* dll:
ComputeClientTests.TestExecuteJavaTaskWithDotnetOnlyArgClassThrowsCorrectException
- Test has low fail rate in base branch 0,0% and is not flaky
* dll: ContinuousQueryTest.TestContinuousQueryCountIsLimitedByMaxCursors - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5569339]]
* ZookeeperDiscoverySpiTestSuite3:
GridCacheReplicatedNodeRestartSelfTest.testRestart - Test has low fail rate in
base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite3:
GridCacheReplicatedNodeRestartSelfTest.testRestartWithPutFourNodesOneBackupsOffheapEvict
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=5569331]]
* exe: ClientClusterTests.TestInvalidCacheNameTriggersIgniteClientException -
Test has low fail rate in base branch 0,0% and is not flaky
* exe: CreateCacheTest.TestCreateFromConfiguration - Test has low fail rate in
base branch 0,0% and is not flaky
* exe: CreateCacheTest.TestCreateFromTemplate - Test has low fail rate in base
branch 0,0% and is not flaky
* exe: ScanQueryTest.TestExceptionInFilter - Test has low fail rate in base
branch 0,0% and is not flaky
* exe: ScanQueryTest.TestMultipleCursors - Test has low fail rate in base
branch 0,0% and is not flaky
* exe:
ComputeClientDisabledTests.TestComputeThrowsCorrectExceptionWhenNotEnabledOnServer
- Test has low fail rate in base branch 0,0% and is not flaky
* exe: ContinuousQueryTest.TestContinuousQueryCountIsLimitedByMaxCursors - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5569313]]
* IgniteCacheTestSuite4:
IgniteCacheInvokeReadThroughTest.testInvokeReadThroughAtomic2 - Test has low
fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/8195/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Thin Client: Java{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5569270]]
* {color:#013220}ClientTestSuite:
IgniteBinaryTest.testBinaryWithNotGenericInterceptor - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5569366buildTypeId=IgniteTests24Java8_RunAll]
> Add possibility to obtain full stack trace on thin client side.
> ---
>
> Key: IGNITE-13389
> URL: https://issues.apache.org/jira/browse/IGNITE-13389
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some server side errors have deeply nested _suppressed_ or _caused by_ errors
> which
