[jira] [Commented] (IGNITE-6449) Visor CMD: Show missed cache properties

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-6449:


Tested.

> Visor CMD: Show missed cache properties
> ---
>
> Key: IGNITE-6449
> URL: https://issues.apache.org/jira/browse/IGNITE-6449
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-6449) Visor CMD: Show missed cache properties

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-6449.
--

> Visor CMD: Show missed cache properties
> ---
>
> Key: IGNITE-6449
> URL: https://issues.apache.org/jira/browse/IGNITE-6449
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6461) Web Console: sanitize user on save

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6461:


Assignee: Alexey Kuznetsov  (was: Ilya Borisov)

> Web Console: sanitize user on save
> --
>
> Key: IGNITE-6461
> URL: https://issues.apache.org/jira/browse/IGNITE-6461
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6461) Web Console: sanitize user on save

[Ilya Borisov (JIRA)]

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

Ilya Borisov commented on IGNITE-6461:
--

[~kuaw26] looks good, I wasn't able to reproduce the issue.

> Web Console: sanitize user on save
> --
>
> Key: IGNITE-6461
> URL: https://issues.apache.org/jira/browse/IGNITE-6461
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Ilya Borisov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-6435) Web Console: Add release version to footer

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-6435.
--

> Web Console: Add release version to footer
> --
>
> Key: IGNITE-6435
> URL: https://issues.apache.org/jira/browse/IGNITE-6435
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6435) Web Console: Add release version to footer

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-6435:


Tested.

> Web Console: Add release version to footer
> --
>
> Key: IGNITE-6435
> URL: https://issues.apache.org/jira/browse/IGNITE-6435
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6446) Stuck on "Loading" screen

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6446:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Looks good. Merged to master. Please retest.

> Stuck on "Loading" screen
> -
>
> Key: IGNITE-6446
> URL: https://issues.apache.org/jira/browse/IGNITE-6446
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Ilya Borisov
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>
> *What happens:*
> Web console gets stuck in loading screen when user opens any URL without 
> prior app navigation and any permission check or HTTP request fails due to 
> missing/expired authorization cookie.
> *How to reproduce:*
> 1. Log out of web console or open private browser tab.
> 2. Go to http://locahost:9000/configuration/basic
> *What should happen:*
> User should be redirected to either 403 or signin screen.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6462) @SpringResource block Service Node bootstrap when the node starts at the first time

[redtank (JIRA)]

redtank created IGNITE-6462:
---

 Summary: @SpringResource block Service Node bootstrap when the 
node starts at the first time
 Key: IGNITE-6462
 URL: https://issues.apache.org/jira/browse/IGNITE-6462
 Project: Ignite
  Issue Type: Bug
  Components: managed services, spring
Affects Versions: 2.1, 2.2
 Environment: OS: OSX 10.12
Java: 1.8.0_112-b16
Kotlin: 1.1.4-3
Reporter: redtank


@SpringResource block Service Node bootstrap and service deployment when the 
node starts at the first time. After killing the service node and restarting, 
the service is deployed successfully.

My steps is

1. Start the data node

