[jira] [Commented] (IGNITE-6816) Webconsole: investigate/integrate Webpack dll-plugin

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin commented on IGNITE-6816:
---

[~Klaster_1] I've adjusted webpack config to preserve fuction and class names. 
Please review,

> Webconsole: investigate/integrate Webpack dll-plugin
> 
>
> Key: IGNITE-6816
> URL: https://issues.apache.org/jira/browse/IGNITE-6816
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Trivial
> Fix For: 2.5
>
>
> As the webconsole frontend app size grows, it takes more and more time to 
> incrementally rebuild after each source code change in development 
> environment. Let's investigate this plugin 
> https://webpack.js.org/plugins/dll-plugin/ and integrate it into webpack 
> build pipeline if it offers measureable performance improvements.



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

[jira] [Assigned] (IGNITE-6816) Webconsole: investigate/integrate Webpack dll-plugin

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-6816:
-

Assignee: Ilya Borisov  (was: Alexey Kuznetsov)

> Webconsole: investigate/integrate Webpack dll-plugin
> 
>
> Key: IGNITE-6816
> URL: https://issues.apache.org/jira/browse/IGNITE-6816
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Trivial
> Fix For: 2.5
>
>
> As the webconsole frontend app size grows, it takes more and more time to 
> incrementally rebuild after each source code change in development 
> environment. Let's investigate this plugin 
> https://webpack.js.org/plugins/dll-plugin/ and integrate it into webpack 
> build pipeline if it offers measureable performance improvements.



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

[jira] [Updated] (IGNITE-5698) Publish Abbreviation Plugin in Apache Ignite code base

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-5698:
---
Attachment: ignite-abbrev-plugin-3.0.0.zip

> Publish Abbreviation Plugin in Apache Ignite code base
> --
>
> Key: IGNITE-5698
> URL: https://issues.apache.org/jira/browse/IGNITE-5698
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Vyacheslav Daradur
>Priority: Major
> Attachments: ignite-abbrev-plugin-3.0.0.zip, ignite-abbrev-plugin.jar
>
>
> Reported at dev list
> http://apache-ignite-developers.2346864.n4.nabble.com/abbrevation-rules-plugin-td19356.html
> There is a plugin , mentioned  in Abbreviation Rules 
>  page 
> that performs on-the-fly check.
> https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-IntelliJIdeaPlugin



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

[jira] [Commented] (IGNITE-8110) GridCacheWriteBehindStore.Flusher thread uses the wrong transformation from milliseconds to nanoseconds.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8110:


GitHub user antkr opened a pull request:

https://github.com/apache/ignite/pull/3742

IGNITE-8110

Fixed ms to nanos transformation.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8110

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3742.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3742


commit f901b799710fda853b9298ff4911b018400a8ceb
Author: Anton Kurbanov 
Date:   2018-04-03T14:32:57Z

IGNITE-8110 fixed transformation of cache flush frequency from ms into nanos

commit 85db60395ac1fbada93ae0fc6e3030dc2d3227eb
Author: Anton Kurbanov 
Date:   2018-04-03T16:58:55Z

Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite 
into ignite-8110




> GridCacheWriteBehindStore.Flusher thread uses the wrong transformation from 
> milliseconds to nanoseconds.
> 
>
> Key: IGNITE-8110
> URL: https://issues.apache.org/jira/browse/IGNITE-8110
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Assignee: Anton Kurbanov
>Priority: Minor
>
> The initial value of a cache flushing frequency is defined as follows:
> {code}
> /** Cache flushing frequence in nanos. */
> protected long cacheFlushFreqNanos = cacheFlushFreq * 1000;
> {code}
> where is {{cacheFlushFreq}} is equal to
> {code}
> /** Default flush frequency for write-behind cache store in milliseconds. 
> */
> public static final long DFLT_WRITE_BEHIND_FLUSH_FREQUENCY = 5000;
> {code}



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

[jira] [Commented] (IGNITE-8078) Add new metrics for data storage

[Ivan Daschinskiy (JIRA)]

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

Ivan Daschinskiy commented on IGNITE-8078:
--

[~DmitriyGovorukhin], may be it's better to extend already implemented 
TcpDiscoverySpiMBean.getCoordinator()? i.e. this method could return String 
formed by U.toString(ClusterNode) instead of UUID.

> Add new metrics for data storage
> 
>
> Key: IGNITE-8078
> URL: https://issues.apache.org/jira/browse/IGNITE-8078
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
>  Labels: iep-6
> Fix For: 2.5
>
>
> 1. Create new MXbean for each index, IndexMxBean
> {code}
> class IndexMxBean{
> /** The number of PUT operations on the index. */
> long getProcessedPuts();
> /** The number of GET operations on the index. */
> long getProcessedGets();
> /** The total index size in bytes. */
> long getIndexSize();
> /** Index name.*/
> String getName();
> }
> {code}
> 2. Add new metrics for data storage and cache group.
> {code}
> class CacheGroupMetricsMXBean{
> /** The total index size in bytes */
> long getIndexesSize();
> /** Total size in bytes for primary key indexes. */
> long getPKIndexesSize();
> /** Total size in bytes for reuse list.*/
> long getReuseListSize();
> /** Total size in bytes. */
> long getTotalSize();
> /** Total size in bytes for pure data.*/
> long getDataSize();
> /** Total size in bytes for data pages.*/
> long getDataPagesSize();
> /** CacheGroup type. PARTITIONED, REPLICATED, LOCAL.*/
> String getType();
> /** Partitions currently assigned to the local node in this cache group. */
> int[] getPartitions();
> }
> {code}
> {code}
> class DataRegionMXBean{
> /** Total size in bytes for indexes. */
> long getIndexesSize();
> /** Total size in bytes for primary key indexes. */
> long getPKIndexesSize();
> /** Total size in bytes. */
> long getTotalSize();
> /** Total size in bytes for pure data.*/
> long getDataSize();
> /** Total size in bytes for data pages.*/
> long getDataPagesSize();
> /** Total used offheap size in bytes. */
> long getOffheapUsedSize();
> /** The number of read pages from last restart. */
> long getPagesRead();
> /** The number of writen pages from last restart. */
> long getPagesWriten();
> /** The number of replaced pages from last restart . */
> long getPagesReplaced();
> /** Total dirty pages for the next checkpoint. */
> long getDirtyPagesForNextCheckpoint();
> }
> {code}
> {code}
> class DataStorageMXbean{
> /** Total size in bytes for indexes. */
> long getIndexesSize();
> /** Total size in bytes for primary key indexes. */
> long getPKIndexesSize();
> /** Total size in bytes for all storages. */
> long getTotalSize();
> /** Total offheap size in bytes. */
> long getOffHeapSize();
> /** Total used offheap size in bytes for all data regions. */
> long getOffheapUsedSize();
> /** Total size in bytes for pure data.*/
> long getDataSize();
> /** The number of read pages from last restart. */
> long getPagesRead();
> /** The number of writen pages from last restart. */
> long getPagesWriten();
> /** The number of replaced pages from last restart. */
> long getPagesReplaced();
> /** Total checkpoint time from last restart. */
> long getCheckpointTotalTime();
> /** Total dirty pages for the next checkpoint. */
> long getDirtyPagesForNextCheckpoint();
> /** Total size in bytes for storage wal files. */
> long getWalTotalSize();
> /** Time of the last WAL segment rollover. */
> long getWalLastSwitchTime();
> }
> {code}
> {code}
> class IgniteMxBean {
> /** Returns string containing Node ID, Consistent ID, Node Order */
> String getCurrentCoordinator();
> }
> {code}
> Depricate CacheMetrics.getRebalancingPartitionsCount(); and move to 
> CacheGroupMetricsMXBean.getRebalancingPartitionsCount();



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

[jira] [Commented] (IGNITE-5698) Publish Abbreviation Plugin in Apache Ignite code base

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-5698:


I’ve prepared [the PR|https://github.com/dspavlov/ignite-abbrev-plugin/pull/1] 
with following changes:
- added Apache 2.0 license to the header of each file
- replaced prefix ‘Grid’ by ‘Ignite’ in class names
- added README.md with a simple description
- changed version 2.6.3 -> 3.0.0 because the project has own GitHub
releases tab and completely new versioning isn't preferable IMO

Also, I’ve built [new artifact|^ignite-abbrev-plugin.jar] and tested it, it 
works well.

> Publish Abbreviation Plugin in Apache Ignite code base
> --
>
> Key: IGNITE-5698
> URL: https://issues.apache.org/jira/browse/IGNITE-5698
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Vyacheslav Daradur
>Priority: Major
> Attachments: ignite-abbrev-plugin.jar
>
>
> Reported at dev list
> http://apache-ignite-developers.2346864.n4.nabble.com/abbrevation-rules-plugin-td19356.html
> There is a plugin , mentioned  in Abbreviation Rules 
>  page 
> that performs on-the-fly check.
> https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-IntelliJIdeaPlugin



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

[jira] [Assigned] (IGNITE-6007) GridCacheBinaryObjectMetadataExchangeMultinodeTest.testSequentialUpdatesNoConflicts fails sometimes

[Amelchev Nikita (JIRA)]

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

Amelchev Nikita reassigned IGNITE-6007:
---

Assignee: (was: Amelchev Nikita)

> GridCacheBinaryObjectMetadataExchangeMultinodeTest.testSequentialUpdatesNoConflicts
>  fails sometimes
> ---
>
> Key: IGNITE-6007
> URL: https://issues.apache.org/jira/browse/IGNITE-6007
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> {noformat}
> java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.binary.GridCacheBinaryObjectMetadataExchangeMultinodeTest.testSequentialUpdatesNoConflicts(GridCacheBinaryObjectMetadataExchangeMultinodeTest.java:289)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Updated] (IGNITE-5698) Publish Abbreviation Plugin in Apache Ignite code base

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-5698:
---
Attachment: ignite-abbrev-plugin.jar

> Publish Abbreviation Plugin in Apache Ignite code base
> --
>
> Key: IGNITE-5698
> URL: https://issues.apache.org/jira/browse/IGNITE-5698
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Vyacheslav Daradur
>Priority: Major
> Attachments: ignite-abbrev-plugin.jar
>
>
> Reported at dev list
> http://apache-ignite-developers.2346864.n4.nabble.com/abbrevation-rules-plugin-td19356.html
> There is a plugin , mentioned  in Abbreviation Rules 
>  page 
> that performs on-the-fly check.
> https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-IntelliJIdeaPlugin



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

[jira] [Reopened] (IGNITE-5698) Publish Abbreviation Plugin in Apache Ignite code base

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur reopened IGNITE-5698:


> Publish Abbreviation Plugin in Apache Ignite code base
> --
>
> Key: IGNITE-5698
> URL: https://issues.apache.org/jira/browse/IGNITE-5698
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Vyacheslav Daradur
>Priority: Major
>
> Reported at dev list
> http://apache-ignite-developers.2346864.n4.nabble.com/abbrevation-rules-plugin-td19356.html
> There is a plugin , mentioned  in Abbreviation Rules 
>  page 
> that performs on-the-fly check.
> https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-IntelliJIdeaPlugin



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

[jira] [Resolved] (IGNITE-5698) Publish Abbreviation Plugin in Apache Ignite code base

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur resolved IGNITE-5698.

