[jira] [Commented] (IGNITE-12068) puzzling select result
[ https://issues.apache.org/jira/browse/IGNITE-12068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906952#comment-16906952 ] JerryKwan commented on IGNITE-12068: Hi [~Pavlukhin], thank for looking into this. If the primary key is single, it must be only exists one result row, but if the primary key is composite, it depends If the primary key is an interger, we can use the filtering condition WHERE id >= 1 and id < 2 as a temporary solution, but what should we do if it is an string? > puzzling select result > -- > > Key: IGNITE-12068 > URL: https://issues.apache.org/jira/browse/IGNITE-12068 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.7.5 > Environment: System version: CentOS Linux release 7.6.1810 (Core) > Apache Ignite version: apache-ignite-2.7.5-1.noarch >Reporter: JerryKwan >Priority: Critical > > select using the first primary key only returns one record, but it should > return more records. > The following is how to reproduce this problem > 1, create a table using > CREATE TABLE IF NOT EXISTS Person( > id int, > city_id int, > name varchar, > age int, > company varchar, > PRIMARY KEY (id, city_id) > ); > 2, insert some records > INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3); > INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4); > INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4); > 3, query using 'select * from Person' show all of the records, expected > [http://www.passimage.in/i/03da31c8f23cf64580d5.png] > 4, query using 'select * from Person where id=1', only get one record, NOT > expected > [http://www.passimage.in/i/f5491491a70c5d796823.png] > 5, query using 'select * from Person where city_id=4' get two records, > expected > [http://www.passimage.in/i/ff0ee4f5e882983d779d.png] > Why 'select * from Person where id=1', only get one record? and how to fix > this? Is there any special operations/configurations to do? -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-12068) puzzling select result
[ https://issues.apache.org/jira/browse/IGNITE-12068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-12068: Priority: Critical (was: Major) > puzzling select result > -- > > Key: IGNITE-12068 > URL: https://issues.apache.org/jira/browse/IGNITE-12068 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.7.5 > Environment: System version: CentOS Linux release 7.6.1810 (Core) > Apache Ignite version: apache-ignite-2.7.5-1.noarch >Reporter: JerryKwan >Priority: Critical > > select using the first primary key only returns one record, but it should > return more records. > The following is how to reproduce this problem > 1, create a table using > CREATE TABLE IF NOT EXISTS Person( > id int, > city_id int, > name varchar, > age int, > company varchar, > PRIMARY KEY (id, city_id) > ); > 2, insert some records > INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3); > INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4); > INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4); > 3, query using 'select * from Person' show all of the records, expected > [http://www.passimage.in/i/03da31c8f23cf64580d5.png] > 4, query using 'select * from Person where id=1', only get one record, NOT > expected > [http://www.passimage.in/i/f5491491a70c5d796823.png] > 5, query using 'select * from Person where city_id=4' get two records, > expected > [http://www.passimage.in/i/ff0ee4f5e882983d779d.png] > Why 'select * from Person where id=1', only get one record? and how to fix > this? Is there any special operations/configurations to do? -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12068) puzzling select result
[
https://issues.apache.org/jira/browse/IGNITE-12068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906943#comment-16906943
]
Ivan Pavlukhin commented on IGNITE-12068:
-
[~JerryKwan], you faced (for our shame) a bug related to an optimization for a
primary key equality lookup. Erroneously it assumes that there should be only
one result row. As a workaround I was able to get proper results using
filtering condition {{WHERE id >= 1 and id < 2}}. But it is really weird, hope
to fix it shortly.
> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Priority: Major
>
> select using the first primary key only returns one record, but it should
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
> id int,
> city_id int,
> name varchar,
> age int,
> company varchar,
> PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get two records,
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why 'select * from Person where id=1', only get one record? and how to fix
> this? Is there any special operations/configurations to do?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12068) puzzling select result
JerryKwan created IGNITE-12068: -- Summary: puzzling select result Key: IGNITE-12068 URL: https://issues.apache.org/jira/browse/IGNITE-12068 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.7.5 Environment: System version: CentOS Linux release 7.6.1810 (Core) Apache Ignite version: apache-ignite-2.7.5-1.noarch Reporter: JerryKwan select using the first primary key only returns one record, but it should return more records. The following is how to reproduce this problem 1, create a table using CREATE TABLE IF NOT EXISTS Person( id int, city_id int, name varchar, age int, company varchar, PRIMARY KEY (id, city_id) ); 2, insert some records INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3); INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4); INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4); 3, query using 'select * from Person' show all of the records, expected [http://www.passimage.in/i/03da31c8f23cf64580d5.png] 4, query using 'select * from Person where id=1', only get one record, NOT expected [http://www.passimage.in/i/f5491491a70c5d796823.png] 5, query using 'select * from Person where city_id=4' get two records, expected [http://www.passimage.in/i/ff0ee4f5e882983d779d.png] Why 'select * from Person where id=1', only get one record? and how to fix this? Is there any special operations/configurations to do? -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12067) SQL: metrics of executions of user queries
Pavel Kuznetsov created IGNITE-12067: Summary: SQL: metrics of executions of user queries Key: IGNITE-12067 URL: https://issues.apache.org/jira/browse/IGNITE-12067 Project: Ignite Issue Type: Bug Components: sql Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov Lets add: - Counter of success executed user queries. - Counter of failed executed user queries. - Counter of failed by OOM executed user queries. - Counter of cancelled user queries. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-12066) Move transmission chunk size to IgniteConfiguration
[
https://issues.apache.org/jira/browse/IGNITE-12066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12066:
-
Summary: Move transmission chunk size to IgniteConfiguration (was: Add
transmission chunk size to IgniteConfiguration)
> Move transmission chunk size to IgniteConfiguration
> ---
>
> Key: IGNITE-12066
> URL: https://issues.apache.org/jira/browse/IGNITE-12066
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Priority: Minor
> Labels: iep-28
>
> Currently, the {{DFLT_CHUNK_SIZE_BYTES}} constant value is used to set the
> size of chunks with data sending to the remote node during the file
> transmission.
> This value must be set from IgniteConfiguration.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-12065) File transmission speed limit
[ https://issues.apache.org/jira/browse/IGNITE-12065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12065: - Priority: Minor (was: Major) > File transmission speed limit > - > > Key: IGNITE-12065 > URL: https://issues.apache.org/jira/browse/IGNITE-12065 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Priority: Minor > Labels: iep-28 > Time Spent: 10m > Remaining Estimate: 0h > > We need to limit transmission speed since the system resources can be > exhausted. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12066) Add transmission chunk size to IgniteConfiguration
Maxim Muzafarov created IGNITE-12066:
Summary: Add transmission chunk size to IgniteConfiguration
Key: IGNITE-12066
URL: https://issues.apache.org/jira/browse/IGNITE-12066
Project: Ignite
Issue Type: Improvement
Reporter: Maxim Muzafarov
Currently, the {{DFLT_CHUNK_SIZE_BYTES}} constant value is used to set the size
of chunks with data sending to the remote node during the file transmission.
This value must be set from IgniteConfiguration.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12065) File transmission speed limit
Maxim Muzafarov created IGNITE-12065: Summary: File transmission speed limit Key: IGNITE-12065 URL: https://issues.apache.org/jira/browse/IGNITE-12065 Project: Ignite Issue Type: Improvement Reporter: Maxim Muzafarov We need to limit transmission speed since the system resources can be exhausted. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-12065) File transmission speed limit
[ https://issues.apache.org/jira/browse/IGNITE-12065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12065: - Ignite Flags: (was: Docs Required) > File transmission speed limit > - > > Key: IGNITE-12065 > URL: https://issues.apache.org/jira/browse/IGNITE-12065 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Priority: Major > Labels: iep-28 > > We need to limit transmission speed since the system resources can be > exhausted. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12059) DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration fails
[
https://issues.apache.org/jira/browse/IGNITE-12059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906401#comment-16906401
]
Ignite TC Bot commented on IGNITE-12059:
{panel:title=Branch: [pull/6765/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Win x64 / Release){color} [[tests 1
BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=4495542]]
* IgniteThinClientTest: CacheClientTestSuite: CacheClientPartitionsRebalance -
Test has low fail rate in base branch 0,0% and is not flaky
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4491523&buildTypeId=IgniteTests24Java8_RunAll]
> DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration
> fails
> ---
>
> Key: IGNITE-12059
> URL: https://issues.apache.org/jira/browse/IGNITE-12059
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration
> fails because validation was removed in IGNITE-9562.
> Need to restore this validation.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12064) Check license headers by checkstyle plugin
[
https://issues.apache.org/jira/browse/IGNITE-12064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906380#comment-16906380
]
Maxim Muzafarov edited comment on IGNITE-12064 at 8/13/19 4:35 PM:
---
[~dpavlov]
Thank you for this notice.
I think it is no matter how headers check its more important that they must
persist in the source files. Anyway, I'll check ASF standards.
was (Author: mmuzaf):
[~dpavlov]
Thank you for this notice.
I think it is no matter how the header should be checked its more important
that they must persist in the source files. Anyway, I'll check ASF standards.
> Check license headers by checkstyle plugin
> --
>
> Key: IGNITE-12064
> URL: https://issues.apache.org/jira/browse/IGNITE-12064
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: checkstyle
>
> Currently, the {{apache-rat-plugin}} is used to check that source files
> contain the specific license header. The suite {{[Licenses Headers]}} is
> configured on TC to do so.
> It is possible to achieve the same thing with {{checkstyle-plugin}} (such it
> is already run on each build). This will save TC resources consumed to run
> both suites and simplify Ignite {{pom.xml}}.
> [1] https://checkstyle.sourceforge.io/config_header.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12064) Check license headers by checkstyle plugin
[
https://issues.apache.org/jira/browse/IGNITE-12064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906380#comment-16906380
]
Maxim Muzafarov commented on IGNITE-12064:
--
[~dpavlov]
Thank you for this notice.
I think it is no matter how the header should be checked its more important
that they must persist in the source files. Anyway, I'll check ASF standards.
> Check license headers by checkstyle plugin
> --
>
> Key: IGNITE-12064
> URL: https://issues.apache.org/jira/browse/IGNITE-12064
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: checkstyle
>
> Currently, the {{apache-rat-plugin}} is used to check that source files
> contain the specific license header. The suite {{[Licenses Headers]}} is
> configured on TC to do so.
> It is possible to achieve the same thing with {{checkstyle-plugin}} (such it
> is already run on each build). This will save TC resources consumed to run
> both suites and simplify Ignite {{pom.xml}}.
> [1] https://checkstyle.sourceforge.io/config_header.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-11075) Index rebuild procedure over cache partition file
[
https://issues.apache.org/jira/browse/IGNITE-11075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11075:
-
Description:
The node can own partition when partition data is rebalanced and cache indexes
are ready. For the message-based cluster rebalancing, approach indexes are
rebuilding simultaneously with cache data loading. For the file-based
rebalancing approach, the index rebuild procedure must be finished before the
partition state is set to the OWNING state.
We need to rebuild local SQL indexes (the {{index.bin}} file) when partition
file has been received. Crash-recovery guarantees must be supported by a node
since index-rebuild performs on the node in the topology.
was:We need to rebuild a {{index.bin}} file when all demanded partitions
uploaded successfully to the demander node.
> Index rebuild procedure over cache partition file
> -
>
> Key: IGNITE-11075
> URL: https://issues.apache.org/jira/browse/IGNITE-11075
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: iep-28
>
> The node can own partition when partition data is rebalanced and cache
> indexes are ready. For the message-based cluster rebalancing, approach
> indexes are rebuilding simultaneously with cache data loading. For the
> file-based rebalancing approach, the index rebuild procedure must be finished
> before the partition state is set to the OWNING state.
> We need to rebuild local SQL indexes (the {{index.bin}} file) when partition
> file has been received. Crash-recovery guarantees must be supported by a node
> since index-rebuild performs on the node in the topology.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-11075) Index rebuild procedure over cache partition file
[
https://issues.apache.org/jira/browse/IGNITE-11075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11075:
-
Summary: Index rebuild procedure over cache partition file (was: Implement
index rebuild procedure after partitions uploaded)
> Index rebuild procedure over cache partition file
> -
>
> Key: IGNITE-11075
> URL: https://issues.apache.org/jira/browse/IGNITE-11075
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: iep-28
>
> We need to rebuild a {{index.bin}} file when all demanded partitions uploaded
> successfully to the demander node.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-11051) Implement partition upload process as new part of GridCachePreloader
[ https://issues.apache.org/jira/browse/IGNITE-11051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11051: - Issue Type: Task (was: Sub-task) Parent: (was: IGNITE-8020) > Implement partition upload process as new part of GridCachePreloader > > > Key: IGNITE-11051 > URL: https://issues.apache.org/jira/browse/IGNITE-11051 > Project: Ignite > Issue Type: Task > Components: persistence >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: None > > > *Preloader* > A new implementation of cache entries preloader assume to be done. The new > implementation must send and receive cache partition files over the > CommunicationSpi channels by chunks of data with validation received items. > The new layer over the cache partition file must support direct using of > FileChannel#transferTo method over the CommunicationSpi pipe connection; > # The process manager must support transferring the cache partition file by > chunks of predefined size (multiply to the page size) one by one; > # The connection bandwidth of the cache partition file transfer must have the > ability to be limited at runtime; -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-10619) Add support files transmission between nodes over connection via CommunicationSpi
[ https://issues.apache.org/jira/browse/IGNITE-10619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10619: - Fix Version/s: 2.8 > Add support files transmission between nodes over connection via > CommunicationSpi > - > > Key: IGNITE-10619 > URL: https://issues.apache.org/jira/browse/IGNITE-10619 > Project: Ignite > Issue Type: Sub-task > Components: persistence >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-28 > Fix For: 2.8 > > Time Spent: 10h 10m > Remaining Estimate: 0h > > Partition preloader must support cache partition file relocation from one > cluster node to another (the zero copy algorithm [1] assume to be used by > default). To achieve this, the file transfer machinery must be implemented at > Apache Ignite over Communication SPI. > _CommunicationSpi_ > Ignite's Comminication SPI must support to: > * establishing channel connections to the remote node to an arbitrary topic > (GridTopic) with predefined processing policy; > * listening incoming channel creation events and registering connection > handlers on the particular node; > * an arbitrary set of channel parameters on connection handshake; > _FileTransmitProcessor_ > The file transmission manager must support to: > * using different approaches of incoming data handling – buffered and direct > (zero-copy approach of FileChannel#transferTo); > * transferring data by chunks of predefined size with saving intermediate > results; > * re-establishing connection if an error occurs and continue file > upload\download; > * limiting connection bandwidth (upload and download) at runtime; -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-11073) Take consistent cache partitions snapshot
[ https://issues.apache.org/jira/browse/IGNITE-11073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11073: - Summary: Take consistent cache partitions snapshot (was: Add Copy-on-Write machinery to the Checkpoiner) > Take consistent cache partitions snapshot > - > > Key: IGNITE-11073 > URL: https://issues.apache.org/jira/browse/IGNITE-11073 > Project: Ignite > Issue Type: Sub-task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-28 > Time Spent: 10m > Remaining Estimate: 0h > > *Checkpointer* > When the supplier node receives the cache partition file demand request it > will send the file over the CommunicationSpi. The cache partition file can be > concurrently updated by checkpoint thread during its transmission. To > guarantee the file consistency Сheckpointer must use Copy-on-Write [3] > tehnique and save a copy of updated chunk into the temporary file. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12064) Check license headers by checkstyle plugin
[
https://issues.apache.org/jira/browse/IGNITE-12064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906351#comment-16906351
]
Dmitriy Pavlov commented on IGNITE-12064:
-
I see rat plugin used in other Apache projects, so it is possible it is a
standard for ASF projects.
I'm not sure, but we should double-check it before we implement this change.
> Check license headers by checkstyle plugin
> --
>
> Key: IGNITE-12064
> URL: https://issues.apache.org/jira/browse/IGNITE-12064
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: checkstyle
>
> Currently, the {{apache-rat-plugin}} is used to check that source files
> contain the specific license header. The suite {{[Licenses Headers]}} is
> configured on TC to do so.
> It is possible to achieve the same thing with {{checkstyle-plugin}} (such it
> is already run on each build). This will save TC resources consumed to run
> both suites and simplify Ignite {{pom.xml}}.
> [1] https://checkstyle.sourceforge.io/config_header.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-9275) [POC] Introduce mechanism to fetch partition file via a p2p protocol
[ https://issues.apache.org/jira/browse/IGNITE-9275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9275: Summary: [POC] Introduce mechanism to fetch partition file via a p2p protocol (was: Introduce mechanism to fetch partition file via a p2p protocol) > [POC] Introduce mechanism to fetch partition file via a p2p protocol > > > Key: IGNITE-9275 > URL: https://issues.apache.org/jira/browse/IGNITE-9275 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexey Goncharuk >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-28 > Fix For: 2.8 > > > As a first step to estimate how much faster the file-rebalancing may be, I > suggest to implement a simple partition fetch procedure via the communication > SPI extension: > 1) Node A sends a partition fetch request to node B > 2) Node B starts a checkpoint and creates a local copy of the partition. Note > that during the partition copy there might be concurrent ongoing checkpoints, > this must be handled properly > 3) Node B establishes a new TCP connection on the TCP communication port > (handshake and verification is assumed) > 4) Node B calls transferFile (or native analogue, investigation needed) to > send the partition file in the most effective way > 5) Node A writes the file to a specified location on the local file system > After this mechanics is implemented, we need to hack the rebalance code and > use partition fetch logic instead of regular rebalance to measure > 1) How much faster (or slower) the new approach performs > 2) How it affects the concurrent transactions in the grid -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-12064) Check license headers by checkstyle plugin
[
https://issues.apache.org/jira/browse/IGNITE-12064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-12064:
--
Summary: Check license headers by checkstyle plugin (was: Check licence
headers by checkstyle plugin)
> Check license headers by checkstyle plugin
> --
>
> Key: IGNITE-12064
> URL: https://issues.apache.org/jira/browse/IGNITE-12064
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: checkstyle
>
> Currently, the {{apache-rat-plugin}} is used to check that source files
> contain the specific license header. The suite {{[Licenses Headers]}} is
> configured on TC to do so.
> It is possible to achieve the same thing with {{checkstyle-plugin}} (such it
> is already run on each build). This will save TC resources consumed to run
> both suites and simplify Ignite {{pom.xml}}.
> [1] https://checkstyle.sourceforge.io/config_header.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-11978) Javadoc enhancement for the ReadRepair feature.
[ https://issues.apache.org/jira/browse/IGNITE-11978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906242#comment-16906242 ] Nikolay Izhikov commented on IGNITE-11978: -- [~slava.koptilin] [~avinogradov] I answered in PR. > Javadoc enhancement for the ReadRepair feature. > --- > > Key: IGNITE-11978 > URL: https://issues.apache.org/jira/browse/IGNITE-11978 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: iep-31 > Fix For: 2.8 > > Time Spent: 4h 50m > Remaining Estimate: 0h > > The newly added `ReadRepair` feature requires Javadoc improvements. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12046) [IEP-35] LongMetric interface contains redundant methods.
[
https://issues.apache.org/jira/browse/IGNITE-12046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906239#comment-16906239
]
Andrey Gura commented on IGNITE-12046:
--
[~NIzhikov] Thanks! No we shouldn't. Only {{LongMetric}} interface had this
methods.
> [IEP-35] LongMetric interface contains redundant methods.
> -
>
> Key: IGNITE-12046
> URL: https://issues.apache.org/jira/browse/IGNITE-12046
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Trivial
> Labels: IEP-35
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following methods on {{LongMetric}} interface a redundant and have the
> same functionality:
> * {{get}}
> * {{longValue}}
> Mentioned methods should be removed.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12064) Check licence headers by checkstyle plugin
Maxim Muzafarov created IGNITE-12064:
Summary: Check licence headers by checkstyle plugin
Key: IGNITE-12064
URL: https://issues.apache.org/jira/browse/IGNITE-12064
Project: Ignite
Issue Type: Improvement
Reporter: Maxim Muzafarov
Currently, the {{apache-rat-plugin}} is used to check that source files contain
the specific license header. The suite {{[Licenses Headers]}} is configured on
TC to do so.
It is possible to achieve the same thing with {{checkstyle-plugin}} (such it is
already run on each build). This will save TC resources consumed to run both
suites and simplify Ignite {{pom.xml}}.
[1] https://checkstyle.sourceforge.io/config_header.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12046) [IEP-35] LongMetric interface contains redundant methods.
[
https://issues.apache.org/jira/browse/IGNITE-12046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906185#comment-16906185
]
Nikolay Izhikov commented on IGNITE-12046:
--
LGTM
Should we create similar tickets for other metrics?
> [IEP-35] LongMetric interface contains redundant methods.
> -
>
> Key: IGNITE-12046
> URL: https://issues.apache.org/jira/browse/IGNITE-12046
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Trivial
> Labels: IEP-35
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following methods on {{LongMetric}} interface a redundant and have the
> same functionality:
> * {{get}}
> * {{longValue}}
> Mentioned methods should be removed.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12063) Add ability to track system/user time held in transaction
Denis Chudov created IGNITE-12063: - Summary: Add ability to track system/user time held in transaction Key: IGNITE-12063 URL: https://issues.apache.org/jira/browse/IGNITE-12063 Project: Ignite Issue Type: Improvement Reporter: Denis Chudov Assignee: Denis Chudov Fix For: 2.8 We should dump user/system times in transaction to log on commit/rollback, if duration of transaction more then threshold. I want to see in log on tx coordinator node: # Transaction duration # System time: #* How long we were getting locks on keys? #* How long we were preparing transaction? #* How long we were commiting transaction? # User time (transaction time - total system time) # Transaction status (commit/rollback) The threshold could be set by system property and overwrite by JMX. We shouldn't dump times, if the property not set. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12061) Silently fail while try to recreate already existing index with differ inline_size.
[ https://issues.apache.org/jira/browse/IGNITE-12061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906168#comment-16906168 ] Dmitriy Pavlov commented on IGNITE-12061: - For now, I've set 2.7.6 if we manage to include it into scope. If not, maybe fix version should be set to 2.8 > Silently fail while try to recreate already existing index with differ > inline_size. > --- > > Key: IGNITE-12061 > URL: https://issues.apache.org/jira/browse/IGNITE-12061 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.5, 2.7, 2.7.5 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.7.6 > > Time Spent: 10m > Remaining Estimate: 0h > > INLINE_SIZE differ from previous value is not correctly sets. > 1. create index idx0(c1, c2) > 2. drop idx0 > 3. create index idx0(c1, c2) inline_size 100; > inline_size remains the same, in this case default = 10. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-12061) Silently fail while try to recreate already existing index with differ inline_size.
[ https://issues.apache.org/jira/browse/IGNITE-12061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-12061: Fix Version/s: 2.7.6 > Silently fail while try to recreate already existing index with differ > inline_size. > --- > > Key: IGNITE-12061 > URL: https://issues.apache.org/jira/browse/IGNITE-12061 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.5, 2.7, 2.7.5 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.7.6 > > Time Spent: 10m > Remaining Estimate: 0h > > INLINE_SIZE differ from previous value is not correctly sets. > 1. create index idx0(c1, c2) > 2. drop idx0 > 3. create index idx0(c1, c2) inline_size 100; > inline_size remains the same, in this case default = 10. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-11953) BTree corruption caused by byte array values
[
https://issues.apache.org/jira/browse/IGNITE-11953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906158#comment-16906158
]
Dmitriy Pavlov commented on IGNITE-11953:
-
[~dmagda], could you please avoid setting version to resolved tickets without
cherry-picking commit?
If you want a ticket to be included into release, mention it in the discussion.
This case it potentially lost commit. Now release is quite small and it is not
a problem, but it would become a problem for 2.8 & 3.0.
> BTree corruption caused by byte array values
>
>
> Key: IGNITE-11953
> URL: https://issues.apache.org/jira/browse/IGNITE-11953
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.7.6
>
>
> In some cases for caches with cache group, we can get BTree corruption
> exception.
> {code}
> 09:53:58,890][SEVERE][sys-stripe-10-#11][] Critical system error detected.
> Will be handled accordingly to configured handler [hnd=CustomFailureHandler
> [ignoreCriticalErrors=false, disabled=false][StopNodeOrHaltFailureHandler
> [tryStop=false, timeout=0]], failureCtx=FailureContext [type=CRITICAL_ERROR,
> err=class o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing
> a transaction has produced runtime exception]]class
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException:
> Committing a transaction has produced runtime exception
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:922)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.localFinish(GridDhtTxLocalAdapter.java:799)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.localFinish(GridDhtTxLocal.java:608)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.finishTx(GridDhtTxLocal.java:478)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.commitDhtLocalAsync(GridDhtTxLocal.java:535)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:1055)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:931)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:887)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:117)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:209)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1129)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:594)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1568)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1196)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1092)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:504)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on search row: SearchRow [key=KeyCacheObjectImpl [part=427,
> val=Grkg1DUF3yQE6tC9Se50mi5w.T, hasValBytes=true], hash=1872857770,
> cacheId=-420893003]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTr
[jira] [Commented] (IGNITE-12051) Update javadoc for the IgniteKernal class
[
https://issues.apache.org/jira/browse/IGNITE-12051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906131#comment-16906131
]
Maxim Muzafarov commented on IGNITE-12051:
--
[~Pavlukhin],
Thank you, I've applied all your suggestions.
> Update javadoc for the IgniteKernal class
> -
>
> Key: IGNITE-12051
> URL: https://issues.apache.org/jira/browse/IGNITE-12051
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
> Fix For: 2.8
>
> Time Spent: 6.5h
> Remaining Estimate: 0h
>
> Update all ambiguous an empty javadoc comments, such as:
> {code}
> /** */
> /** Periodic starvation check interval. */
> private static final long PERIODIC_STARVATION_CHECK_FREQ = 1000 * 30;
> /** Long jvm pause detector. */
> private LongJVMPauseDetector longJVMPauseDetector;
> /** Scheduler. */
> private IgniteScheduler scheduler;
> /** Stop guard. */
> private final AtomicBoolean stopGuard = new AtomicBoolean();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-11697) Suspended optimistic transaction automatically resumes to last thread after a timeout.
[
https://issues.apache.org/jira/browse/IGNITE-11697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11697:
---
Fix Version/s: 2.8
> Suspended optimistic transaction automatically resumes to last thread after a
> timeout.
> --
>
> Key: IGNITE-11697
> URL: https://issues.apache.org/jira/browse/IGNITE-11697
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-34
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This leads to unpredictable results from a user's point of view.
> Reproducer:
>
> {code:java}
> public class IgniteTxSuspendAndTimeoutTest extends GridCommonAbstractTest {
> @Test
> public void testSuspendAndTimeout() throws Exception {
> Ignite ignite = startGrid(0);
> IgniteCache cache = ignite.createCache(new
> CacheConfiguration<>().setName("c").setAtomicityMode(TRANSACTIONAL));
> Transaction tx1 = ignite.transactions().txStart(OPTIMISTIC,
> TransactionIsolation.REPEATABLE_READ, 100, 0);
> cache.put(1, 1);
> tx1.suspend();
> assertNull(cache.get(1)); // Pass here.
> doSleep(200);
> assertNull(cache.get(1)); // Fail here. But we don't expect any
> explicitly running transaction at this point.
> }
> }
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-11685) Java thin client: Handle multiple async requests in parallel
[
https://issues.apache.org/jira/browse/IGNITE-11685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11685:
---
Fix Version/s: 2.8
> Java thin client: Handle multiple async requests in parallel
>
>
> Key: IGNITE-11685
> URL: https://issues.apache.org/jira/browse/IGNITE-11685
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-34
> Fix For: 2.8
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> In the current implementation {{ReliableChannel}} uses an exclusive lock to
> send a request and waits for response synchronously. In this implementation,
> there are no benefits of using multiple threads. To improve throughput and
> latency we can implement async request/response processing on the client
> side, since the server side is already async.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-9410) Add transactions support to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9410: -- Summary: Add transactions support to thin clients (was: MVCC: add support to thin clients) > Add transactions support to thin clients > > > Key: IGNITE-9410 > URL: https://issues.apache.org/jira/browse/IGNITE-9410 > Project: Ignite > Issue Type: Task > Components: mvcc, thin client >Reporter: Vladimir Ozerov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-34 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently only ODBC and JDBC drivers support transactions and in not very > efficient way. We need to add transactional API to .NET, Java, CPP, NodeJS > and Python clients. > Key pieces: > # Add API to relevant clients > # Review listener logic - currently we create separate threads. But is it > really needed? > ## If there is an implicit operation and no ongoing transaction, then > operation might be executed right away > ## If cache operations are decoupled from threads, then we can resort to > reactive approach, when multiple transactions could be executed from the same > thread -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906006#comment-16906006 ] Ivan Pavlukhin commented on IGNITE-10973: - [~ivanan.fed], I suppose we cannot proceed until the problem with .NET tests is fixed. > Migrate example module tests from Junit 4 to 5 > -- > > Key: IGNITE-10973 > URL: https://issues.apache.org/jira/browse/IGNITE-10973 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Time Spent: 0.5h > Remaining Estimate: 0h > > For more information refer parent task. > Migrate from Junit 4 to 5 in the example module. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions
[ https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905998#comment-16905998 ] Aleksey Plekhanov commented on IGNITE-5714: --- [~DmitriyGovorukhin], sorry, fixed. > Implementation of suspend/resume for pessimistic transactions > - > > Key: IGNITE-5714 > URL: https://issues.apache.org/jira/browse/IGNITE-5714 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Alexey Kuznetsov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-34 > Fix For: 2.8 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > Support transaction suspend()\resume() operations for pessimistic > transactions. Resume can be called in another thread. >_+But there is a problem+_: Imagine, we started pessimistic transaction in > thread T1 and then perform put operation, which leads to sending > GridDistributedLockRequest to another node. Lock request contains thread id > of the transaction. Then we call suspend, resume in another thread and we > also must send messages to other nodes to change thread id. > It seems complicated task.It’s better to get rid of sending thread id to the > nodes. > We can use transaction xid on other nodes instead of thread id. Xid is sent > to nodes in GridDistributedLockRequest#nearXidVer >_+Proposed solution+_ : On remote nodes instead of thread id of near > transaction GridDistributedLockRequest#threadId use its xid > GridDistributedLockRequest#nearXidVer. > Remove usages of near transaction's thread id on remote nodes. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions
[ https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-5714: -- Fix Version/s: 2.8 > Implementation of suspend/resume for pessimistic transactions > - > > Key: IGNITE-5714 > URL: https://issues.apache.org/jira/browse/IGNITE-5714 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Alexey Kuznetsov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-34 > Fix For: 2.8 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > Support transaction suspend()\resume() operations for pessimistic > transactions. Resume can be called in another thread. >_+But there is a problem+_: Imagine, we started pessimistic transaction in > thread T1 and then perform put operation, which leads to sending > GridDistributedLockRequest to another node. Lock request contains thread id > of the transaction. Then we call suspend, resume in another thread and we > also must send messages to other nodes to change thread id. > It seems complicated task.It’s better to get rid of sending thread id to the > nodes. > We can use transaction xid on other nodes instead of thread id. Xid is sent > to nodes in GridDistributedLockRequest#nearXidVer >_+Proposed solution+_ : On remote nodes instead of thread id of near > transaction GridDistributedLockRequest#threadId use its xid > GridDistributedLockRequest#nearXidVer. > Remove usages of near transaction's thread id on remote nodes. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-5475) SQL: add CTE ("WITH AS") support
[
https://issues.apache.org/jira/browse/IGNITE-5475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-5475:
---
Summary: SQL: add CTE ("WITH AS") support (was: SQL: add "WITH AS" support)
> SQL: add CTE ("WITH AS") support
>
>
> Key: IGNITE-5475
> URL: https://issues.apache.org/jira/browse/IGNITE-5475
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Andrew Mashenkov
>Priority: Minor
> Labels: sql-engine
>
> Seems for now, H2 doesn't support "WITH AS" clause.
> We should throw exception until we found a workaround or "WITH" support be
> added to H2.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12061) Silently fail while try to recreate already existing index with differ inline_size.
[ https://issues.apache.org/jira/browse/IGNITE-12061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905985#comment-16905985 ] Stanilovsky Evgeny commented on IGNITE-12061: - [TC in progress|https://ci.ignite.apache.org/viewLog.html?buildId=4495067&buildTypeId=IgniteTests24Java8_RunAll] > Silently fail while try to recreate already existing index with differ > inline_size. > --- > > Key: IGNITE-12061 > URL: https://issues.apache.org/jira/browse/IGNITE-12061 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.5, 2.7, 2.7.5 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > INLINE_SIZE differ from previous value is not correctly sets. > 1. create index idx0(c1, c2) > 2. drop idx0 > 3. create index idx0(c1, c2) inline_size 100; > inline_size remains the same, in this case default = 10. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-5475) SQL: add "WITH AS" support
[
https://issues.apache.org/jira/browse/IGNITE-5475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905984#comment-16905984
]
Ivan Pavlukhin commented on IGNITE-5475:
[~amashenkov] could we close this ticket as it seems that queries using syntax
{{WITH ... AS}} (CTE) are accepted by Ignite?
> SQL: add "WITH AS" support
> --
>
> Key: IGNITE-5475
> URL: https://issues.apache.org/jira/browse/IGNITE-5475
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Andrew Mashenkov
>Priority: Minor
> Labels: sql-engine
>
> Seems for now, H2 doesn't support "WITH AS" clause.
> We should throw exception until we found a workaround or "WITH" support be
> added to H2.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions
[ https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905979#comment-16905979 ] Dmitriy Govorukhin commented on IGNITE-5714: [~alex_pl] Why issue resolve without fix version? > Implementation of suspend/resume for pessimistic transactions > - > > Key: IGNITE-5714 > URL: https://issues.apache.org/jira/browse/IGNITE-5714 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Alexey Kuznetsov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-34 > Time Spent: 4h 40m > Remaining Estimate: 0h > > Support transaction suspend()\resume() operations for pessimistic > transactions. Resume can be called in another thread. >_+But there is a problem+_: Imagine, we started pessimistic transaction in > thread T1 and then perform put operation, which leads to sending > GridDistributedLockRequest to another node. Lock request contains thread id > of the transaction. Then we call suspend, resume in another thread and we > also must send messages to other nodes to change thread id. > It seems complicated task.It’s better to get rid of sending thread id to the > nodes. > We can use transaction xid on other nodes instead of thread id. Xid is sent > to nodes in GridDistributedLockRequest#nearXidVer >_+Proposed solution+_ : On remote nodes instead of thread id of near > transaction GridDistributedLockRequest#threadId use its xid > GridDistributedLockRequest#nearXidVer. > Remove usages of near transaction's thread id on remote nodes. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12062) IntMap throws NullPointerException when map is creating
[ https://issues.apache.org/jira/browse/IGNITE-12062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905956#comment-16905956 ] Stepachev Maksim commented on IGNITE-12062: --- https://github.com/apache/ignite/pull/6769 > IntMap throws NullPointerException when map is creating > --- > > Key: IGNITE-12062 > URL: https://issues.apache.org/jira/browse/IGNITE-12062 > Project: Ignite > Issue Type: Bug >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The problem located here: > compactThreshold = (int)(COMPACT_LOAD_FACTOR * (entries.length >> 1)); > scaleThreshold = (int)(entries.length * SCALE_LOAD_FACTOR); > The fix looks that: > compactThreshold = (int)(COMPACT_LOAD_FACTOR * (entriesSize >> 1)); > scaleThreshold = (int)(entriesSize * SCALE_LOAD_FACTOR); -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12062) IntMap throws NullPointerException when map is creating
Stepachev Maksim created IGNITE-12062: - Summary: IntMap throws NullPointerException when map is creating Key: IGNITE-12062 URL: https://issues.apache.org/jira/browse/IGNITE-12062 Project: Ignite Issue Type: Bug Reporter: Stepachev Maksim Assignee: Stepachev Maksim The problem located here: compactThreshold = (int)(COMPACT_LOAD_FACTOR * (entries.length >> 1)); scaleThreshold = (int)(entries.length * SCALE_LOAD_FACTOR); The fix looks that: compactThreshold = (int)(COMPACT_LOAD_FACTOR * (entriesSize >> 1)); scaleThreshold = (int)(entriesSize * SCALE_LOAD_FACTOR); -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-9410) MVCC: add support to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905889#comment-16905889 ] Aleksey Plekhanov edited comment on IGNITE-9410 at 8/13/19 7:38 AM: The patch is ready, it includes server implementation and java client implementation to support transactions. [~isapego], there is thin client protocol change in the patch (we discussed it on dev list with you). Could you please review the patch? was (Author: alex_pl): The patch is ready. [~isapego], there is thin client protocol change in the patch (we discussed it on dev list with you). Could you please review the patch? > MVCC: add support to thin clients > - > > Key: IGNITE-9410 > URL: https://issues.apache.org/jira/browse/IGNITE-9410 > Project: Ignite > Issue Type: Task > Components: mvcc, thin client >Reporter: Vladimir Ozerov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-34 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently only ODBC and JDBC drivers support transactions and in not very > efficient way. We need to add transactional API to .NET, Java, CPP, NodeJS > and Python clients. > Key pieces: > # Add API to relevant clients > # Review listener logic - currently we create separate threads. But is it > really needed? > ## If there is an implicit operation and no ongoing transaction, then > operation might be executed right away > ## If cache operations are decoupled from threads, then we can resort to > reactive approach, when multiple transactions could be executed from the same > thread -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-9410) MVCC: add support to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905889#comment-16905889 ] Aleksey Plekhanov commented on IGNITE-9410: --- The patch is ready. [~isapego], there is thin client protocol change in the patch (we discussed it on dev list with you). Could you please review the patch? > MVCC: add support to thin clients > - > > Key: IGNITE-9410 > URL: https://issues.apache.org/jira/browse/IGNITE-9410 > Project: Ignite > Issue Type: Task > Components: mvcc, thin client >Reporter: Vladimir Ozerov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-34 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently only ODBC and JDBC drivers support transactions and in not very > efficient way. We need to add transactional API to .NET, Java, CPP, NodeJS > and Python clients. > Key pieces: > # Add API to relevant clients > # Review listener logic - currently we create separate threads. But is it > really needed? > ## If there is an implicit operation and no ongoing transaction, then > operation might be executed right away > ## If cache operations are decoupled from threads, then we can resort to > reactive approach, when multiple transactions could be executed from the same > thread -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-9410) MVCC: add support to thin clients
[
https://issues.apache.org/jira/browse/IGNITE-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905887#comment-16905887
]
Ignite TC Bot commented on IGNITE-9410:
---
{panel:title=Branch: [pull/6734/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4491910&buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: add support to thin clients
> -
>
> Key: IGNITE-9410
> URL: https://issues.apache.org/jira/browse/IGNITE-9410
> Project: Ignite
> Issue Type: Task
> Components: mvcc, thin client
>Reporter: Vladimir Ozerov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-34
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently only ODBC and JDBC drivers support transactions and in not very
> efficient way. We need to add transactional API to .NET, Java, CPP, NodeJS
> and Python clients.
> Key pieces:
> # Add API to relevant clients
> # Review listener logic - currently we create separate threads. But is it
> really needed?
> ## If there is an implicit operation and no ongoing transaction, then
> operation might be executed right away
> ## If cache operations are decoupled from threads, then we can resort to
> reactive approach, when multiple transactions could be executed from the same
> thread
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
