[jira] [Updated] (IGNITE-6912) .NET: Thin client: Cache iterator

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6912:
---
Description: 
{{ICacheClient}} should be {{IEnumerable>}}, same as 
{{ICache}}.
This can be easily implemented with a ScanQuery without a filter. Find out 
wether ScanQuery is a good equivalent of a proper cache iterator.
Same thing for {{GetLocalEntries}}.

  was:
{{ICacheClient}} should be {{IEnumerable>}}, same as 
{{ICache}}.
This can be easily implemented with a ScanQuery without a filter. Find out 
wether ScanQuery is a good equivalent of a proper cache iterator.


> .NET: Thin client: Cache iterator
> -
>
> Key: IGNITE-6912
> URL: https://issues.apache.org/jira/browse/IGNITE-6912
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> {{ICacheClient}} should be {{IEnumerable>}}, same as 
> {{ICache}}.
> This can be easily implemented with a ScanQuery without a filter. Find out 
> wether ScanQuery is a good equivalent of a proper cache iterator.
> Same thing for {{GetLocalEntries}}.



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

[jira] [Commented] (IGNITE-6854) Enabling Persistent Memory for Ignite

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6854:
-

[~mulugeta],

No doubts, it will be beneficial for Ignite to integrate with the persistent 
memory. Personally, I truly like option 2.

Please initiate a discussion on Apache Ignite dev list bringing the proposed 
integration to the attention of a wider audience. First, we need to assess the 
complexity and confirm that's either of options is feasible and worth the 
efforts of both Ignite and Intel developers.

Don't forget to register on the dev list before sending a message there:
https://ignite.apache.org/community/resources.html#mail-lists  

> Enabling Persistent Memory for Ignite
> -
>
> Key: IGNITE-6854
> URL: https://issues.apache.org/jira/browse/IGNITE-6854
> Project: Ignite
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.3
>Reporter: Mulugeta Mammo
> Fix For: 2.4
>
>
> Ignite, when persistence mode is enabled, stores data and indexes on disk. To 
> minimize the latency of disks, several tuning options can be applied. Setting 
> the page size of a memory region to match the page size of the underlying 
> storage, using a separate disk for the WAL, and using production-level SSDs 
> are just a few of them [ 
> https://apacheignite.readme.io/docs/durable-memory-tuning#section-native-persistence-related-tuning
>  ]. 
>  
> A persistent memory store with low latency and high capacity offers a viable 
> alternative to disks. In light of this, we are proposing to make use of our 
> Low Level Persistent Library (LLPL), 
> https://github.com/pmem/pcj/tree/master/LLPL, to offer a persistent memory 
> storage for Ignite. 
>  
> At this point, we envision two distinct implementation options:
> # Data and indexes will continue to be stored in the off-heap memory but the 
> disk will be replaced by a persistent memory. Since persistence memory in 
> this option is not a file system, the logic currently offered by WAL file and 
> the partition files would have to be implemented from scratch.
> # In this option, we eliminate the current check-point process and the WAL 
> file. We will use a memory region defined by LLPL to store data and indexes. 
> There will be no off-heap memory. DRAM will be exclusively used to store hot 
> cache entries just like the on-heap cache is in the current implementation. 
>   
>  
> In both cases, there are more details and subtleties that have to handled – 
> e.g. the atomic and transactional guarantees offered. More clarifications 
> will be given as we go along.



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

[jira] [Created] (IGNITE-6912) .NET: Thin client: Cache iterator

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6912:
--

 Summary: .NET: Thin client: Cache iterator
 Key: IGNITE-6912
 URL: https://issues.apache.org/jira/browse/IGNITE-6912
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
  Components: platforms, thin client
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.4


{{ICacheClient}} should be {{IEnumerable>}}, same as 
{{ICache}}.
This can be easily implemented with a ScanQuery without a filter. Find out 
wether ScanQuery is a good equivalent of a proper cache iterator.



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

[jira] [Updated] (IGNITE-6912) .NET: Thin client: Cache iterator

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6912:
---
Description: 
{{ICacheClient}} should be {{IEnumerable>}}, same as 
{{ICache}}.
This can be easily implemented with a {{ScanQuery}} without a filter.
Same thing for {{GetLocalEntries}}.

  was:
{{ICacheClient}} should be {{IEnumerable>}}, same as 
{{ICache}}.
This can be easily implemented with a ScanQuery without a filter. Find out 
wether ScanQuery is a good equivalent of a proper cache iterator.
Same thing for {{GetLocalEntries}}.


> .NET: Thin client: Cache iterator
> -
>
> Key: IGNITE-6912
> URL: https://issues.apache.org/jira/browse/IGNITE-6912
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> {{ICacheClient}} should be {{IEnumerable>}}, same as 
> {{ICache}}.
> This can be easily implemented with a {{ScanQuery}} without a filter.
> Same thing for {{GetLocalEntries}}.



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

[jira] [Created] (IGNITE-6911) .NET: Optionally disable Java console redirect

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6911:
--

 Summary: .NET: Optionally disable Java console redirect
 Key: IGNITE-6911
 URL: https://issues.apache.org/jira/browse/IGNITE-6911
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.4


Java console redirect ({{PlatformCallbackUtils.consoleWrite}} involves JNI 
callback and, potentially, can affect performance and stability of the 
application.

It would be a good idea to disable this in production.
* Add {{IgniteConfiguration.EnableJavaConsoleRedirect}} propery.
* Disable callback on both .NET and Java sides



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

[jira] [Assigned] (IGNITE-4394) Web console: memory leak when dialog "Connection to Ignite Node is not established" on the screen

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-4394:
-

Assignee: Alexander Kalinin

> Web console: memory leak when dialog "Connection to Ignite Node is not 
> established" on the screen
> -
>
> Key: IGNITE-4394
> URL: https://issues.apache.org/jira/browse/IGNITE-4394
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Alexander Kalinin
>  Time Spent: 0.1m
>  Remaining Estimate: 0h
>
> I've noticed memory leak in case when dialog is opened during long period.



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

[jira] [Created] (IGNITE-6913) Add support for baseline manipulations to controls.sh

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-6913:


 Summary: Add support for baseline manipulations to controls.sh
 Key: IGNITE-6913
 URL: https://issues.apache.org/jira/browse/IGNITE-6913
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.4


This is a ticket to make required changes baseline topology introduced in 
Ignite:
[https://issues.apache.org/jira/browse/IGNITE-5849] 

We can reuse control.sh script, and add few new commands.

# Print current baseline: `./control.sh --baseline`
# Add nodes to baseline: `./control.sh --baseline add 
constId1[,constid2,,constidN]`
# Remove nodes from baseline: ./control.sh --baseline remove 
constid1[,constid2,,constidN]
# Set baseline: `./control.sh --baseline set constid1[,constid2,,constidN]
# Set baseline for version: `./control.sh --baseline version topVersion`





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

[jira] [Commented] (IGNITE-6686) Document SQL Data Types

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6686:
-

[~ptupitsyn], [~isapego],

Please fill out .NET, C++ and ODBC for these types:
https://apacheignite-sql.readme.io/v2.3/docs/data-types#section-binary
https://apacheignite-sql.readme.io/v2.3/docs/data-types#section-array

[~vozerov], 

Referring to this source {{H2DatabaseType}}, some of the types' mappings are 
ambiguous. For instance, {{TIMESTAMP}} maps to both {{java.util.Date}} and 
{{java.sql.Timestamp}} [1]. It's clear that if a user passes {{java.util.Date}} 
or {{java.sql.Timestamp}} value then it will be marked as {{TIMESTAMP}}. 
However, what's the default type? Assume we support {{DEFAULT}} constraint for 
columns and I need to initialize a {{TIMESTAMP}} column with a value. What will 
be the type of the value?

[1] 
https://github.com/apache/ignite/blob/master/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/H2DatabaseType.java#L111

> Document SQL Data Types
> ---
>
> Key: IGNITE-6686
> URL: https://issues.apache.org/jira/browse/IGNITE-6686
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
> Fix For: 2.3
>
>
> The data types page should include all SQL types supported and how they 
> mapped to a language or driver specific type. Presently the types are 
> represented in a tabular format:
> https://apacheignite-sql.readme.io/v2.3/docs/data-types
> Guys, please help to fill out langage/drivers specific columns:
> # [~ptupitsyn] - .NET data types.
> # [~isapego] - C++ and ODBC data type.
> # [~al.psc] - JDBC and JAVA data types.
> [~vozerov], please suggest what to do with these few types below. They 
> supported by H2 but I'm not sure how Ignite deals with them:
> http://www.h2database.com/html/datatypes.html#identity_type
> http://www.h2database.com/html/datatypes.html#binary_type
> http://www.h2database.com/html/datatypes.html#other_type
> http://www.h2database.com/html/datatypes.html#varchar_ignorecase_type
> http://www.h2database.com/html/datatypes.html#blob_type
> http://www.h2database.com/html/datatypes.html#clob_type
> http://www.h2database.com/html/datatypes.html#array_type
> http://www.h2database.com/html/datatypes.html#enum_type



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

[jira] [Commented] (IGNITE-6912) .NET: Thin client: Cache iterator

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6912:


See {{GridCacheAdapter.scanIterator()}}. It appears that scan query without a 
filter is exactly the same thing as a cache iterator.

> .NET: Thin client: Cache iterator
> -
>
> Key: IGNITE-6912
> URL: https://issues.apache.org/jira/browse/IGNITE-6912
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> {{ICacheClient}} should be {{IEnumerable>}}, same as 
> {{ICache}}.
> This can be easily implemented with a ScanQuery without a filter. Find out 
> wether ScanQuery is a good equivalent of a proper cache iterator.



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

[jira] [Commented] (IGNITE-6912) .NET: Thin client: Cache iterator

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6912:
-

[~ptupitsyn], scans and standard iterators are not semantically equal. To be 
more precise, we never declared that they are semantically different, but 
neither we state that they are semantically equal. One example of such a 
difference is MVCC [1]. We have a plan to support it to scans, but do not have 
clear plans for iterators yet. So I'd prefer to use standard iterator API 
instead.

[1] IGNITE-3478

> .NET: Thin client: Cache iterator
> -
>
> Key: IGNITE-6912
> URL: https://issues.apache.org/jira/browse/IGNITE-6912
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> {{ICacheClient}} should be {{IEnumerable>}}, same as 
> {{ICache}}.
> This can be easily implemented with a {{ScanQuery}} without a filter.
> Same thing for {{GetLocalEntries}}.



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

[jira] [Commented] (IGNITE-5635) Web Console: Show query execution progress

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-5635:


Successfully tested

> Web Console: Show query execution progress
> --
>
> Key: IGNITE-5635
> URL: https://issues.apache.org/jira/browse/IGNITE-5635
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
> Attachments: screenshot-1.png
>
>
> Show query execution progress, some progress or spinning wheel.



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

[jira] [Assigned] (IGNITE-5635) Web Console: Show query execution progress

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-5635:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Web Console: Show query execution progress
> --
>
> Key: IGNITE-5635
> URL: https://issues.apache.org/jira/browse/IGNITE-5635
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.4
>
> Attachments: screenshot-1.png
>
>
> Show query execution progress, some progress or spinning wheel.



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

[jira] [Assigned] (IGNITE-5731) Wrong metrics calculation in ClusterMetricsSnapshot

[Denis Loginov (JIRA)]

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

Denis Loginov reassigned IGNITE-5731:
-

Assignee: Denis Loginov

> Wrong metrics calculation in ClusterMetricsSnapshot
> ---
>
> Key: IGNITE-5731
> URL: https://issues.apache.org/jira/browse/IGNITE-5731
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Evgenii Zhuravlev
>Assignee: Denis Loginov
>Priority: Minor
>
>  Error in ClusterMetricsSnapshot constructor:
>  curWaitingJobs += m.getCurrentJobWaitTime();
>  avgWaitingJobs += m.getCurrentWaitingJobs();



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

[jira] [Updated] (IGNITE-6915) SQL: Failed to invoke getter method (type=class java.lang.String)

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-6915:
---
Component/s: sql

> SQL: Failed to invoke getter method (type=class java.lang.String)
> -
>
> Key: IGNITE-6915
> URL: https://issues.apache.org/jira/browse/IGNITE-6915
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Pavel Konstantinov
> Attachments: screenshot-1.png
>
>
> cluster configuration:
> - 2 server nodes (one with a load)
> - cache populated with data
> Executed ' select * from "cache".Person '
> !screenshot-1.png!
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: ┬эєЄЁхээ   ю°шсър: "class 
> org.apache.ignite.IgniteCheckedException: Failed to invoke getter method 
> [type=class java.lang.String, property=firstName]"
> General error: "class org.apache.ignite.IgniteCheckedException: Failed to 
> invoke getter method [type=class java.lang.String, property=firstName]"; SQL 
> statement:
> SELECT
> __Z0.FIRSTNAME __C0_0,
> __Z0.LASTNAME __C0_1,
> __Z0.RANK __C0_2,
> __Z0.TITLE __C0_3,
> __Z0.AGE __C0_4,
> __Z0.SALARY __C0_5,
> __Z0.ID __C0_6,
> __Z0.DEPID __C0_7
> FROM "c_partitioned".PERSON __Z0 [5-195]
> at 
> org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:295)
> at 
> org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:348)
> at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:236)
> at org.h2.table.TableFilter.getValue(TableFilter.java:1083)
> at 
> org.h2.expression.ExpressionColumn.getValue(ExpressionColumn.java:186)
> at org.h2.expression.Alias.getValue(Alias.java:36)
> at 
> org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1459)
> at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
> at org.h2.result.LazyResult.next(LazyResult.java:59)
> at org.h2.command.dml.Select.queryFlat(Select.java:519)
> at org.h2.command.dml.Select.queryWithoutCache(Select.java:625)
> at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
> at org.h2.command.dml.Query.query(Query.java:352)
> at org.h2.command.dml.Query.query(Query.java:333)
> at org.h2.command.CommandContainer.query(CommandContainer.java:113)
> at org.h2.command.Command.executeQuery(Command.java:201)
> at 
> org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:111)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:967)
> ... 31 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to invoke 
> getter method [type=class java.lang.String, property=firstName]
> at 
> org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:51)
> at 
> org.apache.ignite.internal.processors.query.property.QueryClassProperty.value(QueryClassProperty.java:82)
> at 
> org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:345)
> ... 47 more
> Caused by: java.lang.IllegalArgumentException: object is not an instance of 
> declaring class
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:48)
> ... 49 more
> {code}



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

[jira] [Commented] (IGNITE-6686) Document SQL Data Types

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6686:


[~dmagda], done.

> Document SQL Data Types
> ---
>
> Key: IGNITE-6686
> URL: https://issues.apache.org/jira/browse/IGNITE-6686
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> The data types page should include all SQL types supported and how they 
> mapped to a language or driver specific type. Presently the types are 
> represented in a tabular format:
> https://apacheignite-sql.readme.io/v2.3/docs/data-types
> Guys, please help to fill out langage/drivers specific columns:
> # [~ptupitsyn] - .NET data types.
> # [~isapego] - C++ and ODBC data type.
> # [~al.psc] - JDBC and JAVA data types.
> [~vozerov], please suggest what to do with these few types below. They 
> supported by H2 but I'm not sure how Ignite deals with them:
> http://www.h2database.com/html/datatypes.html#identity_type
> http://www.h2database.com/html/datatypes.html#binary_type
> http://www.h2database.com/html/datatypes.html#other_type
> http://www.h2database.com/html/datatypes.html#varchar_ignorecase_type
> http://www.h2database.com/html/datatypes.html#blob_type
> http://www.h2database.com/html/datatypes.html#clob_type
> http://www.h2database.com/html/datatypes.html#array_type
> http://www.h2database.com/html/datatypes.html#enum_type



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

