[jira] [Commented] (IGNITE-7285) Add default query timeout

2019-08-18 Thread Saikat Maitra (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910057#comment-16910057
 ] 

Saikat Maitra commented on IGNITE-7285:
---

Hi [~Pavlukhin]

I have updated the PR and made changes in IgniteH2Indexing for query timeout so 
that default query timeout get used during query execution.

Please take a look and let me know if this change looks good.

I will update tests if the approach looks good.

PR [https://github.com/apache/ignite/pull/6490]

Regards,

Saikat

> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
>  Labels: sql-stability
> Fix For: 2.8
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be 
> very useful to have default timeout value provided on cache startup. Let's 
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-12083) Change release scripts according pre-build DEB/RPM folders

2019-08-18 Thread Dmitriy Pavlov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-12083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-12083:

Description: svn: E02: Can't stat 
'/mnt/c/dev_env/release-2.7.6-rc0/packaging/pkg': No such file or directory

> Change release scripts according pre-build DEB/RPM folders
> --
>
> Key: IGNITE-12083
> URL: https://issues.apache.org/jira/browse/IGNITE-12083
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.7.6
>
>
> svn: E02: Can't stat '/mnt/c/dev_env/release-2.7.6-rc0/packaging/pkg': No 
> such file or directory



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-12083) Change release scripts according pre-build DEB/RPM folders

2019-08-18 Thread Dmitriy Pavlov (JIRA)
Dmitriy Pavlov created IGNITE-12083:
---

 Summary: Change release scripts according pre-build DEB/RPM folders
 Key: IGNITE-12083
 URL: https://issues.apache.org/jira/browse/IGNITE-12083
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov
 Fix For: 2.7.6






--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-12082) Automate version assignment to pre-build DEB/RPM or describe how to set packages version to RC version

2019-08-18 Thread Dmitriy Pavlov (JIRA)
Dmitriy Pavlov created IGNITE-12082:
---

 Summary: Automate version assignment to pre-build DEB/RPM or 
describe how to set packages version to RC version
 Key: IGNITE-12082
 URL: https://issues.apache.org/jira/browse/IGNITE-12082
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov
 Fix For: 2.7.6


https://ci.ignite.apache.org/viewLog.html?buildTypeId=Releases_ApacheIgniteMain_ReleaseBuild=4513186_Releases_ApacheIgniteMain_ReleaseBuild=ignite-2.7.6

RC 0 for 2.7.6. the build was successful, but versions for packages remain 
unchanged

https://cwiki.apache.org/confluence/display/IGNITE/Release+Process does not 
require Release manager to update versions, but pre-build DEB & RPM keeps 
version from previous release.

We need to add a new step
https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-4.1.Updatereleasebranchversionsandyearincopyrightmessages
e.g. 4.1.4, where will ask a release manager to update versions.

May be similar with commit 
https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=84c2dac5103a448bdaee88cb8290fd6e05a435bb



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12068) puzzling select result

2019-08-18 Thread Dmitriy Pavlov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-12068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909973#comment-16909973
 ] 

Dmitriy Pavlov commented on IGNITE-12068:
-

[~Pavlukhin] thank you for preparing release notes. I was thinking about how to 
describe the issue, but you've already shared 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
>  Labels: 2.7.6-rc0
> 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-12081) Page replacement can reload invalid page during checkpoint

2019-08-18 Thread Dmitriy Pavlov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-12081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-12081:

Labels: 2.7.6-rc0  (was: )

> 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
>  Labels: 2.7.6-rc0
> Fix For: 2.7.6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> 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] [Commented] (IGNITE-12081) Page replacement can reload invalid page during checkpoint

2019-08-18 Thread Dmitriy Pavlov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-12081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909952#comment-16909952
 ] 

Dmitriy Pavlov commented on IGNITE-12081:
-

Blockers not related to this fix (always happen because TC Bot does not compare 
base branch build problem occurrences).

The fix is looking good for me, Dmitriy, thank for your contribution and for 
preparing fix for 2.7.6.

Merged to 2.7.6. (via ./apply-pull-request.sh 6787 -tb ignite-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
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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] [Commented] (IGNITE-12081) Page replacement can reload invalid page during checkpoint

2019-08-18 Thread Ignite TC Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-12081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909948#comment-16909948
 ] 

