[jira] [Commented] (IGNITE-8166) stopGrid() hangs in some cases when node is invalidated and PDS is enabled

[Aleksey Plekhanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428765#comment-16428765
 ] 

Aleksey Plekhanov commented on IGNITE-8166:
---

[~Jokser], Hello!
I found this bug on yesterdays master branch. In the PR 3633 I see 
{{cpFinishFut}} completion, not {{cpBeginFut}}

> stopGrid() hangs in some cases when node is invalidated and PDS is enabled
> --
>
> Key: IGNITE-8166
> URL: https://issues.apache.org/jira/browse/IGNITE-8166
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-14
>
> Node invalidation via FailureProcessor can hang {{exchange-worker}} and 
> {{stopGrid()}} when PDS is enabled.
> Reproducer (reproducer is racy, sometimes finished without hang):
> {code:java}
> public class StopNodeHangsTest extends GridCommonAbstractTest {
> /** Offheap size for memory policy. */
> private static final int SIZE = 10 * 1024 * 1024;
> /** Page size. */
> static final int PAGE_SIZE = 2048;
> /** Number of entries. */
> static final int ENTRIES = 2_000;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> DataStorageConfiguration dsCfg = new DataStorageConfiguration();
> DataRegionConfiguration dfltPlcCfg = new DataRegionConfiguration();
> dfltPlcCfg.setName("dfltPlc");
> dfltPlcCfg.setInitialSize(SIZE);
> dfltPlcCfg.setMaxSize(SIZE);
> dfltPlcCfg.setPersistenceEnabled(true);
> dsCfg.setDefaultDataRegionConfiguration(dfltPlcCfg);
> dsCfg.setPageSize(PAGE_SIZE);
> cfg.setDataStorageConfiguration(dsCfg);
> cfg.setFailureHandler(new FailureHandler() {
> @Override public boolean onFailure(Ignite ignite, FailureContext 
> failureCtx) {
> return true;
> }
> });
> return cfg;
> }
> public void testStopNodeHangs() throws Exception {
> cleanPersistenceDir();
> IgniteEx ignite0 = startGrid(0);
> IgniteEx ignite1 = startGrid(1);
> ignite1.cluster().active(true);
> awaitPartitionMapExchange();
> IgniteCache cache = ignite1.getOrCreateCache("TEST");
> Map entries = new HashMap<>();
> for (int i = 0; i < ENTRIES; i++)
> entries.put(i, new byte[PAGE_SIZE * 2 / 3]);
> cache.putAll(entries);
> ignite1.context().failure().process(new 
> FailureContext(FailureType.CRITICAL_ERROR, null));
> stopGrid(0);
> stopGrid(1);
> }
> }
> {code}
> {{stopGrid(1)}} waiting until exchange finished, {{exchange-worker}} waits on 
> method {{GridCacheDatabaseSharedManager#checkpointReadLock}} for 
> {{CheckpointProgressSnapshot#cpBeginFut}}, but this future is never done 
> because {{db-checkpoint-thread}} got exception at 
> {{GridCacheDatabaseSharedManager.Checkpointer#markCheckpointBegin}} thrown by 
> {{FileWriteAheadLogManager#checkNode}} and leave method 
> {{markCheckpointBegin}} before future is done ({{curr.cpBeginFut.onDone();}})



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6241) Integrate with Kubernetes StatefulSet to support Ignite Persistence

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428809#comment-16428809
 ] 

Denis Magda commented on IGNITE-6241:
-

Ryan Samo kindly shared a solution in this thread: 
http://apache-ignite-users.70518.x6.nabble.com/Kubernetes-Access-Ignite-Cluster-Externally-td20532.html

Now it's our turn to go ahead and get it documented on readme.io.

The POC environment is running Kubernetes 1.9.6 with Ignite Fabric 2.4. I am 
using Statefulsets to make sure Ignite has some stickiness to the nodes in 
case of failures, etc. I am also utilizing local storage on each of the K8s 
nodes so that Ignite persistence will work and it does, very well in fact. 

*Making it work* 

The following link will give you everything you need to know to enable local 
stoarage on Kubernetes: 
https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume

   

- In order to use persistence, you have to have K8s version 1.9.3 and above. 
This is because there are some "feature-gates" that you must enable to allow 
for the persistence to operate properly. If your K8s version is >= 1.9.3 and 
< 1.10.0 then you need "feature-gates: 
PersistentLocalVolumes=true,VolumeScheduling=true,MountPropagation=true". If 
your K8s version is >= 1.10.0 then you only need "feature-gates: 
BlockVolume=true". 

- Next you will need to create a StorageClass where "volumeBindingMode: 
WaitForFirstConsumer". This allows us to bind to a storage class and wait 
for it to be picked up by a volume claim before it can be used. 

- Now we need a DaemonSet that monitors the disk that we want to use for 
local storage and checks for mounts. When it sees a new mount, it will 
create a PersistentVolume(PV) in K8s. Fortunately Quay has a docker image 
that does everything we need, 
"quay.io/external_storage/local-volume-provisioner". This is awesome because 
we can add more storage or mounts or both and our DaemonSet will pick it up 
automatically! 

- Now you just need to create a StatefulSet that uses an Ignite docker 
image, has a "volumeClaimTemplates" section which points to a the 
"volume.beta.kubernetes.io/storage-class" we specified earlier, and a 
"volumeMounts" section which points to a mount point that was 
auto-discovered by the DaemonSet above. When you start the StatefulSet, it 
will create a PersistentVolumeClaim for the mount you specified and bind 
that to the StatefulSet. 

Bingo, you have persistent storage! 


> Integrate with Kubernetes StatefulSet to support Ignite Persistence
> ---
>
> Key: IGNITE-6241
> URL: https://issues.apache.org/jira/browse/IGNITE-6241
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Priority: Critical
> Fix For: 2.6
>
>
> Ignite Kubernetes integration has to support StatefulSet which enables Ignite 
> Persistence usage in Kubernetes deployments. More details are here:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Persistence-on-Kubernetes-td16396.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6241) Integrate with Kubernetes StatefulSet to support Ignite Persistence

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-6241:

Fix Version/s: 2.6

> Integrate with Kubernetes StatefulSet to support Ignite Persistence
> ---
>
> Key: IGNITE-6241
> URL: https://issues.apache.org/jira/browse/IGNITE-6241
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Priority: Critical
> Fix For: 2.6
>
>
> Ignite Kubernetes integration has to support StatefulSet which enables Ignite 
> Persistence usage in Kubernetes deployments. More details are here:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Persistence-on-Kubernetes-td16396.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7700) SQL system view for list of nodes

[Aleksey Plekhanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Plekhanov updated IGNITE-7700:
--
Fix Version/s: (was: 2.5)
   2.6

> SQL system view for list of nodes
> -
>
> Key: IGNITE-7700
> URL: https://issues.apache.org/jira/browse/IGNITE-7700
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-13, sql
> Fix For: 2.6
>
>
> Implement SQL system view to show list of nodes in topology.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8033) Flaky failure TxOptimisticDeadlockDetectionCrossCacheTest.testDeadlock on TC

[Aleksey Plekhanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Plekhanov updated IGNITE-8033:
--
Fix Version/s: (was: 2.5)
   2.6

> Flaky failure TxOptimisticDeadlockDetectionCrossCacheTest.testDeadlock on TC
> 
>
> Key: IGNITE-8033
> URL: https://issues.apache.org/jira/browse/IGNITE-8033
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Test TxOptimisticDeadlockDetectionCrossCacheTest.testDeadlock flakily fail on 
> TC. Sometimes with timeout, sometimes with the following error:
> {noformat}
> [2018-03-21 12:06:23,469][ERROR][main][root] Test failed. 
>   
>
> junit.framework.AssertionFailedError  
>   
>
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertTrue(Assert.java:31)
>   at junit.framework.TestCase.assertTrue(TestCase.java:201)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.TxOptimisticDeadlockDetectionCrossCacheTest.doTestDeadlock(TxOptimisticDeadlockDetectionCrossCacheTest.java:186)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.TxOptimisticDeadlockDetectionCrossCacheTest.testDeadlock(TxOptimisticDeadlockDetectionCrossCacheTest.java:118)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
>   
>  
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7527) SQL system view for current node transactions

[Aleksey Plekhanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Plekhanov updated IGNITE-7527:
--
Fix Version/s: (was: 2.5)
   2.6

> SQL system view for current node transactions
> -
>
> Key: IGNITE-7527
> URL: https://issues.apache.org/jira/browse/IGNITE-7527
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-13, sql
> Fix For: 2.6
>
>
> Implement SQL system view to show active transactions on local node.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8059) Integrate decision tree with partition based dataset

[Anton Dmitriev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anton Dmitriev updated IGNITE-8059:
---
Description: 
A partition based dataset (new underlying infrastructure component) was added 
as part of IGNITE-7437 and now we need to adopt decision tree algorithm to work 
on top of this infrastructure.

The way decision tree algorithm is implemented on top of a row-partitioned data 
is described further.

At first, the basic idea behind any decision tree, bother regression and 
classification, is to find the *data split* that allows to minimize an 
*impurity measure* like [Gini 
coefficient|https://en.wikipedia.org/wiki/Gini_coefficient], 
[entropy|https://en.wikipedia.org/wiki/Entropy_(information_theory)] or [mean 
squared error|https://en.wikipedia.org/wiki/Mean_squared_error]. To calculate 
the best split we need to build a _function_ that describes dependency between 
split point (independent variable) and impurity measure (dependent variable) 
and then find a minimum of this _function_.

In case of a distributed system, when a data is partitioned by row, we can 
calculate such _function_ on every node, compress it somehow, and then pass it 
to the master node. On the master node we need to summarize _functions_ 
received from all nodes and then find a minimum of the result _function_. It's 
the way decision tree algorithm is implemented in Apache Ignite ML module.

  was:
A partition based dataset (new underlying infrastructure component) was added 
as part of IGNITE-7437 and now we need to adopt decision tree algorithm to work 
on top of this infrastructure.

The way decision tree algorithm is implemented on top of a row-partitioned data 
is described further.

At first, the basic idea behind any decision tree, bother regression and 
classification, is to find the *data split* that allows to minimize an 
*impurity measure* like [Gini 
coefficient|[https://en.wikipedia.org/wiki/Gini_coefficient]] 
[entropy|https://en.wikipedia.org/wiki/Entropy_(information_theory)] or [mean 
squared error|[https://en.wikipedia.org/wiki/Mean_squared_error]]. To calculate 
the best split we need to build a _function_ that describes dependency between 
split point (independent variable) and impurity measure (dependent variable) 
and then find a minimum of this _function_.

In case of a distributed system, when a data is partitioned by row, we can 
calculate such _function_ on every node, compress it somehow, and then pass it 
to the master node. On the master node we need to summarize _functions_ 
received from all nodes and then find a minimum of the result _function_. It's 
the way decision tree algorithm is implemented in Apache Ignite ML module.


> Integrate decision tree with partition based dataset
> 
>
> Key: IGNITE-8059
> URL: https://issues.apache.org/jira/browse/IGNITE-8059
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Anton Dmitriev
>Assignee: Anton Dmitriev
>Priority: Major
> Fix For: 2.5
>
>
> A partition based dataset (new underlying infrastructure component) was added 
> as part of IGNITE-7437 and now we need to adopt decision tree algorithm to 
> work on top of this infrastructure.
> 
> The way decision tree algorithm is implemented on top of a row-partitioned 
> data is described further.
> At first, the basic idea behind any decision tree, bother regression and 
> classification, is to find the *data split* that allows to minimize an 
> *impurity measure* like [Gini 
> coefficient|https://en.wikipedia.org/wiki/Gini_coefficient], 
> [entropy|https://en.wikipedia.org/wiki/Entropy_(information_theory)] or [mean 
> squared error|https://en.wikipedia.org/wiki/Mean_squared_error]. To calculate 
> the best split we need to build a _function_ that describes dependency 
> between split point (independent variable) and impurity measure (dependent 
> variable) and then find a minimum of this _function_.
> In case of a distributed system, when a data is partitioned by row, we can 
> calculate such _function_ on every node, compress it somehow, and then pass 
> it to the master node. On the master node we need to summarize _functions_ 
> received from all nodes and then find a minimum of the result _function_. 
> It's the way decision tree algorithm is implemented in Apache Ignite ML 
> module.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7701) SQL system view for node attributes

[Aleksey Plekhanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Plekhanov updated IGNITE-7701:
--
Fix Version/s: (was: 2.5)
   2.6

> SQL system view for node attributes
> ---
>
> Key: IGNITE-7701
> URL: https://issues.apache.org/jira/browse/IGNITE-7701
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-13, sql
> Fix For: 2.6
>
>
> Implement SQL system view to show attributes for each node in topology.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8059) Integrate decision tree with partition based dataset

[Anton Dmitriev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anton Dmitriev updated IGNITE-8059:
---
Description: 
A partition based dataset (new underlying infrastructure component) was added 
as part of IGNITE-7437 and now we need to adopt decision tree algorithm to work 
on top of this infrastructure.

The way decision tree algorithm is implemented on top of a row-partitioned data 
is described further.

At first, the basic idea behind any decision tree, bother regression and 
classification, is to find the *data split* that allows to minimize an 
*impurity measure* like [Gini 
coefficient|[https://en.wikipedia.org/wiki/Gini_coefficient],] 
[entropy|https://en.wikipedia.org/wiki/Entropy_(information_theory)] or [mean 
squared error|[https://en.wikipedia.org/wiki/Mean_squared_error].] To calculate 
the best split we need to build a _function_ that describes dependency between 
split point (independent variable) and impurity measure (dependent variable) 
and then find a minimum of this _function_.

In case of a distributed system, when a data is partitioned by row, we can 
calculate such _function_ on every node, compress it somehow, and then pass it 
to the master node. On the master node we need to summarize _functions_ 
received from all nodes and then find a minimum of the result _function_. It's 
the way decision tree algorithm is implemented in Apache Ignite ML module.

  was:A partition based dataset (new underlying infrastructure component) was 
added as part of IGNITE-7437 and now we need to adopt decision tree algorithm 
to work on top of this infrastructure. 


> Integrate decision tree with partition based dataset
> 
>
> Key: IGNITE-8059
> URL: https://issues.apache.org/jira/browse/IGNITE-8059
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Anton Dmitriev
>Assignee: Anton Dmitriev
>Priority: Major
> Fix For: 2.5
>
>
> A partition based dataset (new underlying infrastructure component) was added 
> as part of IGNITE-7437 and now we need to adopt decision tree algorithm to 
> work on top of this infrastructure.
> 
> The way decision tree algorithm is implemented on top of a row-partitioned 
> data is described further.
> At first, the basic idea behind any decision tree, bother regression and 
> classification, is to find the *data split* that allows to minimize an 
> *impurity measure* like [Gini 
> coefficient|[https://en.wikipedia.org/wiki/Gini_coefficient],] 
> [entropy|https://en.wikipedia.org/wiki/Entropy_(information_theory)] or [mean 
> squared error|[https://en.wikipedia.org/wiki/Mean_squared_error].] To 
> calculate the best split we need to build a _function_ that describes 
> dependency between split point (independent variable) and impurity measure 
> (dependent variable) and then find a minimum of this _function_.
> In case of a distributed system, when a data is partitioned by row, we can 
> calculate such _function_ on every node, compress it somehow, and then pass 
> it to the master node. On the master node we need to summarize _functions_ 
> received from all nodes and then find a minimum of the result _function_. 
> It's the way decision tree algorithm is implemented in Apache Ignite ML 
> module.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8059) Integrate decision tree with partition based dataset

[Anton Dmitriev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anton Dmitriev updated IGNITE-8059:
---
Description: 
A partition based dataset (new underlying infrastructure component) was added 
as part of IGNITE-7437 and now we need to adopt decision tree algorithm to work 
on top of this infrastructure.

The way decision tree algorithm is implemented on top of a row-partitioned data 
is described further.

At first, the basic idea behind any decision tree, bother regression and 
classification, is to find the *data split* that allows to minimize an 
*impurity measure* like [Gini 
coefficient|[https://en.wikipedia.org/wiki/Gini_coefficient]] 
[entropy|https://en.wikipedia.org/wiki/Entropy_(information_theory)] or [mean 
squared error|[https://en.wikipedia.org/wiki/Mean_squared_error]]. To calculate 
the best split we need to build a _function_ that describes dependency between 
split point (independent variable) and impurity measure (dependent variable) 
and then find a minimum of this _function_.

In case of a distributed system, when a data is partitioned by row, we can 
calculate such _function_ on every node, compress it somehow, and then pass it 
to the master node. On the master node we need to summarize _functions_ 
received from all nodes and then find a minimum of the result _function_. It's 
the way decision tree algorithm is implemented in Apache Ignite ML module.

  was:
A partition based dataset (new underlying infrastructure component) was added 
as part of IGNITE-7437 and now we need to adopt decision tree algorithm to work 
on top of this infrastructure.

The way decision tree algorithm is implemented on top of a row-partitioned data 
is described further.

At first, the basic idea behind any decision tree, bother regression and 
classification, is to find the *data split* that allows to minimize an 
*impurity measure* like [Gini 
coefficient|[https://en.wikipedia.org/wiki/Gini_coefficient],] 
[entropy|https://en.wikipedia.org/wiki/Entropy_(information_theory)] or [mean 
squared error|[https://en.wikipedia.org/wiki/Mean_squared_error].] To calculate 
the best split we need to build a _function_ that describes dependency between 
split point (independent variable) and impurity measure (dependent variable) 
and then find a minimum of this _function_.

In case of a distributed system, when a data is partitioned by row, we can 
calculate such _function_ on every node, compress it somehow, and then pass it 
to the master node. On the master node we need to summarize _functions_ 
received from all nodes and then find a minimum of the result _function_. It's 
the way decision tree algorithm is implemented in Apache Ignite ML module.


> Integrate decision tree with partition based dataset
> 
>
> Key: IGNITE-8059
> URL: https://issues.apache.org/jira/browse/IGNITE-8059
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Anton Dmitriev
>Assignee: Anton Dmitriev
>Priority: Major
> Fix For: 2.5
>
>
> A partition based dataset (new underlying infrastructure component) was added 
> as part of IGNITE-7437 and now we need to adopt decision tree algorithm to 
> work on top of this infrastructure.
> 
> The way decision tree algorithm is implemented on top of a row-partitioned 
> data is described further.
> At first, the basic idea behind any decision tree, bother regression and 
> classification, is to find the *data split* that allows to minimize an 
> *impurity measure* like [Gini 
> coefficient|[https://en.wikipedia.org/wiki/Gini_coefficient]] 
> [entropy|https://en.wikipedia.org/wiki/Entropy_(information_theory)] or [mean 
> squared error|[https://en.wikipedia.org/wiki/Mean_squared_error]]. To 
> calculate the best split we need to build a _function_ that describes 
> dependency between split point (independent variable) and impurity measure 
> (dependent variable) and then find a minimum of this _function_.
> In case of a distributed system, when a data is partitioned by row, we can 
> calculate such _function_ on every node, compress it somehow, and then pass 
> it to the master node. On the master node we need to summarize _functions_ 
> received from all nodes and then find a minimum of the result _function_. 
> It's the way decision tree algorithm is implemented in Apache Ignite ML 
> module.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-4161) Discovery SPI for nodes that will connect to Ignite Kubernetes cluster from outside

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428819#comment-16428819
 ] 

Denis Magda commented on IGNITE-4161:
-

More ideas and feedback are shared in this discussion: 
http://apache-ignite-users.70518.x6.nabble.com/Kubernetes-Access-Ignite-Cluster-Externally-td20532.html

> Discovery SPI for nodes that will connect to Ignite Kubernetes cluster from 
> outside
> ---
>
> Key: IGNITE-4161
> URL: https://issues.apache.org/jira/browse/IGNITE-4161
> Project: Ignite
>  Issue Type: New Feature
>  Components: general
>Affects Versions: 2.0
>Reporter: Denis Magda
>Priority: Major
>
> Ignite cluster can be considered as a set of Kubernetes pods of a similar 
> type that are scaled across available hardware. To get access to the cluster 
> from outside the one has to use Kubernetes Service that will expose a single 
> public API address for the whole Ignite Cluster. 
> Let's think over how an Ignite client can connect to the Ignite's Kubernetes 
> cluster from outside, look up nodes and interact with them. As a result, most 
> likely we will implement a special discovery SPI for such "outside" nodes 
> that will connect to Kubernetes Service before the joining process.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-4161) Discovery SPI for nodes that will connect to Ignite Kubernetes cluster from outside

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-4161:

Issue Type: New Feature  (was: Task)

> Discovery SPI for nodes that will connect to Ignite Kubernetes cluster from 
> outside
> ---
>
> Key: IGNITE-4161
> URL: https://issues.apache.org/jira/browse/IGNITE-4161
> Project: Ignite
>  Issue Type: New Feature
>  Components: general
>Affects Versions: 2.0
>Reporter: Denis Magda
>Priority: Major
>
> Ignite cluster can be considered as a set of Kubernetes pods of a similar 
> type that are scaled across available hardware. To get access to the cluster 
> from outside the one has to use Kubernetes Service that will expose a single 
> public API address for the whole Ignite Cluster. 
> Let's think over how an Ignite client can connect to the Ignite's Kubernetes 
> cluster from outside, look up nodes and interact with them. As a result, most 
> likely we will implement a special discovery SPI for such "outside" nodes 
> that will connect to Kubernetes Service before the joining process.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-4161) Discovery SPI for nodes that will connect to Ignite Kubernetes cluster from outside

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-4161:

Issue Type: Task  (was: Sub-task)
Parent: (was: IGNITE-4159)

> Discovery SPI for nodes that will connect to Ignite Kubernetes cluster from 
> outside
> ---
>
> Key: IGNITE-4161
> URL: https://issues.apache.org/jira/browse/IGNITE-4161
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Denis Magda
>Priority: Major
>
> Ignite cluster can be considered as a set of Kubernetes pods of a similar 
> type that are scaled across available hardware. To get access to the cluster 
> from outside the one has to use Kubernetes Service that will expose a single 
> public API address for the whole Ignite Cluster. 
> Let's think over how an Ignite client can connect to the Ignite's Kubernetes 
> cluster from outside, look up nodes and interact with them. As a result, most 
> likely we will implement a special discovery SPI for such "outside" nodes 
> that will connect to Kubernetes Service before the joining process.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8153) Nodes fail to connect each other when SSL is enabled

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16429112#comment-16429112
 ] 

ASF GitHub Bot commented on IGNITE-8153:


GitHub user mcherkasov opened a pull request:

https://github.com/apache/ignite/pull/3773

IGNITE-8153 Nodes fail to connect each other when SSL is enabled



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8153

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3773.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3773


commit af30014cb50e5c6f6bf4919beaf04ae39e38cd36
Author: mcherkasov 
Date:   2018-04-04T01:48:27Z

IGNITE-8153 Nodes fail to connect each other when SSL is enabled




> Nodes fail to connect each other when SSL is enabled
> 
>
> Key: IGNITE-8153
> URL: https://issues.apache.org/jira/browse/IGNITE-8153
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
>Priority: Major
> Fix For: 2.5
>
>
> Nodes can fail to connect each other when SSL is enabled under some 
> circumstances.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8171) Document how to rollback transactions to let PME complete

[Denis Magda (JIRA)]

Denis Magda created IGNITE-8171:
---

 Summary: Document how to rollback transactions to let PME complete
 Key: IGNITE-8171
 URL: https://issues.apache.org/jira/browse/IGNITE-8171
 Project: Ignite
  Issue Type: New Feature
  Components: documentation
Reporter: Denis Magda
 Fix For: 2.5


Some Ignite operations provoke partition map exchange process within Ignite to 
ensure the partitions distribution state is synchronized cluster-wide. Topology 
update events and a start of a new distributed cache are examples of those 
operations.

When the partition map exchange starts, Ignite acquires a global lock at a 
particular stage. The lock can't be obtained until pending transactions are 
running in parallel. If there is a transaction that runs for a while, then it 
will prevent the partition map exchange process from the start freezing some 
operations such as a new node join process.

This property allows to rollback such long transactions to let Ignite acquire 
the lock faster and initiate the partition map exchange process. The timeout is 
enforced only at the time of the partition map exchange process.

See {{TransactionConfiguraion}} and 
{{IgniteTransactions.localActiveTransactions and withLabel}} methods.

Original ticket:
https://issues.apache.org/jira/browse/IGNITE-6827



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8125) Returns null on cache querying on column type PGOBJECT (JSONB) superset or @>

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16429067#comment-16429067
 ] 

Denis Magda commented on IGNITE-8125:
-

[~sid_human], Ignite SQL engine is not PostgreSQL compliant. The engine 
supports ANSI-99 syntax of H2 database that is used internally for some of the 
needs: https://apacheignite-sql.readme.io/docs/how-ignite-sql-works

So, it's not an issue. 

> Returns null on cache querying on column type PGOBJECT (JSONB) superset or @>
> -
>
> Key: IGNITE-8125
> URL: https://issues.apache.org/jira/browse/IGNITE-8125
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, jdbc, sql
>Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4
>Reporter: Siddarth sreeni
>Priority: Critical
>  Labels: documentation, fix-by-workaround
>
> Apache Ignite briefly discusses the uses of SQL Cache query. It talks about 
> the different transactional query it can be used to done. Apache Ignite is as 
> said supported on PostGreSQL databases. 
> For example: In a table of column type JSONB. Querying for a specific object 
> superset in a column returns Null.
> Query: Select * from Table where column @> 'Object' 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications

[Prachi Garg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Prachi Garg reassigned IGNITE-8039:
---

Assignee: Vladimir Ozerov  (was: Prachi Garg)

> Binary Client Protocol spec: data types/format clarifications
> -
>
> Key: IGNITE-8039
> URL: https://issues.apache.org/jira/browse/IGNITE-8039
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, thin client
>Affects Versions: 2.4
>Reporter: Alexey Kosenchuk
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>
> Assuming the Binary Client Protocol spec should be detalized enough to allow 
> a client development basing on the spec only, w/o looking at other client 
> implementations and asking additional questions...
> The following should be clarified / corrected in the Binary Client Protocol 
> spec (v.2.4) 
> (https://apacheignite.readme.io/v2.4/docs/binary-client-protocol#section-data-format):
> Type Codes table:
> -
> - UUID (Guid) size: should be 16 bytes, not 8 (?) 
> - what is Object array (type code 23) ? What is the difference between it and 
> Objects Wrapped In​ Array (type code 27) ?
> - what is Collection USER_SET ?
> - what is Collection USER_COL ?
> - what is Collection SINGLETON_LIST ?
> - Collection: misprint: should be "... + length ..."
> - what is Decimal ?
> - what is Timestamp ?
> - what is Time ?
> Complex Objects:
> 
> - what does flag USER_TYPE mean ?
> - Schema "field Id; Java-style hash code of field" -> should be "... of field 
> name".
> - "Repeat for as many times as the total number of schemas you have" -> 
> should be "... total number of fields you have".
> - is it mandated that the number of fields in the Schema must be equal to the 
> number of fields in the Data Object ?
> Objects Wrapped In​ Array
> 
> - may binary objects with different type codes be in the same array ?
> - may complex objects with different type ids be in the same array ?
> - "All cache operations return complex objects inside a wrapper (but not 
> primitives)." -> does it mean that in general a complex object (103) must 
> always be sent via the Binary Protocol in a wrapper (27)? 
> - "Byte array size" -> "Payload size" or "Size of the whole array with 
> header" ?
> - Offset. What is "object graph" here ? The Binary Protocol nowhere describes 
> any relations ("graph") between data objects in the protocol.
> Terminology
> ---
> Not critical but would be really convenient to define and use the same terms 
> along the whole spec. For example:
> - "binary object" is always the same as "data object" of any type (?). Can be 
> "standard/predefined type object" or "complex object".
> - "cluster" or "server" ?
> - "cluster member" or "server nodes" ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7975) SQL TX: allow batch inserts

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7975:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: allow batch inserts
> ---
>
> Key: IGNITE-7975
> URL: https://issues.apache.org/jira/browse/IGNITE-7975
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.6
>
>
> Need to implement proper handling for batch inserts. It is disabled 
> currently, see {{DmlStatementsProcessor#updateSqlFieldsBatched}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7261) SQL TX: SELECT and DML operations must share the same MVCC version

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7261:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: SELECT and DML operations must share the same MVCC version
> --
>
> Key: IGNITE-7261
> URL: https://issues.apache.org/jira/browse/IGNITE-7261
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.6
>
>
> Need to make sure that all statements within TX share the same MVCC version 
> which is assigned on first read/write. 
> Need to add tests for this to confirm REPEATABLE_READ behavior.
> Note that regular implicit SELECTs outside transaction should only register 
> itself as "query" on MVCC coordinator, while SELECT inside TX must register 
> itself as both "query" and "tx".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7259) GridIndexRebuildSelfTest hangs

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7259:
-
Fix Version/s: (was: 2.5)
   2.6

> GridIndexRebuildSelfTest hangs
> --
>
> Key: IGNITE-7259
> URL: https://issues.apache.org/jira/browse/IGNITE-7259
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.6
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6936) SQL TX: Implement commit protocol

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-6936:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: Implement commit protocol
> -
>
> Key: IGNITE-6936
> URL: https://issues.apache.org/jira/browse/IGNITE-6936
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Priority: Major
>  Labels: iep-3
> Fix For: 2.6
>
>
> Once we are able to lock entries [1], next step is to implement 2PC commit 
> protocol. Cache protocol could be used as a template. The main difference is 
> that near (client) node will not store entries. 
> [1] IGNITE-6935



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-5933) Integrate mvcc support in cache.getAll protocol

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-5933:
-
Fix Version/s: (was: 2.5)
   2.6

> Integrate mvcc support in cache.getAll protocol
> ---
>
> Key: IGNITE-5933
> URL: https://issues.apache.org/jira/browse/IGNITE-5933
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Semen Boikov
>Priority: Major
> Fix For: 2.6
>
>
> Need integrate mvcc support in cache.getAll protocol:
> - request current ID and list of active txs from coordinator
> - pass this info in get requests and in local 'get'
> - notify coordinator after getAll completed



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6149) Create mvcc prototype application

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-6149:
-
Fix Version/s: (was: 2.5)
   2.6

> Create mvcc prototype application
> -
>
> Key: IGNITE-6149
> URL: https://issues.apache.org/jira/browse/IGNITE-6149
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Semen Boikov
>Priority: Major
> Fix For: 2.6
>
> Attachments: MvccTestApp.java
>
>
> Need create simple prototype application to verify major concepts:
> - which data should be stored on coordinator and on data nodes
> - filtering algorithm for getAll and sql operations
> - clean up of committed versions



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-3484) MVCC data structure for getAll operation

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-3484:
-
Fix Version/s: (was: 2.5)
   2.6

> MVCC data structure for getAll operation
> 
>
> Key: IGNITE-3484
> URL: https://issues.apache.org/jira/browse/IGNITE-3484
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Semen Boikov
>Priority: Major
> Fix For: 2.6
>
>
> Need implement some data structure to store/get multiple entry versions:
> - committed value at first is stored in separate data structure (there also 
> need store related tx id to filter out data for non-finished transactions), 
> probably existing BPlusTree can be used
> - periodically need flush data for finished transaction in 'main' hash index
> - 'getAll' operation should include max 'visible' ID and list of active 
> transactions, this information should be used to find last 'visible' version 
> in 'mvcc' or 'main' index



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6738) Support mvcc filter for local sql queries

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-6738:
-
Fix Version/s: (was: 2.5)
   2.6

> Support mvcc filter for local sql queries
> -
>
> Key: IGNITE-6738
> URL: https://issues.apache.org/jira/browse/IGNITE-6738
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Semen Boikov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.6
>
>
> Need receive/release mvcc version for queries with setLocal flag set, there 
> are already some tests in CacheMvccSqlQueriesTest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8111) Add extra validation for WAL segment size

[Ivan Rakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428253#comment-16428253
 ] 

Ivan Rakov commented on IGNITE-8111:


[~garus.d.g], I've looked through your changes.
Fix looks good. I've left some comments regarding code style in github PR.

> Add extra validation for WAL segment size
> -
>
> Key: IGNITE-8111
> URL: https://issues.apache.org/jira/browse/IGNITE-8111
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Ivan Rakov
>Assignee: Denis Garus
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Currently we can set extra small DataStorageConfiguration#walSegmentSize (10 
> pages or even less than one page), which will trigger multiple assertion 
> errors in code.
> We have to implement validation on node start that WAL segment size has 
> reasonable value (512KB or more).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-8111) Add extra validation for WAL segment size

[Ivan Rakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428253#comment-16428253
 ] 

Ivan Rakov edited comment on IGNITE-8111 at 4/6/18 12:24 PM:
-

[~garus.d.g], I've looked through your changes.
Fix itself looks good. I've left some comments regarding code style in github 
PR.


was (Author: ivan.glukos):
[~garus.d.g], I've looked through your changes.
Fix looks good. I've left some comments regarding code style in github PR.

> Add extra validation for WAL segment size
> -
>
> Key: IGNITE-8111
> URL: https://issues.apache.org/jira/browse/IGNITE-8111
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Ivan Rakov
>Assignee: Denis Garus
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Currently we can set extra small DataStorageConfiguration#walSegmentSize (10 
> pages or even less than one page), which will trigger multiple assertion 
> errors in code.
> We have to implement validation on node start that WAL segment size has 
> reasonable value (512KB or more).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428242#comment-16428242
 ] 

ASF GitHub Bot commented on IGNITE-8085:


GitHub user 1vanan opened a pull request:

https://github.com/apache/ignite/pull/3767

IGNITE-8085



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/1vanan/ignite IGNITE-8085

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3767.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3767


commit 192dbd515dcf81638ce52d6ec1f3239f97e29538
Author: Fedotov 
Date:   2018-04-06T08:38:06Z

make more timeout and kick off Thread.sleep

commit f97bae5b3e43b29d04c3806dc56201364d065649
Author: Fedotov 
Date:   2018-04-06T11:57:50Z

fix timeout and foreach

commit 7cd3e0dda7b569f91fea9e8cb669df89199da287
Author: Fedotov 
Date:   2018-04-06T12:04:13Z

testSuite




> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-5934) Integrate mvcc support in sql query protocol

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-5934:
-
Fix Version/s: (was: 2.5)
   2.6

> Integrate mvcc support in sql query protocol
> 
>
> Key: IGNITE-5934
> URL: https://issues.apache.org/jira/browse/IGNITE-5934
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Semen Boikov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.6
>
>
> Need integrate mvcc support in sql query protocol:
> - request current ID and list of active txs from coordinator
> - pass this info in sql requests and in sql queries
> - notify coordinator after query completed



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7501) Improve underlying iterators closing process for cache iterators.

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7501:
-
Fix Version/s: (was: 2.5)
   2.6

> Improve underlying iterators closing process for cache iterators.
> -
>
> Key: IGNITE-7501
> URL: https://issues.apache.org/jira/browse/IGNITE-7501
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
>  Labels: cache, iterators, mvcc
> Fix For: 2.6
>
>
> When we call {{javax.cache.Cache#iterator()}}  we get {{java.util.Iterator}} 
> which doesn't have a {{close()}} method. But underlying 
> {{GridCloseableIterator}} does have this method and it should be called when 
> all the work with the current iterator is done. Currently calling {{close()}} 
> for the underlying closeable iterator is delegated to 
> {{WeakQueryCloseableIterator}}. So, {{close()}} method is usually called in 
> GridCacheGateway#onEnter or on a garbage collection phase, which is not 
> acceptable in some situations. For example if MVCC is enabled, this *late* 
> iterator closing could dramatically increase the active queries tracking list 
> size which  could lead to the performance and garbage collection ("vacuum") 
> issues.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-5937) Mvcc data structure for SQL queries

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-5937:
-
Fix Version/s: (was: 2.5)
   2.6

> Mvcc data structure for SQL queries
> ---
>
> Key: IGNITE-5937
> URL: https://issues.apache.org/jira/browse/IGNITE-5937
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Semen Boikov
>Assignee: Semen Boikov
>Priority: Major
> Fix For: 2.6
>
>
> Need implement some data structure to store/query multiple entry versions.
> One possible option:
> - committed value at first is stored in separate BPlusTree index (there also 
> need store related tx id to filter out data for non-finished transactions)
> - periodically flush data for finished transaction in 'main' index
> - for SQL queries need merge result from main index and filtered 'mvcc' 
> index. Note: it is possible 'mvcc' index will contain multiple committed 
> versions of the same entry, need make sure only one last one will appear in 
> result.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8163) PDS Indexing suite is hanging on TC in different branches including master

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-8163:
---
Fix Version/s: 2.6

> PDS Indexing suite is hanging on TC in different branches including master
> --
>
> Key: IGNITE-8163
> URL: https://issues.apache.org/jira/browse/IGNITE-8163
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> As logs show WalCompactionTest hangs because of race between autoactivation 
> and manual activation.
> For now it is enough to fix the test itself; root cause issue will be fixed 
> later.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-8111) Add extra validation for WAL segment size

[Ivan Rakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428273#comment-16428273
 ] 

Ivan Rakov edited comment on IGNITE-8111 at 4/6/18 12:59 PM:
-

[~dpavlov], can you please help with merge?


was (Author: ivan.glukos):
[~dpavlov], can you please help with mege?

> Add extra validation for WAL segment size
> -
>
> Key: IGNITE-8111
> URL: https://issues.apache.org/jira/browse/IGNITE-8111
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Ivan Rakov
>Assignee: Denis Garus
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Currently we can set extra small DataStorageConfiguration#walSegmentSize (10 
> pages or even less than one page), which will trigger multiple assertion 
> errors in code.
> We have to implement validation on node start that WAL segment size has 
> reasonable value (512KB or more).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8111) Add extra validation for WAL segment size

[Ivan Rakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428273#comment-16428273
 ] 

Ivan Rakov commented on IGNITE-8111:


[~dpavlov], can you please help with mege?

> Add extra validation for WAL segment size
> -
>
> Key: IGNITE-8111
> URL: https://issues.apache.org/jira/browse/IGNITE-8111
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Ivan Rakov
>Assignee: Denis Garus
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Currently we can set extra small DataStorageConfiguration#walSegmentSize (10 
> pages or even less than one page), which will trigger multiple assertion 
> errors in code.
> We have to implement validation on node start that WAL segment size has 
> reasonable value (512KB or more).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7183) SQL TX: Implicit transactions

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7183:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: Implicit transactions
> -
>
> Key: IGNITE-7183
> URL: https://issues.apache.org/jira/browse/IGNITE-7183
> Project: Ignite
>  Issue Type: Task
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
>  Labels: iep-3, sql
> Fix For: 2.6
>
>
> Implicit transaction has to be started on any SQL update in a transactional 
> cache.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7272) SQL TX: incorrect row MVCC version override during CREATE INDEX

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7272:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: incorrect row MVCC version override during CREATE INDEX
> ---
>
> Key: IGNITE-7272
> URL: https://issues.apache.org/jira/browse/IGNITE-7272
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.6
>
>
> Affected tests: {{DynamicIndexServerNodeFIlterBasicSelfTest}} and all 
> siblings.
> Root cause: see {{IgniteH2Indexing#dynamicIndexCreate}}
> {code}
> if (rowDesc.context().mvccEnabled())
> row.mvccVersion(1, MVCC_START_CNTR);
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6938) SQL TX: Reads should see own's previous writes

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-6938:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: Reads should see own's previous writes
> --
>
> Key: IGNITE-6938
> URL: https://issues.apache.org/jira/browse/IGNITE-6938
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Major
>  Labels: iep-3
> Fix For: 2.6
>
>
> If transaction modified a row, subsequent {{SELECT}} statements in the same 
> TX must return latest pending update instead of last matching committed 
> version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Pavel Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428251#comment-16428251
 ] 

Pavel Kuznetsov commented on IGNITE-7743:
-

Github pull request : https://github.com/apache/ignite/pull/3761

> JDBC driver allows to connect to non existent schema
> 
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: usability
> Fix For: 2.5
>
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
> {{indexedTypes}}), separate schema for this cache is created. Schema name is 
> case sensitive, so to connect to it with JDBC driver, it's required to 
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then 
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u 
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that 
> does not exist, throw exception in this case. Exception should provide proper 
> explanation how to connect properly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7807) SQL TX: Store lock info inside tuples

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7807:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: Store lock info inside tuples
> -
>
> Key: IGNITE-7807
> URL: https://issues.apache.org/jira/browse/IGNITE-7807
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.6
>
>
> We need to store lock info inside tuples. Otherwise, touching a lot of 
> entries would lead to OOME. Also we should rework our locking logic - instead 
> of trying to enlist ourselves in every entry, we should stop on the very 
> first locked entry and wait for it's release.
> Suggested fix: 
> 1) Check for {{lock_id}} field of an entry
> 2) If it is empty, CAS own XID
> 3) If it is not empty, check fo TX LOG to see if transaction is still active; 
> if not - CAS itself
> 4) If failed to install own version - stop locking and wait for release
> 5) When transaction commits, no locks are released explicilty. Instead, it is 
> responsibility of the next locker to check TX LOG and undesrantnad whether 
> entry could be locked or not
> 6) When lock is acquired, create new version of an entry with lock info



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6935) SQL TX: Locking protocol for simple queries

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-6935:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: Locking protocol for simple queries
> ---
>
> Key: IGNITE-6935
> URL: https://issues.apache.org/jira/browse/IGNITE-6935
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Major
>  Labels: iep-3
> Fix For: 2.6
>
>
> We need to develop locking protocol for SQL queries. Design considerations:
> 1) Use {{GridNeaLockRequest|Response}} as a template for new messages
> 2) Cover only queries which doesn't require reduce stage (see server-side DML 
> optimization code, e.g. {{GridH2DmlRequest}}).
> 3) When next entry is found, try locking it. If it is already locked, then 
> register current TX as candidate in MVCC manager and go to the next row. 
> Other TXes will notify use when entries are released. Send a response when 
> all entries are locked.
> 4) Read entry version before locking and after. If they doesn't match (i.e. 
> concurrent modification occurred), then throw an exception.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8050) Throw a meaningful exception when user issues TX SQL keyword with MVCC turned off

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-8050:
-
Fix Version/s: (was: 2.5)
   2.6

