[jira] [Commented] (IGNITE-6024) SQL: execute DML statements on the server when possible
[ https://issues.apache.org/jira/browse/IGNITE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203166#comment-16203166 ] Vladimir Ozerov commented on IGNITE-6024: - Renamed flag to {{skipReducerOnUpdate}}. > SQL: execute DML statements on the server when possible > --- > > Key: IGNITE-6024 > URL: https://issues.apache.org/jira/browse/IGNITE-6024 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Assignee: Sergey Kalashnikov > Labels: important, performance > Fix For: 2.3 > > > Currently we execute DML statements as follows: > 1) Get query result set to the client > 2) Construct entry processors and send them to servers in batches > This approach is inefficient as it causes a lot of unnecessary network > communication Instead, we should execute DML statements directly on server > nodes when it is possible. > Implementation considerations: > 1) Determine set of queries which could be processed in this way. E.g., > {{LIMIT/OFFSET}}, {{GROUP BY}}, {{ORDER BY}}, {{DISTINCT}}, etc. are out of > question - they must go through the client anyway. Probably > {{skipMergeTable}} flag is a good starting point (good, not precise!) > 2) Send request to every server and execute local DML right there > 3) No failover support at the moment - throw "partial update" exception if > topology is unstable > 4) Handle partition reservation carefully > 5) Transactions: we still have single coordinator - this is a client. When > MVCC and TX SQL is ready, client will assign proper counters to server > requests. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6024) SQL: execute DML statements on the server when possible
[ https://issues.apache.org/jira/browse/IGNITE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203167#comment-16203167 ] Vladimir Ozerov commented on IGNITE-6024: - Final test run: https://ci.ignite.apache.org/viewQueued.html?itemId=889324 > SQL: execute DML statements on the server when possible > --- > > Key: IGNITE-6024 > URL: https://issues.apache.org/jira/browse/IGNITE-6024 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Assignee: Sergey Kalashnikov > Labels: important, performance > Fix For: 2.3 > > > Currently we execute DML statements as follows: > 1) Get query result set to the client > 2) Construct entry processors and send them to servers in batches > This approach is inefficient as it causes a lot of unnecessary network > communication Instead, we should execute DML statements directly on server > nodes when it is possible. > Implementation considerations: > 1) Determine set of queries which could be processed in this way. E.g., > {{LIMIT/OFFSET}}, {{GROUP BY}}, {{ORDER BY}}, {{DISTINCT}}, etc. are out of > question - they must go through the client anyway. Probably > {{skipMergeTable}} flag is a good starting point (good, not precise!) > 2) Send request to every server and execute local DML right there > 3) No failover support at the moment - throw "partial update" exception if > topology is unstable > 4) Handle partition reservation carefully > 5) Transactions: we still have single coordinator - this is a client. When > MVCC and TX SQL is ready, client will assign proper counters to server > requests. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-4723) .NET: Support REGEXP_LIKE in LINQ
[ https://issues.apache.org/jira/browse/IGNITE-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203179#comment-16203179 ] ASF GitHub Bot commented on IGNITE-4723: GitHub user apopovgg opened a pull request: https://github.com/apache/ignite/pull/2842 IGNITE-4723 .NET: Support REGEXP_LIKE in LINQ You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4723 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2842.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 #2842 commit 5b77a02948885239418708edde91480e1b73fb0d Author: apopov Date: 2017-10-13T08:03:10Z IGNITE-4723 .NET: Support REGEXP_LIKE in LINQ > .NET: Support REGEXP_LIKE in LINQ > - > > Key: IGNITE-4723 > URL: https://issues.apache.org/jira/browse/IGNITE-4723 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Alexey Popov > Labels: .NET, LINQ, newbie > > {{REGEXP_REPLACE}} H2 function is supported in LINQ via {{Regex.Replace}}, > see {{MethodVisitor}}. > Add mapping for {{REGEXP_LIKE}} via {{Regex.IsMatch}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-4723) .NET: Support REGEXP_LIKE in LINQ
[ https://issues.apache.org/jira/browse/IGNITE-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203182#comment-16203182 ] Alexey Popov commented on IGNITE-4723: -- Changes: 1. {{Regex.IsMatch()}} added 2. Basic {{RegexOptions}} are supported for {{Regex.Replace()}} and {{Regex.IsMatch()}} 3. Corresponding string tests added [~ptupitsyn] Please review > .NET: Support REGEXP_LIKE in LINQ > - > > Key: IGNITE-4723 > URL: https://issues.apache.org/jira/browse/IGNITE-4723 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Alexey Popov > Labels: .NET, LINQ, newbie > Fix For: 2.4 > > > {{REGEXP_REPLACE}} H2 function is supported in LINQ via {{Regex.Replace}}, > see {{MethodVisitor}}. > Add mapping for {{REGEXP_LIKE}} via {{Regex.IsMatch}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6617) Web console: there is no error message that cluster is not active on Queries screen
Pavel Konstantinov created IGNITE-6617: -- Summary: Web console: there is no error message that cluster is not active on Queries screen Key: IGNITE-6617 URL: https://issues.apache.org/jira/browse/IGNITE-6617 Project: Ignite Issue Type: Bug Components: wizards Affects Versions: 2.1 Reporter: Pavel Konstantinov Fix For: 2.4 start cluster with persistent start web agent connected to this cluster open Queries on web console try to execute any 'select' query there is no error message that cluster is not active -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-5908) Web console: may failed to open non-root if user is not authorized
[ https://issues.apache.org/jira/browse/IGNITE-5908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov closed IGNITE-5908. -- > Web console: may failed to open non-root if user is not authorized > -- > > Key: IGNITE-5908 > URL: https://issues.apache.org/jira/browse/IGNITE-5908 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov > > For example try to open http://localhost/configuration/basic > Expected: should redirect to home page -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6482) Add support for groups count
[ https://issues.apache.org/jira/browse/IGNITE-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-6482: -- Assignee: (was: Pavel Konstantinov) > Add support for groups count > > > Key: IGNITE-6482 > URL: https://issues.apache.org/jira/browse/IGNITE-6482 > Project: Ignite > Issue Type: Improvement > Components: yardstick >Reporter: Pavel Konstantinov >Priority: Minor > > Current implementation supports only one group for caches. > We need improve it to support more then one group. > Each group will have / caches inside. > Applicable only if option -cc (caches count) is set. > Default groups count = 1. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6618) Do not show client nodes in node selection modal
Pavel Konstantinov created IGNITE-6618: -- Summary: Do not show client nodes in node selection modal Key: IGNITE-6618 URL: https://issues.apache.org/jira/browse/IGNITE-6618 Project: Ignite Issue Type: Bug Components: wizards Affects Versions: 2.1 Reporter: Pavel Konstantinov Fix For: 2.3 I tried to 'Execute on Selected Node' the following query {code} SELECT c.id, d.id, p.id, p.salary FROM "c_partitioned".City c inner join "c_partitioned".Department d on c.id=d.CTYID inner join "c_partitioned".Person p on d.id=p.depID and p.salary > 5000 inner join "c_partitioned".PersonBonus pb on p.id=pb.perID and pb.COUNT < 5000 where exists (select * from "c_partitioned".Person where rank > 0) {code} and selected a client node in the list of nodes and got exception {code} General error: "java.lang.NullPointerException"; SQL statement: SELECT c.id, d.id, p.id, p.salary FROM "c_partitioned".City c inner join "c_partitioned".Department d on c.id=d.CTYID inner join "c_partitioned".Person p on d.id=p.depID and p.salary > 5000 inner join "c_partitioned".PersonBonus pb on p.id=pb.perID and pb.COUNT < 5000 where exists (select * from "c_partitioned".Person where rank > 0) [5-195] {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6618) Web console: Do not show client nodes in node selection modal
[ https://issues.apache.org/jira/browse/IGNITE-6618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-6618: --- Summary: Web console: Do not show client nodes in node selection modal (was: Do not show client nodes in node selection modal) > Web console: Do not show client nodes in node selection modal > - > > Key: IGNITE-6618 > URL: https://issues.apache.org/jira/browse/IGNITE-6618 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.1 >Reporter: Pavel Konstantinov > Fix For: 2.3 > > > I tried to 'Execute on Selected Node' the following query > {code} > SELECT c.id, d.id, p.id, p.salary > FROM "c_partitioned".City c > inner join "c_partitioned".Department d > on c.id=d.CTYID > inner join "c_partitioned".Person p > on d.id=p.depID and p.salary > 5000 > inner join "c_partitioned".PersonBonus pb > on p.id=pb.perID and pb.COUNT < 5000 > where exists (select * from "c_partitioned".Person where rank > 0) > {code} > and selected a client node in the list of nodes > and got exception > {code} > General error: "java.lang.NullPointerException"; SQL statement: SELECT c.id, > d.id, p.id, p.salary > FROM "c_partitioned".City c > inner join "c_partitioned".Department d > on c.id=d.CTYID > inner join "c_partitioned".Person p > on d.id=p.depID and p.salary > 5000 > inner join "c_partitioned".PersonBonus pb > on p.id=pb.perID and pb.COUNT < 5000 > where exists (select * from "c_partitioned".Person where rank > 0) > [5-195] > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6592) Describe Ignite C++ pointer reading and writing semantics
[ https://issues.apache.org/jira/browse/IGNITE-6592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-6592: --- Assignee: Prachi Garg (was: Igor Sapego) > Describe Ignite C++ pointer reading and writing semantics > - > > Key: IGNITE-6592 > URL: https://issues.apache.org/jira/browse/IGNITE-6592 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.2 >Reporter: Igor Sapego >Assignee: Prachi Garg > Fix For: 2.3 > > > Need to describe how user can read and write nullable values using pointer > semantic in Ignite C++: > {code} > // One can write null value like this: > writer.WriteObject(nullptr); > // And read it like this: > std::unique_ptr nullableVal = reader.ReadObject(); > if (nullableVal) { > // Processing... > } > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6592) Describe Ignite C++ pointer reading and writing semantics
[ https://issues.apache.org/jira/browse/IGNITE-6592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203279#comment-16203279 ] Igor Sapego commented on IGNITE-6592: - Done. > Describe Ignite C++ pointer reading and writing semantics > - > > Key: IGNITE-6592 > URL: https://issues.apache.org/jira/browse/IGNITE-6592 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.2 >Reporter: Igor Sapego >Assignee: Prachi Garg > Fix For: 2.3 > > > Need to describe how user can read and write nullable values using pointer > semantic in Ignite C++: > {code} > // One can write null value like this: > writer.WriteObject(nullptr); > // And read it like this: > std::unique_ptr nullableVal = reader.ReadObject(); > if (nullableVal) { > // Processing... > } > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6619) .NET: Ignite Demo Application
Pavel Tupitsyn created IGNITE-6619: -- Summary: .NET: Ignite Demo Application Key: IGNITE-6619 URL: https://issues.apache.org/jira/browse/IGNITE-6619 Project: Ignite Issue Type: Task Components: examples, platforms Reporter: Pavel Tupitsyn We have a number of examples, but each of them demonstrates some particular feature in isolation. Let's create a fully-functional line-of-business CRUD .NET application that uses Ignite.NET as a database, demonstrating transactions, queries (SQL and LINQ), atomics, whatever we can put in there. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6608) .NET: Thin client documentation
[ https://issues.apache.org/jira/browse/IGNITE-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203285#comment-16203285 ] Pavel Tupitsyn commented on IGNITE-6608: Done, [~dmagda], please have a look. > .NET: Thin client documentation > --- > > Key: IGNITE-6608 > URL: https://issues.apache.org/jira/browse/IGNITE-6608 > Project: Ignite > Issue Type: Task > Components: documentation, platforms >Affects Versions: 2.3 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.3 > > > Document new Thin Client API on readme.io: > https://apacheignite-net.readme.io/docs -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6371) .NET: Thin client example
[ https://issues.apache.org/jira/browse/IGNITE-6371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203288#comment-16203288 ] Pavel Tupitsyn commented on IGNITE-6371: Merged to master: {{5ec744cf7fb0db0658f91176bf98dfe5ccb05be2}}. > .NET: Thin client example > - > > Key: IGNITE-6371 > URL: https://issues.apache.org/jira/browse/IGNITE-6371 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.4 > > > Create an example for thin client (requires external node started with > {{ignite.bat}} or {{Apache.Ignite.exe}}). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6371) .NET: Thin client example
[ https://issues.apache.org/jira/browse/IGNITE-6371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203290#comment-16203290 ] ASF GitHub Bot commented on IGNITE-6371: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/2830 > .NET: Thin client example > - > > Key: IGNITE-6371 > URL: https://issues.apache.org/jira/browse/IGNITE-6371 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.4 > > > Create an example for thin client (requires external node started with > {{ignite.bat}} or {{Apache.Ignite.exe}}). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6024) SQL: execute DML statements on the server when possible
[ https://issues.apache.org/jira/browse/IGNITE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203296#comment-16203296 ] ASF GitHub Bot commented on IGNITE-6024: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/2488 > SQL: execute DML statements on the server when possible > --- > > Key: IGNITE-6024 > URL: https://issues.apache.org/jira/browse/IGNITE-6024 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Assignee: Sergey Kalashnikov > Labels: important, performance > Fix For: 2.3 > > > Currently we execute DML statements as follows: > 1) Get query result set to the client > 2) Construct entry processors and send them to servers in batches > This approach is inefficient as it causes a lot of unnecessary network > communication Instead, we should execute DML statements directly on server > nodes when it is possible. > Implementation considerations: > 1) Determine set of queries which could be processed in this way. E.g., > {{LIMIT/OFFSET}}, {{GROUP BY}}, {{ORDER BY}}, {{DISTINCT}}, etc. are out of > question - they must go through the client anyway. Probably > {{skipMergeTable}} flag is a good starting point (good, not precise!) > 2) Send request to every server and execute local DML right there > 3) No failover support at the moment - throw "partial update" exception if > topology is unstable > 4) Handle partition reservation carefully > 5) Transactions: we still have single coordinator - this is a client. When > MVCC and TX SQL is ready, client will assign proper counters to server > requests. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6620) Document JDBC/ODBC "skipReducerOnUpdate" flag
Vladimir Ozerov created IGNITE-6620: --- Summary: Document JDBC/ODBC "skipReducerOnUpdate" flag Key: IGNITE-6620 URL: https://issues.apache.org/jira/browse/IGNITE-6620 Project: Ignite Issue Type: Bug Components: documentation Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.3 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6605) SQL: Merge and optimize backup query filter
[ https://issues.apache.org/jira/browse/IGNITE-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203312#comment-16203312 ] Vladimir Ozerov commented on IGNITE-6605: - One more run: https://ci.ignite.apache.org/viewQueued.html?itemId=889654 > SQL: Merge and optimize backup query filter > --- > > Key: IGNITE-6605 > URL: https://issues.apache.org/jira/browse/IGNITE-6605 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.3 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: performance > Fix For: 2.4 > > > 1) Merge two anonymous implementations as they does the same things. > 2) Get rid of binary search in favor of hash-based lookup. > 3) Do not create a filter for {{PARTITIONED}} cache with no backups when > there are no explicit partitions. > 4) In most cases we do not need real key/value! Only partition is needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5714) Context switching for pessimistic transactions
[ https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-5714: - Description: Support transaction suspend()\resume() operations for pessimistic transactions. Resume can be called in another thread. _But there is a problem_: Imagine, we started pessimistic transaction in thread T1 and then perform put operation, which leads to sending GridDistributedLockRequest to another node. Lock request contains thread id of the transaction. Then we call suspend, resume in another thread and we also must send messages to other nodes to change thread id. It seems complicated task.It’s better to get rid of sending thread id to the nodes. We can use transaction xid on other nodes instead of thread id. Xid is sent to nodes in GridDistributedLockRequest#nearXidVer _Proposed solution_ : On remote nodes instead of thread id of near transaction GridDistributedLockRequest#threadId use its xid GridDistributedLockRequest#nearXidVer. Remove usages of near transaction's thread id on remote nodes. was:Implement context switching for pessimistic transactions > Context switching for pessimistic transactions > -- > > Key: IGNITE-5714 > URL: https://issues.apache.org/jira/browse/IGNITE-5714 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov > > Support transaction suspend()\resume() operations for pessimistic > transactions. Resume can be called in another thread. >_But there is a problem_: Imagine, we started pessimistic transaction in > thread T1 and then perform put operation, which leads to sending > GridDistributedLockRequest to another node. Lock request contains thread id > of the transaction. Then we call suspend, resume in another thread and we > also must send messages to other nodes to change thread id. > It seems complicated task.It’s better to get rid of sending thread id to the > nodes. > We can use transaction xid on other nodes instead of thread id. Xid is sent > to nodes in GridDistributedLockRequest#nearXidVer >_Proposed solution_ : On remote nodes instead of thread id of near > transaction GridDistributedLockRequest#threadId use its xid > GridDistributedLockRequest#nearXidVer. > Remove usages of near transaction's thread id on remote nodes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6621) .NET: Disable thin client for 2.3 release
Pavel Tupitsyn created IGNITE-6621: -- Summary: .NET: Disable thin client for 2.3 release Key: IGNITE-6621 URL: https://issues.apache.org/jira/browse/IGNITE-6621 Project: Ignite Issue Type: Task Components: platforms, thin client Affects Versions: 2.3 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.3 2.3 is coming out soon, and thin client feature is far from being release-ready (small part of cache APIs is all we have), let's disable it in {{ignite-2.3}} branch. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5714) Context switching for pessimistic transactions
[ https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-5714: - Description: Support transaction suspend()\resume() operations for pessimistic transactions. Resume can be called in another thread. _+But there is a problem+_: Imagine, we started pessimistic transaction in thread T1 and then perform put operation, which leads to sending GridDistributedLockRequest to another node. Lock request contains thread id of the transaction. Then we call suspend, resume in another thread and we also must send messages to other nodes to change thread id. It seems complicated task.It’s better to get rid of sending thread id to the nodes. We can use transaction xid on other nodes instead of thread id. Xid is sent to nodes in GridDistributedLockRequest#nearXidVer _+Proposed solution+_ : On remote nodes instead of thread id of near transaction GridDistributedLockRequest#threadId use its xid GridDistributedLockRequest#nearXidVer. Remove usages of near transaction's thread id on remote nodes. was: Support transaction suspend()\resume() operations for pessimistic transactions. Resume can be called in another thread. _But there is a problem_: Imagine, we started pessimistic transaction in thread T1 and then perform put operation, which leads to sending GridDistributedLockRequest to another node. Lock request contains thread id of the transaction. Then we call suspend, resume in another thread and we also must send messages to other nodes to change thread id. It seems complicated task.It’s better to get rid of sending thread id to the nodes. We can use transaction xid on other nodes instead of thread id. Xid is sent to nodes in GridDistributedLockRequest#nearXidVer _Proposed solution_ : On remote nodes instead of thread id of near transaction GridDistributedLockRequest#threadId use its xid GridDistributedLockRequest#nearXidVer. Remove usages of near transaction's thread id on remote nodes. > Context switching for pessimistic transactions > -- > > Key: IGNITE-5714 > URL: https://issues.apache.org/jira/browse/IGNITE-5714 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov > > Support transaction suspend()\resume() operations for pessimistic > transactions. Resume can be called in another thread. >_+But there is a problem+_: Imagine, we started pessimistic transaction in > thread T1 and then perform put operation, which leads to sending > GridDistributedLockRequest to another node. Lock request contains thread id > of the transaction. Then we call suspend, resume in another thread and we > also must send messages to other nodes to change thread id. > It seems complicated task.It’s better to get rid of sending thread id to the > nodes. > We can use transaction xid on other nodes instead of thread id. Xid is sent > to nodes in GridDistributedLockRequest#nearXidVer >_+Proposed solution+_ : On remote nodes instead of thread id of near > transaction GridDistributedLockRequest#threadId use its xid > GridDistributedLockRequest#nearXidVer. > Remove usages of near transaction's thread id on remote nodes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6621) .NET: Disable thin client for 2.3 release
[ https://issues.apache.org/jira/browse/IGNITE-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-6621: --- Description: 2.3 is coming out soon, and thin client feature is far from being release-ready (small part of cache APIs is all we have), let's disable it in {{ignite-2.3}} branch to avoid confusing users. (was: 2.3 is coming out soon, and thin client feature is far from being release-ready (small part of cache APIs is all we have), let's disable it in {{ignite-2.3}} branch.) > .NET: Disable thin client for 2.3 release > - > > Key: IGNITE-6621 > URL: https://issues.apache.org/jira/browse/IGNITE-6621 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Affects Versions: 2.3 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.3 > > > 2.3 is coming out soon, and thin client feature is far from being > release-ready (small part of cache APIs is all we have), let's disable it in > {{ignite-2.3}} branch to avoid confusing users. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5608) SQL scripts execution capability
[ https://issues.apache.org/jira/browse/IGNITE-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203322#comment-16203322 ] Oleg Ostanin commented on IGNITE-5608: -- I've added more examples in help and .bat file for sqlline launch: > SQL scripts execution capability > > > Key: IGNITE-5608 > URL: https://issues.apache.org/jira/browse/IGNITE-5608 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Denis Magda >Assignee: Oleg Ostanin > Fix For: 2.3 > > > There should be a way to feed an SQL script to Ignite and execute it right > away. A script can consist of DDL command that will define cluster and SQL > configuration as well as of DML commands that, for instance, preload data > into Ignite. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5608) SQL scripts execution capability
[ https://issues.apache.org/jira/browse/IGNITE-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203322#comment-16203322 ] Oleg Ostanin edited comment on IGNITE-5608 at 10/13/17 9:53 AM: I've added more examples in help and .bat file for sqlline launch: https://ci.ignite.apache.org/viewLog.html?buildId=889637&tab=artifacts&buildTypeId=IgniteRelease_XxxFromMirrorIgniteRelease3PrepareVote#!1rrb2,1esn4zrslm4po was (Author: oleg-ostanin): I've added more examples in help and .bat file for sqlline launch: > SQL scripts execution capability > > > Key: IGNITE-5608 > URL: https://issues.apache.org/jira/browse/IGNITE-5608 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Denis Magda >Assignee: Oleg Ostanin > Fix For: 2.3 > > > There should be a way to feed an SQL script to Ignite and execute it right > away. A script can consist of DDL command that will define cluster and SQL > configuration as well as of DML commands that, for instance, preload data > into Ignite. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6622) User defined function doesn't work if query executed via ignite.context().query().querySqlFieldsNoCache(qry, true);
Pavel Konstantinov created IGNITE-6622: -- Summary: User defined function doesn't work if query executed via ignite.context().query().querySqlFieldsNoCache(qry, true); Key: IGNITE-6622 URL: https://issues.apache.org/jira/browse/IGNITE-6622 Project: Ignite Issue Type: Bug Affects Versions: 2.3 Reporter: Pavel Konstantinov User defined function doesn't work if query executed via ignite.context().query().querySqlFieldsNoCache(qry, true); -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6519) Race in SplitAwareTopologyValidator on activator and server node join
[ https://issues.apache.org/jira/browse/IGNITE-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203355#comment-16203355 ] ASF GitHub Bot commented on IGNITE-6519: Github user akuramshingg closed the pull request at: https://github.com/apache/ignite/pull/2767 > Race in SplitAwareTopologyValidator on activator and server node join > - > > Key: IGNITE-6519 > URL: https://issues.apache.org/jira/browse/IGNITE-6519 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.1 >Reporter: Alexandr Kuramshin >Assignee: Alexandr Kuramshin > > The following sequence may occur: > 1. {{SplitAwareTopologyValidator}} detects split, gets {{NOTVALID}} and > returns false from {{validate()}} > 2. Activator node joins and {{SplitAwareTopologyValidator}} gets {{REPAIRED}} > 3. Server node joins from other DC and it makes > {{SplitAwareTopologyValidator}} gets {{VALID}} > 4. Then the server node left the cluster and {{SplitAwareTopologyValidator}} > should return false from {{validate()}} in cause of next split > But current implementation makes {{SplitAwareTopologyValidator}} > auto-{{REPAIRED}}. Actually if the activator node will being forgotten to > leave the cluster it may automatically repair a split many times. But it > supposed to be manual operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6519) Race in SplitAwareTopologyValidator on activator and server node join
[ https://issues.apache.org/jira/browse/IGNITE-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203367#comment-16203367 ] ASF GitHub Bot commented on IGNITE-6519: GitHub user akuramshingg opened a pull request: https://github.com/apache/ignite/pull/2845 IGNITE-6519 Race in SplitAwareTopologyValidator on activator and server node join TestRecordingCommunicationSpi fix references IGNITE-6507 Commit can be lost in network split scenario You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6519 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2845.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 #2845 commit 25fefabd3a61df7de2bac48a49fe384107d02aa4 Author: Alexandr Kuramshin Date: 2017-10-13T10:27:12Z IGNITE-6519 Race in SplitAwareTopologyValidator on activator and server node join TestRecordingCommunicationSpi fix > Race in SplitAwareTopologyValidator on activator and server node join > - > > Key: IGNITE-6519 > URL: https://issues.apache.org/jira/browse/IGNITE-6519 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.1 >Reporter: Alexandr Kuramshin >Assignee: Alexandr Kuramshin > > The following sequence may occur: > 1. {{SplitAwareTopologyValidator}} detects split, gets {{NOTVALID}} and > returns false from {{validate()}} > 2. Activator node joins and {{SplitAwareTopologyValidator}} gets {{REPAIRED}} > 3. Server node joins from other DC and it makes > {{SplitAwareTopologyValidator}} gets {{VALID}} > 4. Then the server node left the cluster and {{SplitAwareTopologyValidator}} > should return false from {{validate()}} in cause of next split > But current implementation makes {{SplitAwareTopologyValidator}} > auto-{{REPAIRED}}. Actually if the activator node will being forgotten to > leave the cluster it may automatically repair a split many times. But it > supposed to be manual operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6623) Web console: export query result set doesn't work on Edge
Pavel Konstantinov created IGNITE-6623: -- Summary: Web console: export query result set doesn't work on Edge Key: IGNITE-6623 URL: https://issues.apache.org/jira/browse/IGNITE-6623 Project: Ignite Issue Type: Bug Components: wizards Reporter: Pavel Konstantinov Execute any query and try to Export\ExportAll in result table -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4887) Support transaction continuation in another thread
[ https://issues.apache.org/jira/browse/IGNITE-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-4887: - Description: Consider the following pseudo-code: {code:xml} IgniteTransactions transactions = ignite1.transactions(); Transaction tx = startTransaction(transactions); cache.put("key1", 1); tx.stop(); {code} And in another thread: {code:xml} transactions.txStart(tx); cache.put("key3", 3); cache.remove("key2"); tx.commit(); {code} The Api should be implemented , that let you continue transaction in another thread. method suspend() should mark the transaction as unavailable for further commit. method resume should resume the transaction. reason behind the proposal : Consider the next scenario: we begin transaction, doing some changes and start async future that will be able to introduce futher changes into transaction and commit it in the end. was: Consider the following pseudo-code: {code:xml} IgniteTransactions transactions = ignite1.transactions(); Transaction tx = startTransaction(transactions); cache.put("key1", 1); tx.stop(); {code} And in another thread: {code:xml} transactions.txStart(tx); cache.put("key3", 3); cache.remove("key2"); tx.commit(); {code} The Api should be implemented , that let you continue transaction in another thread. method stop() should mark the transaction as unavailable for further commit. method txStart() should resume the transaction. reason behind the proposal : Consider the next scenario: we begin transaction, doing some changes and start async future that will be able to introduce futher changes into transaction and commit it in the end. > Support transaction continuation in another thread > -- > > Key: IGNITE-4887 > URL: https://issues.apache.org/jira/browse/IGNITE-4887 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.9 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov > Attachments: HangTest.txt > > > Consider the following pseudo-code: > {code:xml} > IgniteTransactions transactions = ignite1.transactions(); > Transaction tx = startTransaction(transactions); > cache.put("key1", 1); > tx.stop(); > {code} > And in another thread: > {code:xml} > transactions.txStart(tx); > cache.put("key3", 3); > cache.remove("key2"); > tx.commit(); > {code} > The Api should be implemented , that let you continue transaction in another > thread. > method suspend() should mark the transaction as unavailable for further > commit. > method resume should resume the transaction. > reason behind the proposal : > Consider the next scenario: > we begin transaction, doing some changes and start async future that will be > able to introduce futher changes into transaction and commit it in the end. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5357) Replicated cache reads load balancing.
[ https://issues.apache.org/jira/browse/IGNITE-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203383#comment-16203383 ] Mikhail Lipkovich commented on IGNITE-5357: --- [~vozerov], [~ascherbakov] thanks both of you! Sorry for late response - I was on a vacation. So probably the question about version is not relevant anymore and it can be changed to 2.4 > Replicated cache reads load balancing. > -- > > Key: IGNITE-5357 > URL: https://issues.apache.org/jira/browse/IGNITE-5357 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.6 >Reporter: Alexei Scherbakov >Assignee: Mikhail Lipkovich > Labels: newbie > Fix For: 2.3 > > > Currently all read requests from client node to replicated cache will go > through primary node for key. > Need to select random affinity node in topology and send request here (only > if readFromBackups=true) > If where are server nodes collocated on same host with client, must select > target node from them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6605) SQL: Merge and optimize backup query filter
[ https://issues.apache.org/jira/browse/IGNITE-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203389#comment-16203389 ] ASF GitHub Bot commented on IGNITE-6605: Github user devozerov closed the pull request at: https://github.com/apache/ignite/pull/2836 > SQL: Merge and optimize backup query filter > --- > > Key: IGNITE-6605 > URL: https://issues.apache.org/jira/browse/IGNITE-6605 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.3 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: performance > Fix For: 2.4 > > > 1) Merge two anonymous implementations as they does the same things. > 2) Get rid of binary search in favor of hash-based lookup. > 3) Do not create a filter for {{PARTITIONED}} cache with no backups when > there are no explicit partitions. > 4) In most cases we do not need real key/value! Only partition is needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-4723) .NET: Support REGEXP_LIKE in LINQ
[ https://issues.apache.org/jira/browse/IGNITE-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203396#comment-16203396 ] Pavel Tupitsyn commented on IGNITE-4723: Looks good to me, merged to master: {{5e1a22db1c1da0e5d866fd5a465dd3cdc7b3ffa0}}. > .NET: Support REGEXP_LIKE in LINQ > - > > Key: IGNITE-4723 > URL: https://issues.apache.org/jira/browse/IGNITE-4723 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Alexey Popov > Labels: .NET, LINQ, newbie > Fix For: 2.4 > > > {{REGEXP_REPLACE}} H2 function is supported in LINQ via {{Regex.Replace}}, > see {{MethodVisitor}}. > Add mapping for {{REGEXP_LIKE}} via {{Regex.IsMatch}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6624) SQL: IndexingQueryCacheFilter should use immediate partition data if possible
Vladimir Ozerov created IGNITE-6624: --- Summary: SQL: IndexingQueryCacheFilter should use immediate partition data if possible Key: IGNITE-6624 URL: https://issues.apache.org/jira/browse/IGNITE-6624 Project: Ignite Issue Type: Task Components: cache, sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.4 We need to filter backup keys during query execution. Currently to achieve this we do the following: 1) Get row link 2) Materialize the row (!!!) 3) Create H2 row (H2 wrapping) 4) Then get key from H2 row (unwrapping) 5) Calculate partition through affinity function What it might look like: 1) Get row link 2) Get partition from link p.1 is very simple to implement. p.2 might be harded and probably should be implemented out of scope of this ticket. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-4723) .NET: Support REGEXP_LIKE in LINQ
[ https://issues.apache.org/jira/browse/IGNITE-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203397#comment-16203397 ] ASF GitHub Bot commented on IGNITE-4723: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/2842 > .NET: Support REGEXP_LIKE in LINQ > - > > Key: IGNITE-4723 > URL: https://issues.apache.org/jira/browse/IGNITE-4723 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Alexey Popov > Labels: .NET, LINQ, newbie > Fix For: 2.4 > > > {{REGEXP_REPLACE}} H2 function is supported in LINQ via {{Regex.Replace}}, > see {{MethodVisitor}}. > Add mapping for {{REGEXP_LIKE}} via {{Regex.IsMatch}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6005) [Test failed] GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe
[ https://issues.apache.org/jira/browse/IGNITE-6005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203400#comment-16203400 ] Andrey Gura commented on IGNITE-6005: - I think better way is using special code flow for operations with non-interruptible semantic. > [Test failed] > GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe > - > > Key: IGNITE-6005 > URL: https://issues.apache.org/jira/browse/IGNITE-6005 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Eduard Shangareev >Assignee: Nikolay Izhikov > Labels: MakeTeamcityGreenAgain > Fix For: 2.3 > > > Example of fail > https://ci.ignite.apache.org/viewLog.html?buildId=762788&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteDataStrucutures > Typical problem is > {code} > org.apache.ignite.IgniteInterruptedException: Failed to wait for asynchronous > operation permit (thread got interrupted). > at > org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:805) > at > org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:803) > at > org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:961) > at > org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1026) > at > org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at junit.framework.TestCase.runTest(TestCase.java:176) > at > org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.InterruptedException: null > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1301) > at java.util.concurrent.Semaphore.acquire(Semaphore.java:317) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOpAcquire(GridCacheAdapter.java:4314) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4177) > at > org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:196) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4509) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4490) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1324) > at > org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.get(GridCacheProxyImpl.java:329) > at > org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$5.applyx(DataStructuresProcessor.java:635) > at > org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.retryTopologySafe(DataStructuresProcessor.java:1519) > at > org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeDataStructure(DataStructuresProcessor.java:629) > at > org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeSemaphore(DataStructuresProcessor.java:1188) > at > org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1023) > at > org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at junit.framework.TestCase.runTest(TestCase.java:176) > at > org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000) > at > org.apache.ignite.testfr
[jira] [Commented] (IGNITE-4172) SQL: Add support for Java 8 Time API classes in date\time functions
[ https://issues.apache.org/jira/browse/IGNITE-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203415#comment-16203415 ] Alexandr Fedotov commented on IGNITE-4172: -- [~avinogradov], PR updated. Please verify. > SQL: Add support for Java 8 Time API classes in date\time functions > --- > > Key: IGNITE-4172 > URL: https://issues.apache.org/jira/browse/IGNITE-4172 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.0 >Reporter: Andrew Mashenkov >Assignee: Alexandr Fedotov > Labels: usability > Fix For: 2.4 > > > We have is issue with querying LocalDateTime objects with our SQL engine. > Next query can fails with error, if one of row localDateTimeField value has > zero-time: > select DATEDIFF('DAY', localDateTimeField, CURRENT_DATE ()) from t; > Startpoint is IgniteH2Indexing.wrap() method. > We need add support to these classes: LocalDate, LocalTime, LocalDateTime. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-3164) Add an option to send resulting value instead of entry processor in transactional cache
[ https://issues.apache.org/jira/browse/IGNITE-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Fedotov reassigned IGNITE-3164: Assignee: (was: Alexandr Fedotov) > Add an option to send resulting value instead of entry processor in > transactional cache > --- > > Key: IGNITE-3164 > URL: https://issues.apache.org/jira/browse/IGNITE-3164 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 1.5.0.final >Reporter: Valentin Kulichenko > > In some cases user can't guarantee that EP behaves consistently on all nodes. > In transactional cache this can lead to inconsistent cache, because we invoke > EP on both primary and backup nodes. > We can add {{withSendValueToBackup()}} flag (naming is arguable) which will > override current default behavior. > We also need to update documentation, especially provide the explanation of > EP behavior in atomic and transactional caches. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6625) JDBC thin: support SSL connection to Ignite node
Taras Ledkov created IGNITE-6625: Summary: JDBC thin: support SSL connection to Ignite node Key: IGNITE-6625 URL: https://issues.apache.org/jira/browse/IGNITE-6625 Project: Ignite Issue Type: Improvement Components: jdbc Affects Versions: 2.2 Reporter: Taras Ledkov Assignee: Taras Ledkov Fix For: 2.3 SSL connection must be supported for JDBC thin driver. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6624) SQL: IndexingQueryCacheFilter should use immediate partition data if possible
[ https://issues.apache.org/jira/browse/IGNITE-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203475#comment-16203475 ] ASF GitHub Bot commented on IGNITE-6624: GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/2847 IGNITE-6624 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6624 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2847.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 #2847 commit c4f0895aa71db35e684de210915a7ccd41ef514c Author: devozerov Date: 2017-10-12T08:11:32Z Removed unused method. commit 046ecb254628ee6fe2471b11f2f5da665b802b78 Author: devozerov Date: 2017-10-12T09:10:47Z WIP. commit 35999f4fffc433294057b40a925227e3882a Author: devozerov Date: 2017-10-12T09:19:21Z Fixed compilation. commit cf16a5181c02df8c16d310a8d94310e01d458d09 Author: devozerov Date: 2017-10-12T09:21:17Z Fix. commit 5846dffcb585c8aa010fc278dcec36ba90521d17 Author: devozerov Date: 2017-10-12T11:02:38Z WIP. commit bbeebee9572e86340fdc4228c4a27eb65418e7c8 Author: devozerov Date: 2017-10-12T11:21:20Z Fixed. commit 9ab5729303ac5221cef25028bd2761802ead52a3 Author: devozerov Date: 2017-10-12T11:26:48Z Fixed. commit de8a6645287f09292be59744515958bc0fcdfeec Author: devozerov Date: 2017-10-12T11:29:36Z Finalization. commit 37b9b68c40f3b8320f08c384a1657be2db4b8c29 Author: devozerov Date: 2017-10-12T11:33:10Z Do not create row. commit 60115cafe10b5bf9cad45b6e6e5337eb65cfb5ef Author: devozerov Date: 2017-10-12T13:26:06Z Merge branch 'master' into ignite-6605 commit 20a74cfd099cf54149f2abdd99ef9d3058236edd Author: devozerov Date: 2017-10-12T13:30:43Z Finalization. commit 71b235cad60a994294762f866987ee3862e00a45 Author: devozerov Date: 2017-10-12T13:35:02Z COMPATIBILITY: rename current class. commit e55e4a6e22c558fc5f47027afa93db8f1c18c487 Author: devozerov Date: 2017-10-12T13:36:15Z Returned old class. commit da60e04a78c9261059b3810a7454bc882a563569 Author: devozerov Date: 2017-10-12T13:40:35Z Revert "Returned old class." This reverts commit e55e4a6e22c558fc5f47027afa93db8f1c18c487. commit 6689035ea3b1808918a36a189720c53d130c380f Author: devozerov Date: 2017-10-12T13:40:45Z Revert "COMPATIBILITY: rename current class." This reverts commit 71b235cad60a994294762f866987ee3862e00a45. commit 50a7cc58b87c27db8bfe327851ce8e29a94de45a Author: devozerov Date: 2017-10-13T08:05:23Z Merge branch 'master' into ignite-6605 commit 3f787a8e34564964a8014f2fe3af59e4115c0341 Author: devozerov Date: 2017-10-13T09:27:08Z WIP. commit ac756bd4c798f509872be34c328f962ef968e6ed Author: devozerov Date: 2017-10-13T11:21:09Z Merge branch 'master' into ignite-6605-debug # Conflicts: # modules/core/src/main/java/org/apache/ignite/spi/indexing/IndexingQueryCacheFilter.java # modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/H2Cursor.java # modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/database/H2PkHashIndex.java # modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GridH2IndexBase.java commit 3fc237cfb5c44ca81ada69ad38643edf9bb31f95 Author: devozerov Date: 2017-10-13T12:17:36Z Cosmetics. > SQL: IndexingQueryCacheFilter should use immediate partition data if possible > - > > Key: IGNITE-6624 > URL: https://issues.apache.org/jira/browse/IGNITE-6624 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: performance > Fix For: 2.4 > > > We need to filter backup keys during query execution. Currently to achieve > this we do the following: > 1) Get row link > 2) Materialize the row (!!!) > 3) Create H2 row (H2 wrapping) > 4) Then get key from H2 row (unwrapping) > 5) Calculate partition through affinity function > What it might look like: > 1) Get row link > 2) Get partition from link > This ticket is to implement working with partitions rather than keys when > possible, -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6624) SQL: IndexingQueryCacheFilter should use immediate partition data if possible
[ https://issues.apache.org/jira/browse/IGNITE-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6624: Description: We need to filter backup keys during query execution. Currently to achieve this we do the following: 1) Get row link 2) Materialize the row (!!!) 3) Create H2 row (H2 wrapping) 4) Then get key from H2 row (unwrapping) 5) Calculate partition through affinity function What it might look like: 1) Get row link 2) Get partition from link This ticket is to implement working with partitions rather than keys when possible, was: We need to filter backup keys during query execution. Currently to achieve this we do the following: 1) Get row link 2) Materialize the row (!!!) 3) Create H2 row (H2 wrapping) 4) Then get key from H2 row (unwrapping) 5) Calculate partition through affinity function What it might look like: 1) Get row link 2) Get partition from link p.1 is very simple to implement. p.2 might be harded and probably should be implemented out of scope of this ticket. > SQL: IndexingQueryCacheFilter should use immediate partition data if possible > - > > Key: IGNITE-6624 > URL: https://issues.apache.org/jira/browse/IGNITE-6624 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: performance > Fix For: 2.4 > > > We need to filter backup keys during query execution. Currently to achieve > this we do the following: > 1) Get row link > 2) Materialize the row (!!!) > 3) Create H2 row (H2 wrapping) > 4) Then get key from H2 row (unwrapping) > 5) Calculate partition through affinity function > What it might look like: > 1) Get row link > 2) Get partition from link > This ticket is to implement working with partitions rather than keys when > possible, -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6621) .NET: Disable thin client for 2.3 release
[ https://issues.apache.org/jira/browse/IGNITE-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203465#comment-16203465 ] ASF GitHub Bot commented on IGNITE-6621: GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/2846 IGNITE-6621 .NET: Disable thin client You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6621 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2846.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 #2846 commit 6859178606d3ad4381b1a337473c360956296a20 Author: Pavel Tupitsyn Date: 2017-10-13T12:15:03Z IGNITE-6621 .NET: Disable thin client > .NET: Disable thin client for 2.3 release > - > > Key: IGNITE-6621 > URL: https://issues.apache.org/jira/browse/IGNITE-6621 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Affects Versions: 2.3 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.3 > > > 2.3 is coming out soon, and thin client feature is far from being > release-ready (small part of cache APIs is all we have), let's disable it in > {{ignite-2.3}} branch to avoid confusing users. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6626) SQL: Doesn't materialize rows when possible
[ https://issues.apache.org/jira/browse/IGNITE-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203477#comment-16203477 ] ASF GitHub Bot commented on IGNITE-6626: GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/2848 IGNITE-6626 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6626 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2848.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 #2848 commit c4f0895aa71db35e684de210915a7ccd41ef514c Author: devozerov Date: 2017-10-12T08:11:32Z Removed unused method. commit 046ecb254628ee6fe2471b11f2f5da665b802b78 Author: devozerov Date: 2017-10-12T09:10:47Z WIP. commit 35999f4fffc433294057b40a925227e3882a Author: devozerov Date: 2017-10-12T09:19:21Z Fixed compilation. commit cf16a5181c02df8c16d310a8d94310e01d458d09 Author: devozerov Date: 2017-10-12T09:21:17Z Fix. commit 5846dffcb585c8aa010fc278dcec36ba90521d17 Author: devozerov Date: 2017-10-12T11:02:38Z WIP. commit bbeebee9572e86340fdc4228c4a27eb65418e7c8 Author: devozerov Date: 2017-10-12T11:21:20Z Fixed. commit 9ab5729303ac5221cef25028bd2761802ead52a3 Author: devozerov Date: 2017-10-12T11:26:48Z Fixed. commit de8a6645287f09292be59744515958bc0fcdfeec Author: devozerov Date: 2017-10-12T11:29:36Z Finalization. commit 37b9b68c40f3b8320f08c384a1657be2db4b8c29 Author: devozerov Date: 2017-10-12T11:33:10Z Do not create row. commit 60115cafe10b5bf9cad45b6e6e5337eb65cfb5ef Author: devozerov Date: 2017-10-12T13:26:06Z Merge branch 'master' into ignite-6605 commit 20a74cfd099cf54149f2abdd99ef9d3058236edd Author: devozerov Date: 2017-10-12T13:30:43Z Finalization. commit 71b235cad60a994294762f866987ee3862e00a45 Author: devozerov Date: 2017-10-12T13:35:02Z COMPATIBILITY: rename current class. commit e55e4a6e22c558fc5f47027afa93db8f1c18c487 Author: devozerov Date: 2017-10-12T13:36:15Z Returned old class. commit da60e04a78c9261059b3810a7454bc882a563569 Author: devozerov Date: 2017-10-12T13:40:35Z Revert "Returned old class." This reverts commit e55e4a6e22c558fc5f47027afa93db8f1c18c487. commit 6689035ea3b1808918a36a189720c53d130c380f Author: devozerov Date: 2017-10-12T13:40:45Z Revert "COMPATIBILITY: rename current class." This reverts commit 71b235cad60a994294762f866987ee3862e00a45. commit 50a7cc58b87c27db8bfe327851ce8e29a94de45a Author: devozerov Date: 2017-10-13T08:05:23Z Merge branch 'master' into ignite-6605 commit 3f787a8e34564964a8014f2fe3af59e4115c0341 Author: devozerov Date: 2017-10-13T09:27:08Z WIP. commit ac756bd4c798f509872be34c328f962ef968e6ed Author: devozerov Date: 2017-10-13T11:21:09Z Merge branch 'master' into ignite-6605-debug # Conflicts: # modules/core/src/main/java/org/apache/ignite/spi/indexing/IndexingQueryCacheFilter.java # modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/H2Cursor.java # modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/database/H2PkHashIndex.java # modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GridH2IndexBase.java commit feec224213e2d13331b6dcae0ed16f735fcb7c7e Author: devozerov Date: 2017-10-13T12:15:03Z Implemented. commit 3fc237cfb5c44ca81ada69ad38643edf9bb31f95 Author: devozerov Date: 2017-10-13T12:17:36Z Cosmetics. commit fd1e90b08d5f9804c2e6160a63c3b09298d5e37c Author: devozerov Date: 2017-10-13T12:18:21Z Done. commit 836523dc77b14c43e7a56e5956daf6c85004d34f Author: devozerov Date: 2017-10-13T12:21:01Z Merge branch 'ignite-6624' into ignite-6626 # Conflicts: # modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/H2Cursor.java > SQL: Doesn't materialize rows when possible > --- > > Key: IGNITE-6626 > URL: https://issues.apache.org/jira/browse/IGNITE-6626 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: performance > Fix For: 2.4 > > > We need to filter backup keys during query execution. Currently to achieve > this we do the following: > 1) Get row link > 2) Materialize the row (!!!) > 3) Create H2 row (H2 wrapping) > 4) Then get key from H2 row (unwrapping) > 5) Calculate partition through affinity function > What it might look like: > 1) Get row link > 2) Get partition from l
[jira] [Created] (IGNITE-6626) SQL: Doesn't materialize rows when possible
Vladimir Ozerov created IGNITE-6626: --- Summary: SQL: Doesn't materialize rows when possible Key: IGNITE-6626 URL: https://issues.apache.org/jira/browse/IGNITE-6626 Project: Ignite Issue Type: Task Components: cache, sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6624) SQL: IndexingQueryCacheFilter should use immediate partition data if possible
[ https://issues.apache.org/jira/browse/IGNITE-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203487#comment-16203487 ] Vladimir Ozerov commented on IGNITE-6624: - Test run: https://ci.ignite.apache.org/viewQueued.html?itemId=890217 > SQL: IndexingQueryCacheFilter should use immediate partition data if possible > - > > Key: IGNITE-6624 > URL: https://issues.apache.org/jira/browse/IGNITE-6624 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: performance > Fix For: 2.4 > > > We need to filter backup keys during query execution. Currently to achieve > this we do the following: > 1) Get row link > 2) Materialize the row (!!!) > 3) Create H2 row (H2 wrapping) > 4) Then get key from H2 row (unwrapping) > 5) Calculate partition through affinity function > What it might look like: > 1) Get row link > 2) Get partition from link > This ticket is to implement working with partitions rather than keys when > possible, -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6626) SQL: Doesn't materialize rows when possible
[ https://issues.apache.org/jira/browse/IGNITE-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203488#comment-16203488 ] Vladimir Ozerov commented on IGNITE-6626: - Test run: https://ci.ignite.apache.org/viewQueued.html?itemId=890225 > SQL: Doesn't materialize rows when possible > --- > > Key: IGNITE-6626 > URL: https://issues.apache.org/jira/browse/IGNITE-6626 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: performance > Fix For: 2.4 > > > We need to filter backup keys during query execution. Currently to achieve > this we do the following: > 1) Get row link > 2) Materialize the row (!!!) > 3) Create H2 row (H2 wrapping) > 4) Then get key from H2 row (unwrapping) > 5) Calculate partition through affinity function > What it might look like: > 1) Get row link > 2) Get partition from link > This ticket is to implement row filtering on B+Tree level and avoid their > materialization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6626) SQL: Doesn't materialize rows when possible
[ https://issues.apache.org/jira/browse/IGNITE-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6626: Description: We need to filter backup keys during query execution. Currently to achieve this we do the following: 1) Get row link 2) Materialize the row (!!!) 3) Create H2 row (H2 wrapping) 4) Then get key from H2 row (unwrapping) 5) Calculate partition through affinity function What it might look like: 1) Get row link 2) Get partition from link This ticket is to implement row filtering on B+Tree level and avoid their materialization. > SQL: Doesn't materialize rows when possible > --- > > Key: IGNITE-6626 > URL: https://issues.apache.org/jira/browse/IGNITE-6626 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: performance > Fix For: 2.4 > > > We need to filter backup keys during query execution. Currently to achieve > this we do the following: > 1) Get row link > 2) Materialize the row (!!!) > 3) Create H2 row (H2 wrapping) > 4) Then get key from H2 row (unwrapping) > 5) Calculate partition through affinity function > What it might look like: > 1) Get row link > 2) Get partition from link > This ticket is to implement row filtering on B+Tree level and avoid their > materialization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6624) SQL: IndexingQueryCacheFilter should use immediate partition data if possible
[ https://issues.apache.org/jira/browse/IGNITE-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6624: Labels: performance (was: ) > SQL: IndexingQueryCacheFilter should use immediate partition data if possible > - > > Key: IGNITE-6624 > URL: https://issues.apache.org/jira/browse/IGNITE-6624 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: performance > Fix For: 2.4 > > > We need to filter backup keys during query execution. Currently to achieve > this we do the following: > 1) Get row link > 2) Materialize the row (!!!) > 3) Create H2 row (H2 wrapping) > 4) Then get key from H2 row (unwrapping) > 5) Calculate partition through affinity function > What it might look like: > 1) Get row link > 2) Get partition from link > This ticket is to implement working with partitions rather than keys when > possible, -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-4172) SQL: Add support for Java 8 Time API classes in date\time functions
[ https://issues.apache.org/jira/browse/IGNITE-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203494#comment-16203494 ] Anton Vinogradov commented on IGNITE-4172: -- [~asfedotov] Looks good to me. > SQL: Add support for Java 8 Time API classes in date\time functions > --- > > Key: IGNITE-4172 > URL: https://issues.apache.org/jira/browse/IGNITE-4172 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.0 >Reporter: Andrew Mashenkov >Assignee: Alexandr Fedotov > Labels: usability > Fix For: 2.4 > > > We have is issue with querying LocalDateTime objects with our SQL engine. > Next query can fails with error, if one of row localDateTimeField value has > zero-time: > select DATEDIFF('DAY', localDateTimeField, CURRENT_DATE ()) from t; > Startpoint is IgniteH2Indexing.wrap() method. > We need add support to these classes: LocalDate, LocalTime, LocalDateTime. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6621) .NET: Disable thin client for 2.3 release
[ https://issues.apache.org/jira/browse/IGNITE-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203532#comment-16203532 ] ASF GitHub Bot commented on IGNITE-6621: Github user ptupitsyn closed the pull request at: https://github.com/apache/ignite/pull/2846 > .NET: Disable thin client for 2.3 release > - > > Key: IGNITE-6621 > URL: https://issues.apache.org/jira/browse/IGNITE-6621 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Affects Versions: 2.3 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.3 > > > 2.3 is coming out soon, and thin client feature is far from being > release-ready (small part of cache APIs is all we have), let's disable it in > {{ignite-2.3}} branch to avoid confusing users. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6581) clent deadlock in spiStart
[ https://issues.apache.org/jira/browse/IGNITE-6581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203552#comment-16203552 ] Semen Boikov commented on IGNITE-6581: -- [~kdudkov], I think this issue should be fixed in this way: when client detects that it is disconnected but client join was never finished (joinLatch is not released), then there is no need to call notifyDiscovery. Thanks > clent deadlock in spiStart > -- > > Key: IGNITE-6581 > URL: https://issues.apache.org/jira/browse/IGNITE-6581 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.9 >Reporter: Konstantin Dudkov >Assignee: Konstantin Dudkov > > {code:java} > "tcp-client-disco-msg-worker-#4%soloots-tg-ManagementFabric%" #50 prio=5 > os_prio=0 tid=0x7fafecd50800 nid=0x469e sleeping[0x7fafc3bfa000] >java.lang.Thread.State: TIMED_WAITING (sleeping) > at java.lang.Thread.sleep(Native Method) > at > org.apache.ignite.internal.util.GridSpinReadWriteLock.tryWriteLock(GridSpinReadWriteLock.java:349) > at > org.apache.ignite.internal.GridKernalGatewayImpl.writeLock(GridKernalGatewayImpl.java:121) > at > org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3427) > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2400) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2379) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1707) > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > "main" #1 prio=5 os_prio=0 tid=0x7fafec01 nid=0x4644 waiting on > condition [0x7faff325] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00068a331ad0> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStart(ClientImpl.java:265) > at > org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1862) > at > org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:268) > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:690) > at > org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1682) > at > org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:940) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1814) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1605) > - locked <0x0004107210e8> (a > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance) > at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:569) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:516) > at org.apache.ignite.Ignition.start(Ignition.java:322) > at > com.workday.fabric.ignite.IgniteFabric.lambda$start$1(IgniteFabric.java:143) > at > com.workday.fabric.ignite.IgniteFabric$$Lambda$6/576020159.run(Unknown Source) > at > com.workday.fabric.util.InvocationInterceptor.invokeRunnable(InvocationInterceptor.java:119) > at com.workday.fabric.ignite.IgniteFabric.start(IgniteFabric.java:138) > - locked <0x0004107212e0> (a > com.workday.fabric.ignite.IgniteWorkdayFabric) > at > com.workday.fabric.FabricManager.ensureFabric(FabricManager.java:146) > - locked <0x000410721368> (a > java.util.concurrent.ConcurrentHashMap) > at > com.workday.fabric.WorkdayFabricManager.ensureFabric(WorkdayFabricManager.java:76) > at > com.workday.fabric.verifier.FabricVerifier.verify(FabricVerifier.java:347) > at > com.workday.fabric.verifier.FabricVerifier.main(FabricVerifier.java:276) > {code} -- This message was sent by Atlassian J
[jira] [Commented] (IGNITE-6621) .NET: Disable thin client for 2.3 release
[ https://issues.apache.org/jira/browse/IGNITE-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203597#comment-16203597 ] Pavel Tupitsyn commented on IGNITE-6621: Merged to {{ignite-2.3}}: {{6df7ebc430cf5a099474361b61b2593a5884992b}}. > .NET: Disable thin client for 2.3 release > - > > Key: IGNITE-6621 > URL: https://issues.apache.org/jira/browse/IGNITE-6621 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Affects Versions: 2.3 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.3 > > > 2.3 is coming out soon, and thin client feature is far from being > release-ready (small part of cache APIs is all we have), let's disable it in > {{ignite-2.3}} branch to avoid confusing users. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-6621) .NET: Disable thin client for 2.3 release
[ https://issues.apache.org/jira/browse/IGNITE-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-6621. Resolution: Fixed > .NET: Disable thin client for 2.3 release > - > > Key: IGNITE-6621 > URL: https://issues.apache.org/jira/browse/IGNITE-6621 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Affects Versions: 2.3 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.3 > > > 2.3 is coming out soon, and thin client feature is far from being > release-ready (small part of cache APIs is all we have), let's disable it in > {{ignite-2.3}} branch to avoid confusing users. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6336) .NET: Thin client: Create cache
[ https://issues.apache.org/jira/browse/IGNITE-6336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-6336: -- Assignee: Pavel Tupitsyn > .NET: Thin client: Create cache > --- > > Key: IGNITE-6336 > URL: https://issues.apache.org/jira/browse/IGNITE-6336 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > > Create caches from thin client (by name and from {{CacheConfiguration}}). > Implement {{ICache.GetConfiguration}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6338) .NET: Thin client: LINQ
[ https://issues.apache.org/jira/browse/IGNITE-6338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-6338: --- Labels: .NET linq (was: .NET) > .NET: Thin client: LINQ > --- > > Key: IGNITE-6338 > URL: https://issues.apache.org/jira/browse/IGNITE-6338 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn > Labels: .NET, linq > > Make sure LINQ works via thin client. This requires implementing > {{ICacheInternal}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4723) .NET: Support REGEXP_LIKE in LINQ
[ https://issues.apache.org/jira/browse/IGNITE-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-4723: --- Fix Version/s: (was: 2.4) 2.3 > .NET: Support REGEXP_LIKE in LINQ > - > > Key: IGNITE-4723 > URL: https://issues.apache.org/jira/browse/IGNITE-4723 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Alexey Popov > Labels: .NET, LINQ, newbie > Fix For: 2.3 > > > {{REGEXP_REPLACE}} H2 function is supported in LINQ via {{Regex.Replace}}, > see {{MethodVisitor}}. > Add mapping for {{REGEXP_LIKE}} via {{Regex.IsMatch}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5224) .NET: PadLeft and PadRight support in LINQ
[ https://issues.apache.org/jira/browse/IGNITE-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-5224: --- Fix Version/s: (was: 2.4) 2.3 > .NET: PadLeft and PadRight support in LINQ > -- > > Key: IGNITE-5224 > URL: https://issues.apache.org/jira/browse/IGNITE-5224 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Alexey Popov >Priority: Trivial > Labels: .NET, LINQ, newbie > Fix For: 2.3 > > > Add {{String.PadLeft}} and {{String.PadRight}} functions to LINQ, map them to > SQL {{LPAD}} and {{RPAD}}. See {{MethodVisitor.cs}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5608) SQL scripts execution capability
[ https://issues.apache.org/jira/browse/IGNITE-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203658#comment-16203658 ] Vladimir Ozerov commented on IGNITE-5608: - [~oleg-ostanin], my comments: 1) Let's utilize the same approach as in {{ignite.bat|sh}} - perform validation and startup in a single Java class. This way we will avoid duplication. 2) We should exit the program in case of connection failure. This is not the case now - I remain in sqlline terminal. Please consult to sqlline scripts to understand how they (vendor) achieve this. > SQL scripts execution capability > > > Key: IGNITE-5608 > URL: https://issues.apache.org/jira/browse/IGNITE-5608 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Denis Magda >Assignee: Oleg Ostanin > Fix For: 2.3 > > > There should be a way to feed an SQL script to Ignite and execute it right > away. A script can consist of DDL command that will define cluster and SQL > configuration as well as of DML commands that, for instance, preload data > into Ignite. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6627) .NET: cache deserialization fail with complex value type & enum
Alexey Popov created IGNITE-6627: Summary: .NET: cache deserialization fail with complex value type & enum Key: IGNITE-6627 URL: https://issues.apache.org/jira/browse/IGNITE-6627 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 2.2 Reporter: Alexey Popov There is an deserialization issue with complex structure. Please see the sample code below: {noformat} public enum SampleEnum : byte { One = 0, Two = 1, Three = 2 } {noformat} {noformat} var cache = ignite.GetOrCreateCache>>("mySampleCache"); cache.Put("DictData", Dict); var result = cache.Get("DictData"); {noformat} {{cache.Get("DictData"); }} fails with eception: {"The constructor to deserialize an object of type 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]' was not found."} if we change Dictionary> to Dictionary> then everything is ok -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum
[ https://issues.apache.org/jira/browse/IGNITE-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Popov updated IGNITE-6627: - Summary: .NET: cache deserialization fails with complex value type & enum (was: .NET: cache deserialization fail with complex value type & enum) > .NET: cache deserialization fails with complex value type & enum > > > Key: IGNITE-6627 > URL: https://issues.apache.org/jira/browse/IGNITE-6627 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.2 >Reporter: Alexey Popov > Labels: .NET > > There is an deserialization issue with complex structure. > Please see the sample code below: > {noformat} > public enum SampleEnum : byte > { > One = 0, > Two = 1, > Three = 2 > } > {noformat} > {noformat} > var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache"); > cache.Put("DictData", Dict); > var result = cache.Get("DictData"); > {noformat} > var result = cache.Get("DictData"); fails with exception: > {"The constructor to deserialize an object of type > 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]' > was not found."} > If we change > Dictionary> > to > Dictionary> > then everything works fine -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6627) .NET: cache deserialization fail with complex value type & enum
[ https://issues.apache.org/jira/browse/IGNITE-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Popov updated IGNITE-6627: - Labels: .NET (was: ) > .NET: cache deserialization fail with complex value type & enum > --- > > Key: IGNITE-6627 > URL: https://issues.apache.org/jira/browse/IGNITE-6627 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.2 >Reporter: Alexey Popov > Labels: .NET > > There is an deserialization issue with complex structure. > Please see the sample code below: > {noformat} > public enum SampleEnum : byte > { > One = 0, > Two = 1, > Three = 2 > } > {noformat} > {noformat} > var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache"); > cache.Put("DictData", Dict); > var result = cache.Get("DictData"); > {noformat} > var result = cache.Get("DictData"); fails with exception: > {"The constructor to deserialize an object of type > 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]' > was not found."} > If we change > Dictionary> > to > Dictionary> > then everything works fine -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum
[ https://issues.apache.org/jira/browse/IGNITE-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Popov reassigned IGNITE-6627: Assignee: Alexey Popov > .NET: cache deserialization fails with complex value type & enum > > > Key: IGNITE-6627 > URL: https://issues.apache.org/jira/browse/IGNITE-6627 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.2 >Reporter: Alexey Popov >Assignee: Alexey Popov > Labels: .NET > > There is an deserialization issue with complex structure. > Please see the sample code below: > {noformat} > public enum SampleEnum : byte > { > One = 0, > Two = 1, > Three = 2 > } > {noformat} > {noformat} > var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache"); > cache.Put("DictData", Dict); > var result = cache.Get("DictData"); > {noformat} > var result = cache.Get("DictData"); fails with exception: > {"The constructor to deserialize an object of type > 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]' > was not found."} > If we change > Dictionary> > to > Dictionary> > then everything works fine -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6627) .NET: cache deserialization fail with complex value type & enum
[ https://issues.apache.org/jira/browse/IGNITE-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Popov updated IGNITE-6627: - Description: There is an deserialization issue with complex structure. Please see the sample code below: {noformat} public enum SampleEnum : byte { One = 0, Two = 1, Three = 2 } {noformat} {noformat} var cache = ignite.GetOrCreateCache>>("mySampleCache"); cache.Put("DictData", Dict); var result = cache.Get("DictData"); {noformat} var result = cache.Get("DictData"); fails with exception: {"The constructor to deserialize an object of type 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]' was not found."} If we change Dictionary> to Dictionary> then everything works fine was: There is an deserialization issue with complex structure. Please see the sample code below: {noformat} public enum SampleEnum : byte { One = 0, Two = 1, Three = 2 } {noformat} {noformat} var cache = ignite.GetOrCreateCache>>("mySampleCache"); cache.Put("DictData", Dict); var result = cache.Get("DictData"); {noformat} {{cache.Get("DictData"); }} fails with eception: {"The constructor to deserialize an object of type 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]' was not found."} if we change Dictionary> to Dictionary> then everything is ok > .NET: cache deserialization fail with complex value type & enum > --- > > Key: IGNITE-6627 > URL: https://issues.apache.org/jira/browse/IGNITE-6627 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.2 >Reporter: Alexey Popov > Labels: .NET > > There is an deserialization issue with complex structure. > Please see the sample code below: > {noformat} > public enum SampleEnum : byte > { > One = 0, > Two = 1, > Three = 2 > } > {noformat} > {noformat} > var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache"); > cache.Put("DictData", Dict); > var result = cache.Get("DictData"); > {noformat} > var result = cache.Get("DictData"); fails with exception: > {"The constructor to deserialize an object of type > 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]' > was not found."} > If we change > Dictionary> > to > Dictionary> > then everything works fine -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6628) Make possible to rebuild all SQL indexes programmatically with enabled persistence.
Alexei Scherbakov created IGNITE-6628: - Summary: Make possible to rebuild all SQL indexes programmatically with enabled persistence. Key: IGNITE-6628 URL: https://issues.apache.org/jira/browse/IGNITE-6628 Project: Ignite Issue Type: Improvement Affects Versions: 2.0 Reporter: Alexei Scherbakov Assignee: Alexei Scherbakov Fix For: 2.4 We have unofficial way for rebuilding indexes, which is called on activation if index.bin is removed from PDS directory. Code is located here [1] I think it's ok to make it public for several cases: model is changed, index is damage, etc... Also current impl has a bug: CacheEntry in [2] is not touched, polluting heap and leading to OOM. [1] org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#beforeExchange [2] org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#rebuildIndexesFromHash -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6628) Make possible to rebuild all SQL indexes programmatically with enabled persistence.
[ https://issues.apache.org/jira/browse/IGNITE-6628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov updated IGNITE-6628: -- Description: We have unofficial way for rebuilding indexes, which is called on activation if index.bin is removed from PDS directory. Code is located here [1] I think it's ok to make it public for several cases: model is changed, index is damaged, etc... Also current impl has a bug: CacheEntry in [2] is not touched, polluting heap and leading to OOM. [1] org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#beforeExchange [2] org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#rebuildIndexesFromHash was: We have unofficial way for rebuilding indexes, which is called on activation if index.bin is removed from PDS directory. Code is located here [1] I think it's ok to make it public for several cases: model is changed, index is damage, etc... Also current impl has a bug: CacheEntry in [2] is not touched, polluting heap and leading to OOM. [1] org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#beforeExchange [2] org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#rebuildIndexesFromHash > Make possible to rebuild all SQL indexes programmatically with enabled > persistence. > --- > > Key: IGNITE-6628 > URL: https://issues.apache.org/jira/browse/IGNITE-6628 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov > Fix For: 2.4 > > > We have unofficial way for rebuilding indexes, which is called on activation > if index.bin is removed from PDS directory. > Code is located here [1] > I think it's ok to make it public for several cases: model is changed, index > is damaged, etc... > Also current impl has a bug: CacheEntry in [2] is not touched, polluting heap > and leading to OOM. > [1] > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#beforeExchange > [2] > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#rebuildIndexesFromHash -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6629) Make service automatic redeployment configurable in ServiceConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-6629: --- Summary: Make service automatic redeployment configurable in ServiceConfiguration (was: Make service persistence and automatic redeployment configurable in ServiceConfiguration) > Make service automatic redeployment configurable in ServiceConfiguration > > > Key: IGNITE-6629 > URL: https://issues.apache.org/jira/browse/IGNITE-6629 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 2.3 >Reporter: Ivan Rakov >Assignee: Alexey Goncharuk > Fix For: 2.4 > > > Before 2.3, if persistence was enabled globally, services were recovered > along with system cache. But in 2.3, persistence can be enabled for per data > region (IGNITE-6030), and system data region is not persistent. > We should add feaure to configure service redeployment after restart. > Service-related information should be stored in Metastore instead of system > cache. > IgniteChangeGlobalStateServiceTest#testDeployService should be fixed under > this ticket. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6629) Make service persistence and automatic redeployment configurable in ServiceConfiguration
Ivan Rakov created IGNITE-6629: -- Summary: Make service persistence and automatic redeployment configurable in ServiceConfiguration Key: IGNITE-6629 URL: https://issues.apache.org/jira/browse/IGNITE-6629 Project: Ignite Issue Type: Improvement Components: managed services Affects Versions: 2.3 Reporter: Ivan Rakov Assignee: Alexey Goncharuk Fix For: 2.4 Before 2.3, if persistence was enabled globally, services were recovered along with system cache. But in 2.3, persistence can be enabled for per data region (IGNITE-6030), and system data region is not persistent. We should add feaure to configure service redeployment after restart. Service-related information should be stored in Metastore instead of system cache. IgniteChangeGlobalStateServiceTest#testDeployService should be fixed under this ticket. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6630) Incorrect time units of average transaction commit/rollback duration cache metrics.
Pavel Pereslegin created IGNITE-6630: Summary: Incorrect time units of average transaction commit/rollback duration cache metrics. Key: IGNITE-6630 URL: https://issues.apache.org/jira/browse/IGNITE-6630 Project: Ignite Issue Type: Bug Reporter: Pavel Pereslegin Assignee: Pavel Pereslegin Priority: Minor AverageTxCommitTime and AverageTxRollbackTime metrics in CacheMetrics calculated in milliseconds instead of microseconds as pointed in javadoc. Simple junit repro: {code:java} public class CacheMetricsTxAvgTimeTest extends GridCommonAbstractTest { /** */ private CacheConfiguration cacheConfiguration(String name) { CacheConfiguration cacheConfiguration = new CacheConfiguration<>(name); cacheConfiguration.setCacheMode(CacheMode.PARTITIONED); cacheConfiguration.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL); cacheConfiguration.setStatisticsEnabled(true); return cacheConfiguration; } /** */ public void testTxCommitDuration() throws Exception { try ( Ignite node = startGrid(0)) { IgniteCache cache = node.createCache(cacheConfiguration(DEFAULT_CACHE_NAME)); try (Transaction tx = node.transactions().txStart()) { cache.put(1, 1); // Await 1 second. U.sleep(1_000); tx.commit(); } // Documentation says that this metric is in microseconds. float commitTime = cache.metrics().getAverageTxCommitTime(); // But this assertion will fail because it in milliseconds and returns only ~1000. assert commitTime >= 1_000_000; } } } {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6630) Incorrect time units of average transaction commit/rollback duration cache metrics.
[ https://issues.apache.org/jira/browse/IGNITE-6630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-6630: - Description: AverageTxCommitTime and AverageTxRollbackTime metrics in CacheMetrics calculated in milliseconds instead of microseconds as pointed in javadoc. Simple junit reproducer: {code:java} public class CacheMetricsTxAvgTimeTest extends GridCommonAbstractTest { /** */ private CacheConfiguration cacheConfiguration(String name) { CacheConfiguration cacheConfiguration = new CacheConfiguration<>(name); cacheConfiguration.setCacheMode(CacheMode.PARTITIONED); cacheConfiguration.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL); cacheConfiguration.setStatisticsEnabled(true); return cacheConfiguration; } /** */ public void testTxCommitDuration() throws Exception { try ( Ignite node = startGrid(0)) { IgniteCache cache = node.createCache(cacheConfiguration(DEFAULT_CACHE_NAME)); try (Transaction tx = node.transactions().txStart()) { cache.put(1, 1); // Await 1 second. U.sleep(1_000); tx.commit(); } // Documentation says that this metric is in microseconds. float commitTime = cache.metrics().getAverageTxCommitTime(); // But this assertion will fail because it in milliseconds and returns only ~1000. assert commitTime >= 1_000_000; } } } {code} was: AverageTxCommitTime and AverageTxRollbackTime metrics in CacheMetrics calculated in milliseconds instead of microseconds as pointed in javadoc. Simple junit repro: {code:java} public class CacheMetricsTxAvgTimeTest extends GridCommonAbstractTest { /** */ private CacheConfiguration cacheConfiguration(String name) { CacheConfiguration cacheConfiguration = new CacheConfiguration<>(name); cacheConfiguration.setCacheMode(CacheMode.PARTITIONED); cacheConfiguration.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL); cacheConfiguration.setStatisticsEnabled(true); return cacheConfiguration; } /** */ public void testTxCommitDuration() throws Exception { try ( Ignite node = startGrid(0)) { IgniteCache cache = node.createCache(cacheConfiguration(DEFAULT_CACHE_NAME)); try (Transaction tx = node.transactions().txStart()) { cache.put(1, 1); // Await 1 second. U.sleep(1_000); tx.commit(); } // Documentation says that this metric is in microseconds. float commitTime = cache.metrics().getAverageTxCommitTime(); // But this assertion will fail because it in milliseconds and returns only ~1000. assert commitTime >= 1_000_000; } } } {code} > Incorrect time units of average transaction commit/rollback duration cache > metrics. > --- > > Key: IGNITE-6630 > URL: https://issues.apache.org/jira/browse/IGNITE-6630 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Minor > Labels: metrics, newbie > > AverageTxCommitTime and AverageTxRollbackTime metrics in CacheMetrics > calculated in milliseconds instead of microseconds as pointed in javadoc. > Simple junit reproducer: > {code:java} > public class CacheMetricsTxAvgTimeTest extends GridCommonAbstractTest { > /** */ > private CacheConfiguration cacheConfiguration(String name) { > CacheConfiguration cacheConfiguration = new > CacheConfiguration<>(name); > cacheConfiguration.setCacheMode(CacheMode.PARTITIONED); > cacheConfiguration.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL); > cacheConfiguration.setStatisticsEnabled(true); > return cacheConfiguration; > } > /** */ > public void testTxCommitDuration() throws Exception { > try ( Ignite node = startGrid(0)) { > IgniteCache cache = > node.createCache(cacheConfiguration(DEFAULT_CACHE_NAME)); > try (Transaction tx = node.transactions().txStart()) { > cache.put(1, 1); > // Await 1 second. > U.sleep(1_000); > tx.commit(); > } > // Documentation says that this metric is in microseconds. > float commitTime = cache.metrics().getAverageTxCommitTime(); > // But this assertion will fail because it in milliseconds and > returns only ~1000. > assert commitTime >= 1_000_000; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6630) Incorrect time units of average transaction commit/rollback duration cache metrics.
[ https://issues.apache.org/jira/browse/IGNITE-6630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16204039#comment-16204039 ] ASF GitHub Bot commented on IGNITE-6630: GitHub user xtern opened a pull request: https://github.com/apache/ignite/pull/2854 IGNITE-6630 Time units fix. You can merge this pull request into a Git repository by running: $ git pull https://github.com/xtern/ignite IGNITE-6630 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2854.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 #2854 commit 73cdd7c96914b3a08551f918e2214a5fdb7a4390 Author: Pereslegin Pavel Date: 2017-10-13T19:01:40Z IGNITE-6630 Time units fix. > Incorrect time units of average transaction commit/rollback duration cache > metrics. > --- > > Key: IGNITE-6630 > URL: https://issues.apache.org/jira/browse/IGNITE-6630 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Minor > Labels: metrics, newbie > > AverageTxCommitTime and AverageTxRollbackTime metrics in CacheMetrics > calculated in milliseconds instead of microseconds as pointed in javadoc. > Simple junit reproducer: > {code:java} > public class CacheMetricsTxAvgTimeTest extends GridCommonAbstractTest { > /** */ > private CacheConfiguration cacheConfiguration(String name) { > CacheConfiguration cacheConfiguration = new > CacheConfiguration<>(name); > cacheConfiguration.setCacheMode(CacheMode.PARTITIONED); > cacheConfiguration.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL); > cacheConfiguration.setStatisticsEnabled(true); > return cacheConfiguration; > } > /** */ > public void testTxCommitDuration() throws Exception { > try ( Ignite node = startGrid(0)) { > IgniteCache cache = > node.createCache(cacheConfiguration(DEFAULT_CACHE_NAME)); > try (Transaction tx = node.transactions().txStart()) { > cache.put(1, 1); > // Await 1 second. > U.sleep(1_000); > tx.commit(); > } > // Documentation says that this metric is in microseconds. > float commitTime = cache.metrics().getAverageTxCommitTime(); > // But this assertion will fail because it in milliseconds and > returns only ~1000. > assert commitTime >= 1_000_000; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6631) Optimize GridH2KeyValueRowOnheap.getValue() method
Vladimir Ozerov created IGNITE-6631: --- Summary: Optimize GridH2KeyValueRowOnheap.getValue() method Key: IGNITE-6631 URL: https://issues.apache.org/jira/browse/IGNITE-6631 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.4 There are some unnecessary operations around this method: 1) Redundant recursion 2) Too big value cache Etc. Need to optimize it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6631) Optimize GridH2KeyValueRowOnheap.getValue() method
[ https://issues.apache.org/jira/browse/IGNITE-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16204142#comment-16204142 ] ASF GitHub Bot commented on IGNITE-6631: GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/2855 IGNITE-6631 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6631 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2855.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 #2855 commit 1438eb74b5789d8dbf5d241be0facae0766bc561 Author: devozerov Date: 2017-10-13T19:53:42Z Optos. commit c0db1bc8a04d16789eb36903bb05d9920389d98b Author: devozerov Date: 2017-10-13T20:12:34Z Fixed. commit be689c22c0409658ec84aba701c7b18d688c82f7 Author: devozerov Date: 2017-10-13T20:17:46Z Minors. > Optimize GridH2KeyValueRowOnheap.getValue() method > -- > > Key: IGNITE-6631 > URL: https://issues.apache.org/jira/browse/IGNITE-6631 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: 2.4 > > > There are some unnecessary operations around this method: > 1) Redundant recursion > 2) Too big value cache > Etc. > Need to optimize it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6631) Optimize GridH2KeyValueRowOnheap.getValue() method
[ https://issues.apache.org/jira/browse/IGNITE-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6631: Labels: performance (was: ) > Optimize GridH2KeyValueRowOnheap.getValue() method > -- > > Key: IGNITE-6631 > URL: https://issues.apache.org/jira/browse/IGNITE-6631 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: performance > Fix For: 2.4 > > > There are some unnecessary operations around this method: > 1) Redundant recursion > 2) Too big value cache > Etc. > Need to optimize it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6608) .NET: Thin client documentation
[ https://issues.apache.org/jira/browse/IGNITE-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16204283#comment-16204283 ] Denis Magda commented on IGNITE-6608: - [~ptupitsyn], I would add the following: * Examples on how to configure the thin client connection with App.config and Spring XML. Presently we have the source code approach only. * Specify the scope of the supported APIs such as cache get/put operations and scan queries. > .NET: Thin client documentation > --- > > Key: IGNITE-6608 > URL: https://issues.apache.org/jira/browse/IGNITE-6608 > Project: Ignite > Issue Type: Task > Components: documentation, platforms >Affects Versions: 2.3 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.3 > > > Document new Thin Client API on readme.io: > https://apacheignite-net.readme.io/docs -- This message was sent by Atlassian JIRA (v6.4.14#64029)