Resolution: Done

> Publish Abbreviation Plugin in Apache Ignite code base
> --
>
> Key: IGNITE-5698
> URL: https://issues.apache.org/jira/browse/IGNITE-5698
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Vyacheslav Daradur
>Priority: Major
>
> Reported at dev list
> http://apache-ignite-developers.2346864.n4.nabble.com/abbrevation-rules-plugin-td19356.html
> There is a plugin , mentioned  in Abbreviation Rules 
>  page 
> that performs on-the-fly check.
> https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-IntelliJIdeaPlugin



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

[jira] [Assigned] (IGNITE-8110) GridCacheWriteBehindStore.Flusher thread uses the wrong transformation from milliseconds to nanoseconds.

[Anton Kurbanov (JIRA)]

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

Anton Kurbanov reassigned IGNITE-8110:
--

Assignee: Anton Kurbanov

> GridCacheWriteBehindStore.Flusher thread uses the wrong transformation from 
> milliseconds to nanoseconds.
> 
>
> Key: IGNITE-8110
> URL: https://issues.apache.org/jira/browse/IGNITE-8110
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Assignee: Anton Kurbanov
>Priority: Minor
>
> The initial value of a cache flushing frequency is defined as follows:
> {code}
> /** Cache flushing frequence in nanos. */
> protected long cacheFlushFreqNanos = cacheFlushFreq * 1000;
> {code}
> where is {{cacheFlushFreq}} is equal to
> {code}
> /** Default flush frequency for write-behind cache store in milliseconds. 
> */
> public static final long DFLT_WRITE_BEHIND_FLUSH_FREQUENCY = 5000;
> {code}



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

[jira] [Updated] (IGNITE-8070) .Net: FailureHandler should be added to Ignite configuration

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-8070:
---
Labels: iep-14  (was: MakeTeamcityGreenAgain iep-14)

> .Net: FailureHandler should be added to Ignite configuration
> 
>
> Key: IGNITE-8070
> URL: https://issues.apache.org/jira/browse/IGNITE-8070
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Andrey Gura
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> {{IgniteConfiguration}} class was extended by new methods: 
> {{setFailureHandler}} and {{getFailureHandler}}. Corresponding changes should 
> be done in ignite .Net 



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

[jira] [Commented] (IGNITE-7957) TestDistributedJoins fails in CPP Win32 suite

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7957:


On TC still reproducible, see muted failure in history 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=417754190398412=%3Cdefault%3E=testDetails

Please feel free to ask if there will be need to mass triggering tests on TC.

> TestDistributedJoins fails in CPP Win32 suite
> -
>
> Key: IGNITE-7957
> URL: https://issues.apache.org/jira/browse/IGNITE-7957
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Dmitriy Pavlov
>Assignee: Igor Sapego
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=417754190398412=%3Cdefault%3E=testDetails
>Ignite Platform CPP Win32 [ tests 1 TC_EXIT_CODE ]  
>   IgniteOdbcTest: QueriesTestSuite: TestDistributedJoins (fail rate 9,8%) 
> {noformat}
> check env != 0 passed
> check dbc != 0 passed
> check stmt != 0 passed
> check rowsNum > 0 passed
> check rowsNum < entriesNum passed
> check env != 0 passed
> check dbc != 0 passed
> check stmt != 0 passed
> check rowsNum == entriesNum failed [2565 != 1000]
> {noformat}



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

[jira] [Commented] (IGNITE-5975) [Test Failed] GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreSingleNodeFailure

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-5975:
--

The reason for this hang is that we stop processing query responses from remote 
nodes when context is stopping, but keep holding a read lock when still waiting 
for response.

> [Test Failed] 
> GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreSingleNodeFailure
> ---
>
> Key: IGNITE-5975
> URL: https://issues.apache.org/jira/browse/IGNITE-5975
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.5
>
>
> Fails locally.
> Example of failing - 
> http://ci.ignite.apache.org/viewLog.html?buildId=758964=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures#testNameId-2988875689386264427.



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

[jira] [Assigned] (IGNITE-5975) [Test Failed] GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreSingleNodeFailure

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-5975:


Assignee: Alexey Goncharuk

> [Test Failed] 
> GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreSingleNodeFailure
> ---
>
> Key: IGNITE-5975
> URL: https://issues.apache.org/jira/browse/IGNITE-5975
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.5
>
>
> Fails locally.
> Example of failing - 
> http://ci.ignite.apache.org/viewLog.html?buildId=758964=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures#testNameId-2988875689386264427.



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

[jira] [Updated] (IGNITE-7898) IgniteCachePartitionLossPolicySelfTest is flaky on TC

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7898:
---
Fix Version/s: 2.5

> IgniteCachePartitionLossPolicySelfTest is flaky on TC
> -
>
> Key: IGNITE-7898
> URL: https://issues.apache.org/jira/browse/IGNITE-7898
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Affected tests:
> testReadOnlyAll
> testReadWriteSafe
> Exception:
> {code:java}
> junit.framework.AssertionFailedError: Failed to find expected lost partition 
> [exp=0, lost=[]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.verifyCacheOps(IgniteCachePartitionLossPolicySelfTest.java:219)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.checkLostPartition(IgniteCachePartitionLossPolicySelfTest.java:166)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.testReadWriteSafe(IgniteCachePartitionLossPolicySelfTest.java:114)
> {code}
> The problem of failure:
> After we prepare topology and shutdown the node containing lost partition we 
> start to check it immediately on all nodes (cache.lostPartitions() method). 
> Sometimes we invoke this method on client node where last PME is not even 
> started and getting empty list of lost partitions because we haven't received 
> it yet on PME.
> Possible solution:
> Wait for PME finishing on all nodes (including client) before start to check 
> for lost partitions.



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

[jira] [Resolved] (IGNITE-8102) IgnitePdsCorruptedStoreTest.testNodeInvalidatedWhenPersistenceIsCorrupted failed in Direct IO 2 suite

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov resolved IGNITE-8102.

Resolution: Cannot Reproduce

Already fixed by changing illegal state to StorageException 
https://issues.apache.org/jira/browse/IGNITE-7831

> IgnitePdsCorruptedStoreTest.testNodeInvalidatedWhenPersistenceIsCorrupted 
> failed in Direct IO 2 suite
> -
>
> Key: IGNITE-8102
> URL: https://issues.apache.org/jira/browse/IGNITE-8102
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
>PDS (Direct IO) [2] [ tests 1 ] 
>   IgnitePdsNativeIoTestSuite2: 
> IgnitePdsCorruptedStoreTest.testNodeInvalidatedWhenPersistenceIsCorrupted 
> (master fail rate 6,8%)  
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7830903222674504151=pull%2F3624%2Fhead=testDetails_IgniteTests24Java8=%3Cdefault%3E
> Failure contains suspicious error:
> {noformat}
> [2018-04-01 
> 15:35:51,704][ERROR][exchange-worker-#25589%persistence.IgnitePdsCorruptedStoreTest0%][IgniteTestResources]
>  Critical failure. Will be handled accordingly to configured handler 
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
> [type=CRITICAL_ERROR, err=java.lang.IllegalStateException: Page is broken. 
> Can't restore it from WAL. (grpId = -1368047377, pageId = 100020008).]] 
> {noformat}



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

[jira] [Commented] (IGNITE-8021) Destroyed caches can be return to life by restart grid

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-8021:
--

Guys,

I think we should currently fix the following case: if all nodes (no offline 
nodes) see the cache destroy, we should not see the cache resurrection after 
cluster restart. All other cases when a node was offline during cache destroy, 
will be covered when we migrate metadata to metadata storage (same way as 
baseline topology).

> Destroyed caches can be return to life by restart grid
> --
>
> Key: IGNITE-8021
> URL: https://issues.apache.org/jira/browse/IGNITE-8021
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Attachments: 8021-patch-for-patch, DstroedCacheReturnTest.java
>
>
> Cache configuration files stay stored on file system after invoke {{destroy}} 
> method.
> By the reason after restart grid all removed caches are start.
>  
> Look at the test [^DstroedCacheReturnTest.java]



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

[jira] [Assigned] (IGNITE-8128) PDS Indexing suite timeout: failure handler incomatibility with test code

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov reassigned IGNITE-8128:
--

Assignee: Pavel Kovalenko  (was: Dmitriy Pavlov)

> PDS Indexing suite timeout: failure handler incomatibility with test code 
> --
>
> Key: IGNITE-8128
> URL: https://issues.apache.org/jira/browse/IGNITE-8128
> Project: Ignite
>  Issue Type: Test
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Pavel Kovalenko
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Ignite PDS Indexing [ tests 0 TIMEOUT , Exit Code warn 9 ] 
> No fail rate info, probably new failure or suite critical failure  
> IgnitePdsDiskErrorsRecoveringTest.testRecoveringOnWALErrorWithoutMmap (last 
> started) More >> 
>  Thread Dump 
> {noformat}
> [06:06:21]W:  [org.apache.ignite:ignite-indexing] [2018-04-03 
> 03:06:21,536][ERROR][wal-write-worker%file.IgnitePdsDiskErrorsRecoveringTest0][IgniteTestResources]
>  Critical failure. Will be handled accordingly to configured handler 
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
> [type=CRITICAL_ERROR, err=class o.a.i.i.pagemem.wal.StorageException: Unable 
> to write]] 
> [06:06:21]W:  [org.apache.ignite:ignite-indexing] [2018-04-03 
> 03:06:21,539][ERROR][test-runner-#29388%file.IgnitePdsDiskErrorsRecoveringTest%][IgniteTestResources]
>  Critical failure. Will be handled accordingly to configured handler 
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
> [type=CRITICAL_ERROR, err=class o.a.i.i.pagemem.wal.StorageException: Unable 
> to write]] 
> {noformat}
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePdsIndexing=%3Cdefault%3E=buildTypeStatusDiv



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

[jira] [Commented] (IGNITE-8128) PDS Indexing suite timeout: failure handler incomatibility with test code

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8128:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3741


> PDS Indexing suite timeout: failure handler incomatibility with test code 
> --
>
> Key: IGNITE-8128
> URL: https://issues.apache.org/jira/browse/IGNITE-8128
> Project: Ignite
>  Issue Type: Test
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Ignite PDS Indexing [ tests 0 TIMEOUT , Exit Code warn 9 ] 
> No fail rate info, probably new failure or suite critical failure  
> IgnitePdsDiskErrorsRecoveringTest.testRecoveringOnWALErrorWithoutMmap (last 
> started) More >> 
>  Thread Dump 
> {noformat}
> [06:06:21]W:  [org.apache.ignite:ignite-indexing] [2018-04-03 
> 03:06:21,536][ERROR][wal-write-worker%file.IgnitePdsDiskErrorsRecoveringTest0][IgniteTestResources]
>  Critical failure. Will be handled accordingly to configured handler 
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
> [type=CRITICAL_ERROR, err=class o.a.i.i.pagemem.wal.StorageException: Unable 
> to write]] 
> [06:06:21]W:  [org.apache.ignite:ignite-indexing] [2018-04-03 
> 03:06:21,539][ERROR][test-runner-#29388%file.IgnitePdsDiskErrorsRecoveringTest%][IgniteTestResources]
>  Critical failure. Will be handled accordingly to configured handler 
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
> [type=CRITICAL_ERROR, err=class o.a.i.i.pagemem.wal.StorageException: Unable 
> to write]] 
> {noformat}
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePdsIndexing=%3Cdefault%3E=buildTypeStatusDiv



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

[jira] [Assigned] (IGNITE-8128) PDS Indexing suite timeout: failure handler incomatibility with test code

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko reassigned IGNITE-8128:
---

 Assignee: Dmitriy Pavlov  (was: Pavel Kovalenko)
Fix Version/s: 2.5

Fix is ready. Indexing suite is passing now.
PR: https://github.com/apache/ignite/pull/3741
TC: 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3741%2Fhead

> PDS Indexing suite timeout: failure handler incomatibility with test code 
> --
>
> Key: IGNITE-8128
> URL: https://issues.apache.org/jira/browse/IGNITE-8128
> Project: Ignite
>  Issue Type: Test
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Ignite PDS Indexing [ tests 0 TIMEOUT , Exit Code warn 9 ] 
> No fail rate info, probably new failure or suite critical failure  
> IgnitePdsDiskErrorsRecoveringTest.testRecoveringOnWALErrorWithoutMmap (last 
> started) More >> 
>  Thread Dump 
> {noformat}
> [06:06:21]W:  [org.apache.ignite:ignite-indexing] [2018-04-03 
> 03:06:21,536][ERROR][wal-write-worker%file.IgnitePdsDiskErrorsRecoveringTest0][IgniteTestResources]
>  Critical failure. Will be handled accordingly to configured handler 
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
> [type=CRITICAL_ERROR, err=class o.a.i.i.pagemem.wal.StorageException: Unable 
> to write]] 
> [06:06:21]W:  [org.apache.ignite:ignite-indexing] [2018-04-03 
> 03:06:21,539][ERROR][test-runner-#29388%file.IgnitePdsDiskErrorsRecoveringTest%][IgniteTestResources]
>  Critical failure. Will be handled accordingly to configured handler 
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
> [type=CRITICAL_ERROR, err=class o.a.i.i.pagemem.wal.StorageException: Unable 
> to write]] 
> {noformat}
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePdsIndexing=%3Cdefault%3E=buildTypeStatusDiv



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

