[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=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=4491523buildTypeId=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=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=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=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=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=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=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=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=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
>
[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=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=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=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=16905985#comment-16905985 ] Stanilovsky Evgeny commented on IGNITE-12061: - [TC in progress|https://ci.ignite.apache.org/viewLog.html?buildId=4495067=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=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=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=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=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=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=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=4491910buildTypeId=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)
[jira] [Comment Edited] (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=16905875#comment-16905875
]
Ivan Pavlukhin edited comment on IGNITE-12051 at 8/13/19 6:48 AM:
--
[~Mmuzaf], I left few comments on GitHub.
was (Author: pavlukhin):
[~Mmuzaf], I left several comments on GitHub.
> 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: 5.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] [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=16905875#comment-16905875
]
Ivan Pavlukhin commented on IGNITE-12051:
-
[~Mmuzaf], I left several comments on GitHub.
> 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: 5.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)