[jira] [Created] (IGNITE-6914) Web console: 'Export All' for scan stucks in Chrome but successfully finish in FireFox

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-6914:
--

 Summary: Web console: 'Export All' for scan stucks in Chrome but 
successfully finish in FireFox
 Key: IGNITE-6914
 URL: https://issues.apache.org/jira/browse/IGNITE-6914
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
Reporter: Pavel Konstantinov


I populated a cache with 100K of data.
Then I opened Query screen and execute Scan for that cache.
Then I executed Export All - under Chrome it stuck



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

[jira] [Created] (IGNITE-6915) SQL: Failed to invoke getter method (type=class java.lang.String)

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-6915:
--

 Summary: SQL: Failed to invoke getter method (type=class 
java.lang.String)
 Key: IGNITE-6915
 URL: https://issues.apache.org/jira/browse/IGNITE-6915
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
Reporter: Pavel Konstantinov


{code}
Caused by: org.h2.jdbc.JdbcSQLException: ┬эєЄЁхээ   ю°шсър: "class 
org.apache.ignite.IgniteCheckedException: Failed to invoke getter method 
[type=class java.lang.String, property=firstName]"
General error: "class org.apache.ignite.IgniteCheckedException: Failed to 
invoke getter method [type=class java.lang.String, property=firstName]"; SQL 
statement:
SELECT
__Z0.FIRSTNAME __C0_0,
__Z0.LASTNAME __C0_1,
__Z0.RANK __C0_2,
__Z0.TITLE __C0_3,
__Z0.AGE __C0_4,
__Z0.SALARY __C0_5,
__Z0.ID __C0_6,
__Z0.DEPID __C0_7
FROM "c_partitioned".PERSON __Z0 [5-195]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:295)
at 
org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:348)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:236)
at org.h2.table.TableFilter.getValue(TableFilter.java:1083)
at 
org.h2.expression.ExpressionColumn.getValue(ExpressionColumn.java:186)
at org.h2.expression.Alias.getValue(Alias.java:36)
at 
org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1459)
at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
at org.h2.result.LazyResult.next(LazyResult.java:59)
at org.h2.command.dml.Select.queryFlat(Select.java:519)
at org.h2.command.dml.Select.queryWithoutCache(Select.java:625)
at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
at org.h2.command.dml.Query.query(Query.java:352)
at org.h2.command.dml.Query.query(Query.java:333)
at org.h2.command.CommandContainer.query(CommandContainer.java:113)
at org.h2.command.Command.executeQuery(Command.java:201)
at 
org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:111)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:967)
... 31 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to invoke 
getter method [type=class java.lang.String, property=firstName]
at 
org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:51)
at 
org.apache.ignite.internal.processors.query.property.QueryClassProperty.value(QueryClassProperty.java:82)
at 
org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:345)
... 47 more
Caused by: java.lang.IllegalArgumentException: object is not an instance of 
declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:48)
... 49 more
{code}



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

[jira] [Updated] (IGNITE-6915) SQL: Failed to invoke getter method (type=class java.lang.String)

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-6915:
---
Description: 
cluster configuration:
- 2 server nodes (one with a load)
- cache populated with data

Executed ' select * from "cache".Person '

!screenshot-1.png!
{code}
Caused by: org.h2.jdbc.JdbcSQLException: ┬эєЄЁхээ   ю°шсър: "class 
org.apache.ignite.IgniteCheckedException: Failed to invoke getter method 
[type=class java.lang.String, property=firstName]"
General error: "class org.apache.ignite.IgniteCheckedException: Failed to 
invoke getter method [type=class java.lang.String, property=firstName]"; SQL 
statement:
SELECT
__Z0.FIRSTNAME __C0_0,
__Z0.LASTNAME __C0_1,
__Z0.RANK __C0_2,
__Z0.TITLE __C0_3,
__Z0.AGE __C0_4,
__Z0.SALARY __C0_5,
__Z0.ID __C0_6,
__Z0.DEPID __C0_7
FROM "c_partitioned".PERSON __Z0 [5-195]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:295)
at 
org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:348)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:236)
at org.h2.table.TableFilter.getValue(TableFilter.java:1083)
at 
org.h2.expression.ExpressionColumn.getValue(ExpressionColumn.java:186)
at org.h2.expression.Alias.getValue(Alias.java:36)
at 
org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1459)
at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
at org.h2.result.LazyResult.next(LazyResult.java:59)
at org.h2.command.dml.Select.queryFlat(Select.java:519)
at org.h2.command.dml.Select.queryWithoutCache(Select.java:625)
at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
at org.h2.command.dml.Query.query(Query.java:352)
at org.h2.command.dml.Query.query(Query.java:333)
at org.h2.command.CommandContainer.query(CommandContainer.java:113)
at org.h2.command.Command.executeQuery(Command.java:201)
at 
org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:111)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:967)
... 31 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to invoke 
getter method [type=class java.lang.String, property=firstName]
at 
org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:51)
at 
org.apache.ignite.internal.processors.query.property.QueryClassProperty.value(QueryClassProperty.java:82)
at 
org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:345)
... 47 more
Caused by: java.lang.IllegalArgumentException: object is not an instance of 
declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:48)
... 49 more
{code}

  was:
cluster configuration:
- 2 server nodes (one with a load)
- cache populated with data

Executed ' select * from "cache".Person '
{code}
Caused by: org.h2.jdbc.JdbcSQLException: ┬эєЄЁхээ   ю°шсър: "class 
org.apache.ignite.IgniteCheckedException: Failed to invoke getter method 
[type=class java.lang.String, property=firstName]"
General error: "class org.apache.ignite.IgniteCheckedException: Failed to 
invoke getter method [type=class java.lang.String, property=firstName]"; SQL 
statement:
SELECT
__Z0.FIRSTNAME __C0_0,
__Z0.LASTNAME __C0_1,
__Z0.RANK __C0_2,
__Z0.TITLE __C0_3,
__Z0.AGE __C0_4,
__Z0.SALARY __C0_5,
__Z0.ID __C0_6,
__Z0.DEPID __C0_7
FROM "c_partitioned".PERSON __Z0 [5-195]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:295)
at 
org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:348)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:236)
at org.h2.table.TableFilter.getValue(TableFilter.java:1083)
at 
org.h2.expression.ExpressionColumn.getValue(ExpressionColumn.java:186)
at 

[jira] [Updated] (IGNITE-6915) SQL: Failed to invoke getter method (type=class java.lang.String)

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-6915:
---
Description: 
cluster configuration:
- 2 server nodes (one with a load)
- cache populated with data

Executed ' select * from "cache".Person '
{code}
Caused by: org.h2.jdbc.JdbcSQLException: ┬эєЄЁхээ   ю°шсър: "class 
org.apache.ignite.IgniteCheckedException: Failed to invoke getter method 
[type=class java.lang.String, property=firstName]"
General error: "class org.apache.ignite.IgniteCheckedException: Failed to 
invoke getter method [type=class java.lang.String, property=firstName]"; SQL 
statement:
SELECT
__Z0.FIRSTNAME __C0_0,
__Z0.LASTNAME __C0_1,
__Z0.RANK __C0_2,
__Z0.TITLE __C0_3,
__Z0.AGE __C0_4,
__Z0.SALARY __C0_5,
__Z0.ID __C0_6,
__Z0.DEPID __C0_7
FROM "c_partitioned".PERSON __Z0 [5-195]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:295)
at 
org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:348)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:236)
at org.h2.table.TableFilter.getValue(TableFilter.java:1083)
at 
org.h2.expression.ExpressionColumn.getValue(ExpressionColumn.java:186)
at org.h2.expression.Alias.getValue(Alias.java:36)
at 
org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1459)
at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
at org.h2.result.LazyResult.next(LazyResult.java:59)
at org.h2.command.dml.Select.queryFlat(Select.java:519)
at org.h2.command.dml.Select.queryWithoutCache(Select.java:625)
at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
at org.h2.command.dml.Query.query(Query.java:352)
at org.h2.command.dml.Query.query(Query.java:333)
at org.h2.command.CommandContainer.query(CommandContainer.java:113)
at org.h2.command.Command.executeQuery(Command.java:201)
at 
org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:111)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:967)
... 31 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to invoke 
getter method [type=class java.lang.String, property=firstName]
at 
org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:51)
at 
org.apache.ignite.internal.processors.query.property.QueryClassProperty.value(QueryClassProperty.java:82)
at 
org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:345)
... 47 more
Caused by: java.lang.IllegalArgumentException: object is not an instance of 
declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:48)
... 49 more
{code}
!screenshot-1.png!

  was:
cluster configuration:
- 2 server nodes (one with a load)
- cache populated with data
{code}
Caused by: org.h2.jdbc.JdbcSQLException: ┬эєЄЁхээ   ю°шсър: "class 
org.apache.ignite.IgniteCheckedException: Failed to invoke getter method 
[type=class java.lang.String, property=firstName]"
General error: "class org.apache.ignite.IgniteCheckedException: Failed to 
invoke getter method [type=class java.lang.String, property=firstName]"; SQL 
statement:
SELECT
__Z0.FIRSTNAME __C0_0,
__Z0.LASTNAME __C0_1,
__Z0.RANK __C0_2,
__Z0.TITLE __C0_3,
__Z0.AGE __C0_4,
__Z0.SALARY __C0_5,
__Z0.ID __C0_6,
__Z0.DEPID __C0_7
FROM "c_partitioned".PERSON __Z0 [5-195]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:295)
at 
org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:348)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:236)
at org.h2.table.TableFilter.getValue(TableFilter.java:1083)
at 
org.h2.expression.ExpressionColumn.getValue(ExpressionColumn.java:186)
at org.h2.expression.Alias.getValue(Alias.java:36)
at 

[jira] [Assigned] (IGNITE-6859) Web console: does not work in IE11

[Ilya Borisov (JIRA)]

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

Ilya Borisov reassigned IGNITE-6859:


Assignee: Pavel Konstantinov  (was: Ilya Borisov)

I've fixed base64 encoding issue in IE11, please check it now. You'll have to 
build a new web agent.

> Web console: does not work in IE11
> --
>
> Key: IGNITE-6859
> URL: https://issues.apache.org/jira/browse/IGNITE-6859
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: wizards
> Environment: WIndows 10, IE11
>Reporter: Ilya Borisov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
> Attachments: screenshot-1.png
>
>
> *What happens:*
> Web console does not work in IE11 at all, it gets stuck at loading screen 
> indefinitely and logs an error into console.
> *Expected behavior:*
> Web console should work in IE11.



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

[jira] [Updated] (IGNITE-6915) SQL: Failed to invoke getter method (type=class java.lang.String)

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-6915:
---
Attachment: export-query-Query123-all.csv

> SQL: Failed to invoke getter method (type=class java.lang.String)
> -
>
> Key: IGNITE-6915
> URL: https://issues.apache.org/jira/browse/IGNITE-6915
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Pavel Konstantinov
> Attachments: export-query-Query123-all.csv, screenshot-1.png
>
>
> cluster configuration:
> - 2 server nodes (one with a load)
> - cache populated with data
> Executed ' select * from "cache".Person '
> !screenshot-1.png!
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: ┬эєЄЁхээ   ю°шсър: "class 
> org.apache.ignite.IgniteCheckedException: Failed to invoke getter method 
> [type=class java.lang.String, property=firstName]"
> General error: "class org.apache.ignite.IgniteCheckedException: Failed to 
> invoke getter method [type=class java.lang.String, property=firstName]"; SQL 
> statement:
> SELECT
> __Z0.FIRSTNAME __C0_0,
> __Z0.LASTNAME __C0_1,
> __Z0.RANK __C0_2,
> __Z0.TITLE __C0_3,
> __Z0.AGE __C0_4,
> __Z0.SALARY __C0_5,
> __Z0.ID __C0_6,
> __Z0.DEPID __C0_7
> FROM "c_partitioned".PERSON __Z0 [5-195]
> at 
> org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:295)
> at 
> org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:348)
> at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:236)
> at org.h2.table.TableFilter.getValue(TableFilter.java:1083)
> at 
> org.h2.expression.ExpressionColumn.getValue(ExpressionColumn.java:186)
> at org.h2.expression.Alias.getValue(Alias.java:36)
> at 
> org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1459)
> at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
> at org.h2.result.LazyResult.next(LazyResult.java:59)
> at org.h2.command.dml.Select.queryFlat(Select.java:519)
> at org.h2.command.dml.Select.queryWithoutCache(Select.java:625)
> at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
> at org.h2.command.dml.Query.query(Query.java:352)
> at org.h2.command.dml.Query.query(Query.java:333)
> at org.h2.command.CommandContainer.query(CommandContainer.java:113)
> at org.h2.command.Command.executeQuery(Command.java:201)
> at 
> org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:111)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:967)
> ... 31 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to invoke 
> getter method [type=class java.lang.String, property=firstName]
> at 
> org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:51)
> at 
> org.apache.ignite.internal.processors.query.property.QueryClassProperty.value(QueryClassProperty.java:82)
> at 
> org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:345)
> ... 47 more
> Caused by: java.lang.IllegalArgumentException: object is not an instance of 
> declaring class
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:48)
> ... 49 more
> {code}



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

[jira] [Commented] (IGNITE-6915) SQL: Failed to invoke getter method (type=class java.lang.String)

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-6915:


Attached CSV file from previous workable version

> SQL: Failed to invoke getter method (type=class java.lang.String)
> -
>
> Key: IGNITE-6915
> URL: https://issues.apache.org/jira/browse/IGNITE-6915
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Pavel Konstantinov
> Attachments: export-query-Query123-all.csv, screenshot-1.png
>
>
> cluster configuration:
> - 2 server nodes (one with a load)
> - cache populated with data
> Executed ' select * from "cache".Person '
> !screenshot-1.png!
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: ┬эєЄЁхээ   ю°шсър: "class 
> org.apache.ignite.IgniteCheckedException: Failed to invoke getter method 
> [type=class java.lang.String, property=firstName]"
> General error: "class org.apache.ignite.IgniteCheckedException: Failed to 
> invoke getter method [type=class java.lang.String, property=firstName]"; SQL 
> statement:
> SELECT
> __Z0.FIRSTNAME __C0_0,
> __Z0.LASTNAME __C0_1,
> __Z0.RANK __C0_2,
> __Z0.TITLE __C0_3,
> __Z0.AGE __C0_4,
> __Z0.SALARY __C0_5,
> __Z0.ID __C0_6,
> __Z0.DEPID __C0_7
> FROM "c_partitioned".PERSON __Z0 [5-195]
> at 
> org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:295)
> at 
> org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:348)
> at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:236)
> at org.h2.table.TableFilter.getValue(TableFilter.java:1083)
> at 
> org.h2.expression.ExpressionColumn.getValue(ExpressionColumn.java:186)
> at org.h2.expression.Alias.getValue(Alias.java:36)
> at 
> org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1459)
> at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
> at org.h2.result.LazyResult.next(LazyResult.java:59)
> at org.h2.command.dml.Select.queryFlat(Select.java:519)
> at org.h2.command.dml.Select.queryWithoutCache(Select.java:625)
> at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
> at org.h2.command.dml.Query.query(Query.java:352)
> at org.h2.command.dml.Query.query(Query.java:333)
> at org.h2.command.CommandContainer.query(CommandContainer.java:113)
> at org.h2.command.Command.executeQuery(Command.java:201)
> at 
> org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:111)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:967)
> ... 31 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to invoke 
> getter method [type=class java.lang.String, property=firstName]
> at 
> org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:51)
> at 
> org.apache.ignite.internal.processors.query.property.QueryClassProperty.value(QueryClassProperty.java:82)
> at 
> org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:345)
> ... 47 more
> Caused by: java.lang.IllegalArgumentException: object is not an instance of 
> declaring class
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:48)
> ... 49 more
> {code}



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