[jira] [Commented] (IGNITE-4193) SQL TX: ODBC driver support

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4193:


Github user isapego closed the pull request at:

https://github.com/apache/ignite/pull/3708


> SQL TX: ODBC driver support
> ---
>
> Key: IGNITE-4193
> URL: https://issues.apache.org/jira/browse/IGNITE-4193
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Denis Magda
>Assignee: Igor Sapego
>Priority: Major
>  Labels: iep-3
> Fix For: 2.5
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from ODBC driver side.



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

[jira] [Resolved] (IGNITE-4193) SQL TX: ODBC driver support

[Igor Sapego (JIRA)]

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

Igor Sapego resolved IGNITE-4193.
-
Resolution: Fixed

Merged to parent ticket.

> SQL TX: ODBC driver support
> ---
>
> Key: IGNITE-4193
> URL: https://issues.apache.org/jira/browse/IGNITE-4193
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Denis Magda
>Assignee: Igor Sapego
>Priority: Major
>  Labels: iep-3
> Fix For: 2.5
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from ODBC driver side.



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

[jira] [Comment Edited] (IGNITE-4193) SQL TX: ODBC driver support

[Igor Sapego (JIRA)]

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

Igor Sapego edited comment on IGNITE-4193 at 4/3/18 3:02 PM:
-

Merged to parent ticket branch.


was (Author: isapego):
Merged to parent ticket.

> SQL TX: ODBC driver support
> ---
>
> Key: IGNITE-4193
> URL: https://issues.apache.org/jira/browse/IGNITE-4193
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Denis Magda
>Assignee: Igor Sapego
>Priority: Major
>  Labels: iep-3
> Fix For: 2.5
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from ODBC driver side.



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

[jira] [Comment Edited] (IGNITE-5994) IgniteInternalCache.invokeAsync().get() can return null

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov edited comment on IGNITE-5994 at 4/3/18 2:57 PM:
-

Resume progress because [~shia] didn't make upsouce review and all other things.


was (Author: sharpler):
Resume progress because [~shia] didn't make PR.

> IgniteInternalCache.invokeAsync().get() can return null
> ---
>
> Key: IGNITE-5994
> URL: https://issues.apache.org/jira/browse/IGNITE-5994
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexander Menshikov
>Priority: Minor
>  Labels: newbie
> Attachments: IgniteCacheSelfTest.java, 
> master_8629b50d6f_ignite-5994.patch
>
>
> The IgniteInternalCache.invoke() always return an EntryProcessorResult, but 
> the IgniteInternalCache.invokeAsync().get() can return the null in case when 
> an EntryProcessor has returned the null.
> Code from reproducer:
> {noformat}
> final EntryProcessor ep = new EntryProcessor Object, Object>() {
> @Override
> public Object process(MutableEntry entry,
> Object... objects) throws EntryProcessorException {
> return null;
> }
> };
> EntryProcessorResult result = utilCache.invoke("test", ep);
> assertNotNull(result);
> assertNull(result.get());
> result = utilCache.invokeAsync("test", ep).get();
> // Assert here!!!
> assertNotNull(result);
> assertNull(result.get());
> {noformat}
> It can be optimization. Nevertheless results of invoke() must be equals with 
> results of invokeAsync().get(). So there are two options:
> 1) To do so would be the invokeAsync(key, ep).get() returned the null too for 
> the optimization.
> 2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult 
> for a logical consistency.
> NOTE: Don't confuse with IgniteCache.invoke.



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

[jira] [Assigned] (IGNITE-8113) ZookeeperClientTest#testReconnect3, testReconnect4 fail on TC

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko reassigned IGNITE-8113:
---

Assignee: Pavel Kovalenko

> ZookeeperClientTest#testReconnect3, testReconnect4 fail on TC
> -
>
> Key: IGNITE-8113
> URL: https://issues.apache.org/jira/browse/IGNITE-8113
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Pavel Kovalenko
>Priority: Major
>
> Tests always fail on TC, testReconnect3 failure is reproducible locally as 
> well.
> A message in logs says that ZooKeeper cluster shuts itself down during the 
> test:
> {noformat}
> [Step 4/5] java.lang.Exception: shutdown Leader! reason: Not sufficient 
> followers synced, only synced with sids: [ 11 ]
> {noformat}
> Most likely there is a bug in test itself, no real functionality is affected.



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

[jira] [Assigned] (IGNITE-6007) GridCacheBinaryObjectMetadataExchangeMultinodeTest.testSequentialUpdatesNoConflicts fails sometimes

[Amelchev Nikita (JIRA)]

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

Amelchev Nikita reassigned IGNITE-6007:
---

Assignee: Amelchev Nikita

> GridCacheBinaryObjectMetadataExchangeMultinodeTest.testSequentialUpdatesNoConflicts
>  fails sometimes
> ---
>
> Key: IGNITE-6007
> URL: https://issues.apache.org/jira/browse/IGNITE-6007
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Amelchev Nikita
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> {noformat}
> java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.binary.GridCacheBinaryObjectMetadataExchangeMultinodeTest.testSequentialUpdatesNoConflicts(GridCacheBinaryObjectMetadataExchangeMultinodeTest.java:289)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Assigned] (IGNITE-8111) Add extra validation for WAL segment size

[JIRA]

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

Денис Гарус reassigned IGNITE-8111:
---

Assignee: Денис Гарус

> Add extra validation for WAL segment size
> -
>
> Key: IGNITE-8111
> URL: https://issues.apache.org/jira/browse/IGNITE-8111
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Ivan Rakov
>Assignee: Денис Гарус
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Currently we can set extra small DataStorageConfiguration#walSegmentSize (10 
> pages or even less than one page), which will trigger multiple assertion 
> errors in code.
> We have to implement validation on node start that WAL segment size has 
> reasonable value (512KB or more).



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

[jira] [Commented] (IGNITE-8114) Add fail recovery mechanism to tracking pages

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev commented on IGNITE-8114:
---

[~dpavlov] 
I don't think so. 

Here I don't see any exception: BPlusTreePageMemoryImplTest. I guess, for some 
reason the test took too much time. 
IgniteCacheEntryProcessorNodeJoinTest.testEntryProcessorNodeLeave - we had seen 
node from other cluster. 
IgniteCacheServerNodeConcurrentStart.testConcurrentStart - PME hanged, no any 
issue with my changes.

> Add fail recovery mechanism to tracking pages
> -
>
> Key: IGNITE-8114
> URL: https://issues.apache.org/jira/browse/IGNITE-8114
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>
> Now we just assert that last saved tag in tracking page should be not greater 
> than passed one.
> But because of different issues which we don't understand yet, it could 
> happen.
> So, I suggest to handle it by adding new "corruption" state to tracking 
> state. 
> If tracking page is in a corrupted state than we would throw an exception on 
> any querying of the tracking page. Caller will have opportunity to catch the 
> exception and recover page state.



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

[jira] [Commented] (IGNITE-8128) PDS Indexing suite timeout: failure handler incomatibility with test code

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8128:


GitHub user Jokser opened a pull request:

https://github.com/apache/ignite/pull/3741

IGNITE-8128 Use StopNodeFailureHandler in tests where required.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8128

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3741.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3741


commit 549ccdfe97c0d0a2e48ca3bb98ed7fcbbaae67b1
Author: Pavel Kovalenko 
Date:   2018-04-03T13:40:42Z

IGNITE-8128 Use StopNodeFailureHandler in tests where required.




> PDS Indexing suite timeout: failure handler incomatibility with test code 
> --
>
> Key: IGNITE-8128
> URL: https://issues.apache.org/jira/browse/IGNITE-8128
> Project: Ignite
>  Issue Type: Test
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Pavel Kovalenko
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> Ignite PDS Indexing [ tests 0 TIMEOUT , Exit Code warn 9 ] 
> No fail rate info, probably new failure or suite critical failure  
> IgnitePdsDiskErrorsRecoveringTest.testRecoveringOnWALErrorWithoutMmap (last 
> started) More >> 
>  Thread Dump 
> {noformat}
> [06:06:21]W:  [org.apache.ignite:ignite-indexing] [2018-04-03 
> 03:06:21,536][ERROR][wal-write-worker%file.IgnitePdsDiskErrorsRecoveringTest0][IgniteTestResources]
>  Critical failure. Will be handled accordingly to configured handler 
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
> [type=CRITICAL_ERROR, err=class o.a.i.i.pagemem.wal.StorageException: Unable 
> to write]] 
> [06:06:21]W:  [org.apache.ignite:ignite-indexing] [2018-04-03 
> 03:06:21,539][ERROR][test-runner-#29388%file.IgnitePdsDiskErrorsRecoveringTest%][IgniteTestResources]
>  Critical failure. Will be handled accordingly to configured handler 
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
> [type=CRITICAL_ERROR, err=class o.a.i.i.pagemem.wal.StorageException: Unable 
> to write]] 
> {noformat}
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePdsIndexing=%3Cdefault%3E=buildTypeStatusDiv



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