Ignite TC Bot commented on IGNITE-12081:


{panel:title=Branch: [ignite-2.7.6_12081] Base: [ignite-2.7.6] : Possible 
Blockers (4)|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=454]]

{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Failure on metric 
|https://ci.ignite.apache.org/viewLog.html?buildId=456]]

{color:#d04437}Platform C++ (Linux)*{color} [[tests 0 Exit Code , Failure on 
metric |https://ci.ignite.apache.org/viewLog.html?buildId=458]]

{color:#d04437}Platform C++ (Win x64 / Release){color} [[tests 0 
BuildFailureOnMessage 
|https://ci.ignite.apache.org/viewLog.html?buildId=4511124]]

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4510431buildTypeId=IgniteTests24Java8_RunAll]

> 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
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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-12057) Persistence files are stored to temp dir

2019-08-18 Thread Dmitriy Pavlov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-12057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-12057:

Labels: 2.7.6-rc0  (was: )

> 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
>  Labels: 2.7.6-rc0
> 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] [Updated] (IGNITE-12068) puzzling select result

2019-08-18 Thread Dmitriy Pavlov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-12068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-12068:

Labels: 2.7.6-rc0  (was: )

> 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
>  Labels: 2.7.6-rc0
> 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-12060) Incorrect row size calculation, lead to tree corruption

2019-08-18 Thread Dmitriy Pavlov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-12060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-12060:

Labels: 2.7.6-rc0  (was: )

> Incorrect row size calculation, lead to tree corruption
> ---
>
> Key: IGNITE-12060
> URL: https://issues.apache.org/jira/browse/IGNITE-12060
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Critical
>  Labels: 2.7.6-rc0
> Fix For: 2.7.6
>
>
> We do not correctly calculate old row size and new row size for check 
> in-place update. One of them may include cacheId but other not. Size 
> dependent on shared group or not.
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.CacheDataStoreImpl#canUpdateOldRow



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-11767) GridDhtPartitionsFullMessage retains huge maps on heap in exchange history

2019-08-18 Thread Dmitriy Pavlov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-11767:

Labels: 2.7.6-rc0  (was: )

> 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
>  Labels: 2.7.6-rc0
> 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] [Commented] (IGNITE-9562) Destroyed cache that resurrected on an old offline node breaks PME

2019-08-18 Thread Dmitriy Pavlov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909937#comment-16909937
 ] 

Dmitriy Pavlov commented on IGNITE-9562:


according to Eduard comments
 IgniteCacheRestartTestSuite2: IgniteCachePutAllRestartTest.testStopNode   
- needs to be researched
PDS 1 [ tests 5 ]   
  IgnitePdsTestSuite: IgnitePdsDestroyCacheTest.testDestroyCachesAbruptly   
   - can be Ignored/failed because of 
https://issues.apache.org/jira/browse/IGNITE-8717

Cache 7 [ tests 2 ]  
  IgniteCacheTestSuite7: CacheMetricsManageTest.testJmxPdsStatisticsEnable 
- this is an issue, need to be fixed.

> 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: Eduard Shangareev
>Priority: Critical
> Fix For: 2.8, 2.7.6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Given:
> 2 nodes, persistence enabled.
> 1) Stop 1 node
> 2) Destroy cache through client
> 3) Start stopped node
> When the stopped node joins to cluster it starts all caches that it has seen 
> before stopping.
> If that cache was cluster-widely destroyed it leads to breaking the crash 
> recovery process or PME.
> Root cause - we don't start/collect caches from the stopped node on another 
> part of a cluster.
> In case of PARTITIONED cache mode that scenario breaks crash recovery:
> {noformat}
> java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:696)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.updateLocal(GridDhtPartitionTopologyImpl.java:2449)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.afterStateRestored(GridDhtPartitionTopologyImpl.java:679)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2445)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2321)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1568)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1308)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1255)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:766)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2577)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2457)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> In case of REPLICATED cache mode that scenario breaks PME coordinator process:
> {noformat}
> [2018-09-12 
> 18:50:36,407][ERROR][sys-#148%distributed.CacheStopAndRessurectOnOldNodeTest0%][GridCacheIoManager]
>  Failed to process message [senderId=4b6fd0d4-b756-4a9f-90ca-f0ee2511, 
> messageType=class 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsSingleMessage]
> java.lang.AssertionError: 3080586
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.clientTopology(GridCachePartitionExchangeManager.java:815)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.updatePartitionSingleMap(GridDhtPartitionsExchangeFuture.java:3621)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2439)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:137)
>   at 
> 

