[jira] [Closed] (IGNITE-6048) Need to document how to connect to Ignite from external SQL tools

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-6048.
---

> Need to document how to connect to Ignite from external SQL tools
> -
>
> Key: IGNITE-6048
> URL: https://issues.apache.org/jira/browse/IGNITE-6048
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: docs
> Fix For: 2.2
>
>
> We need to provide all the possible required JDBC and ODBC settings. We 
> should also pick any SQL tool and provide screenshots. For example, DBeaver 
> is a good candidate.
> http://dbeaver.jkiss.org/
> D.



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

[jira] [Resolved] (IGNITE-6048) Need to document how to connect to Ignite from external SQL tools

[Denis Magda (JIRA)]

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

Denis Magda resolved IGNITE-6048.
-
Resolution: Fixed

Done:
https://apacheignite.readme.io/docs/sql-tooling

> Need to document how to connect to Ignite from external SQL tools
> -
>
> Key: IGNITE-6048
> URL: https://issues.apache.org/jira/browse/IGNITE-6048
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: docs
> Fix For: 2.2
>
>
> We need to provide all the possible required JDBC and ODBC settings. We 
> should also pick any SQL tool and provide screenshots. For example, DBeaver 
> is a good candidate.
> http://dbeaver.jkiss.org/
> D.



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

[jira] [Closed] (IGNITE-6038) Update Data Grid page on the website to reflect Persistence

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-6038.
---

> Update Data Grid page on the website to reflect Persistence
> ---
>
> Key: IGNITE-6038
> URL: https://issues.apache.org/jira/browse/IGNITE-6038
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> # Change the diagram to reflect native persistence
> # add native persistence sub-section
> # add native persistence feature



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

[jira] [Resolved] (IGNITE-6036) Ignite 2.1 use case changes on the website

[Denis Magda (JIRA)]

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

Denis Magda resolved IGNITE-6036.
-
Resolution: Fixed

> Ignite 2.1 use case changes on the website
> --
>
> Key: IGNITE-6036
> URL: https://issues.apache.org/jira/browse/IGNITE-6036
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> Need to make the following changes to the use case section on the website:
> # Add new section in the dropdown: Distributed Database
> ## add Distributed Transactional Database page
> ## add In-Memory Database page
> ## add Ignite vs NoSQL Databases
> ## add Ignite vs RDBMS Databases
> # Under In-Memory Caching Section
> ## add Ignite and In-Memory Data Grids page (explain persistence)
> ## fix Key-Value Store page to reflect native persistence
> ## fix JCache Provider page to reflect native persistence
> Branch with the changes: 
> https://svn.apache.org/repos/asf/ignite/site/ignite-6036
> Update Ignite overview on the db-engines once the ticket is ready: 
> https://db-engines.com/en/system/Ignite



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

[jira] [Commented] (IGNITE-6036) Ignite 2.1 use case changes on the website

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6036:
-

The task is completed from my side. Below you’ll find the brand new pages added 
to the site. In addition, the items of “Docs” menu were rearranged for clarity.

Features Menu:
Collocated processing: https://ignite.apache.org/collocatedprocessing.html

Use Cases:
Distributed database: 
https://ignite.apache.org/use-cases/database/distributed-database.html
In-Memory database: 
https://ignite.apache.org/use-cases/database/in-memory-database.html
SQL database: https://ignite.apache.org/use-cases/database/sql-database.html
Key-value database: 
https://ignite.apache.org/use-cases/database/key-value-database.html
Ignite for NoSQL users: 
https://ignite.apache.org/use-cases/comparison/ignite-for-nosql.html
Ignite for RDBMS users: 
https://ignite.apache.org/use-cases/comparison/ignite-for-rdbms.html


> Ignite 2.1 use case changes on the website
> --
>
> Key: IGNITE-6036
> URL: https://issues.apache.org/jira/browse/IGNITE-6036
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> Need to make the following changes to the use case section on the website:
> # Add new section in the dropdown: Distributed Database
> ## add Distributed Transactional Database page
> ## add In-Memory Database page
> ## add Ignite vs NoSQL Databases
> ## add Ignite vs RDBMS Databases
> # Under In-Memory Caching Section
> ## add Ignite and In-Memory Data Grids page (explain persistence)
> ## fix Key-Value Store page to reflect native persistence
> ## fix JCache Provider page to reflect native persistence
> Branch with the changes: 
> https://svn.apache.org/repos/asf/ignite/site/ignite-6036
> Update Ignite overview on the db-engines once the ticket is ready: 
> https://db-engines.com/en/system/Ignite



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

[jira] [Closed] (IGNITE-6036) Ignite 2.1 use case changes on the website

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-6036.
---

> Ignite 2.1 use case changes on the website
> --
>
> Key: IGNITE-6036
> URL: https://issues.apache.org/jira/browse/IGNITE-6036
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: site
>
> Need to make the following changes to the use case section on the website:
> # Add new section in the dropdown: Distributed Database
> ## add Distributed Transactional Database page
> ## add In-Memory Database page
> ## add Ignite vs NoSQL Databases
> ## add Ignite vs RDBMS Databases
> # Under In-Memory Caching Section
> ## add Ignite and In-Memory Data Grids page (explain persistence)
> ## fix Key-Value Store page to reflect native persistence
> ## fix JCache Provider page to reflect native persistence
> Branch with the changes: 
> https://svn.apache.org/repos/asf/ignite/site/ignite-6036
> Update Ignite overview on the db-engines once the ticket is ready: 
> https://db-engines.com/en/system/Ignite



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

[jira] [Resolved] (IGNITE-6164) H2 dependency is not resolved from ignite-indexing:2.1.0

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko resolved IGNITE-6164.
-
Resolution: Won't Fix

> H2 dependency is not resolved from ignite-indexing:2.1.0
> 
>
> Key: IGNITE-6164
> URL: https://issues.apache.org/jira/browse/IGNITE-6164
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pranas Baliuka
>Priority: Minor
>
> I've tested the first code sample from Ignite book code 
> https://github.com/srecon/ignite-book-code-samples with dependecies:
> {code}
> 
> UTF-8
> 2.1.0
> 
> 
> 
> junit
> junit
> 3.8.1
> test
> 
> 
> org.apache.ignite
> ignite-core
> ${ignite.version}
> 
> 
> org.apache.ignite
> ignite-spring
> 
> 
> org.apache.ignite
> ignite-indexing
> 
> 
> {code}
> Runtime exception indicates what transitive dependency:
> {code}
> 
> com.h2database
> h2
> 1.4.195
> runtime
> 
> {code}
> is not resolved from the {{ignite-indexing}} . Consider fixing



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

[jira] [Commented] (IGNITE-6164) H2 dependency is not resolved from ignite-indexing:2.1.0

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-6164:
-

[~pranas], all these dependencies are available in Maven Central and can be 
resolved, this works for everybody. I would suggest you to refer to examples 
project which is available with every release and use it as a start.

If nothing helps, ask on user list, providing as much information as possible 
(your pom file, errors, logs, etc.). The problem, in the way it's currently 
described, is far from being a bug and I doubt something needs to be fixed 
here. I will close the ticket.

> H2 dependency is not resolved from ignite-indexing:2.1.0
> 
>
> Key: IGNITE-6164
> URL: https://issues.apache.org/jira/browse/IGNITE-6164
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pranas Baliuka
>Priority: Minor
>
> I've tested the first code sample from Ignite book code 
> https://github.com/srecon/ignite-book-code-samples with dependecies:
> {code}
> 
> UTF-8
> 2.1.0
> 
> 
> 
> junit
> junit
> 3.8.1
> test
> 
> 
> org.apache.ignite
> ignite-core
> ${ignite.version}
> 
> 
> org.apache.ignite
> ignite-spring
> 
> 
> org.apache.ignite
> ignite-indexing
> 
> 
> {code}
> Runtime exception indicates what transitive dependency:
> {code}
> 
> com.h2database
> h2
> 1.4.195
> runtime
> 
> {code}
> is not resolved from the {{ignite-indexing}} . Consider fixing



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

[jira] [Closed] (IGNITE-6164) H2 dependency is not resolved from ignite-indexing:2.1.0

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko closed IGNITE-6164.
---