[jira] [Updated] (IGNITE-6913) Add support for baseline manipulations to controls.sh

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-6913:
-
Description: 
This is a ticket to make required changes baseline topology introduced in 
Ignite:
[https://issues.apache.org/jira/browse/IGNITE-6310] 

We can reuse control.sh script, and add few new commands.

# Print current baseline: `./control.sh --baseline`
# Add nodes to baseline: `./control.sh --baseline add 
constId1[,constid2,,constidN]`
# Remove nodes from baseline: ./control.sh --baseline remove 
constid1[,constid2,,constidN]
# Set baseline: `./control.sh --baseline set constid1[,constid2,,constidN]
# Set baseline for version: `./control.sh --baseline version topVersion`



  was:
This is a ticket to make required changes baseline topology introduced in 
Ignite:
[https://issues.apache.org/jira/browse/IGNITE-5849] 

We can reuse control.sh script, and add few new commands.

# Print current baseline: `./control.sh --baseline`
# Add nodes to baseline: `./control.sh --baseline add 
constId1[,constid2,,constidN]`
# Remove nodes from baseline: ./control.sh --baseline remove 
constid1[,constid2,,constidN]
# Set baseline: `./control.sh --baseline set constid1[,constid2,,constidN]
# Set baseline for version: `./control.sh --baseline version topVersion`




> Add support for baseline manipulations to controls.sh
> -
>
> Key: IGNITE-6913
> URL: https://issues.apache.org/jira/browse/IGNITE-6913
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.4
>
>
> This is a ticket to make required changes baseline topology introduced in 
> Ignite:
> [https://issues.apache.org/jira/browse/IGNITE-6310] 
> We can reuse control.sh script, and add few new commands.
> # Print current baseline: `./control.sh --baseline`
> # Add nodes to baseline: `./control.sh --baseline add 
> constId1[,constid2,,constidN]`
> # Remove nodes from baseline: ./control.sh --baseline remove 
> constid1[,constid2,,constidN]
> # Set baseline: `./control.sh --baseline set constid1[,constid2,,constidN]
> # Set baseline for version: `./control.sh --baseline version topVersion`



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

[jira] [Assigned] (IGNITE-6618) Web console: Do not show client nodes in node selection modal

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-6618:
-

Assignee: Pavel Konstantinov  (was: Alexander Kalinin)

Excluded client nodes from selection modal. Please test.

> Web console: Do not show client nodes in node selection modal
> -
>
> Key: IGNITE-6618
> URL: https://issues.apache.org/jira/browse/IGNITE-6618
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> I tried to 'Execute on Selected Node' the following query
> {code}
> SELECT c.id, d.id, p.id, p.salary 
> FROM "c_partitioned".City c
> inner join "c_partitioned".Department d
> on c.id=d.CTYID 
> inner join "c_partitioned".Person p
> on d.id=p.depID and p.salary > 5000
> inner join "c_partitioned".PersonBonus pb
> on p.id=pb.perID and pb.COUNT  < 5000
> where exists (select * from "c_partitioned".Person where rank > 0)
> {code}
> and selected a client node in the list of nodes
> and got exception
> {code}
> General error: "java.lang.NullPointerException"; SQL statement: SELECT c.id, 
> d.id, p.id, p.salary 
>  FROM "c_partitioned".City c
>  inner join "c_partitioned".Department d
>  on c.id=d.CTYID 
>  inner join "c_partitioned".Person p
>  on d.id=p.depID and p.salary > 5000
>  inner join "c_partitioned".PersonBonus pb
>  on p.id=pb.perID and pb.COUNT < 5000
>  where exists (select * from "c_partitioned".Person where rank > 0) 
> [5-195]
> {code}



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

[jira] [Assigned] (IGNITE-6914) Web console: 'Export All' for scan stucks in Chrome but successfully finish in FireFox

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-6914:
-

Assignee: Alexander Kalinin

> Web console: 'Export All' for scan stucks in Chrome but successfully finish 
> in FireFox
> --
>
> Key: IGNITE-6914
> URL: https://issues.apache.org/jira/browse/IGNITE-6914
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Pavel Konstantinov
>Assignee: Alexander Kalinin
>
> I populated a cache with 100K of data.
> Then I opened Query screen and execute Scan for that cache.
> Then I executed Export All - under Chrome it stuck



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

[jira] [Updated] (IGNITE-6915) SQL: Failed to invoke getter method (type=class java.lang.String)

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-6915:
---
Description: 
{code}
Caused by: org.h2.jdbc.JdbcSQLException: ┬эєЄЁхээ   ю°шсър: "class 
org.apache.ignite.IgniteCheckedException: Failed to invoke getter method 
[type=class java.lang.String, property=firstName]"
General error: "class org.apache.ignite.IgniteCheckedException: Failed to 
invoke getter method [type=class java.lang.String, property=firstName]"; SQL 
statement:
SELECT
__Z0.FIRSTNAME __C0_0,
__Z0.LASTNAME __C0_1,
__Z0.RANK __C0_2,
__Z0.TITLE __C0_3,
__Z0.AGE __C0_4,
__Z0.SALARY __C0_5,
__Z0.ID __C0_6,
__Z0.DEPID __C0_7
FROM "c_partitioned".PERSON __Z0 [5-195]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:295)
at 
org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:348)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:236)
at org.h2.table.TableFilter.getValue(TableFilter.java:1083)
at 
org.h2.expression.ExpressionColumn.getValue(ExpressionColumn.java:186)
at org.h2.expression.Alias.getValue(Alias.java:36)
at 
org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1459)
at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
at org.h2.result.LazyResult.next(LazyResult.java:59)
at org.h2.command.dml.Select.queryFlat(Select.java:519)
at org.h2.command.dml.Select.queryWithoutCache(Select.java:625)
at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
at org.h2.command.dml.Query.query(Query.java:352)
at org.h2.command.dml.Query.query(Query.java:333)
at org.h2.command.CommandContainer.query(CommandContainer.java:113)
at org.h2.command.Command.executeQuery(Command.java:201)
at 
org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:111)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:967)
... 31 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to invoke 
getter method [type=class java.lang.String, property=firstName]
at 
org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:51)
at 
org.apache.ignite.internal.processors.query.property.QueryClassProperty.value(QueryClassProperty.java:82)
at 
org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:345)
... 47 more
Caused by: java.lang.IllegalArgumentException: object is not an instance of 
declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:48)
... 49 more
{code}
!screenshot-1.png!

  was:
{code}
Caused by: org.h2.jdbc.JdbcSQLException: ┬эєЄЁхээ   ю°шсър: "class 
org.apache.ignite.IgniteCheckedException: Failed to invoke getter method 
[type=class java.lang.String, property=firstName]"
General error: "class org.apache.ignite.IgniteCheckedException: Failed to 
invoke getter method [type=class java.lang.String, property=firstName]"; SQL 
statement:
SELECT
__Z0.FIRSTNAME __C0_0,
__Z0.LASTNAME __C0_1,
__Z0.RANK __C0_2,
__Z0.TITLE __C0_3,
__Z0.AGE __C0_4,
__Z0.SALARY __C0_5,
__Z0.ID __C0_6,
__Z0.DEPID __C0_7
FROM "c_partitioned".PERSON __Z0 [5-195]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:295)
at 
org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:348)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:236)
at org.h2.table.TableFilter.getValue(TableFilter.java:1083)
at 
org.h2.expression.ExpressionColumn.getValue(ExpressionColumn.java:186)
at org.h2.expression.Alias.getValue(Alias.java:36)
at 
org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1459)
at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
at org.h2.result.LazyResult.next(LazyResult.java:59)
at 

[jira] [Updated] (IGNITE-6915) SQL: Failed to invoke getter method (type=class java.lang.String)

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-6915:
---
Attachment: screenshot-1.png

> SQL: Failed to invoke getter method (type=class java.lang.String)
> -
>
> Key: IGNITE-6915
> URL: https://issues.apache.org/jira/browse/IGNITE-6915
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Pavel Konstantinov
> Attachments: screenshot-1.png
>
>
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: ┬эєЄЁхээ   ю°шсър: "class 
> org.apache.ignite.IgniteCheckedException: Failed to invoke getter method 
> [type=class java.lang.String, property=firstName]"
> General error: "class org.apache.ignite.IgniteCheckedException: Failed to 
> invoke getter method [type=class java.lang.String, property=firstName]"; SQL 
> statement:
> SELECT
> __Z0.FIRSTNAME __C0_0,
> __Z0.LASTNAME __C0_1,
> __Z0.RANK __C0_2,
> __Z0.TITLE __C0_3,
> __Z0.AGE __C0_4,
> __Z0.SALARY __C0_5,
> __Z0.ID __C0_6,
> __Z0.DEPID __C0_7
> FROM "c_partitioned".PERSON __Z0 [5-195]
> at 
> org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:295)
> at 
> org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:348)
> at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:236)
> at org.h2.table.TableFilter.getValue(TableFilter.java:1083)
> at 
> org.h2.expression.ExpressionColumn.getValue(ExpressionColumn.java:186)
> at org.h2.expression.Alias.getValue(Alias.java:36)
> at 
> org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1459)
> at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
> at org.h2.result.LazyResult.next(LazyResult.java:59)
> at org.h2.command.dml.Select.queryFlat(Select.java:519)
> at org.h2.command.dml.Select.queryWithoutCache(Select.java:625)
> at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
> at org.h2.command.dml.Query.query(Query.java:352)
> at org.h2.command.dml.Query.query(Query.java:333)
> at org.h2.command.CommandContainer.query(CommandContainer.java:113)
> at org.h2.command.Command.executeQuery(Command.java:201)
> at 
> org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:111)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:967)
> ... 31 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to invoke 
> getter method [type=class java.lang.String, property=firstName]
> at 
> org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:51)
> at 
> org.apache.ignite.internal.processors.query.property.QueryClassProperty.value(QueryClassProperty.java:82)
> at 
> org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:345)
> ... 47 more
> Caused by: java.lang.IllegalArgumentException: object is not an instance of 
> declaring class
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:48)
> ... 49 more
> {code}



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

[jira] [Closed] (IGNITE-6795) Web console: Make default file name for saving scan results more informative

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-6795.
--

> Web console: Make default file name for saving scan results more informative
> 
>
> Key: IGNITE-6795
> URL: https://issues.apache.org/jira/browse/IGNITE-6795
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.4
>
>
> Currently file name is '' + '-all' in case if I want to save all 
> result set. (export all)
> I suggest to use 'scan--all'



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

[jira] [Commented] (IGNITE-6795) Web console: Make default file name for saving scan results more informative

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-6795:


Successfully tested

> Web console: Make default file name for saving scan results more informative
> 
>
> Key: IGNITE-6795
> URL: https://issues.apache.org/jira/browse/IGNITE-6795
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.4
>
>
> Currently file name is '' + '-all' in case if I want to save all 
> result set. (export all)
> I suggest to use 'scan--all'



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

[jira] [Updated] (IGNITE-6915) SQL: Failed to invoke getter method (type=class java.lang.String)

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-6915:
---
Description: 
cluster configuration:
- 2 server nodes (one with a load)
- cache populated with data
{code}
Caused by: org.h2.jdbc.JdbcSQLException: ┬эєЄЁхээ   ю°шсър: "class 
org.apache.ignite.IgniteCheckedException: Failed to invoke getter method 
[type=class java.lang.String, property=firstName]"
General error: "class org.apache.ignite.IgniteCheckedException: Failed to 
invoke getter method [type=class java.lang.String, property=firstName]"; SQL 
statement:
SELECT
__Z0.FIRSTNAME __C0_0,
__Z0.LASTNAME __C0_1,
__Z0.RANK __C0_2,
__Z0.TITLE __C0_3,
__Z0.AGE __C0_4,
__Z0.SALARY __C0_5,
__Z0.ID __C0_6,
__Z0.DEPID __C0_7
FROM "c_partitioned".PERSON __Z0 [5-195]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:295)
at 
org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:348)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:236)
at org.h2.table.TableFilter.getValue(TableFilter.java:1083)
at 
org.h2.expression.ExpressionColumn.getValue(ExpressionColumn.java:186)
at org.h2.expression.Alias.getValue(Alias.java:36)
at 
org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1459)
at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
at org.h2.result.LazyResult.next(LazyResult.java:59)
at org.h2.command.dml.Select.queryFlat(Select.java:519)
at org.h2.command.dml.Select.queryWithoutCache(Select.java:625)
at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
at org.h2.command.dml.Query.query(Query.java:352)
at org.h2.command.dml.Query.query(Query.java:333)
at org.h2.command.CommandContainer.query(CommandContainer.java:113)
at org.h2.command.Command.executeQuery(Command.java:201)
at 
org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:111)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:967)
... 31 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to invoke 
getter method [type=class java.lang.String, property=firstName]
at 
org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:51)
at 
org.apache.ignite.internal.processors.query.property.QueryClassProperty.value(QueryClassProperty.java:82)
at 
org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:345)
... 47 more
Caused by: java.lang.IllegalArgumentException: object is not an instance of 
declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.ignite.internal.processors.query.property.QueryReadOnlyMethodsAccessor.getValue(QueryReadOnlyMethodsAccessor.java:48)
... 49 more
{code}
!screenshot-1.png!

  was:
{code}
Caused by: org.h2.jdbc.JdbcSQLException: ┬эєЄЁхээ   ю°шсър: "class 
org.apache.ignite.IgniteCheckedException: Failed to invoke getter method 
[type=class java.lang.String, property=firstName]"
General error: "class org.apache.ignite.IgniteCheckedException: Failed to 
invoke getter method [type=class java.lang.String, property=firstName]"; SQL 
statement:
SELECT
__Z0.FIRSTNAME __C0_0,
__Z0.LASTNAME __C0_1,
__Z0.RANK __C0_2,
__Z0.TITLE __C0_3,
__Z0.AGE __C0_4,
__Z0.SALARY __C0_5,
__Z0.ID __C0_6,
__Z0.DEPID __C0_7
FROM "c_partitioned".PERSON __Z0 [5-195]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:295)
at 
org.apache.ignite.internal.processors.query.h2.H2RowDescriptor.columnValue(H2RowDescriptor.java:348)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:236)
at org.h2.table.TableFilter.getValue(TableFilter.java:1083)
at 
org.h2.expression.ExpressionColumn.getValue(ExpressionColumn.java:186)
at org.h2.expression.Alias.getValue(Alias.java:36)
at 
org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1459)
at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
 

[jira] [Commented] (IGNITE-6835) ODBC driver should handle ungraceful tcp disconnects

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-6835:
-

[~skalashnikov], good catch, fixed.