[jira] [Commented] (IGNITE-8114) Add fail recovery mechanism to tracking pages

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8114:


Suspicious tests

   Cache [2] 
Test failures count is low < 3, probably new test introduced   
IgniteCacheTestSuite2: 
IgniteCacheEntryProcessorNodeJoinTest.testEntryProcessorNodeLeave (master fail 
rate 0,0%) 
Test failures count is low < 3, probably new test introduced   
IgniteCacheTestSuite2: IgniteCacheServerNodeConcurrentStart.testConcurrentStart 
(master fail rate 0,0%) 

 Ignite PDS [1]  
   Test failures count is low < 3, probably new test introduced   
IgnitePdsTestSuite: 
BPlusTreePageMemoryImplTest.testSizeForRandomPutRmvMultithreadedAsync_3 (master 
fail rate 0,0%) 

Please check if it is related to this change

> Add fail recovery mechanism to tracking pages
> -
>
> Key: IGNITE-8114
> URL: https://issues.apache.org/jira/browse/IGNITE-8114
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>
> Now we just assert that last saved tag in tracking page should be not greater 
> than passed one.
> But because of different issues which we don't understand yet, it could 
> happen.
> So, I suggest to handle it by adding new "corruption" state to tracking 
> state. 
> If tracking page is in a corrupted state than we would throw an exception on 
> any querying of the tracking page. Caller will have opportunity to catch the 
> exception and recover page state.



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

[jira] [Created] (IGNITE-8128) PDS Indexing suite timeout: failure handler incomatibility with test code

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-8128:
--

 Summary: PDS Indexing suite timeout: failure handler 
incomatibility with test code 
 Key: IGNITE-8128
 URL: https://issues.apache.org/jira/browse/IGNITE-8128
 Project: Ignite
  Issue Type: Test
  Components: persistence
Reporter: Dmitriy Pavlov
Assignee: Pavel Kovalenko


Ignite PDS Indexing [ tests 0 TIMEOUT , Exit Code warn 9 ] 
No fail rate info, probably new failure or suite critical failure  
IgnitePdsDiskErrorsRecoveringTest.testRecoveringOnWALErrorWithoutMmap (last 
started) More >> 
 Thread Dump 
{noformat}
[06:06:21]W:[org.apache.ignite:ignite-indexing] [2018-04-03 
03:06:21,536][ERROR][wal-write-worker%file.IgnitePdsDiskErrorsRecoveringTest0][IgniteTestResources]
 Critical failure. Will be handled accordingly to configured handler [hnd=class 
o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
[type=CRITICAL_ERROR, err=class o.a.i.i.pagemem.wal.StorageException: Unable to 
write]] 
[06:06:21]W:[org.apache.ignite:ignite-indexing] [2018-04-03 
03:06:21,539][ERROR][test-runner-#29388%file.IgnitePdsDiskErrorsRecoveringTest%][IgniteTestResources]
 Critical failure. Will be handled accordingly to configured handler [hnd=class 
o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
[type=CRITICAL_ERROR, err=class o.a.i.i.pagemem.wal.StorageException: Unable to 
write]] 
{noformat}

https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePdsIndexing=%3Cdefault%3E=buildTypeStatusDiv




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

[jira] [Commented] (IGNITE-8114) Add fail recovery mechanism to tracking pages

[Ivan Rakov (JIRA)]

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

Ivan Rakov commented on IGNITE-8114:


I've looked through your changes. Please proceed with merge.

> Add fail recovery mechanism to tracking pages
> -
>
> Key: IGNITE-8114
> URL: https://issues.apache.org/jira/browse/IGNITE-8114
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>
> Now we just assert that last saved tag in tracking page should be not greater 
> than passed one.
> But because of different issues which we don't understand yet, it could 
> happen.
> So, I suggest to handle it by adding new "corruption" state to tracking 
> state. 
> If tracking page is in a corrupted state than we would throw an exception on 
> any querying of the tracking page. Caller will have opportunity to catch the 
> exception and recover page state.



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

[jira] [Updated] (IGNITE-8127) .NET: Fix flaky test ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress

[Alexey Popov (JIRA)]

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

Alexey Popov updated IGNITE-8127:
-
Labels: MakeTeamcityGreenAgain  (was: )

> .NET: Fix flaky test 
> ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress
> ---
>
> Key: IGNITE-8127
> URL: https://issues.apache.org/jira/browse/IGNITE-8127
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.5
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
>  Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1173105=buildResultsDiv=IgniteTests24Java8_IgnitePlatformNetLongRunning
> Test(s) failed.   Some tasks should have failed.
>   Expected: True
>   But was:  False
>at NUnit.Framework.Assert.That(Object actual, IResolveConstraint 
> expression, String message, Object[] args)
>at 
> Apache.Ignite.Core.Tests.Client.ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress()
>  in 
> c:\BuildAgent\work\bd85361428dcdb1\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Client\ClientConnectionTest.cs:line
>  277



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

[jira] [Created] (IGNITE-8127) .NET: Fix flaky test ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress

[Alexey Popov (JIRA)]

Alexey Popov created IGNITE-8127:


 Summary: .NET: Fix flaky test 
ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress
 Key: IGNITE-8127
 URL: https://issues.apache.org/jira/browse/IGNITE-8127
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.5
Reporter: Alexey Popov
Assignee: Alexey Popov


https://ci.ignite.apache.org/viewLog.html?buildId=1173105=buildResultsDiv=IgniteTests24Java8_IgnitePlatformNetLongRunning

Test(s) failed.   Some tasks should have failed.
  Expected: True
  But was:  False

   at NUnit.Framework.Assert.That(Object actual, IResolveConstraint expression, 
String message, Object[] args)
   at 
Apache.Ignite.Core.Tests.Client.ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress()
 in 
c:\BuildAgent\work\bd85361428dcdb1\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Client\ClientConnectionTest.cs:line
 277




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

[jira] [Assigned] (IGNITE-7306) Incorrect force key request processing when MVCC is enabled

[Roman Kondakov (JIRA)]

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

Roman Kondakov reassigned IGNITE-7306:
--

Assignee: Roman Kondakov  (was: Igor Seliverstov)

> Incorrect force key request processing when MVCC is enabled
> ---
>
> Key: IGNITE-7306
> URL: https://issues.apache.org/jira/browse/IGNITE-7306
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.5
>
>
> Reproducer: {{IgniteCacheMultiTxLockSelfTest#testExplicitLockManyKeys}}
> Root cause: when {{GridDhtForceKeysRequest}} is processed locally, we obtain 
> {{GridCacheEntryInfo}} through {{GridCacheMapEntry.info}}. Returned instance 
> is unaware of MVCC version. Need to return {{GridCacheMvccEntryInfo}} instead.
> {code}
> java.lang.AssertionError
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccInitialValue(IgniteCacheOffheapManagerImpl.java:1433)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccInitialValue(IgniteCacheOffheapManagerImpl.java:396)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2624)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture$MiniFuture.onResult(GridDhtForceKeysFuture.java:537)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onResult(GridDhtForceKeysFuture.java:199)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processForceKeyResponse(GridDhtCacheAdapter.java:176)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$11.onMessage(GridDhtTransactionalCacheAdapter.java:193)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$11.onMessage(GridDhtTransactionalCacheAdapter.java:191)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$MessageHandler.apply(GridDhtCacheAdapter.java:1406)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$MessageHandler.apply(GridDhtCacheAdapter.java:1388)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1567)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1195)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:128)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1092)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
>   at java.lang.Thread.run(Thread.java:748)
> {code}



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

[jira] [Commented] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-7692:
--

If this is not an issue, we should remove SQL from the affinity run because in 
current API it does not guarantee anything.

[~vozerov] Can you confirm?

> affinityCall and affinityRun may execute code on backup partitions
> --
>
> Key: IGNITE-7692
> URL: https://issues.apache.org/jira/browse/IGNITE-7692
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test, usability
> Fix For: 2.5
>
>
> Apparently, the affinityCall and affinityRun methods reserve partitions and 
> check their state to be OWNING, however, if topology changes and partition 
> role is changed to backup from primary, the code is still executed.
> This can be an issue if a user executes a local SQL query inside the 
> affinityCall runnable. In this case, the query result may return null.
> This can be observed in the 
> IgniteCacheLockPartitionOnAffinityRunTest#getPersonsCountSingleCache - note 
> an additional check I've added to make the test pass.
> I think it is ok to have an old semantics for the API, because in some cases 
> (scan query, local gets) a backup OWNER is enough. However, it looks like we 
> need to add another API method to enforce that affinity run be executed on 
> primary nodes and forbid primary role change.
> Another option is to detect a topology version of the affinity run and use 
> that version for local SQL queries.



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

[jira] [Commented] (IGNITE-8119) NPE on clear DB and unclear WAL/WAL_ARCHIVE

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8119:


Why do you expect Ignite should operate on broken PDS storage?

> NPE on clear DB and unclear WAL/WAL_ARCHIVE
> ---
>
> Key: IGNITE-8119
> URL: https://issues.apache.org/jira/browse/IGNITE-8119
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Priority: Major
> Attachments: ClearTest.java, ClearTestP.java
>
>
> 1) Start grid (1 node will be enought), activate it and populate some data
> 2) Stop node and clear db folder
> 3) Start grid and activate it
> Expected result:
> Error about inconsistent storage configuration with/without start node with 
> such store
> Actual result:
> Exchange-worker on node stop with NPE, this can hang whole cluster from 
> complete any PME operations.
> {noformat}
> Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1, 
> minorTopVer=1], ...
> java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyUpdate(GridCacheDatabaseSharedManager.java:2354)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2099)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1325)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1113)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1063)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:661)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2329)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Commented] (IGNITE-8072) SQL query with multiple JOIN and subquery with UNION produces "Column not found" exception

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-8072:
--