> H2 dependency is not resolved from ignite-indexing:2.1.0
> 
>
> Key: IGNITE-6164
> URL: https://issues.apache.org/jira/browse/IGNITE-6164
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pranas Baliuka
>Priority: Minor
>
> I've tested the first code sample from Ignite book code 
> https://github.com/srecon/ignite-book-code-samples with dependecies:
> {code}
> 
> UTF-8
> 2.1.0
> 
> 
> 
> junit
> junit
> 3.8.1
> test
> 
> 
> org.apache.ignite
> ignite-core
> ${ignite.version}
> 
> 
> org.apache.ignite
> ignite-spring
> 
> 
> org.apache.ignite
> ignite-indexing
> 
> 
> {code}
> Runtime exception indicates what transitive dependency:
> {code}
> 
> com.h2database
> h2
> 1.4.195
> runtime
> 
> {code}
> is not resolved from the {{ignite-indexing}} . Consider fixing



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

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

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-6171:
-

https://stackoverflow.com/questions/2057792/garbage-collection-notification

It turns out you can listen to GC events.

> 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
> Fix For: 2.2
>
>
> 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-5280) SparseDistributedMatrix refactoring

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-5280:
-

LGTM. Merged to master branch.

> SparseDistributedMatrix refactoring
> ---
>
> Key: IGNITE-5280
> URL: https://issues.apache.org/jira/browse/IGNITE-5280
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> We must refactor SparseDistributedMatrix for decrease communication during 
> computations.



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

[jira] [Assigned] (IGNITE-6175) JVM Crash in "Ignite Binary Objects Simple Mapper Basic" suite

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev reassigned IGNITE-6175:
-

Assignee: Andrey Gura  (was: Eduard Shangareev)

Please, take a look.

> JVM Crash in "Ignite Binary Objects Simple Mapper Basic" suite
> ---
>
> Key: IGNITE-6175
> URL: https://issues.apache.org/jira/browse/IGNITE-6175
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Andrey Gura
> Fix For: 2.2
>
>
> JVM crash dump and logs you could find here
> https://ci.ignite.apache.org/viewLog.html?buildTypeId=Ignite20Tests_IgniteBinarySImpleMapperBasic=785893_Ignite20Tests_IgniteBinarySImpleMapperBasic=pull/2380/head
> {code}
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x7f6a0274a13f, pid=3507, tid=140092082124544
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_80-b15) (build 
> 1.7.0_80-b15)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.80-b11 mixed mode 
> linux-amd64 compressed oops)
> # Problematic frame:
> # J 10572 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readLock(Lorg/apache/ignite/internal/pagemem/PageMemory;IJJLorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageLockListener;)J
>  (39 bytes) @ 0x7f6a0274a13f [0x7f6a02749ba0+0x59f]
> #
> # Core dump written. Default location: 
> /data/teamcity/work/820be461cd64b574/core or core.3507
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.java.com/bugreport/crash.jsp
> # {code}



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

[jira] [Comment Edited] (IGNITE-6175) JVM Crash in "Ignite Binary Objects Simple Mapper Basic" suite

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev edited comment on IGNITE-6175 at 8/23/17 5:47 PM:


The issue was in not waiting before threads stop and closing page memory (it 
happens when a test fails by timeout in BPlusTreeSelfTest and its descendants).


was (Author: edshanggg):
The issue was in not waiting before threads stop and closing page memory.

> JVM Crash in "Ignite Binary Objects Simple Mapper Basic" suite
> ---
>
> Key: IGNITE-6175
> URL: https://issues.apache.org/jira/browse/IGNITE-6175
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
> Fix For: 2.2
>
>
> JVM crash dump and logs you could find here
> https://ci.ignite.apache.org/viewLog.html?buildTypeId=Ignite20Tests_IgniteBinarySImpleMapperBasic=785893_Ignite20Tests_IgniteBinarySImpleMapperBasic=pull/2380/head
> {code}
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x7f6a0274a13f, pid=3507, tid=140092082124544
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_80-b15) (build 
> 1.7.0_80-b15)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.80-b11 mixed mode 
> linux-amd64 compressed oops)
> # Problematic frame:
> # J 10572 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readLock(Lorg/apache/ignite/internal/pagemem/PageMemory;IJJLorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageLockListener;)J
>  (39 bytes) @ 0x7f6a0274a13f [0x7f6a02749ba0+0x59f]
> #
> # Core dump written. Default location: 
> /data/teamcity/work/820be461cd64b574/core or core.3507
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.java.com/bugreport/crash.jsp
> # {code}



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

[jira] [Commented] (IGNITE-6175) JVM Crash in "Ignite Binary Objects Simple Mapper Basic" suite

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6175:


GitHub user EdShangGG opened a pull request:

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

IGNITE-6175 JVM Crash in "Ignite Binary Objects Simple Mapper Basic" …

…suite

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

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

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

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


commit a0186af956072eb382427bf3c0432f5f1c5a01aa
Author: Eduard Shangareev 
Date:   2017-08-23T17:19:21Z

IGNITE-6175 JVM Crash in "Ignite Binary Objects Simple Mapper Basic" suite




> JVM Crash in "Ignite Binary Objects Simple Mapper Basic" suite
> ---
>
> Key: IGNITE-6175
> URL: https://issues.apache.org/jira/browse/IGNITE-6175
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
> Fix For: 2.2
>
>
> JVM crash dump and logs you could find here
> https://ci.ignite.apache.org/viewLog.html?buildTypeId=Ignite20Tests_IgniteBinarySImpleMapperBasic=785893_Ignite20Tests_IgniteBinarySImpleMapperBasic=pull/2380/head
> {code}
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x7f6a0274a13f, pid=3507, tid=140092082124544
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_80-b15) (build 
> 1.7.0_80-b15)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.80-b11 mixed mode 
> linux-amd64 compressed oops)
> # Problematic frame:
> # J 10572 C2 
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readLock(Lorg/apache/ignite/internal/pagemem/PageMemory;IJJLorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageLockListener;)J
>  (39 bytes) @ 0x7f6a0274a13f [0x7f6a02749ba0+0x59f]
> #
> # Core dump written. Default location: 
> /data/teamcity/work/820be461cd64b574/core or core.3507
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.java.com/bugreport/crash.jsp
> # {code}



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

[jira] [Commented] (IGNITE-6125) Improve robustness for JDBC driver metadata queries

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-6125:
-

[~vozerov] please review this change.

We're making shift towards case-insensitive matching of table names and 
rejecting of non-empty catalog values.

Please confirm that we're OK with this (potentially breaking) API change.

> Improve robustness for JDBC driver metadata queries
> ---
>
> Key: IGNITE-6125
> URL: https://issues.apache.org/jira/browse/IGNITE-6125
> Project: Ignite
>  Issue Type: Task
>  Components: clients, jdbc
>Affects Versions: 2.1
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
> Fix For: 2.2
>
>
> org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata is in worrysome state:
> - Makes frivolous use of toUpperCase() to address former.
> - getPrimaryKeys() never returns anything because of defective use of 
> toUpperCase().
> - No tests on indexes, primary keys, schemas or parameters metadata retrieval.
> - Ignores "catalog" parameter instead of checking if it matches empty catalog.
> - See also IGNITE-6138, IGNITE-6139
> That should be fixes without compromising backwards compatibility too much. 
> Tests may be borrowed from thin client implementation.



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

[jira] [Created] (IGNITE-6175) JVM Crash in "Ignite Binary Objects Simple Mapper Basic" suite

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-6175:
-

 Summary: JVM Crash in "Ignite Binary Objects Simple Mapper Basic" 
suite
 Key: IGNITE-6175
 URL: https://issues.apache.org/jira/browse/IGNITE-6175
 Project: Ignite
  Issue Type: Bug
Reporter: Eduard Shangareev
Assignee: Eduard Shangareev
 Fix For: 2.2


JVM crash dump and logs you could find here
https://ci.ignite.apache.org/viewLog.html?buildTypeId=Ignite20Tests_IgniteBinarySImpleMapperBasic=785893_Ignite20Tests_IgniteBinarySImpleMapperBasic=pull/2380/head