> ODBC driver should handle ungraceful tcp disconnects
> 
>
> Key: IGNITE-6835
> URL: https://issues.apache.org/jira/browse/IGNITE-6835
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 2.4
>
>
> It is found that ungraceful TCP disconnect makes ODBC driver stuck at socket 
> recv().
> Ungraceful TCP disconnect could be caused:
> 1. Network failure (or new firewall rules)
> 2. Remote party shutdown (Half Closed Connection)
> So, the proposal is:
> setup socket  options: 
> 1) SO_KEEPALIVE enabled
> 2) TCP_KEEPIDLE to 60 sec. It is 2 hour by default
> 3) TCP_KEEPINTVL to 5 (\?) sec. It is 1 sec at Win and 75 sec at Linux by 
> default.
> 4) send/receive buffers to some greater value (8k by default)



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

[jira] [Commented] (IGNITE-6071) Client may detect necessity for reconnect for too long

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6071:


Github user alamar closed the pull request at:

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


> Client may detect necessity for reconnect for too long
> --
>
> Key: IGNITE-6071
> URL: https://issues.apache.org/jira/browse/IGNITE-6071
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Yakov Zhdanov
>Assignee: Ilya Kasnacheev
>
> There was a GC pause on client that caused servers to drop client due to 
> inability to establish TCP communication connection. Then it took some time 
> for client to detect that it has been dropped. During that time client many 
> times attempted to connect to server which can be seen in the logs. After 
> client detected its drop and reconnected servers fired node added event and 
> no log flood can be found any more.
> We need to find out why client was reconnecting via communication and did not 
> detect the drop for such a long time.
> I hope this can be reproduced in test:
> * start 2 servers
> * start client
> * suspend all client threads with Thread.suspend() - just filter threads of 
> current JVM by name and suspend ones belonging to the client.
> {noformat}
> [10:12:24,785][WARNING][disco-event-worker-#71%null%][GridDiscoveryManager] 
> Node FAILED: TcpDiscoveryNode [id=dd71479c-41ba-443e-b25c-3803a2a94f4f, 
> addrs=[10.44.3.14, 127.0.0.1], sockAddrs=[/127.0.0.1:0, 
> XXX.com/10.44.3.14:0], discPort=0, order=2, intOrder=2, 
> lastExchangeTime=1502269008673, loc=false, ver=2.1.1#20170618-sha1:09ce29e0, 
> isClient=true]
> [10:12:24,785][INFO][disco-event-worker-#71%null%][GridDiscoveryManager] 
> Topology snapshot [ver=5, servers=2, clients=1, CPUs=144, heap=76.0GB]
> [10:12:24,794][INFO][exchange-worker-#72%null%][time] Started exchange init 
> [topVer=AffinityTopologyVersion [topVer=5, minorTopVer=0], crd=false, evt=12, 
> node=TcpDiscoveryNode [id=98c1fdf7-09db-4fa0-bb01-8ca7f046643d, 
> addrs=[10.44.3.11, 127.0.0.1], sockAddrs=[/127.0.0.1:47500, 
> XXX.com/10.44.3.11:47500], discPort=47500, order=3, intOrder=3, 
> lastExchangeTime=1502269944782, loc=true, ver=2.1.1#20170618-sha1:09ce29e0, 
> isClient=false], evtNode=TcpDiscoveryNode 
> [id=98c1fdf7-09db-4fa0-bb01-8ca7f046643d, addrs=[10.44.3.11, 127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500, XXX.com/10.44.3.11:47500], discPort=47500, 
> order=3, intOrder=3, lastExchangeTime=1502269944782, loc=true, 
> ver=2.1.1#20170618-sha1:09ce29e0, isClient=false], customEvt=null]
> [10:12:24,813][INFO][exchange-worker-#72%null%][time] Finished exchange init 
> [topVer=AffinityTopologyVersion [topVer=5, minorTopVer=0], crd=false]
> [10:12:24,819][INFO][exchange-worker-#72%null%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=5, minorTopVer=0], evt=NODE_FAILED, 
> node=dd71479c-41ba-443e-b25c-3803a2a94f4f]
> [10:12:28,344][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52474]
> [10:12:28,348][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52482]
> [10:12:28,356][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52506]
> [10:12:28,362][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52522]
> [10:12:28,368][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52538]
> [10:12:28,374][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52554]
> [10:12:28,380][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52570]
> [10:12:28,386][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52586]
> [10:12:28,392][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52602]
> [10:12:28,397][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection 

[jira] [Commented] (IGNITE-6071) Client may detect necessity for reconnect for too long

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6071:


Github user alamar closed the pull request at:

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


> Client may detect necessity for reconnect for too long
> --
>
> Key: IGNITE-6071
> URL: https://issues.apache.org/jira/browse/IGNITE-6071
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Yakov Zhdanov
>Assignee: Ilya Kasnacheev
>
> There was a GC pause on client that caused servers to drop client due to 
> inability to establish TCP communication connection. Then it took some time 
> for client to detect that it has been dropped. During that time client many 
> times attempted to connect to server which can be seen in the logs. After 
> client detected its drop and reconnected servers fired node added event and 
> no log flood can be found any more.
> We need to find out why client was reconnecting via communication and did not 
> detect the drop for such a long time.
> I hope this can be reproduced in test:
> * start 2 servers
> * start client
> * suspend all client threads with Thread.suspend() - just filter threads of 
> current JVM by name and suspend ones belonging to the client.
> {noformat}
> [10:12:24,785][WARNING][disco-event-worker-#71%null%][GridDiscoveryManager] 
> Node FAILED: TcpDiscoveryNode [id=dd71479c-41ba-443e-b25c-3803a2a94f4f, 
> addrs=[10.44.3.14, 127.0.0.1], sockAddrs=[/127.0.0.1:0, 
> XXX.com/10.44.3.14:0], discPort=0, order=2, intOrder=2, 
> lastExchangeTime=1502269008673, loc=false, ver=2.1.1#20170618-sha1:09ce29e0, 
> isClient=true]
> [10:12:24,785][INFO][disco-event-worker-#71%null%][GridDiscoveryManager] 
> Topology snapshot [ver=5, servers=2, clients=1, CPUs=144, heap=76.0GB]
> [10:12:24,794][INFO][exchange-worker-#72%null%][time] Started exchange init 
> [topVer=AffinityTopologyVersion [topVer=5, minorTopVer=0], crd=false, evt=12, 
> node=TcpDiscoveryNode [id=98c1fdf7-09db-4fa0-bb01-8ca7f046643d, 
> addrs=[10.44.3.11, 127.0.0.1], sockAddrs=[/127.0.0.1:47500, 
> XXX.com/10.44.3.11:47500], discPort=47500, order=3, intOrder=3, 
> lastExchangeTime=1502269944782, loc=true, ver=2.1.1#20170618-sha1:09ce29e0, 
> isClient=false], evtNode=TcpDiscoveryNode 
> [id=98c1fdf7-09db-4fa0-bb01-8ca7f046643d, addrs=[10.44.3.11, 127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500, XXX.com/10.44.3.11:47500], discPort=47500, 
> order=3, intOrder=3, lastExchangeTime=1502269944782, loc=true, 
> ver=2.1.1#20170618-sha1:09ce29e0, isClient=false], customEvt=null]
> [10:12:24,813][INFO][exchange-worker-#72%null%][time] Finished exchange init 
> [topVer=AffinityTopologyVersion [topVer=5, minorTopVer=0], crd=false]
> [10:12:24,819][INFO][exchange-worker-#72%null%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=5, minorTopVer=0], evt=NODE_FAILED, 
> node=dd71479c-41ba-443e-b25c-3803a2a94f4f]
> [10:12:28,344][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52474]
> [10:12:28,348][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52482]
> [10:12:28,356][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52506]
> [10:12:28,362][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52522]
> [10:12:28,368][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52538]
> [10:12:28,374][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52554]
> [10:12:28,380][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52570]
> [10:12:28,386][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52586]
> [10:12:28,392][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52602]
> [10:12:28,397][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection 

[jira] [Commented] (IGNITE-6071) Client may detect necessity for reconnect for too long

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6071:


Github user alamar closed the pull request at:

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


> Client may detect necessity for reconnect for too long
> --
>
> Key: IGNITE-6071
> URL: https://issues.apache.org/jira/browse/IGNITE-6071
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Yakov Zhdanov
>Assignee: Ilya Kasnacheev
>
> There was a GC pause on client that caused servers to drop client due to 
> inability to establish TCP communication connection. Then it took some time 
> for client to detect that it has been dropped. During that time client many 
> times attempted to connect to server which can be seen in the logs. After 
> client detected its drop and reconnected servers fired node added event and 
> no log flood can be found any more.
> We need to find out why client was reconnecting via communication and did not 
> detect the drop for such a long time.
> I hope this can be reproduced in test:
> * start 2 servers
> * start client
> * suspend all client threads with Thread.suspend() - just filter threads of 
> current JVM by name and suspend ones belonging to the client.
> {noformat}
> [10:12:24,785][WARNING][disco-event-worker-#71%null%][GridDiscoveryManager] 
> Node FAILED: TcpDiscoveryNode [id=dd71479c-41ba-443e-b25c-3803a2a94f4f, 
> addrs=[10.44.3.14, 127.0.0.1], sockAddrs=[/127.0.0.1:0, 
> XXX.com/10.44.3.14:0], discPort=0, order=2, intOrder=2, 
> lastExchangeTime=1502269008673, loc=false, ver=2.1.1#20170618-sha1:09ce29e0, 
> isClient=true]
> [10:12:24,785][INFO][disco-event-worker-#71%null%][GridDiscoveryManager] 
> Topology snapshot [ver=5, servers=2, clients=1, CPUs=144, heap=76.0GB]
> [10:12:24,794][INFO][exchange-worker-#72%null%][time] Started exchange init 
> [topVer=AffinityTopologyVersion [topVer=5, minorTopVer=0], crd=false, evt=12, 
> node=TcpDiscoveryNode [id=98c1fdf7-09db-4fa0-bb01-8ca7f046643d, 
> addrs=[10.44.3.11, 127.0.0.1], sockAddrs=[/127.0.0.1:47500, 
> XXX.com/10.44.3.11:47500], discPort=47500, order=3, intOrder=3, 
> lastExchangeTime=1502269944782, loc=true, ver=2.1.1#20170618-sha1:09ce29e0, 
> isClient=false], evtNode=TcpDiscoveryNode 
> [id=98c1fdf7-09db-4fa0-bb01-8ca7f046643d, addrs=[10.44.3.11, 127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500, XXX.com/10.44.3.11:47500], discPort=47500, 
> order=3, intOrder=3, lastExchangeTime=1502269944782, loc=true, 
> ver=2.1.1#20170618-sha1:09ce29e0, isClient=false], customEvt=null]
> [10:12:24,813][INFO][exchange-worker-#72%null%][time] Finished exchange init 
> [topVer=AffinityTopologyVersion [topVer=5, minorTopVer=0], crd=false]
> [10:12:24,819][INFO][exchange-worker-#72%null%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=5, minorTopVer=0], evt=NODE_FAILED, 
> node=dd71479c-41ba-443e-b25c-3803a2a94f4f]
> [10:12:28,344][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52474]
> [10:12:28,348][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52482]
> [10:12:28,356][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52506]
> [10:12:28,362][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52522]
> [10:12:28,368][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52538]
> [10:12:28,374][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52554]
> [10:12:28,380][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52570]
> [10:12:28,386][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52586]
> [10:12:28,392][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52602]
> [10:12:28,397][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection 

[jira] [Resolved] (IGNITE-6901) IgniteH2Indexing#rebuildIndexesFromHash should pass old value to indexing engine

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-6901.
-
Resolution: Fixed

> IgniteH2Indexing#rebuildIndexesFromHash should pass old value to indexing 
> engine
> 
>
> Key: IGNITE-6901
> URL: https://issues.apache.org/jira/browse/IGNITE-6901
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: cache, persistence, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexey Goncharuk
> Fix For: 2.4
>
>
> When index rebuild is triggered, index is updated from the method 
> {{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl.updateIndexes}}. Notice 
> how we always pass {{null}} as previous row value. It breaks recent 
> optimization which use previous value to avoid old row materialization 
> IGNITE-6701, so assertion like this is observed:
> {code}
> java.lang.AssertionError: Replaced: true
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:451)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:581)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1748)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:406)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:1375)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateIndexes(GridCacheOffheapManager.java:1242)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:364)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.ensureIndexed(GridCacheMapEntry.java:3149)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.rebuildIndexesFromHash(IgniteH2Indexing.java:2030)
> {code}



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

[jira] [Assigned] (IGNITE-6901) IgniteH2Indexing#rebuildIndexesFromHash should pass old value to indexing engine

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-6901:
---

Assignee: Vladimir Ozerov  (was: Alexey Goncharuk)

> IgniteH2Indexing#rebuildIndexesFromHash should pass old value to indexing 
> engine
> 
>
> Key: IGNITE-6901
> URL: https://issues.apache.org/jira/browse/IGNITE-6901
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: cache, persistence, sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> When index rebuild is triggered, index is updated from the method 
> {{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl.updateIndexes}}. Notice 
> how we always pass {{null}} as previous row value. It breaks recent 
> optimization which use previous value to avoid old row materialization 
> IGNITE-6701, so assertion like this is observed:
> {code}
> java.lang.AssertionError: Replaced: true
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:451)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:581)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1748)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:406)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:1375)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateIndexes(GridCacheOffheapManager.java:1242)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:364)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.ensureIndexed(GridCacheMapEntry.java:3149)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.rebuildIndexesFromHash(IgniteH2Indexing.java:2030)
> {code}



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

[jira] [Commented] (IGNITE-5343) .NET: Interoperate with JVM directly, get rid of C++ layer

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-5343:
--

[~ptupitsyn], looks good for me

> .NET: Interoperate with JVM directly, get rid of C++ layer
> --
>
> Key: IGNITE-5343
> URL: https://issues.apache.org/jira/browse/IGNITE-5343
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, xplat
>
> We can work with JNI directly using P/Invoke, there is no real need for C++ 
> layer.
> Advantages of removing C++ layer:
> * *No MSVC++ 2010 dependency*
> * *No build tools required for development*
> * Simplify and speed up the build procedure
> * No embedded libraries
> * Easier crossplatform support (IGNITE-2662)



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

[jira] [Updated] (IGNITE-6893) Provide metric to monitor Java Deadlocks

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6893:
-
Labels: iep-7  (was: )

> Provide metric to monitor Java Deadlocks 
> -
>
> Key: IGNITE-6893
> URL: https://issues.apache.org/jira/browse/IGNITE-6893
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Anton Vinogradov
>  Labels: iep-7
>




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

[jira] [Updated] (IGNITE-6894) Provide metric to monitor Internal threads stuck

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6894:
-
Labels: iep-7  (was: )

> Provide metric to monitor Internal threads stuck
> 
>
> Key: IGNITE-6894
> URL: https://issues.apache.org/jira/browse/IGNITE-6894
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Anton Vinogradov
>  Labels: iep-7
>




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

[jira] [Updated] (IGNITE-5811) Detect internal Ignite problems (java-level deadlock, hangs, etc) and act according to a policy configured.

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-5811:
-
Labels: iep-7 usability  (was: usability)

> Detect internal Ignite problems (java-level deadlock, hangs, etc) and act 
> according to a policy configured.
> ---
>
> Key: IGNITE-5811
> URL: https://issues.apache.org/jira/browse/IGNITE-5811
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Yakov Zhdanov
>  Labels: iep-7, usability
>
> This has something in common with segmentation policy we currently have. User 
> should get notified on a deadlock problem and node should take an action 
> (stop by default).
> Also Ignite may react on internal errors and hangs in the same way - fire 
> event and take the appropriate action.
> Current list of cases when node should (by default) stop itself:
> # Discovery reports segmentation (already implemented)
> # Critical discovery thread fails (already implemented)
> # NIO communication thread fails (already implemented)
> The following needs to be added
> # Java-deadlock detected
> # Internal threads stuck (no progress on current tasks during defined period)
> # ExchangeWorker exits with error
> We need to reapproach handling for all situations above to use the same 
> mechanism and make node take the action according to a configured policy



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

[jira] [Updated] (IGNITE-6892) Proper behavior on OOM/IgniteOutOfMemoryException

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6892:
-
Labels: iep-7  (was: )

> Proper behavior on OOM/IgniteOutOfMemoryException
> -
>
> Key: IGNITE-6892
> URL: https://issues.apache.org/jira/browse/IGNITE-6892
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Anton Vinogradov
>  Labels: iep-7
>
> In case of any OOM node should be stopped anyway, what we can provide is user 
> callback, something like 'beforeNodeStop'.



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

[jira] [Updated] (IGNITE-6895) Provide metric to monitor any TX deadlock

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6895:
-
Labels: iep-7  (was: )

> Provide metric to monitor any TX deadlock
> -
>
> Key: IGNITE-6895
> URL: https://issues.apache.org/jira/browse/IGNITE-6895
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Anton Vinogradov
>  Labels: iep-7
>




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

[jira] [Updated] (IGNITE-6171) Native facility to control excessive GC pauses

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6171:
-
Labels: iep-7 usability  (was: usability)

> Native facility to control excessive GC pauses
> --
>
> Key: IGNITE-6171
> URL: https://issues.apache.org/jira/browse/IGNITE-6171
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Dmitriy Sorokin
>  Labels: iep-7, usability
>
> Ignite is Java-based application. If node experiences long GC pauses it may 
> negatively affect other nodes. We need to find a way to detect long GC pauses 
> within the process and trigger some actions in response, e.g. node stop. 
> This is a kind of Inception \[1\], when you need to understand that you sleep 
> while sleeping. As all Java threads are blocked on safepoint, we cannot use 
> Java's thread to detect Java's GC. Native threads should be used instead.
> Proposed solution:
> 1) Thread 1 should periodically call dummy JNI method returning current time, 
> and set this time to shared variable;
> 2) Thread 2 should periodically check that variable. If it has not been 
> changed for some time - most likely we are in GC pause. Once certain 
> threashold is reached - trigger compensating action, whether this is a 
> warning, process kill, or what so ever.
> Justification: crossing native -> Java boundaries involves safepoints. This 
> way Thread 1 will be trapped if STW pause is in progress. Java method cannot 
> be empty, as JVM is smart enough and can deduce it to no-op. 
> \[1\] http://www.imdb.com/title/tt1375666/



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

[jira] [Commented] (IGNITE-6896) .NET: support Multidimensional Arrays in binary serializer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6896:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-6896 .NET: support Multidimensional Arrays in binary serializer



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

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

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

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


commit 8735d68ec178b7593f25f1207a6362ed9ea238fc
Author: Pavel Tupitsyn 
Date:   2017-11-14T13:48:21Z

IGNITE-6896 .NET: support Multidimensional Arrays in binary serializer




> .NET: support Multidimensional Arrays in binary serializer
> --
>
> Key: IGNITE-6896
> URL: https://issues.apache.org/jira/browse/IGNITE-6896
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> It is found that legacy 2D, 3D, etc. are not working in BinarySerializer.
> Sample reproducer:
> {code:java}
> [Test]
> public void TestXX()
> {
> var array2D = new float[32, 32];
> var res = TestUtils.SerializeDeserialize(array2D);
> Assert.AreEqual(array2D, res);
> }
> {code}
> BTW, please note that 2D array in Java (a[2][2]) is just a jugged array:
> {noformat}
> obj = {byte[2][]@1928}
>  0 = {byte[2]@1974}
>  1 = {byte[2]@1975}
> {noformat}



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

[jira] [Assigned] (IGNITE-6896) .NET: support Multidimensional Arrays in binary serializer

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-6896:
--

Assignee: Alexey Popov  (was: Pavel Tupitsyn)

Fixed, [~alexey.tank2], please review.

> .NET: support Multidimensional Arrays in binary serializer
> --
>
> Key: IGNITE-6896
> URL: https://issues.apache.org/jira/browse/IGNITE-6896
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>  Labels: .NET
> Fix For: 2.4
>
>
> It is found that legacy 2D, 3D, etc. are not working in BinarySerializer.
> Sample reproducer:
> {code:java}
> [Test]
> public void TestXX()
> {
> var array2D = new float[32, 32];
> var res = TestUtils.SerializeDeserialize(array2D);
> Assert.AreEqual(array2D, res);
> }
> {code}
> BTW, please note that 2D array in Java (a[2][2]) is just a jugged array:
> {noformat}
> obj = {byte[2][]@1928}
>  0 = {byte[2]@1974}
>  1 = {byte[2]@1975}
> {noformat}



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

[jira] [Commented] (IGNITE-6337) .NET: Thin client: SQL queries

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6337:


[~tledkov-gridgain] please have a look as well. I tried to make the request 
format similar to that in JDBC (however, there are extra flags), so that we 
have a more uniform protocol.

> .NET: Thin client: SQL queries
> --
>
> Key: IGNITE-6337
> URL: https://issues.apache.org/jira/browse/IGNITE-6337
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> SQL and Fields queries in thin client.



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

[jira] [Commented] (IGNITE-6836) ODBC: Add support for SQL_ATTR_QUERY_TIMEOUT

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-6836:
-

[~skalashnikov], added test.

> ODBC: Add support for SQL_ATTR_QUERY_TIMEOUT
> 
>
> Key: IGNITE-6836
> URL: https://issues.apache.org/jira/browse/IGNITE-6836
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Igor Sapego
> Fix For: 2.4
>
>
> It would be great if we can support {{SQL_ATTR_QUERY_TIMEOUT}} at ODBC.
> That gives a flexibility to end-user code to handle long-running/timeouted 
> queries.



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

[jira] [Comment Edited] (IGNITE-6337) .NET: Thin client: SQL queries

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-6337 at 11/14/17 1:33 PM:


[~ptupitsyn], the changes is OK with me. But please remove braces for one-liner 
statements according with [Ignite code 
style|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-BracesandIdentation].

I have some comments about client protocol unification (merge ODBC, JDBC & .NET 
cli protocols)
- ODBC & JDBC use internal query API because:
-- {{schema}} name is used instead of cache ID;
-- queries that contains multiple statements are supported;
- JDBC use lazy read the query result metadata, ODBC and .NET client include 
metadata into QueryResponce and haven't request to gather metadata for opened 
cursor.


If we really need to merge the client protocol of the ODBC, JDBC & .NET clients 
i propose to file separate umbrella ticket to track this activity.


was (Author: tledkov-gridgain):
[~ptupitsyn], the changes is OK with me. 
I have some comments about client protocol unification (merge ODBC, JDBC & .NET 
cli protocols)
- ODBC & JDBC use internal query API because:
-- {{schema}} name is used instead of cache ID;
-- queries that contains multiple statements are supported;
- JDBC use lazy read the query result metadata, ODBC and .NET client include 
metadata into QueryResponce and haven't request to gather metadata for opened 
cursor.

If we really need to merge the client protocol of the ODBC, JDBC & .NET clients 
i propose to file separate umbrella ticket to track this activity.

> .NET: Thin client: SQL queries
> --
>
> Key: IGNITE-6337
> URL: https://issues.apache.org/jira/browse/IGNITE-6337
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> SQL and Fields queries in thin client.



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

[jira] [Commented] (IGNITE-6836) ODBC: Add support for SQL_ATTR_QUERY_TIMEOUT

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-6836:


[~isapego], Thanks. I am ok with the changes.

> ODBC: Add support for SQL_ATTR_QUERY_TIMEOUT
> 
>
> Key: IGNITE-6836
> URL: https://issues.apache.org/jira/browse/IGNITE-6836
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Igor Sapego
> Fix For: 2.4
>
>
> It would be great if we can support {{SQL_ATTR_QUERY_TIMEOUT}} at ODBC.
> That gives a flexibility to end-user code to handle long-running/timeouted 
> queries.



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

[jira] [Commented] (IGNITE-6071) Client may detect necessity for reconnect for too long

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6071:


Github user alamar closed the pull request at:

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


> Client may detect necessity for reconnect for too long
> --
>
> Key: IGNITE-6071
> URL: https://issues.apache.org/jira/browse/IGNITE-6071
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Yakov Zhdanov
>Assignee: Ilya Kasnacheev
>
> There was a GC pause on client that caused servers to drop client due to 
> inability to establish TCP communication connection. Then it took some time 
> for client to detect that it has been dropped. During that time client many 
> times attempted to connect to server which can be seen in the logs. After 
> client detected its drop and reconnected servers fired node added event and 
> no log flood can be found any more.
> We need to find out why client was reconnecting via communication and did not 
> detect the drop for such a long time.
> I hope this can be reproduced in test:
> * start 2 servers
> * start client
> * suspend all client threads with Thread.suspend() - just filter threads of 
> current JVM by name and suspend ones belonging to the client.
> {noformat}
> [10:12:24,785][WARNING][disco-event-worker-#71%null%][GridDiscoveryManager] 
> Node FAILED: TcpDiscoveryNode [id=dd71479c-41ba-443e-b25c-3803a2a94f4f, 
> addrs=[10.44.3.14, 127.0.0.1], sockAddrs=[/127.0.0.1:0, 
> XXX.com/10.44.3.14:0], discPort=0, order=2, intOrder=2, 
> lastExchangeTime=1502269008673, loc=false, ver=2.1.1#20170618-sha1:09ce29e0, 
> isClient=true]
> [10:12:24,785][INFO][disco-event-worker-#71%null%][GridDiscoveryManager] 
> Topology snapshot [ver=5, servers=2, clients=1, CPUs=144, heap=76.0GB]
> [10:12:24,794][INFO][exchange-worker-#72%null%][time] Started exchange init 
> [topVer=AffinityTopologyVersion [topVer=5, minorTopVer=0], crd=false, evt=12, 
> node=TcpDiscoveryNode [id=98c1fdf7-09db-4fa0-bb01-8ca7f046643d, 
> addrs=[10.44.3.11, 127.0.0.1], sockAddrs=[/127.0.0.1:47500, 
> XXX.com/10.44.3.11:47500], discPort=47500, order=3, intOrder=3, 
> lastExchangeTime=1502269944782, loc=true, ver=2.1.1#20170618-sha1:09ce29e0, 
> isClient=false], evtNode=TcpDiscoveryNode 
> [id=98c1fdf7-09db-4fa0-bb01-8ca7f046643d, addrs=[10.44.3.11, 127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500, XXX.com/10.44.3.11:47500], discPort=47500, 
> order=3, intOrder=3, lastExchangeTime=1502269944782, loc=true, 
> ver=2.1.1#20170618-sha1:09ce29e0, isClient=false], customEvt=null]
> [10:12:24,813][INFO][exchange-worker-#72%null%][time] Finished exchange init 
> [topVer=AffinityTopologyVersion [topVer=5, minorTopVer=0], crd=false]
> [10:12:24,819][INFO][exchange-worker-#72%null%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=5, minorTopVer=0], evt=NODE_FAILED, 
> node=dd71479c-41ba-443e-b25c-3803a2a94f4f]
> [10:12:28,344][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52474]
> [10:12:28,348][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52482]
> [10:12:28,356][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52506]
> [10:12:28,362][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52522]
> [10:12:28,368][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52538]
> [10:12:28,374][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52554]
> [10:12:28,380][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52570]
> [10:12:28,386][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52586]
> [10:12:28,392][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/10.44.3.11:47100, 
> rmtAddr=/10.44.3.14:52602]
> [10:12:28,397][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
>  Accepted incoming communication connection 

[jira] [Resolved] (IGNITE-6693) Private method initBlockFor in BlockMatrixStorage works incorrect for small matricie

[Yury Babak (JIRA)]

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

Yury Babak resolved IGNITE-6693.

   Resolution: Duplicate
Fix Version/s: 2.4

> Private method initBlockFor in BlockMatrixStorage works incorrect for small 
> matricie
> 
>
> Key: IGNITE-6693
> URL: https://issues.apache.org/jira/browse/IGNITE-6693
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Yury Babak
> Fix For: 2.4
>
>
> It creates block 1*1 for matrix 1*6. It should create 1*6 block.
> Possible solution:
> # add test for this case
> # change row/cols block calculation



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

[jira] [Commented] (IGNITE-5846) Add support of distributed matrices for OLS regression.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5846:


GitHub user zaleslaw opened a pull request:

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

IGNITE-5846: Add support of distributed matrices for OLS regression



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

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

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

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


commit 2cb4f5f3da67ad077f837eeeda11baf44c101245
Author: zaleslaw 
Date:   2017-11-14T12:47:29Z

Refactored keys

commit 462719fef2364cd2aded23bb32edf4d0a53b9d7f
Author: zaleslaw 
Date:   2017-11-14T12:47:51Z

Added tests

commit c180c8c60a1b43a516cd7a045420bc1dc16adcdd
Author: zaleslaw 
Date:   2017-11-14T12:48:14Z

Added vectors

commit 39766ed0bfdb9a95118b7e0c59ec39a441307c0e
Author: zaleslaw 
Date:   2017-11-14T12:48:43Z

Refactored storages and matrices

commit b9deec6d3f71db8da45800ad8a6f0ec560a25294
Author: zaleslaw 
Date:   2017-11-14T12:49:11Z

Fixed issues with keys




> Add support of distributed matrices for OLS regression.
> ---
>
> Key: IGNITE-5846
> URL: https://issues.apache.org/jira/browse/IGNITE-5846
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
>
> Currently OSL regression works only with local matrices.



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

[jira] [Commented] (IGNITE-6835) ODBC driver should handle ungraceful tcp disconnects

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6835:


Github user asfgit closed the pull request at:

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


> ODBC driver should handle ungraceful tcp disconnects
> 
>
> Key: IGNITE-6835
> URL: https://issues.apache.org/jira/browse/IGNITE-6835
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 2.4
>
>
> It is found that ungraceful TCP disconnect makes ODBC driver stuck at socket 
> recv().
> Ungraceful TCP disconnect could be caused:
> 1. Network failure (or new firewall rules)
> 2. Remote party shutdown (Half Closed Connection)
> So, the proposal is:
> setup socket  options: 
> 1) SO_KEEPALIVE enabled
> 2) TCP_KEEPIDLE to 60 sec. It is 2 hour by default
> 3) TCP_KEEPINTVL to 5 (\?) sec. It is 1 sec at Win and 75 sec at Linux by 
> default.
> 4) send/receive buffers to some greater value (8k by default)



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

[jira] [Commented] (IGNITE-6850) SQL: integrate index inline size to CREATE INDEX syntax

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-6850:


[~kirill.shirokov]
I think that it is safe to use {{IgniteQueryErrorCode.Parsing}} code instead of 
{{UNKNOWN}} in {{tryQueryDistributedSqlFieldsNative()}}. Otherwise, looks good 
to me.

> SQL: integrate index inline size to CREATE INDEX syntax
> ---
>
> Key: IGNITE-6850
> URL: https://issues.apache.org/jira/browse/IGNITE-6850
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Kirill Shirokov
> Fix For: 2.4
>
>
> Index value inline is important optimization which used to minimize amount of 
> data page reads when doing index lookup (see {{InlineIndexHelper}}). 
> Currently the only way to set it is {{QueryIndex.inlineSize}} property, so it 
> cannot be set from SQL command. We need to integrate it to our SQL syntax 
> (see {{SqlCreateIndexCommand}}) and make sure it is propagated properly.
> Sample syntax:
> {code}
> CREATE INDEX idx ON tbl(field) INLINE_SIZE 20;
> {code}



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

[jira] [Updated] (IGNITE-6890) Proper behavior on ExchangeWorker exits with error

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6890:
-
Labels: iep-7  (was: )

> Proper behavior on ExchangeWorker exits with error 
> ---
>
> Key: IGNITE-6890
> URL: https://issues.apache.org/jira/browse/IGNITE-6890
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Anton Vinogradov
>  Labels: iep-7
>
> Node should be stopped anyway, what we can provide is user callback, 
> something like beforeNodeStop'.



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

[jira] [Commented] (IGNITE-6337) .NET: Thin client: SQL queries

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-6337:
--

[~ptupitsyn], the changes is OK with me. 
I have some comments about client protocol unification (merge ODBC, JDBC & .NET 
cli protocols)
# ODBC & JDBC use internal query API because:
  - {{schema}} name is used instead of cache ID;
  - queries that contains multiple statements are supported;
# JDBC use lazy read the query result metadata, ODBC and .NET client include 
metadata into QueryResponce and haven't request to gather metadata for opened 
cursor.

If we really need to merge the client protocol of the ODBC, JDBC & .NET clients 
i propose to file separate umbrella ticket to track this activity.

> .NET: Thin client: SQL queries
> --
>
> Key: IGNITE-6337
> URL: https://issues.apache.org/jira/browse/IGNITE-6337
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> SQL and Fields queries in thin client.



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

[jira] [Comment Edited] (IGNITE-6337) .NET: Thin client: SQL queries

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-6337 at 11/14/17 1:20 PM:


[~ptupitsyn], the changes is OK with me. 
I have some comments about client protocol unification (merge ODBC, JDBC & .NET 
cli protocols)
- ODBC & JDBC use internal query API because:
  - {{schema}} name is used instead of cache ID;
  - queries that contains multiple statements are supported;
- JDBC use lazy read the query result metadata, ODBC and .NET client include 
metadata into QueryResponce and haven't request to gather metadata for opened 
cursor.

If we really need to merge the client protocol of the ODBC, JDBC & .NET clients 
i propose to file separate umbrella ticket to track this activity.


was (Author: tledkov-gridgain):
[~ptupitsyn], the changes is OK with me. 
I have some comments about client protocol unification (merge ODBC, JDBC & .NET 
cli protocols)
# ODBC & JDBC use internal query API because:
  - {{schema}} name is used instead of cache ID;
  - queries that contains multiple statements are supported;
# JDBC use lazy read the query result metadata, ODBC and .NET client include 
metadata into QueryResponce and haven't request to gather metadata for opened 
cursor.

If we really need to merge the client protocol of the ODBC, JDBC & .NET clients 
i propose to file separate umbrella ticket to track this activity.

> .NET: Thin client: SQL queries
> --
>
> Key: IGNITE-6337
> URL: https://issues.apache.org/jira/browse/IGNITE-6337
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> SQL and Fields queries in thin client.



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

[jira] [Commented] (IGNITE-6901) IgniteH2Indexing#rebuildIndexesFromHash should pass old value to indexing engine

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6901:


Github user asfgit closed the pull request at:

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


> IgniteH2Indexing#rebuildIndexesFromHash should pass old value to indexing 
> engine
> 
>
> Key: IGNITE-6901
> URL: https://issues.apache.org/jira/browse/IGNITE-6901
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: cache, persistence, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexey Goncharuk
> Fix For: 2.4
>
>
> When index rebuild is triggered, index is updated from the method 
> {{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl.updateIndexes}}. Notice 
> how we always pass {{null}} as previous row value. It breaks recent 
> optimization which use previous value to avoid old row materialization 
> IGNITE-6701, so assertion like this is observed:
> {code}
> java.lang.AssertionError: Replaced: true
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:451)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:581)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1748)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:406)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:1375)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateIndexes(GridCacheOffheapManager.java:1242)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:364)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.ensureIndexed(GridCacheMapEntry.java:3149)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.rebuildIndexesFromHash(IgniteH2Indexing.java:2030)
> {code}



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

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

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov reassigned IGNITE-5934:


Assignee: Igor Seliverstov

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



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

[jira] [Updated] (IGNITE-6891) Proper behavior on Persistence errors

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6891:
-
Labels: iep-7  (was: )

> Proper behavior on Persistence errors 
> --
>
> Key: IGNITE-6891
> URL: https://issues.apache.org/jira/browse/IGNITE-6891
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Anton Vinogradov
>  Labels: iep-7
>
> Node should be stopped anyway, what we can provide is user callback, 
> something like beforeNodeStop'.



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

[jira] [Comment Edited] (IGNITE-6337) .NET: Thin client: SQL queries

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-6337 at 11/14/17 1:21 PM:


[~ptupitsyn], the changes is OK with me. 
I have some comments about client protocol unification (merge ODBC, JDBC & .NET 
cli protocols)
- ODBC & JDBC use internal query API because:
-- {{schema}} name is used instead of cache ID;
-- queries that contains multiple statements are supported;
- JDBC use lazy read the query result metadata, ODBC and .NET client include 
metadata into QueryResponce and haven't request to gather metadata for opened 
cursor.

If we really need to merge the client protocol of the ODBC, JDBC & .NET clients 
i propose to file separate umbrella ticket to track this activity.


was (Author: tledkov-gridgain):
[~ptupitsyn], the changes is OK with me. 
I have some comments about client protocol unification (merge ODBC, JDBC & .NET 
cli protocols)
- ODBC & JDBC use internal query API because:
  - {{schema}} name is used instead of cache ID;
  - queries that contains multiple statements are supported;
- JDBC use lazy read the query result metadata, ODBC and .NET client include 
metadata into QueryResponce and haven't request to gather metadata for opened 
cursor.

If we really need to merge the client protocol of the ODBC, JDBC & .NET clients 
i propose to file separate umbrella ticket to track this activity.

> .NET: Thin client: SQL queries
> --
>
> Key: IGNITE-6337
> URL: https://issues.apache.org/jira/browse/IGNITE-6337
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> SQL and Fields queries in thin client.



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

[jira] [Updated] (IGNITE-5343) .NET: Interoperate with JVM directly, get rid of C++ layer

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5343:
---
Fix Version/s: 2.4

> .NET: Interoperate with JVM directly, get rid of C++ layer
> --
>
> Key: IGNITE-5343
> URL: https://issues.apache.org/jira/browse/IGNITE-5343
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, xplat
> Fix For: 2.4
>
>
> We can work with JNI directly using P/Invoke, there is no real need for C++ 
> layer.
> Advantages of removing C++ layer:
> * *No MSVC++ 2010 dependency*
> * *No build tools required for development*
> * Simplify and speed up the build procedure
> * No embedded libraries
> * Easier crossplatform support (IGNITE-2662)



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

[jira] [Updated] (IGNITE-6896) .NET: support Multidimensional Arrays in binary serializer

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6896:
---
Fix Version/s: 2.4

> .NET: support Multidimensional Arrays in binary serializer
> --
>
> Key: IGNITE-6896
> URL: https://issues.apache.org/jira/browse/IGNITE-6896
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> It is found that legacy 2D, 3D, etc. are not working in BinarySerializer.
> Sample reproducer:
> {code:java}
> [Test]
> public void TestXX()
> {
> var array2D = new float[32, 32];
> var res = TestUtils.SerializeDeserialize(array2D);
> Assert.AreEqual(array2D, res);
> }
> {code}
> BTW, please note that 2D array in Java (a[2][2]) is just a jugged array:
> {noformat}
> obj = {byte[2][]@1928}
>  0 = {byte[2]@1974}
>  1 = {byte[2]@1975}
> {noformat}



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-5934 at 11/14/17 9:03 AM:
---

MVCC support for queries is mostly ready. However, several things need to be 
addressed:
1) Perform cleanup in {{MvccQueryTracker}}, so that all TODOs has relevant 
tickets.
2) {{GridReduceQueryExecutor.query}} - need to make sure that queries without 
caches (e.g. {{SELECT 1}}) works correctly. This also can be done in separate 
ticket.
3) Check if {{GridH2IndexRangeRequest}} requires MVCC version as well (see 
{{GridH2IndexBase.onIndexRangeRequest}}).
4) {{H2TreeIndex}} - we need to merge {{mvccFilter}} and 
{{IndexingQueryCacheFilter}} into a single implementation of 
{{TreeRowClosure}}. There should be a common method to get this filter from 
thread-local context. Currently we mistakenly ignore 
{{IndexingQueryCacheFilter}} in {{H2TreeIndex.findFirstOrLast}} method. Backup 
closure should be checked first.