[jira] [Updated] (IGNITE-10451) .NET: Persistence does not work with custom affinity function

2019-08-18 Thread Dmitriy Pavlov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-10451:

Labels: .NET 2.7.6-rc0  (was: .NET)

> .NET: Persistence does not work with custom affinity function
> -
>
> Key: IGNITE-10451
> URL: https://issues.apache.org/jira/browse/IGNITE-10451
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, 2.7.6-rc0
> Fix For: 2.7.6
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> To reproduce: assign custom affinity function in 
> {{PersistenceTest.TestCacheDataSurvivesNodeRestart}}.
> As a result, node restart fails with the following exception:
> {code}
> Apache.Ignite.Core.Common.IgniteException : An error occurred during cache 
> configuration loading from file 
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
>   > Apache.Ignite.Core.Common.JavaException : class 
> org.apache.ignite.IgniteException: An error occurred during cache 
> configuration loading from file 
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
>   at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1027)
>   at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:48)
>   at 
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
> Caused by: class org.apache.ignite.IgniteCheckedException: An error occurred 
> during cache configuration loading from file 
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:902)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:844)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.addCacheOnJoinFromConfig(GridCacheProcessor.java:891)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.restoreCacheConfigurations(GridCacheProcessor.java:756)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1300(GridCacheProcessor.java:204)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5456)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:412)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:724)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4473)
>   at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1047)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
>   at 
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
>   ... 1 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
> deserialize object with given class loader: 
> sun.misc.Launcher$AppClassLoader@18b4aac2
>   at 
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:147)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:898)
>   ... 15 more
> Caused by: java.lang.IllegalArgumentException: Ignite instance name thread 
> local must be set or this method should be accessed under 
> org.apache.ignite.thread.IgniteThread
>   at 
> org.apache.ignite.internal.IgnitionEx.localIgnite(IgnitionEx.java:1413)
>   at 
> 

[jira] [Commented] (IGNITE-9562) Destroyed cache that resurrected on an old offline node breaks PME

2019-08-18 Thread Ignite TC Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909935#comment-16909935
 ] 

Ignite TC Bot commented on IGNITE-9562:
---

{panel:title=Branch: [pull/6781/head] Base: [ignite-2.7.6] : Possible Blockers 
(8)|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=4512345]]

{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Failure on metric 
|https://ci.ignite.apache.org/viewLog.html?buildId=4512347]]

{color:#d04437}Platform C++ (Linux)*{color} [[tests 0 Exit Code , Failure on 
metric |https://ci.ignite.apache.org/viewLog.html?buildId=4512349]]

{color:#d04437}Cache (Restarts) 2{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=4512351]]
* 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=4512353]]
* 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=4512355]]
* IgniteCacheTestSuite7: CacheMetricsManageTest.testJmxPdsStatisticsEnable - 
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=4512359]]

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4507062buildTypeId=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: Eduard Shangareev
>Priority: Critical
> Fix For: 2.8, 2.7.6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Given:
> 2 nodes, persistence enabled.
> 1) Stop 1 node
> 2) Destroy cache through client
> 3) Start stopped node
> When the stopped node joins to cluster it starts all caches that it has seen 
> before stopping.
> If that cache was cluster-widely destroyed it leads to breaking the crash 
> recovery process or PME.
> Root cause - we don't start/collect caches from the stopped node on another 
> part of a cluster.
> In case of PARTITIONED cache mode that scenario breaks crash recovery:
> {noformat}
> java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:696)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.updateLocal(GridDhtPartitionTopologyImpl.java:2449)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.afterStateRestored(GridDhtPartitionTopologyImpl.java:679)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2445)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2321)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1568)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1308)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1255)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:766)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2577)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2457)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at 

[jira] [Updated] (IGNITE-11736) Make the TeamCity console quiet.

2019-08-18 Thread Dmitriy Pavlov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-11736:

Labels: 2.7.6-rc0  (was: )