> Throw a meaningful exception when user issues TX SQL keyword with MVCC turned 
> off
> -
>
> Key: IGNITE-8050
> URL: https://issues.apache.org/jira/browse/IGNITE-8050
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.6
>
>
> An exception must be thrown when the user issues TX SQL command (BEGIN, 
> COMMIT, ROLLBACK) in absence of MVCC - ingoring these may be confusing and 
> can lead to SQL engine behavior to behaving quite differently from what the 
> user expects, esp. in terms of data consistency.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-4192) SQL TX: JDBC driver support

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-4192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-4192:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: JDBC driver support
> ---
>
> Key: IGNITE-4192
> URL: https://issues.apache.org/jira/browse/IGNITE-4192
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Major
>  Labels: iep-3
> Fix For: 2.6
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from JDBC driver side.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7583) SQL TX: Change secondary indexes structure

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7583:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: Change secondary indexes structure
> --
>
> Key: IGNITE-7583
> URL: https://issues.apache.org/jira/browse/IGNITE-7583
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Igor Seliverstov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.6
>
>
> We need to change:
>  * rows with the same key and different versions should be placed in a tree 
> ordered by version decending
>  * move next version from BTree leafs to data rows
>  * filters according to next logic: the row is visible if leaf version is 
> less than assigned and not active and max_version of referenced row is NA or 
> heigher than assigned or active 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7911) TX SQL: restrict usages of unsupported APIs and configuration parameters

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7911:
-
Fix Version/s: (was: 2.5)
   2.6