was (Author: vozerov):
MVCC support for queries is mostly ready. However, several things need to be 
addressed:
1) Perform cleanup in {{MvccQueryTracker}}, so that all TODOs has relevant 
tickets.
2) {{GridReduceQueryExecutor.query}} - need to make sure that queries without 
caches (e.g. {{SELECT 1}}) works correctly. This also can be done in separate 
ticket.
3) Check if {{GridH2IndexRangeRequest}} requires MVCC version as well (see 
{{GridH2IndexBase.onIndexRangeRequest}}).
4) {{H2TreeIndex}} - we need to merge {{mvccFilter}} and 
{{IndexingQueryCacheFilter}} into a single implementation of 
{{TreeRowClosure}}. There should be a common method to get this filter from 
thread-local context. Currently we mistakenly ignore 
{{IndexingQueryCacheFilter}} in {{H2TreeIndex.findFirstOrLast}} method.

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



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-5934 at 11/14/17 9:03 AM:
---

MVCC support for queries is mostly ready. However, several things need to be 
addressed:
1) Perform cleanup in {{MvccQueryTracker}}, so that all TODOs has relevant 
tickets.
2) {{GridReduceQueryExecutor.query}} - need to make sure that queries without 
caches (e.g. {{SELECT 1}}) works correctly. This also can be done in separate 
ticket.
3) Check if {{GridH2IndexRangeRequest}} requires MVCC version as well (see 
{{GridH2IndexBase.onIndexRangeRequest}}).
4) {{H2TreeIndex}} - we need to merge {{mvccFilter}} and 
{{IndexingQueryCacheFilter}} into a single implementation of 
{{TreeRowClosure}}. There should be a common method to get this filter from 
thread-local context. Currently we mistakenly ignore 
{{IndexingQueryCacheFilter}} in {{H2TreeIndex.findFirstOrLast}} method. Backup 
closure should be checked first.
5) MVCC filter is not propagated to {{H2PkHashIndex}}