On version 1.9 if you query on replicated cache it is equal to 
{{SqlFieldsQuery#setLocal(true)}}
It might produce wrong results in some cases.
But if 1.9 behavior is needed {{SqlFieldsQuery#setLocal(true)}} - is proper 
workaround.

> SQL query with multiple JOIN and subquery with UNION produces "Column not 
> found" exception
> --
>
> Key: IGNITE-8072
> URL: https://issues.apache.org/jira/browse/IGNITE-8072
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1, 2.3, 2.4
>Reporter: Pavel Vinokurov
>Priority: Major
>
> Initial script:
> CREATE TABLE Person(id INTEGER PRIMARY KEY, company_id INTEGER);
> CREATE TABLE Company(id INTEGER PRIMARY KEY, name VARCHAR);
> CREATE TABLE Department(id INTEGER PRIMARY KEY, company_id INTEGER);
> Query:
> select * from 
> (
> select 
>p.id as id,
>p.company_id as company_id 
>from person p 
>union  
> select
>p.id as id,
>p.company_id as company_id 
>from person p 
> ) p
> left join company c on p.company_id=c.id
> left join department d on p.company_id=d.id
> Result:
> SEVERE: Failed to run map query on local node.
> class org.apache.ignite.IgniteCheckedException: Failed to parse SQL query: 
> SELECT
> C__Z3.NAME __C2_0,
> D__Z4.ID __C2_1,
> D__Z4.COMPANY_ID __C2_2,
> C__Z3.ID __C2_3
> FROM PUBLIC.COMPANY C__Z3 
>  LEFT OUTER JOIN PUBLIC.DEPARTMENT D__Z4 
>  ON P__Z2.COMPANY_ID = D__Z4.ID
> ORDER BY 4



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

[jira] [Assigned] (IGNITE-7628) SqlQuery hangs indefinitely with additional not registered in baseline node.

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev reassigned IGNITE-7628:
-

Assignee: Eduard Shangareev

> SqlQuery hangs indefinitely with additional not registered in baseline node.
> 
>
> Key: IGNITE-7628
> URL: https://issues.apache.org/jira/browse/IGNITE-7628
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Stanilovsky Evgeny
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
> Attachments: 
> IgniteChangingBaselineCacheQueryAdditionalNodeSelfTest.java
>
>
> SqlQuery hangs indefinitely while additional node registered in topology but 
> still not in baseline.
> Reproducer attached. Apparently problem in 
> GridH2IndexRangeResponse#awaitForResponse func.



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

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-6846:


[~Alexey Kuznetsov] I still would like to wait Val response.

I don't know any expert, which is not loaded with reviews currently.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



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

[jira] [Commented] (IGNITE-7993) Striped pool can't be disabled

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7993:


[~yzhdanov], could you please review this change? 

I am afraid I can't estimate impact of this change.

> Striped pool can't be disabled
> --
>
> Key: IGNITE-7993
> URL: https://issues.apache.org/jira/browse/IGNITE-7993
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Valentin Kulichenko
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.5
>
>
> Javadoc for {{IgniteConfiguration#setStripedPoolSize}} states that striped 
> pool can be disabled by providing value less or equal than zero:
> {noformat}
> If set to non-positive value then requests get processed in system pool.
> {noformat}
> However, doing that prevents node from startup, it fails with the following 
> exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: Invalid 
> stripedPool thread pool size (must be greater than 0), actual value: 0
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.validateThreadPoolSize(IgnitionEx.java:2061)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
>   at org.apache.ignite.Ignition.start(Ignition.java:322)
>   ... 7 more
> {noformat}



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

[jira] [Commented] (IGNITE-7957) TestDistributedJoins fails in CPP Win32 suite

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-7957:
-

Can not reproduce locally.

> TestDistributedJoins fails in CPP Win32 suite
> -
>
> Key: IGNITE-7957
> URL: https://issues.apache.org/jira/browse/IGNITE-7957
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Dmitriy Pavlov
>Assignee: Igor Sapego
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=417754190398412=%3Cdefault%3E=testDetails
>Ignite Platform CPP Win32 [ tests 1 TC_EXIT_CODE ]  
>   IgniteOdbcTest: QueriesTestSuite: TestDistributedJoins (fail rate 9,8%) 
> {noformat}
> check env != 0 passed
> check dbc != 0 passed
> check stmt != 0 passed
> check rowsNum > 0 passed
> check rowsNum < entriesNum passed
> check env != 0 passed
> check dbc != 0 passed
> check stmt != 0 passed
> check rowsNum == entriesNum failed [2565 != 1000]
> {noformat}



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

[jira] [Commented] (IGNITE-4193) SQL TX: ODBC driver support

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-4193:
-

Thanks. Fixed.

> SQL TX: ODBC driver support
> ---
>
> Key: IGNITE-4193
> URL: https://issues.apache.org/jira/browse/IGNITE-4193
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Denis Magda
>Assignee: Igor Sapego
>Priority: Major
>  Labels: iep-3
> Fix For: 2.5
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from ODBC driver side.



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

[jira] [Commented] (IGNITE-7963) Futures from DataStreamer.addData() fail to complete if DataStreamer.flush() is never called

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-7963:
-

[~dpavlov] tests are passing much better now at 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3651%2Fhead
https://ci.ignite.apache.org/viewLog.html?buildId=1167555=buildResultsDiv=IgniteTests24Java8_RunAll
There was one suspicious test  
CacheTtlTransactionalPartitionedSelfTest.testDefaultTimeToLivePreload but it 
seems to pass locally

> Futures from DataStreamer.addData() fail to complete if DataStreamer.flush() 
> is never called
> 
>
> Key: IGNITE-7963
> URL: https://issues.apache.org/jira/browse/IGNITE-7963
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>  Labels: usability
>
> DataStreamer.addData() will return futures for operation.
> Thus the naive use of DataStreamer will look like this:
> {code}
> for (Data d : data)
>  futs.add(dataStreamer.addData(d));
> for (IgniteFuture f : futs)
> f.get();
> dataStreamer.close();
> {code}
> However, this does not work. Unless flush is called (manual or otherwisE), 
> futures are not being processed. This code will likely hang on f.get().
> The solution, IMHO, is to introduce dataStreamer-flushing clause in f.get().



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

[jira] [Commented] (IGNITE-8106) In control.sh -active, exception will be eaten and not displayed

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-8106:
-

[~dpavlov] please review proposed change!

> In control.sh -active, exception will be eaten and not displayed
> 
>
> Key: IGNITE-8106
> URL: https://issues.apache.org/jira/browse/IGNITE-8106
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>
> Here is the relevant code from GridChangeStateCommandHandler:
> {code}
> sb.a(e.getMessage()).a("\n").a("suppressed: \n");
> for (Throwable t:e.getSuppressed())
> sb.a(t.getMessage()).a("\n");
> {code}
> However, before that code the exception will pass through 
> IgniteUtils.convertException(), which will wrap the old 
> IgniteCheckedException with suppressed parts with a new IgniteException with 
> 0 suppressed.



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

[jira] [Commented] (IGNITE-8106) In control.sh -active, exception will be eaten and not displayed

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-8106:
-

There was one suspicious failure in Hadoop command, but after rerun it went away

> In control.sh -active, exception will be eaten and not displayed
> 
>
> Key: IGNITE-8106
> URL: https://issues.apache.org/jira/browse/IGNITE-8106
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>
> Here is the relevant code from GridChangeStateCommandHandler:
> {code}
> sb.a(e.getMessage()).a("\n").a("suppressed: \n");
> for (Throwable t:e.getSuppressed())
> sb.a(t.getMessage()).a("\n");
> {code}
> However, before that code the exception will pass through 
> IgniteUtils.convertException(), which will wrap the old 
> IgniteCheckedException with suppressed parts with a new IgniteException with 
> 0 suppressed.



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

[jira] [Commented] (IGNITE-8050) Throw a meaningful exception when user issues TX SQL keyword with MVCC turned off

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov commented on IGNITE-8050:
--

[~al.psc], looks OK to me.

> Throw a meaningful exception when user issues TX SQL keyword with MVCC turned 
> off
> -
>
> Key: IGNITE-8050
> URL: https://issues.apache.org/jira/browse/IGNITE-8050
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
>
> An exception must be thrown when the user issues TX SQL command (BEGIN, 
> COMMIT, ROLLBACK) in absence of MVCC - ingoring these may be confusing and 
> can lead to SQL engine behavior to behaving quite differently from what the 
> user expects, esp. in terms of data consistency.



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

[jira] [Commented] (IGNITE-1776) [Test Failed] TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer fails sometimes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1776:


GitHub user NSAmelchev opened a pull request:

https://github.com/apache/ignite/pull/3739

IGNITE-1776



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/NSAmelchev/ignite ignite-1776

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3739.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3739


commit 11424e9eeefc8fe1b8575623c18a8d565a376ab9
Author: NSAmelchev 
Date:   2017-11-28T14:25:13Z

Merge remote-tracking branch 'refs/remotes/apache/master'

commit 0b16700731bda414b8d7921f2c098c5ad1b6540b
Author: NSAmelchev 
Date:   2018-01-19T09:46:31Z

Merge remote-tracking branch 'refs/remotes/apache/master'

commit 0de054fe0a1ae41db58a67d3387d08deaf6d22e2
Author: NSAmelchev 
Date:   2018-02-27T11:00:41Z

Merge remote-tracking branch 'apache/master'

commit 29cb0f44d25621d1e41e00d504c3e7bf44c1d735
Author: NSAmelchev 
Date:   2018-03-15T10:58:37Z

Merge pull request #20 from apache/master

merge

commit 9b0f16930a5e1da4ef3a528b7879cd1fca5307f7
Author: NSAmelchev 
Date:   2018-03-20T08:17:26Z

Merge pull request #21 from apache/master

Merge

commit 28619f3040851925c7e176ea04749dcd47ad8cd7
Author: NSAmelchev 
Date:   2018-04-02T12:38:26Z

del fail




> [Test Failed] TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer fails 
> sometimes
> ---
>
> Key: IGNITE-1776
> URL: https://issues.apache.org/jira/browse/IGNITE-1776
> Project: Ignite
>  Issue Type: Test
>Reporter: Artem Shutak
>Assignee: Amelchev Nikita
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
>
> TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer fails on TC 
> sometimes.
> Looks like a test bug, need just increase awaitTime(). I see Node FAILED 
> message exactly after 10 seconds. But it's strange that it's require too long 
> time. May be something wrong on agent.
> Logs:
> {noformat}
> junit.framework.AssertionFailedError: Latch count: 1
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.await(TcpClientDiscoverySpiSelfTest.java:2030)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer(TcpClientDiscoverySpiSelfTest.java:811)
> --- Stdout: ---
> [03:18:46,228][INFO ][main][root] >>> Starting test: 
> testClientNodeFailOneServer <<<
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] 
> >>>__    
> >>>   /  _/ ___/ |/ /  _/_  __/ __/  
> >>>  _/ // (7 7// /  / / / _/
> >>> /___/\___/_/|_/___/ /_/ /___/   
> >>> 
> >>> ver. 1.5.0-SNAPSHOT#19700101-sha1:DEV
> >>> 2015 Copyright(C) Apache Software Foundation
> >>> 
> >>> Ignite documentation: http://ignite.apache.org
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Config URL: n/a
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Daemon mode: off
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] OS: Mac OS X 10.7.5 
> x86_64
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] OS user: teamcity
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Language runtime: 
> Java Platform API Specification ver. 1.7
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] VM information: 
> Java(TM) SE Runtime Environment 1.7.0_67-b01 Oracle Corporation Java 
> HotSpot(TM) 64-Bit Server VM 24.65-b04
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] VM total memory: 
> 2.7GB
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Remote Management 
> [restart: off, REST: off, JMX (remote: off)]
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] 
> IGNITE_HOME=/Users/teamcity/buildAgent/work/871ff4a46e450b13
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] VM arguments: 
> [-DJAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home, 
> -DMCAST_GRP=229.116.1.2, -Dagent.home.dir=/Users/teamcity/buildAgent, 
> -Dagent.name=ip_192.168.1.116, -Dagent.ownPort=9090, 
> -Dagent.work.dir=/Users/teamcity/buildAgent/work, -Dbuild.number=3345, 
> -Dbuild.vcs.number=91e31e99c2574f7cede8d80ec9b8d981ccc34bcb, 
> 

[jira] [Commented] (IGNITE-6856) SQL: invalid security checks during query execution

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6856:
-

Apparently, the problem is deeper than I thought in the first place. 
1) SQL permissions have never worked correctly. If query is executed through 
cache API, then we only check permissions against this cache. It means, that if 
one has read permission to one cache, it could be used as a "window" for all 
other caches.
2) Our new DML and DDL commands are not integrated into security circuit anyhow 
at the moment. They require different checks and permissions comparing to 
{{SELECT}} statements. Also note that with DDL we need to have completely new 
permissions for {{CREATE/DROP INDEX}}.