> TX SQL: restrict usages of unsupported APIs and configuration parameters
> 
>
> Key: IGNITE-7911
> URL: https://issues.apache.org/jira/browse/IGNITE-7911
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.6
>
>
> We need to make sure that when MVCC flag is enabled, users get correct 
> exception in case of invalid configurations and/or API usages. Two general 
> rules should apply
> 1) SQL and cache operations cannot be mixed in the same transactions because 
> they still use different APIs. This restriction will be removed in future 
> when native cache API is reworked to new locking logic.
> 2) If configuration is invalid or not-yet-supported API is called, user gets 
> correct exception instead of invalid result.
> All listed cases must be covered with tests.
> Checklist:
> 1) Cache configuration
> 1.1) Cache store is not allowed for TX caches
> 1.2) Expiry policy is not allowed for TX caches
> 1.3) Interceptors are not allowed for TX caches
> 2) Cache API unsupported operations - throw UnsupportedOperationException and 
> create relevant ticket (if one doesn't exist):
> 2.1) withExpiryPolicy 
> 2.2) Continuous queries
> 2.3) "clear" method family 
> 2.4) "lock" method family 
> 2.5) "load" method family 
> 2.6) "peek" method family 
> 2.7) "evict" method family
> 3) Cache API consistency - make sure that these operations use consistent 
> snapshot assigned to transaction (as with other operations). If this is the 
> case - do nothing; if this is not the case - throw 
> UnsupportedOperationException and create a ticket (if one doesn't exist)
> 3.1) Scan queries
> 3.2) "size" method family
> 3.3) Iterator methods (iterator, localEntries)
> 4) Mixed native API and SQL usage is restricted and proper IgniteException is 
> thrown. When snapshot is requested for the first time we should mark 
> transation as either "SQL" or "native". If any SQL query is executed on 
> "native" transaction or vice versa throw an exception (IllegalStateException? 
> IgniteException?)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7266) SQL TX: Joins return duplicated result when MVCC is disabled

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7266:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: Joins return duplicated result when MVCC is disabled
> 
>
> Key: IGNITE-7266
> URL: https://issues.apache.org/jira/browse/IGNITE-7266
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.6
>
>
> Affected tests:
> {{IgniteCacheJoinQueryWithAffinityKeyTest}}
> {{IgniteCacheCrossCacheJoinRandomTest}}
> All tests failed for the same reason: {{expected=X, actual=2*X}}. Looks like 
> we return too much results in some cases.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-4191) SQL: support transactions

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-4191:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL: support transactions
> -
>
> Key: IGNITE-4191
> URL: https://issues.apache.org/jira/browse/IGNITE-4191
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Denis Magda
>Priority: Major
>  Labels: iep-3, important
> Fix For: 2.6
>
>
> Presently there is no any way to execute data modification statements and 
> SELECT queries in a transactional fashion using our JDBC/ODBC drivers and DML 
> API.
> This can be fully supported once MVCC is ready and released.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6709) Support mvcc filter for H2TreeIndex.findFirstOrLast

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-6709:
-
Fix Version/s: (was: 2.5)
   2.6