was (Author: vozerov):
MVCC support for queries is mostly ready. However, several things need to be 
addressed:
1) Perform cleanup in {{MvccQueryTracker}}, so that all TODOs has relevant 
tickets.
2) {{GridReduceQueryExecutor.query}} - need to make sure that queries without 
caches (e.g. {{SELECT 1}}) works correctly. This also can be done in separate 
ticket.
3) Check if {{GridH2IndexRangeRequest}} requires MVCC version as well (see 
{{GridH2IndexBase.onIndexRangeRequest}}).
4) {{H2TreeIndex}} - we need to merge {{mvccFilter}} and 
{{IndexingQueryCacheFilter}} into a single implementation of 
{{TreeRowClosure}}. There should be a common method to get this filter from 
thread-local context. Currently we mistakenly ignore 
{{IndexingQueryCacheFilter}} in {{H2TreeIndex.findFirstOrLast}} method. Backup 
closure should be checked first.

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



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

[jira] [Commented] (IGNITE-6496) Client node does not reconnect to server node when the latter is restarted.

[Vyacheslav Koptilin (JIRA)]

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

Vyacheslav Koptilin commented on IGNITE-6496:
-

TeamCity looks good enough 
https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F2981%2Fmerge
I could not find test failures that are related to the changes.

> Client node does not reconnect to server node when the latter is restarted.
> ---
>
> Key: IGNITE-6496
> URL: https://issues.apache.org/jira/browse/IGNITE-6496
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures
>Affects Versions: 1.9
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
> Attachments: ExampleNodeStartup.java
>
>
> The following scenario may result in deadlock on the client node:
>  - start server node and one client
>  - client node invokes IgniteQueue#take() method, that requires acquiring 
> both GridCacheGateway#readLock and GridCacheQueueAdapter#readSem.
>  - client node disconnects from the cluster for some reason (for example, 
> server node was stopped)
>in that case, GridCacheQueueAdapter does not release readSem and, 
> therefore, GridCacheGateway#readLock is also not released.
>  - 'tcp-client-disco-msg-worker' hangs due to unable acquiring 
> GridCacheGateway.writeLock
> "tcp-client-disco-msg-worker-#10%datastructures.GridCacheQueueClientReconnect1%"
>  #101 prio=5 os_prio=0 tid=0x21634000 nid=0x49a8 waiting on condition 
> [0x3a61e000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> parking to wait for  <0x00076fa988f8> (a 
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at 
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at 
> org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.lock0(StripedCompositeReadWriteLock.java:154)
> at 
> org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.lock(StripedCompositeReadWriteLock.java:123)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.writeLock(GridCacheGateway.java:278)
> at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3873)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:768)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:573)
> locked <0x00076f9f4048> (a java.lang.Object)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2415)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2394)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1710)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)



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

[jira] [Commented] (IGNITE-6844) Additional JMX metrics for cluster monitoring.

[Pavel Pereslegin (JIRA)]

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

Pavel Pereslegin commented on IGNITE-6844:
--

[~avinogradov],
I took IGNITE-6867 to work and it would be better to close this ticket.

> Additional JMX metrics for cluster monitoring.
> --
>
> Key: IGNITE-6844
> URL: https://issues.apache.org/jira/browse/IGNITE-6844
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.3
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
> Fix For: 2.4
>
>
> For some monitoring tasks we need to access these metrics through JMX:
> 1. Total server nodes in cluster.
> 2. Current topology version.
> We can’t access them via JMX for now.
> I suggest to add new management bean IgniteClusterMBean that will provide 
> such information.
> {code:java}
> @MXBeanDescription("Server nodes count.")
> public int getTotalServerNodes();
> @MXBeanDescription("Current topology version.")
> public long getTopologyVersion();
> {code}



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5934:
-

MVCC support for queries is mostly ready. However, several things need to be 
addressed:
1) Perform cleanup in {{MvccQueryTracker}}, so that all TODOs has relevant 
tickets.
2) {{GridReduceQueryExecutor.query}} - need to make sure that queries without 
caches (e.g. {{SELECT 1}}) works correctly. This also can be done in separate 
ticket.

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



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

[jira] [Updated] (IGNITE-6496) Client node does not reconnect to server node when the latter is restarted.

[Vyacheslav Koptilin (JIRA)]

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

Vyacheslav Koptilin updated IGNITE-6496:

Description: 
The following scenario may result in deadlock on the client node:
 - start server node and one client
 - client node invokes IgniteQueue#take() method, that requires acquiring both 
GridCacheGateway#readLock and GridCacheQueueAdapter#readSem.
 - client node disconnects from the cluster for some reason (for example, 
server node was stopped)
   in that case, GridCacheQueueAdapter does not release readSem and, therefore, 
GridCacheGateway#readLock is also not released.
 - 'tcp-client-disco-msg-worker' hangs due to unable acquiring 
GridCacheGateway.writeLock
"tcp-client-disco-msg-worker-#10%datastructures.GridCacheQueueClientReconnect1%"
 #101 prio=5 os_prio=0 tid=0x21634000 nid=0x49a8 waiting on condition 