> SQL: invalid security checks during query execution
> ---
>
> Key: IGNITE-6856
> URL: https://issues.apache.org/jira/browse/IGNITE-6856
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>
> Currently security check is performed inside {{IgniteCacheProxy}}. This is 
> wrong place. Instead, we should perform it inside query processor after 
> parsing when all affected caches are known.



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

[jira] [Commented] (IGNITE-4193) SQL TX: ODBC driver support

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-4193:
-

[~isapego] the only minor thing to fix is class javadoc for 
{{OdbcRequestHandlerWorker}} - it mentions JDBC, this clearly needs fixing.

> SQL TX: ODBC driver support
> ---
>
> Key: IGNITE-4193
> URL: https://issues.apache.org/jira/browse/IGNITE-4193
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Denis Magda
>Assignee: Igor Sapego
>Priority: Major
>  Labels: iep-3
> Fix For: 2.5
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from ODBC driver side.



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

[jira] [Closed] (IGNITE-8123) Web console: incorrect text after all clusters have been deleted

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-8123.
--

> Web console: incorrect text after all clusters have been deleted
> 
>
> Key: IGNITE-8123
> URL: https://issues.apache.org/jira/browse/IGNITE-8123
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Ilya Borisov
>Priority: Minor
>
> # create two clusters
> # delete all clusters
> # see attachment



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

[jira] [Resolved] (IGNITE-8123) Web console: incorrect text after all clusters have been deleted

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov resolved IGNITE-8123.

Resolution: Duplicate

> Web console: incorrect text after all clusters have been deleted
> 
>
> Key: IGNITE-8123
> URL: https://issues.apache.org/jira/browse/IGNITE-8123
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Ilya Borisov
>Priority: Minor
>
> # create two clusters
> # delete all clusters
> # see attachment



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

[jira] [Created] (IGNITE-8126) Web console: the method 'LoadCaches' should not be generated if cache doesn't contain cache store configuration

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8126:
--

 Summary: Web console: the method 'LoadCaches' should not be 
generated if cache doesn't contain cache store configuration
 Key: IGNITE-8126
 URL: https://issues.apache.org/jira/browse/IGNITE-8126
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Vasiliy Sisko


# create cluster, save
# create cache, save
# see project structure



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

[jira] [Comment Edited] (IGNITE-6827) Configurable rollback for long running transactions before partition exchange

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-6827 at 4/3/18 10:30 AM:
--

[~ascherbakov] I've reviewed changes and have some comments.

First of all, it seems strange that {{rollbackOnTopologyChangeTimeout}} 
parameter is part of {{TransactionConfiguration}}. Actually PME uses this value 
and it is PME's responsibility to rollback transactions, so timeout should be 
parameter of exchange.


Some minor comments:

* Some TODO's added but isn't resolved in classes: {{IgniteTxManager}}, 
{{GridCacheAdapter}}, {{GridCAcheMvccManager}}.
* {{IgniteTxAdapter.remainingTime}}: {{timedOut}} flag value checking is 
redundant because the same work will be done in couple lines below.
* {{GridCachePartitionExchangeManager.body0()}}: two calls of 
{{cfg.getTransactionConfiguration().getRollbackOnTopologyChangeTimeout()}} can 
be rewritten in more concise and convenient form:

Before:

{code:java}
boolean rollbackEnabled = 
cfg.getTransactionConfiguration().getRollbackOnTopologyChangeTimeout() > 0;

final long dumpTimeout = 2 * 
cctx.gridConfig().getNetworkTimeout();

long nextDumpTime = 0;

while (true) {
try {
resVer = exchFut.get(rollbackEnabled ? 
cfg.getTransactionConfiguration().
getRollbackOnTopologyChangeTimeout() : 
dumpTimeout, TimeUnit.MILLISECONDS);

break;
}
{code}

After: 

{code:java}
long rollbackTimeout = 
cfg.getTransactionConfiguration().getRollbackOnTopologyChangeTimeout();

final long dumpTimeout = 2 * 
cctx.gridConfig().getNetworkTimeout();

long nextDumpTime = 0;

while (true) {
try {
resVer = exchFut.get(rollbackTimeout > 0 ? 
rollbackTimeout : dumpTimeout, TimeUnit.MILLISECONDS);

break;
}
{code}


was (Author: agura):
[~ascherbakov] I've reviewed changes and have some comments.

First of all, it seems strange that {{rollbackOnTopologyChangeTimeout}} 
parameter is part of {{TransactionConfiguration}}. Actually PME uses this value 
and it is PME's responsibility to rollback transactions, so timeout should be 
parameter of exchange.

{{GridDistributedTxFinishRequest}} contains new field {{timedout}}. I believe 
that we can use bit from {{flags}} field instead of new boolean field. In this 
case message format will n't be changed.

Some minor comments:

* Some TODO's added but isn't resolved in classes: {{IgniteTxManager}}, 
{{GridCacheAdapter}}, {{GridCAcheMvccManager}}.
* {{IgniteTxAdapter.remainingTime}}: {{timedOut}} flag value checking is 
redundant because the same work will be done in couple lines below.
* {{GridCachePartitionExchangeManager.body0()}}: two calls of 
{{cfg.getTransactionConfiguration().getRollbackOnTopologyChangeTimeout()}} can 
be rewritten in more concise and convenient form:

Before:

{code:java}
boolean rollbackEnabled = 
cfg.getTransactionConfiguration().getRollbackOnTopologyChangeTimeout() > 0;

final long dumpTimeout = 2 * 
cctx.gridConfig().getNetworkTimeout();

long nextDumpTime = 0;

while (true) {
try {
resVer = exchFut.get(rollbackEnabled ? 
cfg.getTransactionConfiguration().
getRollbackOnTopologyChangeTimeout() : 
dumpTimeout, TimeUnit.MILLISECONDS);

break;
}
{code}

After: 

{code:java}
long rollbackTimeout = 
cfg.getTransactionConfiguration().getRollbackOnTopologyChangeTimeout();

final long dumpTimeout = 2 * 
cctx.gridConfig().getNetworkTimeout();

long nextDumpTime = 0;

while (true) {
try {
resVer = exchFut.get(rollbackTimeout > 0 ? 
rollbackTimeout : dumpTimeout, TimeUnit.MILLISECONDS);

break;
}
{code}

> Configurable rollback for long running transactions before partition exchange
> -
>
> Key: IGNITE-6827
> URL: https://issues.apache.org/jira/browse/IGNITE-6827
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 

[jira] [Commented] (IGNITE-4193) SQL TX: ODBC driver support

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-4193:
-

[~isapego] please disregard my previous comment, it seems like code duplication 
is intentional pattern in current JDBC/ODBC state of things not to couple those 
together.

> SQL TX: ODBC driver support
> ---
>
> Key: IGNITE-4193
> URL: https://issues.apache.org/jira/browse/IGNITE-4193
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Denis Magda
>Assignee: Igor Sapego
>Priority: Major
>  Labels: iep-3
> Fix For: 2.5
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from ODBC driver side.



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

[jira] [Created] (IGNITE-8125) Returns null on cache querying on column type PGOBJECT (JSONB) superset or @>

[Siddarth sreeni (JIRA)]

Siddarth sreeni created IGNITE-8125:
---

 Summary: Returns null on cache querying on column type PGOBJECT 
(JSONB) superset or @>
 Key: IGNITE-8125
 URL: https://issues.apache.org/jira/browse/IGNITE-8125
 Project: Ignite
  Issue Type: Bug
  Components: cache, jdbc, sql
Affects Versions: 2.4, 2.3, 2.2, 2.1, 2.0
Reporter: Siddarth sreeni


Apache Ignite briefly discusses the uses of SQL Cache query. It talks about the 
different transactional query it can be used to done. Apache Ignite is as said 
supported on PostGreSQL databases. 
For example: In a table of column type JSONB. Querying for a specific object 
superset in a column returns Null.
Query: Select * from Table where column @> 'Object' 



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

[jira] [Commented] (IGNITE-4193) SQL TX: ODBC driver support

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-4193:
-

[~isapego] thanks for the patch, my sole comment would be about 
{{OdbcRequestHandlerWorker}} - it's almost complete copy-paste from 
{{JdbcRequestHandlerWorker}} and JDBC is even still mentioned in comments. Can 
we generify this piece? Probably we'll have to extract some auxiliary interface 
with {{doHandle}} method to achieve this.

> SQL TX: ODBC driver support
> ---
>
> Key: IGNITE-4193
> URL: https://issues.apache.org/jira/browse/IGNITE-4193
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Denis Magda
>Assignee: Igor Sapego
>Priority: Major
>  Labels: iep-3
> Fix For: 2.5
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from ODBC driver side.



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

[jira] [Updated] (IGNITE-6892) OOM should be covered by failure handling

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-6892:

Description: 
{{java.lang.OutOfMemoryError}} should be handled accordingly to provided 
failure handle. 

There are at least 3 types of places where OOM can be catched:

1. Crtitical workers that listed in IEP-14. In this case we just handle 
failures as {{CRITICAL _WORKER_TERMINATED}}.
2. We should consider uncaught or default exception handlers for other treads: 
threads of system, public, etc. thread pools, all threads that are instances of 
{{IgniteThread}}. 

Some memory should be reserved at node start to increase chances of OOM 
handling.

  was:
{{java.lang.OutOfMemoryError}} should be handled accordingly to provided 
failure handle. 

There are at least 3 types of places where OOM can be catched:

1. Crtitical workers that listed in IEP-14. In this case we just handle 
failures as {{CRITICAL _WORKER_TERMINATED}}.
2. Other threads. We should consider uncaught or default exception handlers for 
such treads.
3. {{IgniteUtils.convertException()}} and 
{{IgniteUtils.convertExceptionNoWrap}} methods that should invoke failure 
handler in case of {{OutOfMemoryError}}.

Some memory should be reserved at node start to increase chances of OOM 
handling.


> OOM should be covered by failure handling
> -
>
> Key: IGNITE-6892
> URL: https://issues.apache.org/jira/browse/IGNITE-6892
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> {{java.lang.OutOfMemoryError}} should be handled accordingly to provided 
> failure handle. 
> There are at least 3 types of places where OOM can be catched:
> 1. Crtitical workers that listed in IEP-14. In this case we just handle 
> failures as {{CRITICAL _WORKER_TERMINATED}}.
> 2. We should consider uncaught or default exception handlers for other 
> treads: threads of system, public, etc. thread pools, all threads that are 
> instances of {{IgniteThread}}. 
> Some memory should be reserved at node start to increase chances of OOM 
> handling.



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

[jira] [Updated] (IGNITE-8121) Web console: import cluster from database doesn't work correctly for second import

[Ilya Borisov (JIRA)]

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

Ilya Borisov updated IGNITE-8121:
-
Attachment: import-1.json
import-2.json

> Web console: import cluster from database doesn't work correctly for second 
> import
> --
>
> Key: IGNITE-8121
> URL: https://issues.apache.org/jira/browse/IGNITE-8121
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
> Attachments: import-1.json, import-2.json
>
>
> # initial state - no one cluster exists
> # import from any DB - the first time all imported correctly
> # import the second time - error "Cluster ... already exists"
> # refresh the cluster list - the second cluster apear
> After that the second imported cluster can't be downloaded.



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

[jira] [Assigned] (IGNITE-8121) Web console: import cluster from database doesn't work correctly for second import

[Ilya Borisov (JIRA)]

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

Ilya Borisov reassigned IGNITE-8121:


Assignee: Alexey Kuznetsov  (was: Ilya Borisov)

> Web console: import cluster from database doesn't work correctly for second 
> import
> --
>
> Key: IGNITE-8121
> URL: https://issues.apache.org/jira/browse/IGNITE-8121
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> # initial state - no one cluster exists
> # import from any DB - the first time all imported correctly
> # import the second time - error "Cluster ... already exists"
> # refresh the cluster list - the second cluster apear
> After that the second imported cluster can't be downloaded.



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

[jira] [Updated] (IGNITE-8124) Web console: incorrect text after all clusters have been deleted

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-8124:
---
Attachment: screenshot-1.png

> Web console: incorrect text after all clusters have been deleted
> 
>
> Key: IGNITE-8124
> URL: https://issues.apache.org/jira/browse/IGNITE-8124
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Ilya Borisov
>Priority: Minor
> Fix For: 2.5
>
> Attachments: screenshot-1.png
>
>
> # create two clusters
> # delete all clusters
> # see attachment



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

[jira] [Updated] (IGNITE-8124) Web console: incorrect text after all clusters have been deleted

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-8124:
---
Description: 
# create two clusters
# delete all clusters
# see attachment

 !screenshot-1.png! 

  was:
# create two clusters
# delete all clusters
# see attachment


> Web console: incorrect text after all clusters have been deleted
> 
>
> Key: IGNITE-8124
> URL: https://issues.apache.org/jira/browse/IGNITE-8124
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Ilya Borisov
>Priority: Minor
> Fix For: 2.5
>
> Attachments: screenshot-1.png
>
>
> # create two clusters
> # delete all clusters
> # see attachment
>  !screenshot-1.png! 



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

[jira] [Created] (IGNITE-8124) Web console: incorrect text after all clusters have been deleted

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8124:
--

 Summary: Web console: incorrect text after all clusters have been 
deleted
 Key: IGNITE-8124
 URL: https://issues.apache.org/jira/browse/IGNITE-8124
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Ilya Borisov
 Attachments: screenshot-1.png

# create two clusters
# delete all clusters
# see attachment



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

[jira] [Updated] (IGNITE-8124) Web console: incorrect text after all clusters have been deleted

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-8124:
---
Fix Version/s: 2.5

> Web console: incorrect text after all clusters have been deleted
> 
>
> Key: IGNITE-8124
> URL: https://issues.apache.org/jira/browse/IGNITE-8124
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Ilya Borisov
>Priority: Minor
> Fix For: 2.5
>
> Attachments: screenshot-1.png
>
>
> # create two clusters
> # delete all clusters
> # see attachment
>  !screenshot-1.png! 



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

[jira] [Created] (IGNITE-8123) Web console: incorrect text after all clusters have been deleted

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8123:
--

 Summary: Web console: incorrect text after all clusters have been 
deleted
 Key: IGNITE-8123
 URL: https://issues.apache.org/jira/browse/IGNITE-8123
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Ilya Borisov


# create two clusters
# delete all clusters
# see attachment



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

[jira] [Commented] (IGNITE-7831) Throw Exceptions instead of AssertionErrors when reading from corrupted persistence

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7831:


[~ilantukh], [~alex_pl], thank you for this contribution. 

I was going to create exactly the same issue, but it is already fixed.

> Throw Exceptions instead of AssertionErrors when reading from corrupted 
> persistence
> ---
>
> Key: IGNITE-7831
> URL: https://issues.apache.org/jira/browse/IGNITE-7831
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> There are a few places in our code where we explicitly throw AssertionErrors 
> due to inability to correctly read data from persistence and many more places 
> where we make assertions based on read values.
> Assertions are used to indicate problems in internal logic, while persistence 
> might also get corrupted by various external reasons. It also makes uniform 
> handling of such issues considerably harder, because exception handling logic 
> in Ignite ignores Errors. If we want to improve stability and minimize 
> consequenses of pesistence corruption, we should replace all those 
> AssertionErrors and asserts with Exceptions, so that current exception 
> handling mechanisms could be reduce. In a number of situations it means that 
> instead of causing cluster-wide hang-up problematic node will be 
> automatically killed.



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

[jira] [Updated] (IGNITE-8122) Partition state restored from WAL may be lost if no checkpoints are done

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-8122:

Description: 
Problem:
1) Start several nodes with enabled persistence.
2) Make sure that all partitions for 'ignite-sys-cache' have status OWN on all 
nodes and appropriate PartitionMetaStateRecord record is logged to WAL
3) Stop all nodes and start again, activate cluster. Checkpoint for 
'ignite-sys-cache' is empty, because there were no data in cache.
4) State for all partitions will be restored to OWN 
(GridCacheDatabaseSharedManager#restoreState) from WAL, but not recorded to 
page memory, because there were no checkpoints and data in cache. Store manager 
doesn't have any allocated pages (including meta) for such partitions.
5) On exchange done we're trying to restore states of partitions 
(initPartitionsWhenAffinityReady) on all nodes. Because page memory is empty, 
states of all partitions will be restored to MOVING by default.
6) All nodes start to rebalance partitions from each other and this process 
become unpredictable because we're trying to rebalance from MOVING partitions.

  was:
Problem:
1) Start several nodes with enabled persistence.
2) Make sure that all partitions for 'ignite-sys-cache' have status OWN on all 
nodes and appropriate PartitionMetaStateRecord record is logged to WAL
3) Stop all nodes and start again, activate cluster. Checkpoint for 
'ignite-sys-cache' is empty, because there were no data in cache.
4) State for all partitions will be restored to OWN 
(GridCacheDatabaseSharedManager#restoreState) from WAL, but not recorded to 
page memory, because there were no checkpoints and data in cache. Store manager 
is not properly initialized for such partitions.
5) On exchange done we're trying to restore states of partitions 
(initPartitionsWhenAffinityReady) on all nodes. Because page memory is empty, 
states of all partitions will be restored to MOVING by default.
6) All nodes start to rebalance partitions from each other and this process 
become unpredictable because we're trying to rebalance from MOVING partitions.


> Partition state restored from WAL may be lost if no checkpoints are done
> 
>
> Key: IGNITE-8122
> URL: https://issues.apache.org/jira/browse/IGNITE-8122
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Minor
> Fix For: 2.5
>
>
> Problem:
> 1) Start several nodes with enabled persistence.
> 2) Make sure that all partitions for 'ignite-sys-cache' have status OWN on 
> all nodes and appropriate PartitionMetaStateRecord record is logged to WAL
> 3) Stop all nodes and start again, activate cluster. Checkpoint for 
> 'ignite-sys-cache' is empty, because there were no data in cache.
> 4) State for all partitions will be restored to OWN 
> (GridCacheDatabaseSharedManager#restoreState) from WAL, but not recorded to 
> page memory, because there were no checkpoints and data in cache. Store 
> manager doesn't have any allocated pages (including meta) for such partitions.
> 5) On exchange done we're trying to restore states of partitions 
> (initPartitionsWhenAffinityReady) on all nodes. Because page memory is empty, 
> states of all partitions will be restored to MOVING by default.
> 6) All nodes start to rebalance partitions from each other and this process 
> become unpredictable because we're trying to rebalance from MOVING partitions.



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

[jira] [Created] (IGNITE-8122) Partition state restored from WAL may be lost if no checkpoints are done

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8122:
---

 Summary: Partition state restored from WAL may be lost if no 
checkpoints are done
 Key: IGNITE-8122
 URL: https://issues.apache.org/jira/browse/IGNITE-8122
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.4
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.5


Problem:
1) Start several nodes with enabled persistence.
2) Make sure that all partitions for 'ignite-sys-cache' have status OWN on all 
nodes and appropriate PartitionMetaStateRecord record is logged to WAL
3) Stop all nodes and start again, activate cluster. Checkpoint for 
'ignite-sys-cache' is empty, because there were no data in cache.
4) State for all partitions will be restored to OWN 
(GridCacheDatabaseSharedManager#restoreState) from WAL, but not recorded to 
page memory, because there were no checkpoints and data in cache. Store manager 
is not properly initialized for such partitions.
5) On exchange done we're trying to restore states of partitions 
(initPartitionsWhenAffinityReady) on all nodes. Because page memory is empty, 
states of all partitions will be restored to MOVING by default.
6) All nodes start to rebalance partitions from each other and this process 
become unpredictable because we're trying to rebalance from MOVING partitions.



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

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-6846:
--

[~dpavlov] Hi!

may be we should choose another reviewer for this ticket?

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



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

[jira] [Commented] (IGNITE-6842) Stop all nodes after test by default.

[Maxim Muzafarov (JIRA)]

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

Maxim Muzafarov commented on IGNITE-6842:
-

More CI regarding new changes after discussions:

[#993 (02 Apr 18 
19:09)|https://ci.ignite.apache.org/viewLog.html?buildId=1173043]
[#1000 (03 Apr 18 
03:27)|https://ci.ignite.apache.org/viewLog.html?buildId=1173802]

> Stop all nodes after test by default.
> -
>
> Key: IGNITE-6842
> URL: https://issues.apache.org/jira/browse/IGNITE-6842
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
> Attachments: IgniteStopGridsTestSuite.java, 
> StopGridsStateFirstTest.java, StopGridsStateSecondTest.java
>
>
> Currently it's required to manually call stopAllGrids() after test completion.
> This leads to errors in subsequent tests if someone forgets to call it and to 
> additional boilerplate code in tests.
> Right choice is to make this default behavior.



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

[jira] [Commented] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[Roman Guseinov (JIRA)]

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

Roman Guseinov commented on IGNITE-7944:


