[jira] [Commented] (IGNITE-7864) Control utility: Add confirm on dangerous operations
[ https://issues.apache.org/jira/browse/IGNITE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16401776#comment-16401776 ] Sergey Kosarev commented on IGNITE-7864: Need to test on Linux/Win/MAc For Commands --deactivate --baseline add --baseline remove --baseline set --baseline version (notice --baseline without arguments does not require confirmation) should show warning text annd require interactive confirmation from console if user responds with y/Y utility will proceed, othertwise exit with zero code (success) if --force option added then confirmation is not requested and commands are executing as usual. > Control utility: Add confirm on dangerous operations > > > Key: IGNITE-7864 > URL: https://issues.apache.org/jira/browse/IGNITE-7864 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Kuznetsov >Assignee: Sergey Kosarev >Priority: Major > Fix For: 2.5 > > > control.sh can deactivate cluster. > It could be very dangerous in some cases. > Lets add manual confirmation for dangerous operations: deactivate, change > base line, ... > Also, lets add "-force" option to not ask for confirmation (will be useful in > scripts). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7864) Control utility: Add confirm on dangerous operations
[ https://issues.apache.org/jira/browse/IGNITE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16401760#comment-16401760 ] Sergey Kosarev commented on IGNITE-7864: It's probably matter of taste I prefer Lists more than Arrays) > Control utility: Add confirm on dangerous operations > > > Key: IGNITE-7864 > URL: https://issues.apache.org/jira/browse/IGNITE-7864 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Kuznetsov >Assignee: Sergey Kosarev >Priority: Major > Fix For: 2.5 > > > control.sh can deactivate cluster. > It could be very dangerous in some cases. > Lets add manual confirmation for dangerous operations: deactivate, change > base line, ... > Also, lets add "-force" option to not ask for confirmation (will be useful in > scripts). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7864) Control utility: Add confirm on dangerous operations
[ https://issues.apache.org/jira/browse/IGNITE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev reassigned IGNITE-7864: -- Assignee: Alexey Kuznetsov (was: Sergey Kosarev) > Control utility: Add confirm on dangerous operations > > > Key: IGNITE-7864 > URL: https://issues.apache.org/jira/browse/IGNITE-7864 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.5 > > > control.sh can deactivate cluster. > It could be very dangerous in some cases. > Lets add manual confirmation for dangerous operations: deactivate, change > base line, ... > Also, lets add "-force" option to not ask for confirmation (will be useful in > scripts). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7864) Control utility: Add confirm on dangerous operations
[ https://issues.apache.org/jira/browse/IGNITE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16401619#comment-16401619 ] Sergey Kosarev commented on IGNITE-7864: updated PR. new TC run https://ci.ignite.apache.org/viewQueued.html?itemId=1139902 > Control utility: Add confirm on dangerous operations > > > Key: IGNITE-7864 > URL: https://issues.apache.org/jira/browse/IGNITE-7864 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Kuznetsov >Assignee: Sergey Kosarev >Priority: Major > Fix For: 2.5 > > > control.sh can deactivate cluster. > It could be very dangerous in some cases. > Lets add manual confirmation for dangerous operations: deactivate, change > base line, ... > Also, lets add "-force" option to not ask for confirmation (will be useful in > scripts). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7914) Add transaction debugging support in control.sh
[ https://issues.apache.org/jira/browse/IGNITE-7914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev reassigned IGNITE-7914: -- Assignee: Sergey Kosarev > Add transaction debugging support in control.sh > --- > > Key: IGNITE-7914 > URL: https://issues.apache.org/jira/browse/IGNITE-7914 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Alexei Scherbakov >Assignee: Sergey Kosarev >Priority: Major > Fix For: 2.5 > > > Detailed description in IGNITE-7910, paragraph 3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7864) Control utility: Add confirm on dangerous operations
[ https://issues.apache.org/jira/browse/IGNITE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev reassigned IGNITE-7864: -- Assignee: Sergey Kosarev > Control utility: Add confirm on dangerous operations > > > Key: IGNITE-7864 > URL: https://issues.apache.org/jira/browse/IGNITE-7864 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Kuznetsov >Assignee: Sergey Kosarev >Priority: Major > Fix For: 2.5 > > > control.sh can deactivate cluster. > It could be very dangerous in some cases. > Lets add manual confirmation for dangerous operations: deactivate, change > base line, ... > Also, lets add "-force" option to not ask for confirmation (will be useful in > scripts). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence
[
https://issues.apache.org/jira/browse/IGNITE-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369312#comment-16369312
]
Sergey Kosarev commented on IGNITE-7742:
Test update added case for cahe.get() from remote node - it causes
AssertionError on remote node and hanging up of waiting thread.
> AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with
> expire policy and persistence
> -
>
> Key: IGNITE-7742
> URL: https://issues.apache.org/jira/browse/IGNITE-7742
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.4
>Reporter: Sergey Kosarev
>Priority: Major
> Attachments: IgniteDbExpirePolicyTest.java
>
>
> Some assertions were added in IGNITE-6423
> One of them fires here.
> We check for
> assert
> cctx.shared().database().checkpointLockIsHeldByThread();
> but we don't have this lock
> {code:java}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
> 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:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
> at java.lang.Thread.run(Thread.java:748){code}
> Simple test fails
> [^IgniteDbExpirePolicyTest.java]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence
[
https://issues.apache.org/jira/browse/IGNITE-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369312#comment-16369312
]
Sergey Kosarev edited comment on IGNITE-7742 at 2/19/18 4:52 PM:
-
Test update added case for cache.get() from remote node - it causes
AssertionError on remote node and hanging up of waiting thread.
was (Author: macrergate):
Test update added case for cahe.get() from remote node - it causes
AssertionError on remote node and hanging up of waiting thread.
> AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with
> expire policy and persistence
> -
>
> Key: IGNITE-7742
> URL: https://issues.apache.org/jira/browse/IGNITE-7742
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.4
>Reporter: Sergey Kosarev
>Priority: Major
> Attachments: IgniteDbExpirePolicyTest.java
>
>
> Some assertions were added in IGNITE-6423
> One of them fires here.
> We check for
> assert
> cctx.shared().database().checkpointLockIsHeldByThread();
> but we don't have this lock
> {code:java}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
> 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:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
> at java.lang.Thread.run(Thread.java:748){code}
> Simple test fails
> [^IgniteDbExpirePolicyTest.java]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence
[
https://issues.apache.org/jira/browse/IGNITE-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kosarev updated IGNITE-7742:
---
Attachment: (was: IgniteDbExpirePolicyTest.java)
> AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with
> expire policy and persistence
> -
>
> Key: IGNITE-7742
> URL: https://issues.apache.org/jira/browse/IGNITE-7742
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.4
>Reporter: Sergey Kosarev
>Priority: Major
> Attachments: IgniteDbExpirePolicyTest.java
>
>
> Some assertions were added in IGNITE-6423
> One of them fires here.
> We check for
> assert
> cctx.shared().database().checkpointLockIsHeldByThread();
> but we don't have this lock
> {code:java}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
> 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:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
> at java.lang.Thread.run(Thread.java:748){code}
> Simple test fails
> [^IgniteDbExpirePolicyTest.java]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence
[
https://issues.apache.org/jira/browse/IGNITE-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kosarev updated IGNITE-7742:
---
Attachment: IgniteDbExpirePolicyTest.java
> AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with
> expire policy and persistence
> -
>
> Key: IGNITE-7742
> URL: https://issues.apache.org/jira/browse/IGNITE-7742
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.4
>Reporter: Sergey Kosarev
>Priority: Major
> Attachments: IgniteDbExpirePolicyTest.java
>
>
> Some assertions were added in IGNITE-6423
> One of them fires here.
> We check for
> assert
> cctx.shared().database().checkpointLockIsHeldByThread();
> but we don't have this lock
> {code:java}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
> 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:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
> at java.lang.Thread.run(Thread.java:748){code}
> Simple test fails
> [^IgniteDbExpirePolicyTest.java]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence
[
https://issues.apache.org/jira/browse/IGNITE-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kosarev updated IGNITE-7742:
---
Description:
Some assertions were added in IGNITE-6423
One of them fires here.
We check for
assert cctx.shared().database().checkpointLockIsHeldByThread();
but we don't have this lock
{code:java}
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at
org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at
org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
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:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
at java.lang.Thread.run(Thread.java:748){code}
Simple test fails
[^IgniteDbExpirePolicyTest.java]
was:
Some assertions were added in IGNITE-6423
One of them fires here.
We check for
assert cctx.shared().database().checkpointLockIsHeldByThread();
but we don't have this lock
{code:java}
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at
org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at
org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
[jira] [Updated] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence
[
https://issues.apache.org/jira/browse/IGNITE-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kosarev updated IGNITE-7742:
---
Attachment: IgniteDbExpirePolicyTest.java
> AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with
> expire policy and persistence
> -
>
> Key: IGNITE-7742
> URL: https://issues.apache.org/jira/browse/IGNITE-7742
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.4
>Reporter: Sergey Kosarev
>Priority: Major
> Attachments: IgniteDbExpirePolicyTest.java
>
>
> Some assertions were added in IGNITE-6423
> One of them fires here.
> We check for
> assert
> cctx.shared().database().checkpointLockIsHeldByThread();
> but we don't have this lock
> {code:java}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
> 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:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
> at java.lang.Thread.run(Thread.java:748){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence
Sergey Kosarev created IGNITE-7742:
--
Summary: AssertionError in IgniteCacheOffheapManagerImpl when
Iterate Cache with expire policy and persistence
Key: IGNITE-7742
URL: https://issues.apache.org/jira/browse/IGNITE-7742
Project: Ignite
Issue Type: Bug
Components: persistence
Affects Versions: 2.4
Reporter: Sergey Kosarev
Some assertions were added in IGNITE-6423
One of them fires here.
We check for
assert cctx.shared().database().checkpointLockIsHeldByThread();
but we don't have this lock
{code:java}
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at
org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at
org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132)
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:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
at java.lang.Thread.run(Thread.java:748){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7674) It is possible to create BinaryObject with wrong field type and that can lead to broken Transaction (TransactionHeuristicException)
[
https://issues.apache.org/jira/browse/IGNITE-7674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kosarev updated IGNITE-7674:
---
Description:
Usuaully if we have any data in a cache, if we try to create BynaryObject with
the same field name and another type we BinaryObjectException is thrown
Wrong value has been set [typeName=org.apache.ignite.internal.binary.Foo,
fieldName=intField, fieldType=int, assignedValueType=String]
, but there are cases we can create an inconsistent BinaryObject
suppose we have
{code:java}
class Foo {
private String strField;
private int intField;
public Foo(String strField, int intField) {
this.intField = intField;
this.strField = strField;
}
}{code}
case 1
{code:java}
binary.builder(Foo.class.getName())
.removeField("intField")
.build()
.toBuilder()
.setField("intField", "String")
.build();{code}
case 2 (if we remove all fields schema flag is cleared )
{code:java}
fooCache.withKeepBinary().get(1)
.toBuilder()
.removeField("intField")
.removeField("strField")
.build()
.toBuilder()
.setField("intField", "String")
.build(){code}
It is especially bad when we have an index on this field and cache is
transactional.
if we put wrong BinaryObject into the cache, we got
TransactionHeuristicException on commit and broken transaction (data can be
comitted or not in some cases)
[^BinaryObjectChangeFieldTypeTest.java] reproduce the problems.
was:
Usuaully if we have any data in a cache, if we try to create BynaryObject with
the same field name and another type we BinaryObjectException is thrown
Wrong value has been set [typeName=org.apache.ignite.internal.binary.Foo,
fieldName=intField, fieldType=int, assignedValueType=String]
, but there are cases we can create an inconsistent BinaryObject
suppose we have
{code:java}
class Foo {
private String strField;
private int intField;
public Foo(String strField, int intField) {
this.intField = intField;
this.strField = strField;
}
}{code}
case 1
{code:java}
binary.builder(Foo.class.getName())
.removeField("intField")
.build()
.toBuilder()
.setField("intField", "String")
.build();{code}
case 2 (if we remove all fields schema flag is cleared )
{code:java}
fooCache.withKeepBinary().get(1)
.toBuilder()
.removeField("intField")
.removeField("strField")
.build()
.toBuilder()
.setField("intField", "String")
.build(){code}
It is especially bad when we have an index on this field and cache is
transactional.
if we put wrong BinaryObject into the cache, we got
TransactionHeuristicException on commit and broken transaction (data can be
comitted or not in some cases)
> It is possible to create BinaryObject with wrong field type and that can lead
> to broken Transaction (TransactionHeuristicException)
> ---
>
> Key: IGNITE-7674
> URL: https://issues.apache.org/jira/browse/IGNITE-7674
> Project: Ignite
> Issue Type: Bug
> Components: binary, sql
>Affects Versions: 2.3
>Reporter: Sergey Kosarev
>Priority: Major
> Attachments: BinaryObjectChangeFieldTypeTest.java
>
>
> Usuaully if we have any data in a cache, if we try to create BynaryObject
> with the same field name and another type we BinaryObjectException is thrown
> Wrong value has been set [typeName=org.apache.ignite.internal.binary.Foo,
> fieldName=intField, fieldType=int, assignedValueType=String]
> , but there are cases we can create an inconsistent BinaryObject
> suppose we have
> {code:java}
> class Foo {
> private String strField;
> private int intField;
> public Foo(String strField, int intField) {
> this.intField = intField;
> this.strField = strField;
> }
> }{code}
> case 1
> {code:java}
> binary.builder(Foo.class.getName())
> .removeField("intField")
> .build()
> .toBuilder()
> .setField("intField", "String")
> .build();{code}
> case 2 (if we remove all fields schema flag is cleared )
> {code:java}
> fooCache.withKeepBinary().get(1)
> .toBuilder()
> .removeField("intField")
> .removeField("strField")
> .build()
> .toBuilder()
> .setField("intField", "String")
> .build(){code}
>
> It is especially bad when we have an index on this field and cache is
> transactional.
> if we put wrong BinaryObject into the cache, we got
> TransactionHeuristicException on commit and broken transaction (data can be
> comitted or not in some cases)
> [^BinaryObjectChangeFieldTypeTest.java] reproduce the problems.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7674) It is possible to create BinaryObject with wrong field type and that can lead to broken Transaction (TransactionHeuristicException)
[
https://issues.apache.org/jira/browse/IGNITE-7674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kosarev updated IGNITE-7674:
---
Attachment: BinaryObjectChangeFieldTypeTest.java
> It is possible to create BinaryObject with wrong field type and that can lead
> to broken Transaction (TransactionHeuristicException)
> ---
>
> Key: IGNITE-7674
> URL: https://issues.apache.org/jira/browse/IGNITE-7674
> Project: Ignite
> Issue Type: Bug
> Components: binary, sql
>Affects Versions: 2.3
>Reporter: Sergey Kosarev
>Priority: Major
> Attachments: BinaryObjectChangeFieldTypeTest.java
>
>
> Usuaully if we have any data in a cache, if we try to create BynaryObject
> with the same field name and another type we BinaryObjectException is thrown
> Wrong value has been set [typeName=org.apache.ignite.internal.binary.Foo,
> fieldName=intField, fieldType=int, assignedValueType=String]
> , but there are cases we can create an inconsistent BinaryObject
> suppose we have
> {code:java}
> class Foo {
> private String strField;
> private int intField;
> public Foo(String strField, int intField) {
> this.intField = intField;
> this.strField = strField;
> }
> }{code}
> case 1
> {code:java}
> binary.builder(Foo.class.getName())
> .removeField("intField")
> .build()
> .toBuilder()
> .setField("intField", "String")
> .build();{code}
> case 2 (if we remove all fields schema flag is cleared )
> {code:java}
> fooCache.withKeepBinary().get(1)
> .toBuilder()
> .removeField("intField")
> .removeField("strField")
> .build()
> .toBuilder()
> .setField("intField", "String")
> .build(){code}
> It is especially bad when we have an index on this field and cache is
> transactional.
> if we put wrong BinaryObject into the cache, we got
> TransactionHeuristicException on commit and broken transaction (data can be
> comitted or not in some cases)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7674) It is possible to create BinaryObject with wrong field type and that can lead to broken Transaction (TransactionHeuristicException)
Sergey Kosarev created IGNITE-7674:
--
Summary: It is possible to create BinaryObject with wrong field
type and that can lead to broken Transaction (TransactionHeuristicException)
Key: IGNITE-7674
URL: https://issues.apache.org/jira/browse/IGNITE-7674
Project: Ignite
Issue Type: Bug
Components: binary, sql
Affects Versions: 2.3
Reporter: Sergey Kosarev
Usuaully if we have any data in a cache, if we try to create BynaryObject with
the same field name and another type we BinaryObjectException is thrown
Wrong value has been set [typeName=org.apache.ignite.internal.binary.Foo,
fieldName=intField, fieldType=int, assignedValueType=String]
, but there are cases we can create an inconsistent BinaryObject
suppose we have
{code:java}
class Foo {
private String strField;
private int intField;
public Foo(String strField, int intField) {
this.intField = intField;
this.strField = strField;
}
}{code}
case 1
{code:java}
binary.builder(Foo.class.getName())
.removeField("intField")
.build()
.toBuilder()
.setField("intField", "String")
.build();{code}
case 2 (if we remove all fields schema flag is cleared )
{code:java}
fooCache.withKeepBinary().get(1)
.toBuilder()
.removeField("intField")
.removeField("strField")
.build()
.toBuilder()
.setField("intField", "String")
.build(){code}
It is especially bad when we have an index on this field and cache is
transactional.
if we put wrong BinaryObject into the cache, we got
TransactionHeuristicException on commit and broken transaction (data can be
comitted or not in some cases)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7624) Cluster Activation from Client Node hangs up in specific configuration
[
https://issues.apache.org/jira/browse/IGNITE-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kosarev updated IGNITE-7624:
---
Attachment: testStartInactiveAndActivateFromClient.patch
> Cluster Activation from Client Node hangs up in specific configuration
> --
>
> Key: IGNITE-7624
> URL: https://issues.apache.org/jira/browse/IGNITE-7624
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.3
>Reporter: Sergey Kosarev
>Priority: Major
> Fix For: 2.5
>
> Attachments: testStartInactiveAndActivateFromClient.patch
>
>
> if we start cluster in inactive state GridTaskProcessor is not initiated
> fully:
> {code:java}
> @Override public void onKernalStart(boolean active) throws
> IgniteCheckedException {
> if (!active)
> return;
> tasksMetaCache = ctx.security().enabled() && !ctx.isDaemon() ?
> ctx.cache().utilityCache() : null;
> startLatch.countDown();
> }{code}
>
> and those startLatch is still up!
>
> Later on if we try activate cluster from client node async task is trying to
> be invoked
> (see
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessorImpl#sendComputeChangeGlobalState)
> and if ctx.security().enabled == true then Task is can't start as he waits
> indefinitely for those startLatch in
> org.apache.ignite.internal.processors.task.GridTaskProcessor#taskMetaCache
> {code:java}
> private IgniteInternalCache taskMetaCache() {
> assert ctx.security().enabled();
> if (tasksMetaCache == null)
> U.awaitQuiet(startLatch);
> return tasksMetaCache;
> }{code}
>
> stacktrace of the waiting thread:
> {code:java}
> "async-runnable-runner-1@3141" prio=5 tid=0x68 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7491)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.taskMetaCache(GridTaskProcessor.java:269)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.saveTaskMetadata(GridTaskProcessor.java:845)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:703)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:448)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor.runAsync(GridClosureProcessor.java:244)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor.runAsync(GridClosureProcessor.java:216)
> at
> org.apache.ignite.internal.IgniteComputeImpl.runAsync0(IgniteComputeImpl.java:704)
> at
> org.apache.ignite.internal.IgniteComputeImpl.runAsync(IgniteComputeImpl.java:689)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessorImpl.sendComputeChangeGlobalState(GridClusterStateProcessorImpl.java:837)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessorImpl.changeGlobalState0(GridClusterStateProcessorImpl.java:684)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessorImpl.changeGlobalState(GridClusterStateProcessorImpl.java:618)
> at
> org.apache.ignite.internal.cluster.IgniteClusterImpl.active(IgniteClusterImpl.java:306)
> at org.apache.ignite.internal.IgniteKernal.active(IgniteKernal.java:3541)
> at
> org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTest$7.run(IgniteClusterActivateDeactivateTest.java:628)
> at org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:892)
> at
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1237)
> at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7624) Cluster Activation from Client Node hangs up in specific configuration
[
https://issues.apache.org/jira/browse/IGNITE-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kosarev updated IGNITE-7624:
---
Description:
if we start cluster in inactive state GridTaskProcessor is not initiated fully:
{code:java}
@Override public void onKernalStart(boolean active) throws
IgniteCheckedException {
if (!active)
return;
tasksMetaCache = ctx.security().enabled() && !ctx.isDaemon() ?
ctx.cache().utilityCache() : null;
startLatch.countDown();
}{code}
and those startLatch is still up!
Later on if we try activate cluster from client node async task is trying to be
invoked
(see
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessorImpl#sendComputeChangeGlobalState)
and if ctx.security().enabled == true then Task is can't start as he waits
indefinitely for those startLatch in
org.apache.ignite.internal.processors.task.GridTaskProcessor#taskMetaCache
{code:java}
private IgniteInternalCache taskMetaCache() {
assert ctx.security().enabled();
if (tasksMetaCache == null)
U.awaitQuiet(startLatch);
return tasksMetaCache;
}{code}
stacktrace of the waiting thread:
{code:java}
"async-runnable-runner-1@3141" prio=5 tid=0x68 nid=NA waiting
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Unsafe.java:-1)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7491)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.taskMetaCache(GridTaskProcessor.java:269)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.saveTaskMetadata(GridTaskProcessor.java:845)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:703)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:448)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor.runAsync(GridClosureProcessor.java:244)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor.runAsync(GridClosureProcessor.java:216)
at
org.apache.ignite.internal.IgniteComputeImpl.runAsync0(IgniteComputeImpl.java:704)
at
org.apache.ignite.internal.IgniteComputeImpl.runAsync(IgniteComputeImpl.java:689)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessorImpl.sendComputeChangeGlobalState(GridClusterStateProcessorImpl.java:837)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessorImpl.changeGlobalState0(GridClusterStateProcessorImpl.java:684)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessorImpl.changeGlobalState(GridClusterStateProcessorImpl.java:618)
at
org.apache.ignite.internal.cluster.IgniteClusterImpl.active(IgniteClusterImpl.java:306)
at org.apache.ignite.internal.IgniteKernal.active(IgniteKernal.java:3541)
at
org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTest$7.run(IgniteClusterActivateDeactivateTest.java:628)
at org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:892)
at org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1237)
at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
{code}
was:
if we start cluster in inactive state GridTaskProcessor is not initiated fully:
{code:java}
@Override public void onKernalStart(boolean active) throws
IgniteCheckedException {
if (!active)
return;
tasksMetaCache = ctx.security().enabled() && !ctx.isDaemon() ?
ctx.cache().utilityCache() : null;
startLatch.countDown();
}{code}
and those startLatch is still up!
Later on if we try activate cluster from client node async task is trying to be
invoked
(see
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessorImpl#sendComputeChangeGlobalState)
and if ctx.security().enabled == true then Task is can't start as he waits
indefinitely for those startLatch in
org.apache.ignite.internal.processors.task.GridTaskProcessor#taskMetaCache
{code:java}
private IgniteInternalCache taskMetaCache() {
assert ctx.security().enabled();
if (tasksMetaCache == null)
U.awaitQuiet(startLatch);
return tasksMetaCache;
}{code}
stacktrace of the waiting thread:
{code:java}
"pool-1-thread-1@3160" prio=5 tid=0x68 nid=NA waiting
[jira] [Created] (IGNITE-7624) Cluster Activation from Client Node hangs up in specific configuration
Sergey Kosarev created IGNITE-7624:
--
Summary: Cluster Activation from Client Node hangs up in specific
configuration
Key: IGNITE-7624
URL: https://issues.apache.org/jira/browse/IGNITE-7624
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.3
Reporter: Sergey Kosarev
Fix For: 2.5
if we start cluster in inactive state GridTaskProcessor is not initiated fully:
{code:java}
@Override public void onKernalStart(boolean active) throws
IgniteCheckedException {
if (!active)
return;
tasksMetaCache = ctx.security().enabled() && !ctx.isDaemon() ?
ctx.cache().utilityCache() : null;
startLatch.countDown();
}{code}
and those startLatch is still up!
Later on if we try activate cluster from client node async task is trying to be
invoked
(see
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessorImpl#sendComputeChangeGlobalState)
and if ctx.security().enabled == true then Task is can't start as he waits
indefinitely for those startLatch in
org.apache.ignite.internal.processors.task.GridTaskProcessor#taskMetaCache
{code:java}
private IgniteInternalCache taskMetaCache() {
assert ctx.security().enabled();
if (tasksMetaCache == null)
U.awaitQuiet(startLatch);
return tasksMetaCache;
}{code}
stacktrace of the waiting thread:
{code:java}
"pool-1-thread-1@3160" prio=5 tid=0x68 nid=NA waiting
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Unsafe.java:-1)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7491)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.taskMetaCache(GridTaskProcessor.java:269)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.saveTaskMetadata(GridTaskProcessor.java:845)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:703)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:448)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor.runAsync(GridClosureProcessor.java:244)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor.runAsync(GridClosureProcessor.java:216)
at
org.apache.ignite.internal.IgniteComputeImpl.runAsync0(IgniteComputeImpl.java:704)
at
org.apache.ignite.internal.IgniteComputeImpl.runAsync(IgniteComputeImpl.java:689)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessorImpl.sendComputeChangeGlobalState(GridClusterStateProcessorImpl.java:837)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessorImpl.changeGlobalState0(GridClusterStateProcessorImpl.java:684)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessorImpl.changeGlobalState(GridClusterStateProcessorImpl.java:618)
at
org.apache.ignite.internal.cluster.IgniteClusterImpl.active(IgniteClusterImpl.java:306)
at org.apache.ignite.internal.IgniteKernal.active(IgniteKernal.java:3541)
at
org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTest$7.run(IgniteClusterActivateDeactivateTest.java:627)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
at java.util.concurrent.FutureTask.run(FutureTask.java:-1)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7485) add support for authentication parameters to control.sh utility
[ https://issues.apache.org/jira/browse/IGNITE-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336026#comment-16336026 ] Sergey Kosarev commented on IGNITE-7485: Changed to "–user", added tests for parsing arguments. > add support for authentication parameters to control.sh utility > --- > > Key: IGNITE-7485 > URL: https://issues.apache.org/jira/browse/IGNITE-7485 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Major > > Currently controls.sh utility does not work if cluster is running under > authentication. > Error is shown: > Failed to get cluster state. > Authentication error. > > it is suggested to introduce authentication parameters to the utitlity > --login LOGIN > --password PASSWORD > > Main Utility class ( CommandHandler ) is located in ignite-core module > currently. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7485) add support for authentication parameters to control.sh utility
[ https://issues.apache.org/jira/browse/IGNITE-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334267#comment-16334267 ] Sergey Kosarev commented on IGNITE-7485: [~kuaw26], I don't mind. Just used same naming as in org.apache.ignite.plugin.security.SecurityCredentials > add support for authentication parameters to control.sh utility > --- > > Key: IGNITE-7485 > URL: https://issues.apache.org/jira/browse/IGNITE-7485 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Major > > Currently controls.sh utility does not work if cluster is running under > authentication. > Error is shown: > Failed to get cluster state. > Authentication error. > > it is suggested to introduce authentication parameters to the utitlity > --login LOGIN > --password PASSWORD > > Main Utility class ( CommandHandler ) is located in ignite-core module > currently. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7485) add support for authentication parameters to control.sh utility
[ https://issues.apache.org/jira/browse/IGNITE-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334162#comment-16334162 ] Sergey Kosarev commented on IGNITE-7485: TC Run https://ci.ignite.apache.org/viewQueued.html?itemId=1053368 > add support for authentication parameters to control.sh utility > --- > > Key: IGNITE-7485 > URL: https://issues.apache.org/jira/browse/IGNITE-7485 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Major > > Currently controls.sh utility does not work if cluster is running under > authentication. > Error is shown: > Failed to get cluster state. > Authentication error. > > it is suggested to introduce authentication parameters to the utitlity > --login LOGIN > --password PASSWORD > > Main Utility class ( CommandHandler ) is located in ignite-core module > currently. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7485) add support for authentication parameters to control.sh utility
[ https://issues.apache.org/jira/browse/IGNITE-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334140#comment-16334140 ] Sergey Kosarev commented on IGNITE-7485: [~avinogradov], Please review my changes. > add support for authentication parameters to control.sh utility > --- > > Key: IGNITE-7485 > URL: https://issues.apache.org/jira/browse/IGNITE-7485 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Major > > Currently controls.sh utility does not work if cluster is running under > authentication. > Error is shown: > Failed to get cluster state. > Authentication error. > > it is suggested to introduce authentication parameters to the utitlity > --login LOGIN > --password PASSWORD > > Main Utility class ( CommandHandler ) is located in ignite-core module > currently. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7485) add support for authentication parameters to control.sh utility
[ https://issues.apache.org/jira/browse/IGNITE-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev updated IGNITE-7485: --- Summary: add support for authentication parameters to control.sh utility (was: control.sh utility does not support authentication) > add support for authentication parameters to control.sh utility > --- > > Key: IGNITE-7485 > URL: https://issues.apache.org/jira/browse/IGNITE-7485 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Major > > Currently controls.sh utility does not work if cluster is running under > authentication. > Error is shown: > Failed to get cluster state. > Authentication error. > > it is suggested to introduce authentication parameters to the utitlity > --login LOGIN > --password PASSWORD > > Main Utility class ( CommandHandler ) is located in ignite-core module > currently. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7485) control.sh utility does not support authentication
Sergey Kosarev created IGNITE-7485: -- Summary: control.sh utility does not support authentication Key: IGNITE-7485 URL: https://issues.apache.org/jira/browse/IGNITE-7485 Project: Ignite Issue Type: Improvement Components: general Reporter: Sergey Kosarev Assignee: Sergey Kosarev Currently controls.sh utility does not work if cluster is running under authentication. Error is shown: Failed to get cluster state. Authentication error. it is suggested to introduce authentication parameters to the utitlity --login LOGIN --password PASSWORD Main Utility class ( CommandHandler ) is located in ignite-core module currently. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5565) Replace Cron4J with Quartz or Spring scheduler for ignite-schedule module.
[ https://issues.apache.org/jira/browse/IGNITE-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16330749#comment-16330749 ] Sergey Kosarev commented on IGNITE-5565: second version change to Spring ThreadPoolTaskScheder removed Cron4J and Quartz > Replace Cron4J with Quartz or Spring scheduler for ignite-schedule module. > -- > > Key: IGNITE-5565 > URL: https://issues.apache.org/jira/browse/IGNITE-5565 > Project: Ignite > Issue Type: Task > Components: general >Reporter: Alexey Kuznetsov >Assignee: Sergey Kosarev >Priority: Major > > 1) Cron4J is very old: > Latest Cron4j 2.2.5 released: 28-Dec-2011 > Latest Quarz 2.3.0 released: 20-Apr-2017 > 2) Not very friendly license: > CronJ4 licensed under GNU LESSER GENERAL PUBLIC LICENSE > Quartz is freely usable, licensed under the Apache 2.0 license. > So, if we replace Cron4J with Quartz we can move ignite-schedule module > from lgpl profile to main distribution. > Also spring's scheduler could be considered as Cron4J alternative. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5565) Replace Cron4J with Quartz or Spring scheduler for ignite-schedule module.
[ https://issues.apache.org/jira/browse/IGNITE-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1632#comment-1632 ] Sergey Kosarev commented on IGNITE-5565: PR https://github.com/apache/ignite/pull/3395 > Replace Cron4J with Quartz or Spring scheduler for ignite-schedule module. > -- > > Key: IGNITE-5565 > URL: https://issues.apache.org/jira/browse/IGNITE-5565 > Project: Ignite > Issue Type: Task > Components: general >Reporter: Alexey Kuznetsov >Assignee: Sergey Kosarev >Priority: Major > > 1) Cron4J is very old: > Latest Cron4j 2.2.5 released: 28-Dec-2011 > Latest Quarz 2.3.0 released: 20-Apr-2017 > 2) Not very friendly license: > CronJ4 licensed under GNU LESSER GENERAL PUBLIC LICENSE > Quartz is freely usable, licensed under the Apache 2.0 license. > So, if we replace Cron4J with Quartz we can move ignite-schedule module > from lgpl profile to main distribution. > Also spring's scheduler could be considered as Cron4J alternative. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-5565) Replace Cron4J with Quartz or Spring scheduler for ignite-schedule module.
[ https://issues.apache.org/jira/browse/IGNITE-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev reassigned IGNITE-5565: -- Assignee: Sergey Kosarev > Replace Cron4J with Quartz or Spring scheduler for ignite-schedule module. > -- > > Key: IGNITE-5565 > URL: https://issues.apache.org/jira/browse/IGNITE-5565 > Project: Ignite > Issue Type: Task > Components: general >Reporter: Alexey Kuznetsov >Assignee: Sergey Kosarev >Priority: Major > > 1) Cron4J is very old: > Latest Cron4j 2.2.5 released: 28-Dec-2011 > Latest Quarz 2.3.0 released: 20-Apr-2017 > 2) Not very friendly license: > CronJ4 licensed under GNU LESSER GENERAL PUBLIC LICENSE > Quartz is freely usable, licensed under the Apache 2.0 license. > So, if we replace Cron4J with Quartz we can move ignite-schedule module > from lgpl profile to main distribution. > Also spring's scheduler could be considered as Cron4J alternative. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