[0x3a61e000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
parking to wait for  <0x00076fa988f8> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at 
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
at 
org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.lock0(StripedCompositeReadWriteLock.java:154)
at 
org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.lock(StripedCompositeReadWriteLock.java:123)
at 
org.apache.ignite.internal.processors.cache.GridCacheGateway.writeLock(GridCacheGateway.java:278)
at 
org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3873)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:768)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:573)
locked <0x00076f9f4048> (a java.lang.Object)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2415)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2394)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1710)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)



  was:
The following scenario may result in deadlock on the client node:
 - start server node and one client
 - client node invokes IgniteQueue#take() method, that requires acquiring both 
GridCacheGateway#readLock and GridCacheQueueAdapter#readSem.
 - client node disconnects from the cluster for some reason (for example, 
server node was stopped)
   in that case, GridCacheQueueAdapter does not release readSem and, therefore, 
GridCacheGateway#readLock is also not released.
 - 'tcp-client-disco-msg-worker' hangs due to unable acquiring 
GridCacheGateway.writeLock
"tcp-client-disco-msg-worker-#10%datastructures.GridCacheQueueClientReconnect1%"
 #101 prio=5 os_prio=0 tid=0x21634000 nid=0x49a8 waiting on condition 
[0x3a61e000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x00076fa988f8> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at 
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
at 
org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.lock0(StripedCompositeReadWriteLock.java:154)
at 
org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.lock(StripedCompositeReadWriteLock.java:123)
at 
org.apache.ignite.internal.processors.cache.GridCacheGateway.writeLock(GridCacheGateway.java:278)
at 
org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3873)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:768)
at 

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5934:
---

Assignee: (was: Vladimir Ozerov)

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



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

[jira] [Resolved] (IGNITE-6844) Additional JMX metrics for cluster monitoring.

[Pavel Pereslegin (JIRA)]

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

Pavel Pereslegin resolved IGNITE-6844.
--
Resolution: Duplicate

> Additional JMX metrics for cluster monitoring.
> --
>
> Key: IGNITE-6844
> URL: https://issues.apache.org/jira/browse/IGNITE-6844
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.3
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
> Fix For: 2.4
>
>
> For some monitoring tasks we need to access these metrics through JMX:
> 1. Total server nodes in cluster.
> 2. Current topology version.
> We can’t access them via JMX for now.
> I suggest to add new management bean IgniteClusterMBean that will provide 
> such information.
> {code:java}
> @MXBeanDescription("Server nodes count.")
> public int getTotalServerNodes();
> @MXBeanDescription("Current topology version.")
> public long getTopologyVersion();
> {code}



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

[jira] [Assigned] (IGNITE-6896) .NET: support Multidimensional Arrays in binary serializer

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-6896:
--

Assignee: Pavel Tupitsyn

> .NET: support Multidimensional Arrays in binary serializer
> --
>
> Key: IGNITE-6896
> URL: https://issues.apache.org/jira/browse/IGNITE-6896
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> It is found that legacy 2D, 3D, etc. are not working in BinarySerializer.
> Sample reproducer:
> {code:java}
> [Test]
> public void TestXX()
> {
> var array2D = new float[32, 32];
> var res = TestUtils.SerializeDeserialize(array2D);
> Assert.AreEqual(array2D, res);
> }
> {code}
> BTW, please note that 2D array in Java (a[2][2]) is just a jugged array:
> {noformat}
> obj = {byte[2][]@1928}
>  0 = {byte[2]@1974}
>  1 = {byte[2]@1975}
> {noformat}



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

[jira] [Updated] (IGNITE-6896) .NET: support Multidimensional Arrays in binary serializer

[Pavel Tupitsyn (JIRA)]

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

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

> .NET: support Multidimensional Arrays in binary serializer
> --
>
> Key: IGNITE-6896
> URL: https://issues.apache.org/jira/browse/IGNITE-6896
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Alexey Popov
>  Labels: .NET
>
> It is found that legacy 2D, 3D, etc. are not working in BinarySerializer.
> Sample reproducer:
> {code:java}
> [Test]
> public void TestXX()
> {
> var array2D = new float[32, 32];
> var res = TestUtils.SerializeDeserialize(array2D);
> Assert.AreEqual(array2D, res);
> }
> {code}
> BTW, please note that 2D array in Java (a[2][2]) is just a jugged array:
> {noformat}
> obj = {byte[2][]@1928}
>  0 = {byte[2]@1974}
>  1 = {byte[2]@1975}
> {noformat}



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-5934 at 11/14/17 8:12 AM:
---

MVCC support for queries is mostly ready. However, several things need to be 
addressed:
1) Perform cleanup in {{MvccQueryTracker}}, so that all TODOs has relevant 
tickets.
2) {{GridReduceQueryExecutor.query}} - need to make sure that queries without 
caches (e.g. {{SELECT 1}}) works correctly. This also can be done in separate 
ticket.
3) Check if {{GridH2IndexRangeRequest}} requires MVCC version as well.


was (Author: vozerov):
MVCC support for queries is mostly ready. However, several things need to be 
addressed:
1) Perform cleanup in {{MvccQueryTracker}}, so that all TODOs has relevant 
tickets.
2) {{GridReduceQueryExecutor.query}} - need to make sure that queries without 
caches (e.g. {{SELECT 1}}) works correctly. This also can be done in separate 
ticket.

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



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-5934 at 11/14/17 8:28 AM:
---

MVCC support for queries is mostly ready. However, several things need to be 
addressed:
1) Perform cleanup in {{MvccQueryTracker}}, so that all TODOs has relevant 
tickets.
2) {{GridReduceQueryExecutor.query}} - need to make sure that queries without 
caches (e.g. {{SELECT 1}}) works correctly. This also can be done in separate 
ticket.
3) Check if {{GridH2IndexRangeRequest}} requires MVCC version as well (see 
{{GridH2IndexBase.onIndexRangeRequest}}).
4) {{H2TreeIndex}} - we need to merge {{mvccFilter}} and 
{{IndexingQueryCacheFilter}} into a single implementation of 
{{TreeRowClosure}}. There should be a common method to get this filter from 
thread-local context. Currently we mistakenly ignore 
{{IndexingQueryCacheFilter}} in {{H2TreeIndex.findFirstOrLast}} method.


was (Author: vozerov):
MVCC support for queries is mostly ready. However, several things need to be 
addressed:
1) Perform cleanup in {{MvccQueryTracker}}, so that all TODOs has relevant 
tickets.
2) {{GridReduceQueryExecutor.query}} - need to make sure that queries without 
caches (e.g. {{SELECT 1}}) works correctly. This also can be done in separate 
ticket.
3) Check if {{GridH2IndexRangeRequest}} requires MVCC version as well.

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



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

[jira] [Commented] (IGNITE-6083) Null value have appear in the entry processor, but the entry is existing

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-6083:
--

[~v.pyatkov] the issue is ready to be reviewed

> Null value have appear in the entry processor, but the entry is existing
> 
>
> Key: IGNITE-6083
> URL: https://issues.apache.org/jira/browse/IGNITE-6083
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>Assignee: Alexey Kuznetsov
> Attachments: EntryProcessorInOptimisticTxTest.java
>
>
> In one thread load some data in a cache, after that I have execute 
> OPTIMISTIC, SERIALIZABLE transaction with two {{IgniteCache.invoke()}} 
> methods.
> The value had been corrected at first {{EntryProcessor}}, but it is NULL at 
> second.



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

[jira] [Created] (IGNITE-6898) Datastreamers can lead to OOM on server side

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-6898:


 Summary: Datastreamers can lead to OOM on server side
 Key: IGNITE-6898
 URL: https://issues.apache.org/jira/browse/IGNITE-6898
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: general
Affects Versions: 2.1
Reporter: Alexander Belyak


If grid server node process many datastreamer in same time (from many clients, 
with many cache backups and persistence, i.e. if processing take some time) it 
can lead to OutOfMemoryError in server JVM. To fix we can:
1) specify buffer sized in bytes instead of entries
2) use pageMemory to store streamer buffers
I get this problem on 16 server node grid with 45g heap each and 15 clients 
with 2 datastreamer each with this settings:
autoFlushFrequency=0
allowOverwrite=false
perNodeParallelOperations=8
perNodeBufferSize=1
Each client have 64g heap.



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

[jira] [Created] (IGNITE-6899) Adding GA Grid to Apache Ignite ML module.

[Yury Babak (JIRA)]

Yury Babak created IGNITE-6899:
--

 Summary: Adding GA Grid to Apache Ignite ML module.
 Key: IGNITE-6899
 URL: https://issues.apache.org/jira/browse/IGNITE-6899
 Project: Ignite
  Issue Type: New Feature
  Security Level: Public (Viewable by anyone)
  Components: ml
Reporter: Yury Babak
 Fix For: 2.4


We want to add GA Grid to our ML Module.

This is the first iteration of this integration. On this step we will simple 
add GA Grid to the separate package in ML module.

(i) This is a good package for GA Grid: org.apache.ignite.ml.genetic 
(i) For GA Grid we need unit tests as well as examples




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

[jira] [Commented] (IGNITE-6835) ODBC driver should handle ungraceful tcp disconnects

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-6835:


[~isapego]
Please correct the misprint "Netwirking initialisation ". Otherwise, looks good.

> ODBC driver should handle ungraceful tcp disconnects
> 
>
> Key: IGNITE-6835
> URL: https://issues.apache.org/jira/browse/IGNITE-6835
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 2.4
>
>
> It is found that ungraceful TCP disconnect makes ODBC driver stuck at socket 
> recv().
> Ungraceful TCP disconnect could be caused:
> 1. Network failure (or new firewall rules)
> 2. Remote party shutdown (Half Closed Connection)
> So, the proposal is:
> setup socket  options: 
> 1) SO_KEEPALIVE enabled
> 2) TCP_KEEPIDLE to 60 sec. It is 2 hour by default
> 3) TCP_KEEPINTVL to 5 (\?) sec. It is 1 sec at Win and 75 sec at Linux by 
> default.
> 4) send/receive buffers to some greater value (8k by default)



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

[jira] [Commented] (IGNITE-6898) Datastreamers can lead to OOM on server side

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov commented on IGNITE-6898:
---

[~sbberkov] perNodeParallelOperations seems to be deprecated. Also, don't you 
think that the same situation is possible if multiple clients do putAlls with 
large key count at the same time?

Suggested solutions do not seem sufficient to me - literally they change 
nothing. 

I think that server node should drop data streamer request and send error 
response to client to forcibly lower the limit for parallel requests at least 
for peak load duration. Once load on server decreases - server sends flag to 
client with some response and client puts the limit for parallel requests back. 
How about that?

Yakov

> Datastreamers can lead to OOM on server side
> 
>
> Key: IGNITE-6898
> URL: https://issues.apache.org/jira/browse/IGNITE-6898
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>
> If grid server node process many datastreamer in same time (from many 
> clients, with many cache backups and persistence, i.e. if processing take 
> some time) it can lead to OutOfMemoryError in server JVM. To fix we can:
> 1) specify buffer sized in bytes instead of entries
> 2) use pageMemory to store streamer buffers
> I get this problem on 16 server node grid with 45g heap each and 15 clients 
> with 2 datastreamer each with this settings:
> autoFlushFrequency=0
> allowOverwrite=false
> perNodeParallelOperations=8
> perNodeBufferSize=1
> Each client have 64g heap.



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

[jira] [Assigned] (IGNITE-6171) Native facility to control excessive GC pauses

[Dmitriy Sorokin (JIRA)]

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

Dmitriy Sorokin reassigned IGNITE-6171:
---

Assignee: Dmitriy Sorokin

> Native facility to control excessive GC pauses
> --
>
> Key: IGNITE-6171
> URL: https://issues.apache.org/jira/browse/IGNITE-6171
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Dmitriy Sorokin
>  Labels: usability
>
> Ignite is Java-based application. If node experiences long GC pauses it may 
> negatively affect other nodes. We need to find a way to detect long GC pauses 
> within the process and trigger some actions in response, e.g. node stop. 
> This is a kind of Inception \[1\], when you need to understand that you sleep 
> while sleeping. As all Java threads are blocked on safepoint, we cannot use 
> Java's thread to detect Java's GC. Native threads should be used instead.
> Proposed solution:
> 1) Thread 1 should periodically call dummy JNI method returning current time, 
> and set this time to shared variable;
> 2) Thread 2 should periodically check that variable. If it has not been 
> changed for some time - most likely we are in GC pause. Once certain 
> threashold is reached - trigger compensating action, whether this is a 
> warning, process kill, or what so ever.
> Justification: crossing native -> Java boundaries involves safepoints. This 
> way Thread 1 will be trapped if STW pause is in progress. Java method cannot 
> be empty, as JVM is smart enough and can deduce it to no-op. 
> \[1\] http://www.imdb.com/title/tt1375666/



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

[jira] [Updated] (IGNITE-6900) .NET: QuerySqlEntity attribute

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6900:
---
Description: 
{{[QuerySqlField]}} provides easy way to add a field to the 
{{CacheConfiguration.QueryEntity.Fields}}. However, often entire user class is 
used for SQL (every field should be included).

We can simplify these scenarios in two ways:
* {{[QuerySqlEntity]}} attribute (applied to a class) includes all fields into 
the QueryEntity
* Constructor overload {{public QueryEntity(Type keyType, Type valueType, bool 
includeAllFields)}}

  was:
{{[QuerySqlField]}} provides easy way to add a field to the 
{{CacheConfiguration.QueryEntity.Fields}}. However, often entire user class is 
used for SQL (every field should be included).

We can simplify these scenarios in two ways:
* [QuerySqlEntity] attribute (applied to a class) includes all fields into the 
QueryEntity
* Constructor overload {{public QueryEntity(Type keyType, Type valueType, bool 
includeAllFields)}}


> .NET: QuerySqlEntity attribute
> --
>
> Key: IGNITE-6900
> URL: https://issues.apache.org/jira/browse/IGNITE-6900
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET
>
> {{[QuerySqlField]}} provides easy way to add a field to the 
> {{CacheConfiguration.QueryEntity.Fields}}. However, often entire user class 
> is used for SQL (every field should be included).
> We can simplify these scenarios in two ways:
> * {{[QuerySqlEntity]}} attribute (applied to a class) includes all fields 
> into the QueryEntity
> * Constructor overload {{public QueryEntity(Type keyType, Type valueType, 
> bool includeAllFields)}}



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

[jira] [Created] (IGNITE-6900) .NET: QuerySqlEntity attribute

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6900:
--

 Summary: .NET: QuerySqlEntity attribute
 Key: IGNITE-6900
 URL: https://issues.apache.org/jira/browse/IGNITE-6900
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
  Components: platforms
Reporter: Pavel Tupitsyn


{{[QuerySqlField]}} provides easy way to add a field to the 
{{CacheConfiguration.QueryEntity.Fields}}. However, often entire user class is 
used for SQL (every field should be included).

We can simplify these scenarios in two ways:
* [QuerySqlEntity] attribute (applied to a class) includes all fields into the 
QueryEntity
* Constructor overload {{public QueryEntity(Type keyType, Type valueType, bool 
includeAllFields)}}



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

[jira] [Created] (IGNITE-6901) IgniteH2Indexing#rebuildIndexesFromHash should pass old value to indexing engine

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6901:
---

 Summary: IgniteH2Indexing#rebuildIndexesFromHash should pass old 
