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

Dmitriy Pavlov edited comment on IGNITE-7339 at 8/13/18 5:48 PM:
-----------------------------------------------------------------

Hi [~ascherbakov], I've checked TC status, and it has a number of suspicious 
failures.

Could you please merge master into the branch and re-run TC?

Probably statistic was outdated, one TC run is already unavailable. So as the 
simplest solution I suggest running fix using the fresh master state.

{noformat}
 Platform .NET (Long Running) [ tests 0 TIMEOUT ]       Critical F.R.: 0,0%
                
 PDS 2 [ tests 3 ]       
 IgnitePdsTestSuite2: IgniteWalReaderTest.testFillWalWithDifferentTypes (fail 
rate 0,0%) 
  
 PDS (Direct IO) 2 [ tests 1 ]   
 IgnitePdsNativeIoTestSuite2: 
SlowHistoricalRebalanceSmallHistoryTest.testReservation   (fail rate 0,0%) 
                 
 Java Client [ tests 2 ]         
 IgniteClientTestSuite: ClientTcpMultiThreadedSelfTest.testMultithreadedTaskRun 
(fail rate 0,0%) 
                 
 Cache 7 (With Persistence) [ tests 1 ]  
 IgniteCacheTestSuite7: 
CacheMetricsManageTest.testClearStatisticsAfterDisableStatistics        (fail 
rate 0,0%) 
                        
 Cache 1 [ tests 1 ]     
 IgniteBinaryCacheTestSuite: 
IgniteDiagnosticMessagesMultipleConnectionsTest.testRemoteTx       (fail rate 
0,0%) 
                
 Basic 1 [ tests 2 ]     
 IgniteBasicTestSuite: 
IgniteCacheP2pUnmarshallingErrorTest.testResponseMessageOnUnmarshallingFailed   
 (fail rate 0,0%) 
                        
 Cache (Restarts) 1 [ tests 1 ]  
 IgniteCacheRestartTestSuite: 
GridCachePartitionedNodeRestartTest.testRestartWithPutTenNodesTwoBackups  (fail 
rate 0,0%) 
{noformat}



was (Author: dpavlov):
Hi [~ascherbakov], I've checked TC status, and it has a number of suspicious 
failures.

Could you please merge master into the branch and re-run TC?

Probably statistic was outdated, one TC run is already unavailable. So as the 
simplest solution I suggest running fix using the fresh master state.

``` Platform .NET (Long Running) [ tests 0 TIMEOUT ]    Critical F.R.: 0,0%
                
 PDS 2 [ tests 3 ]       
 IgnitePdsTestSuite2: IgniteWalReaderTest.testFillWalWithDifferentTypes (fail 
rate 0,0%) 
  
 PDS (Direct IO) 2 [ tests 1 ]   
 IgnitePdsNativeIoTestSuite2: 
SlowHistoricalRebalanceSmallHistoryTest.testReservation   (fail rate 0,0%) 
                 
 Java Client [ tests 2 ]         
 IgniteClientTestSuite: ClientTcpMultiThreadedSelfTest.testMultithreadedTaskRun 
(fail rate 0,0%) 
                 
 Cache 7 (With Persistence) [ tests 1 ]  
 IgniteCacheTestSuite7: 
CacheMetricsManageTest.testClearStatisticsAfterDisableStatistics        (fail 
rate 0,0%) 
                        
 Cache 1 [ tests 1 ]     
 IgniteBinaryCacheTestSuite: 
IgniteDiagnosticMessagesMultipleConnectionsTest.testRemoteTx       (fail rate 
0,0%) 
                
 Basic 1 [ tests 2 ]     
 IgniteBasicTestSuite: 
IgniteCacheP2pUnmarshallingErrorTest.testResponseMessageOnUnmarshallingFailed   
 (fail rate 0,0%) 
                        
 Cache (Restarts) 1 [ tests 1 ]  
 IgniteCacheRestartTestSuite: 
GridCachePartitionedNodeRestartTest.testRestartWithPutTenNodesTwoBackups  (fail 
rate 0,0%) 
 ```

> RENTING partition is not evicted after restore from storage
> -----------------------------------------------------------
>
>                 Key: IGNITE-7339
>                 URL: https://issues.apache.org/jira/browse/IGNITE-7339
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Semen Boikov
>            Assignee: Alexei Scherbakov
>            Priority: Critical
>
> If partition was in RENTING state at the moment when node is stopped, then 
> after restart it is not evicted.
> It seems it is an issue in GridDhtLocalPartition.rent, 'tryEvictAsync' is not 
> called is partition was already in RENTING state.
> Also there is error in GridDhtPartitionTopologyImpl.checkEvictions: partition 
> state is always treated as changed after part.rent call even if part.rent 
> does not actually change state.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to