```
fun main(args: Array) {
SpringApplication(DataNodeApplication::class.java).apply {
addInitializers(
ApplicationContextInitializer {
DataNodeApplication.beans().initialize(it)
}
)
}.run(*args)
}

@SpringBootConfiguration
@EnableAutoConfiguration
class DataNodeApplication {

companion object {
fun beans() = beans {
bean("igniteInstance") {
// Ignite configuration with all defaults
// and enabled p2p deployment and enabled events.
val igniteConfig = IgniteConfiguration().apply {
isPeerClassLoadingEnabled = true

/*
Labeling Data Nodes with special attribute.
This attribute is checked by 
common.filters.DataNodeFilters
which decides where caches have to be deployed.
 */
userAttributes = mutableMapOf("data.node" to true)

// Configuring caches that will be deployed on Data Nodes
setCacheConfiguration(
// Cache for QuoteRequest
CacheConfiguration().apply {
name = "QuoteRequest"
/*
Enabling a special nodes filter for the 
cache. The filter
will make sure that the cache will be 
deployed only on Data
Nodes, the nodes that have 'data.node' 
attribute in the local
node map.
 */
nodeFilter = DataNodeFilter()
},
// Cache for Maintenance records
CacheConfiguration().apply {
name = "maintenance"
/*
Enabling a special nodes filter for the 
cache. The filter
will make sure that the cache will be 
deployed only on Data
Nodes, the nodes that have 'data.node' 
attribute in the local
node map.
 */
nodeFilter = DataNodeFilter()

// Enabling our sample cache store for the 
Maintenance cache

setCacheStoreFactory(FactoryBuilder.factoryOf("common.cachestore.SimpleCacheStore"))

// Avoid Maintenance objects deserialization on 
data nodes side
// when they are passed to SampleCacheStore.
isStoreKeepBinary = true

// Enabling the write-through feature for the 
store.
isWriteThrough = true

// Enabling the read-through feature for the 
store.
isReadThrough = true

// Configuring SQL schema.
queryEntities = listOf(
QueryEntity().apply {
// Setting indexed type's key class
keyType = "java.lang.Integer"

// Setting indexed type's value 
class
valueType = "entity.Maintenance"

// Defining fields that will be 
either indexed or queryable.
// Indexed fields are added to 
'indexes' list below.
fields = linkedMapOf("vehicleId" to 
"java.lang.Integer")

// Defining indexed fields.
// Single field (aka. column) index
indexes = 

[jira] [Created] (IGNITE-6461) Web Console: sanitize user on save

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-6461:


 Summary: Web Console: sanitize user on save
 Key: IGNITE-6461
 URL: https://issues.apache.org/jira/browse/IGNITE-6461
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.3






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6446) Stuck on "Loading" screen

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6446:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Please test several URLs in incognito mode.

> Stuck on "Loading" screen
> -
>
> Key: IGNITE-6446
> URL: https://issues.apache.org/jira/browse/IGNITE-6446
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Ilya Borisov
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>
> *What happens:*
> Web console gets stuck in loading screen when user opens any URL without 
> prior app navigation and any permission check or HTTP request fails due to 
> missing/expired authorization cookie.
> *How to reproduce:*
> 1. Log out of web console or open private browser tab.
> 2. Go to http://locahost:9000/configuration/basic
> *What should happen:*
> User should be redirected to either 403 or signin screen.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-995) Nodes on one host doesn't discover each other if IP finder doesn't explicitly provide port

[Mikhail Lipkovich (JIRA)]

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

Mikhail Lipkovich reassigned IGNITE-995:


Assignee: Mikhail Lipkovich

> Nodes on one host doesn't discover each other if IP finder doesn't explicitly 
> provide port
> --
>
> Key: IGNITE-995
> URL: https://issues.apache.org/jira/browse/IGNITE-995
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Mikhail Lipkovich
>Priority: Minor
>  Labels: Usability, newbie
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6442) Deadlock detection doesn't execute.

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-6442 at 9/20/17 9:34 PM:
--

[~VitaliyB]

It's bad idea to check that deadlock detection procedure was initiated using 
log messages. In all tests we have expectation about deadlock detection: at 
least one transaction should detect deadlock. It's enough for tests purposes 
and more reliable because can't be affected by log message changes. Please, fix 
it.


was (Author: agura):
[~VitaliyB]

It's bad idead to check that deadlock detection procedure was initiated using 
log messages. In all tests we have expectation about deadlock detection: at 
least one transaction should detect deadlock. It's enough for tests purposes 
and more reliable because can't be affected by log message changes. Please, fix 
it.

> Deadlock detection doesn't execute.
> ---
>
> Key: IGNITE-6442
> URL: https://issues.apache.org/jira/browse/IGNITE-6442
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
> Fix For: 2.3
>
>
> In case of a configuration with near cache and if all entities of one of the 
> transactions involved in the deadlock are on the node being the initiator of 
> this transaction, then immediately after the timeout, the transaction rolls 
> back (without calling DD).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6442) Deadlock detection doesn't execute.

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-6442:

Fix Version/s: 2.3

> Deadlock detection doesn't execute.
> ---
>
> Key: IGNITE-6442
> URL: https://issues.apache.org/jira/browse/IGNITE-6442
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
> Fix For: 2.3
>
>
> In case of a configuration with near cache and if all entities of one of the 
> transactions involved in the deadlock are on the node being the initiator of 
> this transaction, then immediately after the timeout, the transaction rolls 
> back (without calling DD).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-3935) ClassLoaders are not switched during object deserialization

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3935:


Github user knovik closed the pull request at:

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


> ClassLoaders are not switched during object deserialization
> ---
>
> Key: IGNITE-3935
> URL: https://issues.apache.org/jira/browse/IGNITE-3935
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.6
>Reporter: Denis Magda
>
> If an object is being deserialized with ClassLoader A then this ClassLoader A 
> will be used for the deserialization of the whole object's state, i.e., 
> including all its fields that can be custom objects loaded by ClassLoader B. 
> In a basic scenario we can have an object of some Ignite class that is 
> presented in the classpath. That Ignite class may enclose an object that is 
> loaded by peer-class-loading class loader. The deserialization will fail 
> because Ignite won't switch to the peer-class-loading loader when it's needed.
> To reproduce the issue do the following:
> 1. Start a remote ignite node using {{./ignite.sh 
> ../examples/config/example-ignite.xml}}
> 2. Run the code below
> {code}
> public class StreamingExample {`
> public static class StreamingExampleCacheEntryProcessor implements 
> CacheEntryProcessor {
> @Override
> public Object process(MutableEntry e, Object... arg) throws 
> EntryProcessorException {
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache = 
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr = 
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(StreamTransformer.from(new 
> StreamingExampleCacheEntryProcessor()));
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> {code}
> However if to modify this code to the following everything will work fine 
> {code}
> public class StreamingExample {
> public static class StreamingExampleCacheEntryProcessor extends 
> StreamTransformer {
> @Override
> public Object process(MutableEntry e, Object... arg) 
> throws EntryProcessorException {
> System.out.println("Executed!");
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, 
> IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache = 
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr = 
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(new StreamingExampleCacheEntryProcessor());
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6460) Wrong consistentId for lightweight ClusterNode instances

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6460:


GitHub user EdShangGG opened a pull request:

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

IGNITE-6460 Wrong consistentId for lightweight ClusterNode instances



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

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

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

https://github.com/apache/ignite/pull/2707.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 #2707


commit 7ece513e55e089ebc00de2d5675066f7eaf8af51
Author: Eduard Shangareev 
Date:   2017-09-20T20:36:55Z

IGNITE-6460 Wrong consistentId for lightweight ClusterNode instances




> Wrong consistentId for lightweight ClusterNode instances
> 
>
> Key: IGNITE-6460
> URL: https://issues.apache.org/jira/browse/IGNITE-6460
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
> Fix For: 2.3
>
>
> I have introduced new constructor for TcpDiscoveryNode to create lightweight 
> instances to store them on disc or etc.
> But to save consistentId we need not only keep it in field, but also add to 
> node attributes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-3935) ClassLoaders are not switched during object deserialization

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3935:


GitHub user knovik opened a pull request:

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

IGNITE-3935 Test on deserialization from different nodes

ClassloaderSwitchSelfTest.java implements a test-case where class loaders 
should be switched to the peer-class-loading loader refering to IGNITE-3935 
issue.

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

$ git pull https://github.com/knovik/ignite IGNITE-3935

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

https://github.com/apache/ignite/pull/2708.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 #2708


commit 107fff32693f18a73e9543bae9f496efd74cc6eb
Author: koctbik 
Date:   2017-09-19T15:00:38Z

IGNITE-3935 Testcase on class loader switching included in test suit 
CacheExamples

commit f7cd9116aab05c0e430ef5f5cd892b4a4b0f2a9e
Author: knovik 
Date:   2017-09-20T20:29:25Z

This closes pull req




> ClassLoaders are not switched during object deserialization
> ---
>
> Key: IGNITE-3935
> URL: https://issues.apache.org/jira/browse/IGNITE-3935
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.6
>Reporter: Denis Magda
>
> If an object is being deserialized with ClassLoader A then this ClassLoader A 
> will be used for the deserialization of the whole object's state, i.e., 
> including all its fields that can be custom objects loaded by ClassLoader B. 
> In a basic scenario we can have an object of some Ignite class that is 
> presented in the classpath. That Ignite class may enclose an object that is 
> loaded by peer-class-loading class loader. The deserialization will fail 
> because Ignite won't switch to the peer-class-loading loader when it's needed.
> To reproduce the issue do the following:
> 1. Start a remote ignite node using {{./ignite.sh 
> ../examples/config/example-ignite.xml}}
> 2. Run the code below
> {code}
> public class StreamingExample {`
> public static class StreamingExampleCacheEntryProcessor implements 
> CacheEntryProcessor {
> @Override
> public Object process(MutableEntry e, Object... arg) throws 
> EntryProcessorException {
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache = 
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr = 
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(StreamTransformer.from(new 
> StreamingExampleCacheEntryProcessor()));
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> {code}
> However if to modify this code to the following everything will work fine 
> {code}
> public class StreamingExample {
> public static class StreamingExampleCacheEntryProcessor extends 
> StreamTransformer {
> @Override
> public Object process(MutableEntry e, Object... arg) 
> throws EntryProcessorException {
> System.out.println("Executed!");
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, 
> IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache = 
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr = 
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(new StreamingExampleCacheEntryProcessor());
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6460) Wrong consistentId for lightweight ClusterNode instances

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev reassigned IGNITE-6460:
-

Assignee: Alexey Goncharuk  (was: Eduard Shangareev)

> Wrong consistentId for lightweight ClusterNode instances
> 
>
> Key: IGNITE-6460
> URL: https://issues.apache.org/jira/browse/IGNITE-6460
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Alexey Goncharuk
> Fix For: 2.3
>
>
> I have introduced new constructor for TcpDiscoveryNode to create lightweight 
> instances to store them on disc or etc.
> But to save consistentId we need not only keep it in field, but also add to 
> node attributes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6460) Wrong consistentId for lightweight ClusterNode instances

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev commented on IGNITE-6460:
---

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

Please, review.

> Wrong consistentId for lightweight ClusterNode instances
> 
>
> Key: IGNITE-6460
> URL: https://issues.apache.org/jira/browse/IGNITE-6460
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
> Fix For: 2.3
>
>
> I have introduced new constructor for TcpDiscoveryNode to create lightweight 
> instances to store them on disc or etc.
> But to save consistentId we need not only keep it in field, but also add to 
> node attributes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6460) Wrong consistentId for lightweight ClusterNode instances

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-6460:
-

 Summary: Wrong consistentId for lightweight ClusterNode instances
 Key: IGNITE-6460
 URL: https://issues.apache.org/jira/browse/IGNITE-6460
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Eduard Shangareev
Assignee: Eduard Shangareev
 Fix For: 2.3


I have introduced new constructor for TcpDiscoveryNode to create lightweight 
instances to store them on disc or etc.
But to save consistentId we need not only keep it in field, but also add to 
node attributes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6380) Exception should be thrown on cache creation attempt inside transaction

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-6380 at 9/20/17 3:13 PM:
---

[~xtern],

Simplified reproducer:
{noformat}
public void test() throws Exception {
Ignite ignite = startGrid();

final IgniteCache cache1 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache1"));

final IgniteCache cache2 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache2"));

final CountDownLatch latch1 = new CountDownLatch(1);

Thread t = new Thread(new Runnable() {
@Override public void run() {
Lock lock = cache2.lock("fake");

try {
lock.lock();

System.out.println("Locked");

latch1.countDown();

Thread.sleep(1000);

cache1.clear();
}
catch (Exception e) {
e.printStackTrace();

throw new RuntimeException(e);
}
finally {
lock.unlock();
}
}
});

t.start();

try {
latch1.await();
}
catch (InterruptedException e) {
e.printStackTrace();
}

ignite.getOrCreateCache(new CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache3"));

System.out.println("No deadlock");
}
{noformat}

{{cache.clear()}} cause {{ctx.kernalContext().task().execute(...)}} which will 
be mapped to pending topology.

We should restrict such call when lock is locked and there is pending topology.
Please make sure we have no such issues under started optimistic transaction.

Simple addition of 
{{throw new IgniteException("")}}
imitating found locked lock
to  
{{org.apache.ignite.internal.processors.task.GridTaskProcessor#execute(org.apache.ignite.compute.ComputeTask,
 T, boolean, java.lang.String)}}
fixing reproducer.


was (Author: avinogradov):
[~xtern],

Simplified reproducer:
{noformat}
public void test() throws Exception {
Ignite ignite = startGrid();

final IgniteCache cache1 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache1"));

final IgniteCache cache2 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache2"));

final CountDownLatch latch1 = new CountDownLatch(1);

Thread t = new Thread(new Runnable() {
@Override public void run() {
Lock lock = cache2.lock("fake");

try {
lock.lock();

System.out.println("Locked");

latch1.countDown();

Thread.sleep(1000);

cache1.clear();
}
catch (Exception e) {
e.printStackTrace();

throw new RuntimeException(e);
}
finally {
lock.unlock();
}
}
});

t.start();

try {
latch1.await();
}
catch (InterruptedException e) {
e.printStackTrace();
}

ignite.getOrCreateCache(new CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache3"));

System.out.println("No deadlock");
}
{noformat}

{{cache.clear()}} cause {{ctx.kernalContext().task().execute(...)}} which will 
be mapped to pending topology.

We should restrict such call when lock is locked and there is pending topology.
Please make sure we have no such issues under started transaction.

Simple addition of 
{{throw new IgniteException("")}}
imitating found locked lock
to  
{{org.apache.ignite.internal.processors.task.GridTaskProcessor#execute(org.apache.ignite.compute.ComputeTask,
 T, boolean, java.lang.String)}}
fixing reproducer.

> Exception should be thrown on cache creation attempt inside transaction
> ---
>
> Key: IGNITE-6380
> URL: https://issues.apache.org/jira/browse/IGNITE-6380
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Pavel Pereslegin
>  Labels: newbie, 

[jira] [Comment Edited] (IGNITE-6380) Exception should be thrown on cache creation attempt inside transaction

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-6380 at 9/20/17 3:13 PM:
---

[~xtern],

Simplified reproducer:
{noformat}
public void test() throws Exception {
Ignite ignite = startGrid();

final IgniteCache cache1 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache1"));

final IgniteCache cache2 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache2"));

final CountDownLatch latch1 = new CountDownLatch(1);

Thread t = new Thread(new Runnable() {
@Override public void run() {
Lock lock = cache2.lock("fake");

try {
lock.lock();

System.out.println("Locked");

latch1.countDown();

Thread.sleep(1000);

cache1.clear();
}
catch (Exception e) {
e.printStackTrace();

throw new RuntimeException(e);
}
finally {
lock.unlock();
}
}
});

t.start();

try {
latch1.await();
}
catch (InterruptedException e) {
e.printStackTrace();
}

ignite.getOrCreateCache(new CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache3"));

System.out.println("No deadlock");
}
{noformat}

{{cache.clear()}} cause {{ctx.kernalContext().task().execute(...)}} which will 
be mapped to pending topology.

We should restrict such call when lock is locked and there is pending topology.
Please make sure we have no such issues under started transaction.

Simple addition of 
{{throw new IgniteException("")}}
imitating found locked lock
to  
{{org.apache.ignite.internal.processors.task.GridTaskProcessor#execute(org.apache.ignite.compute.ComputeTask,
 T, boolean, java.lang.String)}}
fixing reproducer.


was (Author: avinogradov):
[~xtern],

Simplified reproducer:
{noformat}
public void test() throws Exception {
Ignite ignite = startGrid();

final IgniteCache cache1 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache1"));

final IgniteCache cache2 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache2"));

final CountDownLatch latch1 = new CountDownLatch(1);

Thread t = new Thread(new Runnable() {
@Override public void run() {
Lock lock = cache2.lock("fake");

try {
lock.lock();

System.out.println("Locked");

latch1.countDown();

Thread.sleep(1000);

cache1.clear();
}
catch (Exception e) {
e.printStackTrace();

throw new RuntimeException(e);
}
finally {
lock.unlock();
}
}
});

t.start();

try {
latch1.await();
}
catch (InterruptedException e) {
e.printStackTrace();
}

ignite.getOrCreateCache(new CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache3"));

System.out.println("No deadlock");
}
{noformat}

{{cache.clear()}} cause {{ctx.kernalContext().task().execute(...)}} which will 
be mapped to pending topology.

We should restrict such call when lock is locked and there is pending topology.

Simple addition of 
{{throw new IgniteException("")}}
imitating found locked lock
to  
{{org.apache.ignite.internal.processors.task.GridTaskProcessor#execute(org.apache.ignite.compute.ComputeTask,
 T, boolean, java.lang.String)}}
fixing reproducer.

> Exception should be thrown on cache creation attempt inside transaction
> ---
>
> Key: IGNITE-6380
> URL: https://issues.apache.org/jira/browse/IGNITE-6380
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Pavel Pereslegin
>  Labels: newbie, usability
>
> Exception should be thrown on cache creation attempt inside 

[jira] [Comment Edited] (IGNITE-6380) Exception should be thrown on cache creation attempt inside transaction

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-6380 at 9/20/17 3:11 PM:
---

[~xtern],

Simplified reproducer:
{noformat}
public void test() throws Exception {
Ignite ignite = startGrid();

final IgniteCache cache1 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache1"));

final IgniteCache cache2 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache2"));

final CountDownLatch latch1 = new CountDownLatch(1);

Thread t = new Thread(new Runnable() {
@Override public void run() {
Lock lock = cache2.lock("fake");

try {
lock.lock();

System.out.println("Locked");

latch1.countDown();

Thread.sleep(1000);

cache1.clear();
}
catch (Exception e) {
e.printStackTrace();

throw new RuntimeException(e);
}
finally {
lock.unlock();
}
}
});

t.start();

try {
latch1.await();
}
catch (InterruptedException e) {
e.printStackTrace();
}

ignite.getOrCreateCache(new CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache3"));

System.out.println("No deadlock");
}
{noformat}

cache.clear cause ctx.kernalContext().task().execute(...) which will be mapped 
to pending topology.

We should restrict such call when lock is locked and there is pending topology.

Simple addition of 
{{throw new IgniteException("")}}
imitating found locked lock
to  
{{org.apache.ignite.internal.processors.task.GridTaskProcessor#execute(org.apache.ignite.compute.ComputeTask,
 T, boolean, java.lang.String)}}
fixing reproducer.


was (Author: avinogradov):
[~xtern],

Simplified reproducer:
{noformat}
public void test() throws Exception {
Ignite ignite = startGrid();

final IgniteCache cache1 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache1"));

final IgniteCache cache2 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache2"));

final CountDownLatch latch1 = new CountDownLatch(1);

Thread t = new Thread(new Runnable() {
@Override public void run() {
Lock lock = cache2.lock("fake");

try {
lock.lock();

System.out.println("Locked");

latch1.countDown();

Thread.sleep(1000);

cache1.clear();
}
catch (Exception e) {
e.printStackTrace();

throw new RuntimeException(e);
}
finally {
lock.unlock();
}
}
});

t.start();

try {
latch1.await();
}
catch (InterruptedException e) {
e.printStackTrace();
}

ignite.getOrCreateCache(new CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache3"));

System.out.println("No deadlock");
}
{noformat}

> Exception should be thrown on cache creation attempt inside transaction
> ---
>
> Key: IGNITE-6380
> URL: https://issues.apache.org/jira/browse/IGNITE-6380
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Pavel Pereslegin
>  Labels: newbie, usability
>
> Exception should be thrown on cache creation attempt inside transaction to 
> prevent deadlocks since cache start triggers exchange and exchange cannot 
> finish until all txs are finished.
> We need to check if thread owns a tx before starting cache and if it does 
> then IllegalStateException should be thrown.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6380) Exception should be thrown on cache creation attempt inside transaction

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-6380 at 9/20/17 3:11 PM:
---

[~xtern],

Simplified reproducer:
{noformat}
public void test() throws Exception {
Ignite ignite = startGrid();

final IgniteCache cache1 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache1"));

final IgniteCache cache2 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache2"));

final CountDownLatch latch1 = new CountDownLatch(1);

Thread t = new Thread(new Runnable() {
@Override public void run() {
Lock lock = cache2.lock("fake");

try {
lock.lock();

System.out.println("Locked");

latch1.countDown();

Thread.sleep(1000);

cache1.clear();
}
catch (Exception e) {
e.printStackTrace();

throw new RuntimeException(e);
}
finally {
lock.unlock();
}
}
});

t.start();

try {
latch1.await();
}
catch (InterruptedException e) {
e.printStackTrace();
}

ignite.getOrCreateCache(new CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache3"));

System.out.println("No deadlock");
}
{noformat}

{{cache.clear()}} cause {{ctx.kernalContext().task().execute(...)}} which will 
be mapped to pending topology.

We should restrict such call when lock is locked and there is pending topology.

Simple addition of 
{{throw new IgniteException("")}}
imitating found locked lock
to  
{{org.apache.ignite.internal.processors.task.GridTaskProcessor#execute(org.apache.ignite.compute.ComputeTask,
 T, boolean, java.lang.String)}}
fixing reproducer.


was (Author: avinogradov):
[~xtern],

Simplified reproducer:
{noformat}
public void test() throws Exception {
Ignite ignite = startGrid();

final IgniteCache cache1 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache1"));

final IgniteCache cache2 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache2"));

final CountDownLatch latch1 = new CountDownLatch(1);

Thread t = new Thread(new Runnable() {
@Override public void run() {
Lock lock = cache2.lock("fake");

try {
lock.lock();

System.out.println("Locked");

latch1.countDown();

Thread.sleep(1000);

cache1.clear();
}
catch (Exception e) {
e.printStackTrace();

throw new RuntimeException(e);
}
finally {
lock.unlock();
}
}
});

t.start();

try {
latch1.await();
}
catch (InterruptedException e) {
e.printStackTrace();
}

ignite.getOrCreateCache(new CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache3"));

System.out.println("No deadlock");
}
{noformat}

cache.clear cause ctx.kernalContext().task().execute(...) which will be mapped 
to pending topology.

We should restrict such call when lock is locked and there is pending topology.

Simple addition of 
{{throw new IgniteException("")}}
imitating found locked lock
to  
{{org.apache.ignite.internal.processors.task.GridTaskProcessor#execute(org.apache.ignite.compute.ComputeTask,
 T, boolean, java.lang.String)}}
fixing reproducer.

> Exception should be thrown on cache creation attempt inside transaction
> ---
>
> Key: IGNITE-6380
> URL: https://issues.apache.org/jira/browse/IGNITE-6380
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Pavel Pereslegin
>  Labels: newbie, usability
>
> Exception should be thrown on cache creation attempt inside transaction to 
> prevent deadlocks since cache start triggers exchange and 

[jira] [Commented] (IGNITE-6380) Exception should be thrown on cache creation attempt inside transaction

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6380:
--

[~xtern],

Simplified reproducer:
{noformat}
public void test() throws Exception {
Ignite ignite = startGrid();

final IgniteCache cache1 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache1"));

final IgniteCache cache2 = ignite.getOrCreateCache(new 
CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache2"));

final CountDownLatch latch1 = new CountDownLatch(1);

Thread t = new Thread(new Runnable() {
@Override public void run() {
Lock lock = cache2.lock("fake");

try {
lock.lock();

System.out.println("Locked");

latch1.countDown();

Thread.sleep(1000);

cache1.clear();
}
catch (Exception e) {
e.printStackTrace();

throw new RuntimeException(e);
}
finally {
lock.unlock();
}
}
});

t.start();

try {
latch1.await();
}
catch (InterruptedException e) {
e.printStackTrace();
}

ignite.getOrCreateCache(new CacheConfiguration<>()
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setName("cache3"));

System.out.println("No deadlock");
}
{noformat}

> Exception should be thrown on cache creation attempt inside transaction
> ---
>
> Key: IGNITE-6380
> URL: https://issues.apache.org/jira/browse/IGNITE-6380
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Pavel Pereslegin
>  Labels: newbie, usability
>
> Exception should be thrown on cache creation attempt inside transaction to 
> prevent deadlocks since cache start triggers exchange and exchange cannot 
> finish until all txs are finished.
> We need to check if thread owns a tx before starting cache and if it does 
> then IllegalStateException should be thrown.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (IGNITE-6380) Exception should be thrown on cache creation attempt inside transaction

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6380:
-
Comment: was deleted

(was: Simplified reproducer:)

> Exception should be thrown on cache creation attempt inside transaction
> ---
>
> Key: IGNITE-6380
> URL: https://issues.apache.org/jira/browse/IGNITE-6380
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Pavel Pereslegin
>  Labels: newbie, usability
>
> Exception should be thrown on cache creation attempt inside transaction to 
> prevent deadlocks since cache start triggers exchange and exchange cannot 
> finish until all txs are finished.
> We need to check if thread owns a tx before starting cache and if it does 
> then IllegalStateException should be thrown.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6380) Exception should be thrown on cache creation attempt inside transaction

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6380:
--

Simplified reproducer:

> Exception should be thrown on cache creation attempt inside transaction
> ---
>
> Key: IGNITE-6380
> URL: https://issues.apache.org/jira/browse/IGNITE-6380
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Pavel Pereslegin
>  Labels: newbie, usability
>
> Exception should be thrown on cache creation attempt inside transaction to 
> prevent deadlocks since cache start triggers exchange and exchange cannot 
> finish until all txs are finished.
> We need to check if thread owns a tx before starting cache and if it does 
> then IllegalStateException should be thrown.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (IGNITE-6380) Exception should be thrown on cache creation attempt inside transaction

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6380:
-
Comment: was deleted

(was: Simplified reproducer:)

> Exception should be thrown on cache creation attempt inside transaction
> ---
>
> Key: IGNITE-6380
> URL: https://issues.apache.org/jira/browse/IGNITE-6380
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Pavel Pereslegin
>  Labels: newbie, usability
>
> Exception should be thrown on cache creation attempt inside transaction to 
> prevent deadlocks since cache start triggers exchange and exchange cannot 
> finish until all txs are finished.
> We need to check if thread owns a tx before starting cache and if it does 
> then IllegalStateException should be thrown.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6380) Exception should be thrown on cache creation attempt inside transaction

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6380:
--

Simplified reproducer:

> Exception should be thrown on cache creation attempt inside transaction
> ---
>
> Key: IGNITE-6380
> URL: https://issues.apache.org/jira/browse/IGNITE-6380
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Pavel Pereslegin
>  Labels: newbie, usability
>
> Exception should be thrown on cache creation attempt inside transaction to 
> prevent deadlocks since cache start triggers exchange and exchange cannot 
> finish until all txs are finished.
> We need to check if thread owns a tx before starting cache and if it does 
> then IllegalStateException should be thrown.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6458) Implement possibility to manually change mvcc coordinator

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-6458:


 Summary: Implement possibility to manually change mvcc coordinator
 Key: IGNITE-6458
 URL: https://issues.apache.org/jira/browse/IGNITE-6458
 Project: Ignite
  Issue Type: Sub-task
  Components: cache
Reporter: Semen Boikov


Need provide some ability to manually switch mvcc coordinator, probably via 
MBean.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6459) Implement metrics to monitor mvcc coordinator performance

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-6459:


 Summary: Implement metrics to monitor mvcc coordinator performance
 Key: IGNITE-6459
 URL: https://issues.apache.org/jira/browse/IGNITE-6459
 Project: Ignite
  Issue Type: Sub-task
Reporter: Semen Boikov


Need provide some public metrics which allow to to monitor mvcc coordinator 
performance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6250) .NET: Thin client: Basic exception handling

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6250:


Github user asfgit closed the pull request at:

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


> .NET: Thin client: Basic exception handling
> ---
>
> Key: IGNITE-6250
> URL: https://issues.apache.org/jira/browse/IGNITE-6250
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Exception handling in thin client: response includes a success flag. Define 
> exception format protocol in case of failure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-584) Need to make sure that scan query returns consistent results on topology changes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-584:
---

GitHub user zstan opened a pull request:

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

IGNITE-584: proper datastructures setDataMap fill while new node append



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

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

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

https://github.com/apache/ignite/pull/2705.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 #2705


commit eec3df4cfd80a95197006b40a728d9b83e668ce8
Author: Evgeny Stanilovskiy 
Date:   2017-09-20T13:48:20Z

IGNITE-584: proper datastructures setDataMap fill while new node append




> Need to make sure that scan query returns consistent results on topology 
> changes
> 
>
> Key: IGNITE-584
> URL: https://issues.apache.org/jira/browse/IGNITE-584
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Artem Shutak
>Assignee: Stanilovsky Evgeny
>  Labels: MakeTeamcityGreenAgain, Muted_test
>
> Consistent results on topology changes was implemented for sql queries, but 
> looks like it still does not work for scan queries.
> This affects 'cache set' tests since set uses scan query for set iteration 
> (to be unmuted on TC): 
> GridCacheSetAbstractSelfTest testNodeJoinsAndLeaves and 
> testNodeJoinsAndLeavesCollocated; 
> Also see todos here GridCacheSetFailoverAbstractSelfTest



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6250) .NET: Thin client: Basic exception handling

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6250:


TC is fine, merged to master: {{904f6a0317f47fa65b802f535fe7da63343285ff}}

> .NET: Thin client: Basic exception handling
> ---
>
> Key: IGNITE-6250
> URL: https://issues.apache.org/jira/browse/IGNITE-6250
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Exception handling in thin client: response includes a success flag. Define 
> exception format protocol in case of failure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6457) Incorrect exception when used schema name in lower case

[Ilya Suntsov (JIRA)]

Ilya Suntsov created IGNITE-6457:


 Summary: Incorrect exception when used schema name in lower case 
 Key: IGNITE-6457
 URL: https://issues.apache.org/jira/browse/IGNITE-6457
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.1
 Environment: Cache configuration:
{noformat}











{noformat}
Reporter: Ilya Suntsov
 Fix For: 2.3


Scenario:
1. Start 1 node
2. connect to node via sqlline (https://github.com/julianhyde/sqlline)
{noformat} ./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
--verbose=true --showWarnings=true --showNestedErrs=true -u 
jdbc:ignite:thin://127.0.0.1:10800/test{noformat}
3. Create table:
{noformat}CREATE TABLE city1 (id LONG PRIMARY KEY, name VARCHAR);{noformat}
Result:
{noformat}
[16:35:27,506][SEVERE][client-connector-#40%null%][JdbcRequestHandler] Failed 
to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest [schemaName=test, 
pageSize=1024, maxRows=0, sqlQry=CREATE TABLE city1 (id LONG PRIMARY KEY, name 
VARCHAR), args=[], stmtType=ANY_STATEMENT_TYPE]]
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to 
set schema for DB connection for thread [schema=test]
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:439)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForSchema(IgniteH2Indexing.java:356)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1287)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
at 
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
at 
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
at 
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
at 
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
at 
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
at 
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at 
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.h2.jdbc.JdbcSQLException: Schema "test" not found; SQL statement:
SET SCHEMA "test" [90079-195]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:179)
at org.h2.message.DbException.get(DbException.java:155)
at org.h2.engine.Database.getSchema(Database.java:1755)
at org.h2.command.dml.Set.update(Set.java:408)
at org.h2.command.CommandContainer.update(CommandContainer.java:101)
at org.h2.command.Command.executeUpdate(Command.java:260)
at 
org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137)
at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:431)
... 19 more
{noformat}

So we have incorrect exception.

Correct one appears if used the following jdbc url: 
{{jdbc:ignite:thin://127.0.0.1:10800/TEST}}







--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-584) Need to make sure that scan query returns consistent results on topology changes

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny reassigned IGNITE-584:
-

Assignee: Stanilovsky Evgeny

> Need to make sure that scan query returns consistent results on topology 
> changes
> 
>
> Key: IGNITE-584
> URL: https://issues.apache.org/jira/browse/IGNITE-584
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Artem Shutak
>Assignee: Stanilovsky Evgeny
>  Labels: MakeTeamcityGreenAgain, Muted_test
>
> Consistent results on topology changes was implemented for sql queries, but 
> looks like it still does not work for scan queries.
> This affects 'cache set' tests since set uses scan query for set iteration 
> (to be unmuted on TC): 
> GridCacheSetAbstractSelfTest testNodeJoinsAndLeaves and 
> testNodeJoinsAndLeavesCollocated; 
> Also see todos here GridCacheSetFailoverAbstractSelfTest



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6397) .NET: Thin client: basic cache operations

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6397:


Proposed method set:
{code}
bool ContainsKey(TK key);
bool ContainsKeys(IEnumerable keys);
bool TryGet(TK key, out TV value);
ICollection> GetAll(IEnumerable keys);
CacheResult GetAndPut(TK key, TV val);
CacheResult GetAndReplace(TK key, TV val);
CacheResult GetAndRemove(TK key);
bool PutIfAbsent(TK key, TV val);
CacheResult GetAndPutIfAbsent(TK key, TV val);
bool Replace(TK key, TV val);
bool Replace(TK key, TV oldVal, TV newVal);
void PutAll(IEnumerable> vals);
void Clear();
void Clear(TK key);
void ClearAll(IEnumerable keys);
bool Remove(TK key);
bool Remove(TK key, TV val);
void RemoveAll(IEnumerable keys);
void RemoveAll();
int GetSize(params CachePeekMode[] modes);

{code}

> .NET: Thin client: basic cache operations
> -
>
> Key: IGNITE-6397
> URL: https://issues.apache.org/jira/browse/IGNITE-6397
> Project: Ignite
>  Issue Type: Bug
>  Components: clients, platforms
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> We need to implement base cache operations, such as "remove", "replace", 
> "putIfAbsent". 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6454) Data structure suite timeout: test is not able to fail after interruption

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6454:


GitHub user dspavlov opened a pull request:

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

IGNITE-6454: suite timeout replace to failure

Interrupted flag check was added

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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-6454-interrupt-fix

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

https://github.com/apache/ignite/pull/2704.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 #2704


commit cfe3240a7933894dc3e048d954de524a9061128e
Author: dpavlov 
Date:   2017-09-20T13:07:11Z

IGNITE-6454: suite timeout replace to failure: interrupted flag check was 
added




> Data structure suite timeout: test is not able to fail after interruption
> -
>
> Key: IGNITE-6454
> URL: https://issues.apache.org/jira/browse/IGNITE-6454
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
> Attachments: 
> lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip,
>  
> lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip
>
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataStrucutures=%3Cdefault%3E=buildTypeStatusDiv
> Most often timeout is caused by following tests:
> GridCacheReplicatedDataStructuresFailoverSelfTest
> - testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> - testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> And most of thread dumps contains the following
> {noformat}
> ] :[Step 4/5] Thread 
> [name="test-runner-#35143%replicated.GridCacheReplicatedDataStructuresFailoverSelfTest%",
>  id=38586, state=RUNNABLE, blockCnt=0, waitCnt=60]
> [20:34:26] :   [Step 4/5] at 
> java.lang.Throwable.fillInStackTrace(Native Method)
> [20:34:26] :   [Step 4/5] at 
> java.lang.Throwable.fillInStackTrace(Throwable.java:783)
> [20:34:26] :   [Step 4/5] - locked o.a.i.IgniteException@754033e
> [20:34:26] :   [Step 4/5] at 
> java.lang.Throwable.(Throwable.java:265)
> [20:34:26] :   [Step 4/5] at 
> java.lang.Exception.(Exception.java:66)
> [20:34:26] :   [Step 4/5] at 
> java.lang.RuntimeException.(RuntimeException.java:62)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.IgniteException.(IgniteException.java:44)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.validate(GridCacheLockImpl.java:275)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.access$1000(GridCacheLockImpl.java:122)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1200)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.doTestReentrantLock(GridCacheAbstractDataStructuresFailoverSelfTest.java:785)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:739)
> [20:34:26] :   [Step 4/5] at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [20:34:26] :   [Step 4/5] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [20:34:26] :   [Step 4/5] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [20:34:26] :   [Step 4/5] at 
> java.lang.reflect.Method.invoke(Method.java:606)
> [20:34:26] :   [Step 4/5] at 
> junit.framework.TestCase.runTest(TestCase.java:176)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> [20:34:26] :   [Step 4/5] at java.lang.Thread.run(Thread.java:745)
> 

[jira] [Commented] (IGNITE-6250) .NET: Thin client: Basic exception handling

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6250:


1) Ok
2) Removed

> .NET: Thin client: Basic exception handling
> ---
>
> Key: IGNITE-6250
> URL: https://issues.apache.org/jira/browse/IGNITE-6250
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Exception handling in thin client: response includes a success flag. Define 
> exception format protocol in case of failure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6454) Data structure suite timeout: test is not able to fail after interruption

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-6454:
---
Description: 
https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataStrucutures=%3Cdefault%3E=buildTypeStatusDiv

Most often timeout is caused by following tests:
GridCacheReplicatedDataStructuresFailoverSelfTest
- testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
- testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()

And most of thread dumps contains the following
{noformat}
] :  [Step 4/5] Thread 
[name="test-runner-#35143%replicated.GridCacheReplicatedDataStructuresFailoverSelfTest%",
 id=38586, state=RUNNABLE, blockCnt=0, waitCnt=60]
[20:34:26] : [Step 4/5] at 
java.lang.Throwable.fillInStackTrace(Native Method)
[20:34:26] : [Step 4/5] at 
java.lang.Throwable.fillInStackTrace(Throwable.java:783)
[20:34:26] : [Step 4/5] - locked o.a.i.IgniteException@754033e
[20:34:26] : [Step 4/5] at 
java.lang.Throwable.(Throwable.java:265)
[20:34:26] : [Step 4/5] at 
java.lang.Exception.(Exception.java:66)
[20:34:26] : [Step 4/5] at 
java.lang.RuntimeException.(RuntimeException.java:62)
[20:34:26] : [Step 4/5] at 
o.a.i.IgniteException.(IgniteException.java:44)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.validate(GridCacheLockImpl.java:275)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.access$1000(GridCacheLockImpl.java:122)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1200)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.doTestReentrantLock(GridCacheAbstractDataStructuresFailoverSelfTest.java:785)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:739)
[20:34:26] : [Step 4/5] at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[20:34:26] : [Step 4/5] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[20:34:26] : [Step 4/5] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[20:34:26] : [Step 4/5] at 
java.lang.reflect.Method.invoke(Method.java:606)
[20:34:26] : [Step 4/5] at 
junit.framework.TestCase.runTest(TestCase.java:176)
[20:34:26] : [Step 4/5] at 
o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
[20:34:26] : [Step 4/5] at 
o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
[20:34:26] : [Step 4/5] at 
o.a.i.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
[20:34:26] : [Step 4/5] at java.lang.Thread.run(Thread.java:745)
[20:34:26] : [Step 4/5] 
{noformat}

That can be indicator that threads are interrupted and flag 
org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl#interruptAll
 is set,
than org.apache.ignite.IgniteException is thrown, but it is ignored by test and 
test continues to execute

  was:
https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataStrucutures=%3Cdefault%3E=buildTypeStatusDiv

Most often timeout is caused by following tests:
GridCacheReplicatedDataStructuresFailoverSelfTest
- testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
-testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()

And most of thread dumps contains the following
{noformat}
] :  [Step 4/5] Thread 
[name="test-runner-#35143%replicated.GridCacheReplicatedDataStructuresFailoverSelfTest%",
 id=38586, state=RUNNABLE, blockCnt=0, waitCnt=60]
[20:34:26] : [Step 4/5] at 
java.lang.Throwable.fillInStackTrace(Native Method)
[20:34:26] : [Step 4/5] at 
java.lang.Throwable.fillInStackTrace(Throwable.java:783)
[20:34:26] : [Step 4/5] - locked o.a.i.IgniteException@754033e
[20:34:26] : [Step 4/5] at 
java.lang.Throwable.(Throwable.java:265)
[20:34:26] : [Step 4/5] at 
java.lang.Exception.(Exception.java:66)
[20:34:26] : [Step 4/5] at 
java.lang.RuntimeException.(RuntimeException.java:62)
[20:34:26] : [Step 4/5] at 
o.a.i.IgniteException.(IgniteException.java:44)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.validate(GridCacheLockImpl.java:275)
[20:34:26] : [Step 4/5] at 

[jira] [Commented] (IGNITE-6250) .NET: Thin client: Basic exception handling

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6250:
-

[~ptupitsyn], my comment:
1) I did some cosmetical changes, please review (in particular - changed one 
error message)
2) {{ClientStatus.ParsingFailed}} - still there. Is it ok?

> .NET: Thin client: Basic exception handling
> ---
>
> Key: IGNITE-6250
> URL: https://issues.apache.org/jira/browse/IGNITE-6250
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Exception handling in thin client: response includes a success flag. Define 
> exception format protocol in case of failure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6455) Add flags to ClientConnectorConfiguration which enable/disable different clients

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6455:

Fix Version/s: (was: 2.3)

> Add flags to ClientConnectorConfiguration which enable/disable different 
> clients
> 
>
> Key: IGNITE-6455
> URL: https://issues.apache.org/jira/browse/IGNITE-6455
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
>
> There is currently no way to disable only one client. For example, currently 
> you can't disallow thin JDBC driver connectivity alone, you can only disable 
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and 
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the 
> {{ClientListenerProcessor}} separately. For example, we can add flags to the 
> {{SqlConnectorConfiguration}}:
> {{enableJdbc}}
> {{enableOdbc}}
> {{enableThinClients}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-6455) Add flags to ClientConnectorConfiguration which enable/disable different clients

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-6455.
-
Resolution: Duplicate

> Add flags to ClientConnectorConfiguration which enable/disable different 
> clients
> 
>
> Key: IGNITE-6455
> URL: https://issues.apache.org/jira/browse/IGNITE-6455
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
> Fix For: 2.3
>
>
> There is currently no way to disable only one client. For example, currently 
> you can't disallow thin JDBC driver connectivity alone, you can only disable 
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and 
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the 
> {{ClientListenerProcessor}} separately. For example, we can add flags to the 
> {{SqlConnectorConfiguration}}:
> {{enableJdbc}}
> {{enableOdbc}}
> {{enableThinClients}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-6455) Add flags to ClientConnectorConfiguration which enable/disable different clients

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-6455.
---

> Add flags to ClientConnectorConfiguration which enable/disable different 
> clients
> 
>
> Key: IGNITE-6455
> URL: https://issues.apache.org/jira/browse/IGNITE-6455
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
> Fix For: 2.3
>
>
> There is currently no way to disable only one client. For example, currently 
> you can't disallow thin JDBC driver connectivity alone, you can only disable 
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and 
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the 
> {{ClientListenerProcessor}} separately. For example, we can add flags to the 
> {{SqlConnectorConfiguration}}:
> {{enableJdbc}}
> {{enableOdbc}}
> {{enableThinClients}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6456) Add flags to ClientConnectorConfiguration which enable/disable different clients

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6456:

Labels: usability  (was: )

> Add flags to ClientConnectorConfiguration which enable/disable different 
> clients
> 
>
> Key: IGNITE-6456
> URL: https://issues.apache.org/jira/browse/IGNITE-6456
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
>  Labels: usability
> Fix For: 2.3
>
>
> There is currently no way to disable only one client. For example, currently 
> you can't disallow thin JDBC driver connectivity alone, you can only disable 
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and 
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the 
> {{ClientListenerProcessor}} separately. For example, we can add flags to the 
> {{SqlConnectorConfiguration}}:
> {{enableJdbc}}
> {{enableOdbc}}
> {{enableThinClients}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6250) .NET: Thin client: Basic exception handling

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6250:


1) Fixed
2) If you mean handshake error handling, see {{ClientSocket.Handshake}}
3) Fixed
4) Handshake failure is handled by {{ClientListenerNioListener.onHandshake}} 
for all client types, there is a boolean flag, not an error code. Not sure if 
we should change this.

> .NET: Thin client: Basic exception handling
> ---
>
> Key: IGNITE-6250
> URL: https://issues.apache.org/jira/browse/IGNITE-6250
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Exception handling in thin client: response includes a success flag. Define 
> exception format protocol in case of failure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6456) Add flags to ClientConnectorConfiguration which enable/disable different clients

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-6456:
---

 Summary: Add flags to ClientConnectorConfiguration which 
enable/disable different clients
 Key: IGNITE-6456
 URL: https://issues.apache.org/jira/browse/IGNITE-6456
 Project: Ignite
  Issue Type: Improvement
  Components: jdbc, odbc, thin client
Affects Versions: 2.1
Reporter: Igor Sapego
 Fix For: 2.3


There is currently no way to disable only one client. For example, currently 
you can't disallow thin JDBC driver connectivity alone, you can only disable 
the whole {{ClientListenerProcessor}}, which is going to disable ODBC and thin 
.NET clients as well.

We should add options to disable/enable every single client, supported by the 
{{ClientListenerProcessor}} separately. For example, we can add flags to the 
{{SqlConnectorConfiguration}}:
{{enableJdbc}}
{{enableOdbc}}
{{enableThinClients}}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6455) Add flags to ClientConnectorConfiguration which enable/disable different clients

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-6455:
---

 Summary: Add flags to ClientConnectorConfiguration which 
enable/disable different clients
 Key: IGNITE-6455
 URL: https://issues.apache.org/jira/browse/IGNITE-6455
 Project: Ignite
  Issue Type: Improvement
  Components: jdbc, odbc, thin client
Affects Versions: 2.1
Reporter: Igor Sapego
 Fix For: 2.3


There is currently no way to disable only one client. For example, currently 
you can't disallow thin JDBC driver connectivity alone, you can only disable 
the whole {{ClientListenerProcessor}}, which is going to disable ODBC and thin 
.NET clients as well.

We should add options to disable/enable every single client, supported by the 
{{ClientListenerProcessor}} separately. For example, we can add flags to the 
{{SqlConnectorConfiguration}}:
{{enableJdbc}}
{{enableOdbc}}
{{enableThinClients}}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6316) SQL: Add ALTER TABLE tests with persistence

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6316:
-

[~agoncharuk], [~al.psc], thanks! Makes sense to me - we need to add these two 
tests before patch is accepted.

> SQL: Add ALTER TABLE tests with persistence
> ---
>
> Key: IGNITE-6316
> URL: https://issues.apache.org/jira/browse/IGNITE-6316
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
>
> Scenario:
> 1) Start a node with persistence and pre-configured cache and {{QueryEntity}}
> 2) Add a column through {{ALTER TABLE}}
> 3) Restart the node
> 4) Make sure that new column is still there



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6448) Select * doesn't return new field name after concurrent ALTER TABLE

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-6448:
--

Waits for [tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2702%2Fhead].

> Select * doesn't return new field name after concurrent ALTER TABLE 
> 
>
> Key: IGNITE-6448
> URL: https://issues.apache.org/jira/browse/IGNITE-6448
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.3
>
>
> Steps for reproduce:
> 1. Start 3 nodes
> 2. Execute 
> {noformat}CREATE TABLE person (id LONG, name VARCHAR, city_id LONG, PRIMARY 
> KEY (id, city_id)) {noformat}
> to create table Person
> 3. Connect to grid via sqlline (https://github.com/julianhyde/sqlline)
> {noformat}./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
> --verbose=true --showWarnings=true --showNestedErrs=true -u 
> jdbc:ignite:thin://127.0.0.1/{noformat}
> 4. Create one more connection {noformat}!connect 
> jdbc:ignite:thin://127.0.0.1/ {noformat}
> 5. Execute ALTER TABLE for both connections {noformat} !all alter table 
> person add field1 varchar;{noformat}
> Result:
> 1. Got exception on coordinator:
> {noformat}[10:59:15,805][SEVERE][client-connector-#55%null%][JdbcRequestHandler]
>  Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest 
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=alter table person add 
> field1 varchar, args=[], stmtType=ANY_STATEMENT_TYPE]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Column 
> already exists: FIELD1
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:329)
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:273)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1383)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
>   at 
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at 
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> 2. When I try to get all data from Person:
> {noformat}select * from person;{noformat}
> I get the table without new field but if try to get only this field from 
> table it works.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6448) Select * doesn't return new field name after concurrent ALTER TABLE

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6448:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-6448: clear query cache on ALTER TABLE ADD 



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

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

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

https://github.com/apache/ignite/pull/2702.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 #2702


commit 7720f091237acba3f43e456c25f4c73d52bb626e
Author: tledkov-gridgain 
Date:   2017-09-20T10:07:46Z

IGNITE-6448: add test

commit 652fa795095ca195a500b5aaef341eb9509c081f
Author: Alexander Paschenko 
Date:   2017-09-20T11:49:47Z

Metadata update fix

commit 26a1ecb98201263ce97f4c88535150938683129f
Author: tledkov-gridgain 
Date:   2017-09-20T12:17:21Z

IGNITE-6448: clear cached queries on add columns to table

commit 47de93df1b7b4e9b7e1953a9ce3f1aa77abf909e
Author: tledkov-gridgain 
Date:   2017-09-20T12:18:22Z

IGNITE-6448: add test to suite




> Select * doesn't return new field name after concurrent ALTER TABLE 
> 
>
> Key: IGNITE-6448
> URL: https://issues.apache.org/jira/browse/IGNITE-6448
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.3
>
>
> Steps for reproduce:
> 1. Start 3 nodes
> 2. Execute 
> {noformat}CREATE TABLE person (id LONG, name VARCHAR, city_id LONG, PRIMARY 
> KEY (id, city_id)) {noformat}
> to create table Person
> 3. Connect to grid via sqlline (https://github.com/julianhyde/sqlline)
> {noformat}./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
> --verbose=true --showWarnings=true --showNestedErrs=true -u 
> jdbc:ignite:thin://127.0.0.1/{noformat}
> 4. Create one more connection {noformat}!connect 
> jdbc:ignite:thin://127.0.0.1/ {noformat}
> 5. Execute ALTER TABLE for both connections {noformat} !all alter table 
> person add field1 varchar;{noformat}
> Result:
> 1. Got exception on coordinator:
> {noformat}[10:59:15,805][SEVERE][client-connector-#55%null%][JdbcRequestHandler]
>  Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest 
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=alter table person add 
> field1 varchar, args=[], stmtType=ANY_STATEMENT_TYPE]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Column 
> already exists: FIELD1
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:329)
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:273)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1383)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
>   at 
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
>   at 
> 

[jira] [Issue Comment Deleted] (IGNITE-6250) .NET: Thin client: Basic exception handling

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6250:
---
Comment: was deleted

(was: 1) Closing connection is bad usability. How are you going to know what 
went wrong? I think we should provide a response when possible. See how web 
servers work.
2) Neither do I. Where do you think we need it in that file?
3,4) Fixed)

> .NET: Thin client: Basic exception handling
> ---
>
> Key: IGNITE-6250
> URL: https://issues.apache.org/jira/browse/IGNITE-6250
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Exception handling in thin client: response includes a success flag. Define 
> exception format protocol in case of failure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6449) Visor CMD: Show missed cache properties

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6449:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Looks good. Merged to master. Please retest.

> Visor CMD: Show missed cache properties
> ---
>
> Key: IGNITE-6449
> URL: https://issues.apache.org/jira/browse/IGNITE-6449
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6435) Web Console: Add release version to footer

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6435:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Looks good. Merged to master. Please retest.

> Web Console: Add release version to footer
> --
>
> Key: IGNITE-6435
> URL: https://issues.apache.org/jira/browse/IGNITE-6435
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6445) IgniteTxManager.txLocksInfo method misses locks

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6445:
-
Description: 
In some cases "IgniteTxManager.txLocksInfo" method (searches for locks) misses 
locks.
For example:
# In case of a configuration with near cache, entries are created in the near 
cache and in the ordinal cache. For each entry, their own MVCC candidates are 
created.
# For non-custom objects of type (Integer, etc.), the entry stored in 
"GridNearTxLocal" is not associated with MVCC candidates with which the same 
entity is associated in another format stored in "GridDhtTxLocal"

  was:
In some cases "IgniteTxManager.txLocksInfo" method (searches for locks) misses 
locks.
For example:
# In case of a configuration with near cache, entries are created in the near 
cache and for the ordinal cache. For each entry, their own MVCC candidates are 
created.
# For non-custom objects of type (Integer, etc.), the entry stored in 
"GridNearTxLocal" is not associated with MVCC candidates with which the same 
entity is associated in another format stored in "GridDhtTxLocal"


> IgniteTxManager.txLocksInfo method misses locks
> ---
>
> Key: IGNITE-6445
> URL: https://issues.apache.org/jira/browse/IGNITE-6445
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>
> In some cases "IgniteTxManager.txLocksInfo" method (searches for locks) 
> misses locks.
> For example:
> # In case of a configuration with near cache, entries are created in the near 
> cache and in the ordinal cache. For each entry, their own MVCC candidates are 
> created.
> # For non-custom objects of type (Integer, etc.), the entry stored in 
> "GridNearTxLocal" is not associated with MVCC candidates with which the same 
> entity is associated in another format stored in "GridDhtTxLocal"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6445) IgniteTxManager.txLocksInfo method misses locks

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6445:
-
Description: 
In some cases "IgniteTxManager.txLocksInfo" method (searches for locks) misses 
locks.
For example:
# In case of a configuration with near cache, entries are created for the near 
cache and for the ordinal cache. For each entry, their own MVCC candidates are 
created.
# For non-custom objects of type (Integer, etc.), the entry stored in 
"GridNearTxLocal" is not associated with MVCC candidates with which the same 
entity is associated in another format stored in "GridDhtTxLocal"

  was:
In some cases "IgniteTxManager.txLocksInfo" method (searches for locks) misses 
locks.
For example:
# In case of a configuration with near cache, entries are created in the near 
cache and in the ordinal cache. For each entry, their own MVCC candidates are 
created.
# For non-custom objects of type (Integer, etc.), the entry stored in 
"GridNearTxLocal" is not associated with MVCC candidates with which the same 
entity is associated in another format stored in "GridDhtTxLocal"


> IgniteTxManager.txLocksInfo method misses locks
> ---
>
> Key: IGNITE-6445
> URL: https://issues.apache.org/jira/browse/IGNITE-6445
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>
> In some cases "IgniteTxManager.txLocksInfo" method (searches for locks) 
> misses locks.
> For example:
> # In case of a configuration with near cache, entries are created for the 
> near cache and for the ordinal cache. For each entry, their own MVCC 
> candidates are created.
> # For non-custom objects of type (Integer, etc.), the entry stored in 
> "GridNearTxLocal" is not associated with MVCC candidates with which the same 
> entity is associated in another format stored in "GridDhtTxLocal"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6445) IgniteTxManager.txLocksInfo method misses locks

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6445:
-
Description: 
In some cases "IgniteTxManager.txLocksInfo" method (searches for locks) misses 
locks.
For example:
# In case of a configuration with near cache, entries are created in the near 
cache and for the ordinal cache. For each entry, their own MVCC candidates are 
created.
# For non-custom objects of type (Integer, etc.), the entry stored in 
"GridNearTxLocal" is not associated with MVCC candidates with which the same 
entity is associated in another format stored in "GridDhtTxLocal"

  was:
In some cases "IgniteTxManager.txLocksInfo" method (searches for locks) misses 
locks.
For example:
# In case of a configuration with near cache, entities are created for the near 
cache and for the ordinal cache. For each entry, their own MVCC candidates are 
created.
# For non-custom objects of type (Integer, etc.), the entry stored in 
"GridNearTxLocal" is not associated with MVCC candidates with which the same 
entity is associated in another format stored in "GridDhtTxLocal"


> IgniteTxManager.txLocksInfo method misses locks
> ---
>
> Key: IGNITE-6445
> URL: https://issues.apache.org/jira/browse/IGNITE-6445
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>
> In some cases "IgniteTxManager.txLocksInfo" method (searches for locks) 
> misses locks.
> For example:
> # In case of a configuration with near cache, entries are created in the near 
> cache and for the ordinal cache. For each entry, their own MVCC candidates 
> are created.
> # For non-custom objects of type (Integer, etc.), the entry stored in 
> "GridNearTxLocal" is not associated with MVCC candidates with which the same 
> entity is associated in another format stored in "GridDhtTxLocal"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6316) SQL: Add ALTER TABLE tests with persistence

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-6316:
--

As the original test was broken, we need to make sure the following cases are 
covered:
1) A node is restarted, but the cluster lives. In this case, the locally stored 
configuration should be overridded by the cluster configuration
2) The configuration is altered, then the cluster is restarted. In this case, 
the configuration should be loaded from disk.

Otherwise looks good

> SQL: Add ALTER TABLE tests with persistence
> ---
>
> Key: IGNITE-6316
> URL: https://issues.apache.org/jira/browse/IGNITE-6316
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
>
> Scenario:
> 1) Start a node with persistence and pre-configured cache and {{QueryEntity}}
> 2) Add a column through {{ALTER TABLE}}
> 3) Restart the node
> 4) Make sure that new column is still there



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6448) Select * doesn't return new field name after concurrent ALTER TABLE

[Taras Ledkov (JIRA)]

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

Taras Ledkov reassigned IGNITE-6448:


Assignee: Taras Ledkov  (was: Alexander Paschenko)

> Select * doesn't return new field name after concurrent ALTER TABLE 
> 
>
> Key: IGNITE-6448
> URL: https://issues.apache.org/jira/browse/IGNITE-6448
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.3
>
>
> Steps for reproduce:
> 1. Start 3 nodes
> 2. Execute 
> {noformat}CREATE TABLE person (id LONG, name VARCHAR, city_id LONG, PRIMARY 
> KEY (id, city_id)) {noformat}
> to create table Person
> 3. Connect to grid via sqlline (https://github.com/julianhyde/sqlline)
> {noformat}./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
> --verbose=true --showWarnings=true --showNestedErrs=true -u 
> jdbc:ignite:thin://127.0.0.1/{noformat}
> 4. Create one more connection {noformat}!connect 
> jdbc:ignite:thin://127.0.0.1/ {noformat}
> 5. Execute ALTER TABLE for both connections {noformat} !all alter table 
> person add field1 varchar;{noformat}
> Result:
> 1. Got exception on coordinator:
> {noformat}[10:59:15,805][SEVERE][client-connector-#55%null%][JdbcRequestHandler]
>  Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest 
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=alter table person add 
> field1 varchar, args=[], stmtType=ANY_STATEMENT_TYPE]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Column 
> already exists: FIELD1
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:329)
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:273)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1383)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
>   at 
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at 
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> 2. When I try to get all data from Person:
> {noformat}select * from person;{noformat}
> I get the table without new field but if try to get only this field from 
> table it works.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6442) Deadlock detection doesn't execute.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov edited comment on IGNITE-6442 at 9/20/17 11:46 AM:


Hi, [~agura].  Please, review this issue. 
[Upsourse|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-346]

I've reproduced the case in which DD is not called and fixed bug. My test 
method checks only that DD was called, but does not verify that it worked 
correctly. Because in this case DD works flaky. I'll fix it at 
[IGNITE-6445|https://issues.apache.org/jira/browse/IGNITE-6445] and add 
correctness check to my test method.

[TC 
run|https://ci.ignite.apache.org/viewLog.html?buildId=840419=buildResultsDiv=Ignite20Tests_RunAll]


was (Author: vitaliyb):
Hi, [~agura].  Please, review this issue. 
[Upsourse|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-346]

I've reproduced the case in which DD is not called and fixed bug. My test 
method checks only that DD was called, but does not verify that it worked 
correctly. Because in this case DD works flaky. I'll fix it at 
[IGNITE-6445|https://issues.apache.org/jira/browse/IGNITE-6445] and add 
correctness check to my test method.

> Deadlock detection doesn't execute.
> ---
>
> Key: IGNITE-6442
> URL: https://issues.apache.org/jira/browse/IGNITE-6442
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>
> In case of a configuration with near cache and if all entities of one of the 
> transactions involved in the deadlock are on the node being the initiator of 
> this transaction, then immediately after the timeout, the transaction rolls 
> back (without calling DD).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6250) .NET: Thin client: Basic exception handling

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6250:


1) Closing connection is bad usability. How are you going to know what went 
wrong? I think we should provide a response when possible. See how web servers 
work.
2) Neither do I. Where do you think we need it in that file?
3,4) Fixed

> .NET: Thin client: Basic exception handling
> ---
>
> Key: IGNITE-6250
> URL: https://issues.apache.org/jira/browse/IGNITE-6250
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Exception handling in thin client: response includes a success flag. Define 
> exception format protocol in case of failure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6095) Web console: In demo mode Implement configuration of key fields in domain model for SQL query

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6095:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Looks good. Merged to master. Please retest.

> Web console: In demo mode Implement configuration of key fields in domain 
> model for SQL query
> -
>
> Key: IGNITE-6095
> URL: https://issues.apache.org/jira/browse/IGNITE-6095
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6422) In visorcmd "cache on nodes" statistics mixes together primary and backup entries

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-6422:
-
Fix Version/s: 2.3

> In visorcmd "cache on nodes" statistics mixes together primary and backup 
> entries
> -
>
> Key: IGNITE-6422
> URL: https://issues.apache.org/jira/browse/IGNITE-6422
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Vasiliy Sisko
> Fix For: 2.3
>
>
> Suppose we have a cache, with 1000 entries, one backup and eviction after 500 
> entries. Then, off-heap entries are doubled in visorcmd, while on-heap 
> entries are not:
> {code}
> +-+
> | Name(@) | EmployeesCache(@c0)   |
> | Nodes   | 2 |
> | Total size Min/Avg/Max  | 1500 / 1500.00 / 1500 |
> |   Heap size Min/Avg/Max | 500 / 500.00 / 500|
> |   Off-heap size Min/Avg/Max | 1000 / 1000.00 / 1000 |
> +-+
> Nodes for: EmployeesCache(@c0)
> +=+
> |  Node ID8(@), IP  | CPUs | Heap Used | CPU Load |   Up Time|
>  Size | Hi/Mi/Rd/Wr |
> +=+
> | 37333BC6(@n0), 172.16.9.1 | 8| 4.47 %| 0.40 %   | 00:00:47:154 | 
> Total: 1500  | Hi: 0   |
> |   |  |   |  |  |   
> Heap: 500  | Mi: 0   |
> |   |  |   |  |  |   
> Off-Heap: 1000 | Rd: 0   |
> |   |  |   |  |  |   
> Off-Heap Memory: 0 | Wr: 0   |
> +---+--+---+--+--+--+-+
> | 26FD4343(@n1), 172.16.9.1 | 8| 3.09 %| 0.23 %   | 00:00:41:602 | 
> Total: 1500  | Hi: 0   |
> |   |  |   |  |  |   
> Heap: 500  | Mi: 0   |
> |   |  |   |  |  |   
> Off-Heap: 1000 | Rd: 0   |
> |   |  |   |  |  |   
> Off-Heap Memory: 0 | Wr: 0   |
> +-+
> 'Hi' - Number of cache hits.
> {code}
> By contrast, on 1.9 it looks like this:
> {code}
> Cache 'EmployeesCache(@c0)':
> +-+
> | Name(@) | EmployeesCache(@c0)   |
> | Nodes   | 2 |
> | Total size Min/Avg/Max  | 1000 / 1000.00 / 1000 |
> |   Heap size Min/Avg/Max | 500 / 500.00 / 500|
> |   Off-heap size Min/Avg/Max | 500 / 500.00 / 500|
> +-+
> Nodes for: EmployeesCache(@c0)
> ++
> |  Node ID8(@), IP  | CPUs | Heap Used | CPU Load |   Up Time|
>   Size   | Hi/Mi/Rd/Wr |
> ++
> | 3229FABE(@n0), 172.16.9.1 | 8| 1.25 %| 0.23 %   | 00:00:43:111 | 
> Total: 1000 | Hi: 0   |
> |   |  |   |  |  |   
> Heap: 500 | Mi: 0   |
> |   |  |   |  |  |   
> Off-Heap: 500 | Rd: 0   |
> |   |  |   |  |  |   
> Off-Heap Memory: 88kb | Wr: 0   |
> +---+--+---+--+--+-+-+
> | 58FA742B(@n1), 172.16.9.1 | 8| 1.15 %| 0.47 %   | 00:00:38:828 | 
> Total: 1000 | Hi: 0   |
> |   |  |   |  |  |   
> Heap: 500 | Mi: 0   |
> |   |  |   |  |  |   
> Off-Heap: 500 | Rd: 0   |
> |   |  |   |  |  |   
> Off-Heap Memory: 88kb | Wr: 0   |
> ++
> {code}
> NB: It might be 

[jira] [Commented] (IGNITE-6226) Review docs for integration with Apache Zeppelin

[Ilya Suntsov (JIRA)]

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

Ilya Suntsov commented on IGNITE-6226:
--

[~dmagda] I correct some inaccuracies (submit editions form) so now this 
[page|https://apacheignite.readme.io/v1.1/docs/data-analysis-with-apache-zeppelin?edits=true]
 up to date

> Review docs for integration with Apache Zeppelin
> 
>
> Key: IGNITE-6226
> URL: https://issues.apache.org/jira/browse/IGNITE-6226
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Assignee: Ilya Suntsov
> Fix For: 2.3
>
>
> Now we have non actual documentation for Apache Zeppelin integration: 
> https://apacheignite.readme.io/v1.1/docs/data-analysis-with-apache-zeppelin?edits=true



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6435) Web Console: Add release version to footer

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-6435:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Web Console: Add release version to footer
> --
>
> Key: IGNITE-6435
> URL: https://issues.apache.org/jira/browse/IGNITE-6435
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6435) Web Console: Add release version to footer

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-6435:


Tested

> Web Console: Add release version to footer
> --
>
> Key: IGNITE-6435
> URL: https://issues.apache.org/jira/browse/IGNITE-6435
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6454) Data structure suite timeout: test is not able to fail after interruption

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov reassigned IGNITE-6454:
--

Assignee: Dmitriy Pavlov

> Data structure suite timeout: test is not able to fail after interruption
> -
>
> Key: IGNITE-6454
> URL: https://issues.apache.org/jira/browse/IGNITE-6454
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
> Attachments: 
> lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip,
>  
> lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip
>
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataStrucutures=%3Cdefault%3E=buildTypeStatusDiv
> Most often timeout is caused by following tests:
> GridCacheReplicatedDataStructuresFailoverSelfTest
> - testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> -testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> And most of thread dumps contains the following
> {noformat}
> ] :[Step 4/5] Thread 
> [name="test-runner-#35143%replicated.GridCacheReplicatedDataStructuresFailoverSelfTest%",
>  id=38586, state=RUNNABLE, blockCnt=0, waitCnt=60]
> [20:34:26] :   [Step 4/5] at 
> java.lang.Throwable.fillInStackTrace(Native Method)
> [20:34:26] :   [Step 4/5] at 
> java.lang.Throwable.fillInStackTrace(Throwable.java:783)
> [20:34:26] :   [Step 4/5] - locked o.a.i.IgniteException@754033e
> [20:34:26] :   [Step 4/5] at 
> java.lang.Throwable.(Throwable.java:265)
> [20:34:26] :   [Step 4/5] at 
> java.lang.Exception.(Exception.java:66)
> [20:34:26] :   [Step 4/5] at 
> java.lang.RuntimeException.(RuntimeException.java:62)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.IgniteException.(IgniteException.java:44)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.validate(GridCacheLockImpl.java:275)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.access$1000(GridCacheLockImpl.java:122)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1200)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.doTestReentrantLock(GridCacheAbstractDataStructuresFailoverSelfTest.java:785)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:739)
> [20:34:26] :   [Step 4/5] at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [20:34:26] :   [Step 4/5] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [20:34:26] :   [Step 4/5] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [20:34:26] :   [Step 4/5] at 
> java.lang.reflect.Method.invoke(Method.java:606)
> [20:34:26] :   [Step 4/5] at 
> junit.framework.TestCase.runTest(TestCase.java:176)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> [20:34:26] :   [Step 4/5] at java.lang.Thread.run(Thread.java:745)
> [20:34:26] :   [Step 4/5] 
> {noformat}
> That can be indicator that threads are interrupted and flag 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl#interruptAll
>  is set,
> than org.apache.ignite.IgniteException is thrown, but it is ignored by test 
> and test continues to execute



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6397) .NET: Thin client: basic cache operations

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6397:
---
Labels: .NET  (was: )

> .NET: Thin client: basic cache operations
> -
>
> Key: IGNITE-6397
> URL: https://issues.apache.org/jira/browse/IGNITE-6397
> Project: Ignite
>  Issue Type: Bug
>  Components: clients, platforms
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> We need to implement base cache operations, such as "remove", "replace", 
> "putIfAbsent". 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6316) SQL: Add ALTER TABLE tests with persistence

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6316:
-

[~agoncharuk], could you please take a look?

> SQL: Add ALTER TABLE tests with persistence
> ---
>
> Key: IGNITE-6316
> URL: https://issues.apache.org/jira/browse/IGNITE-6316
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
>
> Scenario:
> 1) Start a node with persistence and pre-configured cache and {{QueryEntity}}
> 2) Add a column through {{ALTER TABLE}}
> 3) Restart the node
> 4) Make sure that new column is still there



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6397) .NET: Thin client: basic cache operations

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6397:
---
Summary: .NET: Thin client: basic cache operations  (was: .NET thin client: 
implement base cache operations)

> .NET: Thin client: basic cache operations
> -
>
> Key: IGNITE-6397
> URL: https://issues.apache.org/jira/browse/IGNITE-6397
> Project: Ignite
>  Issue Type: Bug
>  Components: clients, platforms
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> We need to implement base cache operations, such as "remove", "replace", 
> "putIfAbsent". 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6454) Data structure suite timeout: test is not able to fail after interruption

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-6454:
---
Attachment: 
lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip

lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip

> Data structure suite timeout: test is not able to fail after interruption
> -
>
> Key: IGNITE-6454
> URL: https://issues.apache.org/jira/browse/IGNITE-6454
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
> Attachments: 
> lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip,
>  
> lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip
>
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataStrucutures=%3Cdefault%3E=buildTypeStatusDiv
> Most often timeout is caused by following tests:
> GridCacheReplicatedDataStructuresFailoverSelfTest
> - testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> -testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> And most of thread dumps contains the following
> {noformat}
> ] :[Step 4/5] Thread 
> [name="test-runner-#35143%replicated.GridCacheReplicatedDataStructuresFailoverSelfTest%",
>  id=38586, state=RUNNABLE, blockCnt=0, waitCnt=60]
> [20:34:26] :   [Step 4/5] at 
> java.lang.Throwable.fillInStackTrace(Native Method)
> [20:34:26] :   [Step 4/5] at 
> java.lang.Throwable.fillInStackTrace(Throwable.java:783)
> [20:34:26] :   [Step 4/5] - locked o.a.i.IgniteException@754033e
> [20:34:26] :   [Step 4/5] at 
> java.lang.Throwable.(Throwable.java:265)
> [20:34:26] :   [Step 4/5] at 
> java.lang.Exception.(Exception.java:66)
> [20:34:26] :   [Step 4/5] at 
> java.lang.RuntimeException.(RuntimeException.java:62)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.IgniteException.(IgniteException.java:44)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.validate(GridCacheLockImpl.java:275)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.access$1000(GridCacheLockImpl.java:122)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1200)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.doTestReentrantLock(GridCacheAbstractDataStructuresFailoverSelfTest.java:785)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:739)
> [20:34:26] :   [Step 4/5] at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [20:34:26] :   [Step 4/5] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [20:34:26] :   [Step 4/5] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [20:34:26] :   [Step 4/5] at 
> java.lang.reflect.Method.invoke(Method.java:606)
> [20:34:26] :   [Step 4/5] at 
> junit.framework.TestCase.runTest(TestCase.java:176)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> [20:34:26] :   [Step 4/5] at java.lang.Thread.run(Thread.java:745)
> [20:34:26] :   [Step 4/5] 
> {noformat}
> That can be indicator that threads are interrupted and flag 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl#interruptAll
>  is set,
> than org.apache.ignite.IgniteException is thrown, but it is ignored by test 
> and test continues to execute



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Deleted] (IGNITE-6453) .NET: Thin client: cache operations

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn deleted IGNITE-6453:
---


> .NET: Thin client: cache operations
> ---
>
> Key: IGNITE-6453
> URL: https://issues.apache.org/jira/browse/IGNITE-6453
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> Add simple cache operations, like {{ContainsKey}} and {{GetSize}}. Skip 
> everything complex for now, like {{Invoke}}, which requires user-defined 
> processor.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-6209) .NET: Build NuGet packages for Apache-Ignite release on CI

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-6209.

Resolution: Fixed

> .NET: Build NuGet packages for Apache-Ignite release on CI
> --
>
> Key: IGNITE-6209
> URL: https://issues.apache.org/jira/browse/IGNITE-6209
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Oleg Ostanin
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Create a suite to build Ignite.NET NuGet packages on TeamCity: 
> https://ci.ignite.apache.org/project.html?projectId=IgniteRelease



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6435) Web Console: Add release version to footer

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6435:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Please test that footer shows version.
Also please test project generation for various versions.

> Web Console: Add release version to footer
> --
>
> Key: IGNITE-6435
> URL: https://issues.apache.org/jira/browse/IGNITE-6435
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6209) .NET: Build NuGet packages for Apache-Ignite release on CI

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6209:


Build script improvements merged to master: 
{{06d297823a3c229f570a3132f1bb222c0349db90}}

> .NET: Build NuGet packages for Apache-Ignite release on CI
> --
>
> Key: IGNITE-6209
> URL: https://issues.apache.org/jira/browse/IGNITE-6209
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Oleg Ostanin
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Create a suite to build Ignite.NET NuGet packages on TeamCity: 
> https://ci.ignite.apache.org/project.html?projectId=IgniteRelease



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6454) Data structure suite timeout: test is not able to fail after interruption

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-6454:
---
Summary: Data structure suite timeout: test is not able to fail after 
interruption  (was: Data structure suite timeout)

> Data structure suite timeout: test is not able to fail after interruption
> -
>
> Key: IGNITE-6454
> URL: https://issues.apache.org/jira/browse/IGNITE-6454
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataStrucutures=%3Cdefault%3E=buildTypeStatusDiv
> Most often timeout is caused by following tests:
> GridCacheReplicatedDataStructuresFailoverSelfTest
> - testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> -testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> And most of thread dumps contains the following
> {noformat}
> ] :[Step 4/5] Thread 
> [name="test-runner-#35143%replicated.GridCacheReplicatedDataStructuresFailoverSelfTest%",
>  id=38586, state=RUNNABLE, blockCnt=0, waitCnt=60]
> [20:34:26] :   [Step 4/5] at 
> java.lang.Throwable.fillInStackTrace(Native Method)
> [20:34:26] :   [Step 4/5] at 
> java.lang.Throwable.fillInStackTrace(Throwable.java:783)
> [20:34:26] :   [Step 4/5] - locked o.a.i.IgniteException@754033e
> [20:34:26] :   [Step 4/5] at 
> java.lang.Throwable.(Throwable.java:265)
> [20:34:26] :   [Step 4/5] at 
> java.lang.Exception.(Exception.java:66)
> [20:34:26] :   [Step 4/5] at 
> java.lang.RuntimeException.(RuntimeException.java:62)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.IgniteException.(IgniteException.java:44)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.validate(GridCacheLockImpl.java:275)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.access$1000(GridCacheLockImpl.java:122)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1200)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.doTestReentrantLock(GridCacheAbstractDataStructuresFailoverSelfTest.java:785)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:739)
> [20:34:26] :   [Step 4/5] at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [20:34:26] :   [Step 4/5] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [20:34:26] :   [Step 4/5] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [20:34:26] :   [Step 4/5] at 
> java.lang.reflect.Method.invoke(Method.java:606)
> [20:34:26] :   [Step 4/5] at 
> junit.framework.TestCase.runTest(TestCase.java:176)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> [20:34:26] :   [Step 4/5] at 
> o.a.i.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> [20:34:26] :   [Step 4/5] at java.lang.Thread.run(Thread.java:745)
> [20:34:26] :   [Step 4/5] 
> {noformat}
> That can be indicator that threads are interrupted and flag 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl#interruptAll
>  is set,
> than org.apache.ignite.IgniteException is thrown, but it is ignored by test 
> and test continues to execute



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6454) Data structure suite timeout

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-6454:
---
Description: 
https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataStrucutures=%3Cdefault%3E=buildTypeStatusDiv

Most often timeout is caused by following tests:
GridCacheReplicatedDataStructuresFailoverSelfTest
- testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
-testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()

And most of thread dumps contains the following
{noformat}
] :  [Step 4/5] Thread 
[name="test-runner-#35143%replicated.GridCacheReplicatedDataStructuresFailoverSelfTest%",
 id=38586, state=RUNNABLE, blockCnt=0, waitCnt=60]
[20:34:26] : [Step 4/5] at 
java.lang.Throwable.fillInStackTrace(Native Method)
[20:34:26] : [Step 4/5] at 
java.lang.Throwable.fillInStackTrace(Throwable.java:783)
[20:34:26] : [Step 4/5] - locked o.a.i.IgniteException@754033e
[20:34:26] : [Step 4/5] at 
java.lang.Throwable.(Throwable.java:265)
[20:34:26] : [Step 4/5] at 
java.lang.Exception.(Exception.java:66)
[20:34:26] : [Step 4/5] at 
java.lang.RuntimeException.(RuntimeException.java:62)
[20:34:26] : [Step 4/5] at 
o.a.i.IgniteException.(IgniteException.java:44)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.validate(GridCacheLockImpl.java:275)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.access$1000(GridCacheLockImpl.java:122)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1200)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.doTestReentrantLock(GridCacheAbstractDataStructuresFailoverSelfTest.java:785)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:739)
[20:34:26] : [Step 4/5] at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[20:34:26] : [Step 4/5] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[20:34:26] : [Step 4/5] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[20:34:26] : [Step 4/5] at 
java.lang.reflect.Method.invoke(Method.java:606)
[20:34:26] : [Step 4/5] at 
junit.framework.TestCase.runTest(TestCase.java:176)
[20:34:26] : [Step 4/5] at 
o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
[20:34:26] : [Step 4/5] at 
o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
[20:34:26] : [Step 4/5] at 
o.a.i.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
[20:34:26] : [Step 4/5] at java.lang.Thread.run(Thread.java:745)
[20:34:26] : [Step 4/5] 
{noformat}

That can be indicator that threads are interrupted and flag 
org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl#interruptAll
 is set,
than org.apache.ignite.IgniteException is thrown, but it is ignored by test and 
test continues to execute

  was:
https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataStrucutures=%3Cdefault%3E=buildTypeStatusDiv

Most often timeout is caused by following tests:

{noformat}
] :  [Step 4/5] Thread 
[name="test-runner-#35143%replicated.GridCacheReplicatedDataStructuresFailoverSelfTest%",
 id=38586, state=RUNNABLE, blockCnt=0, waitCnt=60]
[20:34:26] : [Step 4/5] at 
java.lang.Throwable.fillInStackTrace(Native Method)
[20:34:26] : [Step 4/5] at 
java.lang.Throwable.fillInStackTrace(Throwable.java:783)
[20:34:26] : [Step 4/5] - locked o.a.i.IgniteException@754033e
[20:34:26] : [Step 4/5] at 
java.lang.Throwable.(Throwable.java:265)
[20:34:26] : [Step 4/5] at 
java.lang.Exception.(Exception.java:66)
[20:34:26] : [Step 4/5] at 
java.lang.RuntimeException.(RuntimeException.java:62)
[20:34:26] : [Step 4/5] at 
o.a.i.IgniteException.(IgniteException.java:44)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.validate(GridCacheLockImpl.java:275)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.access$1000(GridCacheLockImpl.java:122)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1200)
[20:34:26] : [Step 4/5] at 

[jira] [Assigned] (IGNITE-6449) Visor CMD: Show missed cache properties

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-6449:
-

Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

> Visor CMD: Show missed cache properties
> ---
>
> Key: IGNITE-6449
> URL: https://issues.apache.org/jira/browse/IGNITE-6449
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6449) Visor CMD: Show missed cache properties

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-6449:
---

Implemented showing of missed cache properties for cache -a command.

> Visor CMD: Show missed cache properties
> ---
>
> Key: IGNITE-6449
> URL: https://issues.apache.org/jira/browse/IGNITE-6449
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-4591) File interop_target.h is missing from source-release

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4591:
---

Assignee: Ilya Suntsov  (was: Igor Sapego)

> File interop_target.h is missing from source-release
> 
>
> Key: IGNITE-4591
> URL: https://issues.apache.org/jira/browse/IGNITE-4591
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Ilya Suntsov
>  Labels: cpp
> Fix For: 2.2
>
>
> File 
> {{modules\platforms\cpp\core\include\ignite\impl\interop\interop_target.h}} 
> missing from source releases of versions 1.7.0 and 1.8.0. It is present, 
> however, in repository and binary releases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6454) Data structure suite timeout

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-6454:
--

 Summary: Data structure suite timeout
 Key: IGNITE-6454
 URL: https://issues.apache.org/jira/browse/IGNITE-6454
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Dmitriy Pavlov
Priority: Critical
 Fix For: 2.3


https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataStrucutures=%3Cdefault%3E=buildTypeStatusDiv

Most often timeout is caused by following tests:

{noformat}
] :  [Step 4/5] Thread 
[name="test-runner-#35143%replicated.GridCacheReplicatedDataStructuresFailoverSelfTest%",
 id=38586, state=RUNNABLE, blockCnt=0, waitCnt=60]
[20:34:26] : [Step 4/5] at 
java.lang.Throwable.fillInStackTrace(Native Method)
[20:34:26] : [Step 4/5] at 
java.lang.Throwable.fillInStackTrace(Throwable.java:783)
[20:34:26] : [Step 4/5] - locked o.a.i.IgniteException@754033e
[20:34:26] : [Step 4/5] at 
java.lang.Throwable.(Throwable.java:265)
[20:34:26] : [Step 4/5] at 
java.lang.Exception.(Exception.java:66)
[20:34:26] : [Step 4/5] at 
java.lang.RuntimeException.(RuntimeException.java:62)
[20:34:26] : [Step 4/5] at 
o.a.i.IgniteException.(IgniteException.java:44)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.validate(GridCacheLockImpl.java:275)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.access$1000(GridCacheLockImpl.java:122)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1200)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.doTestReentrantLock(GridCacheAbstractDataStructuresFailoverSelfTest.java:785)
[20:34:26] : [Step 4/5] at 
o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:739)
[20:34:26] : [Step 4/5] at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[20:34:26] : [Step 4/5] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[20:34:26] : [Step 4/5] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[20:34:26] : [Step 4/5] at 
java.lang.reflect.Method.invoke(Method.java:606)
[20:34:26] : [Step 4/5] at 
junit.framework.TestCase.runTest(TestCase.java:176)
[20:34:26] : [Step 4/5] at 
o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
[20:34:26] : [Step 4/5] at 
o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
[20:34:26] : [Step 4/5] at 
o.a.i.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
[20:34:26] : [Step 4/5] at java.lang.Thread.run(Thread.java:745)
[20:34:26] : [Step 4/5] 
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6304) Visor CMD: Failed script execution after throttling interval

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6304:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Looks good. Merged to master. Please retest.

> Visor CMD: Failed script execution after throttling interval
> 
>
> Key: IGNITE-6304
> URL: https://issues.apache.org/jira/browse/IGNITE-6304
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>
> To reproduce:
> 1) create alert
> 2) after alert triggered script is executed
> 3) after alert is gone and throttling interval is expire and alert was 
> triggered again the script doesn't execute



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6376) Web console: Enable task and job events in demo mode by default.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6376:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Looks good. Merged to master. Please retest.

> Web console: Enable task and job events in demo mode by default.
> 
>
> Key: IGNITE-6376
> URL: https://issues.apache.org/jira/browse/IGNITE-6376
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6453) .NET: Thin client: cache operations

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6453:
--

 Summary: .NET: Thin client: cache operations
 Key: IGNITE-6453
 URL: https://issues.apache.org/jira/browse/IGNITE-6453
 Project: Ignite
  Issue Type: Improvement
  Components: platforms, thin client
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.3


Add simple cache operations, like {{ContainsKey}} and {{GetSize}}. Skip 
everything complex for now, like {{Invoke}}, which requires user-defined 
processor.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6309) .NET: Thin client: Do not buffer entire socket response

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-6309:
--

Assignee: (was: Pavel Tupitsyn)

> .NET: Thin client: Do not buffer entire socket response
> ---
>
> Key: IGNITE-6309
> URL: https://issues.apache.org/jira/browse/IGNITE-6309
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET, performance
> Fix For: 2.3
>
>
> See {{ClientSocket.SendReceive}}: it buffers entire socket response into an 
> array. Responses can be huge (with {{QueryCursor.GetAll}} and the like), so 
> this can cause LOH allocations.
> We should implement {{IBinaryStream}} over a socket instead.
> This may cause situation when another socket call happens in the middle of 
> data transfer (for example, GetBinaryTypeName while reading cursor data).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6425) Races during transaction finalization

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev updated IGNITE-6425:
--
Description: 
I have found during stress-test (start-stop nodes during transactions running):
{code}
[2017-09-20 12:37:04,224][ERROR][updater-1][GridDhtColocatedCache]  
Failed to rollback transaction (cache may contain stale locks): GridNearTxLocal 
[mappings=IgniteTxMappingsSingleImpl [mapping=null], nearLocallyMapped=false, 
colocatedLocallyMapped=false, needCheckBackup=null, hasRemoteLocks=false, 
thread=updater-1, mappings=IgniteTxMappingsSingleImpl [mapping=null], 
super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[], 
dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter 
[completedBase=null, sndTransformedVals=false, depEnabled=false, 
txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false], 
super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=117380231, 
order=1505900296519, nodeOrder=1], writeVer=null, implicit=true, loc=true, 
threadId=15914, startTime=1505900224068, 
nodeId=2699eb85-b97a-431f-a038-a6970ee0, startVer=GridCacheVersion 
[topVer=117380231, order=1505900296519, nodeOrder=1], endVer=null, 
isolation=READ_COMMITTED, concurrency=OPTIMISTIC, timeout=0, 
sysInvalidate=false, sys=false, plc=2, commitVer=GridCacheVersion 
[topVer=117380231, order=1505900296519, nodeOrder=1], finalizing=NONE, 
invalidParts=null, state=ROLLED_BACK, timedOut=false, 
topVer=AffinityTopologyVersion [topVer=12, minorTopVer=0], duration=153ms, 
onePhaseCommit=false], size=1]]]
class org.apache.ignite.IgniteCheckedException: Failed to commit transaction: 
GridNearTxLocal[id=749f6ae9e51--06ff-1487--0001, 
concurrency=OPTIMISTIC, isolation=READ_COMMITTED, state=ROLLED_BACK, 
invalidate=false, rollbackOnly=true, 
nodeId=2699eb85-b97a-431f-a038-a6970ee0, duration=153]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:423)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3310)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$10.applyx(GridNearTxLocal.java:2411)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$10.applyx(GridNearTxLocal.java:2393)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:494)
at 
org.apache.ignite.internal.processors.cache.GridCacheCompoundIdentityFuture.onDone(GridCacheCompoundIdentityFuture.java:56)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:473)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.onDone(GridNearTxFinishFuture.java:340)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.onDone(GridNearTxFinishFuture.java:69)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:450)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:494)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:473)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:450)
at 

[jira] [Assigned] (IGNITE-898) Ignite does not starts from folder which name contains space

[Aleksei Zaitsev (JIRA)]

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

Aleksei Zaitsev reassigned IGNITE-898:
--

Assignee: Aleksei Zaitsev

> Ignite does not starts from folder which name contains space
> 
>
> Key: IGNITE-898
> URL: https://issues.apache.org/jira/browse/IGNITE-898
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Aleksei Zaitsev
>Priority: Trivial
> Fix For: 2.3
>
>
> Observed:
> In case folder name contains space character Ignite node cannot be started.
> Expected:
> Ingine node should be startable even when folder name contains space 
> character.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6425) Races during transaction finalization

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev updated IGNITE-6425:
--
Fix Version/s: 2.3

> Races during transaction finalization
> -
>
> Key: IGNITE-6425
> URL: https://issues.apache.org/jira/browse/IGNITE-6425
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
> Fix For: 2.3
>
>
> I have found during stress-test (start-stop nodes during transactions 
> running):
> {code}
> [2017-09-20 12:37:04,224][ERROR][updater-1][GridDhtColocatedCache]  
> Failed to rollback transaction (cache may contain stale locks): 
> GridNearTxLocal [mappings=IgniteTxMappingsSingleImpl [mapping=null], 
> nearLocallyMapped=false, colocatedLocallyMapped=false, needCheckBackup=null, 
> hasRemoteLocks=false, thread=updater-1, mappings=IgniteTxMappingsSingleImpl 
> [mapping=null], super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, 
> nearNodes=[], dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter 
> [completedBase=null, sndTransformedVals=false, depEnabled=false, 
> txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false], 
> super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=117380231, 
> order=1505900296519, nodeOrder=1], writeVer=null, implicit=true, loc=true, 
> threadId=15914, startTime=1505900224068, 
> nodeId=2699eb85-b97a-431f-a038-a6970ee0, startVer=GridCacheVersion 
> [topVer=117380231, order=1505900296519, nodeOrder=1], endVer=null, 
> isolation=READ_COMMITTED, concurrency=OPTIMISTIC, timeout=0, 
> sysInvalidate=false, sys=false, plc=2, commitVer=GridCacheVersion 
> [topVer=117380231, order=1505900296519, nodeOrder=1], finalizing=NONE, 
> invalidParts=null, state=ROLLED_BACK, timedOut=false, 
> topVer=AffinityTopologyVersion [topVer=12, minorTopVer=0], duration=153ms, 
> onePhaseCommit=false], size=1]]]
> class org.apache.ignite.IgniteCheckedException: Failed to commit transaction: 
> GridNearTxLocal[id=749f6ae9e51--06ff-1487--0001, 
> concurrency=OPTIMISTIC, isolation=READ_COMMITTED, state=ROLLED_BACK, 
> invalidate=false, rollbackOnly=true, 
> nodeId=2699eb85-b97a-431f-a038-a6970ee0, duration=153]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:423)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3310)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$10.applyx(GridNearTxLocal.java:2411)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$10.applyx(GridNearTxLocal.java:2393)
>   at 
> org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
>   at 
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
>   at 
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
>   at 
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:494)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheCompoundIdentityFuture.onDone(GridCacheCompoundIdentityFuture.java:56)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:473)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.onDone(GridNearTxFinishFuture.java:340)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.onDone(GridNearTxFinishFuture.java:69)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:450)
>   at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
>   at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
>   at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
>   at 

[jira] [Updated] (IGNITE-6425) Races during transaction finalization

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev updated IGNITE-6425:
--
Priority: Critical  (was: Major)

> Races during transaction finalization
> -
>
> Key: IGNITE-6425
> URL: https://issues.apache.org/jira/browse/IGNITE-6425
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Critical
> Fix For: 2.3
>
>
> I have found during stress-test (start-stop nodes during transactions 
> running):
> {code}
> [2017-09-20 12:37:04,224][ERROR][updater-1][GridDhtColocatedCache]  
> Failed to rollback transaction (cache may contain stale locks): 
> GridNearTxLocal [mappings=IgniteTxMappingsSingleImpl [mapping=null], 
> nearLocallyMapped=false, colocatedLocallyMapped=false, needCheckBackup=null, 
> hasRemoteLocks=false, thread=updater-1, mappings=IgniteTxMappingsSingleImpl 
> [mapping=null], super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, 
> nearNodes=[], dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter 
> [completedBase=null, sndTransformedVals=false, depEnabled=false, 
> txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false], 
> super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=117380231, 
> order=1505900296519, nodeOrder=1], writeVer=null, implicit=true, loc=true, 
> threadId=15914, startTime=1505900224068, 
> nodeId=2699eb85-b97a-431f-a038-a6970ee0, startVer=GridCacheVersion 
> [topVer=117380231, order=1505900296519, nodeOrder=1], endVer=null, 
> isolation=READ_COMMITTED, concurrency=OPTIMISTIC, timeout=0, 
> sysInvalidate=false, sys=false, plc=2, commitVer=GridCacheVersion 
> [topVer=117380231, order=1505900296519, nodeOrder=1], finalizing=NONE, 
> invalidParts=null, state=ROLLED_BACK, timedOut=false, 
> topVer=AffinityTopologyVersion [topVer=12, minorTopVer=0], duration=153ms, 
> onePhaseCommit=false], size=1]]]
> class org.apache.ignite.IgniteCheckedException: Failed to commit transaction: 
> GridNearTxLocal[id=749f6ae9e51--06ff-1487--0001, 
> concurrency=OPTIMISTIC, isolation=READ_COMMITTED, state=ROLLED_BACK, 
> invalidate=false, rollbackOnly=true, 
> nodeId=2699eb85-b97a-431f-a038-a6970ee0, duration=153]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:423)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3310)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$10.applyx(GridNearTxLocal.java:2411)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$10.applyx(GridNearTxLocal.java:2393)
>   at 
> org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
>   at 
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
>   at 
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
>   at 
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:494)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheCompoundIdentityFuture.onDone(GridCacheCompoundIdentityFuture.java:56)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:473)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.onDone(GridNearTxFinishFuture.java:340)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.onDone(GridNearTxFinishFuture.java:69)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:450)
>   at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
>   at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
>   at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
>   at 
> 

[jira] [Updated] (IGNITE-6425) Races during transaction finalization

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev updated IGNITE-6425:
--
Description: 
I have found during stress-test (start-stop nodes during transactions running):
{code}
[2017-09-20 12:37:04,224][ERROR][updater-1][GridDhtColocatedCache]  
Failed to rollback transaction (cache may contain stale locks): GridNearTxLocal 
[mappings=IgniteTxMappingsSingleImpl [mapping=null], nearLocallyMapped=false, 
colocatedLocallyMapped=false, needCheckBackup=null, hasRemoteLocks=false, 
thread=updater-1, mappings=IgniteTxMappingsSingleImpl [mapping=null], 
super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[], 
dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter 
[completedBase=null, sndTransformedVals=false, depEnabled=false, 
txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false], 
super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=117380231, 
order=1505900296519, nodeOrder=1], writeVer=null, implicit=true, loc=true, 
threadId=15914, startTime=1505900224068, 
nodeId=2699eb85-b97a-431f-a038-a6970ee0, startVer=GridCacheVersion 
[topVer=117380231, order=1505900296519, nodeOrder=1], endVer=null, 
isolation=READ_COMMITTED, concurrency=OPTIMISTIC, timeout=0, 
sysInvalidate=false, sys=false, plc=2, commitVer=GridCacheVersion 
[topVer=117380231, order=1505900296519, nodeOrder=1], finalizing=NONE, 
invalidParts=null, state=ROLLED_BACK, timedOut=false, 
topVer=AffinityTopologyVersion [topVer=12, minorTopVer=0], duration=153ms, 
onePhaseCommit=false], size=1]]]
class org.apache.ignite.IgniteCheckedException: Failed to commit transaction: 
GridNearTxLocal[id=749f6ae9e51--06ff-1487--0001, 
concurrency=OPTIMISTIC, isolation=READ_COMMITTED, state=ROLLED_BACK, 
invalidate=false, rollbackOnly=true, 
nodeId=2699eb85-b97a-431f-a038-a6970ee0, duration=153]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:423)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3310)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$10.applyx(GridNearTxLocal.java:2411)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$10.applyx(GridNearTxLocal.java:2393)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:494)
at 
org.apache.ignite.internal.processors.cache.GridCacheCompoundIdentityFuture.onDone(GridCacheCompoundIdentityFuture.java:56)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:473)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.onDone(GridNearTxFinishFuture.java:340)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.onDone(GridNearTxFinishFuture.java:69)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:450)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:494)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:473)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:450)
at 

[jira] [Commented] (IGNITE-6355) Calculating cache size during cache stop sporadically fails with ClusterGroupEmptyCheckedException

[Ivan Rakov (JIRA)]

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

Ivan Rakov commented on IGNITE-6355:


Previous fix is already merged to master. Development will be continued under 
IGNITE-6452.

> Calculating cache size during cache stop sporadically fails with 
> ClusterGroupEmptyCheckedException
> --
>
> Key: IGNITE-6355
> URL: https://issues.apache.org/jira/browse/IGNITE-6355
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Example stacktrace:
> {noformat}
> [16:21:06,343][ERROR][main][root] Test failed.
> javax.cache.CacheException: class 
> org.apache.ignite.cluster.ClusterGroupEmptyException: Topology projection is 
> empty.
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1327)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1672)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.size(IgniteCacheProxyImpl.java:762)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.size(GatewayProtectedCacheProxy.java:508)
>   at 
> org.gridgain.grid.internal.processors.cache.database.IgniteDbSnapshotSelfTest.testReuseCacheProxyAfterRestore(IgniteDbSnapshotSelfTest.java:1793)
>   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:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.cluster.ClusterGroupEmptyException: 
> Topology projection is empty.
>   at 
> org.apache.ignite.internal.util.IgniteUtils$6.apply(IgniteUtils.java:823)
>   at 
> org.apache.ignite.internal.util.IgniteUtils$6.apply(IgniteUtils.java:821)
>   ... 14 more
> Caused by: class 
> org.apache.ignite.internal.cluster.ClusterGroupEmptyCheckedException: 
> Topology projection is empty.
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.getTaskTopology(GridTaskWorker.java:665)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:500)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:758)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:454)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:410)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.sizeAsync(GridCacheAdapter.java:3747)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.size(GridCacheAdapter.java:3704)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.size(IgniteCacheProxyImpl.java:759)
>   ... 11 more
> {noformat}
> Data race stems from here (GridCacheAdapter#sizeAsync):
> {noformat}
> Group grp = modes.near ? cluster.forCacheNodes(name(), true, true, 
> false) : cluster.forDataNodes(name());
> Collection nodes = grp.nodes();
> if (nodes.isEmpty())
> return new GridFinishedFuture<>(0);
> ctx.kernalContext().task().setThreadContext(TC_SUBGRID, nodes);
> return ctx.kernalContext().task().execute(
> new SizeTask(ctx.name(), 
> ctx.affinity().affinityTopologyVersion(), peekModes), null);
> {noformat}
> Method grp.nodes() returns PredicateCollectionView, which size depends on 
> Ignite state. It can pass nodes.isEmpty() check and become empty later.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-6355) Calculating cache size during cache stop sporadically fails with ClusterGroupEmptyCheckedException

[Ivan Rakov (JIRA)]

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

Ivan Rakov resolved IGNITE-6355.

Resolution: Fixed

> Calculating cache size during cache stop sporadically fails with 
> ClusterGroupEmptyCheckedException
> --
>
> Key: IGNITE-6355
> URL: https://issues.apache.org/jira/browse/IGNITE-6355
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Example stacktrace:
> {noformat}
> [16:21:06,343][ERROR][main][root] Test failed.
> javax.cache.CacheException: class 
> org.apache.ignite.cluster.ClusterGroupEmptyException: Topology projection is 
> empty.
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1327)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1672)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.size(IgniteCacheProxyImpl.java:762)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.size(GatewayProtectedCacheProxy.java:508)
>   at 
> org.gridgain.grid.internal.processors.cache.database.IgniteDbSnapshotSelfTest.testReuseCacheProxyAfterRestore(IgniteDbSnapshotSelfTest.java:1793)
>   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:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.cluster.ClusterGroupEmptyException: 
> Topology projection is empty.
>   at 
> org.apache.ignite.internal.util.IgniteUtils$6.apply(IgniteUtils.java:823)
>   at 
> org.apache.ignite.internal.util.IgniteUtils$6.apply(IgniteUtils.java:821)
>   ... 14 more
> Caused by: class 
> org.apache.ignite.internal.cluster.ClusterGroupEmptyCheckedException: 
> Topology projection is empty.
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.getTaskTopology(GridTaskWorker.java:665)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:500)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:758)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:454)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:410)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.sizeAsync(GridCacheAdapter.java:3747)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.size(GridCacheAdapter.java:3704)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.size(IgniteCacheProxyImpl.java:759)
>   ... 11 more
> {noformat}
> Data race stems from here (GridCacheAdapter#sizeAsync):
> {noformat}
> Group grp = modes.near ? cluster.forCacheNodes(name(), true, true, 
> false) : cluster.forDataNodes(name());
> Collection nodes = grp.nodes();
> if (nodes.isEmpty())
> return new GridFinishedFuture<>(0);
> ctx.kernalContext().task().setThreadContext(TC_SUBGRID, nodes);
> return ctx.kernalContext().task().execute(
> new SizeTask(ctx.name(), 
> ctx.affinity().affinityTopologyVersion(), peekModes), null);
> {noformat}
> Method grp.nodes() returns PredicateCollectionView, which size depends on 
> Ignite state. It can pass nodes.isEmpty() check and become empty later.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6452) Invocation of getAll() through cache proxy during cache restart can throw unexpected CacheException

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-6452:
--

 Summary: Invocation of getAll() through cache proxy during cache 
restart can throw unexpected CacheException
 Key: IGNITE-6452
 URL: https://issues.apache.org/jira/browse/IGNITE-6452
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Ivan Rakov
Assignee: Ivan Rakov
 Fix For: 2.3


Instead of expected IgniteCacheRestartingException, load test shows the 
following exception sometimes:
{noformat}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: 
Failed to find message handler for message: GridNearGetRequest 
[futId=6fc73459e51-84b93e3c-47e1-433c-8a91-0700f131c617, 
miniId=27d73459e51-84b93e3c-47e1-433c-8a91-0700f131c617, ver=null, keyMap=null, 
flags=1, topVer=AffinityTopologyVersion [topVer=4, minorTopVer=32], 
subjId=080177d4-b78e-4f6f-a386-77be8830, taskNameHash=0, createTtl=-1, 
accessTtl=-1]

at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1285)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1648)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.getAll(IgniteCacheProxyImpl.java:873)
at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.getAll(GatewayProtectedCacheProxy.java:718)
at 
org.gridgain.grid.internal.processors.cache.database.IgniteDbSnapshotSelfTest$15.apply(IgniteDbSnapshotSelfTest.java:1911)
at 
org.gridgain.grid.internal.processors.cache.database.IgniteDbSnapshotSelfTest$15.apply(IgniteDbSnapshotSelfTest.java:1904)
at 
org.gridgain.grid.internal.processors.cache.database.IgniteDbSnapshotSelfTest.testReuseCacheProxyAfterRestore(IgniteDbSnapshotSelfTest.java:1796)
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:497)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6450) Kotlin: Inherited platform declarations clash

[redtank (JIRA)]

redtank created IGNITE-6450:
---

 Summary: Kotlin: Inherited platform declarations clash
 Key: IGNITE-6450
 URL: https://issues.apache.org/jira/browse/IGNITE-6450
 Project: Ignite
  Issue Type: Bug
  Components: cache, spring
Affects Versions: 2.1, 2.2
 Environment: OS: macOS 10.12
Java: 1.8.0_112-b16
Kotlin: 1.1.4-3

org.apache.ignite:ignite-spring-data:2.2.0
org.springframework.data:spring-data-commons:1.13.1.RELEASE -> 2.0.0.RC3
Reporter: redtank


I am trying Spring Data and Ignite. My repository interface is below

```
@RepositoryConfig(cacheName = "QuoteRequest")
interface QuoteRequestRepository : IgniteRepository
```

The code works for spring-data-commons:1.13.1.RELEASE. But it doesn't work for 
2.0.0.RC3. The error message is below
 
```
Error:(9, 11) Kotlin: Inherited platform declarations clash: The following 
declarations have the same JVM signature (deleteAll(Ljava/lang/Iterable;)V):
fun deleteAll(p0: (Mutable)Iterable!): Unit defined in 
repository.QuoteRequestRepository
fun deleteAll(p0: (Mutable)Iterable!): Unit defined in 
repository.QuoteRequestRepository
```



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6448) Select * doesn't return new field name after concurrent ALTER TABLE

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-6448:
--

Root cause: use cached query at the 
{{IgniteH2Indexing#queryDistributedSqlFields}}.
Proposal: the query cache {{IgniteH2Indexing#twoStepCache}} must be reset or 
partially cleaned after add / remove columns.

> Select * doesn't return new field name after concurrent ALTER TABLE 
> 
>
> Key: IGNITE-6448
> URL: https://issues.apache.org/jira/browse/IGNITE-6448
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.3
>
>
> Steps for reproduce:
> 1. Start 3 nodes
> 2. Execute 
> {noformat}CREATE TABLE person (id LONG, name VARCHAR, city_id LONG, PRIMARY 
> KEY (id, city_id)) {noformat}
> to create table Person
> 3. Connect to grid via sqlline (https://github.com/julianhyde/sqlline)
> {noformat}./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
> --verbose=true --showWarnings=true --showNestedErrs=true -u 
> jdbc:ignite:thin://127.0.0.1/{noformat}
> 4. Create one more connection {noformat}!connect 
> jdbc:ignite:thin://127.0.0.1/ {noformat}
> 5. Execute ALTER TABLE for both connections {noformat} !all alter table 
> person add field1 varchar;{noformat}
> Result:
> 1. Got exception on coordinator:
> {noformat}[10:59:15,805][SEVERE][client-connector-#55%null%][JdbcRequestHandler]
>  Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest 
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=alter table person add 
> field1 varchar, args=[], stmtType=ANY_STATEMENT_TYPE]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Column 
> already exists: FIELD1
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:329)
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:273)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1383)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
>   at 
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at 
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> 2. When I try to get all data from Person:
> {noformat}select * from person;{noformat}
> I get the table without new field but if try to get only this field from 
> table it works.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6449) Visor CMD: Show missed cache properties

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-6449:
-

 Summary: Visor CMD: Show missed cache properties
 Key: IGNITE-6449
 URL: https://issues.apache.org/jira/browse/IGNITE-6449
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.1
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko
 Fix For: 2.3






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6448) Select * doesn't return new field name after concurrent ALTER TABLE

[Ilya Suntsov (JIRA)]

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

Ilya Suntsov commented on IGNITE-6448:
--

I obsed the same behavior also for non concurrent ALTER TABLE

> Select * doesn't return new field name after concurrent ALTER TABLE 
> 
>
> Key: IGNITE-6448
> URL: https://issues.apache.org/jira/browse/IGNITE-6448
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.3
>
>
> Steps for reproduce:
> 1. Start 3 nodes
> 2. Execute 
> {noformat}CREATE TABLE person (id LONG, name VARCHAR, city_id LONG, PRIMARY 
> KEY (id, city_id)) {noformat}
> to create table Person
> 3. Connect to grid via sqlline (https://github.com/julianhyde/sqlline)
> {noformat}./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
> --verbose=true --showWarnings=true --showNestedErrs=true -u 
> jdbc:ignite:thin://127.0.0.1/{noformat}
> 4. Create one more connection {noformat}!connect 
> jdbc:ignite:thin://127.0.0.1/ {noformat}
> 5. Execute ALTER TABLE for both connections {noformat} !all alter table 
> person add field1 varchar;{noformat}
> Result:
> 1. Got exception on coordinator:
> {noformat}[10:59:15,805][SEVERE][client-connector-#55%null%][JdbcRequestHandler]
>  Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest 
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=alter table person add 
> field1 varchar, args=[], stmtType=ANY_STATEMENT_TYPE]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Column 
> already exists: FIELD1
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:329)
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:273)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1383)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
>   at 
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at 
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> 2. When I try to get all data from Person:
> {noformat}select * from person;{noformat}
> I get the table without new field but if try to get only this field from 
> table it works.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6448) Select * doesn't return new field name after concurrent ALTER TABLE

[Ilya Suntsov (JIRA)]

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

Ilya Suntsov edited comment on IGNITE-6448 at 9/20/17 8:48 AM:
---

I observed the same behavior also for non concurrent ALTER TABLE


was (Author: ustas):
I obsed the same behavior also for non concurrent ALTER TABLE

> Select * doesn't return new field name after concurrent ALTER TABLE 
> 
>
> Key: IGNITE-6448
> URL: https://issues.apache.org/jira/browse/IGNITE-6448
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.3
>
>
> Steps for reproduce:
> 1. Start 3 nodes
> 2. Execute 
> {noformat}CREATE TABLE person (id LONG, name VARCHAR, city_id LONG, PRIMARY 
> KEY (id, city_id)) {noformat}
> to create table Person
> 3. Connect to grid via sqlline (https://github.com/julianhyde/sqlline)
> {noformat}./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
> --verbose=true --showWarnings=true --showNestedErrs=true -u 
> jdbc:ignite:thin://127.0.0.1/{noformat}
> 4. Create one more connection {noformat}!connect 
> jdbc:ignite:thin://127.0.0.1/ {noformat}
> 5. Execute ALTER TABLE for both connections {noformat} !all alter table 
> person add field1 varchar;{noformat}
> Result:
> 1. Got exception on coordinator:
> {noformat}[10:59:15,805][SEVERE][client-connector-#55%null%][JdbcRequestHandler]
>  Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest 
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=alter table person add 
> field1 varchar, args=[], stmtType=ANY_STATEMENT_TYPE]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Column 
> already exists: FIELD1
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:329)
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:273)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1383)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
>   at 
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at 
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> 2. When I try to get all data from Person:
> {noformat}select * from person;{noformat}
> I get the table without new field but if try to get only this field from 
> table it works.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6448) Select * doesn't return new field name after concurrent ALTER TABLE

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6448:

Priority: Critical  (was: Blocker)

> Select * doesn't return new field name after concurrent ALTER TABLE 
> 
>
> Key: IGNITE-6448
> URL: https://issues.apache.org/jira/browse/IGNITE-6448
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Priority: Critical
> Fix For: 2.3
>
>
> Steps for reproduce:
> 1. Start 3 nodes
> 2. Execute 
> {noformat}CREATE TABLE person (id LONG, name VARCHAR, city_id LONG, PRIMARY 
> KEY (id, city_id)) {noformat}
> to create table Person
> 3. Connect to grid via sqlline (https://github.com/julianhyde/sqlline)
> {noformat}./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
> --verbose=true --showWarnings=true --showNestedErrs=true -u 
> jdbc:ignite:thin://127.0.0.1/{noformat}
> 4. Create one more connection {noformat}!connect 
> jdbc:ignite:thin://127.0.0.1/ {noformat}
> 5. Execute ALTER TABLE for both connections {noformat} !all alter table 
> person add field1 varchar;{noformat}
> Result:
> 1. Got exception on coordinator:
> {noformat}[10:59:15,805][SEVERE][client-connector-#55%null%][JdbcRequestHandler]
>  Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest 
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=alter table person add 
> field1 varchar, args=[], stmtType=ANY_STATEMENT_TYPE]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Column 
> already exists: FIELD1
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:329)
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:273)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1383)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
>   at 
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at 
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> 2. When I try to get all data from Person:
> {noformat}select * from person;{noformat}
> I get the table without new field but if try to get only this field from 
> table it works.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6448) Select * doesn't return new field name after concurrent ALTER TABLE

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-6448:
---

Assignee: Taras Ledkov

> Select * doesn't return new field name after concurrent ALTER TABLE 
> 
>
> Key: IGNITE-6448
> URL: https://issues.apache.org/jira/browse/IGNITE-6448
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.3
>
>
> Steps for reproduce:
> 1. Start 3 nodes
> 2. Execute 
> {noformat}CREATE TABLE person (id LONG, name VARCHAR, city_id LONG, PRIMARY 
> KEY (id, city_id)) {noformat}
> to create table Person
> 3. Connect to grid via sqlline (https://github.com/julianhyde/sqlline)
> {noformat}./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
> --verbose=true --showWarnings=true --showNestedErrs=true -u 
> jdbc:ignite:thin://127.0.0.1/{noformat}
> 4. Create one more connection {noformat}!connect 
> jdbc:ignite:thin://127.0.0.1/ {noformat}
> 5. Execute ALTER TABLE for both connections {noformat} !all alter table 
> person add field1 varchar;{noformat}
> Result:
> 1. Got exception on coordinator:
> {noformat}[10:59:15,805][SEVERE][client-connector-#55%null%][JdbcRequestHandler]
>  Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest 
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=alter table person add 
> field1 varchar, args=[], stmtType=ANY_STATEMENT_TYPE]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Column 
> already exists: FIELD1
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:329)
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:273)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1383)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
>   at 
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at 
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> 2. When I try to get all data from Person:
> {noformat}select * from person;{noformat}
> I get the table without new field but if try to get only this field from 
> table it works.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6448) Select * doesn't return new field name after concurrent ALTER TABLE

[Ilya Suntsov (JIRA)]

Ilya Suntsov created IGNITE-6448:


 Summary: Select * doesn't return new field name after concurrent 
ALTER TABLE 
 Key: IGNITE-6448
 URL: https://issues.apache.org/jira/browse/IGNITE-6448
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.1
Reporter: Ilya Suntsov
Priority: Blocker
 Fix For: 2.3


Steps for reproduce:
1. Start 3 nodes
2. Execute 
{noformat}CREATE TABLE person (id LONG, name VARCHAR, city_id LONG, PRIMARY KEY 
(id, city_id)) {noformat}
to create table Person
3. Connect to grid via sqlline (https://github.com/julianhyde/sqlline)
{noformat}./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
--verbose=true --showWarnings=true --showNestedErrs=true -u 
jdbc:ignite:thin://127.0.0.1/{noformat}
4. Create one more connection {noformat}!connect jdbc:ignite:thin://127.0.0.1/ 
{noformat}
5. Execute ALTER TABLE for both connections {noformat} !all alter table person 
add field1 varchar;{noformat}
Result:
1. Got exception on coordinator:
{noformat}[10:59:15,805][SEVERE][client-connector-#55%null%][JdbcRequestHandler]
 Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest 
[schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=alter table person add 
field1 varchar, args=[], stmtType=ANY_STATEMENT_TYPE]]
class org.apache.ignite.internal.processors.query.IgniteSQLException: Column 
already exists: FIELD1
at 
org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:329)
at 
org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:273)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1383)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
at 
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
at 
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
at 
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
at 
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
at 
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
at 
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at 
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
2. When I try to get all data from Person:
{noformat}select * from person;{noformat}
I get the table without new field but if try to get only this field from table 
it works.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)