> Support mvcc filter for H2TreeIndex.findFirstOrLast
> ---
>
> Key: IGNITE-6709
> URL: https://issues.apache.org/jira/browse/IGNITE-6709
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Semen Boikov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.6
>
>
> Need implement possibility to pass filter in findFirst/findLast (test already 
> exists CacheMvccSqlQueriesTest.testMaxMinTransactional).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8111) Add extra validation for WAL segment size

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428244#comment-16428244
 ] 

ASF GitHub Bot commented on IGNITE-8111:


GitHub user dgarus opened a pull request:

https://github.com/apache/ignite/pull/3768

IGNITE-8111 Add extra validation for WAL segment size



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dgarus/ignite ignite-8111

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3768.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3768


commit f6a76f18246a6af3f69c126c2fbf3c4680319754
Author: denis.garus 
Date:   2018-04-06T12:06:56Z

IGNITE-8111 Add extra validation for WAL segment size




> Add extra validation for WAL segment size
> -
>
> Key: IGNITE-8111
> URL: https://issues.apache.org/jira/browse/IGNITE-8111
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Ivan Rakov
>Assignee: Denis Garus
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Currently we can set extra small DataStorageConfiguration#walSegmentSize (10 
> pages or even less than one page), which will trigger multiple assertion 
> errors in code.
> We have to implement validation on node start that WAL segment size has 
> reasonable value (512KB or more).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-3479) Coordinator(s) for global transaction ordering

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-3479:
-
Fix Version/s: (was: 2.5)
   2.6

> Coordinator(s) for global transaction ordering
> --
>
> Key: IGNITE-3479
> URL: https://issues.apache.org/jira/browse/IGNITE-3479
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Semen Boikov
>Priority: Major
> Fix For: 2.6
>
>
> Current transaction ID will not work for SQL MVCC ordering because two 
> transaction IDs are not in total order across the cluster.
> One of the approaches is to have a dedicated coordinator which will assign a 
> continuously growing transaction ID for each committed transaction. This ID 
> must be acquired by each transaction at the last step of PREPARE stage.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6929) Preserve mvcc versions on index rebuild

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-6929:
-
Fix Version/s: (was: 2.5)
   2.6

> Preserve mvcc versions on index rebuild
> ---
>
> Key: IGNITE-6929
> URL: https://issues.apache.org/jira/browse/IGNITE-6929
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Igor Seliverstov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.6
>
>
> Currently we may loose next available version for an index row on index 
> rebuild 
> ({{org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.CacheDataStoreImpl#updateIndexes}})



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Pavel Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428250#comment-16428250
 ] 

Pavel Kuznetsov commented on IGNITE-7743:
-

[~vozerov] Could you please take a look at the patch?
TC sql run is currently queued 
https://ci.ignite.apache.org/viewQueued.html?itemId=1183179

> JDBC driver allows to connect to non existent schema
> 
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: usability
> Fix For: 2.5
>
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
> {{indexedTypes}}), separate schema for this cache is created. Schema name is 
> case sensitive, so to connect to it with JDBC driver, it's required to 
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then 
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u 
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that 
> does not exist, throw exception in this case. Exception should provide proper 
> explanation how to connect properly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8017) Disable WAL during initial preloading

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428277#comment-16428277
 ] 

ASF GitHub Bot commented on IGNITE-8017:


GitHub user ilantukh opened a pull request:

https://github.com/apache/ignite/pull/3770

IGNITE-8017 (2)



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8017-8122

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3770.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3770


commit 604ee719b304d0b4cf4caabaa6fa16b5a980e04e
Author: Pavel Kovalenko 
Date:   2018-04-04T09:33:10Z

IGNITE-8122 Restore partition state to OWNING if unable to read from page 
memory.

commit 67a48943b876b193067625fb564ab44d57a83f56
Author: Ilya Lantukh 
Date:   2018-03-23T13:10:41Z

ignite-8017 : Simple test.

commit 0021e39fe4a232a402c93aa6431048cdd00ca74c
Author: Ilya Lantukh 
Date:   2018-03-23T13:46:29Z

ignite-8017 : Basic implementation.

commit 3d446aa7bf78d53511725eb33e2546293e641167
Author: Ilya Lantukh 
Date:   2018-03-23T14:05:55Z

ignite-8017 : Configuration property.

commit bda2ba4e25e6699974520cc378638be22f4e1db3
Author: Ilya Lantukh 
Date:   2018-03-23T14:09:04Z

ignite-8017 : Property value check.

commit 9f50edc7a68dbf3253ec19ef15a8530d8484377a
Author: Ilya Lantukh 
Date:   2018-03-23T14:46:19Z

ignite-8017 : Fixed test finalization.

commit da2d400f578cd57c129c9a410e48b4586310a728
Author: Ilya Lantukh 
Date:   2018-03-26T12:34:14Z

ignite-8017 : Fixed parameter handling.

commit 34aa645d93c67ab7cea75edd4357339aab785bc8
Author: Ilya Lantukh 
Date:   2018-03-26T16:25:00Z

ignite-8017 : WIP.

commit 620b15b97511ade697ed7ec3255f4312afe857c5
Author: Ilya Lantukh 
Date:   2018-03-27T15:04:03Z

ignite-8017 : Test refactoring.

commit adab75755da9dcdec82d27e8d4d4099491c6d2f3
Author: Ilya Lantukh 
Date:   2018-03-27T15:19:26Z

ignite-8017 : Test for local and global WAL state.

commit 95492f025381521b76b480d4871a88a5fc9e3b40
Author: Ilya Lantukh 
Date:   2018-03-27T15:27:15Z

ignite-8017 : Separate handling for global and local WAL state.

commit 6da9bd39a28a6aee21613c2fb660ad6a9c6b62fb
Author: Ilya Lantukh 
Date:   2018-03-29T13:58:58Z

ignite-8017 : WIP.

commit 66968f98a3579c939ea0166008c36f15dbd0d484
Author: Ilya Lantukh 
Date:   2018-04-03T13:43:07Z

ignite-8017 : WIP.

commit d008fde6ded45d3f31ca3848bbbe347d75a05f30
Author: Ilya Lantukh 
Date:   2018-04-03T14:04:32Z

ignite-8017 : WIP.

commit 06d820950d87c0c4405c5b063596edcde37b0bf3
Author: Ilya Lantukh 
Date:   2018-04-04T16:01:55Z

ignite-8017 : WIP.

commit 4d8b7bdd0724da39d4cc45b403624c479984d1f8
Author: Ilya Lantukh 
Date:   2018-04-04T16:06:31Z

ignite-8017 : WIP.

commit 5022a554aa2ac73200f9180314f2ef69b54afb38
Author: Ilya Lantukh 
Date:   2018-04-05T11:54:12Z

ignite-8017 : WIP.

commit c43c598916bd9bda2f624a214cefcc28b0380a5c
Author: Pavel Kovalenko 
Date:   2018-04-05T14:26:53Z

IGNITE-8122 Restore partitions when persistence is enabled with OWNING 
default state.

commit a061cdba3a46f5384910fecf89366101f904ccdf
Author: Pavel Kovalenko 
Date:   2018-04-05T14:50:20Z

IGNITE-8122 Move OWN logic to GridDhtLocalPartition constructor.

commit 9259407a462633a68de6dcd7d3ae135c8c7c0b37
Author: Pavel Kovalenko 
Date:   2018-04-05T17:15:39Z

IGNITE-8122 Docs.

commit 20979dc4874cfeca649b29d8827d522f3e57ee67
Author: Pavel Kovalenko 
Date:   2018-04-05T17:16:54Z

Merge branch 'master' into ignite-8122

commit 96ac09a87690fbe8a0d9623b01e12715905c568a
Author: Ilya Lantukh 
Date:   2018-04-06T12:28:05Z

Merge branch 'ignite-8017' of https://github.com/gridgain/apache-ignite 
into ignite-8017-8122

