[jira] [Comment Edited] (IGNITE-6053) IgniteCache.clear clears local caches with same names on all server nodes
[ https://issues.apache.org/jira/browse/IGNITE-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16151389#comment-16151389 ] Roman Shtykh edited comment on IGNITE-6053 at 9/2/17 3:14 AM: -- [~ntikhonov] Thanks for checking it again! Btw, why would it be better to use the public pool for this method? I am just curious -- other methods in `GridCacheAdapter` use the system pool. Anyway, I changed it to the public pool for tests. I ran TC tests now. Looks good to me. If you are ok with it, I will merge. was (Author: roman_s): [~ntikhonov] Thanks for checking it again! Btw, why would it be better to use the public pool for this method? I am just curious -- other methods in `GridCacheAdapter` use the system pool. I ran TC tests now. Looks good to me. > IgniteCache.clear clears local caches with same names on all server nodes > - > > Key: IGNITE-6053 > URL: https://issues.apache.org/jira/browse/IGNITE-6053 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Evgenii Zhuravlev >Assignee: Roman Shtykh > Fix For: 2.3 > > > Clear on LOCAL cache should clear cache on the current node only, not on all > nodes, that have local caches with same names. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6053) IgniteCache.clear clears local caches with same names on all server nodes
[ https://issues.apache.org/jira/browse/IGNITE-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16151389#comment-16151389 ] Roman Shtykh commented on IGNITE-6053: -- [~ntikhonov] Thanks for checking it again! Btw, why would it be better to use the public pool for this method? I am just curious -- other methods in `GridCacheAdapter` use the system pool. I ran TC tests now. Looks good to me. > IgniteCache.clear clears local caches with same names on all server nodes > - > > Key: IGNITE-6053 > URL: https://issues.apache.org/jira/browse/IGNITE-6053 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Evgenii Zhuravlev >Assignee: Roman Shtykh > Fix For: 2.3 > > > Clear on LOCAL cache should clear cache on the current node only, not on all > nodes, that have local caches with same names. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-955) Local listener in continuous queries should not be mandatory
[
https://issues.apache.org/jira/browse/IGNITE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16151269#comment-16151269
]
Valentin Kulichenko commented on IGNITE-955:
[~yzhdanov], it does of course. But why do we require it if there is a use case
when it's not needed?
> Local listener in continuous queries should not be mandatory
>
>
> Key: IGNITE-955
> URL: https://issues.apache.org/jira/browse/IGNITE-955
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
> Labels: Usability
>
> We need to support the use case when remote filter is needed, but local
> listener is not (filter always returns {{false}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6133) Add clearNodeLocalMap() to IgniteMXBean
[ https://issues.apache.org/jira/browse/IGNITE-6133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16151205#comment-16151205 ] ASF GitHub Bot commented on IGNITE-6133: GitHub user vk23 opened a pull request: https://github.com/apache/ignite/pull/2582 IGNITE-6133 Added clearNodeLocalMap() method for IgniteMXBean. You can merge this pull request into a Git repository by running: $ git pull https://github.com/vk23/ignite master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2582.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 #2582 commit 39dbbfc0dd71e59c21ee8c6f58a26677f53d18e2 Author: vk Date: 2017-09-01T20:36:33Z IGNITE-6133 Added clearNodeLocalMap() method for IgniteMXBean. > Add clearNodeLocalMap() to IgniteMXBean > --- > > Key: IGNITE-6133 > URL: https://issues.apache.org/jira/browse/IGNITE-6133 > Project: Ignite > Issue Type: New Feature >Reporter: Yakov Zhdanov >Assignee: vk > Labels: newbie > > Sometimes it is handy to clear node local map on Ignite nodes esp when > testing some functionality. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6133) Add clearNodeLocalMap() to IgniteMXBean
[ https://issues.apache.org/jira/browse/IGNITE-6133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] vk reassigned IGNITE-6133: -- Assignee: vk > Add clearNodeLocalMap() to IgniteMXBean > --- > > Key: IGNITE-6133 > URL: https://issues.apache.org/jira/browse/IGNITE-6133 > Project: Ignite > Issue Type: New Feature >Reporter: Yakov Zhdanov >Assignee: vk > Labels: newbie > > Sometimes it is handy to clear node local map on Ignite nodes esp when > testing some functionality. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6247) Review Ignite & Cassandra Integration Documentation
[ https://issues.apache.org/jira/browse/IGNITE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6247: Priority: Critical (was: Major) > Review Ignite & Cassandra Integration Documentation > --- > > Key: IGNITE-6247 > URL: https://issues.apache.org/jira/browse/IGNITE-6247 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Critical > > Ignite & Cassandra [1] end users shared the feedback that the documentation > doesn't precisely state corner cases or pitfalls that might arise. > Specifically, consider these bullet points [2] by Roger Fischer. > Review the existing documentation and make sure all the points like these [2] > and another brought up in that discussion are documented there to avoid any > uncertainty. > [1] https://apacheignite-mix.readme.io/docs/ignite-with-apache-cassandra > [2] > http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-1-0-Thread-deadlock-on-DefaultSingletonBeanRegistry-getSingleton-td16481.html#a16604 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6247) Review Ignite & Cassandra Integration Documentation
Denis Magda created IGNITE-6247: --- Summary: Review Ignite & Cassandra Integration Documentation Key: IGNITE-6247 URL: https://issues.apache.org/jira/browse/IGNITE-6247 Project: Ignite Issue Type: Task Reporter: Denis Magda Assignee: Prachi Garg Ignite & Cassandra [1] end users shared the feedback that the documentation doesn't precisely state corner cases or pitfalls that might arise. Specifically, consider these bullet points [2] by Roger Fischer. Review the existing documentation and make sure all the points like these [2] and another brought up in that discussion are documented there to avoid any uncertainty. [1] https://apacheignite-mix.readme.io/docs/ignite-with-apache-cassandra [2] http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-1-0-Thread-deadlock-on-DefaultSingletonBeanRegistry-getSingleton-td16481.html#a16604 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6246) Document Durable Memory and Linux Kernel Tuning Parameters
[ https://issues.apache.org/jira/browse/IGNITE-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6246: Description: It's time to document Durable Memory and its Native Persistence tuning parameters. Let's start doing this for Linux based deployments first. https://apacheignite.readme.io/docs/durable-memory-tuning As for the operating system related settings we should borrow the parameters used for GC tuning: https://apacheignite.readme.io/v2.1/docs/jvm-and-system-tuning#gc-attacks-by-linux It's totally fine to have sections for different Linux distributions on that page (like RedHat 6 and 7) if the set of parameters varies. Documentation on @dev list: http://apache-ignite-developers.2346864.n4.nabble.com/Durable-Memory-and-Ignite-Persistence-Tuning-td21611.html was: It's time to document Durable Memory and its Native Persistence tuning parameters. Let's start doing this for Linux based deployments first. https://apacheignite.readme.io/docs/durable-memory-tuning As for the operating system related settings we should borrow the parameters used for GC tuning: https://apacheignite.readme.io/v2.1/docs/jvm-and-system-tuning#linux-kernel-tuning It's totally fine to have sections for different Linux distributions on that page (like RedHat 6 and 7) if the set of parameters varies. Documentation on @dev list: http://apache-ignite-developers.2346864.n4.nabble.com/Durable-Memory-and-Ignite-Persistence-Tuning-td21611.html > Document Durable Memory and Linux Kernel Tuning Parameters > -- > > Key: IGNITE-6246 > URL: https://issues.apache.org/jira/browse/IGNITE-6246 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Alexei Scherbakov >Priority: Critical > > It's time to document Durable Memory and its Native Persistence tuning > parameters. Let's start doing this for Linux based deployments first. > https://apacheignite.readme.io/docs/durable-memory-tuning > As for the operating system related settings we should borrow the parameters > used for GC tuning: > https://apacheignite.readme.io/v2.1/docs/jvm-and-system-tuning#gc-attacks-by-linux > It's totally fine to have sections for different Linux distributions on that > page (like RedHat 6 and 7) if the set of parameters varies. > Documentation on @dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/Durable-Memory-and-Ignite-Persistence-Tuning-td21611.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6246) Document Durable Memory and Linux Kernel Tuning Parameters
[ https://issues.apache.org/jira/browse/IGNITE-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6246: Priority: Critical (was: Major) > Document Durable Memory and Linux Kernel Tuning Parameters > -- > > Key: IGNITE-6246 > URL: https://issues.apache.org/jira/browse/IGNITE-6246 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Alexei Scherbakov >Priority: Critical > > It's time to document Durable Memory and its Native Persistence tuning > parameters. Let's start doing this for Linux based deployments first. > https://apacheignite.readme.io/docs/durable-memory-tuning > As for the operating system related settings we should borrow the parameters > used for GC tuning: > https://apacheignite.readme.io/v2.1/docs/jvm-and-system-tuning#linux-kernel-tuning > It's totally fine to have sections for different Linux distributions on that > page (like RedHat 6 and 7) if the set of parameters varies. > Documentation on @dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/Durable-Memory-and-Ignite-Persistence-Tuning-td21611.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6246) Document Durable Memory and Linux Kernel Tuning Parameters
[ https://issues.apache.org/jira/browse/IGNITE-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6246: Description: It's time to document Durable Memory and its Native Persistence tuning parameters. Let's start doing this for Linux based deployments first. https://apacheignite.readme.io/docs/durable-memory-tuning As for the operating system related settings we should borrow the parameters used for GC tuning: https://apacheignite.readme.io/v2.1/docs/jvm-and-system-tuning#linux-kernel-tuning It's totally fine to have sections for different Linux distributions on that page (like RedHat 6 and 7) if the set of parameters varies. Documentation on @dev list: http://apache-ignite-developers.2346864.n4.nabble.com/Durable-Memory-and-Ignite-Persistence-Tuning-td21611.html was: It's time to document Durable Memory and its Native Persistence tuning parameters. Let's start doing this for Linux based deployments first. https://apacheignite.readme.io/docs/durable-memory-tuning As for the operating system related settings we should borrow the parameters used for GC tuning: https://apacheignite.readme.io/v2.1/docs/jvm-and-system-tuning#linux-kernel-tuning It's totally fine to have sections for different Linux distributions on that page (like RedHat 6 and 7) if the set of parameters varies. > Document Durable Memory and Linux Kernel Tuning Parameters > -- > > Key: IGNITE-6246 > URL: https://issues.apache.org/jira/browse/IGNITE-6246 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Alexei Scherbakov > > It's time to document Durable Memory and its Native Persistence tuning > parameters. Let's start doing this for Linux based deployments first. > https://apacheignite.readme.io/docs/durable-memory-tuning > As for the operating system related settings we should borrow the parameters > used for GC tuning: > https://apacheignite.readme.io/v2.1/docs/jvm-and-system-tuning#linux-kernel-tuning > It's totally fine to have sections for different Linux distributions on that > page (like RedHat 6 and 7) if the set of parameters varies. > Documentation on @dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/Durable-Memory-and-Ignite-Persistence-Tuning-td21611.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6246) Document Durable Memory and Linux Kernel Tuning Parameters
[ https://issues.apache.org/jira/browse/IGNITE-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150926#comment-16150926 ] Denis Magda commented on IGNITE-6246: - [~ascherbakov], please suggest the Linux related settings. > Document Durable Memory and Linux Kernel Tuning Parameters > -- > > Key: IGNITE-6246 > URL: https://issues.apache.org/jira/browse/IGNITE-6246 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Alexei Scherbakov > > It's time to document Durable Memory and its Native Persistence tuning > parameters. Let's start doing this for Linux based deployments first. > https://apacheignite.readme.io/docs/durable-memory-tuning > As for the operating system related settings we should borrow the parameters > used for GC tuning: > https://apacheignite.readme.io/v2.1/docs/jvm-and-system-tuning#linux-kernel-tuning > It's totally fine to have sections for different Linux distributions on that > page (like RedHat 6 and 7) if the set of parameters varies. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6246) Document Durable Memory and Linux Kernel Tuning Parameters
Denis Magda created IGNITE-6246: --- Summary: Document Durable Memory and Linux Kernel Tuning Parameters Key: IGNITE-6246 URL: https://issues.apache.org/jira/browse/IGNITE-6246 Project: Ignite Issue Type: Task Reporter: Denis Magda Assignee: Alexei Scherbakov It's time to document Durable Memory and its Native Persistence tuning parameters. Let's start doing this for Linux based deployments first. https://apacheignite.readme.io/docs/durable-memory-tuning As for the operating system related settings we should borrow the parameters used for GC tuning: https://apacheignite.readme.io/v2.1/docs/jvm-and-system-tuning#linux-kernel-tuning It's totally fine to have sections for different Linux distributions on that page (like RedHat 6 and 7) if the set of parameters varies. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5750) Format of uptime for metrics
[ https://issues.apache.org/jira/browse/IGNITE-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150907#comment-16150907 ] ASF GitHub Bot commented on IGNITE-5750: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/2298 > Format of uptime for metrics > > > Key: IGNITE-5750 > URL: https://issues.apache.org/jira/browse/IGNITE-5750 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.0 >Reporter: Alexandr Kuramshin >Assignee: Yevgeniy Ignatyev >Priority: Trivial > Labels: newbie > Fix For: 2.3 > > > Metrics for local node shows uptime formatted as 00:00:00:000 > But the last colon should be changed to the dot. > Right format is 00:00:00.000 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-6040) Update Distributed SQL Database page on the website
[ https://issues.apache.org/jira/browse/IGNITE-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-6040. --- > Update Distributed SQL Database page on the website > --- > > Key: IGNITE-6040 > URL: https://issues.apache.org/jira/browse/IGNITE-6040 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Dmitriy Setrakyan >Assignee: Denis Magda > Labels: site > > # change DDL examples to pure SQL (without Java) > # change DML examples to pure SQL (without Java) > # change Query examples to pure SQL (without Java) > # add Java API section and show 1 Query, 1 DDL, 1 DML example from Java > # add .NET / C# API section and show 1 Query, 1 DDL, 1 DML example from C# > # add Other API section and show 1 Query, 1 DDL, 1 DML example from Python, > PHP, etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-6040) Update Distributed SQL Database page on the website
[ https://issues.apache.org/jira/browse/IGNITE-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-6040. - Resolution: Fixed Thanks [~ptupitsyn]! > Update Distributed SQL Database page on the website > --- > > Key: IGNITE-6040 > URL: https://issues.apache.org/jira/browse/IGNITE-6040 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Dmitriy Setrakyan >Assignee: Denis Magda > Labels: site > > # change DDL examples to pure SQL (without Java) > # change DML examples to pure SQL (without Java) > # change Query examples to pure SQL (without Java) > # add Java API section and show 1 Query, 1 DDL, 1 DML example from Java > # add .NET / C# API section and show 1 Query, 1 DDL, 1 DML example from C# > # add Other API section and show 1 Query, 1 DDL, 1 DML example from Python, > PHP, etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6188) ODBC: SQLFreeStmt failing if called before all the rows from the result set were fetched.
[
https://issues.apache.org/jira/browse/IGNITE-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150814#comment-16150814
]
ASF GitHub Bot commented on IGNITE-6188:
GitHub user isapego opened a pull request:
https://github.com/apache/ignite/pull/2581
IGNITE-6188: ODBC: Fix for SQLFreeStmt(SQL_CLOSE).
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6188
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2581.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 #2581
commit 54f1c71c6a743406bba4f82ce1bb0810912dece2
Author: Igor Sapego
Date: 2017-09-01T16:29:08Z
IGNITE-6188: Added test.
commit 7e30295db6cdb2571a0e996998cd0b6dc6785c1b
Author: Igor Sapego
Date: 2017-09-01T16:41:10Z
IGNITE-6188: Fix
> ODBC: SQLFreeStmt failing if called before all the rows from the result set
> were fetched.
> -
>
> Key: IGNITE-6188
> URL: https://issues.apache.org/jira/browse/IGNITE-6188
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Labels: important
> Fix For: 2.3
>
>
> Steps to reproduce:
> 1. Execute select query with more then 1 row in result set.
> 2. Fetch results and close the cursor before detecting end of result set.
> 3. Check for statement error.
> Error message:
> {noformat}
> HY000: Failed to find query with ID: 10
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6245) ODBC: update query should return affected rows number for non-batch queries as well.
Andrew Mashenkov created IGNITE-6245: Summary: ODBC: update query should return affected rows number for non-batch queries as well. Key: IGNITE-6245 URL: https://issues.apache.org/jira/browse/IGNITE-6245 Project: Ignite Issue Type: Bug Reporter: Andrew Mashenkov Fix For: 2.3 Looks like OdbcQueryExecuteResult class doesn't have rowAffected field that OdbcQueryExecuteBatchResult has. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5581) Local caches aren't stored
[ https://issues.apache.org/jira/browse/IGNITE-5581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-5581: - Fix Version/s: (was: 2.3) 2.1 > Local caches aren't stored > -- > > Key: IGNITE-5581 > URL: https://issues.apache.org/jira/browse/IGNITE-5581 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.1 >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov > Fix For: 2.1 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-4188) Savepoints support inside of Ignite Transactions
[
https://issues.apache.org/jira/browse/IGNITE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150749#comment-16150749
]
Ryabov Dmitrii commented on IGNITE-4188:
[~sboikov], rollback to savepoint can cause situation, when primary node will
have no keys locked, but still have {{GridDhtTxLocal}} transaction. After that
happen if {{GridNearTxLocal}} transaction will have no locked keys for this
node, it will not send commit/rollback request to this node. So I want to
delete such "empty" transaction during rollback to savepoint. Is it good idea?
Or may be I should rollback it instead of deleting? But for rollback I'll need
to do more changes because of same cache versions, mappings without
keys/partitions/nodes and etc.
> Savepoints support inside of Ignite Transactions
>
>
> Key: IGNITE-4188
> URL: https://issues.apache.org/jira/browse/IGNITE-4188
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Ryabov Dmitrii
> Fix For: 2.3
>
>
> A savepoint is a special mark inside a transaction that allows all commands
> that are executed after it was established to be rolled back, restoring the
> transaction state to what it was at the time of the savepoint.
> Here is a reference to the similar functionality implemented by some of RDBMs
> vendors.
> https://www.postgresql.org/docs/8.1/static/sql-savepoint.html
> https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_10001.htm
> http://dev.mysql.com/doc/refman/5.7/en/savepoint.html
> Consider the following example.
> {code}
> BEGIN;
> INSERT INTO table1 VALUES (1);
> SAVEPOINT my_savepoint;
> INSERT INTO table1 VALUES (2);
> ROLLBACK TO SAVEPOINT my_savepoint;
> INSERT INTO table1 VALUES (3);
> COMMIT;
> {code}
> The execution result must guarantee that only values 1 and 3 are inserted
> into table1.
> In Ignite, it should be supported this way (preserving the same behavior as
> above).
> {code}
> Ignite ignite = ;
> IgniteCache c = ;
> try (Transaction tx = ignite.transactions().txStart()) {
> c.put(1, 1);
>
> tx.savepoint("mysavepoint");
>
> c.put(2, 2);
>
> tx.rollbackToSavepoint("mysavepoint");
>
> c.put(3, 3);
>
> tx.commit();
> }
> {code}
> As a summary the following has to be supported on Ignite side:
> - The {{savepoint}} method which will set a named transaction savepoint with
> a name of an identifier.
> - Multiple savepoints defined within a transaction. The names of the
> savepoints have to differ from each other. If the current transaction has a
> savepoint with the same name, the old savepoint is deleted and a new one is
> set.
> - The {{rollbackToSavepoint}} method that will roll back all the changes done
> after a specific checkpoint establishment.
> - The {{releaseCheckpoint}} method that will destroy a savepoint, keeping the
> effects of commands executed after it was established.
> - Full support of the behavior listed above at the level of ODBC and JDBC
> drivers and DML (will be handled under separate tickets).
> - The behavior has to be support for all transactional modes.
> Original proposal on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/TX-savepoints-td12041.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6214) Binary metadata update may hang
[ https://issues.apache.org/jira/browse/IGNITE-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150720#comment-16150720 ] Sergey Chugunov commented on IGNITE-6214: - reviewed the change, looks good to me > Binary metadata update may hang > --- > > Key: IGNITE-6214 > URL: https://issues.apache.org/jira/browse/IGNITE-6214 > Project: Ignite > Issue Type: Bug >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov > Fix For: 2.3 > > Attachments: SqlInserter.java, sql-test-client.xml, > sql-test-default.xml, sql-test.xml > > > Sometimes client may hang when performing concurrent SQL updates. > Reproducing code is in the attachment. > The reason is that insert triggers metadata update, which may leave some of > the nodes infinitely waiting when performed concurrently. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6244) .NET: Thin client: ScanQuery
Pavel Tupitsyn created IGNITE-6244: -- Summary: .NET: Thin client: ScanQuery Key: IGNITE-6244 URL: https://issues.apache.org/jira/browse/IGNITE-6244 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.3 Implement ScanQuery in thin client. Challenges: * Query cursor. This will require some kind of HandleRegistry on Java side, so we can pass an ID back to client. * Predicate. Thin client is not .NET-specific. We need a way to support predicates in (at least) Java and .NET, there should be some platform id. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6236) .NET: Thin client: cache.Get and Put for user types
[
https://issues.apache.org/jira/browse/IGNITE-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150631#comment-16150631
]
Pavel Tupitsyn edited comment on IGNITE-6236 at 9/1/17 2:39 PM:
[~vozerov] done, please have a look, diff with {{IGNITE-5896}}.
was (Author: ptupitsyn):
[~vozerov] done, please have a look.
> .NET: Thin client: cache.Get and Put for user types
> ---
>
> Key: IGNITE-6236
> URL: https://issues.apache.org/jira/browse/IGNITE-6236
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.3
>
>
> Cache operations on user types require proper metadata handling. Make sure
> dynamic type registration works.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5869) Unexpected timeout exception while client connecting with different BinaryConfiguration compactFooter param.
[ https://issues.apache.org/jira/browse/IGNITE-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150648#comment-16150648 ] Andrey Gura commented on IGNITE-5869: - Merged to master branch. > Unexpected timeout exception while client connecting with different > BinaryConfiguration compactFooter param. > > > Key: IGNITE-5869 > URL: https://issues.apache.org/jira/browse/IGNITE-5869 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.0 >Reporter: Stanilovsky Evgeny >Assignee: Andrey Gura > Fix For: 2.3 > > Attachments: TcpClientDiscoveryMarshallerCheckSelfTest.java > > > While client connecting with different from cluster > BinaryConfiguration::setCompactFooter param, instead of expecting: > "configuration is not equal" exception catch: Join process timed out > exception. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6236) .NET: Thin client: cache.Get and Put for user types
[ https://issues.apache.org/jira/browse/IGNITE-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150631#comment-16150631 ] Pavel Tupitsyn commented on IGNITE-6236: [~vozerov] done, please have a look. > .NET: Thin client: cache.Get and Put for user types > --- > > Key: IGNITE-6236 > URL: https://issues.apache.org/jira/browse/IGNITE-6236 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.3 > > > Cache operations on user types require proper metadata handling. Make sure > dynamic type registration works. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6236) .NET: Thin client: cache.Get and Put for user types
[ https://issues.apache.org/jira/browse/IGNITE-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150621#comment-16150621 ] ASF GitHub Bot commented on IGNITE-6236: GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/2580 IGNITE-6236 .NET: Thin client: cache.Get and Put for user types You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6236 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2580.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 #2580 commit fe7699a44160da698bc37491f6858f88db6bfed8 Author: Pavel Tupitsyn Date: 2017-09-01T14:23:29Z IGNITE-6236 .NET: Thin client: cache.Get and Put for user types > .NET: Thin client: cache.Get and Put for user types > --- > > Key: IGNITE-6236 > URL: https://issues.apache.org/jira/browse/IGNITE-6236 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.3 > > > Cache operations on user types require proper metadata handling. Make sure > dynamic type registration works. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6236) .NET: Thin client: cache.Get and Put for user types
[ https://issues.apache.org/jira/browse/IGNITE-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-6236: --- Description: Cache operations on user types require proper metadata handling. Make sure dynamic type registration works. (was: Cache operations on user types require proper metadata handling. Make sure cache works with: * Dynamic type registration * Static type registration * Binary objects) > .NET: Thin client: cache.Get and Put for user types > --- > > Key: IGNITE-6236 > URL: https://issues.apache.org/jira/browse/IGNITE-6236 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.3 > > > Cache operations on user types require proper metadata handling. Make sure > dynamic type registration works. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5549) Ignite Cache Failover2: test suite hands up from CacheAsyncOperationsFailoverTxTest.testAsyncFailover()
[
https://issues.apache.org/jira/browse/IGNITE-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Lantukh reassigned IGNITE-5549:
Assignee: Ilya Lantukh
> Ignite Cache Failover2: test suite hands up from
> CacheAsyncOperationsFailoverTxTest.testAsyncFailover()
> ---
>
> Key: IGNITE-5549
> URL: https://issues.apache.org/jira/browse/IGNITE-5549
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Ilya Lantukh
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, test-fail
> Fix For: 2.3
>
> Attachments: ThreadDump0.log
>
>
> Timeout came from CacheAsyncOperationsFailoverTxTest.testAsyncFailover() test:
> http://ci.ignite.apache.org/viewLog.html?buildId=756819&buildTypeId=Ignite20Tests_IgniteCacheFailover2&tab=buildResultsDiv
> {noformat}
> ransaction has been already completed.
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:787)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:727)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:683)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:95)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:165)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:163)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:485)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> java.lang.Thread.run(Thread.java:745)
> [16:29:30]W: [org.apache.ignite:ignite-core]
> java.lang.AssertionError: Invalid threadId [this=GridCacheMvccCandidate
> [nodeId=d6f0c17e-68b3-4da7-bd02-914ada70, ver=GridCacheVersion
> [topVer=11427, order=1501856691702, nodeOrder=1], threadId=211336,
> id=30502322, topVer=AffinityTopologyVersion [topVer=126, minorTopVer=0],
> reentry=null, otherNodeId=d6f0c17e-68b3-4da7-bd02-914ada70,
> otherVer=GridCacheVersion [topVer=11427, order=1501856691702,
> nodeOrder=1], mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null,
> serOrder=null,
> key=org.apache.ignite.internal.processors.cache.distributed.CacheAsyncOperationsFailoverAbstractTest$TestKey
> [idHash=742616132, hash=-1080846605, key=48],
> masks=local=1|owner=0|rea
[jira] [Commented] (IGNITE-5849) Introduce ignite node persistent meta-store
[ https://issues.apache.org/jira/browse/IGNITE-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150548#comment-16150548 ] ASF GitHub Bot commented on IGNITE-5849: Github user kdudkov closed the pull request at: https://github.com/apache/ignite/pull/2464 > Introduce ignite node persistent meta-store > --- > > Key: IGNITE-5849 > URL: https://issues.apache.org/jira/browse/IGNITE-5849 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Konstantin Dudkov > Fix For: 2.3 > > > As persistence feature is being developed, we will have a need for a > component, which reliably stores arbitrary metadata about node and cluster. > We already have reserved partition IDs for this purpose, all we need to do is > to extend the partition store abstraction to store non-cache objects and make > sure this new store participates in all common recovery procedures. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5849) Introduce ignite node persistent meta-store
[ https://issues.apache.org/jira/browse/IGNITE-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150532#comment-16150532 ] Ilya Lantukh edited comment on IGNITE-5849 at 9/1/17 1:39 PM: -- [~kdudkov], Thanks for your pull request! I've performed review of your code, here are my remarks, questions and suggestions: - MetadataStorage - refactor, rename to IndexStorage and make subtype of MetaStorage. - Validate that cache with name "MetaStorage" cannot be created with meaningful error message. Also validate memory policy name. - MetaStorage put/remove - can we avoid synchronization at this level? CacheDataStore works without it. - MetaStorage.getOrAllocateMetas() - looks like copy/paste. Refactor? - MetaStorage.FreeListImpl.getRow(...) - looks like it does the same work as CacheDataRowAdapter.initFromLink(...). Reuse existing code, it already has fragmentation handling. - MetaStorage.start(...) - rename to init() or something else. Start(...) implicitly requires that stop(...) method also exists. - DataPageIO - reuse it for MetaStorage, skip unneeded fragments. - GridCacheDatabaseSharedManager.getMetastoreData() - unused method? .start0() - commented code? - IgniteCacheDatabaseSharedManager.addMemoryPolicy(...) and createPageEvictionTracker(...) - why protected? - IgniteWalRecoveryTest - add test that MetaStorage survives crash in the middle of checkpoint. Also remove unnecessary type casts in code. was (Author: ilantukh): [~kdudkov], Thanks for your pull request! I've performed review of your code, here are my remarks, questions and suggestions: - MetadataStorage - refactor, rename to IndexStorage and make subtype of MetaStorage. - Validate that cache with name "MetaStorage" cannot be created with meaningful error message. Also validate memory policy name. - MetaStorage put/remove - can we avoid synchronization at this level? CacheDataStore works without it. - MetaStorage.getOrAllocateMetas() - looks like copy/paste. Refactor? - MetaStorage.FreeListImpl.getRow(...) looks like it does the same as CacheDataRowAdapter.initFromLink(...). Reuse existing code, it already has fragmentation handling. - MetaStorage.start(...) - rename to init() or something else. Start(...) implicitly requires that stop(...) method also exists. - DataPageIO - reuse it for MetaStorage, skip unneeded fragments. - GridCacheDatabaseSharedManager.getMetastoreData() - unused method? .start0() - commented code? - IgniteCacheDatabaseSharedManager.addMemoryPolicy(...) and createPageEvictionTracker(...) - why protected? - IgniteWalRecoveryTest - add test that MetaStorage survives crash in the middle of checkpoint. Also remove unnecessary type casts in code. > Introduce ignite node persistent meta-store > --- > > Key: IGNITE-5849 > URL: https://issues.apache.org/jira/browse/IGNITE-5849 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Konstantin Dudkov > Fix For: 2.3 > > > As persistence feature is being developed, we will have a need for a > component, which reliably stores arbitrary metadata about node and cluster. > We already have reserved partition IDs for this purpose, all we need to do is > to extend the partition store abstraction to store non-cache objects and make > sure this new store participates in all common recovery procedures. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5849) Introduce ignite node persistent meta-store
[ https://issues.apache.org/jira/browse/IGNITE-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150532#comment-16150532 ] Ilya Lantukh commented on IGNITE-5849: -- [~kdudkov], Thanks for your pull request! I've performed review of your code, here are my remarks, questions and suggestions: - MetadataStorage - refactor, rename to IndexStorage and make subtype of MetaStorage. - Validate that cache with name "MetaStorage" cannot be created with meaningful error message. Also validate memory policy name. - MetaStorage put/remove - can we avoid synchronization at this level? CacheDataStore works without it. - MetaStorage.getOrAllocateMetas() - looks like copy/paste. Refactor? - MetaStorage.FreeListImpl.getRow(...) looks like it does the same as CacheDataRowAdapter.initFromLink(...). Reuse existing code, it already has fragmentation handling. - MetaStorage.start(...) - rename to init() or something else. Start(...) implicitly requires that stop(...) method also exists. - DataPageIO - reuse it for MetaStorage, skip unneeded fragments. - GridCacheDatabaseSharedManager.getMetastoreData() - unused method? .start0() - commented code? - IgniteCacheDatabaseSharedManager.addMemoryPolicy(...) and createPageEvictionTracker(...) - why protected? - IgniteWalRecoveryTest - add test that MetaStorage survives crash in the middle of checkpoint. Also remove unnecessary type casts in code. > Introduce ignite node persistent meta-store > --- > > Key: IGNITE-5849 > URL: https://issues.apache.org/jira/browse/IGNITE-5849 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Konstantin Dudkov > Fix For: 2.3 > > > As persistence feature is being developed, we will have a need for a > component, which reliably stores arbitrary metadata about node and cluster. > We already have reserved partition IDs for this purpose, all we need to do is > to extend the partition store abstraction to store non-cache objects and make > sure this new store participates in all common recovery procedures. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5884) Change default pageSize of page memory to 4KB
[ https://issues.apache.org/jira/browse/IGNITE-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148984#comment-16148984 ] Ivan Rakov edited comment on IGNITE-5884 at 9/1/17 1:26 PM: TC run: https://ci.ignite.apache.org/viewQueued.html?itemId=805712 was (Author: ivan.glukos): TC run: https://ci.ignite.apache.org/viewQueued.html?itemId=803028 > Change default pageSize of page memory to 4KB > - > > Key: IGNITE-5884 > URL: https://issues.apache.org/jira/browse/IGNITE-5884 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Critical > Labels: usability > Fix For: 2.3 > > Attachments: CpBenchmark.java, iostat.log, ssdlab.log > > > Checkpoint write speed is suboptimal with default 2K page on most UNIX-driven > enviroments with SSD disk. There are several reasons for this: > 1) Page size of linux page cache is 4k by default on most kernels (you can > check yours by "getconf PAGE_SIZE" command). With 2k random writes > vm.dirty_ratio threshold is reached two times faster than with 4k random > writes. > 2) Most SSD manufacturers don't expose actual disk page size, but they > recommend to write at least 4k at once. Also, 4k blocks are used during > benchmarking SSD random writes. > Related question: > https://superuser.com/questions/1168014/nvme-ssd-why-is-4k-writing-faster-than-reading > Article by Emmanuel Goossaert describing why writing less than a page is > сounterproductive: > http://codecapsule.com/2014/02/12/coding-for-ssds-part-3-pages-blocks-and-the-flash-translation-layer/ > I've prepared a checkpoint emulation benchmark (code and results attached). > Run on production-level hardware (CentOS, 100 GB RAM, total LFS size is > 100GB, vm.dirty_ratio=10) showed that checkpointing with 4k pages is much > more efficient than with 2k. > *Important: backwards compatibility must be ensured with LFS files created > with old 2k default page size.* -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5250) Unhelpful exception when value of wrong type is passed to H2
[
https://issues.apache.org/jira/browse/IGNITE-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5250:
Fix Version/s: 2.3
> Unhelpful exception when value of wrong type is passed to H2
>
>
> Key: IGNITE-5250
> URL: https://issues.apache.org/jira/browse/IGNITE-5250
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
> Attachments: ExampleNodeStartup.java
>
>
> For instance, if an SQL schema defined this way:
> {code}
> cfg.setIndexedTypes(AffinityKey.class, Person.class);
> {code}
> and then, by some reason, the users confuses the type of the key passing
> {{int}} instead of {{AffinityKey}}
> {code}
> SqlFieldsQuery query = new SqlFieldsQuery("INSERT INTO Person (_key,
> id, name, country ) " +
> "VALUES ( ? , ? , ? , ?)");
> // Setting the key of a wrong type (AffinityKey instance must be used
> instead).
> query.setArgs(100, 1000, "John", "Canada");
> // Getting not user friendly exception.
> cache.query(query).getAll();
> {code}
> he will get an exception that doesn't point out to the exact root cause:
> {noformat}
> Caused by: class org.apache.ignite.IgniteException: Failed to execute SQL
> query.
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:365)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:94)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:836)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:378)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:173)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:207)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1657)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1701)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1699)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2129)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1706)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:783)
> ... 6 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
> SQL query.
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:1224)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1276)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.access$1300(IgniteH2Indexing.java:239)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1079)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1067)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:362)
> ... 18 more
> Caused by: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number
> of characters: "100"; SQL statement:
> SELECT
> TABLE._KEY,
> TABLE.ID,
> TABLE.NAME,
> TABLE.COUNTRY
> FROM TABLE(_KEY OTHER=(?1,), ID BIGINT=(?2,), NAME VARCHAR=(?3,), COUNTRY
> VARCHAR=(?4,)) [90003-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.util.StringUtils.convertHexToBytes(StringUtils.java:930)
> at org.h2.value.Value.convertTo(Value.java:957)
> at org.h2.table.Column.convert(Column.java:167)
> at org.h2.expression.TableFunction.getTable(TableFunction.java:118)
> at org.h2.expression.TableFunction.getValue(TableFunction.java:41)
> at org.h2.table.FunctionTable.getValueResultSet(FunctionTable.java:218)
> at org.h2.table.FunctionTable.getResult(FunctionTable.java:189)
> at
[jira] [Assigned] (IGNITE-5250) Unhelpful exception when value of wrong type is passed to H2
[
https://issues.apache.org/jira/browse/IGNITE-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-5250:
---
Assignee: Alexander Paschenko
> Unhelpful exception when value of wrong type is passed to H2
>
>
> Key: IGNITE-5250
> URL: https://issues.apache.org/jira/browse/IGNITE-5250
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
> Attachments: ExampleNodeStartup.java
>
>
> For instance, if an SQL schema defined this way:
> {code}
> cfg.setIndexedTypes(AffinityKey.class, Person.class);
> {code}
> and then, by some reason, the users confuses the type of the key passing
> {{int}} instead of {{AffinityKey}}
> {code}
> SqlFieldsQuery query = new SqlFieldsQuery("INSERT INTO Person (_key,
> id, name, country ) " +
> "VALUES ( ? , ? , ? , ?)");
> // Setting the key of a wrong type (AffinityKey instance must be used
> instead).
> query.setArgs(100, 1000, "John", "Canada");
> // Getting not user friendly exception.
> cache.query(query).getAll();
> {code}
> he will get an exception that doesn't point out to the exact root cause:
> {noformat}
> Caused by: class org.apache.ignite.IgniteException: Failed to execute SQL
> query.
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:365)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:94)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:836)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:378)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:173)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:207)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1657)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1701)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1699)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2129)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1706)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:783)
> ... 6 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
> SQL query.
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:1224)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1276)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.access$1300(IgniteH2Indexing.java:239)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1079)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1067)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:362)
> ... 18 more
> Caused by: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number
> of characters: "100"; SQL statement:
> SELECT
> TABLE._KEY,
> TABLE.ID,
> TABLE.NAME,
> TABLE.COUNTRY
> FROM TABLE(_KEY OTHER=(?1,), ID BIGINT=(?2,), NAME VARCHAR=(?3,), COUNTRY
> VARCHAR=(?4,)) [90003-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.util.StringUtils.convertHexToBytes(StringUtils.java:930)
> at org.h2.value.Value.convertTo(Value.java:957)
> at org.h2.table.Column.convert(Column.java:167)
> at org.h2.expression.TableFunction.getTable(TableFunction.java:118)
> at org.h2.expression.TableFunction.getValue(TableFunction.java:41)
> at org.h2.table.FunctionTable.getValueResultSet(FunctionTable.java:218)
> at org.h2.table.FunctionTable.getResult(FunctionTable.ja
[jira] [Commented] (IGNITE-5879) .NET: Move TestPlatformPlugin to a separate module
[ https://issues.apache.org/jira/browse/IGNITE-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150443#comment-16150443 ] Pavel Tupitsyn commented on IGNITE-5879: [~daradurvs] you are right. Looks good to me then. > .NET: Move TestPlatformPlugin to a separate module > -- > > Key: IGNITE-5879 > URL: https://issues.apache.org/jira/browse/IGNITE-5879 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.1 >Reporter: Pavel Tupitsyn >Assignee: Vyacheslav Daradur > Labels: .NET > Fix For: 2.3 > > > Move test plugin to a separate module and load it only for .NET tests so we > don't interfere with other tests. > Dev list discussion: > http://apache-ignite-developers.2346864.n4.nabble.com/Plugins-in-tests-td20167.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
[ https://issues.apache.org/jira/browse/IGNITE-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita reassigned IGNITE-5553: --- Assignee: Amelchev Nikita > Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error > - > > Key: IGNITE-5553 > URL: https://issues.apache.org/jira/browse/IGNITE-5553 > Project: Ignite > Issue Type: Bug > Components: data structures, persistence >Affects Versions: 2.1 >Reporter: Dmitriy Pavlov >Assignee: Amelchev Nikita >Priority: Critical > Labels: MakeTeamcityGreenAgain, Muted_test, test-fail > Fix For: 2.3 > > > h2. Notes-4435 > When IgniteSet is restored from persistence, size of set is always 0, [link > to test > history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-7043871603266099589&tab=testDetails]. > h2. Detailed description > Unlike *IgniteQueue* which uses separate cache key to store its size > *IgniteSet* stores it in a field of some class. > Test from the link above shows very clearly that after restoring memory state > from PDS all set values are restored correctly but size is lost. > h2. Proposed solution > One possible solution might be to do the same thing as *IgniteQueue* does: > size of *IgniteSet* must be stored is cache instead of volatile in-memory > fields of random classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5879) .NET: Move TestPlatformPlugin to a separate module
[
https://issues.apache.org/jira/browse/IGNITE-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150421#comment-16150421
]
Vyacheslav Daradur commented on IGNITE-5879:
[~ptupitsyn], there is no recursion, the method {{AppendTestClasses}} calls
{{AppendTestClasses*0*}}.
I've checked it manually - it is necessary.
Modules in subfolders ({{modules\subFolder\moduleName}}) won't be included in
the classpath because it's looking for {{target}} folder in top directory level.
> .NET: Move TestPlatformPlugin to a separate module
> --
>
> Key: IGNITE-5879
> URL: https://issues.apache.org/jira/browse/IGNITE-5879
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Vyacheslav Daradur
> Labels: .NET
> Fix For: 2.3
>
>
> Move test plugin to a separate module and load it only for .NET tests so we
> don't interfere with other tests.
> Dev list discussion:
> http://apache-ignite-developers.2346864.n4.nabble.com/Plugins-in-tests-td20167.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6014) Add transaction prepare and commit markers to WAL
[ https://issues.apache.org/jira/browse/IGNITE-6014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150403#comment-16150403 ] ASF GitHub Bot commented on IGNITE-6014: GitHub user Jokser opened a pull request: https://github.com/apache/ignite/pull/2578 IGNITE-6014 Transaction records in WAL. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6014 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2578.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 #2578 commit b36d13e2d122f559320dbfceb043d392228c8e1a Author: Pavel Kovalenko Date: 2017-09-01T11:47:13Z IGNITE-6014 Transaction records in WAL. > Add transaction prepare and commit markers to WAL > - > > Key: IGNITE-6014 > URL: https://issues.apache.org/jira/browse/IGNITE-6014 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Pavel Kovalenko > Fix For: 2.3 > > > This may be useful for various recovery procedures in the future -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6053) IgniteCache.clear clears local caches with same names on all server nodes
[
https://issues.apache.org/jira/browse/IGNITE-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150391#comment-16150391
]
Nikolay Tikhonov edited comment on IGNITE-6053 at 9/1/17 11:43 AM:
---
[~roman_s],
I've looked at code and have only one comment, let's will execute clear closure
in public pool instead of system pool. For it need to pass false to localSafe
method. {{ctx.closures().callLocalSafe(..., false)}}
Also I don't see a runs on TC. Are you sure that you triggered this suites
[link
TC|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&branch_Ignite20Tests=pull%2F2443%2Fhead]?
BTW Thank you for your contribution!
was (Author: ntikhonov):
[~roman_s],
I've looked at code and have only one comment, let's will execute clearTask in
public pool instead of system pool. For it need to pass false to localSafe
method. {{ctx.closures().callLocalSafe(..., false)}}
Also I don't see a runs on TC. Are you sure that you triggered this suites
[link
TC|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&branch_Ignite20Tests=pull%2F2443%2Fhead]?
BTW Thank you for your contribution!
> IgniteCache.clear clears local caches with same names on all server nodes
> -
>
> Key: IGNITE-6053
> URL: https://issues.apache.org/jira/browse/IGNITE-6053
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Roman Shtykh
> Fix For: 2.3
>
>
> Clear on LOCAL cache should clear cache on the current node only, not on all
> nodes, that have local caches with same names.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6053) IgniteCache.clear clears local caches with same names on all server nodes
[
https://issues.apache.org/jira/browse/IGNITE-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150391#comment-16150391
]
Nikolay Tikhonov commented on IGNITE-6053:
--
[~roman_s],
I've looked at code and have only one comment, let's will execute clearTask in
public pool instead of system pool. For it need to pass false to localSafe
method. {{ctx.closures().callLocalSafe(..., false)}}
Also I don't see a runs on TC. Are you sure that you triggered this suites
[link
TC|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&branch_Ignite20Tests=pull%2F2443%2Fhead]?
BTW Thank you for your contribution!
> IgniteCache.clear clears local caches with same names on all server nodes
> -
>
> Key: IGNITE-6053
> URL: https://issues.apache.org/jira/browse/IGNITE-6053
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Roman Shtykh
> Fix For: 2.3
>
>
> Clear on LOCAL cache should clear cache on the current node only, not on all
> nodes, that have local caches with same names.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5999) Assertion fails: Moving partition is below zero
[
https://issues.apache.org/jira/browse/IGNITE-5999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150375#comment-16150375
]
Ilya Lantukh commented on IGNITE-5999:
--
"Moving" field value was calculated incorrectly if map values were copied from
another map. I fixed it. However, the test still fails sometimes due to other
reasons.
> Assertion fails: Moving partition is below zero
> ---
>
> Key: IGNITE-5999
> URL: https://issues.apache.org/jira/browse/IGNITE-5999
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Ilya Lantukh
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.3
>
>
> It was found during
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheQueryNodeRestartSelfTest2#testRestarts
> execution
> {code}
> java.lang.AssertionError: -10
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.hasMovingPartitions(GridDhtPartitionMap.java:135)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.hasMovingPartitions(GridDhtPartitionTopologyImpl.java:2116)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.hasMovingPartitions(GridReduceQueryExecutor.java:366)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.isPreloadingActive(GridReduceQueryExecutor.java:354)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:577)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1160)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:114)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheQueryNodeRestartSelfTest2$1.applyx(IgniteCacheQueryNodeRestartSelfTest2.java:247)
> at
> org.apache.ignite.internal.util.lang.GridAbsClosureX.apply(GridAbsClosureX.java:35)
> at
> org.apache.ignite.internal.util.lang.GridAbsClosure.run(GridAbsClosure.java:50)
> at
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1236)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6040) Update Distributed SQL Database page on the website
[ https://issues.apache.org/jira/browse/IGNITE-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150369#comment-16150369 ] Pavel Tupitsyn commented on IGNITE-6040: [~dmagda] SQL and DML examples added to https://ignite.apache.org/features/sql.html. > Update Distributed SQL Database page on the website > --- > > Key: IGNITE-6040 > URL: https://issues.apache.org/jira/browse/IGNITE-6040 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Dmitriy Setrakyan >Assignee: Pavel Tupitsyn > Labels: site > > # change DDL examples to pure SQL (without Java) > # change DML examples to pure SQL (without Java) > # change Query examples to pure SQL (without Java) > # add Java API section and show 1 Query, 1 DDL, 1 DML example from Java > # add .NET / C# API section and show 1 Query, 1 DDL, 1 DML example from C# > # add Other API section and show 1 Query, 1 DDL, 1 DML example from Python, > PHP, etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization
[
https://issues.apache.org/jira/browse/IGNITE-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150380#comment-16150380
]
Vladislav Pyatkov commented on IGNITE-5038:
---
[~vozerov] Then you for detailed review my changes.
I have had accepted your change and too your point of view.
Please look at my final PR again:
https://github.com/apache/ignite/pull/2011/commits
also I passed the patch in TC, look at the run over {{pull/2011/head}}.
> BinaryMarshaller might need to use context class loader for deserialization
> ---
>
> Key: IGNITE-5038
> URL: https://issues.apache.org/jira/browse/IGNITE-5038
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Vladislav Pyatkov
> Labels: features
> Fix For: 2.3
>
> Attachments: results-compound-20170802.zip,
> results-compound-20170808.zip
>
>
> There is a special use case discussed on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224
> According to the use case, BinaryMarshaller might need to try to deserialize
> an object using a context class loader if it failed to do so with a custom
> classloader (`IgniteConfiguration.getClassLoader()`) or the system one.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5849) Introduce ignite node persistent meta-store
[ https://issues.apache.org/jira/browse/IGNITE-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150363#comment-16150363 ] ASF GitHub Bot commented on IGNITE-5849: GitHub user kdudkov opened a pull request: https://github.com/apache/ignite/pull/2576 IGNITE-5849 refactor DataPageIO & FreeList, introduce MetaStorage You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-5849-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2576.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 #2576 commit 8474db6c56f6cacaa0745f1f43beaa812b65cb2f Author: Konstantin Dudkov Date: 2017-08-17T10:39:28Z IGNITE-5849 refactor DataPageIO & FreeList, introduce MetaStorage > Introduce ignite node persistent meta-store > --- > > Key: IGNITE-5849 > URL: https://issues.apache.org/jira/browse/IGNITE-5849 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Konstantin Dudkov > Fix For: 2.3 > > > As persistence feature is being developed, we will have a need for a > component, which reliably stores arbitrary metadata about node and cluster. > We already have reserved partition IDs for this purpose, all we need to do is > to extend the partition store abstraction to store non-cache objects and make > sure this new store participates in all common recovery procedures. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5999) Assertion fails: Moving partition is below zero
[
https://issues.apache.org/jira/browse/IGNITE-5999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150377#comment-16150377
]
ASF GitHub Bot commented on IGNITE-5999:
GitHub user ilantukh opened a pull request:
https://github.com/apache/ignite/pull/2577
IGNITE-5999 : Fixed calculation of moving partitions count.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-5999
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2577.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 #2577
commit bd23da34b1a77e4c9742b7021e6917ca91fadf8f
Author: Ilya Lantukh
Date: 2017-09-01T11:25:34Z
ignite-5999 : Fixed calculation of moving partitions count.
> Assertion fails: Moving partition is below zero
> ---
>
> Key: IGNITE-5999
> URL: https://issues.apache.org/jira/browse/IGNITE-5999
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Ilya Lantukh
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.3
>
>
> It was found during
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheQueryNodeRestartSelfTest2#testRestarts
> execution
> {code}
> java.lang.AssertionError: -10
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.hasMovingPartitions(GridDhtPartitionMap.java:135)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.hasMovingPartitions(GridDhtPartitionTopologyImpl.java:2116)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.hasMovingPartitions(GridReduceQueryExecutor.java:366)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.isPreloadingActive(GridReduceQueryExecutor.java:354)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:577)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1160)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:114)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheQueryNodeRestartSelfTest2$1.applyx(IgniteCacheQueryNodeRestartSelfTest2.java:247)
> at
> org.apache.ignite.internal.util.lang.GridAbsClosureX.apply(GridAbsClosureX.java:35)
> at
> org.apache.ignite.internal.util.lang.GridAbsClosure.run(GridAbsClosure.java:50)
> at
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1236)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-5999) Assertion fails: Moving partition is below zero
[
https://issues.apache.org/jira/browse/IGNITE-5999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Lantukh reassigned IGNITE-5999:
Assignee: Ilya Lantukh
> Assertion fails: Moving partition is below zero
> ---
>
> Key: IGNITE-5999
> URL: https://issues.apache.org/jira/browse/IGNITE-5999
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Ilya Lantukh
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.3
>
>
> It was found during
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheQueryNodeRestartSelfTest2#testRestarts
> execution
> {code}
> java.lang.AssertionError: -10
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.hasMovingPartitions(GridDhtPartitionMap.java:135)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.hasMovingPartitions(GridDhtPartitionTopologyImpl.java:2116)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.hasMovingPartitions(GridReduceQueryExecutor.java:366)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.isPreloadingActive(GridReduceQueryExecutor.java:354)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:577)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1160)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:114)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheQueryNodeRestartSelfTest2$1.applyx(IgniteCacheQueryNodeRestartSelfTest2.java:247)
> at
> org.apache.ignite.internal.util.lang.GridAbsClosureX.apply(GridAbsClosureX.java:35)
> at
> org.apache.ignite.internal.util.lang.GridAbsClosure.run(GridAbsClosure.java:50)
> at
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1236)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6211) ODBC: SQLBindParameter should not unbind parameter if the ParameterValuePtr is NULL
[
https://issues.apache.org/jira/browse/IGNITE-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150371#comment-16150371
]
Pavel Tupitsyn commented on IGNITE-6211:
[~isapego] looks good to me.
> ODBC: SQLBindParameter should not unbind parameter if the ParameterValuePtr
> is NULL
> ---
>
> Key: IGNITE-6211
> URL: https://issues.apache.org/jira/browse/IGNITE-6211
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Labels: important
> Fix For: 2.3
>
>
> Currently, {{SQLBindParameter}} unbinds parameter if the
> {{ParameterValuePtr}} is {{NULL}} in analogy with {{SQLBindCol}}. Howeverm
> according to
> https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlbindparameter-function
> there should not be such a behaviour. {{ParameterValuePtr}} can be set to
> {{NULL}} for example if user wants to bind {{SQL_NULL_DATA}} parameter.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5879) .NET: Move TestPlatformPlugin to a separate module
[
https://issues.apache.org/jira/browse/IGNITE-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150370#comment-16150370
]
Pavel Tupitsyn commented on IGNITE-5879:
[~daradurvs], {{AppendTestClasses}} is recursive, this change does not seem to
be necessary.
> .NET: Move TestPlatformPlugin to a separate module
> --
>
> Key: IGNITE-5879
> URL: https://issues.apache.org/jira/browse/IGNITE-5879
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Vyacheslav Daradur
> Labels: .NET
> Fix For: 2.3
>
>
> Move test plugin to a separate module and load it only for .NET tests so we
> don't interfere with other tests.
> Dev list discussion:
> http://apache-ignite-developers.2346864.n4.nabble.com/Plugins-in-tests-td20167.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6040) Update Distributed SQL Database page on the website
[ https://issues.apache.org/jira/browse/IGNITE-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-6040: -- Assignee: Denis Magda (was: Pavel Tupitsyn) > Update Distributed SQL Database page on the website > --- > > Key: IGNITE-6040 > URL: https://issues.apache.org/jira/browse/IGNITE-6040 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Dmitriy Setrakyan >Assignee: Denis Magda > Labels: site > > # change DDL examples to pure SQL (without Java) > # change DML examples to pure SQL (without Java) > # change Query examples to pure SQL (without Java) > # add Java API section and show 1 Query, 1 DDL, 1 DML example from Java > # add .NET / C# API section and show 1 Query, 1 DDL, 1 DML example from C# > # add Other API section and show 1 Query, 1 DDL, 1 DML example from Python, > PHP, etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-2779) BinaryMarshaller caches must be cleaned during client reconnect.
[
https://issues.apache.org/jira/browse/IGNITE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150358#comment-16150358
]
Amelchev Nikita commented on IGNITE-2779:
-
[~vozerov] I have done issue. Could you review, please?
> BinaryMarshaller caches must be cleaned during client reconnect.
>
>
> Key: IGNITE-2779
> URL: https://issues.apache.org/jira/browse/IGNITE-2779
> Project: Ignite
> Issue Type: Task
> Components: cache, general
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Amelchev Nikita
> Labels: community
> Fix For: 2.3
>
> Attachments: IgniteProblemTest.java
>
>
> The problem is originally reported by Vinay Sharma here:
> http://apache-ignite-users.70518.x6.nabble.com/changed-cache-configuration-and-restarted-server-nodes-Getting-exception-td3064.html#none
> *Root cause*:
> When client is reconnected to topology after full topology restart (i.e. all
> server nodes were down), it doesn't re-send binary metadata to topology. As a
> result, {{BinaryMarshaller}} exception occurs.
> *Steps to reproduce*
> Run attached code.
> *Proposed solution*
> Clean cached binary metadata during re-connect.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6243) RazorSQL crash on try edit, describe and another actions with table.
[ https://issues.apache.org/jira/browse/IGNITE-6243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Chetaev updated IGNITE-6243: Summary: RazorSQL crash on try edit, describe and another actions with table. (was: RazorSQL crashed on try edit, describe and another actions with table.) > RazorSQL crash on try edit, describe and another actions with table. > > > Key: IGNITE-6243 > URL: https://issues.apache.org/jira/browse/IGNITE-6243 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.1 >Reporter: Aleksey Chetaev > > 1. Install ODBC on Windows. > 2. Crete DSN for Ignite ODBC Driver. > 3. Connect by RazorSQL using ODBC. > 4. Create new table. > 5. Try to edit table, using right click. > RazorSQL crashed without error. > Need check that it's not crash of Apache Ignite ODBC driver. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6243) RazorSQL crashed on try edit, describe and another actions with table.
Aleksey Chetaev created IGNITE-6243: --- Summary: RazorSQL crashed on try edit, describe and another actions with table. Key: IGNITE-6243 URL: https://issues.apache.org/jira/browse/IGNITE-6243 Project: Ignite Issue Type: Bug Components: odbc Affects Versions: 2.1 Reporter: Aleksey Chetaev 1. Install ODBC on Windows. 2. Crete DSN for Ignite ODBC Driver. 3. Connect by RazorSQL using ODBC. 4. Create new table. 5. Try to edit table, using right click. RazorSQL crashed without error. Need check that it's not crash of Apache Ignite ODBC driver. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6071) Client may detect necessity for reconnect for too long
[
https://issues.apache.org/jira/browse/IGNITE-6071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150343#comment-16150343
]
ASF GitHub Bot commented on IGNITE-6071:
GitHub user alamar opened a pull request:
https://github.com/apache/ignite/pull/2575
IGNITE-6071 Finite number of attempts in reserveClient()
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6071
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2575.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 #2575
commit 1e8e082ced9fc99b20867d05ede08e881a0c503b
Author: Ilya Kasnacheev
Date: 2017-09-01T10:24:52Z
IGNITE-6071 Finite number of attempts in reserveClient()
> Client may detect necessity for reconnect for too long
> --
>
> Key: IGNITE-6071
> URL: https://issues.apache.org/jira/browse/IGNITE-6071
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Yakov Zhdanov
>Assignee: Ilya Kasnacheev
>
> There was a GC pause on client that caused servers to drop client due to
> inability to establish TCP communication connection. Then it took some time
> for client to detect that it has been dropped. During that time client many
> times attempted to connect to server which can be seen in the logs. After
> client detected its drop and reconnected servers fired node added event and
> no log flood can be found any more.
> We need to find out why client was reconnecting via communication and did not
> detect the drop for such a long time.
> I hope this can be reproduced in test:
> * start 2 servers
> * start client
> * suspend all client threads with Thread.suspend() - just filter threads of
> current JVM by name and suspend ones belonging to the client.
> {noformat}
> [10:12:24,785][WARNING][disco-event-worker-#71%null%][GridDiscoveryManager]
> Node FAILED: TcpDiscoveryNode [id=dd71479c-41ba-443e-b25c-3803a2a94f4f,
> addrs=[10.44.3.14, 127.0.0.1], sockAddrs=[/127.0.0.1:0,
> XXX.com/10.44.3.14:0], discPort=0, order=2, intOrder=2,
> lastExchangeTime=1502269008673, loc=false, ver=2.1.1#20170618-sha1:09ce29e0,
> isClient=true]
> [10:12:24,785][INFO][disco-event-worker-#71%null%][GridDiscoveryManager]
> Topology snapshot [ver=5, servers=2, clients=1, CPUs=144, heap=76.0GB]
> [10:12:24,794][INFO][exchange-worker-#72%null%][time] Started exchange init
> [topVer=AffinityTopologyVersion [topVer=5, minorTopVer=0], crd=false, evt=12,
> node=TcpDiscoveryNode [id=98c1fdf7-09db-4fa0-bb01-8ca7f046643d,
> addrs=[10.44.3.11, 127.0.0.1], sockAddrs=[/127.0.0.1:47500,
> XXX.com/10.44.3.11:47500], discPort=47500, order=3, intOrder=3,
> lastExchangeTime=1502269944782, loc=true, ver=2.1.1#20170618-sha1:09ce29e0,
> isClient=false], evtNode=TcpDiscoveryNode
> [id=98c1fdf7-09db-4fa0-bb01-8ca7f046643d, addrs=[10.44.3.11, 127.0.0.1],
> sockAddrs=[/127.0.0.1:47500, XXX.com/10.44.3.11:47500], discPort=47500,
> order=3, intOrder=3, lastExchangeTime=1502269944782, loc=true,
> ver=2.1.1#20170618-sha1:09ce29e0, isClient=false], customEvt=null]
> [10:12:24,813][INFO][exchange-worker-#72%null%][time] Finished exchange init
> [topVer=AffinityTopologyVersion [topVer=5, minorTopVer=0], crd=false]
> [10:12:24,819][INFO][exchange-worker-#72%null%][GridCachePartitionExchangeManager]
> Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion
> [topVer=5, minorTopVer=0], evt=NODE_FAILED,
> node=dd71479c-41ba-443e-b25c-3803a2a94f4f]
> [10:12:28,344][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
> rmtAddr=/10.44.3.14:52474]
> [10:12:28,348][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
> rmtAddr=/10.44.3.14:52482]
> [10:12:28,356][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
> rmtAddr=/10.44.3.14:52506]
> [10:12:28,362][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
> rmtAddr=/10.44.3.14:52522]
> [10:12:28,368][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
> rmtAddr=/10.44.3.14:52538]
> [10:12:28,374][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
> rmtAddr=/10.44.3.14:52554]
> [10:12:28,380][I
[jira] [Commented] (IGNITE-6139) JDBC driver should return actual values for get*Version()
[ https://issues.apache.org/jira/browse/IGNITE-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150250#comment-16150250 ] Ilya Kasnacheev commented on IGNITE-6139: - [~vozerov] please merge if it's okay. > JDBC driver should return actual values for get*Version() > - > > Key: IGNITE-6139 > URL: https://issues.apache.org/jira/browse/IGNITE-6139 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 2.1 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev > Fix For: 2.3 > > > Right now it returns: > Database version 1.0 (suggested - actual version from server nodes) > JDBC version 1.0 (suggested - 4.1, that's what's in Java 7) > Driver version 1.0 (suggested - actual version of running Ignite code) > Database product name is "Ignite Cache", probably keep that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6139) JDBC driver should return actual values for get*Version()
[ https://issues.apache.org/jira/browse/IGNITE-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150240#comment-16150240 ] Taras Ledkov edited comment on IGNITE-6139 at 9/1/17 9:01 AM: -- [~ilyak], the patch is OK with me. A little comment about ticket description: Ignite JDBC v2 driver use Ignite client to connect to Ignite grid. In this case *Database version* == *Driver version* because nodes with different versions cannot joins to topology. Moreover, client node is joined into grid topology. It doesn't connect to one Ignite server. was (Author: tledkov-gridgain): [~ilyak], the patch is OK with me. A little comment about ticket description: Ignite JDBC v2 driver use Ignite client to connect to Ignite grid. In this case *Database version* == *Driver version* because nodes with different versions cannot joins to topology. Moreover, client node join grid topology. It doesn't connect to one Ignite server. > JDBC driver should return actual values for get*Version() > - > > Key: IGNITE-6139 > URL: https://issues.apache.org/jira/browse/IGNITE-6139 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 2.1 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev > Fix For: 2.3 > > > Right now it returns: > Database version 1.0 (suggested - actual version from server nodes) > JDBC version 1.0 (suggested - 4.1, that's what's in Java 7) > Driver version 1.0 (suggested - actual version of running Ignite code) > Database product name is "Ignite Cache", probably keep that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6139) JDBC driver should return actual values for get*Version()
[ https://issues.apache.org/jira/browse/IGNITE-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150240#comment-16150240 ] Taras Ledkov edited comment on IGNITE-6139 at 9/1/17 9:00 AM: -- [~ilyak], the patch is OK with me. A little comment about ticket description: Ignite JDBC v2 driver use Ignite client to connect to Ignite grid. In this case *Database version* == *Driver version* because nodes with different versions cannot joins to topology. Moreover, client node join grid topology. It doesn't connect to one Ignite server. was (Author: tledkov-gridgain): [~ilyak], the patch is OK with me. A little comment about ticket description: Ignite JDBC v2 driver use Ignite client to connect to Ignite grid. In this case *Database version* == *Driver version* because nodes with different versions cannot join topology. Moreover, client node join grid topology. It doesn't connect to one Ignite server. > JDBC driver should return actual values for get*Version() > - > > Key: IGNITE-6139 > URL: https://issues.apache.org/jira/browse/IGNITE-6139 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 2.1 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev > Fix For: 2.3 > > > Right now it returns: > Database version 1.0 (suggested - actual version from server nodes) > JDBC version 1.0 (suggested - 4.1, that's what's in Java 7) > Driver version 1.0 (suggested - actual version of running Ignite code) > Database product name is "Ignite Cache", probably keep that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6139) JDBC driver should return actual values for get*Version()
[ https://issues.apache.org/jira/browse/IGNITE-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150240#comment-16150240 ] Taras Ledkov edited comment on IGNITE-6139 at 9/1/17 9:00 AM: -- [~ilyak], the patch is OK with me. A little comment about ticket description: Ignite JDBC v2 driver use Ignite client to connect to Ignite grid. In this case *Database version* == *Driver version* because nodes with different versions cannot join topology. Moreover, client node join grid topology. It doesn't connect to one Ignite server. was (Author: tledkov-gridgain): [~ilyak], the patch is OK with me. Ignite JDBC v2 driver use Ignite client to connect to Ignite grid. In this case *Database version* == *Driver version* because nodes with different versions cannot join topology. Moreover, client node join grid topology. It doesn't connect to one Ignite server. > JDBC driver should return actual values for get*Version() > - > > Key: IGNITE-6139 > URL: https://issues.apache.org/jira/browse/IGNITE-6139 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 2.1 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev > Fix For: 2.3 > > > Right now it returns: > Database version 1.0 (suggested - actual version from server nodes) > JDBC version 1.0 (suggested - 4.1, that's what's in Java 7) > Driver version 1.0 (suggested - actual version of running Ignite code) > Database product name is "Ignite Cache", probably keep that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6139) JDBC driver should return actual values for get*Version()
[ https://issues.apache.org/jira/browse/IGNITE-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150240#comment-16150240 ] Taras Ledkov commented on IGNITE-6139: -- [~ilyak], the patch is OK with me. Ignite JDBC v2 driver use Ignite client to connect to Ignite grid. In this case *Database version* == *Driver version* because nodes with different versions cannot join topology. Moreover, client node join grid topology. It doesn't connect to one Ignite server. > JDBC driver should return actual values for get*Version() > - > > Key: IGNITE-6139 > URL: https://issues.apache.org/jira/browse/IGNITE-6139 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 2.1 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev > Fix For: 2.3 > > > Right now it returns: > Database version 1.0 (suggested - actual version from server nodes) > JDBC version 1.0 (suggested - 4.1, that's what's in Java 7) > Driver version 1.0 (suggested - actual version of running Ignite code) > Database product name is "Ignite Cache", probably keep that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6238) Fix GridClosureProcessorRemoteTest, add it to suite
[ https://issues.apache.org/jira/browse/IGNITE-6238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150236#comment-16150236 ] Ilya Kasnacheev commented on IGNITE-6238: - [~sboikov] please take a look, does it still carry the original intent? > Fix GridClosureProcessorRemoteTest, add it to suite > --- > > Key: IGNITE-6238 > URL: https://issues.apache.org/jira/browse/IGNITE-6238 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Trivial > > It seems that it got lost and suffered from bit rot. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6233) .NET: Extract type codes to a separate class
[
https://issues.apache.org/jira/browse/IGNITE-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150228#comment-16150228
]
ASF GitHub Bot commented on IGNITE-6233:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2570
> .NET: Extract type codes to a separate class
>
>
> Key: IGNITE-6233
> URL: https://issues.apache.org/jira/browse/IGNITE-6233
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.3
>
>
> {{BinaryUtils}} class is a mess. First candidate for extraction is a set of
> type codes ({{TypeByte}} etc). {{BinarySystemHandlers.GetTypeId}} should be
> moved to the same class.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6139) JDBC driver should return actual values for get*Version()
[ https://issues.apache.org/jira/browse/IGNITE-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150221#comment-16150221 ] Ilya Kasnacheev commented on IGNITE-6139: - [~tledkov-gridgain] please take a look. > JDBC driver should return actual values for get*Version() > - > > Key: IGNITE-6139 > URL: https://issues.apache.org/jira/browse/IGNITE-6139 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 2.1 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev > Fix For: 2.3 > > > Right now it returns: > Database version 1.0 (suggested - actual version from server nodes) > JDBC version 1.0 (suggested - 4.1, that's what's in Java 7) > Driver version 1.0 (suggested - actual version of running Ignite code) > Database product name is "Ignite Cache", probably keep that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5855) SQL: BigInteger support broken in SQL queries.
[ https://issues.apache.org/jira/browse/IGNITE-5855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150224#comment-16150224 ] Ilya Kasnacheev commented on IGNITE-5855: - [~tledkov] please take a look at the amended fix > SQL: BigInteger support broken in SQL queries. > -- > > Key: IGNITE-5855 > URL: https://issues.apache.org/jira/browse/IGNITE-5855 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.0, 2.1 >Reporter: Andrew Mashenkov >Assignee: Ilya Kasnacheev > Attachments: BigIntegerKeySqlTest.java > > > Looks like BigInteger support in SQL was broken. > It works fine on ignite-1.9 > PFA reproducer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6233) .NET: Extract type codes to a separate class
[
https://issues.apache.org/jira/browse/IGNITE-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150216#comment-16150216
]
Pavel Tupitsyn commented on IGNITE-6233:
Merged to master: {{55e0b5c9bf3b0b12ed930dbffea8e5bfced1ef18}}.
> .NET: Extract type codes to a separate class
>
>
> Key: IGNITE-6233
> URL: https://issues.apache.org/jira/browse/IGNITE-6233
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.3
>
>
> {{BinaryUtils}} class is a mess. First candidate for extraction is a set of
> type codes ({{TypeByte}} etc). {{BinarySystemHandlers.GetTypeId}} should be
> moved to the same class.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-6233) .NET: Extract type codes to a separate class
[
https://issues.apache.org/jira/browse/IGNITE-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-6233.
Resolution: Fixed
> .NET: Extract type codes to a separate class
>
>
> Key: IGNITE-6233
> URL: https://issues.apache.org/jira/browse/IGNITE-6233
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.3
>
>
> {{BinaryUtils}} class is a mess. First candidate for extraction is a set of
> type codes ({{TypeByte}} etc). {{BinarySystemHandlers.GetTypeId}} should be
> moved to the same class.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6214) Binary metadata update may hang
[ https://issues.apache.org/jira/browse/IGNITE-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-6214: - Description: Sometimes client may hang when performing concurrent SQL updates. Reproducing code is in the attachment. The reason is that insert triggers metadata update, which may leave some of the nodes infinitely waiting when performed concurrently. was: Sometimes client may hang when performing concurrent SQL updates. Reproducing code is in the attachment. > Binary metadata update may hang > --- > > Key: IGNITE-6214 > URL: https://issues.apache.org/jira/browse/IGNITE-6214 > Project: Ignite > Issue Type: Bug >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov > Fix For: 2.3 > > Attachments: SqlInserter.java, sql-test-client.xml, > sql-test-default.xml, sql-test.xml > > > Sometimes client may hang when performing concurrent SQL updates. > Reproducing code is in the attachment. > The reason is that insert triggers metadata update, which may leave some of > the nodes infinitely waiting when performed concurrently. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6214) Binary metadata update may hang
[ https://issues.apache.org/jira/browse/IGNITE-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-6214: - Summary: Binary metadata update may hang (was: Client hangs when executing SQL updates) > Binary metadata update may hang > --- > > Key: IGNITE-6214 > URL: https://issues.apache.org/jira/browse/IGNITE-6214 > Project: Ignite > Issue Type: Bug >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov > Fix For: 2.3 > > Attachments: SqlInserter.java, sql-test-client.xml, > sql-test-default.xml, sql-test.xml > > > Sometimes client may hang when performing concurrent SQL updates. > Reproducing code is in the attachment. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6242) Passing custom cache name to CREATE TABLE
[
https://issues.apache.org/jira/browse/IGNITE-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-6242:
---
Assignee: Alexander Paschenko (was: Vladimir Ozerov)
> Passing custom cache name to CREATE TABLE
> -
>
> Key: IGNITE-6242
> URL: https://issues.apache.org/jira/browse/IGNITE-6242
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
> Labels: usability
> Fix For: 2.3
>
>
> CREATE TABLE automatically creates an IgniteCache naming it
> SQL_PUBLIC_{TABLE}. So, if a Person table is created you’ll have
> SQL_PUBLIC_PERSON cache in the cluster.
> If we keep to SQL APIs the cache name is not a big deal but as soon as
> key-value, compute, service grid APIs are needed the cache name will be used
> here and there looking bizarre.
> Let's give a way to pass the cache name into WITH clause parameters set
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6237) Script for signing and uploading artifacts to remote staging.
[ https://issues.apache.org/jira/browse/IGNITE-6237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ostanin updated IGNITE-6237: - Fix Version/s: (was: 2.2) 2.3 > Script for signing and uploading artifacts to remote staging. > - > > Key: IGNITE-6237 > URL: https://issues.apache.org/jira/browse/IGNITE-6237 > Project: Ignite > Issue Type: Sub-task > Components: build >Reporter: Oleg Ostanin >Assignee: Oleg Ostanin > Fix For: 2.3 > > > Create script for signing artifacts in locally staged repository and > uploading to the remote staging. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
