[jira] [Comment Edited] (IGNITE-8769) JVM crash in Basic1 suite in master branch on TC
[
https://issues.apache.org/jira/browse/IGNITE-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507212#comment-16507212
]
Eduard Shangareev edited comment on IGNITE-8769 at 6/10/18 12:19 AM:
-
Ok, I have found the source.
I analyzed 5 JVM crashes. And logs before them contains:
{code:java}
Failure in thread: Thread [id=169557, name=runner-4]
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.takeEmptyPage(PagesList.java:1053)
at
org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.insertDataRow(AbstractFreeList.java:482)
at
org.apache.ignite.internal.processors.database.CacheFreeListImplSelfTest$1.call(CacheFreeListImplSelfTest.java:208)
at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
{code}
or
{code}
Failure in thread: Thread [id=165136, name=runner-1]
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.put(PagesList.java:641)
at
org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.addForRecycle(AbstractFreeList.java:601)
at
org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.removeDataRowByLink(AbstractFreeList.java:572)
at
org.apache.ignite.internal.processors.database.CacheFreeListImplSelfTest$1.call(CacheFreeListImplSelfTest.java:226)
at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
{code}
And with bisect found that commit below is root cause:
IGNITE-4958 Make data pages recyclable into index/meta/etc pages and vice versa.
[~cyberdemon], please, take a look.
was (Author: edshanggg):
Ok, I have found the source.
I analyzed 5 JVM crashes. And logs before them contains:
{code:java}
Failure in thread: Thread [id=169557, name=runner-4]
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.takeEmptyPage(PagesList.java:1053)
at
org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.insertDataRow(AbstractFreeList.java:482)
at
org.apache.ignite.internal.processors.database.CacheFreeListImplSelfTest$1.call(CacheFreeListImplSelfTest.java:208)
at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
{code}
> JVM crash in Basic1 suite in master branch on TC
>
>
> Key: IGNITE-8769
> URL: https://issues.apache.org/jira/browse/IGNITE-8769
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Priority: Blocker
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Latest build with crash: [TC
> link|https://ci.ignite.apache.org/viewLog.html?buildId=1373991=buildResultsDiv=IgniteTests24Java8_Basic1]
> There is another crash in the history: [TC
> link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Basic1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8769) JVM crash in Basic1 suite in master branch on TC
[
https://issues.apache.org/jira/browse/IGNITE-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507212#comment-16507212
]
Eduard Shangareev commented on IGNITE-8769:
---
Ok, I have found the source.
I analyzed 5 JVM crashes. And logs before them contains:
{code:java}
Failure in thread: Thread [id=169557, name=runner-4]
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.takeEmptyPage(PagesList.java:1053)
at
org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.insertDataRow(AbstractFreeList.java:482)
at
org.apache.ignite.internal.processors.database.CacheFreeListImplSelfTest$1.call(CacheFreeListImplSelfTest.java:208)
at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
{code}
> JVM crash in Basic1 suite in master branch on TC
>
>
> Key: IGNITE-8769
> URL: https://issues.apache.org/jira/browse/IGNITE-8769
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Priority: Blocker
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Latest build with crash: [TC
> link|https://ci.ignite.apache.org/viewLog.html?buildId=1373991=buildResultsDiv=IgniteTests24Java8_Basic1]
> There is another crash in the history: [TC
> link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Basic1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-584) Need to make sure that scan query returns consistent results on topology changes
[ https://issues.apache.org/jira/browse/IGNITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507178#comment-16507178 ] Eduard Shangareev commented on IGNITE-584: -- Please, update PR and add fresh TC Run. I have looked through changes, they seem obvious. If there wouldn't any new test fails, then I will recommend to merge it. > Need to make sure that scan query returns consistent results on topology > changes > > > Key: IGNITE-584 > URL: https://issues.apache.org/jira/browse/IGNITE-584 > Project: Ignite > Issue Type: Sub-task > Components: data structures >Affects Versions: 1.9, 2.0, 2.1 >Reporter: Artem Shutak >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.6 > > Attachments: tc1.png > > > Consistent results on topology changes was implemented for sql queries, but > looks like it still does not work for scan queries. > This affects 'cache set' tests since set uses scan query for set iteration > (to be unmuted on TC): > GridCacheSetAbstractSelfTest testNodeJoinsAndLeaves and > testNodeJoinsAndLeavesCollocated; > Also see todos here GridCacheSetFailoverAbstractSelfTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8103) Node with BLT is not allowed to join cluster without one
[ https://issues.apache.org/jira/browse/IGNITE-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov reassigned IGNITE-8103: --- Assignee: (was: Maxim Muzafarov) > Node with BLT is not allowed to join cluster without one > > > Key: IGNITE-8103 > URL: https://issues.apache.org/jira/browse/IGNITE-8103 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.4 >Reporter: Alexander Belyak >Priority: Major > Fix For: 2.6 > > Attachments: ActivateTest.java > > > 1) Start cluster of 2-3 nodes and activate it, fill some data > 2) Stop cluster, clear LFS on first node > 3) Start cluster from first node (or start all nodes synchronously) > Expected result: ? > Actual result: "Node with set up BaselineTopology is not allowed to join > cluster without one: cons_srv2" > In the technical point of view it's expected behaviour, because first node > with cleared storage became grid coordinator and reject any connection > attempts from nodes with different baseline. But it's bad for usability: if > we always start all nodes together and wanna clear storage on one node by > some reason - we need to define start sequence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-584) Need to make sure that scan query returns consistent results on topology changes
[ https://issues.apache.org/jira/browse/IGNITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny reassigned IGNITE-584: - Assignee: Stanilovsky Evgeny (was: Semen Boikov) > Need to make sure that scan query returns consistent results on topology > changes > > > Key: IGNITE-584 > URL: https://issues.apache.org/jira/browse/IGNITE-584 > Project: Ignite > Issue Type: Sub-task > Components: data structures >Affects Versions: 1.9, 2.0, 2.1 >Reporter: Artem Shutak >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.6 > > Attachments: tc1.png > > > Consistent results on topology changes was implemented for sql queries, but > looks like it still does not work for scan queries. > This affects 'cache set' tests since set uses scan query for set iteration > (to be unmuted on TC): > GridCacheSetAbstractSelfTest testNodeJoinsAndLeaves and > testNodeJoinsAndLeavesCollocated; > Also see todos here GridCacheSetFailoverAbstractSelfTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-584) Need to make sure that scan query returns consistent results on topology changes
[ https://issues.apache.org/jira/browse/IGNITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507091#comment-16507091 ] Stanilovsky Evgeny commented on IGNITE-584: --- [~EdShangGG], i change Assignee field, for pointing that ticket need to review, change it. Can someone check this fix? > Need to make sure that scan query returns consistent results on topology > changes > > > Key: IGNITE-584 > URL: https://issues.apache.org/jira/browse/IGNITE-584 > Project: Ignite > Issue Type: Sub-task > Components: data structures >Affects Versions: 1.9, 2.0, 2.1 >Reporter: Artem Shutak >Assignee: Semen Boikov >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.6 > > Attachments: tc1.png > > > Consistent results on topology changes was implemented for sql queries, but > looks like it still does not work for scan queries. > This affects 'cache set' tests since set uses scan query for set iteration > (to be unmuted on TC): > GridCacheSetAbstractSelfTest testNodeJoinsAndLeaves and > testNodeJoinsAndLeavesCollocated; > Also see todos here GridCacheSetFailoverAbstractSelfTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8179) ZookeeperDiscoverySpiTest#testCommunicationFailureResolve_KillRandom always fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-8179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507089#comment-16507089
]
ASF GitHub Bot commented on IGNITE-8179:
GitHub user BiryukovVA opened a pull request:
https://github.com/apache/ignite/pull/4177
IGNITE-8179: Fluky test.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/BiryukovVA/ignite IGNITE-8179
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4177.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 #4177
commit 543d6af8c3a458700fda6b2958de2634e14c2707
Author: Vitaliy Biryukov
Date: 2018-06-09T17:38:12Z
GNITE-8179: Test fixed.
commit 0a25439bc1d79bc2edfc1fab15d68f33999685ad
Author: Vitaliy Biryukov
Date: 2018-06-09T17:41:59Z
GNITE-8179: For TC testing.
> ZookeeperDiscoverySpiTest#testCommunicationFailureResolve_KillRandom always
> fails on TC
> ---
>
> Key: IGNITE-8179
> URL: https://issues.apache.org/jira/browse/IGNITE-8179
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Test fails on TC with the following stack trace:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1698)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1007)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1977)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1148)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:646)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrids(GridAbstractTest.java:683)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGridsMultiThreaded(GridAbstractTest.java:710)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.startGridsMultiThreaded(GridCommonAbstractTest.java:507)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.startGridsMultiThreaded(GridCommonAbstractTest.java:497)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testCommunicationFailureResolve_KillRandom(ZookeeperDiscoverySpiTest.java:2742)
> 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:2080)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> SPI: ZookeeperDiscoverySpi [zkRootPath=/apacheIgnite,
> zkConnectionString=127.0.0.1:40921,127.0.0.1:35014,127.0.0.1:38754,
> joinTimeout=0, sesTimeout=2000, clientReconnectDisabled=false,
> internalLsnr=null]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:300)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:905)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1693)
> ... 23 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to
> initialize Zookeeper nodes
> at
>
[jira] [Commented] (IGNITE-8769) JVM crash in Basic1 suite in master branch on TC
[ https://issues.apache.org/jira/browse/IGNITE-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507086#comment-16507086 ] Eduard Shangareev commented on IGNITE-8769: --- Stopping test: CacheFreeListImplSelfTest#testInsertDeleteSingleThreaded_16384 last message. > JVM crash in Basic1 suite in master branch on TC > > > Key: IGNITE-8769 > URL: https://issues.apache.org/jira/browse/IGNITE-8769 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Priority: Blocker > Labels: MakeTeamcityGreenAgain > Fix For: 2.6 > > > Latest build with crash: [TC > link|https://ci.ignite.apache.org/viewLog.html?buildId=1373991=buildResultsDiv=IgniteTests24Java8_Basic1] > There is another crash in the history: [TC > link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Basic1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8073) Cache read metric is calculated incorrectly in atomic cache.
[ https://issues.apache.org/jira/browse/IGNITE-8073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-8073: - Description: In atomic cache with near enabled we perform put and remove operations. After it, get operation is called. Now, cache 'read' metric is calculated incorrectly, because it takes into account near cache entry. Reproducer is attached. Note that remove operation untracks 'reader' node from dht cache entry, but near cache entry still exists. The following test checks it : GridCacheAtomicNearCacheSelfTest#checkNearCache, see checkReaderRemove(). was: In atomic cache with near enabled we perform put and remove operations. After it, get operation is called. Now, cache 'read' metric is calculated incorrectly, because it takes into account near cache entry. Reproducer is attached. Note that remove operation untracks 'reader' node from dht cache entry, but near cache entry still exists. The following test checks it : GridCacheAtomicNearCacheSelfTest#checkNearCache, see checkReaderRemove(). See also http://apache-ignite-developers.2346864.n4.nabble.com/Near-cache-entry-removal-td28698.html > Cache read metric is calculated incorrectly in atomic cache. > > > Key: IGNITE-8073 > URL: https://issues.apache.org/jira/browse/IGNITE-8073 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.6 > > Attachments: GridCacheNearAtomicMetricsSelfTest.java > > > In atomic cache with near enabled we perform put and remove operations. > After it, get operation is called. > Now, cache 'read' metric is calculated incorrectly, because it takes into > account near cache entry. > Reproducer is attached. > Note that remove operation untracks 'reader' node from dht cache entry, but > near cache entry still exists. The following test checks it : > GridCacheAtomicNearCacheSelfTest#checkNearCache, see checkReaderRemove(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-2136) Issue with tx entry lock assignment when near cache is used
[ https://issues.apache.org/jira/browse/IGNITE-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507077#comment-16507077 ] Eduard Shangareev commented on IGNITE-2136: --- Hi, [~sboikov]. Do you plan to work with the ticket? > Issue with tx entry lock assignment when near cache is used > --- > > Key: IGNITE-2136 > URL: https://issues.apache.org/jira/browse/IGNITE-2136 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov >Priority: Major > > Adde test reproducing hang on tx putAll when near cache is used: > NearCachePutAllMultinodeTest. > Root cause for this issue is that remote mvcc candidates are marked as owners > during tx finish step. To fix it we can try to move logic from > 'tx.doneRemote' to prepare step. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-584) Need to make sure that scan query returns consistent results on topology changes
[ https://issues.apache.org/jira/browse/IGNITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507079#comment-16507079 ] Eduard Shangareev commented on IGNITE-584: -- Hi, [~sboikov]. Do you plan to work on the ticket? > Need to make sure that scan query returns consistent results on topology > changes > > > Key: IGNITE-584 > URL: https://issues.apache.org/jira/browse/IGNITE-584 > Project: Ignite > Issue Type: Sub-task > Components: data structures >Affects Versions: 1.9, 2.0, 2.1 >Reporter: Artem Shutak >Assignee: Semen Boikov >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.6 > > Attachments: tc1.png > > > Consistent results on topology changes was implemented for sql queries, but > looks like it still does not work for scan queries. > This affects 'cache set' tests since set uses scan query for set iteration > (to be unmuted on TC): > GridCacheSetAbstractSelfTest testNodeJoinsAndLeaves and > testNodeJoinsAndLeavesCollocated; > Also see todos here GridCacheSetFailoverAbstractSelfTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-170) A call of IgniteSet.iterator().next() can produce ClusterTopologyCheckedException on killing a node in topology.
[ https://issues.apache.org/jira/browse/IGNITE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507076#comment-16507076 ] Eduard Shangareev commented on IGNITE-170: -- Hi, [~sboikov]. Do you plan to work with the ticket? > A call of IgniteSet.iterator().next() can produce > ClusterTopologyCheckedException on killing a node in topology. > > > Key: IGNITE-170 > URL: https://issues.apache.org/jira/browse/IGNITE-170 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Irina Vasilinets >Assignee: Semen Boikov >Priority: Major > Labels: MakeTeamcityGreenAgain > > h3. Original description. > GridCachePartitionedAtomicSetFailoverSelfTest.testNodeRestart fails sometimes. > h3. Updated description. > A call of the method next() on an IgniteSet iterator can produce > 'javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: > Query execution failed' exception caused by 'ClusterTopologyCheckedException: > Remote node has left topology' exception (see the full stack trace in > comments). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-627) Inconsistent value in near cache
[ https://issues.apache.org/jira/browse/IGNITE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507078#comment-16507078 ] Eduard Shangareev commented on IGNITE-627: -- Hi, [~sboikov]. Do you plan to work on the ticket? > Inconsistent value in near cache > > > Key: IGNITE-627 > URL: https://issues.apache.org/jira/browse/IGNITE-627 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov >Priority: Major > > This scenario is possible in atomic cache with near cache enabled: > - key is updated concurrently from near and primary node > - primary node first executes update request from near node, registers it as > reader and sends GridNearAtomicUpdateResponse to near node > - then primary node executes second update, sees that there is a reader and > sends GridDhtAtomicUpdateRequest to near node > - GridDhtAtomicUpdateRequest is handled first on near node (see > GridNearAtomicCache.processDhtAtomicUpdateRequest), it tries to peek entry, > it is not created yet and it is considered as evicted, updated is skipped and > reader will be removed on primary node > - then near node handles GridNearAtomicUpdateResponse and creates entry with > incorrect value > Tests > GridCacheValueConsistencyAtomicPrimaryWriteOrderNearEnabledSelfTest.testPutRemoveConsistencyMultithreaded > and testPutConsistencyMultithreaded fail from time to time because of this > issue. > Most probably there is similar issue in transactional cache since > GridCacheValueConsistencyTransactionalNearEnabledSelfTest also fails from > time to time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5510) AssertionError: null instead of GridCacheReturnCompletableWrapper
[
https://issues.apache.org/jira/browse/IGNITE-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507075#comment-16507075
]
Eduard Shangareev commented on IGNITE-5510:
---
Hi, [~sboikov].
Do you plan to work with the ticket?
> AssertionError: null instead of GridCacheReturnCompletableWrapper
> -
>
> Key: IGNITE-5510
> URL: https://issues.apache.org/jira/browse/IGNITE-5510
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Semen Boikov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, test-fail
>
> Reproducer: {{CacheLateAffinityAssignmentTest#testNoForceKeysRequests}}
> Sample log:
> http://ci.ignite.apache.org/viewLog.html?buildId=666034=buildResultsDiv=Ignite20Tests_IgniteCache5
> Stack trace:
> {code}
> java.lang.AssertionError: null instead of GridCacheReturnCompletableWrapper
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1040)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxOnePhaseCommitAckRequest(IgniteTxHandler.java:1070)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$700(IgniteTxHandler.java:95)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:183)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:181)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1032)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:553)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:371)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:301)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:104)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:291)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:124)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1095)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8712) [Test Failed] IgniteDataStructureUniqueNameTest#testUniqueNameMultithreaded fails sometimes in master.
[
https://issues.apache.org/jira/browse/IGNITE-8712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-8712:
-
Summary: [Test Failed]
IgniteDataStructureUniqueNameTest#testUniqueNameMultithreaded fails sometimes
in master. (was: IgniteDataStructureUniqueNameTest#testUniqueNameMultithreaded
fails sometimes in master.)
> [Test Failed] IgniteDataStructureUniqueNameTest#testUniqueNameMultithreaded
> fails sometimes in master.
> --
>
> Key: IGNITE-8712
> URL: https://issues.apache.org/jira/browse/IGNITE-8712
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.5
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=5920780021361517364=TEST_STATUS_DESC_IgniteTests24Java8=%3Cdefault%3E=10
> Typical output:
> {noformat}
> junit.framework.AssertionFailedError: expected: org.apache.ignite.internal.processors.datastructures.GridCacheSetProxy> but
> was: org.apache.ignite.internal.processors.datastructures.GridCacheAtomicStampedImpl>
> at
> org.apache.ignite.internal.processors.cache.datastructures.IgniteDataStructureUniqueNameTest.testUniqueName(IgniteDataStructureUniqueNameTest.java:385)
> at
> org.apache.ignite.internal.processors.cache.datastructures.IgniteDataStructureUniqueNameTest.testUniqueNameMultithreaded(IgniteDataStructureUniqueNameTest.java:85)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8073) Cache read metric is calculated incorrectly in atomic cache.
[ https://issues.apache.org/jira/browse/IGNITE-8073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507066#comment-16507066 ] ASF GitHub Bot commented on IGNITE-8073: GitHub user voipp opened a pull request: https://github.com/apache/ignite/pull/4174 IGNITE-8073 Cache read metric is calculated incorrectly in atomic cache. You can merge this pull request into a Git repository by running: $ git pull https://github.com/voipp/ignite IGNITE-8073 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4174.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 #4174 commit e404757231de50e15416dae2f4795e17e1d777c4 Author: voipp Date: 2018-06-09T14:36:11Z #draft > Cache read metric is calculated incorrectly in atomic cache. > > > Key: IGNITE-8073 > URL: https://issues.apache.org/jira/browse/IGNITE-8073 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.6 > > Attachments: GridCacheNearAtomicMetricsSelfTest.java > > > In atomic cache with near enabled we perform put and remove operations. > After it, get operation is called. > Now, cache 'read' metric is calculated incorrectly, because it takes into > account near cache entry. > Reproducer is attached. > Note that remove operation untracks 'reader' node from dht cache entry, but > near cache entry still exists. The following test checks it : > GridCacheAtomicNearCacheSelfTest#checkNearCache, see checkReaderRemove(). > See also > http://apache-ignite-developers.2346864.n4.nabble.com/Near-cache-entry-removal-td28698.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8771) OutOfMemory in Cache2 suite in master branch on TC
Sergey Chugunov created IGNITE-8771: --- Summary: OutOfMemory in Cache2 suite in master branch on TC Key: IGNITE-8771 URL: https://issues.apache.org/jira/browse/IGNITE-8771 Project: Ignite Issue Type: Bug Reporter: Sergey Chugunov Fix For: 2.6 OutOfMemory error happened in Cache2 suite for the first time in a while: [https://ci.ignite.apache.org/viewLog.html?buildId=1372380=buildResultsDiv=IgniteTests24Java8_Cache2] Recent history doesn't contain any OOMs or execution timeouts for this suite: [TC link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache2_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8750) IgniteWalFlushDefaultSelfTest.testFailAfterStart fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-8750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-8750:
---
Priority: Major (was: Minor)
> IgniteWalFlushDefaultSelfTest.testFailAfterStart fails on TC
>
>
> Key: IGNITE-8750
> URL: https://issues.apache.org/jira/browse/IGNITE-8750
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> {noformat}
> org.apache.ignite.IgniteException: Failed to get object field
> [obj=GridCacheSharedManagerAdapter [starting=true, stop=false],
> fieldNames=[mmap]]
> Caused by: java.lang.NoSuchFieldException: mmap
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8770) OutOfMemory in Queries1 suite in master branch on TC
Sergey Chugunov created IGNITE-8770: --- Summary: OutOfMemory in Queries1 suite in master branch on TC Key: IGNITE-8770 URL: https://issues.apache.org/jira/browse/IGNITE-8770 Project: Ignite Issue Type: Bug Environment: OutOfMemory happened for the first time in a while for this suite: [TC link|https://ci.ignite.apache.org/viewLog.html?buildId=1372426=buildResultsDiv=IgniteTests24Java8_Queries1] No execution timeouts or OOM errors in recent history: [TC link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Queries1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv] Reporter: Sergey Chugunov Fix For: 2.6 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8748) All FileIO#write methods should return number of written bytes
[ https://issues.apache.org/jira/browse/IGNITE-8748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507047#comment-16507047 ] Alexey Stelmak commented on IGNITE-8748: https://github.com/apache/ignite/pull/4170 > All FileIO#write methods should return number of written bytes > -- > > Key: IGNITE-8748 > URL: https://issues.apache.org/jira/browse/IGNITE-8748 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Assignee: Alexey Stelmak >Priority: Major > Fix For: 2.6 > > > FileIO#write(byte[], int, int) doesn't return a value of written bytes which > makes it impossible for callers to detect a situation of no space left on > device. > API should be changed to return written bytes, all callers of this method > should adopt changes to be ready to detect "no space left" situation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8748) All FileIO#write methods should return number of written bytes
[ https://issues.apache.org/jira/browse/IGNITE-8748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507047#comment-16507047 ] Alexey Stelmak edited comment on IGNITE-8748 at 6/9/18 3:40 PM: PR: [https://github.com/apache/ignite/pull/4170] was (Author: astelmak): https://github.com/apache/ignite/pull/4170 > All FileIO#write methods should return number of written bytes > -- > > Key: IGNITE-8748 > URL: https://issues.apache.org/jira/browse/IGNITE-8748 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Assignee: Alexey Stelmak >Priority: Major > Fix For: 2.6 > > > FileIO#write(byte[], int, int) doesn't return a value of written bytes which > makes it impossible for callers to detect a situation of no space left on > device. > API should be changed to return written bytes, all callers of this method > should adopt changes to be ready to detect "no space left" situation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8562) Turn system-critical Ignite threads into GridWorkers
[
https://issues.apache.org/jira/browse/IGNITE-8562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507043#comment-16507043
]
ASF GitHub Bot commented on IGNITE-8562:
GitHub user andrey-kuznetsov opened a pull request:
https://github.com/apache/ignite/pull/4173
IGNITE-8562: As single large commit.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/andrey-kuznetsov/ignite ignite-8562-2
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4173.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 #4173
commit 1d8b7ce77fb2b5adb1f7a5e8e0ec85ec9c9c9e13
Author: Andrey Kuznetsov
Date: 2018-06-09T15:34:48Z
IGNITE-8562: As single large commit.
> Turn system-critical Ignite threads into GridWorkers
>
>
> Key: IGNITE-8562
> URL: https://issues.apache.org/jira/browse/IGNITE-8562
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.6
>
>
> The goal of the change is to make system-critical threads (in terms of
> IEP-14, [1]) available to {{WorkersControlMXBean}}.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8683) Tests fail after IGNITE-6639
[ https://issues.apache.org/jira/browse/IGNITE-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507035#comment-16507035 ] Dmitriy Pavlov commented on IGNITE-8683: [~mcherkasov], could you also share TC run? > Tests fail after IGNITE-6639 > > > Key: IGNITE-8683 > URL: https://issues.apache.org/jira/browse/IGNITE-8683 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > > Example of failed tests: > org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeSelfTest#testDeployOnEachNodeButClientUpdateTopology > > instead of checking address for loopback we should compare addr with locHost, > because nodes can use the same port, but different local address and both > addresses can be loopback. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8764) Informatica can not connect to a cluster using ODBC driver on Windows
[ https://issues.apache.org/jira/browse/IGNITE-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507031#comment-16507031 ] ASF GitHub Bot commented on IGNITE-8764: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4168 > Informatica can not connect to a cluster using ODBC driver on Windows > - > > Key: IGNITE-8764 > URL: https://issues.apache.org/jira/browse/IGNITE-8764 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.5 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: odbc > Fix For: 2.6 > > > It crashes or returns garbage on attempt to connect to a server node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8764) Informatica can not connect to a cluster using ODBC driver on Windows
[ https://issues.apache.org/jira/browse/IGNITE-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507028#comment-16507028 ] Sergey Kalashnikov commented on IGNITE-8764: [~isapego], I'm OK with the changes. > Informatica can not connect to a cluster using ODBC driver on Windows > - > > Key: IGNITE-8764 > URL: https://issues.apache.org/jira/browse/IGNITE-8764 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.5 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: odbc > Fix For: 2.6 > > > It crashes or returns garbage on attempt to connect to a server node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8769) JVM crash in Basic1 suite in master branch on TC
Sergey Chugunov created IGNITE-8769: --- Summary: JVM crash in Basic1 suite in master branch on TC Key: IGNITE-8769 URL: https://issues.apache.org/jira/browse/IGNITE-8769 Project: Ignite Issue Type: Bug Reporter: Sergey Chugunov Fix For: 2.6 Latest build with crash: [TC link|https://ci.ignite.apache.org/viewLog.html?buildId=1373991=buildResultsDiv=IgniteTests24Java8_Basic1] There is another crash in the history: [TC link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Basic1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8768) JVM crash in PDS1 suite in master branch
[ https://issues.apache.org/jira/browse/IGNITE-8768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-8768: Component/s: persistence > JVM crash in PDS1 suite in master branch > > > Key: IGNITE-8768 > URL: https://issues.apache.org/jira/browse/IGNITE-8768 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Sergey Chugunov >Priority: Blocker > Labels: MakeTeamcityGreenAgain > Fix For: 2.6 > > > JVM crash in latest build: [TC > link|https://ci.ignite.apache.org/viewLog.html?buildId=1372456=buildResultsDiv=IgniteTests24Java8_Pds1] > It is the first crash is latest 15 builds: [TC > link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Pds1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8768) JVM crash in PDS1 suite in master branch
Sergey Chugunov created IGNITE-8768: --- Summary: JVM crash in PDS1 suite in master branch Key: IGNITE-8768 URL: https://issues.apache.org/jira/browse/IGNITE-8768 Project: Ignite Issue Type: Bug Reporter: Sergey Chugunov Fix For: 2.6 JVM crash in latest build: [TC link|https://ci.ignite.apache.org/viewLog.html?buildId=1372456=buildResultsDiv=IgniteTests24Java8_Pds1] It is the first crash is latest 15 builds: [TC link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Pds1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8767) JavaClient test suite times out in master branch
Sergey Chugunov created IGNITE-8767: --- Summary: JavaClient test suite times out in master branch Key: IGNITE-8767 URL: https://issues.apache.org/jira/browse/IGNITE-8767 Project: Ignite Issue Type: Bug Components: clients Reporter: Sergey Chugunov Fix For: 2.6 Latest execution timeout: [link to TC|https://ci.ignite.apache.org/viewLog.html?buildId=1372416=buildResultsDiv=IgniteTests24Java8_JavaClient] Suite hangs regularly in master branch: [link to TC|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_JavaClient_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv] Looks like culprit test is JettyRestProcessorAuthenticationWithCredsSelfTest.testDeactivateActivate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8645) CacheMetrics.getCacheTxCommits() doesn't include transactions started on client node
[ https://issues.apache.org/jira/browse/IGNITE-8645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507022#comment-16507022 ] Ryabov Dmitrii commented on IGNITE-8645: Looks good. > CacheMetrics.getCacheTxCommits() doesn't include transactions started on > client node > > > Key: IGNITE-8645 > URL: https://issues.apache.org/jira/browse/IGNITE-8645 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Roman Guseinov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.6 > > Attachments: CacheTxCommitsMetricTest.java > > > The test is attached [^CacheTxCommitsMetricTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8384) SQL: Secondary indexes should sort entries by links rather than keys
[
https://issues.apache.org/jira/browse/IGNITE-8384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507019#comment-16507019
]
Vladimir Ozerov commented on IGNITE-8384:
-
New test run: https://ci.ignite.apache.org/viewQueued.html?itemId=1374871
> SQL: Secondary indexes should sort entries by links rather than keys
>
>
> Key: IGNITE-8384
> URL: https://issues.apache.org/jira/browse/IGNITE-8384
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Labels: iep-19, performance
> Fix For: 2.6
>
>
> Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The
> key itself is not stored in the index in general case. It means that we need
> to perform a lookup to data page to find correct insertion point for index
> entry.
> This could be fixed easily by sorting entries a bit differently - {{idx_cols,
> link}}. This is all we need.
> UPD: If we have an affinity keys, then affinity column will be added to
> secondary index as well.
> So, we'll have secondary index as {{(idx_cols, KEY, AFF_COL)}}
> Comparison occur here:
> {{org.apache.ignite.internal.processors.query.h2.database.H2Tree#compare}}
> What we need is to avoid adding PK and affinity key columns to every
> secondary index and compare links instead in this method.
> Probably we need to preserve old behavior for compatibility purposes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8766) TcpDiscoverySpi: discovery threads naming
Sergey Chugunov created IGNITE-8766: --- Summary: TcpDiscoverySpi: discovery threads naming Key: IGNITE-8766 URL: https://issues.apache.org/jira/browse/IGNITE-8766 Project: Ignite Issue Type: Improvement Components: general Reporter: Sergey Chugunov Including information about next/prev nodes into names of discovery-related threads could be very helpful when investigating situations of network glitches. tcp-disco-sock-reader and tcp-disco-msg-worker threads must include such information in their names. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6055) SQL: Add String length constraint
[
https://issues.apache.org/jira/browse/IGNITE-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507005#comment-16507005
]
Nikolay Izhikov commented on IGNITE-6055:
-
[~vozerov] I don't get it.
Can you name the ticket I should wait for?
How my PR depends on it?
I think my PR is correct and solves the ticket. Isn't it?
> SQL: Add String length constraint
> -
>
> Key: IGNITE-6055
> URL: https://issues.apache.org/jira/browse/IGNITE-6055
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: sql-engine
>
> We should support {{CHAR(X)}} and {{VARCHAR{X}} syntax. Currently, we ignore
> it. First, it affects semantics. E.g., one can insert a string with greater
> length into a cache/table without any problems. Second, it limits efficiency
> of our default configuration. E.g., index inline cannot be applied to
> {{String}} data type as we cannot guess it's length.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8751) Possible race on node segmentation.
[ https://issues.apache.org/jira/browse/IGNITE-8751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507004#comment-16507004 ] ASF GitHub Bot commented on IGNITE-8751: GitHub user agura opened a pull request: https://github.com/apache/ignite/pull/4171 IGNITE-8751 Failure handler accordingly to segmentation policy should be invoked on node segmentation instead of configured failure handler … be invoked on node segmentation instead of configured failure handler You can merge this pull request into a Git repository by running: $ git pull https://github.com/agura/incubator-ignite ignite-8751 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4171.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 #4171 commit 56f02086cdabe05af5001fb228406935ca000994 Author: Andrey Gura Date: 2018-06-09T13:37:49Z IGNITE-8751 Failure handler accordingly to segmentation policy should be invoked on node segmentation instead of configured failure handler > Possible race on node segmentation. > --- > > Key: IGNITE-8751 > URL: https://issues.apache.org/jira/browse/IGNITE-8751 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrew Mashenkov >Assignee: Andrey Gura >Priority: Major > Fix For: 2.6 > > > Segmentation policy may be ignored, probably, due to a race. > See [1] for details. > [1] > [http://apache-ignite-users.70518.x6.nabble.com/Node-pause-for-no-obvious-reason-td21923.html] > Logs from segmented node. > [08:42:42,290][INFO][tcp-disco-sock-reader-#15][TcpDiscoverySpi] Finished > serving remote node connection [rmtAddr=/10.29.42.45:38712, rmtPort=38712 > [08:42:42,290][WARNING][disco-event-worker-#161][GridDiscoveryManager] Local > node SEGMENTED: TcpDiscoveryNode [id=8333aa56-8bf4-4558-a387-809b1d2e2e5b, > addrs=[10.29.42.44, 127.0.0.1], sockAddrs=[sap-datanode1/10.29.42.44:49500, > /127.0.0.1:49500], discPort=49500, order=1, intOrder=1, > lastExchangeTime=1528447362286, loc=true, ver=2.5.0#20180523-sha1:86e110c7, > isClient=false] > [08:42:42,294][SEVERE][tcp-disco-srvr-#2][] Critical system error detected. > Will be handled accordingly to configured handler [hnd=class > o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext > [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread > tcp-disco-srvr-#2 is terminated unexpectedly.]] > java.lang.IllegalStateException: Thread tcp-disco-srvr-#2 is terminated > unexpectedly. > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$TcpServer.body(ServerImpl.java:5686) > > at > org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [08:42:42,294][SEVERE][tcp-disco-srvr-#2][] JVM will be halted immediately > due to the failure: [failureCtx=FailureContext > [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread > tcp-disco-srvr-#2 is terminated unexpectedly.]] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6055) SQL: Add String length constraint
[
https://issues.apache.org/jira/browse/IGNITE-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506995#comment-16506995
]
Nikolay Izhikov commented on IGNITE-6055:
-
[~vozerov]
> it is illegal to replace 2.5.0 version with 2.6.0
Fixed.
> SQL: Add String length constraint
> -
>
> Key: IGNITE-6055
> URL: https://issues.apache.org/jira/browse/IGNITE-6055
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: sql-engine
>
> We should support {{CHAR(X)}} and {{VARCHAR{X}} syntax. Currently, we ignore
> it. First, it affects semantics. E.g., one can insert a string with greater
> length into a cache/table without any problems. Second, it limits efficiency
> of our default configuration. E.g., index inline cannot be applied to
> {{String}} data type as we cannot guess it's length.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-1260) S3 IP finder should have an option to use a subfolder instead of bucket root
[ https://issues.apache.org/jira/browse/IGNITE-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506981#comment-16506981 ] Uday Kale commented on IGNITE-1260: --- Test for this task is failing in TC. I have noticed that other tests in the suite are failing but muted. The failure is same for all test: "java.lang.AssertionError: Environment variable 'test.amazon.access.key' is not set" including mine. The comments link the issue to [IGNITE-5495|https://issues.apache.org/jira/browse/IGNITE-5495]. So I will have to mute my test too? [~ntikho...@apache.org] can you please help here? > S3 IP finder should have an option to use a subfolder instead of bucket root > > > Key: IGNITE-1260 > URL: https://issues.apache.org/jira/browse/IGNITE-1260 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.1.4 >Reporter: Valentin Kulichenko >Priority: Minor > Labels: newbie, usability, user-request > > Current implementation forces user to use the bucket root which is not always > possible. Need to provide a configuration parameter that allows to provide a > path in addition to the bucket name. > Corresponding user@ thread: > http://apache-ignite-users.70518.x6.nabble.com/AWS-Integration-td495.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6991) SharedDeploymentTest.testDeploymentFromSecondAndThird Test fails in 100 percentage cases
[
https://issues.apache.org/jira/browse/IGNITE-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ivanov closed IGNITE-6991.
> SharedDeploymentTest.testDeploymentFromSecondAndThird Test fails in 100
> percentage cases
>
>
> Key: IGNITE-6991
> URL: https://issues.apache.org/jira/browse/IGNITE-6991
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Peter Ivanov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> {noformat}
> java.lang.ClassNotFoundException:
> org.apache.ignite.tests.p2p.compute.ExternalCallable2
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at
> org.apache.ignite.testframework.GridTestExternalClassLoader.findClass(GridTestExternalClassLoader.java:143)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at
> org.apache.ignite.testframework.GridTestExternalClassLoader.loadClass(GridTestExternalClassLoader.java:152)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at
> org.apache.ignite.p2p.SharedDeploymentTest.runJob2(SharedDeploymentTest.java:124)
> at
> org.apache.ignite.p2p.SharedDeploymentTest.testDeploymentFromSecondAndThird(SharedDeploymentTest.java:82)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense
[ https://issues.apache.org/jira/browse/IGNITE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506977#comment-16506977 ] Vyacheslav Daradur commented on IGNITE-5097: Moved status to "Open", because we are waiting for a contributor who is able to implement CPP part. > BinaryMarshaller should write ints in "varint" encoding where it makes sense > > > Key: IGNITE-5097 > URL: https://issues.apache.org/jira/browse/IGNITE-5097 > Project: Ignite > Issue Type: Task > Components: binary >Affects Versions: 2.0 >Reporter: Vladimir Ozerov >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-2, performance > Fix For: 2.6 > > > There are a lot of places in the code where we write integers for some > special purposes. Quite often their value will be vary small, so that > applying "varint" format could save a lot of space at the cost of very low > additional CPU overhead. > Specifically: > 1) Array/collection/map lengths > 2) BigDecimal's (usually will save ~6 bytes) > 3) Strings > 4) Enum ordinals -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur reassigned IGNITE-8131:
--
Assignee: Denis Garus (was: Vyacheslav Daradur)
> ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
>
>
> Key: IGNITE-8131
> URL: https://issues.apache.org/jira/browse/IGNITE-8131
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Two tests always fail on TC with the assertion
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
> {noformat}
> from client disconnect/reconnect events check. Obviously client doesn't
> generate these events as it supposed to do.
> (TC runs can be found
> [here|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteZooKeeperDiscovery_IgniteTests24Java8=pull%2F3730%2Fhead=buildTypeStatusDiv]).
> It is possible to reproduce test failure locally as well, but with low
> probability: one failure for 50 or even 300 successful executions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur reassigned IGNITE-8131:
--
Assignee: Vyacheslav Daradur (was: Denis Garus)
> ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
>
>
> Key: IGNITE-8131
> URL: https://issues.apache.org/jira/browse/IGNITE-8131
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Two tests always fail on TC with the assertion
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
> {noformat}
> from client disconnect/reconnect events check. Obviously client doesn't
> generate these events as it supposed to do.
> (TC runs can be found
> [here|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteZooKeeperDiscovery_IgniteTests24Java8=pull%2F3730%2Fhead=buildTypeStatusDiv]).
> It is possible to reproduce test failure locally as well, but with low
> probability: one failure for 50 or even 300 successful executions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-8131:
---
Fix Version/s: 2.6
> ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
>
>
> Key: IGNITE-8131
> URL: https://issues.apache.org/jira/browse/IGNITE-8131
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Two tests always fail on TC with the assertion
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
> {noformat}
> from client disconnect/reconnect events check. Obviously client doesn't
> generate these events as it supposed to do.
> (TC runs can be found
> [here|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteZooKeeperDiscovery_IgniteTests24Java8=pull%2F3730%2Fhead=buildTypeStatusDiv]).
> It is possible to reproduce test failure locally as well, but with low
> probability: one failure for 50 or even 300 successful executions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506969#comment-16506969
]
Denis Garus edited comment on IGNITE-8131 at 6/9/18 1:01 PM:
-
[~sergey-chugunov],
I deleted a fail line in tests and ran TC. Everything seems to be OK.
Should we close this ticket?
Test history:
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1700882236921635901=testDetails
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1337433329747388373=testDetails
was (Author: garus.d.g):
[~sergey-chugunov],
I deleted a fail line in tests and ran TC. Everything seems to be OK.
Should we close this ticket?
Test history:
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1700882236921635901=testDetails
> ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
>
>
> Key: IGNITE-8131
> URL: https://issues.apache.org/jira/browse/IGNITE-8131
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Two tests always fail on TC with the assertion
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
> {noformat}
> from client disconnect/reconnect events check. Obviously client doesn't
> generate these events as it supposed to do.
> (TC runs can be found
> [here|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteZooKeeperDiscovery_IgniteTests24Java8=pull%2F3730%2Fhead=buildTypeStatusDiv]).
> It is possible to reproduce test failure locally as well, but with low
> probability: one failure for 50 or even 300 successful executions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506969#comment-16506969
]
Denis Garus commented on IGNITE-8131:
-
[~sergey-chugunov],
I deleted a fail line in tests and ran TC. Everything seems to be OK.
Should we close this ticket?
Test history:
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1700882236921635901=testDetails
> ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
>
>
> Key: IGNITE-8131
> URL: https://issues.apache.org/jira/browse/IGNITE-8131
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Two tests always fail on TC with the assertion
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
> {noformat}
> from client disconnect/reconnect events check. Obviously client doesn't
> generate these events as it supposed to do.
> (TC runs can be found
> [here|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteZooKeeperDiscovery_IgniteTests24Java8=pull%2F3730%2Fhead=buildTypeStatusDiv]).
> It is possible to reproduce test failure locally as well, but with low
> probability: one failure for 50 or even 300 successful executions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8286) ScanQuery ignore setLocal with non local partition
[ https://issues.apache.org/jira/browse/IGNITE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506964#comment-16506964 ] Ilya Lantukh commented on IGNITE-8286: -- Hi [~roman_s], I've reviewed your changes here: https://reviews.ignite.apache.org/ignite/revision/296d1f6e919d1984cedf0f514d43fec5488acdcf. > ScanQuery ignore setLocal with non local partition > -- > > Key: IGNITE-8286 > URL: https://issues.apache.org/jira/browse/IGNITE-8286 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Alexander Belyak >Assignee: Roman Shtykh >Priority: Major > Fix For: 2.6 > > > 1) Create partitioned cache on 2+ nodes cluster > 2) Select some partition N, local node should not be OWNER of partition N > 3) execute: cache.query(new ScanQuery<>().setLocal(true).setPartition(N)) > Expected result: > empty result (probaply with logging smth like "Trying to execute local query > with non local partition N") or even throw exception > Actual result: > executing (with ScanQueryFallbackClosableIterator) query on remote node. > Problem is that we execute local query on remote node. > Same behaviour can be achieved if we get empty node list from > GridCacheQueryAdapter.node() by any reasons, for example - if we run "local" > query from non data node from given cache (see > GridDiscoveryNamager.cacheAffinityNode(ClusterNode node, String cacheName) in > GridcacheQueryAdapter.executeScanQuery() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8752) Deadlock when registering binary metadata while holding topology read lock
[
https://issues.apache.org/jira/browse/IGNITE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506962#comment-16506962
]
Evgenii Zhuravlev commented on IGNITE-8752:
---
Attached reproducer for this issue
> Deadlock when registering binary metadata while holding topology read lock
> --
>
> Key: IGNITE-8752
> URL: https://issues.apache.org/jira/browse/IGNITE-8752
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.6
>
> Attachments: DeadlockTest.java
>
>
> The following deadlock was reproduced on ignite-2.4 version:
> {code}
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:284)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassName(BinaryContext.java:1191)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:773)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:751)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:622)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:251)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:396)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:381)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:875)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheObject(CacheObjectBinaryProcessorImpl.java:825)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.toCacheObject(GridCacheContext.java:1783)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.runEntryProcessor(GridCacheMapEntry.java:5264)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4667)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4484)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3083)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$6200(BPlusTree.java:2977)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1732)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1610)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1270)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1769)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2420)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1883)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1736)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
>
[jira] [Updated] (IGNITE-8752) Deadlock when registering binary metadata while holding topology read lock
[
https://issues.apache.org/jira/browse/IGNITE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev updated IGNITE-8752:
--
Attachment: DeadlockTest.java
> Deadlock when registering binary metadata while holding topology read lock
> --
>
> Key: IGNITE-8752
> URL: https://issues.apache.org/jira/browse/IGNITE-8752
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.6
>
> Attachments: DeadlockTest.java
>
>
> The following deadlock was reproduced on ignite-2.4 version:
> {code}
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:284)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassName(BinaryContext.java:1191)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:773)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:751)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:622)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:251)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:396)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:381)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:875)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheObject(CacheObjectBinaryProcessorImpl.java:825)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.toCacheObject(GridCacheContext.java:1783)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.runEntryProcessor(GridCacheMapEntry.java:5264)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4667)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4484)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3083)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$6200(BPlusTree.java:2977)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1732)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1610)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1270)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1769)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2420)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1883)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1736)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> at
>
[jira] [Issue Comment Deleted] (IGNITE-8748) All FileIO#write methods should return number of written bytes
[ https://issues.apache.org/jira/browse/IGNITE-8748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Stelmak updated IGNITE-8748: --- Comment: was deleted (was: PR: https://github.com/apache/ignite/pull/4170) > All FileIO#write methods should return number of written bytes > -- > > Key: IGNITE-8748 > URL: https://issues.apache.org/jira/browse/IGNITE-8748 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Assignee: Alexey Stelmak >Priority: Major > Fix For: 2.6 > > > FileIO#write(byte[], int, int) doesn't return a value of written bytes which > makes it impossible for callers to detect a situation of no space left on > device. > API should be changed to return written bytes, all callers of this method > should adopt changes to be ready to detect "no space left" situation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8748) All FileIO#write methods should return number of written bytes
[ https://issues.apache.org/jira/browse/IGNITE-8748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506960#comment-16506960 ] Alexey Stelmak commented on IGNITE-8748: PR: https://github.com/apache/ignite/pull/4170 > All FileIO#write methods should return number of written bytes > -- > > Key: IGNITE-8748 > URL: https://issues.apache.org/jira/browse/IGNITE-8748 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Assignee: Alexey Stelmak >Priority: Major > Fix For: 2.6 > > > FileIO#write(byte[], int, int) doesn't return a value of written bytes which > makes it impossible for callers to detect a situation of no space left on > device. > API should be changed to return written bytes, all callers of this method > should adopt changes to be ready to detect "no space left" situation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8765) SQL event is not fired when query is reduced to local form
Vladimir Ozerov created IGNITE-8765:
---
Summary: SQL event is not fired when query is reduced to local form
Key: IGNITE-8765
URL: https://issues.apache.org/jira/browse/IGNITE-8765
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.5, 2.4
Reporter: Vladimir Ozerov
*Reproducer*
{{org.apache.ignite.internal.processors.cache.IgniteCacheAbstractQuerySelfTest#testSqlQueryEvents}}
*Root Cause*
Local and non-local query execution is performed differently. Local query is
logged early. However, non-local query could be reduced after that. As a
result, event is missed. Try change
{{org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser#isLocalQuery}}
method to always return {{false}} and then re-run failed test to see the
difference.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8763) java.nio.file.AccessDeniedException is not handled with default failure handler
[
https://issues.apache.org/jira/browse/IGNITE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-8763:
-
Assignee: Aleksey Plekhanov
> java.nio.file.AccessDeniedException is not handled with default failure
> handler
> ---
>
> Key: IGNITE-8763
> URL: https://issues.apache.org/jira/browse/IGNITE-8763
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Andrey Gura
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.6
>
>
> java.nio.file.AccessDeniedException is not handled with default failure
> handler
> 1. Start cluster(4 nodes).
> 2. Upload some data.
> 3. Make files in metastore read only.
> 4. Deactivate grid.
> 5. Activate grid.
> On this step I see java.nio.file.AccessDeniedException:
> {noformat}
> [17:55:40,035][INFO][exchange-worker-#62][GridCacheDatabaseSharedManager]
> Read checkpoint status
> [startMarker=/storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/cp/1526568907638-46128a87-562a-45fc-8d73-75ccb1490d63-START.bin,
>
> endMarker=/storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/cp/1526568907638-46128a87-562a-45fc-8d73-75ccb1490d63-END.bin]
> [17:55:40,037][SEVERE][exchange-worker-#62][GridDhtPartitionsExchangeFuture]
> Failed to activate node components
> [nodeId=bd7115d5-1f95-4673-9f40-47056b0b1a58, client=false,
> topVer=AffinityTopologyVersion [topVer=4, minorTopVer=5]]
> class org.apache.ignite.IgniteCheckedException: Error while creating file
> page store
> [file=/storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/metastorage/part-0.bin]:
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FileVersionCheckingFactory.createPageStore(FileVersionCheckingFactory.java:98)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.initDir(FilePageStoreManager.java:463)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.initializeForMetastorage(FilePageStoreManager.java:234)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:743)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:896)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:643)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.file.AccessDeniedException:
> /storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/metastorage/part-0.bin
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileSystemProvider.newAsynchronousFileChannel(UnixFileSystemProvider.java:196)
> at
> java.nio.channels.AsynchronousFileChannel.open(AsynchronousFileChannel.java:248)
> at
> java.nio.channels.AsynchronousFileChannel.open(AsynchronousFileChannel.java:301)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.(AsyncFileIO.java:57)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIOFactory.create(AsyncFileIOFactory.java:53)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIOFactory.create(AsyncFileIOFactory.java:41)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FileVersionCheckingFactory.createPageStore(FileVersionCheckingFactory.java:78)
> ... 9 more
> {noformat}
> Situation led to NPE exception after AccessDeniedException looks like this:
> 1. AccessDeniedException was thrown in ExchangeFuture right before affinity
> initialization so affinity was never initialized.
> 2. After that node receives PartitionSingleMessage and tries to access
> affinity information. Null is returned because of
[jira] [Assigned] (IGNITE-8352) IgniteStandByClusterSuite: IgniteClusterActivateDeactivateTest.testClientReconnectClusterDeactivateInProgress flaky fail rate 12%
[ https://issues.apache.org/jira/browse/IGNITE-8352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov reassigned IGNITE-8352: --- Assignee: (was: Maxim Muzafarov) > IgniteStandByClusterSuite: > IgniteClusterActivateDeactivateTest.testClientReconnectClusterDeactivateInProgress > flaky fail rate 12% > - > > Key: IGNITE-8352 > URL: https://issues.apache.org/jira/browse/IGNITE-8352 > Project: Ignite > Issue Type: Test >Reporter: Maxim Muzafarov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.6 > > > IgniteStandByClusterSuite: > IgniteClusterActivateDeactivateTest.testClientReconnectClusterDeactivateInProgress > (master fail rate 12,8%) > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5210129488604303757=%3Cdefault%3E=testDetails] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IGNITE-8671) Provide instructions on running Apache Ignite as systemd service on Windows 10 WSL Ubuntu
[ https://issues.apache.org/jira/browse/IGNITE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reopened IGNITE-8671: -- > Provide instructions on running Apache Ignite as systemd service on Windows > 10 WSL Ubuntu > - > > Key: IGNITE-8671 > URL: https://issues.apache.org/jira/browse/IGNITE-8671 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Blocker > Fix For: 2.6 > > > Prepare instructions (and possibly update official documentation) on running > Apache Ignite as systemd service on Windows 10 WSL Ubuntu using official DEB > package. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7618) validateCache synchronously waits for state change
[
https://issues.apache.org/jira/browse/IGNITE-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506923#comment-16506923
]
Ryabov Dmitrii commented on IGNITE-7618:
[~agoncharuk], I investigated issue a bit more. In current implementation
{{ExchangeActions}} doesn't have cluster state, only state changing.
But the main problem is that cache gets last finished future, which can be not
actual, so the future must check real state in state processor.
If we will save state to the future, then bad situation is possible: in
sequence deactivation-activation-operation deactivation future can be finished,
activation future not finished, but user already started operation. Like in
{{IgniteStandByClusterTest#testSimple()}} test.
In this situation valid operation will see future containing deactivated state,
so operation will fail.
I can't reproduce situation from description, so could you please share your
reproducer, if you have one? Because without reproducer this ticket is about
serious refactoring, which isn't acceptable in most cases by community.
> validateCache synchronously waits for state change
> --
>
> Key: IGNITE-7618
> URL: https://issues.apache.org/jira/browse/IGNITE-7618
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.6
>
>
> Currently, we call publicApiActiveState(waitForTransition=true) in
> GridDhtTopologyFutureAdapter#validateCache. This is incorrect, because the
> cluster state is updated from discovery thread, and mapping may be happening
> on a previous topology version. We must capture the cluster active state flag
> to the exchange future (I believe we already have all the mechanics for this
> in ExchangeActions class) and validate the state in the exchange future
> itself, without touching ClusterStateProcessor.
> Below is an example of a deadlock happened because of synchronous wait:
> {code}
> "db-checkpoint-thread-#12318%database.IgniteDbBaselineTopologySelfTest0%"
> #15498 prio=5 os_prio=0 tid=0x7fa173e80800 nid=0x3d08 waiting on
> condition [0x7fa2069a8000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007abfc16e8> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> 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.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:2991)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:2797)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2722)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> "snapshot-scheduler-restats-#12202%database.IgniteDbBaselineTopologySelfTest0%"
> #15332 prio=5 os_prio=0 tid=0x7fa228143000 nid=0x3c65 waiting on
> condition [0x7fa2be919000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.publicApiActiveState(GridClusterStateProcessor.java:194)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:83)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.mapOnTopology(GridDhtColocatedLockFuture.java:787)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.map(GridDhtColocatedLockFuture.java:763)
> at
>
[jira] [Commented] (IGNITE-8764) Informatica can not connect to a cluster using ODBC driver on Windows
[ https://issues.apache.org/jira/browse/IGNITE-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506917#comment-16506917 ] ASF GitHub Bot commented on IGNITE-8764: GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/4168 IGNITE-8764: Fixed issue with Informatica on Windows You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8764 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4168.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 #4168 commit abd7d59fb02b4a3346999bd7efea9d5568831808 Author: Igor Sapego Date: 2018-06-09T11:17:59Z IGNITE-8764: Fixed issue with Informatica on Windows > Informatica can not connect to a cluster using ODBC driver on Windows > - > > Key: IGNITE-8764 > URL: https://issues.apache.org/jira/browse/IGNITE-8764 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.5 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: odbc > Fix For: 2.6 > > > It crashes or returns garbage on attempt to connect to a server node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8764) Informatica can not connect to a cluster using ODBC driver on Windows
Igor Sapego created IGNITE-8764: --- Summary: Informatica can not connect to a cluster using ODBC driver on Windows Key: IGNITE-8764 URL: https://issues.apache.org/jira/browse/IGNITE-8764 Project: Ignite Issue Type: Bug Components: odbc Affects Versions: 2.5 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.6 It crashes or returns garbage on attempt to connect to a server node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8702) Crash in ODBC driver under Informatica connection checker on Linux
[
https://issues.apache.org/jira/browse/IGNITE-8702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-8702:
Summary: Crash in ODBC driver under Informatica connection checker on Linux
(was: Crash in ODBC driver under Informatica connection checker)
> Crash in ODBC driver under Informatica connection checker on Linux
> --
>
> Key: IGNITE-8702
> URL: https://issues.apache.org/jira/browse/IGNITE-8702
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.6
>
>
> I'm trying to connect Informatica to Ignite via ODBC.
> When I try to specify my connection as a ready-made DSN by its name, it
> starts connecting to remote but then fails:
> {code}
> [ikasnacheev@lab15 ODBC7.1]$ IGNITE_ODBC_LOG_PATH=/home/ikasnacheev/odbc2.log
> INFA_HOME=/storage/ssd/ikasnacheev
> LD_LIBRARY_PATH=/storage/ssd/ikasnacheev/ODBC7.1/lib:$LD_LIBRARY_PATH:/storage/ssd/ikasnacheev/services/shared/bin
> /storage/ssd/ikasnacheev/java/jre/bin/java -d64 -DpwdDecrypt=true
> -DconnectionName=Lab -DuserName=lab -Dpassword="nq/Jypc7Q2EhoQ2iAQlOCA=="
> -DconnectionString=LABignite -DdataStoreType=ODBC
> -DINFA_HOME=/storage/ssd/ikasnacheev -classpath
> '.:/storage/ssd/ikasnacheev/services/AdministratorConsole/webapps/administrator/WEB-INF/lib/*:/storage/ssd/ikasnacheev/services/shared/jars/platform/*:/storage/ssd/ikasnacheev/services/shared/jars/thirdparty/*:/storage/ssd/ikasnacheev/plugins/osgi/*:/storage/ssd/ikasnacheev/plugins/infa/*:/storage/ssd/ikasnacheev/plugins/dynamic/*'
> com.informatica.adminconsole.app.chain.commands.TestODBCConnection
> ...
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x7faeb806d5e4, pid=26471, tid=140392269498112
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_77-b03) (build
> 1.8.0_77-b03)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.77-b03 mixed mode
> linux-amd64 compressed oops)
> # Problematic frame:
> # C [libignite-odbc.so+0x2c5e4]
> ignite::odbc::system::TcpSocketClient::Connect(char const*, unsigned short,
> int, ignite::odbc::diagnostic::Diagnosable&)+0x7b4
> {code}
> The contents of Ignite driver log file as follows:
> {code}
> SQLAllocEnv: SQLAllocEnv called
> SQLSetEnvAttr: SQLSetEnvAttr called
> AddStatusRecord: Adding new record: ODBC version is not supported., rowNum:
> 0, columnNum: 0
> SQLAllocConnect: SQLAllocConnect called
> SQLGetInfo: SQLGetInfo called: 77 (SQL_DRIVER_ODBC_VER), 7faec08d1450, 6,
> 7faf9f5a29ee
> GetInfo: SQLGetInfo called: 77 (SQL_DRIVER_ODBC_VER), 7faec08d1450, 6,
> 7faf9f5a29ee
> SQLSetConnectOption: SQLSetConnectOption called
> SQLConnect: SQLConnect called
> SQLConnect: DSN: LABignite
> Connect: Host: 172.25.1.16, port: 10800
> Connect: Addr: 172.25.1.16
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8763) java.nio.file.AccessDeniedException is not handled with default failure handler
Andrey Gura created IGNITE-8763:
---
Summary: java.nio.file.AccessDeniedException is not handled with
default failure handler
Key: IGNITE-8763
URL: https://issues.apache.org/jira/browse/IGNITE-8763
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.5
Reporter: Andrey Gura
Fix For: 2.6
java.nio.file.AccessDeniedException is not handled with default failure handler
1. Start cluster(4 nodes).
2. Upload some data.
3. Make files in metastore read only.
4. Deactivate grid.
5. Activate grid.
On this step I see java.nio.file.AccessDeniedException:
{noformat}
[17:55:40,035][INFO][exchange-worker-#62][GridCacheDatabaseSharedManager] Read
checkpoint status
[startMarker=/storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/cp/1526568907638-46128a87-562a-45fc-8d73-75ccb1490d63-START.bin,
endMarker=/storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/cp/1526568907638-46128a87-562a-45fc-8d73-75ccb1490d63-END.bin]
[17:55:40,037][SEVERE][exchange-worker-#62][GridDhtPartitionsExchangeFuture]
Failed to activate node components
[nodeId=bd7115d5-1f95-4673-9f40-47056b0b1a58, client=false,
topVer=AffinityTopologyVersion [topVer=4, minorTopVer=5]]
class org.apache.ignite.IgniteCheckedException: Error while creating file page
store
[file=/storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/metastorage/part-0.bin]:
at
org.apache.ignite.internal.processors.cache.persistence.file.FileVersionCheckingFactory.createPageStore(FileVersionCheckingFactory.java:98)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.initDir(FilePageStoreManager.java:463)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.initializeForMetastorage(FilePageStoreManager.java:234)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:743)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:896)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:643)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.nio.file.AccessDeniedException:
/storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/metastorage/part-0.bin
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileSystemProvider.newAsynchronousFileChannel(UnixFileSystemProvider.java:196)
at
java.nio.channels.AsynchronousFileChannel.open(AsynchronousFileChannel.java:248)
at
java.nio.channels.AsynchronousFileChannel.open(AsynchronousFileChannel.java:301)
at
org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.(AsyncFileIO.java:57)
at
org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIOFactory.create(AsyncFileIOFactory.java:53)
at
org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIOFactory.create(AsyncFileIOFactory.java:41)
at
org.apache.ignite.internal.processors.cache.persistence.file.FileVersionCheckingFactory.createPageStore(FileVersionCheckingFactory.java:78)
... 9 more
{noformat}
Situation led to NPE exception after AccessDeniedException looks like this:
1. AccessDeniedException was thrown in ExchangeFuture right before affinity
initialization so affinity was never initialized.
2. After that node receives PartitionSingleMessage and tries to access
affinity information. Null is returned because of exception in step #1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8763) java.nio.file.AccessDeniedException is not handled with default failure handler
[
https://issues.apache.org/jira/browse/IGNITE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura updated IGNITE-8763:
Issue Type: Bug (was: Improvement)
> java.nio.file.AccessDeniedException is not handled with default failure
> handler
> ---
>
> Key: IGNITE-8763
> URL: https://issues.apache.org/jira/browse/IGNITE-8763
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Andrey Gura
>Priority: Major
> Fix For: 2.6
>
>
> java.nio.file.AccessDeniedException is not handled with default failure
> handler
> 1. Start cluster(4 nodes).
> 2. Upload some data.
> 3. Make files in metastore read only.
> 4. Deactivate grid.
> 5. Activate grid.
> On this step I see java.nio.file.AccessDeniedException:
> {noformat}
> [17:55:40,035][INFO][exchange-worker-#62][GridCacheDatabaseSharedManager]
> Read checkpoint status
> [startMarker=/storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/cp/1526568907638-46128a87-562a-45fc-8d73-75ccb1490d63-START.bin,
>
> endMarker=/storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/cp/1526568907638-46128a87-562a-45fc-8d73-75ccb1490d63-END.bin]
> [17:55:40,037][SEVERE][exchange-worker-#62][GridDhtPartitionsExchangeFuture]
> Failed to activate node components
> [nodeId=bd7115d5-1f95-4673-9f40-47056b0b1a58, client=false,
> topVer=AffinityTopologyVersion [topVer=4, minorTopVer=5]]
> class org.apache.ignite.IgniteCheckedException: Error while creating file
> page store
> [file=/storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/metastorage/part-0.bin]:
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FileVersionCheckingFactory.createPageStore(FileVersionCheckingFactory.java:98)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.initDir(FilePageStoreManager.java:463)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.initializeForMetastorage(FilePageStoreManager.java:234)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:743)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:896)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:643)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.file.AccessDeniedException:
> /storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/metastorage/part-0.bin
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileSystemProvider.newAsynchronousFileChannel(UnixFileSystemProvider.java:196)
> at
> java.nio.channels.AsynchronousFileChannel.open(AsynchronousFileChannel.java:248)
> at
> java.nio.channels.AsynchronousFileChannel.open(AsynchronousFileChannel.java:301)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.(AsyncFileIO.java:57)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIOFactory.create(AsyncFileIOFactory.java:53)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIOFactory.create(AsyncFileIOFactory.java:41)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FileVersionCheckingFactory.createPageStore(FileVersionCheckingFactory.java:78)
> ... 9 more
> {noformat}
> Situation led to NPE exception after AccessDeniedException looks like this:
> 1. AccessDeniedException was thrown in ExchangeFuture right before affinity
> initialization so affinity was never initialized.
> 2. After that node receives PartitionSingleMessage and tries to access
> affinity information. Null is returned because of exception in step #1.
--
This message was sent by
[jira] [Created] (IGNITE-8762) TcpDiscoverySpi: additional validation on handshake phase
Sergey Chugunov created IGNITE-8762: --- Summary: TcpDiscoverySpi: additional validation on handshake phase Key: IGNITE-8762 URL: https://issues.apache.org/jira/browse/IGNITE-8762 Project: Ignite Issue Type: Improvement Components: general Reporter: Sergey Chugunov Extra information about topology should be added to Handshake phase of establishing discovery connection between two nodes, e.g. info about current coordinator, current topology version, topology hash. Node processing Handshake request will be able to validate this information and make a decision about next steps from printing warning to logs to forcibly stopping other node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5945) Flaky failure in IgniteCache 5: IgniteCacheAtomicProtocolTest.testPutReaderUpdate2
[
https://issues.apache.org/jira/browse/IGNITE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506900#comment-16506900
]
ASF GitHub Bot commented on IGNITE-5945:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/3979
> Flaky failure in IgniteCache 5:
> IgniteCacheAtomicProtocolTest.testPutReaderUpdate2
> --
>
> Key: IGNITE-5945
> URL: https://issues.apache.org/jira/browse/IGNITE-5945
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Alexander Menshikov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest#testPutReaderUpdate2
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertFalse(Assert.java:39)
> at junit.framework.Assert.assertFalse(Assert.java:47)
> at junit.framework.TestCase.assertFalse(TestCase.java:219)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.readerUpdateDhtFails(IgniteCacheAtomicProtocolTest.java:865)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.testPutReaderUpdate2(IgniteCacheAtomicProtocolTest.java:765)
> 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: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:748)
> {noformat}
> Fail is reproducable locally 2 times per 20 runs
> On TeamCity test success rate is 88,2%
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8485) TDE - Phase-1
[ https://issues.apache.org/jira/browse/IGNITE-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506896#comment-16506896 ] ASF GitHub Bot commented on IGNITE-8485: GitHub user nizhikov opened a pull request: https://github.com/apache/ignite/pull/4167 IGNITE-8485: TDE Implementation You can merge this pull request into a Git repository by running: $ git pull https://github.com/nizhikov/ignite IGNITE-8485 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4167.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 #4167 commit 02bf17120260850a51fd707b1c4af0ea029f5947 Author: Nikolay Izhikov Date: 2018-05-04T15:42:15Z First draft of TDE public api commit b8219398ed899859943371499edaf97094b89f07 Author: Nikolay Izhikov Date: 2018-05-17T12:38:34Z Merge branch 'tde-public-api' into IGNITE-8485 commit e3588129374ce382c9e263f9124ac36dc1157e04 Author: Nikolay Izhikov Date: 2018-05-18T11:05:10Z IGNITE-8485: Initial commit. commit bd784bc72a0f6014d96af2ca6ca3ec0871804df9 Author: Nikolay Izhikov Date: 2018-05-23T18:44:54Z Merge branch 'master' into IGNITE-8485 commit 2a4cb3e2d79dbc724afe58fb3d411ea890491c68 Author: Nikolay Izhikov Date: 2018-05-24T07:50:32Z Merge branch 'master' into IGNITE-8485 commit a1eee8cf8bf2a601b5180261e7d8bc64ef994ce6 Author: Nikolay Izhikov Date: 2018-05-24T11:13:41Z IGNITE-6055: Some work done commit 1f11d94ebf608a27e36c5b3ba7869d791363eebe Author: Nikolay Izhikov Date: 2018-05-28T06:59:16Z Merge branch 'master' into IGNITE-8485 commit 5ba1429c8ee8cc18d5e6bbbe1b798564098d9852 Author: Nikolay Izhikov Date: 2018-05-28T12:04:08Z IGNITE-8485: Cipher SPI Default implementation. commit 55e63969472d2c14e67f5f47f2ea4b26245fc0e5 Author: Nikolay Izhikov Date: 2018-05-28T12:14:50Z IGNITE-8485: Cipher SPI Default implementation. commit 54480f6057d1a90cf39dae025c1790a14e2a0100 Author: Nikolay Izhikov Date: 2018-05-28T13:12:52Z Merge branch 'master' into IGNITE-8485 commit 406e9b9f991d25a11050026a82a899dad95a85c7 Author: Nikolay Izhikov Date: 2018-05-28T19:11:26Z IGNITE-8485: Working on cache creation enhancement. commit caa33c72b5ab4bae2a65a030451bdcb40fd64e1e Author: Nikolay Izhikov Date: 2018-05-29T09:38:23Z Merge branch 'master' into IGNITE-8485 commit 76591c66c9ab4424bcf2b3a86bd6b53345352ae6 Author: Nikolay Izhikov Date: 2018-05-29T10:36:31Z IGNITE-8485: Working on cache creation enhancement. commit 48c09d6c861db73ae28d96908a1d2e32ed3fda21 Author: Nikolay Izhikov Date: 2018-05-29T13:49:00Z Merge branch 'master' into IGNITE-8485 commit 0aa270f1f348cb6a1e03c8f6ec1c592e13b08c0f Author: Nikolay Izhikov Date: 2018-05-29T17:28:12Z IGNITE-8485: Working on cache creation enhancement. commit 31552585852b1619c09731492584f592975a6b06 Author: Nikolay Izhikov Date: 2018-05-30T06:10:36Z IGNITE-8485: Working on cache creation enhancement. commit 93ae93035570f99af7342f7e7d335f9dde36825b Author: Nikolay Izhikov Date: 2018-05-30T06:10:50Z Merge branch 'master' of github.com:apache/ignite into IGNITE-8485 commit 030069df12338ad93725f1b92e41b7213896f64f Author: Nikolay Izhikov Date: 2018-05-30T16:35:53Z IGNITE-8485: Cache create implementation. commit bc66683e85dd1156f0945f308bab7c9ef8cf6639 Author: Nikolay Izhikov Date: 2018-05-30T16:42:02Z Merge branch 'master' of github.com:apache/ignite into IGNITE-8485 commit af826e2e4f510a02be642147df56ab167372e126 Author: Nikolay Izhikov Date: 2018-05-31T14:43:34Z IGNITE-8485: Cache create implementation. commit d451d4e46687ac8f1afa08c4b6ac8139fa8a5249 Author: Nikolay Izhikov Date: 2018-05-31T15:02:00Z IGNITE-8485: Cache create implementation. commit 5f49d749a48e814bf5a97371fd261bbdda9498ce Author: Nikolay Izhikov Date: 2018-05-31T15:04:27Z Merge branch 'master' into IGNITE-8485 commit 04613b2dc739ee1b0916e0e97f6bd5131a2c353e Author: Nikolay Izhikov Date: 2018-06-01T10:51:00Z IGNITE-8485: Validation of master key for joining node added. commit c4da23c88f6b84269fa9ae944e4706a716350408 Author: Nikolay Izhikov Date: 2018-06-01T17:21:38Z IGNITE-8485: Cache creation on cluster activation seems to be working. commit 2f58ad4cf0d7c2b64aca6d0050a0107dc823ee4b Author: Nikolay Izhikov Date: 2018-06-01T17:47:25Z Merge branch 'master' into IGNITE-8485 commit 6379fcf11803c6574349665365edeae7b20ffa7b Author: Nikolay Izhikov Date: 2018-06-04T12:47:01Z Merge branch 'master' into IGNITE-8485 commit 7f1640dc6d73411b549ed324d1afe8486be5e955 Author: Nikolay Izhikov Date: 2018-06-04T16:20:40Z IGNITE-8485: Refactoring to be able to implement EncryptedPageStore commit
[jira] [Commented] (IGNITE-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506893#comment-16506893
]
ASF GitHub Bot commented on IGNITE-8131:
GitHub user dgarus opened a pull request:
https://github.com/apache/ignite/pull/4166
IGNITE-8131 ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire*
tests fail on TC
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/dgarus/ignite ignite-8131
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4166.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 #4166
commit 28fe7b5b9c5c6c07015d3ff99cb249f89493a47f
Author: Garus Denis
Date: 2018-06-09T10:12:08Z
IGNITE-8131. check TC fail
> ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
>
>
> Key: IGNITE-8131
> URL: https://issues.apache.org/jira/browse/IGNITE-8131
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Two tests always fail on TC with the assertion
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
> {noformat}
> from client disconnect/reconnect events check. Obviously client doesn't
> generate these events as it supposed to do.
> (TC runs can be found
> [here|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteZooKeeperDiscovery_IgniteTests24Java8=pull%2F3730%2Fhead=buildTypeStatusDiv]).
> It is possible to reproduce test failure locally as well, but with low
> probability: one failure for 50 or even 300 successful executions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8761) WAL fsync at rollover should be asynchronous in LOG_ONLY and BACKGROUND modes
Ivan Rakov created IGNITE-8761:
--
Summary: WAL fsync at rollover should be asynchronous in LOG_ONLY
and BACKGROUND modes
Key: IGNITE-8761
URL: https://issues.apache.org/jira/browse/IGNITE-8761
Project: Ignite
Issue Type: Improvement
Components: persistence
Reporter: Ivan Rakov
Fix For: 2.6
Transactions may periodically hang for a few seconds in LOG_ONLY or BACKGROUND
persistent modes. Thread dumps show that threads are hanging on syncing
previous WAL segment during rollover:
{noformat}
java.lang.Thread.State: RUNNABLE
at java.nio.MappedByteBuffer.force0(MappedByteBuffer.java:-1)
at java.nio.MappedByteBuffer.force(MappedByteBuffer.java:203)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.close(FileWriteAheadLogManager.java:2843)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$600(FileWriteAheadLogManager.java:2483)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.rollOver(FileWriteAheadLogManager.java:1094)
{noformat}
Waiting for this fsync is not necessary action to ensure crash recovery
guarantees. Instead of this, we should just perform fsyncs asychronously and
ensure that they are completed prior to next checkpoint start.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Garus reassigned IGNITE-8131:
---
Assignee: Denis Garus
> ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
>
>
> Key: IGNITE-8131
> URL: https://issues.apache.org/jira/browse/IGNITE-8131
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Two tests always fail on TC with the assertion
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
> {noformat}
> from client disconnect/reconnect events check. Obviously client doesn't
> generate these events as it supposed to do.
> (TC runs can be found
> [here|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteZooKeeperDiscovery_IgniteTests24Java8=pull%2F3730%2Fhead=buildTypeStatusDiv]).
> It is possible to reproduce test failure locally as well, but with low
> probability: one failure for 50 or even 300 successful executions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8760) TcpDiscoverySpi: validation of discovery message path on each node
[ https://issues.apache.org/jira/browse/IGNITE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-8760: Component/s: general > TcpDiscoverySpi: validation of discovery message path on each node > -- > > Key: IGNITE-8760 > URL: https://issues.apache.org/jira/browse/IGNITE-8760 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Priority: Major > Labels: discovery > > As each discovery message goes across the ring it can record all nodes it was > handled on. > It gives discovery protocol an opportunity to set up a constant monitoring of > cluster topology: each node on receiving discovery message will compare path > recorded by the message and its local picture of current topology. On > detecting any discrepancy node may at least print warning or take other > actions. > Path recording may be expensive in terms of network traffic so it is better > to add this logic to specific types of discovery messages: all topology > changing messages and (may be) heartbeats. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8760) TcpDiscoverySpi: validation of discovery message path on each node
[ https://issues.apache.org/jira/browse/IGNITE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-8760: Labels: discovery (was: ) > TcpDiscoverySpi: validation of discovery message path on each node > -- > > Key: IGNITE-8760 > URL: https://issues.apache.org/jira/browse/IGNITE-8760 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Priority: Major > Labels: discovery > > As each discovery message goes across the ring it can record all nodes it was > handled on. > It gives discovery protocol an opportunity to set up a constant monitoring of > cluster topology: each node on receiving discovery message will compare path > recorded by the message and its local picture of current topology. On > detecting any discrepancy node may at least print warning or take other > actions. > Path recording may be expensive in terms of network traffic so it is better > to add this logic to specific types of discovery messages: all topology > changing messages and (may be) heartbeats. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8760) TcpDiscoverySpi: validation of discovery message path on each node
Sergey Chugunov created IGNITE-8760: --- Summary: TcpDiscoverySpi: validation of discovery message path on each node Key: IGNITE-8760 URL: https://issues.apache.org/jira/browse/IGNITE-8760 Project: Ignite Issue Type: Improvement Reporter: Sergey Chugunov As each discovery message goes across the ring it can record all nodes it was handled on. It gives discovery protocol an opportunity to set up a constant monitoring of cluster topology: each node on receiving discovery message will compare path recorded by the message and its local picture of current topology. On detecting any discrepancy node may at least print warning or take other actions. Path recording may be expensive in terms of network traffic so it is better to add this logic to specific types of discovery messages: all topology changing messages and (may be) heartbeats. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8747) Remove\RemoveAll method should not count expired entry as removed.
[ https://issues.apache.org/jira/browse/IGNITE-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-8747: - Summary: Remove\RemoveAll method should not count expired entry as removed. (was: AccessExpiryPolicy should be check on first entry touch.) > Remove\RemoveAll method should not count expired entry as removed. > -- > > Key: IGNITE-8747 > URL: https://issues.apache.org/jira/browse/IGNITE-8747 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain, tck, test-failure > > We have 2 TCK 1.0 test that are passed due to we have eagerTtl=true by > default. > The reason is remove() return true even if an expired entry was removed. > Seems, we have to evict expired entry from cache on remove(), but do not > count it as removed. > java.lang.AssertionError > at > org.jsr107.tck.expiry.CacheExpiryTest.expire_whenAccessed(CacheExpiryTest.java:326) > java.lang.AssertionError: expected:<0> but was:<1> at > org.jsr107.tck.expiry.CacheExpiryTest.testCacheStatisticsRemoveAll(CacheExpiryTest.java:160) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8747) AccessExpiryPolicy should be check on first entry touch.
[ https://issues.apache.org/jira/browse/IGNITE-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506888#comment-16506888 ] ASF GitHub Bot commented on IGNITE-8747: GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/4165 IGNITE-8747: Remove\RemoveAll shouldn't report of successful deletion for expired entries. (cherry picked from commit f65f0a5) You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8747 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4165.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 #4165 commit ec567c0e5bd0b13f2ea9e097057c2cb4b57f2467 Author: Andrey V. Mashenkov Date: 2018-06-09T08:52:38Z IGNITE-8747: Apply AccessPolicy instantly on first touch. (cherry picked from commit f65f0a5) > AccessExpiryPolicy should be check on first entry touch. > > > Key: IGNITE-8747 > URL: https://issues.apache.org/jira/browse/IGNITE-8747 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain, tck, test-failure > > We have 2 TCK 1.0 test that are passed due to we have eagerTtl=true by > default. > The reason is remove() return true even if an expired entry was removed. > Seems, we have to evict expired entry from cache on remove(), but do not > count it as removed. > java.lang.AssertionError > at > org.jsr107.tck.expiry.CacheExpiryTest.expire_whenAccessed(CacheExpiryTest.java:326) > java.lang.AssertionError: expected:<0> but was:<1> at > org.jsr107.tck.expiry.CacheExpiryTest.testCacheStatisticsRemoveAll(CacheExpiryTest.java:160) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-8747) AccessExpiryPolicy should be check on first entry touch.
[ https://issues.apache.org/jira/browse/IGNITE-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-8747: - Comment: was deleted (was: I've renamed a ticket as ExpiryPolicy shouldn't be applied on remove operation. There is a TCK test on this. So, first get() operation is responsible to expire entry in expire_whenAccessed() test. I've found, on first entry touch we check TTL related to CreatedExpiryPolicy and then update is with AccessExpiryPolicy, but we miss the check if entry should be expired instantly due to newly applied AccessExpiryPolicy. This miss makes next remove() method report about successful entry deletions. Also, this issue was not introduced by IGNITE-8681. It can be easily reproduced on master with eagerTtl=false.) > AccessExpiryPolicy should be check on first entry touch. > > > Key: IGNITE-8747 > URL: https://issues.apache.org/jira/browse/IGNITE-8747 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain, tck, test-failure > > We have 2 TCK 1.0 test that are passed due to we have eagerTtl=true by > default. > The reason is remove() return true even if an expired entry was removed. > Seems, we have to evict expired entry from cache on remove(), but do not > count it as removed. > java.lang.AssertionError > at > org.jsr107.tck.expiry.CacheExpiryTest.expire_whenAccessed(CacheExpiryTest.java:326) > java.lang.AssertionError: expected:<0> but was:<1> at > org.jsr107.tck.expiry.CacheExpiryTest.testCacheStatisticsRemoveAll(CacheExpiryTest.java:160) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8759) TcpDiscoverySpi: detailed info about current state in MBean
Sergey Chugunov created IGNITE-8759: --- Summary: TcpDiscoverySpi: detailed info about current state in MBean Key: IGNITE-8759 URL: https://issues.apache.org/jira/browse/IGNITE-8759 Project: Ignite Issue Type: Improvement Components: general Reporter: Sergey Chugunov When TcpDiscoverySpi is used all nodes keep information about current topology locally. Discovery protocol is responsible of keeping this information consistent across all nodes. However in situations of network glitches some nodes may have different pictures of current state and topology of the cluster. To make it easier to monitor state of the whole cluster and identify such nodes quicker the following information should be presented via MBean interface on each node: * Current topology version; * Hash of current topology (e.g. sum of hash codes of all nodeIds) (to allow quick matching); * Pretty-formatted snapshot of current topology visible from the node; * Information about nodes visible/invisible to local one; * Other information useful to monitoring of topology state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6295) SQL: Get rid of "replicatedOnly" flag
[
https://issues.apache.org/jira/browse/IGNITE-6295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506880#comment-16506880
]
Vladimir Ozerov commented on IGNITE-6295:
-
Test run with the main logic implemented:
https://ci.ignite.apache.org/viewQueued.html?itemId=1373767
> SQL: Get rid of "replicatedOnly" flag
> -
>
> Key: IGNITE-6295
> URL: https://issues.apache.org/jira/browse/IGNITE-6295
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: performance, usability
> Fix For: 2.6
>
>
> This flag acts as a hint that all tables are reside in {{REPLICATED}} cache.
> However, we already have this information in runtime! No need to ask users to
> think about it.
> Let's deprecate that flag.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6295) SQL: Get rid of "replicatedOnly" flag
[
https://issues.apache.org/jira/browse/IGNITE-6295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506879#comment-16506879
]
ASF GitHub Bot commented on IGNITE-6295:
GitHub user devozerov opened a pull request:
https://github.com/apache/ignite/pull/4164
IGNITE-6295
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6295
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4164.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 #4164
commit 5defccc2898049b1f40cb97873bc53e8e95e594d
Author: devozerov
Date: 2018-06-09T09:34:02Z
Implemented base logic, need to run tests.
> SQL: Get rid of "replicatedOnly" flag
> -
>
> Key: IGNITE-6295
> URL: https://issues.apache.org/jira/browse/IGNITE-6295
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: performance, usability
> Fix For: 2.6
>
>
> This flag acts as a hint that all tables are reside in {{REPLICATED}} cache.
> However, we already have this information in runtime! No need to ask users to
> think about it.
> Let's deprecate that flag.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6295) SQL: Get rid of "replicatedOnly" flag
[
https://issues.apache.org/jira/browse/IGNITE-6295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6295:
Fix Version/s: 2.6
> SQL: Get rid of "replicatedOnly" flag
> -
>
> Key: IGNITE-6295
> URL: https://issues.apache.org/jira/browse/IGNITE-6295
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: performance, usability
> Fix For: 2.6
>
>
> This flag acts as a hint that all tables are reside in {{REPLICATED}} cache.
> However, we already have this information in runtime! No need to ask users to
> think about it.
> Let's deprecate that flag.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-6295) SQL: Get rid of "replicatedOnly" flag
[
https://issues.apache.org/jira/browse/IGNITE-6295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-6295:
---
Assignee: Vladimir Ozerov
> SQL: Get rid of "replicatedOnly" flag
> -
>
> Key: IGNITE-6295
> URL: https://issues.apache.org/jira/browse/IGNITE-6295
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: performance, usability
> Fix For: 2.6
>
>
> This flag acts as a hint that all tables are reside in {{REPLICATED}} cache.
> However, we already have this information in runtime! No need to ask users to
> think about it.
> Let's deprecate that flag.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8747) AccessExpiryPolicy should be check on first entry touch.
[ https://issues.apache.org/jira/browse/IGNITE-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506875#comment-16506875 ] Andrew Mashenkov commented on IGNITE-8747: -- I've renamed a ticket as ExpiryPolicy shouldn't be applied on remove operation. There is a TCK test on this. So, first get() operation is responsible to expire entry in expire_whenAccessed() test. I've found, on first entry touch we check TTL related to CreatedExpiryPolicy and then update is with AccessExpiryPolicy, but we miss the check if entry should be expired instantly due to newly applied AccessExpiryPolicy. This miss makes next remove() method report about successful entry deletions. Also, this issue was not introduced by IGNITE-8681. It can be easily reproduced on master with eagerTtl=false. > AccessExpiryPolicy should be check on first entry touch. > > > Key: IGNITE-8747 > URL: https://issues.apache.org/jira/browse/IGNITE-8747 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain, tck, test-failure > > We have 2 TCK 1.0 test that are passed due to we have eagerTtl=true by > default. > The reason is remove() return true even if an expired entry was removed. > Seems, we have to evict expired entry from cache on remove(), but do not > count it as removed. > java.lang.AssertionError > at > org.jsr107.tck.expiry.CacheExpiryTest.expire_whenAccessed(CacheExpiryTest.java:326) > java.lang.AssertionError: expected:<0> but was:<1> at > org.jsr107.tck.expiry.CacheExpiryTest.testCacheStatisticsRemoveAll(CacheExpiryTest.java:160) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8747) AccessExpiryPolicy should be check on first entry touch.
[ https://issues.apache.org/jira/browse/IGNITE-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-8747: - Summary: AccessExpiryPolicy should be check on first entry touch. (was: Remove\RemoveAll method should not count expired entry as removed.) > AccessExpiryPolicy should be check on first entry touch. > > > Key: IGNITE-8747 > URL: https://issues.apache.org/jira/browse/IGNITE-8747 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain, tck, test-failure > > We have 2 TCK 1.0 test that are passed due to we have eagerTtl=true by > default. > The reason is remove() return true even if an expired entry was removed. > Seems, we have to evict expired entry from cache on remove(), but do not > count it as removed. > java.lang.AssertionError > at > org.jsr107.tck.expiry.CacheExpiryTest.expire_whenAccessed(CacheExpiryTest.java:326) > java.lang.AssertionError: expected:<0> but was:<1> at > org.jsr107.tck.expiry.CacheExpiryTest.testCacheStatisticsRemoveAll(CacheExpiryTest.java:160) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506872#comment-16506872 ] ASF GitHub Bot commented on IGNITE-1094: GitHub user sk0x50 opened a pull request: https://github.com/apache/ignite/pull/4163 IGNITE-1094 Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-1094-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4163.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 #4163 commit 51f13379fc920f1f9412bcc07025ceadab28666c Author: Slava Koptilin Date: 2018-06-08T10:14:16Z added IgniteDynamicCacheStartFailSelfTest commit 1e85bb15db98fd2b8bc3ea338f1b528945d3d5f4 Author: Slava Koptilin Date: 2018-06-08T10:16:21Z added new attribute ATTR_DYNAMIC_CACHE_START_ROLLBACK_SUPPORTED which indicates that rollback of exchange is supported commit 8907568fe7292ab78b64f82475dd3ddf77e07f34 Author: Slava Koptilin Date: 2018-06-08T10:18:45Z added convenience method to check that all nodes has an attribute and its value equals to expected value. commit d937eefdb3715f54d01bec9379649fb284e9ed93 Author: Slava Koptilin Date: 2018-06-08T10:22:01Z added DynamicCacheChangeFailureMessage that represents exchange failure due to dynamic cache start. commit 3580d89045754cf7763b56aea9a40176c532add8 Author: Slava Koptilin Date: 2018-06-08T20:43:40Z added rollback dynamically started caches commit b184de02feffab58916378185dad1a7e6132c5b5 Author: Slava Koptilin Date: 2018-06-08T21:21:15Z merged with master commit f82b99c07ac8fe094698d626ec99dfb594edaf63 Author: Slava Koptilin Date: 2018-06-08T21:27:40Z updated test suite > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: Muted_test > Fix For: 2.6 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-955) Local listener in continuous queries should not be mandatory
[
https://issues.apache.org/jira/browse/IGNITE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-955:
Comment: was deleted
(was: [~vkulichenko] [~yzhdanov]
1)What is the point of creating continuous query without local listener ?
2)What if we set transformer via _setRemoteTransformerFactory_ only, should
local listener be optional?
3)If no listeners or filters set, should exception be thrown ? I, believe yes)
> Local listener in continuous queries should not be mandatory
>
>
> Key: IGNITE-955
> URL: https://issues.apache.org/jira/browse/IGNITE-955
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Major
> Labels: Usability
>
> We need to support the use case when remote filter is needed, but local
> listener is not (filter always returns {{false}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-8758) Web console: Broken UI under Firefox in case of long user name
[ https://issues.apache.org/jira/browse/IGNITE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-8758. -- > Web console: Broken UI under Firefox in case of long user name > -- > > Key: IGNITE-8758 > URL: https://issues.apache.org/jira/browse/IGNITE-8758 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.5 >Reporter: Pavel Konstantinov >Assignee: Andrey Novikov >Priority: Minor > Fix For: 2.6 > > > Just change a user name in the profile to 1 > and check how it looks under Firefox -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8758) Web console: Broken UI under Firefox in case of long user name
[ https://issues.apache.org/jira/browse/IGNITE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-8758: -- Assignee: Andrey Novikov (was: Pavel Konstantinov) > Web console: Broken UI under Firefox in case of long user name > -- > > Key: IGNITE-8758 > URL: https://issues.apache.org/jira/browse/IGNITE-8758 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.5 >Reporter: Pavel Konstantinov >Assignee: Andrey Novikov >Priority: Minor > Fix For: 2.6 > > > Just change a user name in the profile to 1 > and check how it looks under Firefox -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8758) Web console: Broken UI under Firefox in case of long user name
[ https://issues.apache.org/jira/browse/IGNITE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506841#comment-16506841 ] Pavel Konstantinov commented on IGNITE-8758: Looks good now. > Web console: Broken UI under Firefox in case of long user name > -- > > Key: IGNITE-8758 > URL: https://issues.apache.org/jira/browse/IGNITE-8758 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.5 >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Minor > Fix For: 2.6 > > > Just change a user name in the profile to 1 > and check how it looks under Firefox -- This message was sent by Atlassian JIRA (v7.6.3#76005)