commit fb079afe7d96aa0c5511d58c7a9db3b77ee8813f
Author: Ilya Lantukh 
Date:   2018-04-06T13:02:16Z

ignite-8017 : WIP.




> Disable WAL during initial preloading
> -
>
> Key: IGNITE-8017
> URL: https://issues.apache.org/jira/browse/IGNITE-8017
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>  Labels: iep-16
> Fix For: 2.5
>
>
> While handling SupplyMessage, node handles each supplied data entry 
> separately, which causes a WAL record for each entry to be 

[jira] [Commented] (IGNITE-7933) The error writing wal point to cp/node-start file can lead to the inability to start node

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428070#comment-16428070
 ] 

ASF GitHub Bot commented on IGNITE-7933:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3633


> The error writing wal point to cp/node-start file can lead to the inability 
> to start node
> -
>
> Key: IGNITE-7933
> URL: https://issues.apache.org/jira/browse/IGNITE-7933
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Dmitriy Govorukhin
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: cache
> Fix For: 2.5
>
>
> The problem is that the file exists on the disk but file content corrupted.
> Neet to write content via .tmp files.
> See:
> - writeCheckpointEntry
> - nodeStart



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8124) Web console: incorrect text after all clusters have been deleted

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov updated IGNITE-8124:
-
Component/s: wizards

> Web console: incorrect text after all clusters have been deleted
> 
>
> Key: IGNITE-8124
> URL: https://issues.apache.org/jira/browse/IGNITE-8124
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Ilya Borisov
>Priority: Minor
> Fix For: 2.5
>
> Attachments: screenshot-1.png
>
>
> # create two clusters
> # delete all clusters
> # see attachment
>  !screenshot-1.png! 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6839) Ignite Compatibility: flaky test testFoldersReuseCompatibility_2_1 & 2_2 & 2_3

[Vyacheslav Daradur (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Daradur updated IGNITE-6839:
---
Fix Version/s: (was: 2.5)
   2.6

> Ignite Compatibility: flaky test testFoldersReuseCompatibility_2_1 & 2_2 & 2_3
> --
>
> Key: IGNITE-6839
> URL: https://issues.apache.org/jira/browse/IGNITE-6839
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Dmitriy Pavlov
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.6
>
>
> Ignite Compatibility: 2 test are flaky:
>   
> org.apache.ignite.compatibility.testsuites.IgniteCompatibilityBasicTestSuite: 
> org.apache.ignite.compatibility.persistence.FoldersReuseCompatibilityTest.testFoldersReuseCompatibility_2_1
>  (fails: 2/55): 
> https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-1418165996957466785=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=1638023358531502921=testDetails_Ignite20Tests=%3Cdefault%3E
> {noformat}
> junit.framework.AssertionFailedError: Directory [binary_meta, 
> 135628fa_5763_46a1_88ff_8c0c8e51fc4e] is expected to exist 
> [/data/teamcity/work/820be461cd64b574/work/binary_meta/135628fa_5763_46a1_88ff_8c0c8e51fc4e]
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at 
> org.apache.ignite.compatibility.persistence.FoldersReuseCompatibilityTest.assertDirectoryExist(FoldersReuseCompatibilityTest.java:220)
> at 
> org.apache.ignite.compatibility.persistence.FoldersReuseCompatibilityTest.assertPdsDirsDefaultExist(FoldersReuseCompatibilityTest.java:193)
> at 
> org.apache.ignite.compatibility.persistence.FoldersReuseCompatibilityTest.runFoldersReuse(FoldersReuseCompatibilityTest.java:108)
> at 
> org.apache.ignite.compatibility.persistence.FoldersReuseCompatibilityTest.testFoldersReuseCompatibility_2_1(FoldersReuseCompatibilityTest.java:86)
> {noformat}
> Test probaly indicates a bug in 
> https://issues.apache.org/jira/browse/IGNITE-6285



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8157) Remove boilerplate and unused code due to grids stopping by default

[Maxim Muzafarov (JIRA)]

Maxim Muzafarov created IGNITE-8157:
---

 Summary: Remove boilerplate and unused code due to grids stopping 
by default
 Key: IGNITE-8157
 URL: https://issues.apache.org/jira/browse/IGNITE-8157
 Project: Ignite
  Issue Type: Task
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
 Fix For: 2.5


Changes IGNITE-6842 guarantee us stopping all Ignite instances after test 
completion by default.
 # We should remove a lot of bolerplate code. 
e.g.
{code:java|title=BaseDecisionTreeTest.java|borderStyle=solid}
/** {@inheritDoc} */
@Override protected void afterTestsStopped() throws Exception {
stopAllGrids();
}
{code}
 # We shuold carefully review whole usages of stopAllGrids method and remove if 
it not necessary anymore or change for using in proper way\position. 
e.g.
{code:java|title=TcpClientDiscoverySpiSelfTest.java|borderStyle=solid}
/** {@inheritDoc} */
@Override protected void afterTest() throws Exception {
stopAllClients(true);
stopAllServers(true);

...
}
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8157) Remove boilerplate and unused code due to grids stopping by default

[Maxim Muzafarov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-8157:

Affects Version/s: 2.4

> Remove boilerplate and unused code due to grids stopping by default
> ---
>
> Key: IGNITE-8157
> URL: https://issues.apache.org/jira/browse/IGNITE-8157
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.4
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>  Labels: test
> Fix For: 2.6
>
>
> Changes IGNITE-6842 guarantee us stopping all Ignite instances after test 
> completion by default.
>  # We should remove a lot of bolerplate code in our test-classes.
>  e.g.
> {code:java|title=BaseDecisionTreeTest.java|borderStyle=solid}
> /** {@inheritDoc} */
> @Override protected void afterTestsStopped() throws Exception {
> stopAllGrids();
> }
> {code}
>  # We shuold carefully review whole usages of stopAllGrids method in our 
> test-classes and remove if it not necessary anymore or change for using in 
> proper way\position.
>  e.g.
> {code:java|title=TcpClientDiscoverySpiSelfTest.java|borderStyle=solid}
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllClients(true);
> stopAllServers(true);
>   
>   ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8157) Remove boilerplate and unused code due to grids stopping by default

[Maxim Muzafarov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-8157:

Description: 
Changes IGNITE-6842 guarantee us stopping all Ignite instances after test 
completion by default.
 # We should remove a lot of bolerplate code in our test-classes.
 e.g.
{code:java|title=BaseDecisionTreeTest.java|borderStyle=solid}
/** {@inheritDoc} */
@Override protected void afterTestsStopped() throws Exception {
stopAllGrids();
}
{code}
 # We shuold carefully review whole usages of stopAllGrids method in our 
test-classes and remove if it not necessary anymore or change for using in 
proper way\position.
 e.g.
{code:java|title=TcpClientDiscoverySpiSelfTest.java|borderStyle=solid}
/** {@inheritDoc} */
@Override protected void afterTest() throws Exception {
stopAllClients(true);
stopAllServers(true);

...
}
{code}

  was:
Changes IGNITE-6842 guarantee us stopping all Ignite instances after test 
completion by default.
 # We should remove a lot of bolerplate code in our test-classes.
 e.g.
{code:java|title=BaseDecisionTreeTest.java|borderStyle=solid}
/** {@inheritDoc} */
@Override protected void afterTestsStopped() throws Exception {
stopAllGrids();
}
{code}

 # We shuold carefully review whole usages of stopAllGrids method in our 
test-classes and remove if it not necessary anymore or change for using in 
proper way\position.
 e.g.
{code:java|title=TcpClientDiscoverySpiSelfTest.java|borderStyle=solid}
/** {@inheritDoc} */
@Override protected void afterTest() throws Exception {
stopAllClients(true);
stopAllServers(true);

...
}
{code}


> Remove boilerplate and unused code due to grids stopping by default
> ---
>
> Key: IGNITE-8157
> URL: https://issues.apache.org/jira/browse/IGNITE-8157
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.4
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>  Labels: test
> Fix For: 2.6
>
>
> Changes IGNITE-6842 guarantee us stopping all Ignite instances after test 
> completion by default.
>  # We should remove a lot of bolerplate code in our test-classes.
>  e.g.
> {code:java|title=BaseDecisionTreeTest.java|borderStyle=solid}
> /** {@inheritDoc} */
> @Override protected void afterTestsStopped() throws Exception {
> stopAllGrids();
> }
> {code}
>  # We shuold carefully review whole usages of stopAllGrids method in our 
> test-classes and remove if it not necessary anymore or change for using in 
> proper way\position.
>  e.g.
> {code:java|title=TcpClientDiscoverySpiSelfTest.java|borderStyle=solid}
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllClients(true);
> stopAllServers(true);
>   
>   ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8157) Remove boilerplate and unused code due to grids stopping by default

[Maxim Muzafarov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-8157:

Labels: test  (was: )

> Remove boilerplate and unused code due to grids stopping by default
> ---
>
> Key: IGNITE-8157
> URL: https://issues.apache.org/jira/browse/IGNITE-8157
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.4
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>  Labels: test
> Fix For: 2.6
>
>
> Changes IGNITE-6842 guarantee us stopping all Ignite instances after test 
> completion by default.
>  # We should remove a lot of bolerplate code in our test-classes.
>  e.g.
> {code:java|title=BaseDecisionTreeTest.java|borderStyle=solid}
> /** {@inheritDoc} */
> @Override protected void afterTestsStopped() throws Exception {
> stopAllGrids();
> }
> {code}
>  # We shuold carefully review whole usages of stopAllGrids method in our 
> test-classes and remove if it not necessary anymore or change for using in 
> proper way\position.
>  e.g.
> {code:java|title=TcpClientDiscoverySpiSelfTest.java|borderStyle=solid}
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllClients(true);
> stopAllServers(true);
>   
>   ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8158) Missed cleanups if afterTestsStop throws exception

[Maxim Muzafarov (JIRA)]

Maxim Muzafarov created IGNITE-8158:
---

 Summary: Missed cleanups if afterTestsStop throws exception
 Key: IGNITE-8158
 URL: https://issues.apache.org/jira/browse/IGNITE-8158
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Maxim Muzafarov
 Fix For: 2.6


Method {{afterTestsStopped}} might throw exception. Contibutor should provide 
solution for ensuring that all cleanups in {{tearDown}} method would be 
executed in this case.

{code:java|title=GridAbstractTest.java}
/** {@inheritDoc} */
@Override protected void tearDown() throws Exception {
...

try {
afterTest();
}
finally {
serializedObj.clear();

if (isLastTest()) {

...

afterTestsStopped();

if (startGrid)
G.stop(getTestIgniteInstanceName(), true);

// Remove counters.
tests.remove(getClass());

// Remove resources cached in static, if any.
GridClassLoaderCache.clear();
U.clearClassCache();
MarshallerExclusions.clearCache();
BinaryEnumCache.clear();
}

Thread.currentThread().setContextClassLoader(clsLdr);

clsLdr = null;

cleanReferences();
}
}
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8160) GridCacheAbstractDataStructuresFailoverSelfTest#testAtomicInitialization flaky-fails on TC

[Alexey Goncharuk (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Goncharuk updated IGNITE-8160:
-
Labels: MakeTeamcityGreenAgain  (was: )

> GridCacheAbstractDataStructuresFailoverSelfTest#testAtomicInitialization 
> flaky-fails on TC
> --
>
> Key: IGNITE-8160
> URL: https://issues.apache.org/jira/browse/IGNITE-8160
> Project: Ignite
>  Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> The test fails because sequence initialization compute is sent to nodes being 
> stopped. The test should be changed to test:
> 1) If the closure may be sent to a stopping node, then NodeStoppingException 
> should be ignored
> 2) Another test should send closures only to stable nodes and should not 
> tolerate any failures



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8159) control.sh Failed with NPE in case of adding not online node in base line

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-8159:


 Summary: control.sh Failed with NPE in case of adding not online 
node in base line
 Key: IGNITE-8159
 URL: https://issues.apache.org/jira/browse/IGNITE-8159
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.4
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.5


{code}

Caused by: java.lang.NullPointerException
 at 
org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.currentBaseLine(VisorBaselineTask.java:100)
 at 
org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.add(VisorBaselineTask.java:148)
 at 
org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.run(VisorBaselineTask.java:203)
 at 
org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.run(VisorBaselineTask.java:52)
 at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
 at 
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:566)
 at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6623)
 at 
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:560)
 at 
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:489)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
 at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1123)
 at 
org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1407)
 at 
org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:660)
 at 
org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:532)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
 at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:760)
 at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:509)
 at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:489)
 at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:227)
 ... 8 more

{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[Vladimir Ozerov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428181#comment-16428181
 ] 

Vladimir Ozerov commented on IGNITE-7944:
-

[~guseinov], [~dpavlov], patch looks simple to me, but I have some doubts 
anyway:
1) Now we do not cancel child tasks in case of disconnect. Is it? Could it lead 
to some uncompleted futures or so?
2) When client is not connected, we do not throw an exception, but just exit 
{{send}} method. Ack closure is not notified either. Can we throw an exception 
instead? What would be the consequences?

> Disconnected client node tries to send JOB_CANCEL message
> -
>
> Key: IGNITE-7944
> URL: https://issues.apache.org/jira/browse/IGNITE-7944
> Project: Ignite
>  Issue Type: Bug
>  Components: messaging
>Affects Versions: 1.9, 2.3
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.5
>
> Attachments: Reproducer7944.java
>
>
> In case the network is blocked (socket connections not closed) and failure is 
> detected, tcp-client-disco-msg-worker thread can be stuck in process of 
> TcpClient creating:
> {code:java}
> "tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
> os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - locked <0x7fa140f520c0> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
> - locked <0x7fa140f520b0> (a java.lang.Object)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
> at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It looks like msg-worker is trying to send JOB_CANCEL message for each job 
> with timeout equals failureDetectionTimeout.
> Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8018) Avoid unnecessary unswap(...) call in GridCacheMapEntry.initialValue(...)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428200#comment-16428200
 ] 