{code}

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7f6a0274a13f, pid=3507, tid=140092082124544
#
# JRE version: Java(TM) SE Runtime Environment (7.0_80-b15) (build 1.7.0_80-b15)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.80-b11 mixed mode linux-amd64 
compressed oops)
# Problematic frame:
# J 10572 C2 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readLock(Lorg/apache/ignite/internal/pagemem/PageMemory;IJJLorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageLockListener;)J
 (39 bytes) @ 0x7f6a0274a13f [0x7f6a02749ba0+0x59f]
#
# Core dump written. Default location: 
/data/teamcity/work/820be461cd64b574/core or core.3507
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# {code}



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

[jira] [Commented] (IGNITE-6125) Improve robustness for JDBC driver metadata queries

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6125:


GitHub user alamar opened a pull request:

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

IGNITE-6125 Increase robustness of JDBC Metadata

Avoid toUpperCase() where possible.
Check that catalog matches to empty catalog.
Ported several tests from Thin driver implementation.
Fixed faulty toUpperCase() in Primary Keys metadata.

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

$ git pull https://github.com/alamar/ignite ignite-6125

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

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


commit 0936d9e8ebbb4b4f4450a915791de728eaa6e845
Author: Ilya Kasnacheev 
Date:   2017-08-18T11:40:42Z

IGNITE-6125 Increase robustness of JDBC Metadata

Avoid toUpperCase() where possible.
Check that catalog matches to empty catalog.
Ported several tests from Thin driver implementation.
Fixed faulty toUpperCase() in Primary Keys metadata.




> Improve robustness for JDBC driver metadata queries
> ---
>
> Key: IGNITE-6125
> URL: https://issues.apache.org/jira/browse/IGNITE-6125
> Project: Ignite
>  Issue Type: Task
>  Components: clients, jdbc
>Affects Versions: 2.1
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
> Fix For: 2.2
>
>
> org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata is in worrysome state:
> - Makes frivolous use of toUpperCase() to address former.
> - getPrimaryKeys() never returns anything because of defective use of 
> toUpperCase().
> - No tests on indexes, primary keys, schemas or parameters metadata retrieval.
> - Ignores "catalog" parameter instead of checking if it matches empty catalog.
> - See also IGNITE-6138, IGNITE-6139
> That should be fixes without compromising backwards compatibility too much. 
> Tests may be borrowed from thin client implementation.



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

[jira] [Commented] (IGNITE-6168) Ability to use TLS client authentication in the TcpDiscoverySpi

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6168:


GitHub user alamar opened a pull request:

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

IGNITE-6168 Need SSL client authentication during discovery

Otherwise when certificates mismatch, discovery succeeds but communication 
fails, leading to a livelock.

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

$ git pull https://github.com/alamar/ignite ignite-6168

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

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


commit 8852328e0a514f3dc625cfc76f96aa280190e96d
Author: Ilya Kasnacheev 
Date:   2017-08-23T16:53:41Z

IGNITE-6168 Need SSL client authentication during discovery




> Ability to use TLS client authentication in the TcpDiscoverySpi
> ---
>
> Key: IGNITE-6168
> URL: https://issues.apache.org/jira/browse/IGNITE-6168
> Project: Ignite
>  Issue Type: Wish
>Affects Versions: 2.1
>Reporter: Jens Borgland
>Assignee: Ilya Kasnacheev
>
> I'm working on an application where we use mutual TLS to protect the 
> communication (of different kinds) between the components. It seems like 
> Ignite uses mutual TLS for the TcpCommunicationSpi but not for the 
> TcpDiscoverySpi. Would it be possible to add this ability (one way could 
> perhaps be by implementing IGNITE-6167 so that it can be done through a 
> custom socket factory)?
> I'm aware that there are other client authentication options for the 
> discovery SPI but it would be nice to be able to use the same mechanism 
> everywhere.



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

[jira] [Updated] (IGNITE-6056) Grid hangs on partition map exhcange during failover test with 500 logical and 26 physical caches

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-6056:

Component/s: general

> Grid hangs on partition map exhcange during failover test with 500 logical 
> and 26 physical caches
> -
>
> Key: IGNITE-6056
> URL: https://issues.apache.org/jira/browse/IGNITE-6056
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Ksenia Rybakova
> Attachments: ignite-base-load-config.xml, run-load.properties, 
> run-load.xml
>
>
> Grid hangs on partition map exhcange during failover test with 500 logical 
> and 26 physical caches.
> Load config:
> - CacheRandomOperationBenchmark
> - 8 client nodes, 40 server nodes
> - 40K perloading, 60K key range
> - 26 physical caches
> - 500 logical caches
> - 2 backups
> - 1 server node is being restarted periodically
> Complete configs are attached.
> Preloading phase is ok, then main test starts and after some time grid hangs.



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

[jira] [Created] (IGNITE-6174) Exchange may do not wait for tx completion in case node failures

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-6174:


 Summary: Exchange may do not wait for tx completion in case node 
failures
 Key: IGNITE-6174
 URL: https://issues.apache.org/jira/browse/IGNITE-6174
 Project: Ignite
  Issue Type: Bug
Reporter: Semen Boikov
Assignee: Semen Boikov
 Fix For: 2.2


Very good reproduces in 
IgniteCachePartitionedNearDisabledPrimaryNodeFailureRecoveryTest.testOptimisticPrimaryAndOriginatingNodeFailureRecovery1.

Approximate scenario:
- there are several nodes in topology
- node A starts tx prepare
- one node fails, exchange is started
- all servers except node A finishes 'waitPartitionRelease()' and coordinator 
waits for node A
- node A also fails, but it was able to send prepare request and it will be 
processed
- since node A failed others nodes can finish exchange, without waiting for tx 
completion

Note: to increase possibility change nodes start order in 
IgniteCacheAbstractTest:
{noformat}
protected void startGrids() throws Exception {
int cnt = gridCount();

assert cnt >= 1 : "At least one grid must be started";

//startGridsMultiThreaded(cnt);
startGrid(0);
startGrid(1);
startGrid(3);
startGrid(2);

awaitPartitionMapExchange();
}
{noformat}

It seems one possible solution: exchange should wait when all messages from 
failed node are processed.



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

[jira] [Commented] (IGNITE-6172) Binary marshaller should support Serializable

[Amelchev Nikita (JIRA)]

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

Amelchev Nikita commented on IGNITE-6172:
-

