[jira] [Updated] (IGNITE-7764) MVCC TX: make cache basic operations support Mvcc tx mode.
[ https://issues.apache.org/jira/browse/IGNITE-7764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-7764: - Summary: MVCC TX: make cache basic operations support Mvcc tx mode. (was: MVCC TX: Locking protocol for Key-Value API) > MVCC TX: make cache basic operations support Mvcc tx mode. > -- > > Key: IGNITE-7764 > URL: https://issues.apache.org/jira/browse/IGNITE-7764 > Project: Ignite > Issue Type: New Feature > Components: mvcc, sql >Reporter: Roman Kondakov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > We need to implement an MVCC-compatible locking protocol for Key-Value API. > At the moment during transactions with KV operations if entry we are going to > change is unlocked we do not check if it has been changed by the previous > transaction. See IGNITE-6935. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9249) Tests hang when different threads try to start and stop nodes at the same time.
[
https://issues.apache.org/jira/browse/IGNITE-9249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610545#comment-16610545
]
Ilya Lantukh commented on IGNITE-9249:
--
https://ci.ignite.apache.org/viewQueued.html?itemId=1841812
> Tests hang when different threads try to start and stop nodes at the same
> time.
> ---
>
> Key: IGNITE-9249
> URL: https://issues.apache.org/jira/browse/IGNITE-9249
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> An example of such test is
> GridCachePartitionedNearDisabledOptimisticTxNodeRestartTest.testRestartWithPutFourNodesOneBackupsOffheapEvict().
> Hanged threads:
> {code}
> "restart-worker-1@63424" prio=5 tid=0x7f5e nid=NA waiting
> java.lang.Thread.State: WAITING
> at java.lang.Object.wait(Object.java:-1)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:949)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:389)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2002)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:916)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1754)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1050)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> - locked <0xfc36> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:920)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:858)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:846)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:812)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.access$1000(GridCacheAbstractNodeRestartSelfTest.java:64)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest$2.run(GridCacheAbstractNodeRestartSelfTest.java:665)
> at java.lang.Thread.run(Thread.java:748)
> "restart-worker-0@63423" prio=5 tid=0x7f5d nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7584)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.grid(IgnitionEx.java:1666)
> at
> org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1284)
> at
> org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1262)
> at org.apache.ignite.Ignition.allGrids(Ignition.java:502)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2258)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1158)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1133)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1433)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.access$800(GridCacheAbstractNodeRestartSelfTest.java:64)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest$2.run(GridCacheAbstractNodeRestartSelfTest.jav
[jira] [Commented] (IGNITE-9519) PK as complex type should can be keep at inline index
[ https://issues.apache.org/jira/browse/IGNITE-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610542#comment-16610542 ] ASF GitHub Bot commented on IGNITE-9519: GitHub user ygerzhedovich opened a pull request: https://github.com/apache/ignite/pull/4724 IGNITE-9519: PK as complex type should can be keep at inline index You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9519 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4724.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 #4724 commit 8b96932e622afdd79fb4cc62b6e5ce0ddf0f497f Author: Yury Gerzhedovich Date: 2018-09-10T15:42:14Z IGNITE-9519: PK as complex type should can be keep at inline index > PK as complex type should can be keep at inline index > - > > Key: IGNITE-9519 > URL: https://issues.apache.org/jira/browse/IGNITE-9519 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.6 >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > > Currently in case PK is complex type it can not be keep at inline index. > This is critical performance issue due to for any put or get operation it > cant' be fully comparable and require read full object from the heap or even > disk storage. > To mitigate the problem we need add ability keep complex type (java object) > at inline indexes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9249) Tests hang when different threads try to start and stop nodes at the same time.
[
https://issues.apache.org/jira/browse/IGNITE-9249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610536#comment-16610536
]
ASF GitHub Bot commented on IGNITE-9249:
GitHub user ilantukh opened a pull request:
https://github.com/apache/ignite/pull/4723
IGNITE-9249
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9249
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4723.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 #4723
commit 3be4dcc6da6649fb04f99f61c31cebb29d03c0fe
Author: Ilya Lantukh
Date: 2018-08-10T13:23:28Z
IGNITE-9249 : Configured node join timeout for all tests.
commit a5ef89937689f29a10930ff9b38f525635d498b2
Author: Ilya Lantukh
Date: 2018-09-11T12:43:21Z
IGNITE-9249 : Join timeout should be checked even with shared IP finder.
> Tests hang when different threads try to start and stop nodes at the same
> time.
> ---
>
> Key: IGNITE-9249
> URL: https://issues.apache.org/jira/browse/IGNITE-9249
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> An example of such test is
> GridCachePartitionedNearDisabledOptimisticTxNodeRestartTest.testRestartWithPutFourNodesOneBackupsOffheapEvict().
> Hanged threads:
> {code}
> "restart-worker-1@63424" prio=5 tid=0x7f5e nid=NA waiting
> java.lang.Thread.State: WAITING
> at java.lang.Object.wait(Object.java:-1)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:949)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:389)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2002)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:916)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1754)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1050)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> - locked <0xfc36> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:920)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:858)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:846)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:812)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.access$1000(GridCacheAbstractNodeRestartSelfTest.java:64)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest$2.run(GridCacheAbstractNodeRestartSelfTest.java:665)
> at java.lang.Thread.run(Thread.java:748)
> "restart-worker-0@63423" prio=5 tid=0x7f5d nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7584)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.grid(IgnitionEx.java:1666)
> at
> org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1284)
> at
> org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1262)
> a
[jira] [Commented] (IGNITE-6044) SQL insert waits for transaction commit, but it must be executed right away
[
https://issues.apache.org/jira/browse/IGNITE-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610518#comment-16610518
]
Taras Ledkov commented on IGNITE-6044:
--
[~jooger], the review status:
| Codestyle | Please review my minor changes |
| Documentation | Please link documentation issue |
| Binary compatibility | - |
| Tests | Please run all SQL suites |
| Comments | # I guess {{DmlInsideTransactionTest.SystemProperty}} must keep
the original property value because property may be setup externally for suite
etc.
# {{SystemProperty}} looks usable. Does make sense move it to
{{org.apache.ignite.testframework}} or {{GridTestUtils}}?|
> SQL insert waits for transaction commit, but it must be executed right away
> ---
>
> Key: IGNITE-6044
> URL: https://issues.apache.org/jira/browse/IGNITE-6044
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1
>Reporter: Mikhail Cherkasov
>Assignee: Yury Gerzhedovich
>Priority: Critical
> Labels: sql-stability, usability
>
> Doc says:
> ""Presently, DML supports the atomic mode only meaning that if there is a DML
> query that is executed as a part of an Ignite transaction then it will not be
> enlisted in the transaction's writing queue and will be executed right away.""
> https://apacheignite.readme.io/docs/dml#section-transactional-support
> However the data will be added to cache only after transaction commit.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-6044) SQL insert waits for transaction commit, but it must be executed right away
[
https://issues.apache.org/jira/browse/IGNITE-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610518#comment-16610518
]
Taras Ledkov edited comment on IGNITE-6044 at 9/11/18 12:21 PM:
[~jooger], the review status:
| Codestyle | Please review my minor changes |
| Documentation | Please link documentation issue |
| Binary compatibility | -- |
| Tests | Please run all SQL suites |
| Comments | # I guess {{DmlInsideTransactionTest.SystemProperty}} must keep
the original property value because property may be setup externally for suite
etc.
# {{SystemProperty}} looks usable. Does make sense move it to
{{org.apache.ignite.testframework}} or {{GridTestUtils}}?|
was (Author: tledkov-gridgain):
[~jooger], the review status:
| Codestyle | Please review my minor changes |
| Documentation | Please link documentation issue |
| Binary compatibility | - |
| Tests | Please run all SQL suites |
| Comments | # I guess {{DmlInsideTransactionTest.SystemProperty}} must keep
the original property value because property may be setup externally for suite
etc.
# {{SystemProperty}} looks usable. Does make sense move it to
{{org.apache.ignite.testframework}} or {{GridTestUtils}}?|
> SQL insert waits for transaction commit, but it must be executed right away
> ---
>
> Key: IGNITE-6044
> URL: https://issues.apache.org/jira/browse/IGNITE-6044
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1
>Reporter: Mikhail Cherkasov
>Assignee: Yury Gerzhedovich
>Priority: Critical
> Labels: sql-stability, usability
>
> Doc says:
> ""Presently, DML supports the atomic mode only meaning that if there is a DML
> query that is executed as a part of an Ignite transaction then it will not be
> enlisted in the transaction's writing queue and will be executed right away.""
> https://apacheignite.readme.io/docs/dml#section-transactional-support
> However the data will be added to cache only after transaction commit.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9333) Adding page with simple statistic for last 50 runs.
[
https://issues.apache.org/jira/browse/IGNITE-9333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610516#comment-16610516
]
Dmitriy Pavlov commented on IGNITE-9333:
Locally feature is failed
{noformat}
java.lang.NullPointerException: null
at
org.apache.ignite.ci.web.model.current.BuildStatisticsSummary.lambda$getProblemsStream$1(BuildStatisticsSummary.java:185)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.LongPipeline.reduce(LongPipeline.java:438)
at java.util.stream.LongPipeline.sum(LongPipeline.java:396)
at java.util.stream.ReferencePipeline.count(ReferencePipeline.java:526)
at
org.apache.ignite.ci.web.model.current.BuildStatisticsSummary.getExecutionTimeoutCount(BuildStatisticsSummary.java:92)
at
org.apache.ignite.ci.web.model.current.BuildStatisticsSummary.getRes(BuildStatisticsSummary.java:226)
at
org.apache.ignite.ci.web.model.current.BuildStatisticsSummary.getFullRes(BuildStatisticsSummary.java:200)
at
org.apache.ignite.ci.web.model.current.BuildStatisticsSummary.initialize(BuildStatisticsSummary.java:86)
at
org.apache.ignite.ci.web.rest.build.GetBuildTestFailures.getBuildStatisticsSummaryNoCache(GetBuildTestFailures.java:210)
at
org.apache.ignite.ci.web.rest.build.GetBuildTestFailures.lambda$getBuildsHistory$e43e8349$1(GetBuildTestFailures.java:189)
at
org.apache.ignite.ci.web.BackgroundUpdater.lambda$get$2(BackgroundUpdater.java:122)
at
org.apache.ignite.ci.web.BackgroundUpdater.lambda$get$3(BackgroundUpdater.java:147)
at
com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:5058)
at
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3708)
at
com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2416)
at
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2299)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2212)
at com.google.common.cache.LocalCache.get(LocalCache.java:4147)
at
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:5053)
at
org.apache.ignite.ci.web.BackgroundUpdater.get(BackgroundUpdater.java:146)
at
org.apache.ignite.ci.web.BackgroundUpdater.get(BackgroundUpdater.java:108)
at
org.apache.ignite.ci.web.rest.build.GetBuildTestFailures.getBuildsHistory(GetBuildTestFailures.java:187)
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)
{noformat}
> Adding page with simple statistic for last 50 runs.
> ---
>
> Key: IGNITE-9333
> URL: https://issues.apache.org/jira/browse/IGNITE-9333
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Eduard Shangareev
>Assignee: Nikolai Kulagin
>Priority: Major
>
> Ok, I am proposing to add a new page which would be named "Statistic".
> It should show last 50 "Run All" for master, the columns:
> ||Id||Total tests||Failed tests||Ignored tests|| Muted tests||Total issues
> (count and the list of TC configurations with links) || Total run time ||
> Also, we need to calculate the statistic.
> Totals (all unique tests with issues), average issues/fails per run, median,
> max, min.
> Total issues = Exit codes + JVM Crashes + OOMs + other issues which caused TC
> configuration fail
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9311) Add missing @Override annotation
[
https://issues.apache.org/jira/browse/IGNITE-9311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610515#comment-16610515
]
Maxim Muzafarov commented on IGNITE-9311:
-
[~roman_s]
Thank you for the review and your time!
Will you merge it or I should ask someone else?
> Add missing @Override annotation
>
>
> Key: IGNITE-9311
> URL: https://issues.apache.org/jira/browse/IGNITE-9311
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>
> New `Code Inspections` profile can be found
> {{\idea\ignite_inspections.xml}}.
> We will need to fix all methods with missed {{@Override}} annotation
> regarding this inscpetion profile.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9535) ClientChangeGlobalStateComputeRequest is missing @GridInternal annotation
[ https://issues.apache.org/jira/browse/IGNITE-9535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610513#comment-16610513 ] ASF GitHub Bot commented on IGNITE-9535: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4721 > ClientChangeGlobalStateComputeRequest is missing @GridInternal annotation > - > > Key: IGNITE-9535 > URL: https://issues.apache.org/jira/browse/IGNITE-9535 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.7 > > > Problematic class: > org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.ClientChangeGlobalStateComputeRequest; > @GridInternal annotation must be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9535) ClientChangeGlobalStateComputeRequest is missing @GridInternal annotation
[ https://issues.apache.org/jira/browse/IGNITE-9535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610512#comment-16610512 ] Dmitriy Govorukhin commented on IGNITE-9535: Merged to master. > ClientChangeGlobalStateComputeRequest is missing @GridInternal annotation > - > > Key: IGNITE-9535 > URL: https://issues.apache.org/jira/browse/IGNITE-9535 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.7 > > > Problematic class: > org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.ClientChangeGlobalStateComputeRequest; > @GridInternal annotation must be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9541) Add the comparison for two general statistics "RunAll" for master in the date interval
[ https://issues.apache.org/jira/browse/IGNITE-9541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolai Kulagin reassigned IGNITE-9541: --- Assignee: Nikolai Kulagin > Add the comparison for two general statistics "RunAll" for master in the date > interval > -- > > Key: IGNITE-9541 > URL: https://issues.apache.org/jira/browse/IGNITE-9541 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolai Kulagin >Assignee: Nikolai Kulagin >Priority: Major > > Based on IGNITE-9333 add the comparison for two general statistics "RunAll" > for master in the date interval -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9464) MVCC TX: make cache basic operations support Mvcc tx mode.
[ https://issues.apache.org/jira/browse/IGNITE-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9464: - Description: Make get/getAll, put/PutAll/getAndPut, remove/removeAll/getAndRemove operations consistent with SQL queries in MVCC mode. This requires to implement MVCC protocol for cache operations. was: Make get/getAll, put/PutAll, remove/removeAll operations consistent with SQL queries in MVCC mode. This requires to implement MVCC protocol for cache operations. > MVCC TX: make cache basic operations support Mvcc tx mode. > -- > > Key: IGNITE-9464 > URL: https://issues.apache.org/jira/browse/IGNITE-9464 > Project: Ignite > Issue Type: New Feature > Components: cache, mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > > Make get/getAll, put/PutAll/getAndPut, remove/removeAll/getAndRemove > operations consistent with SQL queries in MVCC mode. > This requires to implement MVCC protocol for cache operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9333) Adding page with simple statistic for last 50 runs.
[
https://issues.apache.org/jira/browse/IGNITE-9333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610511#comment-16610511
]
ASF GitHub Bot commented on IGNITE-9333:
asfgit closed pull request #3: IGNITE-9333 Add statistics page
URL: https://github.com/apache/ignite-teamcity-bot/pull/3
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
index 9782cbf..d9d8d1d 100644
--- a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
+++ b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
@@ -33,6 +33,7 @@
import org.apache.ignite.ci.tcmodel.conf.BuildType;
import org.apache.ignite.ci.tcmodel.hist.BuildRef;
import org.apache.ignite.ci.tcmodel.result.Build;
+import org.apache.ignite.ci.tcmodel.result.issues.IssuesUsagesList;
import org.apache.ignite.ci.tcmodel.result.problems.ProblemOccurrence;
import org.apache.ignite.ci.tcmodel.result.problems.ProblemOccurrences;
import org.apache.ignite.ci.tcmodel.result.stat.Statistics;
@@ -52,6 +53,7 @@
public interface ITeamcity extends AutoCloseable {
String DEFAULT = "";
+long DEFAULT_BUILDS_COUNT = 1000;
CompletableFuture> getProjectSuites(String projectId);
@@ -62,7 +64,17 @@
* @param branch
* @return list of builds in historical order, recent builds coming last
*/
-List getFinishedBuilds(String projectId, String branch);
+default List getFinishedBuilds(String projectId, String branch) {
+return getFinishedBuilds(projectId, branch, null);
+};
+
+/**
+ * @param projectId suite ID (string without spaces)
+ * @param branch
+ * @param cnt builds count
+ * @return list of builds in historical order, recent builds coming last
+ */
+List getFinishedBuilds(String projectId, String branch, Long
cnt);
/**
* Includes snapshot dependencies failed builds into list
@@ -71,7 +83,19 @@
* @param branch branch in TC identification
* @return list of builds in historical order, recent builds coming last
*/
-List getFinishedBuildsIncludeSnDepFailed(String projectId,
String branch);
+default List getFinishedBuildsIncludeSnDepFailed(String
projectId, String branch){
+return getFinishedBuilds(projectId, branch, null);
+};
+
+/**
+ * Includes snapshot dependencies failed builds into list
+ *
+ * @param projectId suite ID (string without spaces)
+ * @param branch branch in TC identification
+ * @param cnt builds count
+ * @return list of builds in historical order, recent builds coming last
+ */
+List getFinishedBuildsIncludeSnDepFailed(String projectId,
String branch, Long cnt);
/** */
CompletableFuture> getRunningBuilds(@Nullable String
branch);
@@ -80,7 +104,11 @@
CompletableFuture> getQueuedBuilds(@Nullable String branch);
default int[] getBuildNumbersFromHistory(String projectId, String
branchNameForHist) {
-return getFinishedBuilds(projectId,
branchNameForHist).stream().mapToInt(BuildRef::getId).toArray();
+return getBuildNumbersFromHistory(projectId, branchNameForHist, null);
+}
+
+default int[] getBuildNumbersFromHistory(String projectId, String
branchNameForHist, Long cnt) {
+return getFinishedBuilds(projectId, branchNameForHist,
cnt).stream().mapToInt(BuildRef::getId).toArray();
}
Build getBuild(String href);
@@ -114,6 +142,8 @@ default Build getBuild(int id) {
ChangesList getChangesList(String href);
+IssuesUsagesList getIssuesUsagesList(String href);
+
/**
* Runs deep collection of all related statistics for particular build
*
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
index 99f61bb..126ad98 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
@@ -36,6 +36,7 @@
import java.util.function.BiFunction;
import java.util.function.Function;
import java.util.function.Predicate;
+import java.util.stream.Collectors;
import java.util.stream.Stream;
import java.util.stream.StreamSupport;
import javax.annotation.Nullable;
@@ -57,6 +58,7 @@
import org.apache.ignite.ci.tcmodel.conf.BuildType;
import org.apache.ignite.ci.tcmodel.hist.BuildRef;
import org.apache.ignite.ci.tcmodel.result.Build;
+import org.apache.ignite.ci.t
[jira] [Commented] (IGNITE-9487) REST: getall can only output keys as scalars
[
https://issues.apache.org/jira/browse/IGNITE-9487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610510#comment-16610510
]
Ilya Kasnacheev commented on IGNITE-9487:
-
[~anovikov] please review proposed change. The idea is to introduce behavior
now, make it the only one in 3.0
> REST: getall can only output keys as scalars
>
>
> Key: IGNITE-9487
> URL: https://issues.apache.org/jira/browse/IGNITE-9487
> Project: Ignite
> Issue Type: Improvement
> Components: rest
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> Regardless of what ConnectorMessageInterceptor does, `getall' command can
> only output key as string or number, and not as JSON object as values can.
> This is because output format is as follows:
> {code}
> {"successStatus":0,"affinityNodeId":null,"sessionToken":null,"response":{"CustomType
> [idHash=1588995554, hash=34706515, key=111]":{"val":"111"},"CustomType
> [idHash=978025370, hash=30386820, key=222]":{"val":"222"}},"error":null}
> {code}
> The desired output format may look like:
> {code}
> {"successStatus":0,"affinityNodeId":null,"sessionToken":null,"response":[{"key":{"key":111},"value":{"val":"111"}},{"key":{"key":222},"value":{"val":"222"}}],"error":null}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9376) Create table with critical failures
[ https://issues.apache.org/jira/browse/IGNITE-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610508#comment-16610508 ] Dmitriy Pavlov commented on IGNITE-9376: I've created https://issues.apache.org/jira/browse/IGNITE-9542 for fixing and refactoring. > Create table with critical failures > --- > > Key: IGNITE-9376 > URL: https://issues.apache.org/jira/browse/IGNITE-9376 > Project: Ignite > Issue Type: Sub-task >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Major > > Create separate table for critical failures (suite timouts, suite non-zero > exit codes, etc) and new tests (failure rate 0.0%) on the PR analysis page of > TCH. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9542) Ignite TC bot: provide separated base/current branch history for PR page
Dmitriy Pavlov created IGNITE-9542: -- Summary: Ignite TC bot: provide separated base/current branch history for PR page Key: IGNITE-9542 URL: https://issues.apache.org/jira/browse/IGNITE-9542 Project: Ignite Issue Type: Bug Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov https://issues.apache.org/jira/browse/IGNITE-9376 works incorrectly without separation of test history for the base and for a shown branch. It is suggested to refactor provided data for the current and for the base branch. It will allow showing blockers based on statistics from the base branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9541) Add the comparison for two general statistics "RunAll" for master in the date interval
Nikolai Kulagin created IGNITE-9541: --- Summary: Add the comparison for two general statistics "RunAll" for master in the date interval Key: IGNITE-9541 URL: https://issues.apache.org/jira/browse/IGNITE-9541 Project: Ignite Issue Type: Sub-task Reporter: Nikolai Kulagin Based on IGNITE-9333 add the comparison for two general statistics "RunAll" for master in the date interval -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9540) MVCC TX: make cache invoke\invokeAll operations support Mvcc tx mode.
[
https://issues.apache.org/jira/browse/IGNITE-9540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-9540:
-
Description:
{color:#FF}{color}Make invoke/invokeAll operations consistent with SQL
queries in MVCC mode.
This requires changes in protocol.
> MVCC TX: make cache invoke\invokeAll operations support Mvcc tx mode.
> -
>
> Key: IGNITE-9540
> URL: https://issues.apache.org/jira/browse/IGNITE-9540
> Project: Ignite
> Issue Type: New Feature
> Components: cache, mvcc
>Reporter: Andrew Mashenkov
>Priority: Major
>
> {color:#FF}{color}Make invoke/invokeAll operations consistent with SQL
> queries in MVCC mode.
> This requires changes in protocol.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9464) MVCC TX: make cache basic operations support Mvcc tx mode.
[ https://issues.apache.org/jira/browse/IGNITE-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9464: - Description: Make get/getAll, put/PutAll, remove/removeAll operations consistent with SQL queries in MVCC mode. This requires to implement MVCC protocol for cache operations. was: Make get/getAll, put/PutAll operations consistent with SQL queries in MVCC mode. This requires to implement MVCC protocol for cache operations. > MVCC TX: make cache basic operations support Mvcc tx mode. > -- > > Key: IGNITE-9464 > URL: https://issues.apache.org/jira/browse/IGNITE-9464 > Project: Ignite > Issue Type: New Feature > Components: cache, mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > > Make get/getAll, put/PutAll, remove/removeAll operations consistent with SQL > queries in MVCC mode. > This requires to implement MVCC protocol for cache operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9388) mesos IgniteProvider tries to access obolete ignite.run or download from slow archive
[ https://issues.apache.org/jira/browse/IGNITE-9388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610507#comment-16610507 ] Ilya Kasnacheev commented on IGNITE-9388: - [~roman_s] Looks good to me now! > mesos IgniteProvider tries to access obolete ignite.run or download from slow > archive > - > > Key: IGNITE-9388 > URL: https://issues.apache.org/jira/browse/IGNITE-9388 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Major > Fix For: 2.7 > > > Although it downloads from the archive, for Japan, for instance, it takes 2-3 > hours. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9540) MVCC TX: make cache invoke\invokeAll operations support Mvcc tx mode.
[ https://issues.apache.org/jira/browse/IGNITE-9540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9540: - Ignite Flags: (was: Docs Required) > MVCC TX: make cache invoke\invokeAll operations support Mvcc tx mode. > - > > Key: IGNITE-9540 > URL: https://issues.apache.org/jira/browse/IGNITE-9540 > Project: Ignite > Issue Type: New Feature > Components: cache, mvcc >Reporter: Andrew Mashenkov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9540) MVCC TX: make cache invoke\invokeAll operations support Mvcc tx mode.
[ https://issues.apache.org/jira/browse/IGNITE-9540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9540: - Component/s: mvcc cache > MVCC TX: make cache invoke\invokeAll operations support Mvcc tx mode. > - > > Key: IGNITE-9540 > URL: https://issues.apache.org/jira/browse/IGNITE-9540 > Project: Ignite > Issue Type: New Feature > Components: cache, mvcc >Reporter: Andrew Mashenkov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9464) MVCC TX: make cache basic operations support Mvcc tx mode.
[ https://issues.apache.org/jira/browse/IGNITE-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9464: - Summary: MVCC TX: make cache basic operations support Mvcc tx mode. (was: MVCC TX: cache basic operations supports Mvcc tx mode.) > MVCC TX: make cache basic operations support Mvcc tx mode. > -- > > Key: IGNITE-9464 > URL: https://issues.apache.org/jira/browse/IGNITE-9464 > Project: Ignite > Issue Type: New Feature > Components: cache, mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > > Make get/getAll, put/PutAll operations consistent with SQL queries in MVCC > mode. > This requires to implement MVCC protocol for cache operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9540) MVCC TX: make cache invoke\invokeAll operations support Mvcc tx mode.
Andrew Mashenkov created IGNITE-9540: Summary: MVCC TX: make cache invoke\invokeAll operations support Mvcc tx mode. Key: IGNITE-9540 URL: https://issues.apache.org/jira/browse/IGNITE-9540 Project: Ignite Issue Type: New Feature Reporter: Andrew Mashenkov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9535) ClientChangeGlobalStateComputeRequest is missing @GridInternal annotation
[ https://issues.apache.org/jira/browse/IGNITE-9535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-9535: --- Fix Version/s: 2.7 > ClientChangeGlobalStateComputeRequest is missing @GridInternal annotation > - > > Key: IGNITE-9535 > URL: https://issues.apache.org/jira/browse/IGNITE-9535 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.7 > > > Problematic class: > org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.ClientChangeGlobalStateComputeRequest; > @GridInternal annotation must be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9377) Handle print critical failures to the PR
[ https://issues.apache.org/jira/browse/IGNITE-9377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610505#comment-16610505 ] Ryabov Dmitrii commented on IGNITE-9377: [~dpavlov], I've prepared a PR with JIRA comment, but it will need to be updated after merge PR#5 (because they have changes in the same files). > Handle print critical failures to the PR > > > Key: IGNITE-9377 > URL: https://issues.apache.org/jira/browse/IGNITE-9377 > Project: Ignite > Issue Type: Sub-task >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > > Create a button by clicking on which the info about critical failures will be > written in the PR. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7371) MVCC TX Repeatable read semantic
[ https://issues.apache.org/jira/browse/IGNITE-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-7371: Assignee: (was: Andrew Mashenkov) > MVCC TX Repeatable read semantic > > > Key: IGNITE-7371 > URL: https://issues.apache.org/jira/browse/IGNITE-7371 > Project: Ignite > Issue Type: New Feature > Components: cache, mvcc >Reporter: Igor Seliverstov >Priority: Major > > Repeatable read isolation implies that each GET operation whithin tx gets a > last commited version of entry *at the time the tx was started*. Curentrly we > get a last commited version of entry *at the time the first read operation > invokes on a particular key whithin tx.* We need to fix this unconsistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9464) MVCC TX: cache basic operations supports Mvcc tx mode.
[ https://issues.apache.org/jira/browse/IGNITE-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9464: - Description: Make get/getAll, put/PutAll operations consistent with SQL queries in MVCC mode. This requires to implement MVCC protocol for cache operations. was:Make cache > MVCC TX: cache basic operations supports Mvcc tx mode. > -- > > Key: IGNITE-9464 > URL: https://issues.apache.org/jira/browse/IGNITE-9464 > Project: Ignite > Issue Type: New Feature > Components: cache, mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > > Make get/getAll, put/PutAll operations consistent with SQL queries in MVCC > mode. > This requires to implement MVCC protocol for cache operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9377) Handle print critical failures to the PR
[
https://issues.apache.org/jira/browse/IGNITE-9377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16609070#comment-16609070
]
Ryabov Dmitrii edited comment on IGNITE-9377 at 9/11/18 11:57 AM:
--
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#cc|titleBGColor=#f7d6c1}
{color:#d04437}Cache 6{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1800125]]
* IgniteCache150ClientsTest.test150Clients (last started)
{color:#d04437}Binary Objects (Simple Mapper Basic){color} [[tests 0 TIMEOUT ,
Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=1800057]]
* TxSavepointsTransactionalCacheTest.testPutWithExplicitTx (last started)
{color:#d04437}Basic 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1800154]]
* TxSavepointsTransactionalCacheTest.testPutWithExplicitTx (last started)
{color:#d04437}Platform C++ (Linux){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1800102]]
{color:#d04437}Cache (Failover) 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1800130]]
* IgniteCacheFailoverTestSuite2:
CacheAsyncOperationsFailoverTxTest.testPutAllAsyncFailover - 76,5% fails in
master.
{color:#d04437}Platform .NET (Long Running){color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=1800109]]
* exe: ExamplesTest.TestRemoteNodes(BinaryModeExample) - 100,0% fails in
master.
* exe: ExamplesTest.TestRemoteNodes(LinqExample) - 100,0% fails in master.
* exe: ExamplesTest.TestRemoteNodes(SqlExample) - 100,0% fails in master.
* exe: CacheAbstractTest.TestCacheConfigurationExpiryPolicy - 10,0% fails in
master.
* exe: CacheAbstractTest.TestCacheConfigurationExpiryPolicy - 10,0% fails in
master.
{color:#d04437}PDS 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1800117]]
* IgnitePdsTestSuite2:
IgniteWalReaderTest.testArchiveIncompleteSegmentAfterInactivity - 10,5% fails
in master.
{color:#d04437}Cache 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1800137]]
* IgniteBinaryCacheTestSuite: IgniteCommunicationBalanceTest.testBalance2 -
0,0% fails in master.
* IgniteBinaryCacheTestSuite:
DataStreamerImplSelfTest.testAllOperationFinishedBeforeFutureCompletion - 0,0%
fails in master.
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=1800100]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_4 - 0,0% fails in master.
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_5 - 0,0% fails in master.
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testReconnectDisabled_ConnectionLost - 0,0% fails in
master.{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1800157&buildTypeId=IgniteTests24Java8_RunAll]
was (Author: somefire):
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#cc|titleBGColor=#f7d6c1}
Cache 6 [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1800125]]
* IgniteCache150ClientsTest.test150Clients (last started)
Binary Objects (Simple Mapper Basic) [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1800057]]
* TxSavepointsTransactionalCacheTest.testPutWithExplicitTx (last started)
Basic 1 [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1800154]]
* TxSavepointsTransactionalCacheTest.testPutWithExplicitTx (last started)
Platform C++ (Linux) [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1800102]]
Cache (Failover) 2 [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1800130]]
* IgniteCacheFailoverTestSuite2:
CacheAsyncOperationsFailoverTxTest.testPutAllAsyncFailover - 76,5% fails in
master.
Platform .NET (Long Running) [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=1800109]]
* exe: ExamplesTest.TestRemoteNodes(BinaryModeExample) - 100,0% fails in
master.
* exe: ExamplesTest.TestRemoteNodes(LinqExample) - 100,0% fails in master.
* exe: ExamplesTest.TestRemoteNodes(SqlExample) - 100,0% fails in master.
* exe: CacheAbstractTest.TestCacheConfigurationExpiryPolicy - 10,0% fails in
master.
* exe: CacheAbstractTest.TestCacheConfigurationExpiryPolicy - 10,0% fails in
master.
PDS 2 [[tests 1|https://ci.ignite.apache.org/viewLog.html?buildId=1800117]]
* IgnitePdsTestSuite2:
IgniteWalReaderTest.testArchiveIncompleteSegmentAfterInactivity - 10,5% fails
in master.
Cache 1 [[tests 2|https://ci.ignite.apache.org/viewLog.html?buildId=1800137]]
* IgniteBinaryCacheTestSuite: IgniteCommunicationBalanceTest.testBalance2 -
0,0% fails in master.
* IgniteBinaryCacheTestSuite:
DataStreamerImplSelfTest.testAllOperationFinishedBeforeFutureCompletion - 0,0%
fails in
[jira] [Reopened] (IGNITE-9185) Collect and check update counters visited during WAL rebalance
[ https://issues.apache.org/jira/browse/IGNITE-9185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov reopened IGNITE-9185: --- > Collect and check update counters visited during WAL rebalance > -- > > Key: IGNITE-9185 > URL: https://issues.apache.org/jira/browse/IGNITE-9185 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Critical > Fix For: 2.7 > > > Currently we don't check what update counters we visit during WAL iteration > and what data we send to a demander node. There can be situation, that we met > last requested update counter in WAL and stop rebalance process, while due to > possible DataRecord's reordering we miss some updates after. > If rebalance process breaks due to end of WAL, but not all data records were > visit, we can easily check what records are missed, cancel rebalance and > print useful information to log for further debug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9185) Collect and check update counters visited during WAL rebalance
[ https://issues.apache.org/jira/browse/IGNITE-9185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov resolved IGNITE-9185. --- Resolution: Won't Fix > Collect and check update counters visited during WAL rebalance > -- > > Key: IGNITE-9185 > URL: https://issues.apache.org/jira/browse/IGNITE-9185 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Critical > Fix For: 2.7 > > > Currently we don't check what update counters we visit during WAL iteration > and what data we send to a demander node. There can be situation, that we met > last requested update counter in WAL and stop rebalance process, while due to > possible DataRecord's reordering we miss some updates after. > If rebalance process breaks due to end of WAL, but not all data records were > visit, we can easily check what records are missed, cancel rebalance and > print useful information to log for further debug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9464) MVCC TX: cache basic operations supports Mvcc tx mode.
[ https://issues.apache.org/jira/browse/IGNITE-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9464: - Summary: MVCC TX: cache basic operations supports Mvcc tx mode. (was: MVCC TX: cache GET supports Mvcc tx mode.) > MVCC TX: cache basic operations supports Mvcc tx mode. > -- > > Key: IGNITE-9464 > URL: https://issues.apache.org/jira/browse/IGNITE-9464 > Project: Ignite > Issue Type: New Feature > Components: cache, mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > > Make cache -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9464) MVCC TX: cache GET supports Mvcc tx mode.
[ https://issues.apache.org/jira/browse/IGNITE-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9464: - Description: Make cache > MVCC TX: cache GET supports Mvcc tx mode. > - > > Key: IGNITE-9464 > URL: https://issues.apache.org/jira/browse/IGNITE-9464 > Project: Ignite > Issue Type: New Feature > Components: cache, mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > > Make cache -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9185) Collect and check update counters visited during WAL rebalance
[ https://issues.apache.org/jira/browse/IGNITE-9185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov resolved IGNITE-9185. --- Resolution: Fixed Broken recovery will be fixed by linked ticket. > Collect and check update counters visited during WAL rebalance > -- > > Key: IGNITE-9185 > URL: https://issues.apache.org/jira/browse/IGNITE-9185 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Critical > Fix For: 2.7 > > > Currently we don't check what update counters we visit during WAL iteration > and what data we send to a demander node. There can be situation, that we met > last requested update counter in WAL and stop rebalance process, while due to > possible DataRecord's reordering we miss some updates after. > If rebalance process breaks due to end of WAL, but not all data records were > visit, we can easily check what records are missed, cancel rebalance and > print useful information to log for further debug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9538) MVCC TX: Send partition update counters to backup nodes on prepare state.
Igor Seliverstov created IGNITE-9538: Summary: MVCC TX: Send partition update counters to backup nodes on prepare state. Key: IGNITE-9538 URL: https://issues.apache.org/jira/browse/IGNITE-9538 Project: Ignite Issue Type: Task Components: cache, mvcc Reporter: Igor Seliverstov Assignee: Igor Seliverstov Fix For: 2.7 There are several issues with partition update counters consistency in transactional caches. The next approach solves most of them: # Count per-partition updates # on prepare state on primary node update current partition counter incrementing it by per-partition updates count and send initial value with updates count to backup nodes # on backup nodes hold all pending updates and update partition update counter applying the lowest gapless update (on tx finish). # on historical rebalance use partition update counter as start point. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9539) Add SQL column precision existence check if scale parameter is setted
PetrovMikhail created IGNITE-9539: - Summary: Add SQL column precision existence check if scale parameter is setted Key: IGNITE-9539 URL: https://issues.apache.org/jira/browse/IGNITE-9539 Project: Ignite Issue Type: Bug Reporter: PetrovMikhail Assignee: PetrovMikhail We should check situation when user sets only scale parameter without precision for column, while creating SQL table. According to [http://www.h2database.com/html/datatypes.html#decimal_type] it's not valid behavior. Currently, we ignore it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8855) Client nodes make a lot of attempts to join topology if EXCHANGE_HISTORY is significantly smaller than number of clients
[ https://issues.apache.org/jira/browse/IGNITE-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-8855: - Assignee: Ivan Bessonov > Client nodes make a lot of attempts to join topology if EXCHANGE_HISTORY is > significantly smaller than number of clients > > > Key: IGNITE-8855 > URL: https://issues.apache.org/jira/browse/IGNITE-8855 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Ivan Bessonov >Priority: Major > > After fixing client nodes hangs in IGNITE-8567 another issue was found out: > when EXCHANGE_HISTORY is significantly smaller than number of clients they > interfere with each other on initial exchange and make reconnect attempts > over and over again. > To avoid this random delay (maybe exponential) should be added for clients > before making new reconnect attempt. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6173) SQL: do not start caches on client nodes
[
https://issues.apache.org/jira/browse/IGNITE-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610458#comment-16610458
]
Andrew Mashenkov commented on IGNITE-6173:
--
I don't like multipurpose method
UpdatePlanBuilder.isMvccEnabledAndStartLazyCaches(parser).
Why we can't return complex result with mvcc flag and list of lazy cache names
and then start cache to make code more readable.
List of lazy caches expects to be short mostly.
> SQL: do not start caches on client nodes
>
>
> Key: IGNITE-6173
> URL: https://issues.apache.org/jira/browse/IGNITE-6173
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: sql-stability
>
> When cache is started, this even is distributed through custom discovery
> message. Server nodes start the cache, client nodes do nothing until cache is
> requested explicitly. At the same time H2 database objects are created only
> when cache is really started.
> For this reason query parsing could lead to {{TABLE NOT FOUND}}, {{INDEX NOT
> FOUND}}, etc. errors. If such exception is observed, we force start of all
> known cache on a client and then retry. See
> {{GridCacheProcessor#createMissingQueryCaches}} method.
> First, client node cache start leads to another custom discovery message. So
> query performance may suffer. Second, this is not needed! We already have all
> necessary cache info in discovery.
> Let's try to find a way to use available discovery data and do not start
> cache on a client for SQL query execution.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8552) Unable to use date as primary key
[
https://issues.apache.org/jira/browse/IGNITE-8552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610447#comment-16610447
]
Taras Ledkov commented on IGNITE-8552:
--
[~SGrimstad], my comments:
| Codestyle | # Please fix empty lines at {{CreateTableWithDateKeySelfTest}}
# {{CreateTableWithDateKeySelfTest.Tab}} is unused |
| Documentation | not required |
| Binary compatibility | OK |
| Tests | OK |
| Comments | - Does make sense similar changes for TIME and TIMESTAMP types?
Please fix there or create separate issues. |
> Unable to use date as primary key
> -
>
> Key: IGNITE-8552
> URL: https://issues.apache.org/jira/browse/IGNITE-8552
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Pavel Vinokurov
>Assignee: Sergey Grimstad
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: IGNITE-8552_implemented.patch
>
>
> It' is unable to create cache via ddl:
> create table tab(id date primary key, date_field date);
> Result:
> ERROR CacheAffinitySharedManager - Failed to initialize cache. Will try to
> rollback cache start routine. [cacheName=SQL_PUBLIC_T3]
> class org.apache.ignite.IgniteCheckedException: Failed to find value class in
> the node classpath (use default marshaller to enable binary objects) :
> SQL_PUBLIC_T3_e90848b2_fe30_4adb_a934_6e13ca0eb409
> at
> org.apache.ignite.internal.processors.query.QueryUtils.typeForQueryEntity(QueryUtils.java:426)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9503) Visor CMD shows wrong REPLICATED cache max size
[
https://issues.apache.org/jira/browse/IGNITE-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasiliy Sisko reassigned IGNITE-9503:
-
Assignee: Pavel Konstantinov (was: Vasiliy Sisko)
> Visor CMD shows wrong REPLICATED cache max size
> ---
>
> Key: IGNITE-9503
> URL: https://issues.apache.org/jira/browse/IGNITE-9503
> Project: Ignite
> Issue Type: Task
> Components: visor
>Affects Versions: 2.5
>Reporter: Denis Magda
>Assignee: Pavel Konstantinov
>Priority: Critical
> Fix For: 2.7
>
> Attachments: image-2018-09-11-11-14-02-347.png
>
>
> Started 2 nodes with a single replicated cache. Preloaded _50_ entries
> there.
> Visor CMD *cache* command shows a wrong total
> {code}
> ++
> |Name(@)|Mode| Nodes | Entries (Heap /
> Off-heap) | Hits| Misses | Reads | Writes |
> ++
> | CacheDataStreamerExample(@c0) | REPLICATED | 2 | min: 246106 (0 /
> 246106) | min: 0| min: 0| min: 0| min: 0|
> | || | avg: 25.00 (0.00 /
> 25.00) | avg: 0.00 | avg: 0.00 | avg: 0.00 | avg: 0.00 |
> | || | max: 253894 (0 /
> 253894) | max: 0| max: 0| max: 0| max: 0|
> ++
> {code}
> You find a correct total number only if *cache -a* is used and you calculate
> the sum of entries on each node manually:
> {code}
> +===+
> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
>Size | Hi/Mi/Rd/Wr |
> +===+
> | 44A2CF9C(@n1), 192.168.1.64 | 4| 19.63 % | 0.43 % | 00:01:46.229 |
> Total: 253894| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 253894 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +-+--+---+--+--+--+-+
> | 72DEC7B5(@n0), 192.168.1.64 | 4| 9.69 %| 0.50 % | 00:02:00.456 |
> Total: 246106| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 246106 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +---+
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9503) Visor CMD shows wrong REPLICATED cache max size
[
https://issues.apache.org/jira/browse/IGNITE-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610431#comment-16610431
]
Vasiliy Sisko edited comment on IGNITE-9503 at 9/11/18 10:58 AM:
-
# Added *Total entries (Heap / Off-heap)* column in a caches table to show
total number of primary entries for cache in topology.
# *Entries (Heap / Off-heap)* column in the caches table renamed to *Primary
entries (Heap / Off-heap)*
# In a table with aggregated cache metrics added a row with *Total entries
(Heap / Off-heap)* value. See description in 1 line.
# *Size* column in a detailed cache by nodes table renamed to *Size (Primary /
Backup)*. Now it show sum of primary and backup keys on node and number of keys
in primary and backup partitions.
# *Size (Primary / Backup)* column now show for *Off-Heap Memory* value
while that metrics is not implemented in Grid.
was (Author: vsisko):
# Added *Total entries (Heap / Off-heap)* column in a caches table to show
total number of primary entries for cache in topology.
# *Entries (Heap / Off-heap)* column in the caches table renamed to *Primary
entries (Heap / Off-heap)*
# In a table with aggregated cache metrics added a row with *Total entries
(Heap / Off-heap)* value. See description in 1 line.
# *Size* column in a detailed cache by nodes table renamed to *Size (Primary /
Backup)*. Now it show sum of primary and backup keys on node and number of keys
in primary and backup partitions.
> Visor CMD shows wrong REPLICATED cache max size
> ---
>
> Key: IGNITE-9503
> URL: https://issues.apache.org/jira/browse/IGNITE-9503
> Project: Ignite
> Issue Type: Task
> Components: visor
>Affects Versions: 2.5
>Reporter: Denis Magda
>Assignee: Vasiliy Sisko
>Priority: Critical
> Fix For: 2.7
>
> Attachments: image-2018-09-11-11-14-02-347.png
>
>
> Started 2 nodes with a single replicated cache. Preloaded _50_ entries
> there.
> Visor CMD *cache* command shows a wrong total
> {code}
> ++
> |Name(@)|Mode| Nodes | Entries (Heap /
> Off-heap) | Hits| Misses | Reads | Writes |
> ++
> | CacheDataStreamerExample(@c0) | REPLICATED | 2 | min: 246106 (0 /
> 246106) | min: 0| min: 0| min: 0| min: 0|
> | || | avg: 25.00 (0.00 /
> 25.00) | avg: 0.00 | avg: 0.00 | avg: 0.00 | avg: 0.00 |
> | || | max: 253894 (0 /
> 253894) | max: 0| max: 0| max: 0| max: 0|
> ++
> {code}
> You find a correct total number only if *cache -a* is used and you calculate
> the sum of entries on each node manually:
> {code}
> +===+
> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
>Size | Hi/Mi/Rd/Wr |
> +===+
> | 44A2CF9C(@n1), 192.168.1.64 | 4| 19.63 % | 0.43 % | 00:01:46.229 |
> Total: 253894| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 253894 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +-+--+---+--+--+--+-+
> | 72DEC7B5(@n0), 192.168.1.64 | 4| 9.69 %| 0.50 % | 00:02:00.456 |
> Total: 246106| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 246106 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +---+
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9503) Visor CMD shows wrong REPLICATED cache max size
[
https://issues.apache.org/jira/browse/IGNITE-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasiliy Sisko reassigned IGNITE-9503:
-
Assignee: Alexey Kuznetsov (was: Pavel Konstantinov)
> Visor CMD shows wrong REPLICATED cache max size
> ---
>
> Key: IGNITE-9503
> URL: https://issues.apache.org/jira/browse/IGNITE-9503
> Project: Ignite
> Issue Type: Task
> Components: visor
>Affects Versions: 2.5
>Reporter: Denis Magda
>Assignee: Alexey Kuznetsov
>Priority: Critical
> Fix For: 2.7
>
> Attachments: image-2018-09-11-11-14-02-347.png
>
>
> Started 2 nodes with a single replicated cache. Preloaded _50_ entries
> there.
> Visor CMD *cache* command shows a wrong total
> {code}
> ++
> |Name(@)|Mode| Nodes | Entries (Heap /
> Off-heap) | Hits| Misses | Reads | Writes |
> ++
> | CacheDataStreamerExample(@c0) | REPLICATED | 2 | min: 246106 (0 /
> 246106) | min: 0| min: 0| min: 0| min: 0|
> | || | avg: 25.00 (0.00 /
> 25.00) | avg: 0.00 | avg: 0.00 | avg: 0.00 | avg: 0.00 |
> | || | max: 253894 (0 /
> 253894) | max: 0| max: 0| max: 0| max: 0|
> ++
> {code}
> You find a correct total number only if *cache -a* is used and you calculate
> the sum of entries on each node manually:
> {code}
> +===+
> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
>Size | Hi/Mi/Rd/Wr |
> +===+
> | 44A2CF9C(@n1), 192.168.1.64 | 4| 19.63 % | 0.43 % | 00:01:46.229 |
> Total: 253894| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 253894 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +-+--+---+--+--+--+-+
> | 72DEC7B5(@n0), 192.168.1.64 | 4| 9.69 %| 0.50 % | 00:02:00.456 |
> Total: 246106| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 246106 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +---+
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9531) ZookeeperDiscovery testClientReconnect is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610437#comment-16610437
]
ASF GitHub Bot commented on IGNITE-9531:
GitHub user avplatonov opened a pull request:
https://github.com/apache/ignite/pull/4722
IGNITE-9531: ZookeeperDiscovery testClientReconnect is flaky in master
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9531
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4722.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 #4722
commit f6ab10a1a78f4c17ba133acdbae76516b5c0d0ac
Author: Alexey Platonov
Date: 2018-09-11T10:55:27Z
add test assertions
commit 5d79313bd92d66c562365d8287536b011c0597cc
Author: Alexey Platonov
Date: 2018-09-11T10:55:44Z
Merge branch 'master' of https://github.com/apache/ignite into ignite-9531
> ZookeeperDiscovery testClientReconnect is flaky in master
> -
>
> Key: IGNITE-9531
> URL: https://issues.apache.org/jira/browse/IGNITE-9531
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Platonov
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> The test IgniteClientReconnectCacheTest#testReconnect periodically.
> From the logs I see that the hang is caused by assertion error:
> {code}
> junit.framework.AssertionFailedError: expected:<22> but was:
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:86)
> at junit.framework.TestCase.assertEquals(TestCase.java:253)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnect(IgniteClientReconnectCacheTest.java:321)
> 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:2177)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9503) Visor CMD shows wrong REPLICATED cache max size
[
https://issues.apache.org/jira/browse/IGNITE-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610431#comment-16610431
]
Vasiliy Sisko commented on IGNITE-9503:
---
# Added *Total entries (Heap / Off-heap)* column in a caches table to show
total number of primary entries for cache in topology.
# *Entries (Heap / Off-heap)* column in the caches table renamed to *Primary
entries (Heap / Off-heap)*
# In a table with aggregated cache metrics added a row with *Total entries
(Heap / Off-heap)* value. See description in 1 line.
# *Size* column in a detailed cache by nodes table renamed to *Size (Primary /
Backup)*. Now it show sum of primary and backup keys on node and number of keys
in primary and backup partitions.
> Visor CMD shows wrong REPLICATED cache max size
> ---
>
> Key: IGNITE-9503
> URL: https://issues.apache.org/jira/browse/IGNITE-9503
> Project: Ignite
> Issue Type: Task
> Components: visor
>Affects Versions: 2.5
>Reporter: Denis Magda
>Assignee: Vasiliy Sisko
>Priority: Critical
> Fix For: 2.7
>
> Attachments: image-2018-09-11-11-14-02-347.png
>
>
> Started 2 nodes with a single replicated cache. Preloaded _50_ entries
> there.
> Visor CMD *cache* command shows a wrong total
> {code}
> ++
> |Name(@)|Mode| Nodes | Entries (Heap /
> Off-heap) | Hits| Misses | Reads | Writes |
> ++
> | CacheDataStreamerExample(@c0) | REPLICATED | 2 | min: 246106 (0 /
> 246106) | min: 0| min: 0| min: 0| min: 0|
> | || | avg: 25.00 (0.00 /
> 25.00) | avg: 0.00 | avg: 0.00 | avg: 0.00 | avg: 0.00 |
> | || | max: 253894 (0 /
> 253894) | max: 0| max: 0| max: 0| max: 0|
> ++
> {code}
> You find a correct total number only if *cache -a* is used and you calculate
> the sum of entries on each node manually:
> {code}
> +===+
> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
>Size | Hi/Mi/Rd/Wr |
> +===+
> | 44A2CF9C(@n1), 192.168.1.64 | 4| 19.63 % | 0.43 % | 00:01:46.229 |
> Total: 253894| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 253894 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +-+--+---+--+--+--+-+
> | 72DEC7B5(@n0), 192.168.1.64 | 4| 9.69 %| 0.50 % | 00:02:00.456 |
> Total: 246106| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 246106 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +---+
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9333) Adding page with simple statistic for last 50 runs.
[ https://issues.apache.org/jira/browse/IGNITE-9333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610392#comment-16610392 ] Anton Kalashnikov commented on IGNITE-9333: --- [~dpavlov], now it again looks good for me. I think it can be merged to master. > Adding page with simple statistic for last 50 runs. > --- > > Key: IGNITE-9333 > URL: https://issues.apache.org/jira/browse/IGNITE-9333 > Project: Ignite > Issue Type: Sub-task >Reporter: Eduard Shangareev >Assignee: Nikolai Kulagin >Priority: Major > > Ok, I am proposing to add a new page which would be named "Statistic". > It should show last 50 "Run All" for master, the columns: > ||Id||Total tests||Failed tests||Ignored tests|| Muted tests||Total issues > (count and the list of TC configurations with links) || Total run time || > Also, we need to calculate the statistic. > Totals (all unique tests with issues), average issues/fails per run, median, > max, min. > Total issues = Exit codes + JVM Crashes + OOMs + other issues which caused TC > configuration fail -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9377) Handle print critical failures to the PR
[
https://issues.apache.org/jira/browse/IGNITE-9377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16609070#comment-16609070
]
Ryabov Dmitrii edited comment on IGNITE-9377 at 9/11/18 10:09 AM:
--
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#cc|titleBGColor=#f7d6c1}
Cache 6 [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1800125]]
* IgniteCache150ClientsTest.test150Clients (last started)
Binary Objects (Simple Mapper Basic) [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1800057]]
* TxSavepointsTransactionalCacheTest.testPutWithExplicitTx (last started)
Basic 1 [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1800154]]
* TxSavepointsTransactionalCacheTest.testPutWithExplicitTx (last started)
Platform C++ (Linux) [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1800102]]
Cache (Failover) 2 [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1800130]]
* IgniteCacheFailoverTestSuite2:
CacheAsyncOperationsFailoverTxTest.testPutAllAsyncFailover - 76,5% fails in
master.
Platform .NET (Long Running) [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=1800109]]
* exe: ExamplesTest.TestRemoteNodes(BinaryModeExample) - 100,0% fails in
master.
* exe: ExamplesTest.TestRemoteNodes(LinqExample) - 100,0% fails in master.
* exe: ExamplesTest.TestRemoteNodes(SqlExample) - 100,0% fails in master.
* exe: CacheAbstractTest.TestCacheConfigurationExpiryPolicy - 10,0% fails in
master.
* exe: CacheAbstractTest.TestCacheConfigurationExpiryPolicy - 10,0% fails in
master.
PDS 2 [[tests 1|https://ci.ignite.apache.org/viewLog.html?buildId=1800117]]
* IgnitePdsTestSuite2:
IgniteWalReaderTest.testArchiveIncompleteSegmentAfterInactivity - 10,5% fails
in master.
Cache 1 [[tests 2|https://ci.ignite.apache.org/viewLog.html?buildId=1800137]]
* IgniteBinaryCacheTestSuite: IgniteCommunicationBalanceTest.testBalance2 -
0,0% fails in master.
* IgniteBinaryCacheTestSuite:
DataStreamerImplSelfTest.testAllOperationFinishedBeforeFutureCompletion - 0,0%
fails in master.
ZooKeeper (Discovery) 1 [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=1800100]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_4 - 0,0% fails in master.
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_5 - 0,0% fails in master.
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testReconnectDisabled_ConnectionLost - 0,0% fails in
master.{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1800157&buildTypeId=IgniteTests24Java8_RunAll]
was (Author: somefire):
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}[Basic
1|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Basic1&branch=pull%2F1815%2Fhead&tab=buildTypeStatusDiv]
[[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1800154]]
* TxSavepointsTransactionalCacheTest.testPutWithExplicitTx (last started)
[Binary Objects (Simple Mapper
Basic)|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BinaryObjectsSimpleMapperBasic&branch=pull%2F1815%2Fhead&tab=buildTypeStatusDiv]
[[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1800057]]
* TxSavepointsTransactionalCacheTest.testPutWithExplicitTx (last started)
[Cache
6|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache6&branch=pull%2F1815%2Fhead&tab=buildTypeStatusDiv]
[[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1800125]]
* IgniteCache150ClientsTest.test150Clients (last started)
[Platform C++
(Linux)|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCLinux&branch=pull%2F1815%2Fhead&tab=buildTypeStatusDiv]
[[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1800102]]
[SPI|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Spi&branch=pull%2F1815%2Fhead&tab=buildTypeStatusDiv]
[[tests 1 |https://ci.ignite.apache.org/viewLog.html?buildId=1800093]]
* IgniteSpiTestSuite:
TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished
[Basic
2|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Basic2&branch=pull%2F1815%2Fhead&tab=buildTypeStatusDiv]
[[tests 1 |https://ci.ignite.apache.org/viewLog.html?buildId=1800055]]
* IgniteServiceConfigVariationsFullApiTestSuite:
IgniteServiceConfigVariationsFullApiTest.testClusterSingletonDeploy
[Compute
(Grid)|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ComputeGrid&branch=pull%2F1815%2Fhead&tab=buildTypeStatusDiv]
[[tests 1 |https://ci.ignite.apache.org/viewLog.html?buildId=
[jira] [Commented] (IGNITE-8545) If queryParallelism in nodes' caches configurations differ, query may hang, assert or return incomplete results
[ https://issues.apache.org/jira/browse/IGNITE-8545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610384#comment-16610384 ] Andrew Mashenkov commented on IGNITE-8545: -- [~Maxim.Pudov], I've add few comments to the PR. Please, take a look. > If queryParallelism in nodes' caches configurations differ, query may hang, > assert or return incomplete results > --- > > Key: IGNITE-8545 > URL: https://issues.apache.org/jira/browse/IGNITE-8545 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.6 >Reporter: Ilya Kasnacheev >Assignee: Maxim Pudov >Priority: Critical > Fix For: 2.7 > > Attachments: IgniteSqlSplitterQueryParallelismTest.java > > > I imagine it should not. See the attached file. > It happens both with client nodes and with server nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9377) Handle print critical failures to the PR
[ https://issues.apache.org/jira/browse/IGNITE-9377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610382#comment-16610382 ] ASF GitHub Bot commented on IGNITE-9377: SomeFire opened a new pull request #6: IGNITE-9377 Handle print crit failures from RunAll to the JIRA ticket URL: https://github.com/apache/ignite-teamcity-bot/pull/6 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Handle print critical failures to the PR > > > Key: IGNITE-9377 > URL: https://issues.apache.org/jira/browse/IGNITE-9377 > Project: Ignite > Issue Type: Sub-task >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > > Create a button by clicking on which the info about critical failures will be > written in the PR. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9376) Create table with critical failures
[ https://issues.apache.org/jira/browse/IGNITE-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610381#comment-16610381 ] Ryabov Dmitrii commented on IGNITE-9376: [~dpavlov], currently blockers are tests with fail rate <4% or nonflacky tests. Looks like tests with 100% fail rate aren't marked as flacky. I think we should mute such tests and create tickets for them. > Create table with critical failures > --- > > Key: IGNITE-9376 > URL: https://issues.apache.org/jira/browse/IGNITE-9376 > Project: Ignite > Issue Type: Sub-task >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Major > > Create separate table for critical failures (suite timouts, suite non-zero > exit codes, etc) and new tests (failure rate 0.0%) on the PR analysis page of > TCH. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9518) getPagesFillFactor returns NaN for empty region
[ https://issues.apache.org/jira/browse/IGNITE-9518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610376#comment-16610376 ] ASF GitHub Bot commented on IGNITE-9518: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4717 > getPagesFillFactor returns NaN for empty region > --- > > Key: IGNITE-9518 > URL: https://issues.apache.org/jira/browse/IGNITE-9518 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.7 > > > PagesFillFactor attribute of DataRegionMetrics / DataStorageMetrics MX bean > returns NaN for empty region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9518) getPagesFillFactor returns NaN for empty region
[ https://issues.apache.org/jira/browse/IGNITE-9518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610373#comment-16610373 ] Dmitriy Govorukhin commented on IGNITE-9518: [~ibessonov] Changes look good, merged to master. Thank for the contribution! > getPagesFillFactor returns NaN for empty region > --- > > Key: IGNITE-9518 > URL: https://issues.apache.org/jira/browse/IGNITE-9518 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.7 > > > PagesFillFactor attribute of DataRegionMetrics / DataStorageMetrics MX bean > returns NaN for empty region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9376) Create table with critical failures
[ https://issues.apache.org/jira/browse/IGNITE-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610371#comment-16610371 ] Dmitriy Pavlov commented on IGNITE-9376: [~SomeFire] I have an idea why it is so, the reason of it - data of recent failures (And as result, flaky detection) is based on PR branch instead of the base (master branch). org/apache/ignite/ci/web/model/current/TestFailure.java:219 I will fix it or create an additional unassigned issue. I would like to think if there can be some refactoring with there rates. > Create table with critical failures > --- > > Key: IGNITE-9376 > URL: https://issues.apache.org/jira/browse/IGNITE-9376 > Project: Ignite > Issue Type: Sub-task >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Major > > Create separate table for critical failures (suite timouts, suite non-zero > exit codes, etc) and new tests (failure rate 0.0%) on the PR analysis page of > TCH. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9376) Create table with critical failures
[ https://issues.apache.org/jira/browse/IGNITE-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610368#comment-16610368 ] Ryabov Dmitrii commented on IGNITE-9376: I'll check it. > Create table with critical failures > --- > > Key: IGNITE-9376 > URL: https://issues.apache.org/jira/browse/IGNITE-9376 > Project: Ignite > Issue Type: Sub-task >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Major > > Create separate table for critical failures (suite timouts, suite non-zero > exit codes, etc) and new tests (failure rate 0.0%) on the PR analysis page of > TCH. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9376) Create table with critical failures
[ https://issues.apache.org/jira/browse/IGNITE-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610360#comment-16610360 ] Dmitriy Pavlov commented on IGNITE-9376: [~SomeFire], please check if this feature is working properly: https://mtcga.gridgain.com/pr.html?serverId=apache&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull%2F4481%2Fhead&action=Latest I can see that tests with a fail rate of 100% are considered as blockers for PR. > Create table with critical failures > --- > > Key: IGNITE-9376 > URL: https://issues.apache.org/jira/browse/IGNITE-9376 > Project: Ignite > Issue Type: Sub-task >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Major > > Create separate table for critical failures (suite timouts, suite non-zero > exit codes, etc) and new tests (failure rate 0.0%) on the PR analysis page of > TCH. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9365) Force backups to different AWS availability zones using only Spring XML
[ https://issues.apache.org/jira/browse/IGNITE-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610353#comment-16610353 ] Dmitriy Pavlov commented on IGNITE-9365: Hi [~syssoftsol], I've triggered run-all for this PR: https://ci.ignite.apache.org/viewQueued.html?itemId=1840220&tab=queuedBuildOverviewTab > Force backups to different AWS availability zones using only Spring XML > --- > > Key: IGNITE-9365 > URL: https://issues.apache.org/jira/browse/IGNITE-9365 > Project: Ignite > Issue Type: Improvement > Components: cache > Environment: >Reporter: David Harvey >Assignee: David Harvey >Priority: Minor > Fix For: 2.7 > > Attachments: master_947962f785_availability_zones_via_spring.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > As a developer, I want to be able to force cache backups each to a different > "Availability Zone", when I'm running out-of-the-box Ignite, without > additional Jars installed. "Availability zone" is a AWS feature with > different names for the same function by other cloud providers. A single > availability zone has the characteristic that some or all of the EC2 > instances in that zone can fail together due to a single fault. You have no > control over the hosts on which the EC2 instance VMs run on in AWS, except by > controlling the availability zone . > > I could write a few lines of a custom affinityBackupFilter, and configure it > a RendezvousAffinityFunction, but then I have to get it deployed on all nodes > in the cluster, and peer class loading will not work to this. The code to > do this should just be part of Ignite. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9333) Adding page with simple statistic for last 50 runs.
[ https://issues.apache.org/jira/browse/IGNITE-9333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610347#comment-16610347 ] Anton Kalashnikov commented on IGNITE-9333: --- [~dpavlov], I left one more note to last changes. When it will be fixed this task will ready to merge. > Adding page with simple statistic for last 50 runs. > --- > > Key: IGNITE-9333 > URL: https://issues.apache.org/jira/browse/IGNITE-9333 > Project: Ignite > Issue Type: Sub-task >Reporter: Eduard Shangareev >Assignee: Nikolai Kulagin >Priority: Major > > Ok, I am proposing to add a new page which would be named "Statistic". > It should show last 50 "Run All" for master, the columns: > ||Id||Total tests||Failed tests||Ignored tests|| Muted tests||Total issues > (count and the list of TC configurations with links) || Total run time || > Also, we need to calculate the statistic. > Totals (all unique tests with issues), average issues/fails per run, median, > max, min. > Total issues = Exit codes + JVM Crashes + OOMs + other issues which caused TC > configuration fail -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9537) .NET: Change MVCC enabled configuration.
Roman Kondakov created IGNITE-9537:
--
Summary: .NET: Change MVCC enabled configuration.
Key: IGNITE-9537
URL: https://issues.apache.org/jira/browse/IGNITE-9537
Project: Ignite
Issue Type: Task
Components: mvcc, platforms
Reporter: Roman Kondakov
Fix For: 2.7
MVCC enabled configuration has changed from the node global flag to per-cache
atomicity mode setting {{CacheAtomicityMode#TRANSACTIONAL_SNAPSHOT}}. We need
to reflect this change in .NET API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9518) getPagesFillFactor returns NaN for empty region
[ https://issues.apache.org/jira/browse/IGNITE-9518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-9518: -- Summary: getPagesFillFactor returns NaN for empty region (was: getPagesFillFactor returns NaN for empty cache) > getPagesFillFactor returns NaN for empty region > --- > > Key: IGNITE-9518 > URL: https://issues.apache.org/jira/browse/IGNITE-9518 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.7 > > > PagesFillFactor attribute of DataRegionMetrics / DataStorageMetrics MX bean > returns NaN for empty region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9536) CPP/ODBC: Change MVCC enabled configuration.
[
https://issues.apache.org/jira/browse/IGNITE-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-9536:
---
Component/s: platforms
> CPP/ODBC: Change MVCC enabled configuration.
>
>
> Key: IGNITE-9536
> URL: https://issues.apache.org/jira/browse/IGNITE-9536
> Project: Ignite
> Issue Type: Task
> Components: mvcc, odbc, platforms
>Reporter: Roman Kondakov
>Priority: Major
> Labels: cpp
> Fix For: 2.7
>
>
> MVCC enabled configuration has changed from the node global flag to per-cache
> atomicity mode setting {{CacheAtomicityMode#TRANSACTIONAL_SNAPSHOT}}. We need
> to reflect this change in CPP/ODBC API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9518) getPagesFillFactor returns NaN for empty cache
[ https://issues.apache.org/jira/browse/IGNITE-9518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-9518: -- Description: PagesFillFactor attribute of DataRegionMetrics / DataStorageMetrics MX bean returns NaN for empty region. (was: PagesFillFactor attribute of DataRegionMetrics / DataStorageMetrics MX bean returns NaN for empty cache.) > getPagesFillFactor returns NaN for empty cache > -- > > Key: IGNITE-9518 > URL: https://issues.apache.org/jira/browse/IGNITE-9518 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.7 > > > PagesFillFactor attribute of DataRegionMetrics / DataStorageMetrics MX bean > returns NaN for empty region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9503) Visor CMD shows wrong REPLICATED cache max size
[
https://issues.apache.org/jira/browse/IGNITE-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610337#comment-16610337
]
Pavel Konstantinov edited comment on IGNITE-9503 at 9/11/18 9:31 AM:
-
# Add a space between numbers, f.e. (from your screenshot) '0 / 5571'
# print 'n/a' instead of zero numbers
after that, the ticket can be merged
was (Author: pkonstantinov):
# Add a space between numbers, f.e. (from your screenshot) '0 / 5571'
# print 'n/a' instead of zero numbers
after that the ticket can be merged
> Visor CMD shows wrong REPLICATED cache max size
> ---
>
> Key: IGNITE-9503
> URL: https://issues.apache.org/jira/browse/IGNITE-9503
> Project: Ignite
> Issue Type: Task
> Components: visor
>Affects Versions: 2.5
>Reporter: Denis Magda
>Assignee: Vasiliy Sisko
>Priority: Critical
> Fix For: 2.7
>
> Attachments: image-2018-09-11-11-14-02-347.png
>
>
> Started 2 nodes with a single replicated cache. Preloaded _50_ entries
> there.
> Visor CMD *cache* command shows a wrong total
> {code}
> ++
> |Name(@)|Mode| Nodes | Entries (Heap /
> Off-heap) | Hits| Misses | Reads | Writes |
> ++
> | CacheDataStreamerExample(@c0) | REPLICATED | 2 | min: 246106 (0 /
> 246106) | min: 0| min: 0| min: 0| min: 0|
> | || | avg: 25.00 (0.00 /
> 25.00) | avg: 0.00 | avg: 0.00 | avg: 0.00 | avg: 0.00 |
> | || | max: 253894 (0 /
> 253894) | max: 0| max: 0| max: 0| max: 0|
> ++
> {code}
> You find a correct total number only if *cache -a* is used and you calculate
> the sum of entries on each node manually:
> {code}
> +===+
> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
>Size | Hi/Mi/Rd/Wr |
> +===+
> | 44A2CF9C(@n1), 192.168.1.64 | 4| 19.63 % | 0.43 % | 00:01:46.229 |
> Total: 253894| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 253894 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +-+--+---+--+--+--+-+
> | 72DEC7B5(@n0), 192.168.1.64 | 4| 9.69 %| 0.50 % | 00:02:00.456 |
> Total: 246106| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 246106 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +---+
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9536) CPP/ODBC: Change MVCC enabled configuration.
[
https://issues.apache.org/jira/browse/IGNITE-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-9536:
---
Labels: cpp (was: )
> CPP/ODBC: Change MVCC enabled configuration.
>
>
> Key: IGNITE-9536
> URL: https://issues.apache.org/jira/browse/IGNITE-9536
> Project: Ignite
> Issue Type: Task
> Components: mvcc, odbc, platforms
>Reporter: Roman Kondakov
>Priority: Major
> Labels: cpp
> Fix For: 2.7
>
>
> MVCC enabled configuration has changed from the node global flag to per-cache
> atomicity mode setting {{CacheAtomicityMode#TRANSACTIONAL_SNAPSHOT}}. We need
> to reflect this change in CPP/ODBC API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9503) Visor CMD shows wrong REPLICATED cache max size
[
https://issues.apache.org/jira/browse/IGNITE-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610337#comment-16610337
]
Pavel Konstantinov edited comment on IGNITE-9503 at 9/11/18 9:29 AM:
-
# Add a space between numbers, f.e. (from your screenshot) '0 / 5571'
# print 'n/a' instead of zero numbers
after that the ticket can be merged
was (Author: pkonstantinov):
# Add a space between numbers, f.e. (from your screenshot) '0 / 5571'
# print 'n/a' instead of zero numbers
> Visor CMD shows wrong REPLICATED cache max size
> ---
>
> Key: IGNITE-9503
> URL: https://issues.apache.org/jira/browse/IGNITE-9503
> Project: Ignite
> Issue Type: Task
> Components: visor
>Affects Versions: 2.5
>Reporter: Denis Magda
>Assignee: Vasiliy Sisko
>Priority: Critical
> Fix For: 2.7
>
> Attachments: image-2018-09-11-11-14-02-347.png
>
>
> Started 2 nodes with a single replicated cache. Preloaded _50_ entries
> there.
> Visor CMD *cache* command shows a wrong total
> {code}
> ++
> |Name(@)|Mode| Nodes | Entries (Heap /
> Off-heap) | Hits| Misses | Reads | Writes |
> ++
> | CacheDataStreamerExample(@c0) | REPLICATED | 2 | min: 246106 (0 /
> 246106) | min: 0| min: 0| min: 0| min: 0|
> | || | avg: 25.00 (0.00 /
> 25.00) | avg: 0.00 | avg: 0.00 | avg: 0.00 | avg: 0.00 |
> | || | max: 253894 (0 /
> 253894) | max: 0| max: 0| max: 0| max: 0|
> ++
> {code}
> You find a correct total number only if *cache -a* is used and you calculate
> the sum of entries on each node manually:
> {code}
> +===+
> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
>Size | Hi/Mi/Rd/Wr |
> +===+
> | 44A2CF9C(@n1), 192.168.1.64 | 4| 19.63 % | 0.43 % | 00:01:46.229 |
> Total: 253894| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 253894 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +-+--+---+--+--+--+-+
> | 72DEC7B5(@n0), 192.168.1.64 | 4| 9.69 %| 0.50 % | 00:02:00.456 |
> Total: 246106| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 246106 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +---+
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9503) Visor CMD shows wrong REPLICATED cache max size
[
https://issues.apache.org/jira/browse/IGNITE-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Konstantinov reassigned IGNITE-9503:
--
Assignee: Vasiliy Sisko (was: Pavel Konstantinov)
> Visor CMD shows wrong REPLICATED cache max size
> ---
>
> Key: IGNITE-9503
> URL: https://issues.apache.org/jira/browse/IGNITE-9503
> Project: Ignite
> Issue Type: Task
> Components: visor
>Affects Versions: 2.5
>Reporter: Denis Magda
>Assignee: Vasiliy Sisko
>Priority: Critical
> Fix For: 2.7
>
> Attachments: image-2018-09-11-11-14-02-347.png
>
>
> Started 2 nodes with a single replicated cache. Preloaded _50_ entries
> there.
> Visor CMD *cache* command shows a wrong total
> {code}
> ++
> |Name(@)|Mode| Nodes | Entries (Heap /
> Off-heap) | Hits| Misses | Reads | Writes |
> ++
> | CacheDataStreamerExample(@c0) | REPLICATED | 2 | min: 246106 (0 /
> 246106) | min: 0| min: 0| min: 0| min: 0|
> | || | avg: 25.00 (0.00 /
> 25.00) | avg: 0.00 | avg: 0.00 | avg: 0.00 | avg: 0.00 |
> | || | max: 253894 (0 /
> 253894) | max: 0| max: 0| max: 0| max: 0|
> ++
> {code}
> You find a correct total number only if *cache -a* is used and you calculate
> the sum of entries on each node manually:
> {code}
> +===+
> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
>Size | Hi/Mi/Rd/Wr |
> +===+
> | 44A2CF9C(@n1), 192.168.1.64 | 4| 19.63 % | 0.43 % | 00:01:46.229 |
> Total: 253894| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 253894 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +-+--+---+--+--+--+-+
> | 72DEC7B5(@n0), 192.168.1.64 | 4| 9.69 %| 0.50 % | 00:02:00.456 |
> Total: 246106| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 246106 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +---+
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9503) Visor CMD shows wrong REPLICATED cache max size
[
https://issues.apache.org/jira/browse/IGNITE-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610337#comment-16610337
]
Pavel Konstantinov commented on IGNITE-9503:
# Add a space between numbers, f.e. (from your screenshot) '0 / 5571'
# print 'n/a' instead of zero numbers
> Visor CMD shows wrong REPLICATED cache max size
> ---
>
> Key: IGNITE-9503
> URL: https://issues.apache.org/jira/browse/IGNITE-9503
> Project: Ignite
> Issue Type: Task
> Components: visor
>Affects Versions: 2.5
>Reporter: Denis Magda
>Assignee: Pavel Konstantinov
>Priority: Critical
> Fix For: 2.7
>
> Attachments: image-2018-09-11-11-14-02-347.png
>
>
> Started 2 nodes with a single replicated cache. Preloaded _50_ entries
> there.
> Visor CMD *cache* command shows a wrong total
> {code}
> ++
> |Name(@)|Mode| Nodes | Entries (Heap /
> Off-heap) | Hits| Misses | Reads | Writes |
> ++
> | CacheDataStreamerExample(@c0) | REPLICATED | 2 | min: 246106 (0 /
> 246106) | min: 0| min: 0| min: 0| min: 0|
> | || | avg: 25.00 (0.00 /
> 25.00) | avg: 0.00 | avg: 0.00 | avg: 0.00 | avg: 0.00 |
> | || | max: 253894 (0 /
> 253894) | max: 0| max: 0| max: 0| max: 0|
> ++
> {code}
> You find a correct total number only if *cache -a* is used and you calculate
> the sum of entries on each node manually:
> {code}
> +===+
> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
>Size | Hi/Mi/Rd/Wr |
> +===+
> | 44A2CF9C(@n1), 192.168.1.64 | 4| 19.63 % | 0.43 % | 00:01:46.229 |
> Total: 253894| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 253894 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +-+--+---+--+--+--+-+
> | 72DEC7B5(@n0), 192.168.1.64 | 4| 9.69 %| 0.50 % | 00:02:00.456 |
> Total: 246106| Hi: 0 |
> | | | | | |
> Heap: 0| Mi: 0 |
> | | | | | |
> Off-Heap: 246106 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +---+
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9536) CPP/ODBC: Change MVCC enabled configuration.
Roman Kondakov created IGNITE-9536:
--
Summary: CPP/ODBC: Change MVCC enabled configuration.
Key: IGNITE-9536
URL: https://issues.apache.org/jira/browse/IGNITE-9536
Project: Ignite
Issue Type: Task
Components: mvcc, odbc
Reporter: Roman Kondakov
Fix For: 2.7
MVCC enabled configuration has changed from the node global flag to per-cache
atomicity mode setting {{CacheAtomicityMode#TRANSACTIONAL_SNAPSHOT}}. We need
to reflect this change in CPP/ODBC API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8244) Sporadic ClusterTopologyCheckedException for the example run
[
https://issues.apache.org/jira/browse/IGNITE-8244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-8244:
-
Assignee: Ivan Bessonov
> Sporadic ClusterTopologyCheckedException for the example run
>
>
> Key: IGNITE-8244
> URL: https://issues.apache.org/jira/browse/IGNITE-8244
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Sergey Kozlov
>Assignee: Ivan Bessonov
>Priority: Minor
> Fix For: 2.7
>
>
> 1. Start standalone node
> 2. Start example from the list:
> {noformat}
> org.apache.ignite.examples.binary.datagrid.store.auto.CacheBinaryAutoStoreExample
> org.apache.ignite.examples.datagrid.store.CacheLoadOnlyStoreExample
> org.apache.ignite.examples.datastructures.IgniteSemaphoreExample
> org.apache.ignite.examples.java8.computegrid.ComputeCallableExample
> org.apache.ignite.examples.java8.datagrid.CacheApiExample
> org.apache.ignite.examples.datagrid.store.auto.CacheAutoStoreExample
> org.apache.ignite.examples.java8.cluster.ClusterGroupExample
> org.apache.ignite.examples.java8.computegrid.ComputeClosureExample
> org.apache.ignite.examples.java8.messaging.MessagingExample
> org.apache.ignite.examples.messaging.MessagingExample
> org.apache.ignite.scalar.examples.ScalarTaskExample
> org.apache.ignite.examples.datagrid.store.jdbc.CacheJdbcStoreExample
> org.apache.ignite.examples.java8.computegrid.ComputeAsyncExample
> org.apache.ignite.examples.java8.computegrid.ComputeRunnableExample
> org.apache.ignite.examples.java8.datagrid.CacheEntryProcessorExample
> org.apache.ignite.examples.java8.messaging.MessagingPingPongExample
> org.apache.ignite.examples.datagrid.store.spring.CacheSpringStoreExample
> org.apache.ignite.examples.java8.computegrid.ComputeBroadcastExample
> org.apache.ignite.examples.java8.datagrid.CacheAffinityExample
> org.apache.ignite.examples.java8.datastructures.IgniteExecutorServiceExample
> {noformat}
> 3. Sometimes example ends up with following exception:
> {noformat}
> class org.apache.ignite.internal.cluster.ClusterTopologyCheckedException:
> Failed to send message because node left grid
> [nodeId=178785f1-6df2-4395-82ba-5636b496f6cd,
> msg=GridDhtTxOnePhaseCommitAckRequest [vers=[GridCacheVersion
> [topVer=135009857, time=1523529863612, order=1523529860859, nodeOrder=1],
> GridCacheVersion [topVer=135009857, time=1523529863612, order=1523529860860,
> nodeOrder=1], GridCacheVersion [topVer=135009857, time=1523529863623,
> order=1523529860866, nodeOrder=1], GridCacheVersion [topVer=135009857,
> time=1523529863625, order=1523529860869, nodeOrder=1]],
> super=GridCacheMessage [msgId=-1, depInfo=null, err=null, skipPrepare=false,
> cacheId=0, cacheId=0]]]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1065)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$2.finish(IgniteTxManager.java:283)
> at
> org.apache.ignite.internal.processors.cache.GridDeferredAckMessageSender$DeferredAckMessageBuffer.finish0(GridDeferredAckMessageSender.java:214)
> at
> org.apache.ignite.internal.processors.cache.GridDeferredAckMessageSender$DeferredAckMessageBuffer.access$000(GridDeferredAckMessageSender.java:111)
> at
> org.apache.ignite.internal.processors.cache.GridDeferredAckMessageSender$DeferredAckMessageBuffer$1.run(GridDeferredAckMessageSender.java:159)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6640)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:788)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9518) getPagesFillFactor returns NaN for empty cache
[ https://issues.apache.org/jira/browse/IGNITE-9518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-9518: --- Fix Version/s: 2.7 > getPagesFillFactor returns NaN for empty cache > -- > > Key: IGNITE-9518 > URL: https://issues.apache.org/jira/browse/IGNITE-9518 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.7 > > > PagesFillFactor attribute of DataRegionMetrics / DataStorageMetrics MX bean > returns NaN for empty cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9535) ClientChangeGlobalStateComputeRequest is missing @GridInternal annotation
[ https://issues.apache.org/jira/browse/IGNITE-9535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610323#comment-16610323 ] ASF GitHub Bot commented on IGNITE-9535: GitHub user ibessonov opened a pull request: https://github.com/apache/ignite/pull/4721 IGNITE-9535 ClientChangeGlobalStateComputeRequest is missing @GridInternal annotation You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9535 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4721.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 #4721 commit 3ef6f4946a2d78de56db77f0b53f85044efd5095 Author: ibessonov Date: 2018-09-11T09:02:26Z IGNITE-9535 Missing annotation added to GridClusterStateProcessor.ClientChangeGlobalStateComputeRequest class. > ClientChangeGlobalStateComputeRequest is missing @GridInternal annotation > - > > Key: IGNITE-9535 > URL: https://issues.apache.org/jira/browse/IGNITE-9535 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > > Problematic class: > org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.ClientChangeGlobalStateComputeRequest; > @GridInternal annotation must be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7728) Put together a doc that shows how to blend SQL with k/v APIs
[ https://issues.apache.org/jira/browse/IGNITE-7728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610309#comment-16610309 ] Artem Budnikov edited comment on IGNITE-7728 at 9/11/18 8:59 AM: - [~dmagda], I added a page under the JAVA DEVELOPER GUIDE section and named it "KEY-VALUE API" (there is already a section named SQL API). I'm still trying to invent an appropriate title for this page. Please review: [https://apacheignite-sql.readme.io/v2.6/docs/key-value-api] was (Author: artem budnikov): [~dmagda], I added a page under the JAVA DEVELOPER GUIDE section and named it "KEY-VALUE API" (there is already a section named SQL API). I'm still trying to infent an appropriate title for this page. Please review: [https://apacheignite-sql.readme.io/v2.6/docs/key-value-api] > Put together a doc that shows how to blend SQL with k/v APIs > > > Key: IGNITE-7728 > URL: https://issues.apache.org/jira/browse/IGNITE-7728 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Blocker > Fix For: 2.7 > > > More and more people start blending SQL with key-value APIs in Ignite. > Usually, they create tables/caches with DDL and wish to use key-value later > as well: > [https://stackoverflow.com/questions/48795533/how-do-i-read-data-from-cache-using-javaapi-after-i-put-it-through-jdbc] > https://stackoverflow.com/questions/49834964/mixing-apache-ignite-binaryobject-with-sql-tables/49864396#49864396 > > We already have a project that demonstrates this approach: > [https://github.com/dmagda/ignite_world_demo] > > Put together a doc that points out to it and elaborates on this topic. The > doc needs to explain how tables are mapped to the caches, columns to types as > discussed here: > http://apache-ignite-developers.2346864.n4.nabble.com/write-through-when-using-SQL-updates-td29767.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7728) Put together a doc that shows how to blend SQL with k/v APIs
[ https://issues.apache.org/jira/browse/IGNITE-7728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610309#comment-16610309 ] Artem Budnikov edited comment on IGNITE-7728 at 9/11/18 8:59 AM: - [~dmagda], I added a page under the JAVA DEVELOPER GUIDE section and named it "KEY-VALUE API" (there is already a section named SQL API). I'm still trying to infent an appropriate title for this page. Please review: [https://apacheignite-sql.readme.io/v2.6/docs/key-value-api] was (Author: artem budnikov): [~dmagda], I added a page under the JAVA DEVELOPER GUIDE section and named it "KEY-VALUE API" (there is already a section named SQL API). I'm still trying to find an appropriate title for this page. Please review: [https://apacheignite-sql.readme.io/v2.6/docs/key-value-api] > Put together a doc that shows how to blend SQL with k/v APIs > > > Key: IGNITE-7728 > URL: https://issues.apache.org/jira/browse/IGNITE-7728 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Blocker > Fix For: 2.7 > > > More and more people start blending SQL with key-value APIs in Ignite. > Usually, they create tables/caches with DDL and wish to use key-value later > as well: > [https://stackoverflow.com/questions/48795533/how-do-i-read-data-from-cache-using-javaapi-after-i-put-it-through-jdbc] > https://stackoverflow.com/questions/49834964/mixing-apache-ignite-binaryobject-with-sql-tables/49864396#49864396 > > We already have a project that demonstrates this approach: > [https://github.com/dmagda/ignite_world_demo] > > Put together a doc that points out to it and elaborates on this topic. The > doc needs to explain how tables are mapped to the caches, columns to types as > discussed here: > http://apache-ignite-developers.2346864.n4.nabble.com/write-through-when-using-SQL-updates-td29767.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7728) Put together a doc that shows how to blend SQL with k/v APIs
[ https://issues.apache.org/jira/browse/IGNITE-7728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov reassigned IGNITE-7728: -- Assignee: Denis Magda (was: Artem Budnikov) > Put together a doc that shows how to blend SQL with k/v APIs > > > Key: IGNITE-7728 > URL: https://issues.apache.org/jira/browse/IGNITE-7728 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Blocker > Fix For: 2.7 > > > More and more people start blending SQL with key-value APIs in Ignite. > Usually, they create tables/caches with DDL and wish to use key-value later > as well: > [https://stackoverflow.com/questions/48795533/how-do-i-read-data-from-cache-using-javaapi-after-i-put-it-through-jdbc] > https://stackoverflow.com/questions/49834964/mixing-apache-ignite-binaryobject-with-sql-tables/49864396#49864396 > > We already have a project that demonstrates this approach: > [https://github.com/dmagda/ignite_world_demo] > > Put together a doc that points out to it and elaborates on this topic. The > doc needs to explain how tables are mapped to the caches, columns to types as > discussed here: > http://apache-ignite-developers.2346864.n4.nabble.com/write-through-when-using-SQL-updates-td29767.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7728) Put together a doc that shows how to blend SQL with k/v APIs
[ https://issues.apache.org/jira/browse/IGNITE-7728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610309#comment-16610309 ] Artem Budnikov commented on IGNITE-7728: [~dmagda], I added a page under the JAVA DEVELOPER GUIDE section and named it "KEY-VALUE API" (there is already a section named SQL API). I'm still trying to find an appropriate title for this page. Please review: [https://apacheignite-sql.readme.io/v2.6/docs/key-value-api] > Put together a doc that shows how to blend SQL with k/v APIs > > > Key: IGNITE-7728 > URL: https://issues.apache.org/jira/browse/IGNITE-7728 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Artem Budnikov >Priority: Blocker > Fix For: 2.7 > > > More and more people start blending SQL with key-value APIs in Ignite. > Usually, they create tables/caches with DDL and wish to use key-value later > as well: > [https://stackoverflow.com/questions/48795533/how-do-i-read-data-from-cache-using-javaapi-after-i-put-it-through-jdbc] > https://stackoverflow.com/questions/49834964/mixing-apache-ignite-binaryobject-with-sql-tables/49864396#49864396 > > We already have a project that demonstrates this approach: > [https://github.com/dmagda/ignite_world_demo] > > Put together a doc that points out to it and elaborates on this topic. The > doc needs to explain how tables are mapped to the caches, columns to types as > discussed here: > http://apache-ignite-developers.2346864.n4.nabble.com/write-through-when-using-SQL-updates-td29767.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9535) ClientChangeGlobalStateComputeRequest is missing @GridInternal annotation
Ivan Bessonov created IGNITE-9535: - Summary: ClientChangeGlobalStateComputeRequest is missing @GridInternal annotation Key: IGNITE-9535 URL: https://issues.apache.org/jira/browse/IGNITE-9535 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Assignee: Ivan Bessonov Problematic class: org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.ClientChangeGlobalStateComputeRequest; @GridInternal annotation must be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8090) Explain disk space compaction by WAL and compaction techniques
[ https://issues.apache.org/jira/browse/IGNITE-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610303#comment-16610303 ] Alexey Goncharuk commented on IGNITE-8090: -- [~Artem Budnikov], I am not sure if users need this information, but here are some details that may be added to the compaction section: - when compaction is enabled, not only does Ignite compress WAL segments, but it also gets rid of the physical records needed for node recovery after crash. After compaction, WAL segments contain only logical records needed for rebalancing. - as for the WAL tuning, in some workloads it may be beneficial to increase the WAL segment size from the default value (64MB) to larger size (up to 2GB) because segment switch involves some synchronization and it may affect throughput and latency percentiles. Increasing WAL segment size reduces the WAL segment switch frequency. The drawback is that we preallocate a certain number of segments in the work directory and increasing segment size will increase the size of the storage Otherwise looks good. > Explain disk space compaction by WAL and compaction techniques > -- > > Key: IGNITE-8090 > URL: https://issues.apache.org/jira/browse/IGNITE-8090 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Denis Magda >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > Explain how WAL occupies the disk space and how to enable the compaction: > https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStore-underthehood-WALHistorySize > There needs to be a special section in WAL documentation as well as in the > capacity planning. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[ https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610299#comment-16610299 ] ASF GitHub Bot commented on IGNITE-9532: GitHub user udaykale opened a pull request: https://github.com/apache/ignite/pull/4720 IGNITE-9532 Binary mode for Ignite Queue You can merge this pull request into a Git repository by running: $ git pull https://github.com/udaykale/ignite IGNITE-9532 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4720.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 #4720 commit abf6cebf989305c4bc5d5cb51f2b8415b34cdd5f Author: uday Date: 2018-09-11T08:40:22Z IGNITE-9532 Binary mode for Ignite Queue > Binary mode for Ignite Queue > > > Key: IGNITE-9532 > URL: https://issues.apache.org/jira/browse/IGNITE-9532 > Project: Ignite > Issue Type: New Feature > Components: binary, data structures >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > > Add binary mode (withKeepBinary) to Data Structures Queue. > This will allow retrieving values in binary format when needed or when class > is not available, and will allow implementing the structures in other > platforms (.NET, C++). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8650) ZookeeperDiscovery testClientReconnectMultinode is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-8650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610295#comment-16610295
]
ASF GitHub Bot commented on IGNITE-8650:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4704
> ZookeeperDiscovery testClientReconnectMultinode is flaky in master
> --
>
> Key: IGNITE-8650
> URL: https://issues.apache.org/jira/browse/IGNITE-8650
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> The test IgniteClientReconnectCacheTest#testReconnectMultinode(LongHistory)
> periodically fails with timeouts in master.
> From the logs I see that the hang is caused by one of the two assertion
> errors:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1345)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {code}
> or
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1388)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {code}
> The test failure can be rarely reproduced locally (run repeatedly with CPU
> stress enabled).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9534) Wrong error message in bin/include/functions.sh
Ilya Suntsov created IGNITE-9534:
Summary: Wrong error message in bin/include/functions.sh
Key: IGNITE-9534
URL: https://issues.apache.org/jira/browse/IGNITE-9534
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.6
Reporter: Ilya Suntsov
In the case when we don't have java installed on the host I see a message:
{noformat}
echo $0", ERROR:"
echo "JAVA_HOME environment variable is not found."
echo "Please point JAVA_HOME variable to location of JDK 1.7 or JDK
1.8."
echo "You can also download latest JDK at http://java.com/download";
{noformat}
Java versions should be changed to:
{noformat}
JDK 1.8 or JDK 9
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8650) ZookeeperDiscovery testClientReconnectMultinode is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-8650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610289#comment-16610289
]
Dmitriy Govorukhin commented on IGNITE-8650:
[~aplatonov] Thanks for the contribution, merged to master.
> ZookeeperDiscovery testClientReconnectMultinode is flaky in master
> --
>
> Key: IGNITE-8650
> URL: https://issues.apache.org/jira/browse/IGNITE-8650
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> The test IgniteClientReconnectCacheTest#testReconnectMultinode(LongHistory)
> periodically fails with timeouts in master.
> From the logs I see that the hang is caused by one of the two assertion
> errors:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1345)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {code}
> or
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1388)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {code}
> The test failure can be rarely reproduced locally (run repeatedly with CPU
> stress enabled).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9495) Update version for org.apache.lucene lucene-queryparser : 5.5.2
[ https://issues.apache.org/jira/browse/IGNITE-9495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610280#comment-16610280 ] Maxim Pudov commented on IGNITE-9495: - Team city looks good to me [https://ci.ignite.apache.org/viewLog.html?buildId=1833967&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_RunAll] [~agerus], please, review. > Update version for org.apache.lucene lucene-queryparser : 5.5.2 > --- > > Key: IGNITE-9495 > URL: https://issues.apache.org/jira/browse/IGNITE-9495 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4, 2.5, 2.6 >Reporter: Alexander Gerus >Assignee: Maxim Pudov >Priority: Major > > Update version for org.apache.lucene > Current version: lucene-queryparser : 5.5.2 > New version version: later than 7.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9320) MVCC: finalize configuration
[
https://issues.apache.org/jira/browse/IGNITE-9320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610277#comment-16610277
]
Igor Seliverstov commented on IGNITE-9320:
--
[~rkondakov], configuration validation on initialize is a wrong pattern, we
already have validation step in the flow, you should move all validation checks
to this place and should not do it twice.
See
\{{org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl#validateCacheConfiguration}}
usages.
> MVCC: finalize configuration
>
>
> Key: IGNITE-9320
> URL: https://issues.apache.org/jira/browse/IGNITE-9320
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.7
>
>
> We need to find a way to configure MVCC caches. Currently this is a global
> setting, which is not very convenient. Proposed solution:
> # Introduce new {{CacheAtomicityMode.TRANSACTIONAL_SNAPSHOT}}
> # Do not allow to change cache this mode during restart (when persistence is
> enabled)
> # Do not allow transactions between {{TRANSACTIONAL}} and
> {{TRANSACTIONAL_SNAPSHOT}} caches
> # Add limitation to cache group - all caches within a group should have the
> same mode
--
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&focusedCommentId=16610273#comment-16610273 ] Vladimir Ozerov commented on IGNITE-8485: - One more reason why encryption should be decoupled from group IDs and cache processor, is that in future it would be used to encrypt other pieces of data. One obvious place is temporal query results. Currently we store everything in memory, what may lead to OOME. When fixed, we will spill intermediate results to disk. These results are not tied to any cache, yet they still have to be encrypted as well. > TDE - Phase-1 > - > > Key: IGNITE-8485 > URL: https://issues.apache.org/jira/browse/IGNITE-8485 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Critical > Fix For: 2.7 > > > Basic support for a Transparent Data Encryption should be implemented: > 1. Usage of standard JKS, Java Security. > 2. Persistent Data Encryption/Decryption. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9533) Monitoring of meta-data discrepancies on all cluster nodes at runtime
Dmitriy Gladkikh created IGNITE-9533: Summary: Monitoring of meta-data discrepancies on all cluster nodes at runtime Key: IGNITE-9533 URL: https://issues.apache.org/jira/browse/IGNITE-9533 Project: Ignite Issue Type: Improvement Reporter: Dmitriy Gladkikh It is required to develop a mechanism that allows to determine the discrepancies between meta-data (binary_meta/marshaller) on all cluster nodes at runtime. This check must be performed periodically. Periodicity should be configured. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9451) Consistent Cache.size for cache API methods over MVCC tables
[ https://issues.apache.org/jira/browse/IGNITE-9451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-9451: --- Summary: Consistent Cache.size for cache API methods over MVCC tables (was: Cache API updates Cache.size according to SNAPSHOT isolation) > Consistent Cache.size for cache API methods over MVCC tables > > > Key: IGNITE-9451 > URL: https://issues.apache.org/jira/browse/IGNITE-9451 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Ivan Pavlukhin >Priority: Major > > In scope of supporting Cache API for MVCC caches we should ensure that > Cache.size is updated consistently and only on transaction commit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9532) Binary mode for Ignite Queue
Uday Kale created IGNITE-9532: - Summary: Binary mode for Ignite Queue Key: IGNITE-9532 URL: https://issues.apache.org/jira/browse/IGNITE-9532 Project: Ignite Issue Type: New Feature Components: binary, data structures Reporter: Uday Kale Assignee: Uday Kale Add binary mode (withKeepBinary) to Data Structures Queue. This will allow retrieving values in binary format when needed or when class is not available, and will allow implementing the structures in other platforms (.NET, C++). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6346) Distributed set does not work in REPLICATED mode
[
https://issues.apache.org/jira/browse/IGNITE-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610257#comment-16610257
]
ASF GitHub Bot commented on IGNITE-6346:
GitHub user xtern reopened a pull request:
https://github.com/apache/ignite/pull/4711
IGNITE-6346
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/xtern/ignite IGNITE-6346
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4711.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 #4711
commit 2efaac326aa6b0a4120fa3b1f845db54dd313fce
Author: kaligula...@gmail.com
Date: 2017-09-26T19:15:04Z
IGNITE-6346 Fix: distributed set does not work in REPLICATED mode
Changes:
1. Fixed bug
2. Added tests
commit 9d24708537ec47baac989d1a747cc716093457b4
Author: pereslegin-pa
Date: 2018-09-10T09:56:49Z
IGNITE-6346 Code cleanup.
> Distributed set does not work in REPLICATED mode
>
>
> Key: IGNITE-6346
> URL: https://issues.apache.org/jira/browse/IGNITE-6346
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: vk
>Priority: Major
> Attachments: Reproducer.java
>
>
> When {{IgniteSet}} is created with {{REPLICATED}} cache mode, any attempt to
> read it fails with exception:
> {noformat}
> Exception in thread "main" class org.apache.ignite.IgniteException: Cluster
> group is empty.
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:48)
> at ReplicatedSet.main(ReplicatedSet.java:36)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: class
> org.apache.ignite.internal.cluster.ClusterGroupEmptyCheckedException: Cluster
> group is empty.
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.execute0(GridCacheQueryAdapter.java:481)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.execute(GridCacheQueryAdapter.java:442)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetImpl.iterator0(GridCacheSetImpl.java:420)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetImpl.iterator(GridCacheSetImpl.java:375)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetProxy.iterator(GridCacheSetProxy.java:342)
> ... 6 more
> {noformat}
> To reproduce run the following code:
> {code}
> Ignition.start(new IgniteConfiguration().setIgniteInstanceName("server-1"));
> Ignition.start(new IgniteConfiguration().setIgniteInstanceName("server-2"));
> Ignition.setClientMode(true);
> Ignite ignite = Ignition.start();
> IgniteSet set = ignite.set("my-set", new
> CollectionConfiguration().setCacheMode(CacheMode.REPLICATED));
> for (String s : set) {
> System.out.println(s);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6346) Distributed set does not work in REPLICATED mode
[
https://issues.apache.org/jira/browse/IGNITE-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610256#comment-16610256
]
ASF GitHub Bot commented on IGNITE-6346:
Github user xtern closed the pull request at:
https://github.com/apache/ignite/pull/4711
> Distributed set does not work in REPLICATED mode
>
>
> Key: IGNITE-6346
> URL: https://issues.apache.org/jira/browse/IGNITE-6346
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: vk
>Priority: Major
> Attachments: Reproducer.java
>
>
> When {{IgniteSet}} is created with {{REPLICATED}} cache mode, any attempt to
> read it fails with exception:
> {noformat}
> Exception in thread "main" class org.apache.ignite.IgniteException: Cluster
> group is empty.
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:48)
> at ReplicatedSet.main(ReplicatedSet.java:36)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: class
> org.apache.ignite.internal.cluster.ClusterGroupEmptyCheckedException: Cluster
> group is empty.
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.execute0(GridCacheQueryAdapter.java:481)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.execute(GridCacheQueryAdapter.java:442)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetImpl.iterator0(GridCacheSetImpl.java:420)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetImpl.iterator(GridCacheSetImpl.java:375)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetProxy.iterator(GridCacheSetProxy.java:342)
> ... 6 more
> {noformat}
> To reproduce run the following code:
> {code}
> Ignition.start(new IgniteConfiguration().setIgniteInstanceName("server-1"));
> Ignition.start(new IgniteConfiguration().setIgniteInstanceName("server-2"));
> Ignition.setClientMode(true);
> Ignite ignite = Ignition.start();
> IgniteSet set = ignite.set("my-set", new
> CollectionConfiguration().setCacheMode(CacheMode.REPLICATED));
> for (String s : set) {
> System.out.println(s);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9531) ZookeeperDiscovery testClientReconnect is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Platonov updated IGNITE-9531:
Description:
The test IgniteClientReconnectCacheTest#testReconnect periodically.
>From the logs I see that the hang is caused by assertion error:
{code}
junit.framework.AssertionFailedError: expected:<22> but was:
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:86)
at junit.framework.TestCase.assertEquals(TestCase.java:253)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnect(IgniteClientReconnectCacheTest.java:321)
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:2177)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
at java.lang.Thread.run(Thread.java:748)
{code}
was:
The test IgniteClientReconnectCacheTest#testReconnectMultinode(LongHistory)
periodically fails with timeouts in master.
>From the logs I see that the hang is caused by one of the two assertion errors:
{code}
java.lang.AssertionError
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1345)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
at
org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
at
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
{code}
or
{code}
java.lang.AssertionError
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1388)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
at
org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
at
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
{code}
The test failure can be rarely reproduced locally (run repeatedly with CPU
stress enabled).
> ZookeeperDiscovery testClientReconnect is flaky in master
> -
>
> Key: IGNITE-9531
> URL: https://issues.apache.org/jira/browse/IGNITE-9531
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Platonov
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> The test IgniteClientReconnectCacheTest#testReconnect periodically.
> From the logs I see that the hang is caused by assertion error:
> {code}
> junit.framework.AssertionFailedError: expected:<22> but was:
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:86)
> at junit.framework.TestCase.assertEquals(TestCase.java:253)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnect(IgniteClientReconnectCacheTest.java:321)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at ja
[jira] [Commented] (IGNITE-8485) TDE - Phase-1
[
https://issues.apache.org/jira/browse/IGNITE-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610255#comment-16610255
]
Vladimir Ozerov commented on IGNITE-8485:
-
Hi [~NIzhikov], my comments:
1) Styling: please look through your code and fix the following issues:
- Unused imports
- Replace abbreviations in method names with full words (as abbreviations are
allowed only for variable, not method names and class names)
- Replace "log.warn" with "U.warn"
2) I am still not satisfied with API. "AES" name is not appropriate here,
because it denotes algorithm, but instead it should denote underlying storage.
Correct name would be "Keystore". First, it will help us to add more algorithms
in future while still using keystore (e.g. 3DES, which is used by other
vendors). Second, what if in future we add another implementation over some KMS
which will also use AES? How would we name? This is why "AES" should go away
from interface names.
3) Key generation for clients - please move it to {{GridEncryptionManager}}, as
this is exactly what managers and processors are created for - to manage
component lifecycle, listen for events, encapsulate related logic in a single
place.
4) Currently random node is picked to send request to. Instead, random *server*
node should be used.
5) I would suggest to remove group IDs from request. First, at this point our
understanding that cache groups is a hack feature, which is likely to be
removed in future in favor of tablespaces. So it is better to avoid relying on
it if possible. Second, there is no need to get existing keys for caches at
all. Because by the time you got the key from existing cache, it may get's
re-created concurrently with another key. Or key rotation may happen (in future
release). So you can never rely on what key is returned, and it should be
compared with existing group key in exchange thread during cache start. IMO all
we need is the request is the number of keys to be generated.
6) {{GridCacheProcessor#genEncKeysAndStartCacheAfter}} - future is registered
after message is sent, which means that response may be missed (e.g. in case of
long GC pause or unfavorable context switch). Also there is no proper sync with
disconnect event, meaning that you may have hanging futures after disconnect as
well. Bulletproof synchronization here looks like this :
{code:java}
boolean stopped;
boolean disconnected;
onStart(...) {
// Set all listeners
}
onKernalStop(...) {
sync (mux) {
// Set stop flag
// Complete all futures with error
}
}
onDiscoveryMessage(...) {
sync (mux) {
// Iterate over registered futures, resend if possible or finish with
error
}
}
onIOMessage(...) {
sync (mux) {
// Generate key or complete and deregister future.
}
}
onDisconnect(...) {
sync (mux) {
// Set disconnect flag
// Complete all futures with error
}
}
onReconnect(...) {
sync (mux) {
// Remove disconnect flag.
}
}
generateKeys(...) {
sync (mux) {
// Check stop and disconnect flags
// Register future, send request
}
}{code}
At this point it should be obvious why all this logic should be located in
separate processor.
7) There is no need to throw exception in IO listener threads. All we can do
here is to log error with proper message.
> TDE - Phase-1
> -
>
> Key: IGNITE-8485
> URL: https://issues.apache.org/jira/browse/IGNITE-8485
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Critical
> Fix For: 2.7
>
>
> Basic support for a Transparent Data Encryption should be implemented:
> 1. Usage of standard JKS, Java Security.
> 2. Persistent Data Encryption/Decryption.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9531) ZookeeperDiscovery testClientReconnect is flaky in master
Alexey Platonov created IGNITE-9531:
---
Summary: ZookeeperDiscovery testClientReconnect is flaky in master
Key: IGNITE-9531
URL: https://issues.apache.org/jira/browse/IGNITE-9531
Project: Ignite
Issue Type: Bug
Reporter: Alexey Platonov
Assignee: Alexey Platonov
Fix For: 2.8
The test IgniteClientReconnectCacheTest#testReconnectMultinode(LongHistory)
periodically fails with timeouts in master.
>From the logs I see that the hang is caused by one of the two assertion errors:
{code}
java.lang.AssertionError
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1345)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
at
org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
at
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
{code}
or
{code}
java.lang.AssertionError
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1388)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
at
org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
at
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
{code}
The test failure can be rarely reproduced locally (run repeatedly with CPU
stress enabled).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8650) ZookeeperDiscovery testClientReconnectMultinode is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-8650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610251#comment-16610251
]
Alexey Platonov commented on IGNITE-8650:
-
testReconnectMultinode and testReconnectMultinodeLongHistory passed
> ZookeeperDiscovery testClientReconnectMultinode is flaky in master
> --
>
> Key: IGNITE-8650
> URL: https://issues.apache.org/jira/browse/IGNITE-8650
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> The test IgniteClientReconnectCacheTest#testReconnectMultinode(LongHistory)
> periodically fails with timeouts in master.
> From the logs I see that the hang is caused by one of the two assertion
> errors:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1345)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {code}
> or
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1388)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {code}
> The test failure can be rarely reproduced locally (run repeatedly with CPU
> stress enabled).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8650) ZookeeperDiscovery testClientReconnectMultinode is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-8650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610251#comment-16610251
]
Alexey Platonov edited comment on IGNITE-8650 at 9/11/18 8:11 AM:
--
testReconnectMultinode and testReconnectMultinodeLongHistory pass
was (Author: aplatonov):
testReconnectMultinode and testReconnectMultinodeLongHistory passed
> ZookeeperDiscovery testClientReconnectMultinode is flaky in master
> --
>
> Key: IGNITE-8650
> URL: https://issues.apache.org/jira/browse/IGNITE-8650
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> The test IgniteClientReconnectCacheTest#testReconnectMultinode(LongHistory)
> periodically fails with timeouts in master.
> From the logs I see that the hang is caused by one of the two assertion
> errors:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1345)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {code}
> or
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1388)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {code}
> The test failure can be rarely reproduced locally (run repeatedly with CPU
> stress enabled).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8650) ZookeeperDiscovery testClientReconnectMultinode is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-8650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610248#comment-16610248
]
Alexey Platonov commented on IGNITE-8650:
-
CheckClientsStatus may fail because of in rare cases while reconnecting already
disconnected client gets list of alive nodes without this client. Such case can
be skipped on client.
> ZookeeperDiscovery testClientReconnectMultinode is flaky in master
> --
>
> Key: IGNITE-8650
> URL: https://issues.apache.org/jira/browse/IGNITE-8650
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> The test IgniteClientReconnectCacheTest#testReconnectMultinode(LongHistory)
> periodically fails with timeouts in master.
> From the logs I see that the hang is caused by one of the two assertion
> errors:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1345)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {code}
> or
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1388)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {code}
> The test failure can be rarely reproduced locally (run repeatedly with CPU
> stress enabled).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8650) ZookeeperDiscovery testClientReconnectMultinode is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-8650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Platonov updated IGNITE-8650:
Summary: ZookeeperDiscovery testClientReconnectMultinode is flaky in master
(was: ZookeeperDiscovery testClientReconnect is flaky in master)
> ZookeeperDiscovery testClientReconnectMultinode is flaky in master
> --
>
> Key: IGNITE-8650
> URL: https://issues.apache.org/jira/browse/IGNITE-8650
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> The test IgniteClientReconnectCacheTest#testReconnectMultinode(LongHistory)
> periodically fails with timeouts in master.
> From the logs I see that the hang is caused by one of the two assertion
> errors:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1345)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {code}
> or
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1388)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {code}
> The test failure can be rarely reproduced locally (run repeatedly with CPU
> stress enabled).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-7793) SQL does not work if value has index filed which name equals to affinity key name
[
https://issues.apache.org/jira/browse/IGNITE-7793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich reassigned IGNITE-7793:
-
Assignee: Maxim Pudov (was: Yury Gerzhedovich)
> SQL does not work if value has index filed which name equals to affinity key
> name
> -
>
> Key: IGNITE-7793
> URL: https://issues.apache.org/jira/browse/IGNITE-7793
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Maxim Pudov
>Priority: Blocker
> Fix For: 2.7
>
>
> SQL does not work if value has index filed which name equals to affinity key
> name:
> {code:java}
> public class AKey {
> @AffinityKeyMapped
> int a;
> public AKey(int a) {
> this.a = a;
> }
> }
> public class AVal {
> @QuerySqlField
> int a;
> public AVal(int a) {
> this.a = a;
> }
> }
> AKey aKey = new AKey(1);
> AVal aVal = new AVal(0);
> IgniteCache cache = ignite.cache("Instrument");
> cache.put(aKey, aVal);
> SqlFieldsQuery query = new SqlFieldsQuery("select * from \"Instrument\".AVal
> it where it.a=?");
> List> res = cache.query(query.setArgs(0)).getAll();
> if(res.isEmpty()) {
> System.out.println("! FAILED !!!");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9530) MVCC TX: Local caches support.
Roman Kondakov created IGNITE-9530: -- Summary: MVCC TX: Local caches support. Key: IGNITE-9530 URL: https://issues.apache.org/jira/browse/IGNITE-9530 Project: Ignite Issue Type: Task Components: cache, mvcc Reporter: Roman Kondakov Mvcc support for local caches is turned off now. We need to consider implementing it in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9529) .NET: Thin client: Implement TextQuery
Pavel Tupitsyn created IGNITE-9529:
--
Summary: .NET: Thin client: Implement TextQuery
Key: IGNITE-9529
URL: https://issues.apache.org/jira/browse/IGNITE-9529
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Implement TextQuery support for Thin Client. Add a new overload to
{{IIgniteClient}}:
{code}
IQueryCursor> Query(TextQuery textQuery);
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