ASF GitHub Bot commented on IGNITE-8018:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3686


> Avoid unnecessary unswap(...) call in GridCacheMapEntry.initialValue(...)
> -
>
> Key: IGNITE-8018
> URL: https://issues.apache.org/jira/browse/IGNITE-8018
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>  Labels: iep-16
> Fix For: 2.5
>
>
> GridCacheMapEntry.initialValue(...) method executes unswap(...) to read entry 
> version from PageMemory, but then it also executes storeValue(...) which 
> writes new value if entry is obsolete. It means that the same entry is 
> searched in PageMemory twice, which is not optimal.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-5841) Ignite SPI Suite: testReconnectAfterFailTopologyChanged() test failure with assertions

[Amelchev Nikita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amelchev Nikita reassigned IGNITE-5841:
---

Assignee: Amelchev Nikita

> Ignite SPI Suite: testReconnectAfterFailTopologyChanged() test failure with 
> assertions
> --
>
> Key: IGNITE-5841
> URL: https://issues.apache.org/jira/browse/IGNITE-5841
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Amelchev Nikita
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Found during PR testing, but fails also for master
> http://ci.ignite.apache.org/viewLog.html?buildId=740511=buildResultsDiv=Ignite20Tests_IgniteSpi
> There is flaky test failing in different suites
> TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectAfterFailTopologyChanged
> Success rate 82,1%
> {noformat}
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.reconnectAfterFail(TcpClientDiscoverySpiSelfTest.java:1422)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testReconnectAfterFailTopologyChanged(TcpClientDiscoverySpiSelfTest.java:1331)
> {noformat}
> TcpClientDiscoverySpiSelfTest.testReconnectAfterFailTopologyChanged 
> Success rate 84,3%
> {noformat}
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.reconnectAfterFail(TcpClientDiscoverySpiSelfTest.java:1422)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testReconnectAfterFailTopologyChanged(TcpClientDiscoverySpiSelfTest.java:1331)
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8160) GridCacheAbstractDataStructuresFailoverSelfTest#testAtomicInitialization flaky-fails on TC

[Alexey Goncharuk (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Goncharuk updated IGNITE-8160:
-
Fix Version/s: (was: 2.5)
   2.6

> GridCacheAbstractDataStructuresFailoverSelfTest#testAtomicInitialization 
> flaky-fails on TC
> --
>
> Key: IGNITE-8160
> URL: https://issues.apache.org/jira/browse/IGNITE-8160
> Project: Ignite
>  Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> The test fails because sequence initialization compute is sent to nodes being 
> stopped. The test should be changed to test:
> 1) If the closure may be sent to a stopping node, then NodeStoppingException 
> should be ignored
> 2) Another test should send closures only to stable nodes and should not 
> tolerate any failures



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8162) Handle ClassNotFoundException during deserialization of persisted cache configuration

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-8162:
---
Description: 
Ticket is created according to dev list discussion: 
http://apache-ignite-developers.2346864.n4.nabble.com/Fwd-Data-Loss-while-upgrading-custom-jar-from-old-jar-in-server-and-client-nodes-td28808.html
Cache configuration is serialized by JDK marshaller and persisted in 
cache_data.dat file. It may contain instances of classes that disappeared from 
runtime classpath (e.g. if implementation of CacheStore has been renamed). In 
such case, node will fail on start.
We should handle this and show meaningful message with instruction how to 
overcome this issue - delete cache_data.dat and restart cache.

  was:
Ticket is created according to dev list discussion: 
http://apache-ignite-developers.2346864.n4.nabble.com/Fwd-Data-Loss-while-upgrading-custom-jar-from-old-jar-in-server-and-client-nodes-td28808.html
Cache configuration is serialized by JDK marshaller and persisted in 
cache_data.dat file. It may contain instances of classes that disappeared from 
runtime classpath (e.g. in case implementation of CacheStore has been renamed). 
In such case, node will fail on start.
We should handle this and show meaningful message with instruction how to 
overcome this issue - delete cache_data.dat and restart cache.


> Handle ClassNotFoundException during deserialization of persisted cache 
> configuration 
> --
>
> Key: IGNITE-8162
> URL: https://issues.apache.org/jira/browse/IGNITE-8162
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.4
>Reporter: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> Ticket is created according to dev list discussion: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Fwd-Data-Loss-while-upgrading-custom-jar-from-old-jar-in-server-and-client-nodes-td28808.html
> Cache configuration is serialized by JDK marshaller and persisted in 
> cache_data.dat file. It may contain instances of classes that disappeared 
> from runtime classpath (e.g. if implementation of CacheStore has been 
> renamed). In such case, node will fail on start.
> We should handle this and show meaningful message with instruction how to 
> overcome this issue - delete cache_data.dat and restart cache.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8162) Handle ClassNotFoundException during deserialization of persisted cache configuration

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-8162:
---
Description: 
Ticket is created according to dev list discussion: 
http://apache-ignite-developers.2346864.n4.nabble.com/Fwd-Data-Loss-while-upgrading-custom-jar-from-old-jar-in-server-and-client-nodes-td28808.html
Cache configuration is serialized by JDK marshaller and persisted in 
cache_data.dat file. It may contain instances of classes that disappeared from 
runtime classpath (e.g. in case implementation of CacheStore has been renamed). 
In such case, node will fail on start.
We should handle this and show meaningful message with instruction how to 
overcome this issue - delete cache_data.dat and restart cache.

  was:
Ticket is created according to dev list discussion: 
http://apache-ignite-developers.2346864.n4.nabble.com/Fwd-Data-Loss-while-upgrading-custom-jar-from-old-jar-in-server-and-client-nodes-td28808.html
Cache configuration is serialized by JDK marshaller and persisted in 
cache_data.dat file. It may contain instances of classes that disappeared from 
runtime classpath (e.g. implementation of CacheStore has been renamed). In such 
case, node will fail on start.
We should handle this and show meaningful message with instruction how to 
overcome this issue - delete cache_data.dat and restart cache.


> Handle ClassNotFoundException during deserialization of persisted cache 
> configuration 
> --
>
> Key: IGNITE-8162
> URL: https://issues.apache.org/jira/browse/IGNITE-8162
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.4
>Reporter: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> Ticket is created according to dev list discussion: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Fwd-Data-Loss-while-upgrading-custom-jar-from-old-jar-in-server-and-client-nodes-td28808.html
> Cache configuration is serialized by JDK marshaller and persisted in 
> cache_data.dat file. It may contain instances of classes that disappeared 
> from runtime classpath (e.g. in case implementation of CacheStore has been 
> renamed). In such case, node will fail on start.
> We should handle this and show meaningful message with instruction how to 
> overcome this issue - delete cache_data.dat and restart cache.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8162) Handle ClassNotFoundException during deserialization of persisted cache configuration

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-8162:
--

 Summary: Handle ClassNotFoundException during deserialization of 
persisted cache configuration 
 Key: IGNITE-8162
 URL: https://issues.apache.org/jira/browse/IGNITE-8162
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 2.4
Reporter: Ivan Rakov
 Fix For: 2.6


Ticket is created according to dev list discussion: 
http://apache-ignite-developers.2346864.n4.nabble.com/Fwd-Data-Loss-while-upgrading-custom-jar-from-old-jar-in-server-and-client-nodes-td28808.html
Cache configuration is serialized by JDK marshaller and persisted in 
cache_data.dat file. It may contain instances of classes that disappeared from 
runtime classpath (e.g. implementation of CacheStore has been renamed). In such 
case, node will fail on start.
We should handle this and show meaningful message with instruction how to 
overcome this issue - delete cache_data.dat and restart cache.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8162) Handle ClassNotFoundException during deserialization of persisted cache configuration

[Ivan Rakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428209#comment-16428209
 ] 

Ivan Rakov commented on IGNITE-8162:


Issue should be covered by test.
We can reproduce it by passing different classloaders into IgniteConfiguration 
(one should have access to CacheStore class, another shoudln't).

> Handle ClassNotFoundException during deserialization of persisted cache 
> configuration 
> --
>
> Key: IGNITE-8162
> URL: https://issues.apache.org/jira/browse/IGNITE-8162
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.4
>Reporter: Ivan Rakov
>Priority: Major
>  Labels: newbie
> Fix For: 2.6
>
>
> Ticket is created according to dev list discussion: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Fwd-Data-Loss-while-upgrading-custom-jar-from-old-jar-in-server-and-client-nodes-td28808.html
> Cache configuration is serialized by JDK marshaller and persisted in 
> cache_data.dat file. It may contain instances of classes that disappeared 
> from runtime classpath (e.g. if implementation of CacheStore has been 
> renamed). In such case, node will fail on start.
> We should handle this and show meaningful message with instruction how to 
> overcome this issue - delete cache_data.dat and restart cache.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-5841) Ignite SPI Suite: testReconnectAfterFailTopologyChanged() test failure with assertions

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428219#comment-16428219
 ] 

Dmitriy Pavlov commented on IGNITE-5841:


Test is not OK. Test still has muted failures. Added correct label: Muted_Test

example 
https://ci.ignite.apache.org/viewLog.html?buildId=1178742=buildResultsDiv=IgniteTests24Java8_IgniteSpi#testNameId-407653158645365162


> Ignite SPI Suite: testReconnectAfterFailTopologyChanged() test failure with 
> assertions
> --
>
> Key: IGNITE-5841
> URL: https://issues.apache.org/jira/browse/IGNITE-5841
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Amelchev Nikita
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
>
> Found during PR testing, but fails also for master
> http://ci.ignite.apache.org/viewLog.html?buildId=740511=buildResultsDiv=Ignite20Tests_IgniteSpi
> There is flaky test failing in different suites
> TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectAfterFailTopologyChanged
> Success rate 82,1%
> {noformat}
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.reconnectAfterFail(TcpClientDiscoverySpiSelfTest.java:1422)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testReconnectAfterFailTopologyChanged(TcpClientDiscoverySpiSelfTest.java:1331)
> {noformat}
> TcpClientDiscoverySpiSelfTest.testReconnectAfterFailTopologyChanged 
> Success rate 84,3%
> {noformat}
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.reconnectAfterFail(TcpClientDiscoverySpiSelfTest.java:1422)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testReconnectAfterFailTopologyChanged(TcpClientDiscoverySpiSelfTest.java:1331)
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7307) H2DynamicIndexingComplexServerTransactionalReplicatedTest.testOperations fails with assertion

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7307:
-
Fix Version/s: (was: 2.5)
   2.6

> H2DynamicIndexingComplexServerTransactionalReplicatedTest.testOperations 
> fails with assertion
> -
>
> Key: IGNITE-7307
> URL: https://issues.apache.org/jira/browse/IGNITE-7307
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Fix For: 2.6
>
>
> {code}
> [2017-12-26 11:40:53,187][ERROR][main][root] Test failed.
> java.lang.AssertionError: localNode = cde0ed21-5bfa-48ee-8e47-53d85880, 
> dhtNodes = [TcpDiscoveryNode [id=49318149-4b22-40d1-b68f-8b6b2d52, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47501], discPort=47501, order=3, 
> intOrder=3, lastExchangeTime=1514277649002, loc=false, 
> ver=2.4.0#19700101-sha1:, isClient=false], TcpDiscoveryNode 
> [id=cde0ed21-5bfa-48ee-8e47-53d85880, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1514277652494, loc=true, ver=2.4.0#19700101-sha1:, 
> isClient=false], TcpDiscoveryNode [id=7530f231-3bd4-4cc0-b295-0e2f11b3, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=4, 
> intOrder=4, lastExchangeTime=1514277649456, loc=false, 
> ver=2.4.0#19700101-sha1:, isClient=false]]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1608)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1274)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:678)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1056)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareAsyncLocal(GridNearTxLocal.java:3619)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareColocatedTx(IgniteTxHandler.java:257)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.prepareLocal(GridNearPessimisticTxPrepareFuture.java:256)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.preparePessimistic(GridNearPessimisticTxPrepareFuture.java:406)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.prepare(GridNearPessimisticTxPrepareFuture.java:190)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareNearTxLocal(GridNearTxLocal.java:3323)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:3390)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commit(GridNearTxLocal.java:3350)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:429)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:177)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:212)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1809)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1645)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:2034)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:2030)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2527)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:2039)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1995)
>   at 
> org.apache.ignite.internal.processors.cache.index.H2DynamicIndexingComplexTest.executeSql(H2DynamicIndexingComplexTest.java:333)
>   at 
> 

[jira] [Updated] (IGNITE-7321) DML operation hangs in case exception is thrown from DHT enlist future

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7321:
-
Fix Version/s: (was: 2.5)
   2.6

> DML operation hangs in case exception is thrown from DHT enlist future
> --
>
> Key: IGNITE-7321
> URL: https://issues.apache.org/jira/browse/IGNITE-7321
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.6
>
>
> Root cause: when exception is thrown on primary node (e.g. double-insert or 
> MVCC version conflict), primary future is completed, but exception doesn't 
> seem to be propagated to near node.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7249) SQL TX: Commit/rollback active TX before DDL statement processing

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7249:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: Commit/rollback active TX before DDL statement processing
> -
>
> Key: IGNITE-7249
> URL: https://issues.apache.org/jira/browse/IGNITE-7249
> Project: Ignite
>  Issue Type: Test
>  Components: sql
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
>  Labels: sql
> Fix For: 2.6
>
>
> Commit/rollback active TX before DDL statement processing



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6826) Change default DiscoverySpi ipFinder type for examples

[Anton Kurbanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428231#comment-16428231
 ] 

Anton Kurbanov commented on IGNITE-6826:


[~SomeFire], exactly what what already described in comment section. Launching 
examples using both .exe and from VS with properly configured nodes using 
Apache.Ignite.exe. Nodes started by Ignite.bat/sh are using different 
configuration sourced from config/default-config.xml. As you already mentioned 
there are some exceptions being thrown in this case due to configuration 
mismatch.

Wondering if this should work with default configuration.

> Change default DiscoverySpi ipFinder type for examples
> --
>
> Key: IGNITE-6826
> URL: https://issues.apache.org/jira/browse/IGNITE-6826
> Project: Ignite
>  Issue Type: Improvement
>  Components: examples
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> It is better to change multicast ipFinder to static (vm) ipFinder for java 
> examples, .NET examples and C++ examples.
> http://apache-ignite-developers.2346864.n4.nabble.com/ipFinder-configuration-for-Samples-td23818.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7952) MVCC TX: cache clear routines for key-value API

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7952:
-
Fix Version/s: (was: 2.5)
   2.6

> MVCC TX: cache clear routines for key-value API
> ---
>
> Key: IGNITE-7952
> URL: https://issues.apache.org/jira/browse/IGNITE-7952
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Alexander Paschenko
>Priority: Major
> Fix For: 2.6
>
>
> We need to implement MVCC-compatible cache clear operations for Key-Value API.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8164) SQL TX: JDBC driver meta data update.

[Roman Kondakov (JIRA)]

Roman Kondakov created IGNITE-8164:
--

 Summary: SQL TX: JDBC driver meta data update.
 Key: IGNITE-8164
 URL: https://issues.apache.org/jira/browse/IGNITE-8164
 Project: Ignite
  Issue Type: Bug
  Components: jdbc, sql
Reporter: Roman Kondakov


Since we've implemented a transactional SQL, we need to reflect it in our JDBC 
driver. At the moment our implementation of {{java.sql.DatabaseMetaData}} 
returns incorrect data. For example, methods

{{boolean supportsTransactions()}}

and 

{{boolean supportsTransactionIsolationLevel(int level)}}

return hardcoded  {{false }}value, which is incorrect if MVCC is enabled. We 
need to fix it.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6937) SQL TX: Support SELECT FOR UPDATE

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-6937:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: Support SELECT FOR UPDATE
> -
>
> Key: IGNITE-6937
> URL: https://issues.apache.org/jira/browse/IGNITE-6937
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
>  Labels: iep-3
> Fix For: 2.6
>
>
> Normally in SQL world readers do not block writers. This is how our SELECT 
> operations should work by default. But we need to add a support for {{SELECT 
> ... FOR UPDATE}} read mode, when reader obtains exclusive lock on read. 
> In this mode we lock entries as usual, but then send data back to the caller. 
> First page can be returned directly in our {{LockResponse}}. Next pages 
> should be requested in separate requests. With this approach {{SELECT ,,, FOR 
> UPDATE}} will require only single round-trip to both lock and read data in 
> case of small updates.
> Update {{SELECT}} statement syntax once this feature is supported:
> https://apacheignite-sql.readme.io/docs/select



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7313) Recovery process doesn't propagate MVCC version

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7313:
-
Fix Version/s: (was: 2.5)
   2.6

> Recovery process doesn't propagate MVCC version
> ---
>
> Key: IGNITE-7313
> URL: https://issues.apache.org/jira/browse/IGNITE-7313
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.6
>
>
> Reproducer: 
> {{IgnitePdsContinuousRestartTest.testRebalancingDuringLoad_8000_8000_8_16}}
> Root cause: MVCC version is not passed during recovery process, as a result 
> we cannot commit transaction properly.
> Stack trace:
> {code}
> [2017-12-26 
> 17:44:03,011][ERROR][sys-stripe-5-#216%persistence.IgnitePdsContinuousRestartTest3%][G]
>  Failed to execute runnable.
> java.lang.AssertionError: Mvcc is not initialized: GridDhtTxRemote 
> [nearNodeId=5213f13a-541e-41e0-ac30-c0cdc9d0, 
> rmtFutId=ea4b6a39061-cf384028-0bcb-46d8-92e1-3c898390d074, 
> nearXidVer=GridCacheVersion [topVer=125779403, order=1514300484265, 
> nodeOrder=1], storeWriteThrough=false, super=GridDistributedTxRemoteAdapter 
> [explicitVers=null, started=true, commitAllowed=1, 
> txState=IgniteTxRemoteStateImpl [readMap={}, writeMap={IgniteTxKey 
> [key=KeyCacheObjectImpl [part=113, val=2545, hasValBytes=true], 
> cacheId=-1368047377]=IgniteTxEntry [key=KeyCacheObjectImpl [part=113, 
> val=2545, hasValBytes=true], cacheId=-1368047377, txKey=IgniteTxKey 
> [key=KeyCacheObjectImpl [part=113, val=2545, hasValBytes=true], 
> cacheId=-1368047377], val=[op=CREATE, val=CacheObjectImpl [val=null, 
> hasValBytes=true]], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null, dhtVer=null, filters=[], filtersPassed=false, 
> filtersSet=false, entry=GridDhtCacheEntry [rdrs=[], part=113, 
> super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [key=KeyCacheObjectImpl [part=113, val=2545, hasValBytes=true], 
> val=CacheObjectImpl [val=null, hasValBytes=true], startVer=1514300484409, 
> ver=GridCacheVersion [topVer=125779403, order=1514300455870, nodeOrder=2], 
> hash=2545, extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc [locs=null, 
> rmts=[GridCacheMvccCandidate [nodeId=91bcaf65-b816-41e9-a74e-ca58c821, 
> ver=GridCacheVersion [topVer=125779403, order=1514300484266, nodeOrder=2], 
> threadId=285, id=1158826, topVer=AffinityTopologyVersion [topVer=-1, 
> minorTopVer=0], reentry=null, 
> otherNodeId=5213f13a-541e-41e0-ac30-c0cdc9d0, otherVer=null, 
> mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null, serOrder=null, 
> key=KeyCacheObjectImpl [part=113, val=2545, hasValBytes=true], 
> masks=local=0|owner=1|ready=0|reentry=0|used=1|tx=1|single_implicit=0|dht_local=0|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null, flags=2]]], prepared=1, locked=false, 
> nodeId=null, locMapped=false, expiryPlc=null, transferExpiryPlc=false, 
> flags=0, partUpdateCntr=0, serReadVer=null, xidVer=null], IgniteTxKey 
> [key=KeyCacheObjectImpl [part=17, val=3089, hasValBytes=true], 
> cacheId=-1368047377]=IgniteTxEntry [key=KeyCacheObjectImpl [part=17, 
> val=3089, hasValBytes=true], cacheId=-1368047377, txKey=IgniteTxKey 
> [key=KeyCacheObjectImpl [part=17, val=3089, hasValBytes=true], 
> cacheId=-1368047377], val=[op=CREATE, val=CacheObjectImpl [val=null, 
> hasValBytes=true]], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null, dhtVer=null, filters=[], filtersPassed=false, 
> filtersSet=false, entry=GridDhtCacheEntry [rdrs=[], part=17, 
> super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [key=KeyCacheObjectImpl [part=17, val=3089, hasValBytes=true], 
> val=CacheObjectImpl [val=null, hasValBytes=true], startVer=1514300484410, 
> ver=GridCacheVersion [topVer=125779403, order=1514300459131, nodeOrder=2], 
> hash=3089, extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc [locs=null, 
> rmts=[GridCacheMvccCandidate [nodeId=91bcaf65-b816-41e9-a74e-ca58c821, 
> ver=GridCacheVersion [topVer=125779403, order=1514300484266, nodeOrder=2], 
> threadId=285, id=1158827, topVer=AffinityTopologyVersion [topVer=-1, 
> minorTopVer=0], reentry=null, 
> otherNodeId=5213f13a-541e-41e0-ac30-c0cdc9d0, otherVer=null, 
> mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null, serOrder=null, 
> key=KeyCacheObjectImpl [part=17, val=3089, hasValBytes=true], 
> masks=local=0|owner=1|ready=0|reentry=0|used=1|tx=1|single_implicit=0|dht_local=0|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null, flags=2]]], prepared=1, locked=false, 
> 

[jira] [Updated] (IGNITE-4193) SQL TX: ODBC driver support

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-4193:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: ODBC driver support
> ---
>
> Key: IGNITE-4193
> URL: https://issues.apache.org/jira/browse/IGNITE-4193
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Denis Magda
>Assignee: Igor Sapego
>Priority: Major
>  Labels: iep-3
> Fix For: 2.6
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from ODBC driver side.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8164) SQL TX: JDBC driver meta data update.

[Roman Kondakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Kondakov updated IGNITE-8164:
---
Description: 
Since we've implemented a transactional SQL, we need to reflect it in our JDBC 
driver. At the moment our implementation of {{java.sql.DatabaseMetaData}} 
returns incorrect data. For example, methods

{{boolean supportsTransactions()}}

and 

{{boolean supportsTransactionIsolationLevel(int level)}}

return hardcoded  \{{false}} value, which is incorrect if MVCC is enabled. We 
need to fix it.

 

  was:
Since we've implemented a transactional SQL, we need to reflect it in our JDBC 
driver. At the moment our implementation of {{java.sql.DatabaseMetaData}} 
returns incorrect data. For example, methods

{{boolean supportsTransactions()}}

and 

{{boolean supportsTransactionIsolationLevel(int level)}}

return hardcoded  {{false }}value, which is incorrect if MVCC is enabled. We 
need to fix it.

 


> SQL TX: JDBC driver meta data update.
> -
>
> Key: IGNITE-8164
> URL: https://issues.apache.org/jira/browse/IGNITE-8164
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Reporter: Roman Kondakov
>Priority: Major
>  Labels: iep-3
>
> Since we've implemented a transactional SQL, we need to reflect it in our 
> JDBC driver. At the moment our implementation of 
> {{java.sql.DatabaseMetaData}} returns incorrect data. For example, methods
> {{boolean supportsTransactions()}}
> and 
> {{boolean supportsTransactionIsolationLevel(int level)}}
> return hardcoded  \{{false}} value, which is incorrect if MVCC is enabled. We 
> need to fix it.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-5936) Cleanup of not needed and committed versions

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-5936:
-
Fix Version/s: (was: 2.5)
   2.6

> Cleanup of not needed and committed versions
> 
>
> Key: IGNITE-5936
> URL: https://issues.apache.org/jira/browse/IGNITE-5936
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.6
>
>
> At first committed data is stored in separate data structure.Need implement 
> some procedure to remove from mvcc storage versions which are not needed 
> anymore and flush committed versions in main storage. Version which is safe 
> to remove (there are not readers using this version) should be somehow passed 
> from coordinator to servers.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6353) Integrate mvcc support in scan query protocol

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-6353:
-
Fix Version/s: (was: 2.5)
   2.6

> Integrate mvcc support in scan query protocol
> -
>
> Key: IGNITE-6353
> URL: https://issues.apache.org/jira/browse/IGNITE-6353
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.6
>
>
> Need integrate mvcc support in scan query protocol:
> - request current ID and list of active txs from coordinator
> - pass this info in query requests and in cache iterators
> - notify coordinator after query completed



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-5935) Integrate mvcc support in tx recovery protocol

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-5935:
-
Fix Version/s: (was: 2.5)
   2.6

> Integrate mvcc support in tx recovery protocol
> --
>
> Key: IGNITE-5935
> URL: https://issues.apache.org/jira/browse/IGNITE-5935
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.6
>
>
> Need make sure tx recovery work properly with mvcc enabled:
> - tx IDs are generated and not lost if transaction is committed by recovery 
> procedure
> - tx should be removed from list of active transactions on coordinator



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8161) Suspend-resume TX test is flaky on TC (~5% fail rate)

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-8161:
--

 Summary: Suspend-resume TX test is flaky on TC (~5% fail rate)
 Key: IGNITE-8161
 URL: https://issues.apache.org/jira/browse/IGNITE-8161
 Project: Ignite
  Issue Type: Test
  Components: cache
Reporter: Dmitriy Pavlov


https://ci.ignite.apache.org/viewLog.html?buildId=1176294=buildResultsDiv=IgniteTests24Java8_Cache6#testNameId-7194341254453895210

Causal chani java.lang.RuntimeException: javax.cache.CacheException: class 
org.apache.ignite.transactions.TransactionTimeoutException: Cache transaction 
timed out: GridNearTxLocal 

First exception in log
{noformat}
validParts=null, state=MARKED_ROLLBACK, timedOut=true, 
topVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0], duration=172ms, 
onePhaseCommit=false], size=0]]]
at 
org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$CI2Exc.apply(IgniteOptimisticTxSuspendResumeTest.java:759)
at 
org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.executeTestForAllCaches(IgniteOptimisticTxSuspendResumeTest.java:728)
at 
org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.testTxTimeoutOnResumed(IgniteOptimisticTxSuspendResumeTest.java:431)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2018)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:136)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1933)
at java.lang.Thread.run(Thread.java:745)
{noformat}

Test history
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7194341254453895210=testDetails




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8161) Suspend-resume TX test is flaky on TC (~5% fail rate)

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-8161:


Assignee: Alexey Kuznetsov

> Suspend-resume TX test is flaky on TC (~5% fail rate)
> -
>
> Key: IGNITE-8161
> URL: https://issues.apache.org/jira/browse/IGNITE-8161
> Project: Ignite
>  Issue Type: Test
>  Components: cache
>Reporter: Dmitriy Pavlov
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1176294=buildResultsDiv=IgniteTests24Java8_Cache6#testNameId-7194341254453895210
> Causal chani java.lang.RuntimeException: javax.cache.CacheException: class 
> org.apache.ignite.transactions.TransactionTimeoutException: Cache transaction 
> timed out: GridNearTxLocal 
> First exception in log
> {noformat}
> validParts=null, state=MARKED_ROLLBACK, timedOut=true, 
> topVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0], duration=172ms, 
> onePhaseCommit=false], size=0]]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$CI2Exc.apply(IgniteOptimisticTxSuspendResumeTest.java:759)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.executeTestForAllCaches(IgniteOptimisticTxSuspendResumeTest.java:728)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.testTxTimeoutOnResumed(IgniteOptimisticTxSuspendResumeTest.java:431)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2018)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:136)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1933)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Test history
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7194341254453895210=testDetails



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8162) Handle ClassNotFoundException during deserialization of persisted cache configuration

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-8162:
---
Labels: newbie  (was: )