value to indexing engine
 Key: IGNITE-6901
 URL: https://issues.apache.org/jira/browse/IGNITE-6901
 Project: Ignite
  Issue Type: Task
  Security Level: Public (Viewable by anyone)
  Components: cache, persistence, sql
Reporter: Vladimir Ozerov
Assignee: Alexey Goncharuk
 Fix For: 2.4


When index rebuild is triggered, index is updated from the method 
{{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl.updateIndexes}}. Notice how 
we always pass {{null}} as previous row value. It breaks recent optimization 
which use previous value to avoid old row materialization IGNITE-6701, so 
assertion like this is observed:
{code}
[00:30:30][org.gridgain:gridgain-ultimate] Exception in thread 
"pub-#25397%database.IgniteDbSnapshotNotStableTopologiesTest3%" 
java.lang.AssertionError: Replaced: true
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:451)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:581)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1748)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:406)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:1375)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateIndexes(GridCacheOffheapManager.java:1242)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:364)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.ensureIndexed(GridCacheMapEntry.java:3149)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.rebuildIndexesFromHash(IgniteH2Indexing.java:2030)
{code}



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

[jira] [Created] (IGNITE-6903) Implement new JMX metrics for Indexing

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-6903:


 Summary: Implement new JMX metrics for Indexing
 Key: IGNITE-6903
 URL: https://issues.apache.org/jira/browse/IGNITE-6903
 Project: Ignite
  Issue Type: New Feature
  Security Level: Public (Viewable by anyone)
Reporter: Anton Vinogradov


These additional metrics and methods should be implemented:
- Space occupied by indexes.



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

[jira] [Updated] (IGNITE-6901) IgniteH2Indexing#rebuildIndexesFromHash should pass old value to indexing engine

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6901:

Description: 
When index rebuild is triggered, index is updated from the method 
{{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl.updateIndexes}}. Notice how 
we always pass {{null}} as previous row value. It breaks recent optimization 
which use previous value to avoid old row materialization IGNITE-6701, so 
assertion like this is observed:
{code}
java.lang.AssertionError: Replaced: true
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:451)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:581)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1748)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:406)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:1375)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateIndexes(GridCacheOffheapManager.java:1242)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:364)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.ensureIndexed(GridCacheMapEntry.java:3149)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.rebuildIndexesFromHash(IgniteH2Indexing.java:2030)
{code}

  was:
When index rebuild is triggered, index is updated from the method 
{{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl.updateIndexes}}. Notice how 
we always pass {{null}} as previous row value. It breaks recent optimization 
which use previous value to avoid old row materialization IGNITE-6701, so 
assertion like this is observed:
{code}
[00:30:30][org.gridgain:gridgain-ultimate] Exception in thread 
"pub-#25397%database.IgniteDbSnapshotNotStableTopologiesTest3%" 
java.lang.AssertionError: Replaced: true
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:451)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:581)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1748)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:406)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:1375)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateIndexes(GridCacheOffheapManager.java:1242)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:364)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.ensureIndexed(GridCacheMapEntry.java:3149)
[00:30:30][org.gridgain:gridgain-ultimate]  at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.rebuildIndexesFromHash(IgniteH2Indexing.java:2030)
{code}


> IgniteH2Indexing#rebuildIndexesFromHash should pass old value to indexing 
> engine
> 
>
> Key: IGNITE-6901
> URL: https://issues.apache.org/jira/browse/IGNITE-6901
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: cache, persistence, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexey Goncharuk
> Fix For: 2.4
>
>
> When index rebuild is triggered, index is updated from the method 
> {{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl.updateIndexes}}. Notice 
> how we always pass {{null}} as previous row value. It breaks recent 
> optimization which use previous value to avoid old row materialization 
> 

[jira] [Commented] (IGNITE-6901) IgniteH2Indexing#rebuildIndexesFromHash should pass old value to indexing engine

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6901:


GitHub user devozerov opened a pull request:

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

IGNITE-6901



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

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

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

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


commit 1c4a41e54a654023f3327d72ae7e480825c93737
Author: devozerov 
Date:   2017-11-14T11:16:19Z

Fix.




> IgniteH2Indexing#rebuildIndexesFromHash should pass old value to indexing 
> engine
> 
>
> Key: IGNITE-6901
> URL: https://issues.apache.org/jira/browse/IGNITE-6901
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: cache, persistence, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexey Goncharuk
> Fix For: 2.4
>
>
> When index rebuild is triggered, index is updated from the method 
> {{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl.updateIndexes}}. Notice 
> how we always pass {{null}} as previous row value. It breaks recent 
> optimization which use previous value to avoid old row materialization 
> IGNITE-6701, so assertion like this is observed:
> {code}
> java.lang.AssertionError: Replaced: true
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:451)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:581)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1748)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:406)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:1375)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateIndexes(GridCacheOffheapManager.java:1242)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:364)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.ensureIndexed(GridCacheMapEntry.java:3149)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.rebuildIndexesFromHash(IgniteH2Indexing.java:2030)
> {code}



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

[jira] [Commented] (IGNITE-5846) Add support of distributed matrices for OLS regression.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5846:


Github user zaleslaw closed the pull request at:

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


> Add support of distributed matrices for OLS regression.
> ---
>
> Key: IGNITE-5846
> URL: https://issues.apache.org/jira/browse/IGNITE-5846
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
>
> Currently OSL regression works only with local matrices.



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

[jira] [Updated] (IGNITE-6846) Add metrics for entry processor invocations

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6846:
-
Labels: iep-6  (was: )

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>  Labels: iep-6
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



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

[jira] [Created] (IGNITE-6902) Implement new JMX metrics for Persistence

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-6902:


 Summary: Implement new JMX metrics for Persistence
 Key: IGNITE-6902
 URL: https://issues.apache.org/jira/browse/IGNITE-6902
 Project: Ignite
  Issue Type: New Feature
  Security Level: Public (Viewable by anyone)
Reporter: Anton Vinogradov


These additional metrics and methods should be implemented:

- Bytes used per data region.
- Bytes used per cache.
- Size of checkpointing buffer.



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

[jira] [Commented] (IGNITE-6850) SQL: integrate index inline size to CREATE INDEX syntax

[Kirill Shirokov (JIRA)]

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

Kirill Shirokov commented on IGNITE-6850:
-

Fixed all the items mentioned by [~skalashnikov]. Testing did not reveal any 
regression.

> SQL: integrate index inline size to CREATE INDEX syntax
> ---
>
> Key: IGNITE-6850
> URL: https://issues.apache.org/jira/browse/IGNITE-6850
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Kirill Shirokov
> Fix For: 2.4
>
>
> Index value inline is important optimization which used to minimize amount of 
> data page reads when doing index lookup (see {{InlineIndexHelper}}). 
> Currently the only way to set it is {{QueryIndex.inlineSize}} property, so it 
> cannot be set from SQL command. We need to integrate it to our SQL syntax 
> (see {{SqlCreateIndexCommand}}) and make sure it is propagated properly.
> Sample syntax:
> {code}
> CREATE INDEX idx ON tbl(field) INLINE_SIZE 20;
> {code}



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

[jira] [Comment Edited] (IGNITE-6896) .NET: support Multidimensional Arrays in binary serializer

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-6896 at 11/14/17 9:45 AM:
--

I see two approaches for a fix:
- Write multidimensional as jagged, convert on use (same as int as uint 
situation)
- Wrap multidimensional in a wrapper (see {{PeerLoadingObjectHolderSerializer}} 
for an example)

First one breaks idenstity (returned object cannot be cast to initial type), so 
we should go with the second one I think.


was (Author: ptupitsyn):
I see two approaches for a fix:
- Write multidimensional as jagged, convert on use (same as int as uint 
situation)
- Wrap multidimensional in a wrapper (see {{PeerLoadingObjectHolderSerializer}} 
for an example)

> .NET: support Multidimensional Arrays in binary serializer
> --
>
> Key: IGNITE-6896
> URL: https://issues.apache.org/jira/browse/IGNITE-6896
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> It is found that legacy 2D, 3D, etc. are not working in BinarySerializer.
> Sample reproducer:
> {code:java}
> [Test]
> public void TestXX()
> {
> var array2D = new float[32, 32];
> var res = TestUtils.SerializeDeserialize(array2D);
> Assert.AreEqual(array2D, res);
> }
> {code}
> BTW, please note that 2D array in Java (a[2][2]) is just a jugged array:
> {noformat}
> obj = {byte[2][]@1928}
>  0 = {byte[2]@1974}
>  1 = {byte[2]@1975}
> {noformat}



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

[jira] [Commented] (IGNITE-6896) .NET: support Multidimensional Arrays in binary serializer

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6896:


I see two approaches for a fix:
- Write multidimensional as jagged, convert on use (same as int as uint 
situation)
- Wrap multidimensional in a wrapper (see {{PeerLoadingObjectHolderSerializer}} 
for an example)

> .NET: support Multidimensional Arrays in binary serializer
> --
>
> Key: IGNITE-6896
> URL: https://issues.apache.org/jira/browse/IGNITE-6896
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> It is found that legacy 2D, 3D, etc. are not working in BinarySerializer.
> Sample reproducer:
> {code:java}
> [Test]
> public void TestXX()
> {
> var array2D = new float[32, 32];
> var res = TestUtils.SerializeDeserialize(array2D);
> Assert.AreEqual(array2D, res);
> }
> {code}
> BTW, please note that 2D array in Java (a[2][2]) is just a jugged array:
> {noformat}
> obj = {byte[2][]@1928}
>  0 = {byte[2]@1974}
>  1 = {byte[2]@1975}
> {noformat}



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

[jira] [Commented] (IGNITE-6898) Datastreamers can lead to OOM on server side

[Alexander Belyak (JIRA)]

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

Alexander Belyak commented on IGNITE-6898:
--

We suggest data streamer as best mechanism to load large amount of data to grid 
so I think it will be enough to optimize it first
You suggest to add some back pressure or load control on application level. OK, 
sounds good.


> Datastreamers can lead to OOM on server side
> 
>
> Key: IGNITE-6898
> URL: https://issues.apache.org/jira/browse/IGNITE-6898
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>
> If grid server node process many datastreamer in same time (from many 
> clients, with many cache backups and persistence, i.e. if processing take 
> some time) it can lead to OutOfMemoryError in server JVM. To fix we can:
> 1) specify buffer sized in bytes instead of entries
> 2) use pageMemory to store streamer buffers
> I get this problem on 16 server node grid with 45g heap each and 15 clients 
> with 2 datastreamer each with this settings:
> autoFlushFrequency=0
> allowOverwrite=false
> perNodeParallelOperations=8
> perNodeBufferSize=1
> Each client have 64g heap.



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

[jira] [Commented] (IGNITE-6901) IgniteH2Indexing#rebuildIndexesFromHash should pass old value to indexing engine

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6901:
-

Test run: https://ci.ignite.apache.org/viewQueued.html?itemId=941836

> IgniteH2Indexing#rebuildIndexesFromHash should pass old value to indexing 
> engine
> 
>
> Key: IGNITE-6901
> URL: https://issues.apache.org/jira/browse/IGNITE-6901
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: cache, persistence, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexey Goncharuk
> Fix For: 2.4
>
>
> When index rebuild is triggered, index is updated from the method 
> {{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl.updateIndexes}}. Notice 
> how we always pass {{null}} as previous row value. It breaks recent 
> optimization which use previous value to avoid old row materialization 
> IGNITE-6701, so assertion like this is observed:
> {code}
> java.lang.AssertionError: Replaced: true
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:451)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:581)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1748)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:406)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:1375)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateIndexes(GridCacheOffheapManager.java:1242)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.updateIndexes(IgniteCacheOffheapManagerImpl.java:364)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.ensureIndexed(GridCacheMapEntry.java:3149)
> [00:30:30][org.gridgain:gridgain-ultimate]at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.rebuildIndexesFromHash(IgniteH2Indexing.java:2030)
> {code}



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

[jira] [Assigned] (IGNITE-6896) .NET: support Multidimensional Arrays in binary serializer

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-6896:
--

Assignee: Pavel Tupitsyn  (was: Alexey Popov)

> .NET: support Multidimensional Arrays in binary serializer
> --
>
> Key: IGNITE-6896
> URL: https://issues.apache.org/jira/browse/IGNITE-6896
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> It is found that legacy 2D, 3D, etc. are not working in BinarySerializer.
> Sample reproducer:
> {code:java}
> [Test]
> public void TestXX()
> {
> var array2D = new float[32, 32];
> var res = TestUtils.SerializeDeserialize(array2D);
> Assert.AreEqual(array2D, res);
> }
> {code}
> BTW, please note that 2D array in Java (a[2][2]) is just a jugged array:
> {noformat}
> obj = {byte[2][]@1928}
>  0 = {byte[2]@1974}
>  1 = {byte[2]@1975}
> {noformat}



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

[jira] [Commented] (IGNITE-5343) .NET: Interoperate with JVM directly, get rid of C++ layer

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5343:


Merged to master: {{ec38564a83ecddd520f5227d904468c04720389a}}.
Woohoo!

> .NET: Interoperate with JVM directly, get rid of C++ layer
> --
>
> Key: IGNITE-5343
> URL: https://issues.apache.org/jira/browse/IGNITE-5343
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, xplat
> Fix For: 2.4
>
>
> We can work with JNI directly using P/Invoke, there is no real need for C++ 
> layer.
> Advantages of removing C++ layer:
> * *No MSVC++ 2010 dependency*
> * *No build tools required for development*
> * Simplify and speed up the build procedure
> * No embedded libraries
> * Easier crossplatform support (IGNITE-2662)



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

[jira] [Commented] (IGNITE-5343) .NET: Interoperate with JVM directly, get rid of C++ layer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5343:


Github user asfgit closed the pull request at:

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


> .NET: Interoperate with JVM directly, get rid of C++ layer
> --
>
> Key: IGNITE-5343
> URL: https://issues.apache.org/jira/browse/IGNITE-5343
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, xplat
> Fix For: 2.4
>
>
> We can work with JNI directly using P/Invoke, there is no real need for C++ 
> layer.
> Advantages of removing C++ layer:
> * *No MSVC++ 2010 dependency*
> * *No build tools required for development*
> * Simplify and speed up the build procedure
> * No embedded libraries
> * Easier crossplatform support (IGNITE-2662)



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

[jira] [Assigned] (IGNITE-6905) Print a consistent ID into a log file

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin reassigned IGNITE-6905:
--

Assignee: (was: Sergey Chugunov)

> Print a consistent ID into a log file
> -
>
> Key: IGNITE-6905
> URL: https://issues.apache.org/jira/browse/IGNITE-6905
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Reporter: Sergey Puchnin
>  Labels: IEP-4
> Fix For: 2.4
>
>
> A BLT allows joining nodes by consistent ID. It's necessary to provide an 
> information about consistent ID in log file



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

[jira] [Updated] (IGNITE-6905) Print a consistent ID into a log file

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin updated IGNITE-6905:
---
Description: A BLT allows joining nodes by consistent ID. It's necessary to 
provide an information about consistent ID in log file  (was: A BLT allows to 
join nodes by  consistens ID)

> Print a consistent ID into a log file
> -
>
> Key: IGNITE-6905
> URL: https://issues.apache.org/jira/browse/IGNITE-6905
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Reporter: Sergey Puchnin
>Assignee: Sergey Chugunov
>  Labels: IEP-4
> Fix For: 2.4
>
>
> A BLT allows joining nodes by consistent ID. It's necessary to provide an 
> information about consistent ID in log file



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