> Make the TeamCity console quiet.
> 
>
> Key: IGNITE-11736
> URL: https://issues.apache.org/jira/browse/IGNITE-11736
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
>  Labels: 2.7.6-rc0
> Fix For: 2.7.6
>
> Attachments: quiet-console-checkbox.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> As a result of this discussion: 
> [https://lists.apache.org/list.html?d...@ignite.apache.org:lte=1M:Make%20the%20TeamCity%20console%20quiet.]
>  
>  # Rollover will be locked. Pros: Only one big file in an archive. Cons: Max 
> size of the file isn't limited. 2. Run all will contain a parameter for 
> switch off the quiet mode. 3. New config: log4j-tc-test.xml for TeamCity 
> environment.
> TC fixes:
> Add a checkbox into the general run window. *By default* the checkbox *is 
> active*. If the checkbox is *active*, the TeamCity adds next params for java 
> run: *-DIGNITE_TEST_PROP_LOG4J_FILE=log4j-tc-test.xml -DIGNITE_QUIET=true* 
> otherwise *empty params*.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12071) Test failures after IGNITE-9562 fix in IGFS suite

2019-08-18 Thread Dmitriy Pavlov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909924#comment-16909924
 ] 

Dmitriy Pavlov commented on IGNITE-12071:
-

[~EdShangGG], [~ivan.glukos], is my understanding correct that fix for these 
tests if the following one-liner

https://github.com/apache/ignite/pull/6765/files#diff-3b0297f8e0e757b6b5ede921d629c6b5R608

?

> Test failures after IGNITE-9562 fix in IGFS suite
> -
>
> Key: IGNITE-12071
> URL: https://issues.apache.org/jira/browse/IGNITE-12071
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Eduard Shangareev
>Priority: Blocker
> Fix For: 2.7.6
>
>
> https://lists.apache.org/thread.html/50375927a1375189c0aeec7dcaabc43ba83b7acee94524a3483d0c1b@%3Cdev.ignite.apache.org%3E
> Unfortunately, since https://issues.apache.org/jira/browse/IGNITE-9562 is 
> planned to the 2.7.6 it is a blocker for the release 
> *New test failure in master-nightly 
> IgfsCachePerBlockLruEvictionPolicySelfTest.testFilePrimary 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-8890685422557348790=%3Cdefault%3E=testDetails
>  *New test failure in master-nightly 
> IgfsCachePerBlockLruEvictionPolicySelfTest.testFileDualExclusion 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=3724804704021179739=%3Cdefault%3E=testDetails
>  Changes may lead to failure were done by 
>  - eduard shangareev  
> https://ci.ignite.apache.org/viewModification.html?modId=889258



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12071) Test failures after IGNITE-9562 fix in IGFS suite

2019-08-18 Thread Dmitriy Pavlov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909923#comment-16909923
 ] 

Dmitriy Pavlov commented on IGNITE-12071:
-

This issue is fixed under https://issues.apache.org/jira/browse/IGNITE-12059 , 
still need to cherry-pick fix to 2.7.6 once fix 
https://issues.apache.org/jira/browse/IGNITE-9562 is there

> Test failures after IGNITE-9562 fix in IGFS suite
> -
>
> Key: IGNITE-12071
> URL: https://issues.apache.org/jira/browse/IGNITE-12071
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Eduard Shangareev
>Priority: Blocker
> Fix For: 2.7.6
>
>
> https://lists.apache.org/thread.html/50375927a1375189c0aeec7dcaabc43ba83b7acee94524a3483d0c1b@%3Cdev.ignite.apache.org%3E
> Unfortunately, since https://issues.apache.org/jira/browse/IGNITE-9562 is 
> planned to the 2.7.6 it is a blocker for the release 
> *New test failure in master-nightly 
> IgfsCachePerBlockLruEvictionPolicySelfTest.testFilePrimary 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-8890685422557348790=%3Cdefault%3E=testDetails
>  *New test failure in master-nightly 
> IgfsCachePerBlockLruEvictionPolicySelfTest.testFileDualExclusion 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=3724804704021179739=%3Cdefault%3E=testDetails
>  Changes may lead to failure were done by 
>  - eduard shangareev  
> https://ci.ignite.apache.org/viewModification.html?modId=889258



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)