[jira] [Closed] (IGNITE-6048) Need to document how to connect to Ignite from external SQL tools
[ 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
[ 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] [Resolved] (IGNITE-6038) Update Data Grid page on the website to reflect Persistence
[ https://issues.apache.org/jira/browse/IGNITE-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-6038. - Resolution: Fixed Done. The diagram will be updated as a part of the new site design related activities. > 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] [Closed] (IGNITE-6038) Update Data Grid page on the website to reflect Persistence
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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&buildId=785893&branch_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
[ https://issues.apache.org/jira/browse/IGNITE-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&buildId=785893&branch_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
[ https://issues.apache.org/jira/browse/IGNITE-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&buildId=785893&branch_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
[ https://issues.apache.org/jira/browse/IGNITE-6125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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&buildId=785893&branch_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
[ https://issues.apache.org/jira/browse/IGNITE-6125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 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
[ https://issues.apache.org/jira/browse/IGNITE-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/IGNITE-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/IGNITE-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/IGNITE-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/IGNITE-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ 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
[ 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.
[ 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.
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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 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
[ https://issues.apache.org/jira/browse/IGNITE-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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-6094) Web console: Implement persistent store in demo mode.
[ https://issues.apache.org/jira/browse/IGNITE-6094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-6094: - Assignee: Vasiliy Sisko > Web console: Implement persistent store in demo mode. > - > > Key: IGNITE-6094 > URL: https://issues.apache.org/jira/browse/IGNITE-6094 > Project: Ignite > Issue Type: Bug > 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)