[~vozerov] I asked about it on a 
[devlist|http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-2894-Binary-object-inside-of-Externalizable-still-serialized-with-OptimizedMarshaller-tp13679p18945.html].
 I suggest dividing the [issue 
2894|https://issues.apache.org/jira/browse/IGNITE-2894] into two tasks: support 
the Externalizable and support the Serializable.

> Binary marshaller should support Serializable
> -
>
> Key: IGNITE-6172
> URL: https://issues.apache.org/jira/browse/IGNITE-6172
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Amelchev Nikita
>
> When binary marshaller meets a Serializable object, it switches to optimized 
> marshaller. Ignite should just have a single marshaller, which drives the 
> whole serialization process. It doesn't delegate to OptimizedMarshaller as it 
> does today. 



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

[jira] [Created] (IGNITE-6173) SQL: do not start caches on client nodes

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6173:
---

 Summary: SQL: do not start caches on client nodes
 Key: IGNITE-6173
 URL: https://issues.apache.org/jira/browse/IGNITE-6173
 Project: Ignite
  Issue Type: Task
  Components: cache, sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov


When cache is started, this even is distributed through custom discovery 
message. Server nodes start the cache, client nodes do nothing until cache is 
requested explicitly. At the same time H2 database objects are created only 
when cache is really started. 

For this reason query parsing could lead to {{TABLE NOT FOUND}}, {{INDEX NOT 
FOUND}}, etc. errors. If such exception is observed, we force start of all 
known cache on a client and then retry. See 
{{GridCacheProcessor#createMissingQueryCaches}} method. 

First, client node cache start leads to another custom discovery message. So 
query performance may suffer. Second, this is not needed! We already have all 
necessary cache info in discovery. 

Let's try to find a way to use available discovery data and do not start cache 
on a client for SQL query execution.



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

[jira] [Commented] (IGNITE-5280) SparseDistributedMatrix refactoring

[Artem Malykh (JIRA)]

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

Artem Malykh commented on IGNITE-5280:
--

Looks good.

> SparseDistributedMatrix refactoring
> ---
>
> Key: IGNITE-5280
> URL: https://issues.apache.org/jira/browse/IGNITE-5280
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> We must refactor SparseDistributedMatrix for decrease communication during 
> computations.



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6171:

Description: 
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/

  was:
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/


> 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
> Fix For: 2.2
>
>
> 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-6172) Binary marshaller should support Serializable

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6172:
-

[~NSAmelchev], {{BinaryMarshaller}} supports {{Serializable}}. What it doesn't 
support natively are {{Externalizable}} and custom {{writeObject}} method. 
Anyway, what is the goal of this change? I.e. why do we need to change existing 
implementation?

> Binary marshaller should support Serializable
> -
>
> Key: IGNITE-6172
> URL: https://issues.apache.org/jira/browse/IGNITE-6172
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Amelchev Nikita
>
> When binary marshaller meets a Serializable object, it switches to optimized 
> marshaller. Ignite should just have a single marshaller, which drives the 
> whole serialization process. It doesn't delegate to OptimizedMarshaller as it 
> does today. 



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

[jira] [Created] (IGNITE-6172) Binary marshaller should support Serializable

[Amelchev Nikita (JIRA)]

Amelchev Nikita created IGNITE-6172:
---

 Summary: Binary marshaller should support Serializable
 Key: IGNITE-6172
 URL: https://issues.apache.org/jira/browse/IGNITE-6172
 Project: Ignite
  Issue Type: Task
  Components: general
Reporter: Amelchev Nikita


When binary marshaller meets a Serializable object, it switches to optimized 
marshaller. Ignite should just have a single marshaller, which drives the whole 
serialization process. It doesn't delegate to OptimizedMarshaller as it does 
today. 



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

[jira] [Comment Edited] (IGNITE-5280) SparseDistributedMatrix refactoring

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko edited comment on IGNITE-5280 at 8/23/17 2:12 PM:
-

code looks good: issues pointed in my initial comments are all addressed now. 
Also Yury confirmed successful running of TracerTest locally (because it 
doesn't run on CI per IGNITE-5725)


was (Author: oignatenko):
issues pointed in my comments are addressed now. Consider running TracerTest 
locally (because it doesn't run on CI per IGNITE-5725)

> SparseDistributedMatrix refactoring
> ---
>
> Key: IGNITE-5280
> URL: https://issues.apache.org/jira/browse/IGNITE-5280
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> We must refactor SparseDistributedMatrix for decrease communication during 
> computations.



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

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

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6171:
---

 Summary: 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
 Fix For: 2.2


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-5280) SparseDistributedMatrix refactoring

[Yury Babak (JIRA)]

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

Yury Babak commented on IGNITE-5280:


TracerTest is green.

> SparseDistributedMatrix refactoring
> ---
>
> Key: IGNITE-5280
> URL: https://issues.apache.org/jira/browse/IGNITE-5280
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> We must refactor SparseDistributedMatrix for decrease communication during 
> computations.



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

[jira] [Commented] (IGNITE-5280) SparseDistributedMatrix refactoring

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko commented on IGNITE-5280:


issues pointed in my comments are addressed now. Consider running TracerTest 
locally (because it doesn't run on CI per IGNITE-5725)

> SparseDistributedMatrix refactoring
> ---
>
> Key: IGNITE-5280
> URL: https://issues.apache.org/jira/browse/IGNITE-5280
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> We must refactor SparseDistributedMatrix for decrease communication during 
> computations.



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

[jira] [Commented] (IGNITE-5280) SparseDistributedMatrix refactoring

[Yury Babak (JIRA)]

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

Yury Babak commented on IGNITE-5280:


Some issues was fixed so please [~amalykh], [~oignatenko] check it again. 
Thanks!

> SparseDistributedMatrix refactoring
> ---
>
> Key: IGNITE-5280
> URL: https://issues.apache.org/jira/browse/IGNITE-5280
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> We must refactor SparseDistributedMatrix for decrease communication during 
> computations.



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

[jira] [Updated] (IGNITE-5280) SparseDistributedMatrix refactoring

[Yury Babak (JIRA)]

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

Yury Babak updated IGNITE-5280:
---
Summary: SparseDistributedMatrix refactoring  (was: SparseDistributedMatrix 
refactorig)

> SparseDistributedMatrix refactoring
> ---
>
> Key: IGNITE-5280
> URL: https://issues.apache.org/jira/browse/IGNITE-5280
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> We must refactor SparseDistributedMatrix for decrease communication during 
> computations.



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

[jira] [Commented] (IGNITE-4643) JdbcDatabaseMetadata.getIndexInfo() method not working

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4643:


Github user asfgit closed the pull request at:

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


> JdbcDatabaseMetadata.getIndexInfo() method not working
> --
>
> Key: IGNITE-4643
> URL: https://issues.apache.org/jira/browse/IGNITE-4643
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
> Fix For: 2.2
>
>
> {{JdbcDatabaseMetadata.getIndexInfo()}} method does not update metadata 
> before creating result set. So if it's a first method invocation on this 
> instance of {{JdbcDatabaseMetadata}}, it fails with NPE. Need to create tests 
> and add {{updateMetaData()}} call in the beginning of the method.



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

[jira] [Created] (IGNITE-6170) JDBC: consistent product name across all drivers

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6170:
---

 Summary: JDBC: consistent product name across all drivers
 Key: IGNITE-6170
 URL: https://issues.apache.org/jira/browse/IGNITE-6170
 Project: Ignite
  Issue Type: Bug
  Components: jdbc
Affects Versions: 2.0
Reporter: Vladimir Ozerov
 Fix For: 2.2


We have 3 JDBC drivers. Some of them report 
{{DatabaseMetaData#getDatabaseProductName}} as *Ignite*, others as *Ignite 
Cache*. Neither are correct. 

It should be *Apache Ignite*.



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

[jira] [Updated] (IGNITE-5280) SparseDistributedMatrix refactorig

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko updated IGNITE-5280:
---
Summary: SparseDistributedMatrix refactorig  (was: SparseDistributedMatrix 
refactoring)

> SparseDistributedMatrix refactorig
> --
>
> Key: IGNITE-5280
> URL: https://issues.apache.org/jira/browse/IGNITE-5280
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> We must refactor SparseDistributedMatrix for decrease communication during 
> computations.



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

[jira] [Updated] (IGNITE-5280) SparseDistributedMatrix refactoring

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko updated IGNITE-5280:
---
Summary: SparseDistributedMatrix refactoring  (was: SparseDistributedMatrix 
refactorig)

> SparseDistributedMatrix refactoring
> ---
>
> Key: IGNITE-5280
> URL: https://issues.apache.org/jira/browse/IGNITE-5280
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> We must refactor SparseDistributedMatrix for decrease communication during 
> computations.



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

[jira] [Commented] (IGNITE-5280) SparseDistributedMatrix refactorig

[Yury Babak (JIRA)]

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

Yury Babak commented on IGNITE-5280:


[~oignatenko], [~amalykh] please take a look on this.

> SparseDistributedMatrix refactorig
> --
>
> Key: IGNITE-5280
> URL: https://issues.apache.org/jira/browse/IGNITE-5280
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> We must refactor SparseDistributedMatrix for decrease communication during 
> computations.



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

[jira] [Commented] (IGNITE-5280) SparseDistributedMatrix refactorig

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5280:


GitHub user ybabak opened a pull request:

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

IGNITE-5280: SparseDistributedMatrix refactorig



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

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

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

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


commit 3889ad739ba9f8dc73f611619776610e8d44d355
Author: Yury Babak 
Date:   2017-08-10T10:12:03Z

IGNITE-5280: SparseDistributedMatrix refactorig
WIP

commit 34d390256516fedc31142d7b6246e802948f11f4
Author: Yury Babak 
Date:   2017-08-14T16:55:50Z

IGNITE-5280: SparseDistributedMatrix refactorig
WIP

commit 476e2e1b4e15635aeac5300628b693e99182de7b
Author: Yury Babak 
Date:   2017-08-18T15:04:12Z

Merge branch 'apacheMaster' into ignite-5280

commit a130b90c59691ec6ccc98271b82943e8561c38ed
Author: Yury Babak 
Date:   2017-08-18T17:19:18Z

IGNITE-5280: SparseDistributedMatrix refactorig
WIP

commit ac6defdb10d11579634088832823a50e22ab4cef
Author: Yury Babak 
Date:   2017-08-22T11:41:50Z

IGNITE-5280: SparseDistributedMatrix refactorig
WIP

commit d6432ef1f7e72ce9f10b7084a9ae36fb8e31f9a7
Author: Yury Babak 
Date:   2017-08-23T12:55:44Z

IGNITE-5280: SparseDistributedMatrix refactorig
cleanup




> SparseDistributedMatrix refactorig
> --
>
> Key: IGNITE-5280
> URL: https://issues.apache.org/jira/browse/IGNITE-5280
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> We must refactor SparseDistributedMatrix for decrease communication during 
> computations.



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

[jira] [Resolved] (IGNITE-6108) Hangs in streamer when using store

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov resolved IGNITE-6108.
--
Resolution: Not A Bug

It's a known issue which is connected to several aspects of current 
architecture, it will be solved in future releases.

> Hangs in streamer when using store
> --
>
> Key: IGNITE-6108
> URL: https://issues.apache.org/jira/browse/IGNITE-6108
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Aleksey Chetaev
>Assignee: Igor Seliverstov
>Priority: Critical
> Attachments: logs_without memory_policy.zip, 
> log_with_memory_policy.zip
>
>
> I have hangs in IgniteStreamer benchmarks when using store with WAL mode 
> different from NONE. 
> Configuration: 1 client 4 servers.Cache mode:  transaction. Range 
> 400_000_000. 
> Problems: 
> * Time for next 100_000_000 entries every is always greater than for the 
> previous one.
> * We can found hangs for greater that 1 minutes in drivers logs. E.x. 
> 11:47:21 - 11:48:27 in archive named "log_with_memory_policy".
> Time for every 100_000_000 in seconds in log named "logs_without 
> memory_policy". 
> * 100_000_000 = 209
> * 200_000_000 = 323
> * 300_000_000 = 547
> * 400_000_000 = 722
> Yardstick logs in attachments. 



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

[jira] [Resolved] (IGNITE-6169) JDBC compatibility is broken

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-6169.
-
Resolution: Fixed

> JDBC compatibility is broken
> 
>
> Key: IGNITE-6169
> URL: https://issues.apache.org/jira/browse/IGNITE-6169
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.2
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>
> JDBC compatibility between 2.1 - 2.2 is broken in case the new JDBC driver 
> connects to an old Ignite node.
> Old server doesn't sent extended handshake response but JDBC client await it 
> without any conditions.



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

[jira] [Assigned] (IGNITE-6169) JDBC compatibility is broken

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-6169:
---

Assignee: Taras Ledkov  (was: Vladimir Ozerov)

> JDBC compatibility is broken
> 
>
> Key: IGNITE-6169
> URL: https://issues.apache.org/jira/browse/IGNITE-6169
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.2
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>
> JDBC compatibility between 2.1 - 2.2 is broken in case the new JDBC driver 
> connects to an old Ignite node.
> Old server doesn't sent extended handshake response but JDBC client await it 
> without any conditions.



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

[jira] [Commented] (IGNITE-6108) Hangs in streamer when using store

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov commented on IGNITE-6108:
--

There are two possible causes of slowdowns:
1) swap partition, which starts to be used in case of incorrect configuration 
(ignite is trying to use more memory than available on the server, some of used 
memory is allocated in swap partition what breaks overall performance)
2) rare or long checlpoints - if the checkpoint buffer became overflowed, 
ignate cannot perform update operations in parallel with checkpoints, it has to 
wait for current checkpoint finish to swap checkpoint buffer.

General recommendations are:

1) use 4 kb pages - it will significantly speed up write operations
2) use several checkpoint threads (4)
3) increase checkpoints frequency not to collect dirty pages and prevent 
checkpoint buffer overflow


> Hangs in streamer when using store
> --
>
> Key: IGNITE-6108
> URL: https://issues.apache.org/jira/browse/IGNITE-6108
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Aleksey Chetaev
>Assignee: Igor Seliverstov
>Priority: Critical
> Attachments: logs_without memory_policy.zip, 
> log_with_memory_policy.zip
>
>
> I have hangs in IgniteStreamer benchmarks when using store with WAL mode 
> different from NONE. 
> Configuration: 1 client 4 servers.Cache mode:  transaction. Range 
> 400_000_000. 
> Problems: 
> * Time for next 100_000_000 entries every is always greater than for the 
> previous one.
> * We can found hangs for greater that 1 minutes in drivers logs. E.x. 
> 11:47:21 - 11:48:27 in archive named "log_with_memory_policy".
> Time for every 100_000_000 in seconds in log named "logs_without 
> memory_policy". 
> * 100_000_000 = 209
> * 200_000_000 = 323
> * 300_000_000 = 547
> * 400_000_000 = 722
> Yardstick logs in attachments. 



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

[jira] [Created] (IGNITE-6169) JDBC compatibility is broken

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-6169:


 Summary: JDBC compatibility is broken
 Key: IGNITE-6169
 URL: https://issues.apache.org/jira/browse/IGNITE-6169
 Project: Ignite
  Issue Type: Bug
  Components: jdbc
Affects Versions: 2.2
Reporter: Taras Ledkov
Assignee: Vladimir Ozerov
 Fix For: 2.2


JDBC compatibility between 2.1 - 2.2 is broken in case the new JDBC driver 
connects to an old Ignite node.

Old server doesn't sent extended handshake response but JDBC client await it 
without any conditions.




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

[jira] [Assigned] (IGNITE-6168) Ability to use TLS client authentication in the TcpDiscoverySpi

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev reassigned IGNITE-6168:
---

Assignee: Ilya Kasnacheev

> Ability to use TLS client authentication in the TcpDiscoverySpi
> ---
>
> Key: IGNITE-6168
> URL: https://issues.apache.org/jira/browse/IGNITE-6168
> Project: Ignite
>  Issue Type: Wish
>Affects Versions: 2.1
>Reporter: Jens Borgland
>Assignee: Ilya Kasnacheev
>
> I'm working on an application where we use mutual TLS to protect the 
> communication (of different kinds) between the components. It seems like 
> Ignite uses mutual TLS for the TcpCommunicationSpi but not for the 
> TcpDiscoverySpi. Would it be possible to add this ability (one way could 
> perhaps be by implementing IGNITE-6167 so that it can be done through a 
> custom socket factory)?
> I'm aware that there are other client authentication options for the 
> discovery SPI but it would be nice to be able to use the same mechanism 
> everywhere.



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

[jira] [Commented] (IGNITE-6168) Ability to use TLS client authentication in the TcpDiscoverySpi

[Jens Borgland (JIRA)]

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

Jens Borgland commented on IGNITE-6168:
---

[~ilyak], makes sense since it seems to be a hard requirement for the 
TcpCommunicationSpi.

> Ability to use TLS client authentication in the TcpDiscoverySpi
> ---
>
> Key: IGNITE-6168
> URL: https://issues.apache.org/jira/browse/IGNITE-6168
> Project: Ignite
>  Issue Type: Wish
>Affects Versions: 2.1
>Reporter: Jens Borgland
>
> I'm working on an application where we use mutual TLS to protect the 
> communication (of different kinds) between the components. It seems like 
> Ignite uses mutual TLS for the TcpCommunicationSpi but not for the 
> TcpDiscoverySpi. Would it be possible to add this ability (one way could 
> perhaps be by implementing IGNITE-6167 so that it can be done through a 
> custom socket factory)?
> I'm aware that there are other client authentication options for the 
> discovery SPI but it would be nice to be able to use the same mechanism 
> everywhere.



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

[jira] [Commented] (IGNITE-6167) Ability to set custom SSLServerSocketFactory and SSLSocketFactory or enabled TLS protocols and cipher suites

[Jens Borgland (JIRA)]

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

Jens Borgland commented on IGNITE-6167:
---

[~ilyak], perhaps it's me who's missing something obvious but I cannot really 
find a reasonable way of subclassing SSLContext - and getSocketFactory() and 
getServerSocketFactory() are both final. I have however created my own 
SslContextFactory (in order to set up revocation checking the way I need) and 
that part works fine.

> Ability to set custom SSLServerSocketFactory and SSLSocketFactory or enabled 
> TLS protocols and cipher suites
> 
>
> Key: IGNITE-6167
> URL: https://issues.apache.org/jira/browse/IGNITE-6167
> Project: Ignite
>  Issue Type: Wish
>Affects Versions: 2.1
>Reporter: Jens Borgland
>
> It would be very useful to be able to, in addition to the 
> {{javax.net.ssl.SSLContext}}, either specify a custom 
> {{javax.net.ssl.SSLServerSocketFactory}} and a custom 
> {{javax.net.ssl.SSLSocketFactory}}, or to be able to at least specify the 
> enabled TLS protocols and cipher suites.
> I have noticed that the 
> {{org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter}} has support for 
> the latter but I cannot find a way of getting a reference to the filter 
> instance. The {{GridNioSslFilter}} also isn't used by {{TcpDiscoverySpi}} as 
> far as I can tell.
> Currently (as far as I can tell) there is no way of specifying the enabled 
> cipher suites and protocols used by Ignite, without doing it globally for the 
> JRE.



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

[jira] [Commented] (IGNITE-5655) Introduce pluggable string encoder/decoder

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5655:
-

[~andrey-kuznetsov], my comments:
1) {{BinaryConfiguration.encoding}} - passing it as a {{byte}} is bad idea as 
it limits total number of available encodings. We should pass it as {{String}}, 
in the same way as it is done in Java classes. In case encoding is not 
supported, an exception should be thrown.
2) {{OdbcColumnMeta, OdbcMessageParser}} - unnecessary changes; ODBC doesn't 
distinguish between String types, this is our internal implementation detail.
3) {{SqlListenerNioListener}} - another unnecessary change. We encode strings 
to save space in storage and page memory. Encoding strings when sending error 
message doesn't make sense.
4) {{SqlListenerUtils}} - unnecessary changes, as encoded strings are not 
supported in JDBC/ODBC at the moment (I do not see any changes in drivers). 
Hence, we should always talk to drivers using {{UTF-8}} strings.
5) {{BinaryStringEncoding}} - should be a part of public API, so let's move it 
to {{org.apache.ignite.binary}} package.
6) {{BinaryReaderExImpl.fieldFlagNames}} - looks like an overkill to me. Just 
concatenate two well-known flags by hand.
7) {{BinarySerializedFieldComparator}} - it is illegal to ignore encoding byte. 
You may endup with situation where two different strings are encoded with 
different encoding, but have similar binary representation. Your code will 
report {{true}}, while {{false}} should be returned. Correct flow here:
7.1) If objects have different encodings - deserialize them and compare using 
String.compareTo
7.2) If encodings are same, we need to understand whether encoded 
representation is comparable. For example, suppose that in certain encoding 
{{A}} represented as {{2}}, and {{B}} is represented as {{1}}. Then 
{{A.compareTo(B) == -1}}, but {{compareArrays(serialize(A), serialize(B) == 
1}}, which is wrong. E.g. see \[1\]. We need to think on how to expose this 
properly, but I think this is a different task. For now let's just restrict any 
binary comparison of non-UTF8 strings and always deserialize them.
8) Feature is definitely undertested. At the very least we need the following 
tests:
8.1) Run SQL queries with custom encoding
8.2) Start two nodes with different encoding and see how they interact with 
each other.

