[jira] [Commented] (IGNITE-12068) puzzling select result
[ https://issues.apache.org/jira/browse/IGNITE-12068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909576#comment-16909576 ] Ivan Pavlukhin commented on IGNITE-12068: - Cherry-picked to master in https://github.com/apache/ignite/commit/45d719e66c95df8a115af467792f8b89dace83e3 > 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 >Assignee: Ivan Pavlukhin >Priority: Blocker > Fix For: 2.7.6 > > Time Spent: 0.5h > Remaining Estimate: 0h > > 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=16909575#comment-16909575 ] Ivan Pavlukhin commented on IGNITE-12068: - C++ and .NET test results are same as in 2.7.6. MVCC Queries tests are not stable, results are comparable to other 2.7.6 runs. > 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 >Assignee: Ivan Pavlukhin >Priority: Blocker > Fix For: 2.7.6 > > Time Spent: 0.5h > Remaining Estimate: 0h > > 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=16909571#comment-16909571
]
Ignite TC Bot commented on IGNITE-12068:
{panel:title=Branch: [pull/6786/head] Base: [ignite-2.7.6] : Possible Blockers
(5)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux Clang){color} [[tests 0 Exit Code , Failure
on metric |https://ci.ignite.apache.org/viewLog.html?buildId=4508498]]
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=4508500]]
{color:#d04437}Platform C++ (Linux)*{color} [[tests 0 Exit Code , Failure on
metric |https://ci.ignite.apache.org/viewLog.html?buildId=4508502]]
{color:#d04437}MVCC Queries{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4509060]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlCoordinatorFailoverTest.testUpdate_N_Objects_ClientServer_Backups0_Sql_Persistence
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform C++ (Win x64 / Release){color} [[tests 0
BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=4508512]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4507680buildTypeId=IgniteTests24Java8_RunAll]
> 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
>Assignee: Ivan Pavlukhin
>Priority: Blocker
> Fix For: 2.7.6
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 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=16909423#comment-16909423 ] Denis Magda commented on IGNITE-12068: -- [~JerryKwan] should be available in the first weeks of September. See this thread for more details: http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-7-6-Time-Scope-and-Release-manager-td42944.html > 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 >Assignee: Ivan Pavlukhin >Priority: Blocker > Fix For: 2.7.6 > > Time Spent: 0.5h > Remaining Estimate: 0h > > 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-10808) Discovery message queue may build up with TcpDiscoveryMetricsUpdateMessage
[ https://issues.apache.org/jira/browse/IGNITE-10808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-10808: Reviewer: Sergey Chugunov (was: Alexey Goncharuk) > Discovery message queue may build up with TcpDiscoveryMetricsUpdateMessage > -- > > Key: IGNITE-10808 > URL: https://issues.apache.org/jira/browse/IGNITE-10808 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Stanislav Lukyanov >Assignee: Denis Mekhanikov >Priority: Major > Labels: discovery > Fix For: 2.8 > > Attachments: IgniteMetricsOverflowTest.java > > > A node receives a new metrics update message every `metricsUpdateFrequency` > milliseconds, and the message will be put at the top of the queue (because it > is a high priority message). > If processing one message takes more than `metricsUpdateFrequency` then > multiple `TcpDiscoveryMetricsUpdateMessage` will be in the queue. A long > enough delay (e.g. caused by a network glitch or GC) may lead to the queue > building up tens of metrics update messages which are essentially useless to > be processed. Finally, if processing a message on average takes a little more > than `metricsUpdateFrequency` (even for a relatively short period of time, > say, for a minute due to network issues) then the message worker will end up > processing only the metrics updates and the cluster will essentially hang. > Reproducer is attached. In the test, the queue first builds up and then very > slowly being teared down, causing "Failed to wait for PME" messages. > Need to change ServerImpl's SocketReader not to put another metrics update > message to the top of the queue if it already has one (or replace the one at > the top with new one). -- 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=16909148#comment-16909148 ] Ivan Pavlukhin commented on IGNITE-12061: - [~zstan], I left a couple comments on GitHub. I suggest to exclude this ticket from 2.7.6 and complete with this ticket calmly. > 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: 3h 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-12081) Page replacement can reload invalid page during checkpoint
[
https://issues.apache.org/jira/browse/IGNITE-12081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-12081:
Fix Version/s: 2.7.6
> Page replacement can reload invalid page during checkpoint
> --
>
> Key: IGNITE-12081
> URL: https://issues.apache.org/jira/browse/IGNITE-12081
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.7.6
>
>
> There is a race between {{writeCheckpointPages}} and page replacement process:
> * Checkpointer thread begins a checkpoint
> * Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
> content *and clear dirty flag*
> * Page replacement tries to find a page for replacement and chooses this
> page, the page is thrown away
> * Before the page is written back to the store, the page is acquired again.
> As a result, an older copy of the page is brought back to memory, which
> causes all kinds of corruption exceptions and assertions.
> The attached unit test demonstrates the issue. It is likely that all
> baselines are affected starting from 2.4
> As a part of this ticket, we must add more unit-tests for checkpointing
> protocol invariants we rely on.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12081) Page replacement can reload invalid page during checkpoint
Dmitriy Govorukhin created IGNITE-12081:
---
Summary: Page replacement can reload invalid page during checkpoint
Key: IGNITE-12081
URL: https://issues.apache.org/jira/browse/IGNITE-12081
Project: Ignite
Issue Type: Bug
Reporter: Dmitriy Govorukhin
Assignee: Dmitriy Govorukhin
There is a race between {{writeCheckpointPages}} and page replacement process:
* Checkpointer thread begins a checkpoint
* Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
content *and clear dirty flag*
* Page replacement tries to find a page for replacement and chooses this page,
the page is thrown away
* Before the page is written back to the store, the page is acquired again.
As a result, an older copy of the page is brought back to memory, which causes
all kinds of corruption exceptions and assertions.
The attached unit test demonstrates the issue. It is likely that all baselines
are affected starting from 2.4
As a part of this ticket, we must add more unit-tests for checkpointing
protocol invariants we rely on.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-11767) GridDhtPartitionsFullMessage retains huge maps on heap in exchange history
[ https://issues.apache.org/jira/browse/IGNITE-11767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-11767: Fix Version/s: (was: 2.8) > GridDhtPartitionsFullMessage retains huge maps on heap in exchange history > -- > > Key: IGNITE-11767 > URL: https://issues.apache.org/jira/browse/IGNITE-11767 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Blocker > Fix For: 2.7.6 > > Time Spent: 20m > Remaining Estimate: 0h > > ExchangeHistory keeps a FinishState for every topology version. > FinishState contains msg, which contains at least two huge maps: > partCntrs2 and partsSizesBytes. > We should probably strip msg, removing those two data structures before > putting msg in exchFuts linked list to be stowed away. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (IGNITE-12073) The doc should mention IGNITE_UPDATE_NOTIFIER has no effect if you're not the first node that started up
[ https://issues.apache.org/jira/browse/IGNITE-12073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk resolved IGNITE-12073. --- Resolution: Fixed Fix Version/s: 2.8 Also made some minor edits in IgniteSystemProperties.java. > The doc should mention IGNITE_UPDATE_NOTIFIER has no effect if you're not the > first node that started up > > > Key: IGNITE-12073 > URL: https://issues.apache.org/jira/browse/IGNITE-12073 > Project: Ignite > Issue Type: Improvement >Reporter: chin >Assignee: Alexey Goncharuk >Priority: Major > Labels: javadoc > Fix For: 2.8 > > > It drove me crazy > I wanted to disable the auto update check. > I found this page > [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html#IGNITE_UPDATE_NOTIFIER] > > spent a few hours trying to set the system property in different ways but > couldn't get the update notification to go away. > > Then I found IGNITE-2350. > > That info should be mentioned clearly in the docs. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-10697) [ML] Add Frequency Encoding
[ https://issues.apache.org/jira/browse/IGNITE-10697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909042#comment-16909042 ] Yury Babak commented on IGNITE-10697: - reviewed, ready for merge > [ML] Add Frequency Encoding > --- > > Key: IGNITE-10697 > URL: https://issues.apache.org/jira/browse/IGNITE-10697 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Trivial > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Encode the values to a fraction of all the labels. Can work with linear > models if the frequency is correlated with the target value. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12073) The doc should mention IGNITE_UPDATE_NOTIFIER has no effect if you're not the first node that started up
[
https://issues.apache.org/jira/browse/IGNITE-12073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909014#comment-16909014
]
Alexey Goncharuk commented on IGNITE-12073:
---
I suggest the following edit for the javadoc:
{code}
* If this system property is set to {@code false} - no checks for new versions
will
* be performed by Ignite. By default, Ignite periodically checks for the new
* version and prints out the message into the log if a new version of Ignite is
* available for download.
*
* Update notifier enabled flag is a cluster-wide value and determined according
to the local setting
* during the start of the first node in the cluster. The chosen value will
survive the first node shutdown
* and will override the property value on all newly joining nodes.
{code}
> The doc should mention IGNITE_UPDATE_NOTIFIER has no effect if you're not the
> first node that started up
>
>
> Key: IGNITE-12073
> URL: https://issues.apache.org/jira/browse/IGNITE-12073
> Project: Ignite
> Issue Type: Improvement
>Reporter: chin
>Assignee: Alexey Goncharuk
>Priority: Major
> Labels: javadoc
>
> It drove me crazy
> I wanted to disable the auto update check.
> I found this page
> [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html#IGNITE_UPDATE_NOTIFIER]
>
> spent a few hours trying to set the system property in different ways but
> couldn't get the update notification to go away.
>
> Then I found IGNITE-2350.
>
> That info should be mentioned clearly in the docs.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (IGNITE-12073) The doc should mention IGNITE_UPDATE_NOTIFIER has no effect if you're not the first node that started up
[ https://issues.apache.org/jira/browse/IGNITE-12073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-12073: - Assignee: Alexey Goncharuk > The doc should mention IGNITE_UPDATE_NOTIFIER has no effect if you're not the > first node that started up > > > Key: IGNITE-12073 > URL: https://issues.apache.org/jira/browse/IGNITE-12073 > Project: Ignite > Issue Type: Improvement >Reporter: chin >Assignee: Alexey Goncharuk >Priority: Major > Labels: javadoc > > It drove me crazy > I wanted to disable the auto update check. > I found this page > [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html#IGNITE_UPDATE_NOTIFIER] > > spent a few hours trying to set the system property in different ways but > couldn't get the update notification to go away. > > Then I found IGNITE-2350. > > That info should be mentioned clearly in the docs. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-12073) The doc should mention IGNITE_UPDATE_NOTIFIER has no effect if you're not the first node that started up
[ https://issues.apache.org/jira/browse/IGNITE-12073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-12073: -- Ignite Flags: (was: Docs Required) > The doc should mention IGNITE_UPDATE_NOTIFIER has no effect if you're not the > first node that started up > > > Key: IGNITE-12073 > URL: https://issues.apache.org/jira/browse/IGNITE-12073 > Project: Ignite > Issue Type: Improvement >Reporter: chin >Assignee: Alexey Goncharuk >Priority: Major > Labels: javadoc > > It drove me crazy > I wanted to disable the auto update check. > I found this page > [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html#IGNITE_UPDATE_NOTIFIER] > > spent a few hours trying to set the system property in different ways but > couldn't get the update notification to go away. > > Then I found IGNITE-2350. > > That info should be mentioned clearly in the docs. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-11767) GridDhtPartitionsFullMessage retains huge maps on heap in exchange history
[ https://issues.apache.org/jira/browse/IGNITE-11767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909004#comment-16909004 ] Ilya Kasnacheev commented on IGNITE-11767: -- [~dpavlov] done, pushed to ignite-2.7.6 > GridDhtPartitionsFullMessage retains huge maps on heap in exchange history > -- > > Key: IGNITE-11767 > URL: https://issues.apache.org/jira/browse/IGNITE-11767 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Blocker > Fix For: 2.8, 2.7.6 > > Time Spent: 20m > Remaining Estimate: 0h > > ExchangeHistory keeps a FinishState for every topology version. > FinishState contains msg, which contains at least two huge maps: > partCntrs2 and partsSizesBytes. > We should probably strip msg, removing those two data structures before > putting msg in exchFuts linked list to be stowed away. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12057) Persistence files are stored to temp dir
[ https://issues.apache.org/jira/browse/IGNITE-12057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908994#comment-16908994 ] Dmitriy Govorukhin commented on IGNITE-12057: - Merged to master and ignite-2.7.6 > Persistence files are stored to temp dir > > > Key: IGNITE-12057 > URL: https://issues.apache.org/jira/browse/IGNITE-12057 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Anton Kalashnikov >Priority: Critical > Fix For: 2.7.6 > > Time Spent: 20m > Remaining Estimate: 0h > > h2. Description > Check this thread: > [https://stackoverflow.com/questions/56951913/ignite-persistent-schema-tables-disappeared-sometimes/56977212#56977212] > This prospect almost dropped us because the company could figure out why > persistence files disappear upon restarts. They turned off WARN logging level > and could see our warning saying that the files are written to such a > directory. > I've updated Ignite docs: > [https://apacheignite.readme.io/docs/distributed-persistent-store#section-persistence-path-management] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12080) Add extended logging for rebalance
Kirill Tkalenko created IGNITE-12080: Summary: Add extended logging for rebalance Key: IGNITE-12080 URL: https://issues.apache.org/jira/browse/IGNITE-12080 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko We should log all information about finished rebalance on demander node. I'd have in log: h3. Total information: # Rebalance duration, rebalance start time/rebalance finish time # How many partitions were processed in each topic (number of paritions, number of entries, number of bytes) # How many nodes were suppliers in rebalance (nodeId, number of supplied paritions, number of supplied entries, number of bytes, duraton of getting and processing partitions from supplier) h3. Information per cache group: # Rebalance duration, rebalance start time/rebalance finish time # How many partitions were processed in each topic (number of paritions, number of entries, number of bytes) # How many nodes were suppliers in rebalance (nodeId, number of supplied paritions, list of partition ids with PRIMARY/BACKUP flag, number of supplied entries, number of bytes, duraton of getting and processing partitions from supplier) # Information about each partition distribution (list of nodeIds with primary/backup flag and marked supplier nodeId) h3. Information per supplier node: # How many paritions were requested: #* Total number #* Primary/backup distribution (number of primary partitions, number of backup partitions) #* Total number of entries #* Total size partitions in bytes # How many paritions were requested per cache group: #* Number of requested partitions #* Number of entries in partitions #* Total size of partitions in bytes #* List of requested partitions with size in bytes, count entries, primary or backup partition flag -- 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=16908976#comment-16908976 ] Stanilovsky Evgeny commented on IGNITE-12061: - [~Pavlukhin] i fixed partially, plz recheck ? thanks ! > 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: 2h 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-12077) Improve Checkstyle or other inspections profile to avoid using GG- reference in Ignite code base
[ https://issues.apache.org/jira/browse/IGNITE-12077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12077: - Labels: checkstyle (was: ) > Improve Checkstyle or other inspections profile to avoid using GG- reference > in Ignite code base > > > Key: IGNITE-12077 > URL: https://issues.apache.org/jira/browse/IGNITE-12077 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Pavlov >Priority: Major > Labels: checkstyle > > Time to time tests are Ignored or todo added with reference to > GG- tickets " > For example here > https://github.com/apache/ignite/pull/6748/files#diff-2dd1dad039cddd36610c62a3dc2c1a28R223 > It is suggested to add some inspection check on TC to reject patches if there > is a line > containing: > - ": //ggsystems.atlassian.net/" > - or at the same time Ignore or todo and "GG- [0-9] *" -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12077) Improve Checkstyle or other inspections profile to avoid using GG- reference in Ignite code base
[
https://issues.apache.org/jira/browse/IGNITE-12077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908957#comment-16908957
]
Maxim Muzafarov commented on IGNITE-12077:
--
Huge +1
But imagine if some workaround of checking pattern [GG-X] will be used? I'd
suggest allowing and check only such patterns:
1. @Ignore("https://issues.apache.org/jira/browse/IGNITE-X;) - Ignoring
tests only with link to an Ignite issue
2. // TODO IGNITE-X Message about what is needed - Todo comments only with
link to an Ignite issue
> Improve Checkstyle or other inspections profile to avoid using GG- reference
> in Ignite code base
>
>
> Key: IGNITE-12077
> URL: https://issues.apache.org/jira/browse/IGNITE-12077
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Pavlov
>Priority: Major
>
> Time to time tests are Ignored or todo added with reference to
> GG- tickets "
> For example here
> https://github.com/apache/ignite/pull/6748/files#diff-2dd1dad039cddd36610c62a3dc2c1a28R223
> It is suggested to add some inspection check on TC to reject patches if there
> is a line
> containing:
> - ": //ggsystems.atlassian.net/"
> - or at the same time Ignore or todo and "GG- [0-9] *"
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12057) Persistence files are stored to temp dir
[ https://issues.apache.org/jira/browse/IGNITE-12057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908943#comment-16908943 ] Sergey Chugunov commented on IGNITE-12057: -- [~akalashnikov], Change looks good to me, lets merge this fix to necessary branch. Thank you for your contribution! > Persistence files are stored to temp dir > > > Key: IGNITE-12057 > URL: https://issues.apache.org/jira/browse/IGNITE-12057 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Anton Kalashnikov >Priority: Critical > Fix For: 2.7.6 > > Time Spent: 10m > Remaining Estimate: 0h > > h2. Description > Check this thread: > [https://stackoverflow.com/questions/56951913/ignite-persistent-schema-tables-disappeared-sometimes/56977212#56977212] > This prospect almost dropped us because the company could figure out why > persistence files disappear upon restarts. They turned off WARN logging level > and could see our warning saying that the files are written to such a > directory. > I've updated Ignite docs: > [https://apacheignite.readme.io/docs/distributed-persistent-store#section-persistence-path-management] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-10697) [ML] Add Frequency Encoding
[ https://issues.apache.org/jira/browse/IGNITE-10697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-10697: -- Issue Type: Sub-task (was: New Feature) Parent: IGNITE-12079 > [ML] Add Frequency Encoding > --- > > Key: IGNITE-10697 > URL: https://issues.apache.org/jira/browse/IGNITE-10697 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Trivial > Fix For: 2.8 > > > Encode the values to a fraction of all the labels. Can work with linear > models if the frequency is correlated with the target value. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12079) [ML][Umbrella] Add advanced preprocessing techniques
Aleksey Zinoviev created IGNITE-12079: - Summary: [ML][Umbrella] Add advanced preprocessing techniques Key: IGNITE-12079 URL: https://issues.apache.org/jira/browse/IGNITE-12079 Project: Ignite Issue Type: New Feature Components: ml Affects Versions: 2.8 Reporter: Aleksey Zinoviev Assignee: Aleksey Zinoviev Fix For: 2.8 *Main goal:* To reduce the gap between Apache Spark and Apache Ignite in preprocessing operations. The reducing of the gap could help with loading Spark ML Pipelines to Ignite ML. Next steps: # Add Frequency Encoder # Add two Imputing Strategies (MIN, MAX, COUNT, MOST_FREQUENT, LEAST_FREQUENT) # Add RobustScaler (will be added in Spark 3.0) # Add CountVectorizer # Add FeatureHasher # Add QuantileDiscretizer # Add Locality Sensitive Hashing (LSH) # Add LabelEncoder # Add RevertStringIndexing # Add multi-column preprocessor -- 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=16908893#comment-16908893 ] Stanilovsky Evgeny commented on IGNITE-12061: - [~Pavlukhin] thanks a lot ! i`ll try to check all your comments soon. As for : "Is it right that before this patch we did not clear index partition at all on index drop? Do you know why was it so?" - i can only explain that it take place for simplification, if u have only root page after index destroy no need to handle IndexDestroy exceptions any more, i discuss with [~agoncharuk] too and it looks like correct behavior to throw exception on concurrent index drop and usage. > 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: 1h > 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] [Resolved] (IGNITE-7022) Use QuadTree for kNN performance
[ https://issues.apache.org/jira/browse/IGNITE-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev resolved IGNITE-7022. -- Resolution: Won't Fix > Use QuadTree for kNN performance > > > Key: IGNITE-7022 > URL: https://issues.apache.org/jira/browse/IGNITE-7022 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Minor > > Now, kNN implementation is not too fast. Its performance could be increased > with [https://en.wikipedia.org/wiki/Quadtree] > Also, benchmarks should be provided too -- 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=16908853#comment-16908853 ] Ivan Pavlukhin commented on IGNITE-12061: - [~zstan], I left my comments on [GitHub|https://github.com/apache/ignite/pull/6770#pullrequestreview-275803048]. Also we need to clarify one thing about "physical" indexes destroy. Is it right that before this patch we did not clear index partition at all on index drop? Do you know why was it so? If it is true we need to highlight that it is not only about _index recreation with different inline size_. > 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: 1h > 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-9562) Destroyed cache that resurrected on an old offline node breaks PME
[
https://issues.apache.org/jira/browse/IGNITE-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908852#comment-16908852
]
Ignite TC Bot commented on IGNITE-9562:
---
{panel:title=Branch: [pull/6781/head] Base: [ignite-2.7.6] : Possible Blockers
(41)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux Clang){color} [[tests 0 Exit Code , Failure
on metric |https://ci.ignite.apache.org/viewLog.html?buildId=4503638]]
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=4503679]]
{color:#d04437}Platform C++ (Linux)*{color} [[tests 0 Exit Code , Failure on
metric |https://ci.ignite.apache.org/viewLog.html?buildId=4503632]]
{color:#d04437}MVCC Cache{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4503639]]
* IgniteCacheMvccTestSuite:
CacheMvccPartitionedCoordinatorFailoverTest.testGetReadInsideTxInProgressCoordinatorFails_ReadDelay
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache (Restarts) 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4503654]]
* IgniteCacheRestartTestSuite2: IgniteCachePutAllRestartTest.testStopNode -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}PDS 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=4503673]]
* IgnitePdsTestSuite: IgnitePdsDestroyCacheTest.testDestroyCachesAbruptly -
Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsTestSuite: IgnitePdsDestroyCacheTest.testDestroyGroupCachesAbruptly
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4503662]]
* IgniteCacheTestSuite7: CacheMetricsManageTest.testJmxPdsStatisticsEnable -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 6{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4503661]]
* IgniteCacheTestSuite6: TxRollbackOnTimeoutNearCacheTest.testSimple - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform C++ (Win x64 / Release){color} [[tests 0
BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=4503633]]
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
30|https://ci.ignite.apache.org/viewLog.html?buildId=4503630]]
* ZookeeperDiscoverySpiTestSuite1: ZookeeperDiscoverySpiTest.testSegmentation2
- Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1: ZookeeperDiscoverySpiTest.testSegmentation3
- Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testConcurrentStartStop2_EventsThrottle - Test has
low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testCustomEventsSimple1_5_Nodes - Test has low fail
rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testMultipleClusters - Test has low fail rate in base
branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testConnectionRestore_Coordinator1_1 - Test has low
fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testWithPersistence1 - Test has low fail rate in base
branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testWithPersistence2 - Test has low fail rate in base
branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1: ZookeeperDiscoverySpiTest.testStartStop1 -
Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1: ZookeeperDiscoverySpiTest.testStartStop2 -
Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1: ZookeeperDiscoverySpiTest.testDeployService2
- Test has low fail rate in base branch 0,0% and is not flaky
... and 19 tests blockers
{color:#d04437}Cache (Failover) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4503648]]
* IgniteCacheFailoverTestSuite:
IgniteAtomicLongChangingTopologySelfTest.testClientQueueCreateCloseFailover -
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=4503707buildTypeId=IgniteTests24Java8_RunAll]
> Destroyed cache that resurrected on an old offline node breaks PME
> --
>
> Key: IGNITE-9562
> URL: https://issues.apache.org/jira/browse/IGNITE-9562
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee:
[jira] [Commented] (IGNITE-12057) Persistence files are stored to temp dir
[
https://issues.apache.org/jira/browse/IGNITE-12057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908833#comment-16908833
]
Ignite TC Bot commented on IGNITE-12057:
{panel:title=Branch: [pull/6774/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=4498708buildTypeId=IgniteTests24Java8_RunAll]
> Persistence files are stored to temp dir
>
>
> Key: IGNITE-12057
> URL: https://issues.apache.org/jira/browse/IGNITE-12057
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Anton Kalashnikov
>Priority: Critical
> Fix For: 2.7.6
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. Description
> Check this thread:
> [https://stackoverflow.com/questions/56951913/ignite-persistent-schema-tables-disappeared-sometimes/56977212#56977212]
> This prospect almost dropped us because the company could figure out why
> persistence files disappear upon restarts. They turned off WARN logging level
> and could see our warning saying that the files are written to such a
> directory.
> I've updated Ignite docs:
> [https://apacheignite.readme.io/docs/distributed-persistent-store#section-persistence-path-management]
--
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=16908826#comment-16908826 ] Yury Gerzhedovich commented on IGNITE-12068: [~Pavlukhin], the patch is good. Let's merge it. > 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 >Assignee: Ivan Pavlukhin >Priority: Blocker > Fix For: 2.7.6 > > Time Spent: 10m > Remaining Estimate: 0h > > 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-12078) implement loadCache on CacheJdbcBlobStore
Luca created IGNITE-12078: - Summary: implement loadCache on CacheJdbcBlobStore Key: IGNITE-12078 URL: https://issues.apache.org/jira/browse/IGNITE-12078 Project: Ignite Issue Type: Task Reporter: Luca When store a cache persistent in a 3rd Party Storage as Blob the CacheJdbcBlobStoreFactory is used. According to the documentation ([https://apacheignite.readme.io/v1.9/docs/persistent-store#section-loadcache-] / [https://apacheignite.readme.io/docs/data-loading#ignitecacheloadcache]) the method loadCache() should be used to load the data from the persistent storage back to the cache. Unfortunately the loadCache() method is only implemented in the CacheJdbcPojoStore but not in the CacheJdbcBlobStore. -- 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=16908780#comment-16908780 ] Ivan Pavlukhin commented on IGNITE-12068: - *Release notes* Fixed a bug when SELECT with an equality predicate on a part of a complex primary key returned a single row result while multiple matching rows existed in the table. > 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 >Assignee: Ivan Pavlukhin >Priority: Blocker > Fix For: 2.7.6 > > Time Spent: 10m > Remaining Estimate: 0h > > 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-12057) Persistence files are stored to temp dir
[ https://issues.apache.org/jira/browse/IGNITE-12057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-12057: - Reviewer: Sergey Chugunov > Persistence files are stored to temp dir > > > Key: IGNITE-12057 > URL: https://issues.apache.org/jira/browse/IGNITE-12057 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Anton Kalashnikov >Priority: Critical > Fix For: 2.7.6 > > Time Spent: 10m > Remaining Estimate: 0h > > h2. Description > Check this thread: > [https://stackoverflow.com/questions/56951913/ignite-persistent-schema-tables-disappeared-sometimes/56977212#56977212] > This prospect almost dropped us because the company could figure out why > persistence files disappear upon restarts. They turned off WARN logging level > and could see our warning saying that the files are written to such a > directory. > I've updated Ignite docs: > [https://apacheignite.readme.io/docs/distributed-persistent-store#section-persistence-path-management] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