TC results: 
[https://ci.ignite.apache.org/viewLog.html?buildId=1174100=queuedBuildOverviewTab]

 

> Disconnected client node tries to send JOB_CANCEL message
> -
>
> Key: IGNITE-7944
> URL: https://issues.apache.org/jira/browse/IGNITE-7944
> Project: Ignite
>  Issue Type: Bug
>  Components: messaging
>Affects Versions: 1.9, 2.3
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.5
>
> Attachments: Reproducer7944.java
>
>
> In case the network is blocked (socket connections not closed) and failure is 
> detected, tcp-client-disco-msg-worker thread can be stuck in process of 
> TcpClient creating:
> {code:java}
> "tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
> os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - locked <0x7fa140f520c0> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
> - locked <0x7fa140f520b0> (a java.lang.Object)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
> at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It looks like msg-worker is trying to send JOB_CANCEL message for each job 
> with timeout equals failureDetectionTimeout.
> Reproducer is attached.



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

[jira] [Updated] (IGNITE-8121) Web console: import cluster from database doesn't work correctly for second import

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-8121:
---
Description: 
# initial state - no one cluster exists
# import from any DB - the first time all imported correctly
# import the second time - error "Cluster ... already exists"
# refresh the cluster list - the second cluster apear
After that the second imported cluster can't be downloaded.

  was:
# initial state - no one cluster exists
# import from any DB - the first time all imported correctly
# import the second time - error "Cluster ... already exists"


> Web console: import cluster from database doesn't work correctly for second 
> import
> --
>
> Key: IGNITE-8121
> URL: https://issues.apache.org/jira/browse/IGNITE-8121
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Pavel Konstantinov
>Assignee: Ilya Borisov
>Priority: Major
> Fix For: 2.5
>
>
> # initial state - no one cluster exists
> # import from any DB - the first time all imported correctly
> # import the second time - error "Cluster ... already exists"
> # refresh the cluster list - the second cluster apear
> After that the second imported cluster can't be downloaded.



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

[jira] [Updated] (IGNITE-8120) Improve test coverage of rebalance failing

[Ivan Daschinskiy (JIRA)]

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

Ivan Daschinskiy updated IGNITE-8120:
-
Description: Need to cover situation, when some archived wal segments, 
which are not reserved by IgniteWriteAheadLogManager, are deleted during 
rebalancing or were deleted before. However, rebalancing from WAL is broken. 
When fix [IGNITE-8116|https://issues.apache.org/jira/browse/IGNITE-8116] is 
available, it will be implemented.  (was: It is important to test safety of 
deleting unused WAL segments when node supplies rebalancing. However, 
rebalancing from WAL is broken. When fix 
[IGNITE-8116|https://issues.apache.org/jira/browse/IGNITE-8116] is available, 
it will be implemented.)

> Improve test coverage of rebalance failing
> --
>
> Key: IGNITE-8120
> URL: https://issues.apache.org/jira/browse/IGNITE-8120
> Project: Ignite
>  Issue Type: Test
>  Components: general
>Affects Versions: 2.4
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Minor
>  Labels: test
> Fix For: 2.5
>
>
> Need to cover situation, when some archived wal segments, which are not 
> reserved by IgniteWriteAheadLogManager, are deleted during rebalancing or 
> were deleted before. However, rebalancing from WAL is broken. When fix 
> [IGNITE-8116|https://issues.apache.org/jira/browse/IGNITE-8116] is available, 
> it will be implemented.



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

[jira] [Assigned] (IGNITE-6681) .NET: QueryMetrics

[Roman Guseinov (JIRA)]

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

Roman Guseinov reassigned IGNITE-6681:
--

Assignee: Roman Guseinov

> .NET: QueryMetrics
> --
>
> Key: IGNITE-6681
> URL: https://issues.apache.org/jira/browse/IGNITE-6681
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: .NET, newbie
>
> Propagate query metrics to .NET. See {{IgniteCache.queryMetrics}}, 
> {{resetQueryMetrics}}.
> Looks like these metrics are enabled with 
> {{CacheConfiguration.EnableStatistics}}.



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

[jira] [Updated] (IGNITE-8121) Web console: import cluster from database doesn't work correctly for second import

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-8121:
---
Affects Version/s: 2.5

> Web console: import cluster from database doesn't work correctly for second 
> import
> --
>
> Key: IGNITE-8121
> URL: https://issues.apache.org/jira/browse/IGNITE-8121
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Pavel Konstantinov
>Assignee: Ilya Borisov
>Priority: Major
> Fix For: 2.5
>
>
> # initial state - no one cluster exists
> # import from any DB - the first time all imported correctly
> # import the second time - error "Cluster ... already exists"



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

[jira] [Updated] (IGNITE-8121) Web console: import cluster from database doesn't work correctly for second import

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-8121:
---
Fix Version/s: 2.5

> Web console: import cluster from database doesn't work correctly for second 
> import
> --
>
> Key: IGNITE-8121
> URL: https://issues.apache.org/jira/browse/IGNITE-8121
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Pavel Konstantinov
>Assignee: Ilya Borisov
>Priority: Major
> Fix For: 2.5
>
>
> # initial state - no one cluster exists
> # import from any DB - the first time all imported correctly
> # import the second time - error "Cluster ... already exists"



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

[jira] [Created] (IGNITE-8121) Web console: import cluster from database doesn't work correctly for second import

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8121:
--

 Summary: Web console: import cluster from database doesn't work 
correctly for second import
 Key: IGNITE-8121
 URL: https://issues.apache.org/jira/browse/IGNITE-8121
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Ilya Borisov


# initial state - no one cluster exists
# import from any DB - the first time all imported correctly
# import the second time - error "Cluster ... already exists"



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

[jira] [Closed] (IGNITE-7550) Fix windows *.bat scripts Java 9 compatibility

[Peter Ivanov (JIRA)]

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

Peter Ivanov closed IGNITE-7550.


> Fix windows *.bat scripts Java 9 compatibility
> --
>
> Key: IGNITE-7550
> URL: https://issues.apache.org/jira/browse/IGNITE-7550
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.4
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Blocker
> Fix For: 2.4
>
>
> Additional check revealed errors and remarks in \{{ignitevisorcmd.bat}}, 
> \{{control.bat}} and \{{ignite.bat}}.



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

[jira] [Commented] (IGNITE-8119) NPE on clear DB and unclear WAL/WAL_ARCHIVE

[Alexander Belyak (JIRA)]

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

Alexander Belyak commented on IGNITE-8119:
--

Add one more test with different exception (WAL hist size too short)m but with 
same root case
{noformat}
Exception in thread "main" class org.apache.ignite.IgniteException: Failed to 
start processor: GridProcessorAdapter []
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:982)
at org.apache.ignite.Ignition.start(Ignition.java:325)
at org.apache.ignite.examples.datagrid.ClearTest.main(ClearTest.java:68)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
processor: GridProcessorAdapter []
at 
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1683)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:928)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1940)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1683)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:631)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:556)
at org.apache.ignite.Ignition.start(Ignition.java:322)
... 1 more
Caused by: class org.apache.ignite.IgniteCheckedException: WAL history is too 
short 
[descs=[org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileDescriptor@6,
 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileDescriptor@7,
 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileDescriptor@8,
 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileDescriptor@9],
 start=FileWALPointer [idx=0, fileOff=0, len=0]]
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$RecordsIterator.init(FileWriteAheadLogManager.java:2972)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$RecordsIterator.(FileWriteAheadLogManager.java:2923)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$RecordsIterator.(FileWriteAheadLogManager.java:2859)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.replay(FileWriteAheadLogManager.java:751)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1831)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:528)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.start0(GridCacheDatabaseSharedManager.java:479)
at 
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:61)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:667)
at 
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1680)
... 8 more
{noformat}

> NPE on clear DB and unclear WAL/WAL_ARCHIVE
> ---
>
> Key: IGNITE-8119
> URL: https://issues.apache.org/jira/browse/IGNITE-8119
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Priority: Major
> Attachments: ClearTest.java, ClearTestP.java
>
>
> 1) Start grid (1 node will be enought), activate it and populate some data
> 2) Stop node and clear db folder
> 3) Start grid and activate it
> Expected result:
> Error about inconsistent storage configuration with/without start node with 
> such store
> Actual result:
> Exchange-worker on node stop with NPE, this can hang whole cluster from 
> complete any PME operations.
> {noformat}
> Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1, 
> minorTopVer=1], ...
> java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyUpdate(GridCacheDatabaseSharedManager.java:2354)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2099)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1325)
>   at 
> 

[jira] [Updated] (IGNITE-8119) NPE on clear DB and unclear WAL/WAL_ARCHIVE

[Alexander Belyak (JIRA)]

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

Alexander Belyak updated IGNITE-8119:
-
Attachment: ClearTest.java

> NPE on clear DB and unclear WAL/WAL_ARCHIVE
> ---
>
> Key: IGNITE-8119
> URL: https://issues.apache.org/jira/browse/IGNITE-8119
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Priority: Major
> Attachments: ClearTest.java, ClearTestP.java
>
>
> 1) Start grid (1 node will be enought), activate it and populate some data
> 2) Stop node and clear db folder
> 3) Start grid and activate it
> Expected result:
> Error about inconsistent storage configuration with/without start node with 
> such store
> Actual result:
> Exchange-worker on node stop with NPE, this can hang whole cluster from 
> complete any PME operations.
> {noformat}
> Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1, 
> minorTopVer=1], ...
> java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyUpdate(GridCacheDatabaseSharedManager.java:2354)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2099)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1325)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1113)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1063)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:661)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2329)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Updated] (IGNITE-8120) Improve test coverage of rebalance failing

[Ivan Daschinskiy (JIRA)]

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

Ivan Daschinskiy updated IGNITE-8120:
-
Description: It is important to test safety of deleting unused WAL segments 
when node supplies rebalancing. However, rebalancing from WAL is broken. When 
fix [IGNITE-8116|https://issues.apache.org/jira/browse/IGNITE-8116] is 
available, it will be implemented.  (was: It is important to test safety of 
deleting unused WAL segments when node supplies rebalancing. However, 
rebalancing from WAL is broken. After fix [IGNITE-8116|http://example.com] )

> Improve test coverage of rebalance failing
> --
>
> Key: IGNITE-8120
> URL: https://issues.apache.org/jira/browse/IGNITE-8120
> Project: Ignite
>  Issue Type: Test
>  Components: general
>Affects Versions: 2.4
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Minor
>  Labels: test
> Fix For: 2.5
>
>
> It is important to test safety of deleting unused WAL segments when node 
> supplies rebalancing. However, rebalancing from WAL is broken. When fix 
> [IGNITE-8116|https://issues.apache.org/jira/browse/IGNITE-8116] is available, 
> it will be implemented.



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

[jira] [Updated] (IGNITE-8120) Improve test coverage of rebalance failing

[Ivan Daschinskiy (JIRA)]

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

Ivan Daschinskiy updated IGNITE-8120:
-
Description: It is important to test safety of deleting unused WAL segments 
when node supplies rebalancing. However, rebalancing from WAL is broken. After 
fix [IGNITE-8116|http://example.com] 

> Improve test coverage of rebalance failing
> --
>
> Key: IGNITE-8120
> URL: https://issues.apache.org/jira/browse/IGNITE-8120
> Project: Ignite
>  Issue Type: Test
>  Components: general
>Affects Versions: 2.4
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Minor
>  Labels: test
> Fix For: 2.5
>
>
> It is important to test safety of deleting unused WAL segments when node 
> supplies rebalancing. However, rebalancing from WAL is broken. After fix 
> [IGNITE-8116|http://example.com] 



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

[jira] [Created] (IGNITE-8120) Improve test coverage of rebalance failing

[Ivan Daschinskiy (JIRA)]

Ivan Daschinskiy created IGNITE-8120:


 Summary: Improve test coverage of rebalance failing
 Key: IGNITE-8120
 URL: https://issues.apache.org/jira/browse/IGNITE-8120
 Project: Ignite
  Issue Type: Test
  Components: general
Affects Versions: 2.4
Reporter: Ivan Daschinskiy
Assignee: Ivan Daschinskiy
 Fix For: 2.5






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