Not covered cases which I propose to implement separately: ODBC, JDBC, C++, 
.NET, efficient ocmparison for inlined indexes and 
BinarySerializedFieldComparator.

The rest looks good to me. Thanks for contribution!

\[1\] https://dev.mysql.com/doc/refman/5.7/en/charset-general.html

> Introduce pluggable string encoder/decoder
> --
>
> Key: IGNITE-5655
> URL: https://issues.apache.org/jira/browse/IGNITE-5655
> Project: Ignite
>  Issue Type: New Feature
>  Components: binary
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Assignee: Andrey Kuznetsov
> Fix For: 2.2
>
>
> Currently binary marshaller encodes strings in UTF-8. However, sometimes it 
> makes sense to serialize strings with different encodings to save space. 
> Let's add global property to control String encoding and customize our binary 
> protocol to support it. For instance, we can add another flag 
> {{ENCODED_STRING}}, which will write strings as follows:
> [flag][encoding_flag][str_len][str_bytes]
> First implementation should set preferred encoding for strings in 
> BinaryConfiguration. This setting is optional, default encoding is UTF-8. 
> Currently, the same BinaryConfiguration is used for all cluster nodes, thus 
> no encoding clashes are possible.



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

[jira] [Commented] (IGNITE-6168) Ability to use TLS client authentication in the TcpDiscoverySpi

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-6168:
-