> Handle ClassNotFoundException during deserialization of persisted cache 
> configuration 
> --
>
> Key: IGNITE-8162
> URL: https://issues.apache.org/jira/browse/IGNITE-8162
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.4
>Reporter: Ivan Rakov
>Priority: Major
>  Labels: newbie
> Fix For: 2.6
>
>
> Ticket is created according to dev list discussion: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Fwd-Data-Loss-while-upgrading-custom-jar-from-old-jar-in-server-and-client-nodes-td28808.html
> Cache configuration is serialized by JDK marshaller and persisted in 
> cache_data.dat file. It may contain instances of classes that disappeared 
> from runtime classpath (e.g. if implementation of CacheStore has been 
> renamed). In such case, node will fail on start.
> We should handle this and show meaningful message with instruction how to 
> overcome this issue - delete cache_data.dat and restart cache.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8163) PDS Indexing suite is hanging on TC in different branches including master

[Sergey Chugunov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428225#comment-16428225
 ] 

Sergey Chugunov commented on IGNITE-8163:
-

Fix artifacts: [PR|https://github.com/apache/ignite/pull/3766], 
[TC|https://ci.ignite.apache.org/viewQueued.html?itemId=1183305=queuedBuildOverviewTab]

> PDS Indexing suite is hanging on TC in different branches including master
> --
>
> Key: IGNITE-8163
> URL: https://issues.apache.org/jira/browse/IGNITE-8163
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> As logs show WalCompactionTest hangs because of race between autoactivation 
> and manual activation.
> For now it is enough to fix the test itself; root cause issue will be fixed 
> later.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (IGNITE-4900) org.apache.ignite.spi.discovery.tcp.TcpDiscoverySelfTest#testFailedNodes4 periodically fails in master

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-4900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov resolved IGNITE-4900.

Resolution: Cannot Reproduce

> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySelfTest#testFailedNodes4 
> periodically fails in master
> --
>
> Key: IGNITE-4900
> URL: https://issues.apache.org/jira/browse/IGNITE-4900
> Project: Ignite
>  Issue Type: Test
>  Components: general
>Reporter: Yakov Zhdanov
>Assignee: Ivan Rakov
>Priority: Major
> Attachments: log.txt
>
>
> See attached log



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6504) Very quick checkpoint can cause AssertionError on next start from LFS

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-6504:
---
Fix Version/s: (was: 2.5)
   2.6

> Very quick checkpoint can cause AssertionError on next start from LFS
> -
>
> Key: IGNITE-6504
> URL: https://issues.apache.org/jira/browse/IGNITE-6504
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
>  Labels: newbie
> Fix For: 2.6
>
>
> Checkpoint markers are compared using their timestamps. If checkpoint took 
> less than 1 millisecond, two subsequent markers will have same timestamp, 
> which will lead to error:
> {noformat}
> java.lang.AssertionError: 
> o1=/data/teamcity/tmpfs/work/db/127_0_0_1_47503/cp/1506338145591-c4f23411-e1b1-4468-856a-4419003bba93-END.bin,
>  
> o2=/data/teamcity/tmpfs/work/db/127_0_0_1_47503/cp/1506338145591-f76c023b-9982-40d7-a1eb-855a33b710f2-END.bin
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$4.compare(GridCacheDatabaseSharedManager.java:216)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$4.compare(GridCacheDatabaseSharedManager.java:195)
> at java.util.TimSort.binarySort(TimSort.java:265)
> at java.util.TimSort.sort(TimSort.java:208)
> at java.util.TimSort.sort(TimSort.java:173)
> at java.util.Arrays.sort(Arrays.java:659)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$CheckpointHistory.loadHistory(GridCacheDatabaseSharedManager.java:2704)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$CheckpointHistory.access$2600(GridCacheDatabaseSharedManager.java:2685)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1468)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:562)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:722)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:613)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2289)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7306) Incorrect force key request processing when MVCC is enabled

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7306:
-
Fix Version/s: (was: 2.5)
   2.6

> Incorrect force key request processing when MVCC is enabled
> ---
>
> Key: IGNITE-7306
> URL: https://issues.apache.org/jira/browse/IGNITE-7306
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.6
>
>
> Reproducer: {{IgniteCacheMultiTxLockSelfTest#testExplicitLockManyKeys}}
> Root cause: when {{GridDhtForceKeysRequest}} is processed locally, we obtain 
> {{GridCacheEntryInfo}} through {{GridCacheMapEntry.info}}. Returned instance 
> is unaware of MVCC version. Need to return {{GridCacheMvccEntryInfo}} instead.
> {code}
> java.lang.AssertionError
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccInitialValue(IgniteCacheOffheapManagerImpl.java:1433)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccInitialValue(IgniteCacheOffheapManagerImpl.java:396)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2624)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture$MiniFuture.onResult(GridDhtForceKeysFuture.java:537)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onResult(GridDhtForceKeysFuture.java:199)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processForceKeyResponse(GridDhtCacheAdapter.java:176)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$11.onMessage(GridDhtTransactionalCacheAdapter.java:193)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$11.onMessage(GridDhtTransactionalCacheAdapter.java:191)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$MessageHandler.apply(GridDhtCacheAdapter.java:1406)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$MessageHandler.apply(GridDhtCacheAdapter.java:1388)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1567)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1195)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:128)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1092)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
>   at java.lang.Thread.run(Thread.java:748)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7371) MVCC TX Repeatable read semantic

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7371:
-
Fix Version/s: (was: 2.5)
   2.6

> MVCC TX Repeatable read semantic
> 
>
> Key: IGNITE-7371
> URL: https://issues.apache.org/jira/browse/IGNITE-7371
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Reporter: Igor Seliverstov
>Priority: Major
> Fix For: 2.6
>
>
> Repeatable read isolation implies that each GET operation whithin tx gets a 
> last commited version of entry *at the time the tx was started*. Curentrly we 
> get a last commited version of entry *at the time the first read operation 
> invokes on a particular key whithin tx.* We need to fix this unconsistence.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7280) SQL TX: improve JDBC test coverage

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7280:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: improve JDBC test coverage
> --
>
> Key: IGNITE-7280
> URL: https://issues.apache.org/jira/browse/IGNITE-7280
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.6
>
>
> The following cases must be handled:
> 1) Single update stmt in TX
> 2) Multiple update stmts in TX
> 3) Changes to multiple caches in TX
> 4) Mix of both selects and updates (e.g. get data from select and then build 
> updates based on it)
> 5) Different operation types - INSERT, UPDATE, MERGE (take in count various 
> DML optimizations to ensure that as much code paths are covered as possible)
> 6) Batch updates
> 7) Joins (both co-located and distributed)
> 8) Different cache modes - PARTITIONED, REPLICATED
> 9) Different backup counts
> 10) Communication with client node vs communication with server node
> 11) Both implicit and explicit transactions



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7302) SQL TX: Failed to query INFORMATIONAL_SCHEMA

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7302:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: Failed to query INFORMATIONAL_SCHEMA
> 
>
> Key: IGNITE-7302
> URL: https://issues.apache.org/jira/browse/IGNITE-7302
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.6
>
>
> {code}
> javax.cache.CacheException: class org.apache.ignite.IgniteException: 
> Unsupported query: Unexpected Table implementation [cls=MetaTable]
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.assert0(GridSqlQueryParser.java:1876)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseTable(GridSqlQueryParser.java:612)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseTableFilter(GridSqlQueryParser.java:565)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseSelect(GridSqlQueryParser.java:665)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseQuery(GridSqlQueryParser.java:1539)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parse(GridSqlQueryParser.java:1490)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.mvccTracker(IgniteH2Indexing.java:1294)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:926)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:870)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:1163)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:1951)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:1936)
> at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2521)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1968)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at 
> org.apache.ignite.internal.processors.cache.local.IgniteCacheLocalFieldsQuerySelfTest.testInformationSchema(IgniteCacheLocalFieldsQuerySelfTest.java:49)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6888) Cache involved tables set for statement

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-6888:
-
Fix Version/s: (was: 2.5)
   2.6

> Cache involved tables set for statement
> ---
>
> Key: IGNITE-6888
> URL: https://issues.apache.org/jira/browse/IGNITE-6888
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Igor Seliverstov
>Priority: Major
> Fix For: 2.6
>
>
> Currently we have to create AST from {{PreparedStatement}} to collect and 
> process all involved 
> in the query caches (See IgniteH2Indexing#mvccTracker}}). It makes sense to 
> cache parse results per statements by analogy with statements itself.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6921) Optimise tx/queries tracking when mvcc is enabled and local caches are used

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-6921:
-
Fix Version/s: (was: 2.5)
   2.6

> Optimise tx/queries tracking when mvcc is enabled and local caches are used
> ---
>
> Key: IGNITE-6921
> URL: https://issues.apache.org/jira/browse/IGNITE-6921
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Igor Seliverstov
>Priority: Major
>  Labels: sql
> Fix For: 2.6
>
>
> Seems we don't need to request mvcc version and track tx/queries on mvcc 
> coordinator when only local caches are used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-3478) Multi-version concurrency control

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-3478:
-
Fix Version/s: (was: 2.5)
   2.6

> Multi-version concurrency control
> -
>
> Key: IGNITE-3478
> URL: https://issues.apache.org/jira/browse/IGNITE-3478
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: important
> Fix For: 2.6
>
>
> Current Ignite SQL does not take into account transaction boundaries. For 
> example, if a transaction atomically changes balance of two accounts, then a 
> concurrent SQL query can see partially committed transaction. This works for 
> data analytics, but does not work for more strict and demanding scenarios.
> It would be perfect if we had a mode which ensures transaction boundaries are 
> taken into account for SQL query.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7185) SQL TX: Updates during rebalancing.

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7185:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: Updates during rebalancing.
> ---
>
> Key: IGNITE-7185
> URL: https://issues.apache.org/jira/browse/IGNITE-7185
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Igor Seliverstov
>Priority: Major
>  Labels: iep-3, sql
> Fix For: 2.6
>
>
> Crrently we map an update operation to data nodes and perform it on all the 
> nodes simultaneously. It works fine on stable topology but produces many 
> issues if the operation happens at the rebalance time because we cannot query 
> data properly if some partitions are in moving state.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7187) SQL TX: Near caches support

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov updated IGNITE-7187:
-
Fix Version/s: (was: 2.5)
   2.6

> SQL TX: Near caches support
> ---
>
> Key: IGNITE-7187
> URL: https://issues.apache.org/jira/browse/IGNITE-7187
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Igor Seliverstov
>Priority: Major
>  Labels: iep-3, sql
> Fix For: 2.6
>
>
> Currently near readers don't participate in SQL transactions, we need to 
> notify near readers on updates.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8157) Remove boilerplate and unused code due to grids stopping by default

[Maxim Muzafarov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-8157:

Description: 
Changes IGNITE-6842 guarantee us stopping all Ignite instances after test 
completion by default.
 # We should remove a lot of bolerplate code in our test-classes.
 e.g.
{code:java|title=BaseDecisionTreeTest.java|borderStyle=solid}
/** {@inheritDoc} */
@Override protected void afterTestsStopped() throws Exception {
stopAllGrids();
}
{code}

 # We shuold carefully review whole usages of stopAllGrids method in our 
test-classes and remove if it not necessary anymore or change for using in 
proper way\position.
 e.g.
{code:java|title=TcpClientDiscoverySpiSelfTest.java|borderStyle=solid}
/** {@inheritDoc} */
@Override protected void afterTest() throws Exception {
stopAllClients(true);
stopAllServers(true);

...
}
{code}

  was:
Changes IGNITE-6842 guarantee us stopping all Ignite instances after test 
completion by default.
 # We should remove a lot of bolerplate code. 
e.g.
{code:java|title=BaseDecisionTreeTest.java|borderStyle=solid}
/** {@inheritDoc} */
@Override protected void afterTestsStopped() throws Exception {
stopAllGrids();
}
{code}
 # We shuold carefully review whole usages of stopAllGrids method and remove if 
it not necessary anymore or change for using in proper way\position. 
e.g.
{code:java|title=TcpClientDiscoverySpiSelfTest.java|borderStyle=solid}
/** {@inheritDoc} */
@Override protected void afterTest() throws Exception {
stopAllClients(true);
stopAllServers(true);

...
}
{code}


> Remove boilerplate and unused code due to grids stopping by default
> ---
>
> Key: IGNITE-8157
> URL: https://issues.apache.org/jira/browse/IGNITE-8157
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.4
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>  Labels: test
> Fix For: 2.6
>
>
> Changes IGNITE-6842 guarantee us stopping all Ignite instances after test 
> completion by default.
>  # We should remove a lot of bolerplate code in our test-classes.
>  e.g.
> {code:java|title=BaseDecisionTreeTest.java|borderStyle=solid}
> /** {@inheritDoc} */
> @Override protected void afterTestsStopped() throws Exception {
> stopAllGrids();
> }
> {code}
>  # We shuold carefully review whole usages of stopAllGrids method in our 
> test-classes and remove if it not necessary anymore or change for using in 
> proper way\position.
>  e.g.
> {code:java|title=TcpClientDiscoverySpiSelfTest.java|borderStyle=solid}
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllClients(true);
> stopAllServers(true);
>   
>   ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)