[~jens.borgland] This looks like an issue indeed, because it is possible for 
two nodes to be stuck in "discovered but not connected and trying to connect 
forever" livelock state for good as I have just confirmed. I think that mutual 
TLS should be the only option in TcpDiscoverySpi.

> Ability to use TLS client authentication in the TcpDiscoverySpi
> ---
>
> Key: IGNITE-6168
> URL: https://issues.apache.org/jira/browse/IGNITE-6168
> Project: Ignite
>  Issue Type: Wish
>Affects Versions: 2.1
>Reporter: Jens Borgland
>
> I'm working on an application where we use mutual TLS to protect the 
> communication (of different kinds) between the components. It seems like 
> Ignite uses mutual TLS for the TcpCommunicationSpi but not for the 
> TcpDiscoverySpi. Would it be possible to add this ability (one way could 
> perhaps be by implementing IGNITE-6167 so that it can be done through a 
> custom socket factory)?
> I'm aware that there are other client authentication options for the 
> discovery SPI but it would be nice to be able to use the same mechanism 
> everywhere.



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

[jira] [Commented] (IGNITE-6164) H2 dependency is not resolved from ignite-indexing:2.1.0

[Pranas Baliuka (JIRA)]

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

Pranas Baliuka commented on IGNITE-6164:


It's not a bit thing to add missing  m2 dependency (minor), but ideally it
should be resolved as transitive runtime dependency.

P.S. some plans for upgrading to Gradle?

On Aug 23, 2017 8:57 PM, "Vladimir Ozerov (JIRA)"  wrote:


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

Vladimir Ozerov commented on IGNITE-6164:
-

[~pranas], I am not sure I understand what is the problem. Do you have
difficulties in resolving certain artifacts?

https://github.com/srecon/ignite-book-code-samples with dependecies:



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


> H2 dependency is not resolved from ignite-indexing:2.1.0
> 
>
> Key: IGNITE-6164
> URL: https://issues.apache.org/jira/browse/IGNITE-6164
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pranas Baliuka
>Priority: Minor
>
> I've tested the first code sample from Ignite book code 
> https://github.com/srecon/ignite-book-code-samples with dependecies:
> {code}
> 
> UTF-8
> 2.1.0
> 
> 
> 
> junit
> junit
> 3.8.1
> test
> 
> 
> org.apache.ignite
> ignite-core
> ${ignite.version}
> 
> 
> org.apache.ignite
> ignite-spring
> 
> 
> org.apache.ignite
> ignite-indexing
> 
> 
> {code}
> Runtime exception indicates what transitive dependency:
> {code}
> 
> com.h2database
> h2
> 1.4.195
> runtime
> 
> {code}
> is not resolved from the {{ignite-indexing}} . Consider fixing



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

[jira] [Commented] (IGNITE-6167) Ability to set custom SSLServerSocketFactory and SSLSocketFactory or enabled TLS protocols and cipher suites

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-6167:
-

[~jens.borgland] You can create your own subclass of SslContextFactory, 
overriding create(), which will return your own SSLContext, overriding 
getSocketFactory() and getServerSocketFactory() and returning custom socket 
factories. Anything obvious I am missing? Seems doable. Of course the usability 
of that solution is suboptimal.

> Ability to set custom SSLServerSocketFactory and SSLSocketFactory or enabled 
> TLS protocols and cipher suites
> 
>
> Key: IGNITE-6167
> URL: https://issues.apache.org/jira/browse/IGNITE-6167
> Project: Ignite
>  Issue Type: Wish
>Affects Versions: 2.1
>Reporter: Jens Borgland
>
> It would be very useful to be able to, in addition to the 
> {{javax.net.ssl.SSLContext}}, either specify a custom 
> {{javax.net.ssl.SSLServerSocketFactory}} and a custom 
> {{javax.net.ssl.SSLSocketFactory}}, or to be able to at least specify the 
> enabled TLS protocols and cipher suites.
> I have noticed that the 
> {{org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter}} has support for 
> the latter but I cannot find a way of getting a reference to the filter 
> instance. The {{GridNioSslFilter}} also isn't used by {{TcpDiscoverySpi}} as 
> far as I can tell.
> Currently (as far as I can tell) there is no way of specifying the enabled 
> cipher suites and protocols used by Ignite, without doing it globally for the 
> JRE.



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

[jira] [Created] (IGNITE-6168) Ability to use TLS client authentication in the TcpDiscoverySpi

[Jens Borgland (JIRA)]

Jens Borgland created IGNITE-6168:
-

 Summary: Ability to use TLS client authentication in the 
TcpDiscoverySpi
 Key: IGNITE-6168
 URL: https://issues.apache.org/jira/browse/IGNITE-6168
 Project: Ignite
  Issue Type: Wish
Affects Versions: 2.1
Reporter: Jens Borgland


I'm working on an application where we use mutual TLS to protect the 
communication (of different kinds) between the components. It seems like Ignite 
uses mutual TLS for the TcpCommunicationSpi but not for the TcpDiscoverySpi. 
Would it be possible to add this ability (one way could perhaps be by 
implementing IGNITE-6167 so that it can be done through a custom socket 
factory)?

I'm aware that there are other client authentication options for the discovery 
SPI but it would be nice to be able to use the same mechanism everywhere.



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

[jira] [Commented] (IGNITE-6164) H2 dependency is not resolved from ignite-indexing:2.1.0

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6164:
-

[~pranas], I am not sure I understand what is the problem. Do you have 
difficulties in resolving certain artifacts?

> H2 dependency is not resolved from ignite-indexing:2.1.0
> 
>
> Key: IGNITE-6164
> URL: https://issues.apache.org/jira/browse/IGNITE-6164
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pranas Baliuka
>Priority: Minor
>
> I've tested the first code sample from Ignite book code 
> https://github.com/srecon/ignite-book-code-samples with dependecies:
> {code}
> 
> UTF-8
> 2.1.0
> 
> 
> 
> junit
> junit
> 3.8.1
> test
> 
> 
> org.apache.ignite
> ignite-core
> ${ignite.version}
> 
> 
> org.apache.ignite
> ignite-spring
> 
> 
> org.apache.ignite
> ignite-indexing
> 
> 
> {code}
> Runtime exception indicates what transitive dependency:
> {code}
> 
> com.h2database
> h2
> 1.4.195
> runtime
> 
> {code}
> is not resolved from the {{ignite-indexing}} . Consider fixing



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

[jira] [Created] (IGNITE-6167) Ability to set custom SSLServerSocketFactory and SSLSocketFactory or enabled TLS protocols and cipher suites

[Jens Borgland (JIRA)]

Jens Borgland created IGNITE-6167:
-

 Summary: Ability to set custom SSLServerSocketFactory and 
SSLSocketFactory or enabled TLS protocols and cipher suites
 Key: IGNITE-6167
 URL: https://issues.apache.org/jira/browse/IGNITE-6167
 Project: Ignite
  Issue Type: Wish
Affects Versions: 2.1
Reporter: Jens Borgland


It would be very useful to be able to, in addition to the 
{{javax.net.ssl.SSLContext}}, either specify a custom 
{{javax.net.ssl.SSLServerSocketFactory}} and a custom 
{{javax.net.ssl.SSLSocketFactory}}, or to be able to at least specify the 
enabled TLS protocols and cipher suites.

I have noticed that the 
{{org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter}} has support for 
the latter but I cannot find a way of getting a reference to the filter 
instance. The {{GridNioSslFilter}} also isn't used by {{TcpDiscoverySpi}} as 
far as I can tell.

Currently (as far as I can tell) there is no way of specifying the enabled 
cipher suites and protocols used by Ignite, without doing it globally for the 
JRE.



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

[jira] [Assigned] (IGNITE-3471) Do not send previous value to client node for invoke() when possible

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov reassigned IGNITE-3471:


Assignee: (was: Alexandr Fedotov)

> Do not send previous value to client node for invoke() when possible
> 
>
> Key: IGNITE-3471
> URL: https://issues.apache.org/jira/browse/IGNITE-3471
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.4
>Reporter: Alexey Goncharuk
> Fix For: 2.2
>
> Attachments: CacheEntryProcessorTxSelfTest.java
>
>
> Currently for invoke() or invokeAll() methods we send previous cache value to 
> near node and apply EntryProcessor locally to get a return value. This can 
> induce a significant overhead when cache value is much larger than entry 
> processor result.
> For many cases this can be avoided, e.g.
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in 
> this case.
> tx.commit();
> }
> {code}
> Note that we need to add additional handling of such a case:
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in 
> this case.
> cache.get(key); // This should actually get the current cache value from 
> primary node and apply an entry processor locally to get the updated value.
> tx.commit();
> }
> {code}



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

[jira] [Assigned] (IGNITE-5569) TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a cluster DDoS

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev reassigned IGNITE-5569:
---

Assignee: Dmitry Karachentsev

> TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a 
> cluster DDoS
> -
>
> Key: IGNITE-5569
> URL: https://issues.apache.org/jira/browse/IGNITE-5569
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Alexey Goncharuk
>Assignee: Dmitry Karachentsev
> Fix For: 2.2
>
>
> A firewall configuration issue may effectively lead to a cluster DDoS. The 
> scheme is as follows:
> 1) A node G joins the cluster, and a firewall rule forbids incoming 
> connection from cluster to this node
> 2) Cluster successfully processes NodeAddedMesage and fires a discovery 
> NODE_JOINED event (not sure why?)
> 4) The last node in the ring fails to connect to the newly joined node and 
> generates NODE_FAILED event
> 5) Coordinator drops the connection, joining node attempts to connect again
> The issues I see here:
> 1) Neither coordinator nor joining node print out the reason why the joining 
> node failed / did not join. A slight hint (failed to send message to the next 
> node) is printed on the node with the largest order (the one that attempted 
> to close the ring), but the root cause (connection refused) is also not 
> printed
> 2) The joining node attempts to connect to the cluster with the same node ID. 
> This violates an invariant we heavily rely on that once a node ID leaves a 
> cluster, this ID never comes back again
> 3) Each discovery event leads to a partition exchange which blocks all cache 
> operations for a time interval equal at least to the full ring latency time. 
> If several nodes are started on a malicious host, this may lead to almost 
> full cluster degradation



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

[jira] [Updated] (IGNITE-5869) Unexpected timeout exception while client connecting with different BinaryConfiguration compactFooter param.

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-5869:

Summary: Unexpected timeout exception while client connecting with 
different BinaryConfiguration compactFooter param.  (was: Unexpected timeout 
exception while client connected with different BinaryConfiguration 
compactFooter param.)

> Unexpected timeout exception while client connecting with different 
> BinaryConfiguration compactFooter param.
> 
>
> Key: IGNITE-5869
> URL: https://issues.apache.org/jira/browse/IGNITE-5869
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.0
>Reporter: Stanilovsky Evgeny
>Assignee: Andrey Gura
> Fix For: 2.2
>
> Attachments: TcpClientDiscoveryMarshallerCheckSelfTest.java
>
>
> While client connecting with different from cluster 
> BinaryConfiguration::setCompactFooter param, instead of expecting: 
> "configuration is not equal" exception catch: Join process timed out 
> exception.



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

[jira] [Updated] (IGNITE-5869) Unexpected timeout exception while client connected with different BinaryConfiguration compactFooter param.

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-5869:

Fix Version/s: 2.2

> Unexpected timeout exception while client connected with different 
> BinaryConfiguration compactFooter param.
> ---
>
> Key: IGNITE-5869
> URL: https://issues.apache.org/jira/browse/IGNITE-5869
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.0
>Reporter: Stanilovsky Evgeny
>Assignee: Andrey Gura
> Fix For: 2.2
>
> Attachments: TcpClientDiscoveryMarshallerCheckSelfTest.java
>
>
> While client connecting with different from cluster 
> BinaryConfiguration::setCompactFooter param, instead of expecting: 
> "configuration is not equal" exception catch: Join process timed out 
> exception.



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

[jira] [Updated] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5038:

Component/s: (was: cache)
 binary

> BinaryMarshaller might need to use context class loader for deserialization
> ---
>
> Key: IGNITE-5038
> URL: https://issues.apache.org/jira/browse/IGNITE-5038
> Project: Ignite
>  Issue Type: New Feature
>  Components: binary
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Vladislav Pyatkov
>  Labels: features
> Fix For: 2.2
>
> Attachments: results-compound-20170802.zip, 
> results-compound-20170808.zip
>
>
> There is a special use case discussed on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224
> According to the use case, BinaryMarshaller might need to try to deserialize 
> an object using a context class loader if it failed to do so with a custom 
> classloader (`IgniteConfiguration.getClassLoader()`) or the system one.



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

[jira] [Commented] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5038:
-

[~v.pyatkov], my comments:
1) {{IgniteUtils.forName}} - {{noCache=true}} is ignored if passed classloader 
is null
2) {{GridBinaryMarshaller.unmarshal(..., ClassLoader)}} - why {{true}}? Looks 
like it should depend on passed classloader

As a whole I am very concerned of passing {{true}} flag all over the code. Why 
do we need it? As I understand, in order to understand whether cache should be 
used or not, we only need node's classloader and current classloader. Node's 
classloader is always somewhere near. Let's try to get rid of {{useCache}} as 
much as possible to minimize chance of error. We need clear invariant here.

> BinaryMarshaller might need to use context class loader for deserialization
> ---
>
> Key: IGNITE-5038
> URL: https://issues.apache.org/jira/browse/IGNITE-5038
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Vladislav Pyatkov
>  Labels: features
> Fix For: 2.2
>
> Attachments: results-compound-20170802.zip, 
> results-compound-20170808.zip
>
>
> There is a special use case discussed on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224
> According to the use case, BinaryMarshaller might need to try to deserialize 
> an object using a context class loader if it failed to do so with a custom 
> classloader (`IgniteConfiguration.getClassLoader()`) or the system one.



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

[jira] [Comment Edited] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-5038 at 8/23/17 9:09 AM:
--

[~v.pyatkov], my comments:
1) {{IgniteUtils.forName}} - {{noCache=true}} is ignored if passed classloader 
is null
2) {{GridBinaryMarshaller.unmarshal(..., ClassLoader)}} - why {{true}}? Looks 
like it should depend on passed classloader

As a whole I am very concerned of passing {{noCache}} flag all over the code. 
Why do we need it? As I understand, in order to understand whether cache should 
be used or not, we only need node's classloader and current classloader. Node's 
classloader is always somewhere near. Let's try to get rid of {{useCache}} as 
much as possible to minimize chance of error. We need clear invariant here.


was (Author: vozerov):
[~v.pyatkov], my comments:
1) {{IgniteUtils.forName}} - {{noCache=true}} is ignored if passed classloader 
is null
2) {{GridBinaryMarshaller.unmarshal(..., ClassLoader)}} - why {{true}}? Looks 
like it should depend on passed classloader

As a whole I am very concerned of passing {{true}} flag all over the code. Why 
do we need it? As I understand, in order to understand whether cache should be 
used or not, we only need node's classloader and current classloader. Node's 
classloader is always somewhere near. Let's try to get rid of {{useCache}} as 
much as possible to minimize chance of error. We need clear invariant here.

> BinaryMarshaller might need to use context class loader for deserialization
> ---
>
> Key: IGNITE-5038
> URL: https://issues.apache.org/jira/browse/IGNITE-5038
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Vladislav Pyatkov
>  Labels: features
> Fix For: 2.2
>
> Attachments: results-compound-20170802.zip, 
> results-compound-20170808.zip
>
>
> There is a special use case discussed on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224
> According to the use case, BinaryMarshaller might need to try to deserialize 
> an object using a context class loader if it failed to do so with a custom 
> classloader (`IgniteConfiguration.getClassLoader()`) or the system one.



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

[jira] [Created] (IGNITE-6166) Exceptions are printed to console, instead of log

[Dmitry Karachentsev (JIRA)]

Dmitry Karachentsev created IGNITE-6166:
---

 Summary: Exceptions are printed to console, instead of log
 Key: IGNITE-6166
 URL: https://issues.apache.org/jira/browse/IGNITE-6166
 Project: Ignite
  Issue Type: Bug
  Components: igfs
Affects Versions: 2.1
Reporter: Dmitry Karachentsev
Priority: Trivial
 Fix For: 2.2


IgniteSourceTask.TaskLocalListener,apply()
IgfsThread.run()

Exceptions should be logged.



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

[jira] [Created] (IGNITE-6165) Use SSL connection in IpcClientTcpEndpoint when it's configured for grid

[Dmitry Karachentsev (JIRA)]

Dmitry Karachentsev created IGNITE-6165:
---

 Summary: Use SSL connection in IpcClientTcpEndpoint when it's 
configured for grid
 Key: IGNITE-6165
 URL: https://issues.apache.org/jira/browse/IGNITE-6165
 Project: Ignite
  Issue Type: Improvement
  Components: igfs
Affects Versions: 2.1
Reporter: Dmitry Karachentsev
 Fix For: 2.2


HadoopIgfsIpcIo in start() method always opens insecure connection, even if SSL 
is configured (should be like in TcpDiscoverySpi.createSocket()), 
IpcServerTcpEndpoint must be protected as well.

{code}
if (isSslEnabled())
sock = sslSockFactory.createSocket();
else
sock = new Socket();
{code}




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

[jira] [Commented] (IGNITE-4643) JdbcDatabaseMetadata.getIndexInfo() method not working

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-4643:
--

The latest minimal changes looks good. It's OK with me.

> JdbcDatabaseMetadata.getIndexInfo() method not working
> --
>
> Key: IGNITE-4643
> URL: https://issues.apache.org/jira/browse/IGNITE-4643
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
> Fix For: 2.2
>
>
> {{JdbcDatabaseMetadata.getIndexInfo()}} method does not update metadata 
> before creating result set. So if it's a first method invocation on this 
> instance of {{JdbcDatabaseMetadata}}, it fails with NPE. Need to create tests 
> and add {{updateMetaData()}} call in the beginning of the method.



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

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

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-6095:
-

Assignee: Vasiliy Sisko

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




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

[jira] [Assigned] (IGNITE-6120) Web Console: Propagate "lazy" flag on Query screen

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-6120:
-

Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

> Web Console: Propagate "lazy" flag on Query screen
> --
>
> Key: IGNITE-6120
> URL: https://issues.apache.org/jira/browse/IGNITE-6120
> Project: Ignite
>  Issue Type: Task
>  Components: sql, wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.2
>
>




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

[jira] [Commented] (IGNITE-6120) Web Console: Propagate "lazy" flag on Query screen

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-6120:
---

Implemented possibility to execute lazy query.

> Web Console: Propagate "lazy" flag on Query screen
> --
>
> Key: IGNITE-6120
> URL: https://issues.apache.org/jira/browse/IGNITE-6120
> Project: Ignite
>  Issue Type: Task
>  Components: sql, wizards
>Reporter: Alexey Kuznetsov
>Assignee: Vasiliy Sisko
> Fix For: 2.2
>
>




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