[jira] [Commented] (IGNITE-10194) ZookeeperDiscoverySpiTest fails on testLocalAuthenticationFails
[
https://issues.apache.org/jira/browse/IGNITE-10194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681013#comment-16681013
]
Ignite TC Bot commented on IGNITE-10194:
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2273364&buildTypeId=IgniteTests24Java8_RunAll]
> ZookeeperDiscoverySpiTest fails on testLocalAuthenticationFails
> ---
>
> Key: IGNITE-10194
> URL: https://issues.apache.org/jira/browse/IGNITE-10194
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Platonov
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> We need to unmute test (remove "_" prefix) and fix this test
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10018) Documentation: manage SQL (ODBC\JDBC\Thin) clients via JMX.
[ https://issues.apache.org/jira/browse/IGNITE-10018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681006#comment-16681006 ] Artem Budnikov commented on IGNITE-10018: - I created a page named "JDBC/ODBC Session Management": [https://apacheignite-sql.readme.io/v2.6/docs/jdbcodbc-session-management] [~pgarg] please review. > Documentation: manage SQL (ODBC\JDBC\Thin) clients via JMX. > --- > > Key: IGNITE-10018 > URL: https://issues.apache.org/jira/browse/IGNITE-10018 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Andrew Mashenkov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > We have to add IGNITE-8628 changes to documantation. > > org.apache.ignite.mxbean.ClientProcessorMXBean interface for MBean was added. > MBean can be accessed from any JMX management console with name containing > "igniteInstanceName= name>,group=Clients,name=ClientListenerProcessor". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10018) Documentation: manage SQL (ODBC\JDBC\Thin) clients via JMX.
[ https://issues.apache.org/jira/browse/IGNITE-10018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov reassigned IGNITE-10018: --- Assignee: Prachi Garg (was: Artem Budnikov) > Documentation: manage SQL (ODBC\JDBC\Thin) clients via JMX. > --- > > Key: IGNITE-10018 > URL: https://issues.apache.org/jira/browse/IGNITE-10018 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Andrew Mashenkov >Assignee: Prachi Garg >Priority: Major > Fix For: 2.7 > > > We have to add IGNITE-8628 changes to documantation. > > org.apache.ignite.mxbean.ClientProcessorMXBean interface for MBean was added. > MBean can be accessed from any JMX management console with name containing > "igniteInstanceName= name>,group=Clients,name=ClientListenerProcessor". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10085) Make compressed wal archives user friendly.
[
https://issues.apache.org/jira/browse/IGNITE-10085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681005#comment-16681005
]
Pavel Voronkin commented on IGNITE-10085:
-
Looks good to me
> Make compressed wal archives user friendly.
> ---
>
> Key: IGNITE-10085
> URL: https://issues.apache.org/jira/browse/IGNITE-10085
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Sergey Antonov
>Priority: Minor
>
> Compressed wal archives are created with ZipEntry(""). In some ZIP GUIs those
> archives are shown empty which can really confuse users.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10188) Move tests with persistence to the convenient suite
[
https://issues.apache.org/jira/browse/IGNITE-10188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681003#comment-16681003
]
Ryabov Dmitrii commented on IGNITE-10188:
-
[~EdShangGG], I made as you suggested, [{{Cache 5}} suite is finished
successfully|https://ci.ignite.apache.org/viewLog.html?buildId=2273604&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Cache5].
> Move tests with persistence to the convenient suite
> ---
>
> Key: IGNITE-10188
> URL: https://issues.apache.org/jira/browse/IGNITE-10188
> Project: Ignite
> Issue Type: Test
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Major
>
> Tests with persistence from {{IgniteCachePartitionLossPolicySelfTest}} must
> be moved to another class and suite.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-6600) Web Console: Make a design of 403 and 404 pages
[ https://issues.apache.org/jira/browse/IGNITE-6600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-6600: -- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web Console: Make a design of 403 and 404 pages > --- > > Key: IGNITE-6600 > URL: https://issues.apache.org/jira/browse/IGNITE-6600 > Project: Ignite > Issue Type: Task > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Alexey Kuznetsov >Priority: Minor > Attachments: 403-page.png, 404-page.png > > Original Estimate: 8h > Time Spent: 8h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6600) Web Console: Make a design of 403 and 404 pages
[ https://issues.apache.org/jira/browse/IGNITE-6600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680994#comment-16680994 ] Pavel Konstantinov commented on IGNITE-6600: Tested. > Web Console: Make a design of 403 and 404 pages > --- > > Key: IGNITE-6600 > URL: https://issues.apache.org/jira/browse/IGNITE-6600 > Project: Ignite > Issue Type: Task > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Pavel Konstantinov >Priority: Minor > Attachments: 403-page.png, 404-page.png > > Original Estimate: 8h > Time Spent: 8h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10162) IgniteCacheAtomicQuerySelfTest#testTwoObjectsTextSearch fails with IgniteCheckedException: Failed to find SQL table for type: ObjectValue
[
https://issues.apache.org/jira/browse/IGNITE-10162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680992#comment-16680992
]
Ignite TC Bot commented on IGNITE-10162:
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2270241&buildTypeId=IgniteTests24Java8_RunAll]
> IgniteCacheAtomicQuerySelfTest#testTwoObjectsTextSearch fails with
> IgniteCheckedException: Failed to find SQL table for type: ObjectValue
> -
>
> Key: IGNITE-10162
> URL: https://issues.apache.org/jira/browse/IGNITE-10162
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Alexey Platonov
>Priority: Major
> Fix For: 2.8
>
>
> IgniteCacheAtomicQuerySelfTest#testTwoObjectsTextSearch (in current codebase
> muted by renaming to {{_testTwoObjectsTextSearch}}) fails:
> {noformat}
> [2018-11-07 14:37:32,728][INFO
> ][grid-nio-worker-tcp-comm-1-#91%near.IgniteCacheAtomicQuerySelfTest1%][IgniteCachePartitionedQuerySelfTest$TestTcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/127.0.0.1:47101,
> rmtAddr=/127.0.0.1:57395][2018-11-07 14:37:32,728][WARN
> ][sys-stripe-1-#61%near.IgniteCacheAtomicQuerySelfTest2%][GridQueryProcessor]
> Key-value pair is not inserted into any SQL table [cacheName=Object-Object,
> valType=o.a.i.i.processors.cache.IgniteCacheAbstractQuerySelfTest$ObjectValue]
> [2018-11-07 14:37:32,728][WARN
> ][sys-stripe-1-#61%near.IgniteCacheAtomicQuerySelfTest2%][GridQueryProcessor]
> ^-- Value type(s) are specified via CacheConfiguration.indexedTypes or
> CacheConfiguration.queryEntities
> [2018-11-07 14:37:32,728][WARN
> ][sys-stripe-1-#61%near.IgniteCacheAtomicQuerySelfTest2%][GridQueryProcessor]
> ^-- Make sure that same type(s) used when adding Object or BinaryObject to
> cache
> [2018-11-07 14:37:32,728][WARN
> ][sys-stripe-1-#61%near.IgniteCacheAtomicQuerySelfTest2%][GridQueryProcessor]
> ^-- Otherwise, entries will be stored in cache, but not appear as SQL Table
> rows
> [2018-11-07 14:37:32,744][INFO
> ][grid-nio-worker-tcp-comm-1-#94%near.IgniteCacheAtomicQuerySelfTest2%][IgniteCachePartitionedQuerySelfTest$TestTcpCommunicationSpi]
> Established outgoing communication connection [locAddr=/127.0.0.1:57395,
> rmtAddr=/127.0.0.1:47101]
> [2018-11-07 14:37:32,766][WARN
> ][sys-stripe-6-#66%near.IgniteCacheAtomicQuerySelfTest2%][GridQueryProcessor]
> Key-value pair is not inserted into any SQL table [cacheName=Object-Object,
> valType=o.a.i.i.processors.cache.IgniteCacheAbstractQuerySelfTest$ObjectValueOther]
> [2018-11-07
> 14:37:32,867][ERROR][query-#150%near.IgniteCacheAtomicQuerySelfTest2%][GridCacheDistributedQueryManager]
> Failed to run query [qry=GridCacheQueryInfo [loc=false,
> trans=null, rdc=null, qry=GridCacheQueryAdapter [type=TEXT,
> clsName=ObjectValue, clause=str, filter=null, transform=null, part=null,
> incMeta=false, metrics=null, pageSize=1024, timeout=0, incBackups=false,
> forceLocal=false, dedup=false, prj=null, keepBinary=false,
> subjId=964a4e0a-38e6-47db-b91c-95d3c410, taskHash=0, mvccSnapshot=null],
> locFut=null, sndId=964a4e0a-38e6-47db-b91c-95d3c410, reqId=27,
> incMeta=false, all=false], node=5c1facf8-cf09-498f-bdf0-e75f9942]
> class org.apache.ignite.IgniteCheckedException: Failed to find SQL table for
> type: ObjectValue
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.typeName(GridQueryProcessor.java:2675)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.access$500(GridQueryProcessor.java:129)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$9.applyx(GridQueryProcessor.java:2617)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$9.applyx(GridQueryProcessor.java:2615)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2696)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryText(GridQueryProcessor.java:2614)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.executeQuery(GridCacheQueryManager.java:614)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.queryResult(GridCacheQueryManager.java:1472)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1106)
> at
> org.apache.ignite.internal.
[jira] [Commented] (IGNITE-10130) Add option for disable triggering cache interceptor on cross datacenter replication changes.
[ https://issues.apache.org/jira/browse/IGNITE-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680962#comment-16680962 ] Sergey Antonov commented on IGNITE-10130: - [~vozerov] Could you review my changes too? > Add option for disable triggering cache interceptor on cross datacenter > replication changes. > > > Key: IGNITE-10130 > URL: https://issues.apache.org/jira/browse/IGNITE-10130 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.8 > > > It's needed for our proprietary plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9700) Remove configurable values from mesos pom.xml
[ https://issues.apache.org/jira/browse/IGNITE-9700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh updated IGNITE-9700: - Fix Version/s: 2.8 > Remove configurable values from mesos pom.xml > - > > Key: IGNITE-9700 > URL: https://issues.apache.org/jira/browse/IGNITE-9700 > Project: Ignite > Issue Type: Bug >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Minor > Fix For: 2.8 > > > pom.xml contains urls and paths that can be configured when building, but it > introduces git changes with every build. > Need to update the links in the file and remove them from build process, > since the whole process depends on the the links and will not likely be > changed in near future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9996) Investigate possible performance drop in FSYNC mode for ignite-2.7 compared to ignite-2.6
[ https://issues.apache.org/jira/browse/IGNITE-9996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-9996: --- Assignee: Nikolay Izhikov (was: Alexey Goncharuk) > Investigate possible performance drop in FSYNC mode for ignite-2.7 compared > to ignite-2.6 > - > > Key: IGNITE-9996 > URL: https://issues.apache.org/jira/browse/IGNITE-9996 > Project: Ignite > Issue Type: Task >Reporter: Alexey Goncharuk >Assignee: Nikolay Izhikov >Priority: Major > Fix For: 2.7 > > Attachments: Screen Shot 2018-10-29 at 3.30.51 PM.png, Screen Shot > 2018-10-31 at 10.30.26 AM.png, Screen Shot 2018-11-08 at 2.38.06 PM.png > > > As per the latest reports we probably have a performance drop around 5-8% on > write benchmarks in FSYNC mode. The cause needs to be investigated and fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10148) Add aws s3 and elb configs to benchmarks/config
[ https://issues.apache.org/jira/browse/IGNITE-10148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680927#comment-16680927 ] Ilya Murchenko commented on IGNITE-10148: - [~ustas] looks good to me. Thank you! > Add aws s3 and elb configs to benchmarks/config > > > Key: IGNITE-10148 > URL: https://issues.apache.org/jira/browse/IGNITE-10148 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Suntsov >Assignee: Ilya Suntsov >Priority: Major > > Add to yardstick: > * S3 discovery config > * ELB discovery config -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10108) Non-static class is passed between cluster nodes
[
https://issues.apache.org/jira/browse/IGNITE-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680887#comment-16680887
]
Roman Shtykh edited comment on IGNITE-10108 at 11/9/18 5:11 AM:
[~Mmuzaf] Ok, thanks for clearing this out. I put it back to
GridCommonAbstractTest.
If everything looks ok from your side, I'll commit. Please have a look.
was (Author: roman_s):
[~Mmuzaf] Ok, thanks for clearing this out. If everything looks ok from your
side, I'll commit.
> Non-static class is passed between cluster nodes
>
>
> Key: IGNITE-10108
> URL: https://issues.apache.org/jira/browse/IGNITE-10108
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Roman Shtykh
>Priority: Major
>
> Need to avoid passing anonymous classes on compute, because this lead to
> serialize whole test-class context.
> By the reason need to refactor that place
> {code}
> ignite.compute().withTimeout(5_000).broadcastAsync(new IgniteRunnable() {
> ...
> });
> {code}
> in method \{{GridCommonAbstractTest#manualCacheRebalancing}} into private
> static nested class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10108) Non-static class is passed between cluster nodes
[
https://issues.apache.org/jira/browse/IGNITE-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680887#comment-16680887
]
Roman Shtykh commented on IGNITE-10108:
---
[~Mmuzaf] Ok, thanks for clearing this out. If everything looks ok from your
side, I'll commit.
> Non-static class is passed between cluster nodes
>
>
> Key: IGNITE-10108
> URL: https://issues.apache.org/jira/browse/IGNITE-10108
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Roman Shtykh
>Priority: Major
>
> Need to avoid passing anonymous classes on compute, because this lead to
> serialize whole test-class context.
> By the reason need to refactor that place
> {code}
> ignite.compute().withTimeout(5_000).broadcastAsync(new IgniteRunnable() {
> ...
> });
> {code}
> in method \{{GridCommonAbstractTest#manualCacheRebalancing}} into private
> static nested class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10079) FileWriteAheadLogManager may return invalid lastCompactedSegment
[
https://issues.apache.org/jira/browse/IGNITE-10079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680880#comment-16680880
]
Anton Kalashnikov commented on IGNITE-10079:
[~andrey-kuznetsov], when you finished any coding please change task status to
"Patch Available" otherwise it's too dificult to understand when your changes
ready to review.
I viewed your changes, now it looks good for me. After all tests passed it can
be merged.
> FileWriteAheadLogManager may return invalid lastCompactedSegment
>
>
> Key: IGNITE-10079
> URL: https://issues.apache.org/jira/browse/IGNITE-10079
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Attachments: WalCompactionAfterRestartTest.java
>
>
> As of current {{master}} branch,
> {{FileWriteAheadLogManager#lastCompactedSegment}} may report -1 even after
> some segments have been actually compressed. Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9937) Primary response error info can be lost due to unwrapping a key
[
https://issues.apache.org/jira/browse/IGNITE-9937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680884#comment-16680884
]
Roman Guseinov commented on IGNITE-9937:
Hi [~ilyak], after adding one more test and updating the fix, I found out that
it's not enough to store keys as binary objects inside
CachePartialUpdateCheckedException. This can lead to failed tests in jcache and
dotnet.
The newest fix resolves the original issue and doesn't affect other use cases.
Could you please take a look again at PR
https://github.com/apache/ignite/pull/5078?
> Primary response error info can be lost due to unwrapping a key
> ---
>
> Key: IGNITE-9937
> URL: https://issues.apache.org/jira/browse/IGNITE-9937
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>
> It can happen when we use SQL DDL to create a table or some dummy values for
> QueryEntity.keyType. Without using Cache API (only SQL), key and value should
> not be deserialized/unwrapped.
> If primary update error happens onPrimaryError call may try to unwrap keys,
> get ClassNotFoundException and hide the original error.
> Here is a stack trace example:
> {code:java}
> Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
> TestTableKey
>at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:706)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1755)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:797)
>at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
>at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:177)
>at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:67)
>at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:404)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onPrimaryResponse(GridNearAtomicUpdateFuture.java:416)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:303)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:300)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:390)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1832)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1633)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:812)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:664)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$25.apply(GridDhtAtomicCache.java:1067)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$25.apply(GridDhtAtomicCache.java:1065)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:761)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAll0(GridDhtAtomicCache.java:1065)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAllConflictAsync(GridDhtAtomicCache.java:687)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomi
[jira] [Commented] (IGNITE-9845) Web Console: Add support of two way ssl authentication in Web Console agent
[ https://issues.apache.org/jira/browse/IGNITE-9845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680759#comment-16680759 ] Andrey Novikov commented on IGNITE-9845: Please implement two way ssl between backend and web agent too. > Web Console: Add support of two way ssl authentication in Web Console agent > --- > > Key: IGNITE-9845 > URL: https://issues.apache.org/jira/browse/IGNITE-9845 > Project: Ignite > Issue Type: Improvement > Components: wizards >Affects Versions: 2.6 >Reporter: Andrey Novikov >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.8 > > > RestExecutor should not be shared between different users requests in case of > two way ssl authentication: > * For each token with ssl we need create separated RestExecutor and set up > socketFactory and trustManager. > * RestExecutor should be removed if token expired. > Add program arguments for passing client certificate, client password, trust > store, trust store password for ignite node connection and web console > backend. > Example on okhttp: > [https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java] > > We can also upgrade socket-io from 1.x to 2.x. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9845) Web Console: Add support of two way ssl authentication in Web Console agent
[ https://issues.apache.org/jira/browse/IGNITE-9845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov reassigned IGNITE-9845: -- Assignee: Alexey Kuznetsov (was: Andrey Novikov) > Web Console: Add support of two way ssl authentication in Web Console agent > --- > > Key: IGNITE-9845 > URL: https://issues.apache.org/jira/browse/IGNITE-9845 > Project: Ignite > Issue Type: Improvement > Components: wizards >Affects Versions: 2.6 >Reporter: Andrey Novikov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > RestExecutor should not be shared between different users requests in case of > two way ssl authentication: > * For each token with ssl we need create separated RestExecutor and set up > socketFactory and trustManager. > * RestExecutor should be removed if token expired. > Add program arguments for passing client certificate, client password, trust > store, trust store password for ignite node connection and web console > backend. > Example on okhttp: > [https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java] > > We can also upgrade socket-io from 1.x to 2.x. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10196) Remove kafka-clients-*-test dependency
[ https://issues.apache.org/jira/browse/IGNITE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Pudov reassigned IGNITE-10196: Assignee: Maxim Pudov (was: Andrey Aleksandrov) > Remove kafka-clients-*-test dependency > -- > > Key: IGNITE-10196 > URL: https://issues.apache.org/jira/browse/IGNITE-10196 > Project: Ignite > Issue Type: Bug > Components: build >Affects Versions: 2.7 >Reporter: Sergey Kozlov >Assignee: Maxim Pudov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10195) Cannot create caches with different names but with same indexed types and schema name
[
https://issues.apache.org/jira/browse/IGNITE-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Platonov updated IGNITE-10195:
-
Description:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{code:java}
node.createCache(new CacheConfiguration()
.setName("PERSON_1")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
node.createCache(new CacheConfiguration()
.setName("PERSON_2")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
{code}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation @QuerySqlField(index =
true)). Here is definition of Person class:
{code:java}
public static class PersonKey {
@QuerySqlField public long id; /** * Constructor. * * @param id ID. */
PersonKey(long id) {
this.id = id; }
/** {@inheritDoc{color:#629755}} */
@Override public int hashCode() {
return (int)id; }
/** {@inheritDoc{color:#629755}} */
@Override public boolean equals(Object obj) {
return obj != null && obj instanceof PersonKey && (F.eq(id,
((PersonKey)obj).id)); }
}{code}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values?
was:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{code:java}
node.createCache(new CacheConfiguration()
.setName("PERSON_1")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
node.createCache(new CacheConfiguration()
.setName("PERSON_2")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
{code}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation
{color:#bbb529}@QuerySqlField{color}({color:#d0d0ff}index {color}=
{color:#cc7832}true{color})). Here is definition of Person class:
\{code}
{color:#cc7832}public static class {color}PersonKey {
{color:#bbb529}@QuerySqlField{color} {color:#cc7832}public long
{color}{color:#9876aa}id{color}{color:#cc7832};{color}
{color:#629755}/**{color}{color:#629755} * Constructor.{color}{color:#629755}
*{color}{color:#629755} * {color}{color:#629755}@param {color}{color:#8a653b}id
{color}{color:#629755}ID.{color}{color:#629755} */{color}
{color:#ffc66d}PersonKey{color}({color:#cc7832}long {color}id) {
{color:#cc7832}this{color}.{color:#9876aa}id {color}=
id{color:#cc7832};{color} }
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public int {color}{color:#ffc66d}hashCode{color}() {
{color:#cc7832}return
{color}({color:#cc7832}int{color}){color:#9876aa}id{color}{color:#cc7832};{color}
}
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public boolean
{color}{color:#ffc66d}equals{color}(Object obj) {
{color:#cc7832}return {color}obj != {color:#cc7832}null {color}&& obj
{color:#cc7832}instanceof {color}PersonKey &&
(F.eq({color:#9876aa}id{color}{color:#cc7832},
{color}((PersonKey)obj).{color:#9876aa}id{color})){color:#cc7832};{color} }
}
\{code}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values?
> Cannot create caches with different names but with same indexed types and
> schema name
> -
>
> Key: IGNITE-10195
> URL: https://issues.apache.org/jira/browse/IGNITE-10195
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Platonov
>Priority: Major
>
> Cannot create caches with different names but with same indexed types and
> schema name. For example, such code will throw exception
> "javax.cache.CacheException: Table already exists: PERSON".
>
> {code:java}
> node.createCache(new CacheConfiguration()
> .setName("PERSON_1")
> .setIndexedTypes(Key.class, Person.class)
> .setSqlSchema(QueryUtils.DFLT_SCHEMA));
> node.createCache(new CacheConfiguration()
> .setName("PERSON_2")
> .setIndexedTypes(Key.class, Person.class)
> .setSqlSchema(QueryUtils.DFLT_SCHEMA));
> {code}
>
> If I set table name manually by setQueryEntities(...) then
> "javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
> thrown (Value has field with "origId" and annotation @QuerySqlField(index =
> true)). Here is definition of Person
[jira] [Updated] (IGNITE-10195) Cannot create caches with different names but with same indexed types and schema name
[
https://issues.apache.org/jira/browse/IGNITE-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Platonov updated IGNITE-10195:
-
Description:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{code:java}
node.createCache(new CacheConfiguration()
.setName("PERSON_1")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
node.createCache(new CacheConfiguration()
.setName("PERSON_2")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
{code}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation
{color:#bbb529}@QuerySqlField{color}({color:#d0d0ff}index {color}=
{color:#cc7832}true{color})). Here is definition of Person class:
\{code}
{color:#cc7832}public static class {color}PersonKey {
{color:#bbb529}@QuerySqlField{color} {color:#cc7832}public long
{color}{color:#9876aa}id{color}{color:#cc7832};{color}
{color:#629755}/**{color}{color:#629755} * Constructor.{color}{color:#629755}
*{color}{color:#629755} * {color}{color:#629755}@param {color}{color:#8a653b}id
{color}{color:#629755}ID.{color}{color:#629755} */{color}
{color:#ffc66d}PersonKey{color}({color:#cc7832}long {color}id) {
{color:#cc7832}this{color}.{color:#9876aa}id {color}=
id{color:#cc7832};{color} }
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public int {color}{color:#ffc66d}hashCode{color}() {
{color:#cc7832}return
{color}({color:#cc7832}int{color}){color:#9876aa}id{color}{color:#cc7832};{color}
}
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public boolean
{color}{color:#ffc66d}equals{color}(Object obj) {
{color:#cc7832}return {color}obj != {color:#cc7832}null {color}&& obj
{color:#cc7832}instanceof {color}PersonKey &&
(F.eq({color:#9876aa}id{color}{color:#cc7832},
{color}((PersonKey)obj).{color:#9876aa}id{color})){color:#cc7832};{color} }
}
\{code}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values?
was:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{code}
node.createCache(new CacheConfiguration()
.setName("PERSON_1")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
node.createCache(new CacheConfiguration()
.setName("PERSON_2")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
{code}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation
{color:#bbb529}@QuerySqlField{color}({color:#d0d0ff}index {color}=
{color:#cc7832}true{color})). Here is definition of Person class:
{color:#cc7832}public static class {color}PersonKey {
{color:#bbb529}@QuerySqlField{color} {color:#cc7832}public long
{color}{color:#9876aa}id{color}{color:#cc7832};{color}
{color:#629755}/**{color}{color:#629755} * Constructor.{color}{color:#629755}
*{color}{color:#629755} * {color}{color:#629755}@param {color}{color:#8a653b}id
{color}{color:#629755}ID.{color}{color:#629755} */{color}
{color:#ffc66d}PersonKey{color}({color:#cc7832}long {color}id) {
{color:#cc7832}this{color}.{color:#9876aa}id {color}=
id{color:#cc7832};{color} }
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public int {color}{color:#ffc66d}hashCode{color}() {
{color:#cc7832}return
{color}({color:#cc7832}int{color}){color:#9876aa}id{color}{color:#cc7832};{color}
}
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public boolean
{color}{color:#ffc66d}equals{color}(Object obj) {
{color:#cc7832}return {color}obj != {color:#cc7832}null {color}&& obj
{color:#cc7832}instanceof {color}PersonKey &&
(F.eq({color:#9876aa}id{color}{color:#cc7832},
{color}((PersonKey)obj).{color:#9876aa}id{color})){color:#cc7832};{color} }
}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values?
> Cannot create caches with different names but with same indexed types and
> schema name
> -
>
> Key: IGNITE-10195
> URL: https://issues.apache.org/jira/browse/IGNITE-10195
> Project: Ignite
> Issue Type:
[jira] [Commented] (IGNITE-10190) [TC Bot] Failed tests don't count as blockers if they were created in the PR
[ https://issues.apache.org/jira/browse/IGNITE-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679881#comment-16679881 ] ASF GitHub Bot commented on IGNITE-10190: - SomeFire opened a new pull request #62: IGNITE-10190 Failed tests don't count as blockers (if created in the PR) URL: https://github.com/apache/ignite-teamcity-bot/pull/62 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 > [TC Bot] Failed tests don't count as blockers if they were created in the PR > > > Key: IGNITE-10190 > URL: https://issues.apache.org/jira/browse/IGNITE-10190 > Project: Ignite > Issue Type: Bug >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Major > > Failed tests don't count as blockers if they were created in the PR. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10192) OptimizedMarshallerTest#testAllocationOverflow throws OOME instead of expected IOE
[
https://issues.apache.org/jira/browse/IGNITE-10192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10192:
Ignite Flags: (was: Docs Required)
> OptimizedMarshallerTest#testAllocationOverflow throws OOME instead of
> expected IOE
> --
>
> Key: IGNITE-10192
> URL: https://issues.apache.org/jira/browse/IGNITE-10192
> Project: Ignite
> Issue Type: Bug
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> OptimizedMarshallerTest#_testAllocationOverflow (in current codebase muted by
> renaming to {{_testAllocationOverflow}}) throws OOME instead of expected IOE
> when trying to marshal {{HugeObject}} - which in turn writes 4 times {{new
> byte\[1 << 31 - 2]}}.
> Note test javadocs say: "WARNING! Requires a lot of heap space. Should not be
> run on CI."
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9442) Collocated IgniteSet#close is not working on non-affinity node.
[
https://issues.apache.org/jira/browse/IGNITE-9442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679837#comment-16679837
]
Pavel Pereslegin commented on IGNITE-9442:
--
[~Mmuzaf], can you review this small patch?
> Collocated IgniteSet#close is not working on non-affinity node.
> ---
>
> Key: IGNITE-9442
> URL: https://issues.apache.org/jira/browse/IGNITE-9442
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: Reproducer.java
>
>
> Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
> contains non-affinity nodes.
> Steps to reproduce:
> 1. Start cluster with two nodes: server and client.
> 2. Create collocated {{IgniteSet}} on client node.
> 3. Close {{IgniteSet}} on client node.
> 4. Invoke {{add()}} method on closed IgniteSet.
> Expected: {{add()}} throws {{IllegalStateException}}.
> Actual: {{add()}} does not throw exception and put new "orphan" item in the
> datastructure cache.
> Alternatively to client node we can exclude server node by using cache node
> filter, as shown in attached junit reproducer.
> This bug is related to
> [IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
> affects usage of IgniteSet in cluster with non-affinity nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10193) IgniteBaselineAffinityTopologyActivationTest#testBaselineTopologyHistoryIsDeletedOnBaselineDelete fails asserting bltHist.history().size()
[
https://issues.apache.org/jira/browse/IGNITE-10193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10193:
Labels: MakeTeamcityGreenAgain (was: )
> IgniteBaselineAffinityTopologyActivationTest#testBaselineTopologyHistoryIsDeletedOnBaselineDelete
> fails asserting bltHist.history().size()
> --
>
> Key: IGNITE-10193
> URL: https://issues.apache.org/jira/browse/IGNITE-10193
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteBaselineAffinityTopologyActivationTest#testBaselineTopologyHistoryIsDeletedOnBaselineDelete
> (in current codebase muted by renaming to
> {{_testBaselineTopologyHistoryIsDeletedOnBaselineDelete}}) fails. Test
> javadoc says: "Restore this test when requirements for BaselineTopology
> deletion are clarified and this feature is covered with more tests."
> (javadoc appears to be giving proper reason)
> Failure message: {noformat}
> junit.framework.AssertionFailedError:
> Expected :0
> Actual :2
> 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:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest$17.verify(IgniteBaselineAffinityTopologyActivationTest.java:1041)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.verifyBaselineTopologyHistoryOnNodes(IgniteBaselineAffinityTopologyActivationTest.java:693)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.testBaselineTopologyHistoryIsDeletedOnBaselineDelete(IgniteBaselineAffinityTopologyActivationTest.java:1082)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Snippet of code referred to from above message: {code}assertEquals(0,
> bltHist.history().size());{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9996) Investigate possible performance drop in FSYNC mode for ignite-2.7 compared to ignite-2.6
[ https://issues.apache.org/jira/browse/IGNITE-9996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680419#comment-16680419 ] Nikolay Izhikov commented on IGNITE-9996: - [~ustas] Thanks for the benchmark results. I will try to provide fix in a one or two days. Which modes I should try to benchmark to check fix fullness? > Investigate possible performance drop in FSYNC mode for ignite-2.7 compared > to ignite-2.6 > - > > Key: IGNITE-9996 > URL: https://issues.apache.org/jira/browse/IGNITE-9996 > Project: Ignite > Issue Type: Task >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.7 > > Attachments: Screen Shot 2018-10-29 at 3.30.51 PM.png, Screen Shot > 2018-10-31 at 10.30.26 AM.png, Screen Shot 2018-11-08 at 2.38.06 PM.png > > > As per the latest reports we probably have a performance drop around 5-8% on > write benchmarks in FSYNC mode. The cause needs to be investigated and fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10196) Remove kafka-clients-*-test dependency
[ https://issues.apache.org/jira/browse/IGNITE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Pudov reassigned IGNITE-10196: Assignee: Andrey Aleksandrov (was: Maxim Pudov) > Remove kafka-clients-*-test dependency > -- > > Key: IGNITE-10196 > URL: https://issues.apache.org/jira/browse/IGNITE-10196 > Project: Ignite > Issue Type: Bug > Components: build >Affects Versions: 2.7 >Reporter: Sergey Kozlov >Assignee: Andrey Aleksandrov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10047) MVCC: Wrong coordinator assignment when two oldest nodes fail.
[
https://issues.apache.org/jira/browse/IGNITE-10047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679937#comment-16679937
]
ASF GitHub Bot commented on IGNITE-10047:
-
GitHub user rkondakov opened a pull request:
https://github.com/apache/ignite/pull/5353
IGNITE-10047: Wrong MVCC coordinator assignment when multiple nodes failed
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10047
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5353.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 #5353
commit 6c364e04d9ad8519035662852c496445d2900042
Author: rkondakov
Date: 2018-10-31T14:23:24Z
IGNITE-10047: Wrong coordinator assignment when two or more oldest nodes
fail.
> MVCC: Wrong coordinator assignment when two oldest nodes fail.
> --
>
> Key: IGNITE-10047
> URL: https://issues.apache.org/jira/browse/IGNITE-10047
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.8
>
>
> Reproducer:
> {{CacheContinuousQueryFailoverMvccTxSelfTest#testLeftPrimaryAndBackupNodes}}.
> This test can sporadically hangs when topology is unstable.
> The problem here is when two oldest nodes A and B failed, other nodes elect B
> node as a new coordinator despite it is down. This happens because the new
> mvcc coordinator is assigned in {{GridDhtPartitionsExchangeFuture#init}}
> method which is called only ones in case of multiple nodes fail
> simultaneously.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10193) IgniteBaselineAffinityTopologyActivationTest#testBaselineTopologyHistoryIsDeletedOnBaselineDelete fails asserting bltHist.history().size()
Oleg Ignatenko created IGNITE-10193:
---
Summary:
IgniteBaselineAffinityTopologyActivationTest#testBaselineTopologyHistoryIsDeletedOnBaselineDelete
fails asserting bltHist.history().size()
Key: IGNITE-10193
URL: https://issues.apache.org/jira/browse/IGNITE-10193
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Oleg Ignatenko
IgniteBaselineAffinityTopologyActivationTest#testBaselineTopologyHistoryIsDeletedOnBaselineDelete
(in current codebase muted by renaming to
{{_testBaselineTopologyHistoryIsDeletedOnBaselineDelete}}) fails. Test javadoc
says: "Restore this test when requirements for BaselineTopology deletion are
clarified and this feature is covered with more tests." (javadoc appears to be
giving proper reason)
Failure message: {noformat}
junit.framework.AssertionFailedError:
Expected :0
Actual :2
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:234)
at junit.framework.Assert.assertEquals(Assert.java:241)
at junit.framework.TestCase.assertEquals(TestCase.java:409)
at
org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest$17.verify(IgniteBaselineAffinityTopologyActivationTest.java:1041)
at
org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.verifyBaselineTopologyHistoryOnNodes(IgniteBaselineAffinityTopologyActivationTest.java:693)
at
org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.testBaselineTopologyHistoryIsDeletedOnBaselineDelete(IgniteBaselineAffinityTopologyActivationTest.java:1082)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Snippet of code referred to from above message: {code}assertEquals(0,
bltHist.history().size());{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9596) Web console: invisible checkbox is visible
[ https://issues.apache.org/jira/browse/IGNITE-9596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679309#comment-16679309 ] Pavel Konstantinov commented on IGNITE-9596: Tested on the master. > Web console: invisible checkbox is visible > -- > > Key: IGNITE-9596 > URL: https://issues.apache.org/jira/browse/IGNITE-9596 > Project: Ignite > Issue Type: Bug > Components: wizards > Environment: Firefox, Chrome (macOS), Safari >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.8 > > Attachments: image-2018-09-14-10-58-23-054.png > > Original Estimate: 3h > Time Spent: 0.5h > Remaining Estimate: 2.5h > > How it looks: > !image-2018-09-14-10-58-23-054.png! > How to reproduce: > 1. Connect to a cluster > 2. Open queries > 3. Click "+Add scan" > 4. Scroll down to filter input with "Cs" appendix. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10162) IgniteCacheAtomicQuerySelfTest#testTwoObjectsTextSearch fails with IgniteCheckedException: Failed to find SQL table for type: ObjectValue
[
https://issues.apache.org/jira/browse/IGNITE-10162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679445#comment-16679445
]
ASF GitHub Bot commented on IGNITE-10162:
-
GitHub user avplatonov opened a pull request:
https://github.com/apache/ignite/pull/5347
IGNITE-10162: IgniteCacheAtomicQuerySelfTest#testTwoObjectsTextSearch fails
with IgniteCheckedException: Failed to find SQL table for type: ObjectValue
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10162
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5347.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 #5347
commit dbe9fc384e768f3a22ff656b43c5319d7013ac3c
Author: Alexey Platonov
Date: 2018-11-08T08:42:59Z
init commit
> IgniteCacheAtomicQuerySelfTest#testTwoObjectsTextSearch fails with
> IgniteCheckedException: Failed to find SQL table for type: ObjectValue
> -
>
> Key: IGNITE-10162
> URL: https://issues.apache.org/jira/browse/IGNITE-10162
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Alexey Platonov
>Priority: Major
> Fix For: 2.8
>
>
> IgniteCacheAtomicQuerySelfTest#testTwoObjectsTextSearch (in current codebase
> muted by renaming to {{_testTwoObjectsTextSearch}}) fails:
> {noformat}
> [2018-11-07 14:37:32,728][INFO
> ][grid-nio-worker-tcp-comm-1-#91%near.IgniteCacheAtomicQuerySelfTest1%][IgniteCachePartitionedQuerySelfTest$TestTcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/127.0.0.1:47101,
> rmtAddr=/127.0.0.1:57395][2018-11-07 14:37:32,728][WARN
> ][sys-stripe-1-#61%near.IgniteCacheAtomicQuerySelfTest2%][GridQueryProcessor]
> Key-value pair is not inserted into any SQL table [cacheName=Object-Object,
> valType=o.a.i.i.processors.cache.IgniteCacheAbstractQuerySelfTest$ObjectValue]
> [2018-11-07 14:37:32,728][WARN
> ][sys-stripe-1-#61%near.IgniteCacheAtomicQuerySelfTest2%][GridQueryProcessor]
> ^-- Value type(s) are specified via CacheConfiguration.indexedTypes or
> CacheConfiguration.queryEntities
> [2018-11-07 14:37:32,728][WARN
> ][sys-stripe-1-#61%near.IgniteCacheAtomicQuerySelfTest2%][GridQueryProcessor]
> ^-- Make sure that same type(s) used when adding Object or BinaryObject to
> cache
> [2018-11-07 14:37:32,728][WARN
> ][sys-stripe-1-#61%near.IgniteCacheAtomicQuerySelfTest2%][GridQueryProcessor]
> ^-- Otherwise, entries will be stored in cache, but not appear as SQL Table
> rows
> [2018-11-07 14:37:32,744][INFO
> ][grid-nio-worker-tcp-comm-1-#94%near.IgniteCacheAtomicQuerySelfTest2%][IgniteCachePartitionedQuerySelfTest$TestTcpCommunicationSpi]
> Established outgoing communication connection [locAddr=/127.0.0.1:57395,
> rmtAddr=/127.0.0.1:47101]
> [2018-11-07 14:37:32,766][WARN
> ][sys-stripe-6-#66%near.IgniteCacheAtomicQuerySelfTest2%][GridQueryProcessor]
> Key-value pair is not inserted into any SQL table [cacheName=Object-Object,
> valType=o.a.i.i.processors.cache.IgniteCacheAbstractQuerySelfTest$ObjectValueOther]
> [2018-11-07
> 14:37:32,867][ERROR][query-#150%near.IgniteCacheAtomicQuerySelfTest2%][GridCacheDistributedQueryManager]
> Failed to run query [qry=GridCacheQueryInfo [loc=false,
> trans=null, rdc=null, qry=GridCacheQueryAdapter [type=TEXT,
> clsName=ObjectValue, clause=str, filter=null, transform=null, part=null,
> incMeta=false, metrics=null, pageSize=1024, timeout=0, incBackups=false,
> forceLocal=false, dedup=false, prj=null, keepBinary=false,
> subjId=964a4e0a-38e6-47db-b91c-95d3c410, taskHash=0, mvccSnapshot=null],
> locFut=null, sndId=964a4e0a-38e6-47db-b91c-95d3c410, reqId=27,
> incMeta=false, all=false], node=5c1facf8-cf09-498f-bdf0-e75f9942]
> class org.apache.ignite.IgniteCheckedException: Failed to find SQL table for
> type: ObjectValue
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.typeName(GridQueryProcessor.java:2675)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.access$500(GridQueryProcessor.java:129)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$9.applyx(GridQueryProcessor.java:2617)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$9.applyx(GridQueryProcessor.java:2615)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.execut
[jira] [Updated] (IGNITE-10183) [Test Failed] IgniteClientReconnectCacheTest.testReconnectOperationInProgress flaky fails on TC.
[
https://issues.apache.org/jira/browse/IGNITE-10183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-10183:
--
Description:
IgniteClientReconnectCacheTest.testReconnectOperationInProgress fails sometimes
in master (see [recent failures on
TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=-1285534571845460301&order=TEST_STATUS_DESC&branch_IgniteTests24Java8=%3Cdefault%3E&itemsCount=50]).
Test fails only for cache with {{TRANSACTIONAL_SNAPSHOT}} atomicity mode.
Typical output:
{noformat}
[2018-11-08 12:49:51,871][ERROR][main][root] Test failed.
class org.apache.ignite.IgniteCheckedException: class
org.apache.ignite.transactions.TransactionRollbackException: Transaction has
been rolled back: 6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:261)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:191)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkOperationInProgressFails(IgniteClientReconnectCacheTest.java:1421)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectOperationInProgress(IgniteClientReconnectCacheTest.java:869)
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:2208)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.cache.CacheException: class
org.apache.ignite.transactions.TransactionRollbackException: Transaction has
been rolled back: 6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:834)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:832)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest$25.call(IgniteClientReconnectCacheTest.java:1406)
at
org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:1003)
at
org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1299)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
Caused by: class org.apache.ignite.transactions.TransactionRollbackException:
Transaction has been rolled back:
6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:922)
at
org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:920)
... 10 more
Caused by: class
org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
Transaction has been rolled back:
6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4282)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2503)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2484)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2461)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1105)
... 7 more
Caused by: class org.apache.ignite.IgniteCheckedException: Cannot serialize
transaction due to write conflict (transaction is marked for rollback)
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
at
org.
[jira] [Created] (IGNITE-10195) Cannot create caches with different names but with same indexed types and schema name
Alexey Platonov created IGNITE-10195:
Summary: Cannot create caches with different names but with same
indexed types and schema name
Key: IGNITE-10195
URL: https://issues.apache.org/jira/browse/IGNITE-10195
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Platonov
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: VALUE".
{color:#9876aa}node{color}.createCache({color:#cc7832}new
{color}CacheConfiguration()
.setName({color:#9876aa}"PERSON_1"{color})
.setIndexedTypes(Key.{color:#cc7832}class,{color}
Person.{color:#cc7832}class{color})
.setSqlSchema(QueryUtils.{color:#9876aa}DFLT_SCHEMA{color})){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#9876aa}node{color}.createCache({color:#cc7832}new
{color}CacheConfiguration()
.setName({color:#9876aa}"PERSON_2"{color})
.setIndexedTypes({color:#cc7832}Key.class, Person.class{color})
.setSqlSchema(QueryUtils.{color:#9876aa}DFLT_SCHEMA{color})){color:#cc7832};{color}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation
{color:#bbb529}@QuerySqlField{color}({color:#d0d0ff}index {color}=
{color:#cc7832}true{color})). Here is definition of Person class:
{color:#cc7832}public static class {color}PersonKey {
{color:#bbb529}@QuerySqlField
{color} {color:#cc7832}public long
{color}{color:#9876aa}id{color}{color:#cc7832};
{color}{color:#cc7832}
{color} {color:#629755}/**
{color}{color:#629755} * Constructor.
{color}{color:#629755} *
{color}{color:#629755} * {color}{color:#629755}@param {color}{color:#8a653b}id
{color}{color:#629755}ID.
{color}{color:#629755} */
{color} {color:#ffc66d}PersonKey{color}({color:#cc7832}long {color}id) {
{color:#cc7832}this{color}.{color:#9876aa}id {color}= id{color:#cc7832};
{color} }
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
{color} {color:#bbb529}@Override {color}{color:#cc7832}public int
{color}{color:#ffc66d}hashCode{color}() {
{color:#cc7832}return
{color}({color:#cc7832}int{color}){color:#9876aa}id{color}{color:#cc7832};
{color} }
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
{color} {color:#bbb529}@Override {color}{color:#cc7832}public boolean
{color}{color:#ffc66d}equals{color}(Object obj) {
{color:#cc7832}return {color}obj != {color:#cc7832}null {color}&& obj
{color:#cc7832}instanceof {color}PersonKey &&
(F.eq({color:#9876aa}id{color}{color:#cc7832},
{color}((PersonKey)obj).{color:#9876aa}id{color})){color:#cc7832};
{color} }
}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10192) OptimizedMarshallerTest#testAllocationOverflow throws OOME instead of expected IOE
[
https://issues.apache.org/jira/browse/IGNITE-10192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10192:
Labels: MakeTeamcityGreenAgain (was: )
> OptimizedMarshallerTest#testAllocationOverflow throws OOME instead of
> expected IOE
> --
>
> Key: IGNITE-10192
> URL: https://issues.apache.org/jira/browse/IGNITE-10192
> Project: Ignite
> Issue Type: Bug
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> OptimizedMarshallerTest#_testAllocationOverflow (in current codebase muted by
> renaming to {{_testAllocationOverflow}}) throws OOME instead of expected IOE
> when trying to marshal {{HugeObject}} - which in turn writes 4 times {{new
> byte\[1 << 31 - 2]}}.
> Note test javadocs say: "WARNING! Requires a lot of heap space. Should not be
> run on CI."
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10185) TX can hang forever if any runtime exception occurs on txFinish.
Andrew Mashenkov created IGNITE-10185: - Summary: TX can hang forever if any runtime exception occurs on txFinish. Key: IGNITE-10185 URL: https://issues.apache.org/jira/browse/IGNITE-10185 Project: Ignite Issue Type: Bug Components: cache Reporter: Andrew Mashenkov The issue relates to incorrect IOOM handling that can occurs on Tx prepare\commit\rollback and can be reproduced if persistence enabled and Tx state logging into WAL enabled. This affects MVCC tx as it always log it's state into WAL and non-MVCC Tx with enabled WAL logging via setting IGNITE_WAL_LOG_TX_RECORDS system property. We have to check and fix if tx finish methods handle RuntimeExceptions in proper way. Good start is to force throw RuntimeException from tm().mvccPrepare() and tm().mvccFinish() methods, and check if DhtFinishFuture done correctly with exception rather then (re)throwing exception bypassing failure handler. The goal is to make IoomFailureHandlerTest passed after runtime failures during Tx commit\prepare\rollback. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10189) SslContextFactory's ciphers doesn't work with control.sh utility
Dmitry Sherstobitov created IGNITE-10189:
Summary: SslContextFactory's ciphers doesn't work with control.sh
utility
Key: IGNITE-10189
URL: https://issues.apache.org/jira/browse/IGNITE-10189
Project: Ignite
Issue Type: Bug
Reporter: Dmitry Sherstobitov
There is no options for control.sh utility if ciphers feature enabled on server
If this property enabled on server:
{code}
...
...
{code}
Control.sh utility doesn't work
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10155) Yardstick should allow modifier when starting servers
[ https://issues.apache.org/jira/browse/IGNITE-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679566#comment-16679566 ] Stephen Darlington commented on IGNITE-10155: - Still a work in progress, but PR here: https://github.com/gridgain/yardstick/pull/29 > Yardstick should allow modifier when starting servers > - > > Key: IGNITE-10155 > URL: https://issues.apache.org/jira/browse/IGNITE-10155 > Project: Ignite > Issue Type: Improvement > Components: yardstick >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > > Currently, Yardstick will start as many copies of Ignite as specified in the > configuration file. However there is currently no way to customise the > behaviour of each of those nodes. The example I'm currently working with is > forcing CPU affinity. > Related: it's also error prone to specify multiple nodes (when the number is > large). It would be nice to have some kind of shorthand to say you want, say, > four nodes on this particular host. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10183) [Test Failed] IgniteClientReconnectCacheTest.testReconnectOperationInProgress flaky fails on TC.
[
https://issues.apache.org/jira/browse/IGNITE-10183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-10183:
--
Description:
IgniteClientReconnectCacheTest.testReconnectOperationInProgress fails sometimes
in master (see [recent failures on
TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=-1285534571845460301&order=TEST_STATUS_DESC&branch_IgniteTests24Java8=%3Cdefault%3E&itemsCount=50]).
Test fails only for cache with {{TRANSACTIONAL_SNAPSHOT}} atomicity mode.
Typical output:
{noformat}
[2018-11-08 12:49:51,871][ERROR][main][root] Test failed.
class org.apache.ignite.IgniteCheckedException: class
org.apache.ignite.transactions.TransactionRollbackException: Transaction has
been rolled back: 6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:261)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:191)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkOperationInProgressFails(IgniteClientReconnectCacheTest.java:1421)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectOperationInProgress(IgniteClientReconnectCacheTest.java:869)
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:2208)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.cache.CacheException: class
org.apache.ignite.transactions.TransactionRollbackException: Transaction has
been rolled back: 6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:834)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:832)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest$25.call(IgniteClientReconnectCacheTest.java:1406)
at
org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:1003)
at
org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1299)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
Caused by: class org.apache.ignite.transactions.TransactionRollbackException:
Transaction has been rolled back:
6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:922)
at
org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:920)
... 10 more
Caused by: class
org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
Transaction has been rolled back:
6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4282)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2503)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2484)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2461)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1105)
... 7 more
Caused by: class org.apache.ignite.IgniteCheckedException: Cannot serialize
transaction due to write conflict (transaction is marked for rollback)
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
at
org.
[jira] [Created] (IGNITE-10192) OptimizedMarshallerTest#testAllocationOverflow throws OOME instead of expected IOE
Oleg Ignatenko created IGNITE-10192:
---
Summary: OptimizedMarshallerTest#testAllocationOverflow throws
OOME instead of expected IOE
Key: IGNITE-10192
URL: https://issues.apache.org/jira/browse/IGNITE-10192
Project: Ignite
Issue Type: Bug
Reporter: Oleg Ignatenko
OptimizedMarshallerTest#_testAllocationOverflow (in current codebase muted by
renaming to {{_testAllocationOverflow}}) throws OOME instead of expected IOE
when trying to marshal {{HugeObject}} - which in turn writes 4 times {{new
byte\[1 << 31 - 2]}}.
Note test javadocs say: "WARNING! Requires a lot of heap space. Should not be
run on CI."
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6145) JDBC thin: support connection pooling
[ https://issues.apache.org/jira/browse/IGNITE-6145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679659#comment-16679659 ] kcheng.mvp commented on IGNITE-6145: right now IGNITE-6140 not sure 2.7 support connection pool or not? > JDBC thin: support connection pooling > - > > Key: IGNITE-6145 > URL: https://issues.apache.org/jira/browse/IGNITE-6145 > Project: Ignite > Issue Type: Task > Components: jdbc >Affects Versions: 2.1 >Reporter: Taras Ledkov >Priority: Major > > W have to support connection pool to JDBC compliance. > At the very least we must test ourselves with well-known pooling providers > (DBCP, c3p0). > This is blocked by IGNITE-6140 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10156) Invalid convertation DynamicCacheDescriptor to StoredCacheData
[
https://issues.apache.org/jira/browse/IGNITE-10156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679531#comment-16679531
]
Ignite TC Bot commented on IGNITE-10156:
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2263071&buildTypeId=IgniteTests24Java8_RunAll]
> Invalid convertation DynamicCacheDescriptor to StoredCacheData
> --
>
> Key: IGNITE-10156
> URL: https://issues.apache.org/jira/browse/IGNITE-10156
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
>
> Invalid convertation DynamicCacheDescriptor to StoredCacheData in
> CacheRegistry#persistCacheConfigurations
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10052) Restart node during TX causes vacuum error.
[
https://issues.apache.org/jira/browse/IGNITE-10052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679705#comment-16679705
]
Ignite TC Bot commented on IGNITE-10052:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2267311]]
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSplitterSelfTest.testReplicatedTablesUsingPartitionedCacheSegmentedClient
- 0,0% fails in last 100 master runs.
{color:#d04437}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2267256]]
* IgniteBasicTestSuite:
MarshallerContextLockingSelfTest.testMultithreadedUpdate - 0,0% fails in last
100 master runs.
{color:#d04437}Data Structures{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2267291]]
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedDataStructuresFailoverSelfTest.testAtomicStampedConstantMultipleTopologyChange
- 0,0% fails in last 100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2267318&buildTypeId=IgniteTests24Java8_RunAll]
> Restart node during TX causes vacuum error.
> ---
>
> Key: IGNITE-10052
> URL: https://issues.apache.org/jira/browse/IGNITE-10052
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.7
>
>
> 1. Start 2 nodes with PDS, activate , start {{sqlline}}
> 2. Create table
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> create table t1 (a int, b int, primary
> key(a)) with "atomicity=TRANSACTIONAL_SNAPSHOT,
> backups=1";
> No rows affected (0,294 seconds)
> {noformat}
> 3. Open TX:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> begin;
> No rows affected (0,007 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
> 1 row affected (0,112 seconds)
> {noformat}
> 4. Stop and then start 2nd node
> 5. Rollback TX and check the table data (no rows added):
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> rollback;
> No rows affected (0,011 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> select * from t1;
> +++
> | A| B|
> +++
> +++
> No rows selected (0,067 seconds)
> {noformat}
> 6. Start second TX that throws the exception:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> begin;
> No rows affected (0,001 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
> Error: Failed to run update. Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []] (state=50
> 000,code=1)
> java.sql.SQLException: Failed to run update. Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchR
> ow []]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 0: jdbc:ignite:thin://127.0.0.1/>
> {noformat}
> The server nodes print out:
> {noformat}
> [18:46:32,136][SEVERE][jdbc-request-handler-worker-#62][DmlStatementsProcessor]
> Error during update [localNodeId=319a2fda-1315-4bdf-8647-7ddee2d3342e]
> class org.apache.ignite.IgniteCheckedException: Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1061)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1919)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccUpdate(GridCacheOffheapManager.java:1840)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:530)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1104)
> at
> org.apache.ig
[jira] [Updated] (IGNITE-10195) Cannot create caches with different names but with same indexed types and schema name
[
https://issues.apache.org/jira/browse/IGNITE-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Platonov updated IGNITE-10195:
-
Description:
Cannot create caches with different names but with same indexed types and
schema name.
{code:java}
node.createCache(new CacheConfiguration()
.setName("PERSON_1")
.setQueryEntities(Arrays.asList(new QueryEntity(PersonKey.class,
Person.class).setTableName("PERSON_1")))
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
node.createCache(new CacheConfiguration()
.setName("PERSON_2")
.setQueryEntities(Arrays.asList(new QueryEntity(PersonKey.class,
Person.class).setTableName("PERSON_2")))
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
{code}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation @QuerySqlField(index =
true)). Here is definition of Person class:
{code:java}
public static class PersonKey {
@QuerySqlField
public long id;
/**
* Constructor.
*
* @param id ID.
*/
PersonKey(long id) {
this.id = id;
}
/** {@inheritDoc} */
Override public int hashCode() {
return (int)id;
}
/** {@inheritDoc} */
@Override public boolean equals(Object obj) {
return obj != null && obj instanceof PersonKey && (F.eq(id,
((PersonKey)obj).id));
}
}{code}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values?
was:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{code:java}
node.createCache(new CacheConfiguration()
.setName("PERSON_1")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
node.createCache(new CacheConfiguration()
.setName("PERSON_2")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
{code}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation @QuerySqlField(index =
true)). Here is definition of Person class:
{code:java}
public static class PersonKey {
@QuerySqlField
public long id;
/**
* Constructor.
*
* @param id ID.
*/
PersonKey(long id) {
this.id = id;
}
/** {@inheritDoc} */
Override public int hashCode() {
return (int)id;
}
/** {@inheritDoc} */
@Override public boolean equals(Object obj) {
return obj != null && obj instanceof PersonKey && (F.eq(id,
((PersonKey)obj).id));
}
}{code}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values?
> Cannot create caches with different names but with same indexed types and
> schema name
> -
>
> Key: IGNITE-10195
> URL: https://issues.apache.org/jira/browse/IGNITE-10195
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Platonov
>Priority: Major
>
> Cannot create caches with different names but with same indexed types and
> schema name.
>
> {code:java}
> node.createCache(new CacheConfiguration()
> .setName("PERSON_1")
> .setQueryEntities(Arrays.asList(new QueryEntity(PersonKey.class,
> Person.class).setTableName("PERSON_1")))
> .setSqlSchema(QueryUtils.DFLT_SCHEMA));
> node.createCache(new CacheConfiguration()
> .setName("PERSON_2")
> .setQueryEntities(Arrays.asList(new QueryEntity(PersonKey.class,
> Person.class).setTableName("PERSON_2")))
> .setSqlSchema(QueryUtils.DFLT_SCHEMA));
> {code}
>
> If I set table name manually by setQueryEntities(...) then
> "javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
> thrown (Value has field with "origId" and annotation @QuerySqlField(index =
> true)). Here is definition of Person class:
>
> {code:java}
> public static class PersonKey {
> @QuerySqlField
> public long id;
> /**
> * Constructor.
> *
> * @param id ID.
> */
> PersonKey(long id) {
> this.id = id;
> }
> /** {@inheritDoc} */
> Override public int hashCode() {
> return (int)id;
> }
> /** {@inheritDoc} */
> @Override public boolean equals(Object obj) {
> return obj != null && obj instanceof PersonKey && (F.eq(id,
> ((PersonKey)obj).id));
> }
> }{code}
> Such behavior seems to be usability bug. Why I cannot create two caches with
> different names but with same indexed values?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10108) Non-static class is passed between cluster nodes
[
https://issues.apache.org/jira/browse/IGNITE-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679711#comment-16679711
]
Maxim Muzafarov commented on IGNITE-10108:
--
[~roman_s]
Yes, you are right. The {{manualCacheRebalancing}} method is used only for
{{CacheBaselineTopologyTest}} and only for rare cases.
But I think we should keep it at {{GridCommonAbstractTest}} as a tool for
widespread use.
> Non-static class is passed between cluster nodes
>
>
> Key: IGNITE-10108
> URL: https://issues.apache.org/jira/browse/IGNITE-10108
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Roman Shtykh
>Priority: Major
>
> Need to avoid passing anonymous classes on compute, because this lead to
> serialize whole test-class context.
> By the reason need to refactor that place
> {code}
> ignite.compute().withTimeout(5_000).broadcastAsync(new IgniteRunnable() {
> ...
> });
> {code}
> in method \{{GridCommonAbstractTest#manualCacheRebalancing}} into private
> static nested class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10147) CPP thin: Headers are not installed on make install
[
https://issues.apache.org/jira/browse/IGNITE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679771#comment-16679771
]
ASF GitHub Bot commented on IGNITE-10147:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5315
> CPP thin: Headers are not installed on make install
> ---
>
> Key: IGNITE-10147
> URL: https://issues.apache.org/jira/browse/IGNITE-10147
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Critical
> Labels: cpp
> Fix For: 2.7
>
>
> Currently, {{make install}} command from {{platforms/cpp}} does not install
> headers for C++ thin client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10193) IgniteBaselineAffinityTopologyActivationTest#testBaselineTopologyHistoryIsDeletedOnBaselineDelete fails asserting bltHist.history().size()
[
https://issues.apache.org/jira/browse/IGNITE-10193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10193:
Ignite Flags: (was: Docs Required)
> IgniteBaselineAffinityTopologyActivationTest#testBaselineTopologyHistoryIsDeletedOnBaselineDelete
> fails asserting bltHist.history().size()
> --
>
> Key: IGNITE-10193
> URL: https://issues.apache.org/jira/browse/IGNITE-10193
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
>
> IgniteBaselineAffinityTopologyActivationTest#testBaselineTopologyHistoryIsDeletedOnBaselineDelete
> (in current codebase muted by renaming to
> {{_testBaselineTopologyHistoryIsDeletedOnBaselineDelete}}) fails. Test
> javadoc says: "Restore this test when requirements for BaselineTopology
> deletion are clarified and this feature is covered with more tests."
> (javadoc appears to be giving proper reason)
> Failure message: {noformat}
> junit.framework.AssertionFailedError:
> Expected :0
> Actual :2
> 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:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest$17.verify(IgniteBaselineAffinityTopologyActivationTest.java:1041)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.verifyBaselineTopologyHistoryOnNodes(IgniteBaselineAffinityTopologyActivationTest.java:693)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.testBaselineTopologyHistoryIsDeletedOnBaselineDelete(IgniteBaselineAffinityTopologyActivationTest.java:1082)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Snippet of code referred to from above message: {code}assertEquals(0,
> bltHist.history().size());{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10195) Cannot create caches with different names but with same indexed types and schema name
[
https://issues.apache.org/jira/browse/IGNITE-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-10195:
---
Description:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{code|lang=java}
node.createCache(new CacheConfiguration()
.setName("PERSON_1")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
node.createCache(new CacheConfiguration()
.setName("PERSON_2")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
{code}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation
{color:#bbb529}@QuerySqlField{color}({color:#d0d0ff}index {color}=
{color:#cc7832}true{color})). Here is definition of Person class:
{color:#cc7832}public static class {color}PersonKey {
{color:#bbb529}@QuerySqlField{color} {color:#cc7832}public long
{color}{color:#9876aa}id{color}{color:#cc7832};{color}
{color:#629755}/**{color}{color:#629755} * Constructor.{color}{color:#629755}
*{color}{color:#629755} * {color}{color:#629755}@param {color}{color:#8a653b}id
{color}{color:#629755}ID.{color}{color:#629755} */{color}
{color:#ffc66d}PersonKey{color}({color:#cc7832}long {color}id) {
{color:#cc7832}this{color}.{color:#9876aa}id {color}=
id{color:#cc7832};{color} }
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public int {color}{color:#ffc66d}hashCode{color}() {
{color:#cc7832}return
{color}({color:#cc7832}int{color}){color:#9876aa}id{color}{color:#cc7832};{color}
}
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public boolean
{color}{color:#ffc66d}equals{color}(Object obj) {
{color:#cc7832}return {color}obj != {color:#cc7832}null {color}&& obj
{color:#cc7832}instanceof {color}PersonKey &&
(F.eq({color:#9876aa}id{color}{color:#cc7832},
{color}((PersonKey)obj).{color:#9876aa}id{color})){color:#cc7832};{color} }
}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values?
was:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{code}
{color:#9876aa}node{color}.createCache({color:#cc7832}new
{color}CacheConfiguration()
.setName({color:#9876aa}"PERSON_1"{color})
.setIndexedTypes(Key.{color:#cc7832}class,{color}
Person.{color:#cc7832}class{color})
.setSqlSchema(QueryUtils.{color:#9876aa}DFLT_SCHEMA{color})){color:#cc7832};{color}{color:#9876aa}node{color}.createCache({color:#cc7832}new
{color}CacheConfiguration()
.setName({color:#9876aa}"PERSON_2"{color})
.setIndexedTypes({color:#cc7832}Key.class, Person.class{color})
.setSqlSchema(QueryUtils.{color:#9876aa}DFLT_SCHEMA{color})){color:#cc7832};{color}
{code}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation
{color:#bbb529}@QuerySqlField{color}({color:#d0d0ff}index {color}=
{color:#cc7832}true{color})). Here is definition of Person class:
{color:#cc7832}public static class {color}PersonKey {
{color:#bbb529}@QuerySqlField{color} {color:#cc7832}public long
{color}{color:#9876aa}id{color}{color:#cc7832};{color}
{color:#629755}/**{color}{color:#629755} * Constructor.{color}{color:#629755}
*{color}{color:#629755} * {color}{color:#629755}@param {color}{color:#8a653b}id
{color}{color:#629755}ID.{color}{color:#629755} */{color}
{color:#ffc66d}PersonKey{color}({color:#cc7832}long {color}id) {
{color:#cc7832}this{color}.{color:#9876aa}id {color}=
id{color:#cc7832};{color} }
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public int {color}{color:#ffc66d}hashCode{color}() {
{color:#cc7832}return
{color}({color:#cc7832}int{color}){color:#9876aa}id{color}{color:#cc7832};{color}
}
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public boolean
{color}{color:#ffc66d}equals{color}(Object obj) {
{color:#cc7832}return {color}obj != {color:#cc7832}null {color}&& obj
{color:#cc7832}instanceof {color}PersonKey &&
(F.eq({color:#9876aa}id{color}{color:#cc7832},
{color}((PersonKey)obj).{color:#9876aa}id{color})){color:#cc7832};{color} }
}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values?
> Cannot create caches with different names but with same i
[jira] [Assigned] (IGNITE-10155) Yardstick should allow modifier when starting servers
[ https://issues.apache.org/jira/browse/IGNITE-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington reassigned IGNITE-10155: --- Assignee: Stephen Darlington > Yardstick should allow modifier when starting servers > - > > Key: IGNITE-10155 > URL: https://issues.apache.org/jira/browse/IGNITE-10155 > Project: Ignite > Issue Type: Improvement > Components: yardstick >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > > Currently, Yardstick will start as many copies of Ignite as specified in the > configuration file. However there is currently no way to customise the > behaviour of each of those nodes. The example I'm currently working with is > forcing CPU affinity. > Related: it's also error prone to specify multiple nodes (when the number is > large). It would be nice to have some kind of shorthand to say you want, say, > four nodes on this particular host. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9840) Possible deadlock on transactional future on client node in case of network problems or long GC pauses
[
https://issues.apache.org/jira/browse/IGNITE-9840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679544#comment-16679544
]
Ignite TC Bot commented on IGNITE-9840:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2270370&buildTypeId=IgniteTests24Java8_Spi]
> Possible deadlock on transactional future on client node in case of network
> problems or long GC pauses
> --
>
> Key: IGNITE-9840
> URL: https://issues.apache.org/jira/browse/IGNITE-9840
> Project: Ignite
> Issue Type: Bug
> Components: clients
>Affects Versions: 2.6
>Reporter: Andrey Aleksandrov
>Assignee: Ilya Lantukh
>Priority: Critical
> Fix For: 2.8
>
>
> Steps to reproduce:
> 1)Start the server node with next timeouts. DefaultTxTimeout should be
> greater than other:
>
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> On the server side you should create a cache with next parameters:
>
>
> {code:java}
>
>
>
>
>
>
> {code}
> 2)After that start the client with the next code:
> {code:java}
> IgniteCache cache = ignite.getOrCreateCache("CACHE");
> try (Transaction tx = ignite.transactions().txStart()) {
> cache.put("Key", new Object());
> System.out.println("Stop me");
> //here we will get long GC pause on server side
> Thread.sleep(1);
> // Commit the transaction.
> tx.commitAsync().get();
> }
> {code}
>
> On step "Stop me" you should suspend all the thread on the server side to
> emulate the networking problem or long GC pause on the server side.
> Finally, you will face in client node next:
> {code:java}
> [2018-10-10 16:46:10,157][ERROR][nio-acceptor-tcp-comm-#28%GRIDC1%][root]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker
> [name=grid-timeout-worker, igniteInstanceName=GRIDC1, finished=false,
> heartbeatTs=1539179057570]]]
> {code}
> Also, the similar issue could be reproduced in 2.4. In both cases looks like
> we have a deadlock during trying to display the TxEntryValueHolder. Looks
> like this values are already used by the transaction with long
> DefaultTxTimeout .
> {code:java}
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata0(CacheObjectBinaryProcessorImpl.java:526)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:510)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:193)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1265)
> at org.apache.ignite.internal.binary.BinaryUtils.type(BinaryUtils.java:2407)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.rawType(BinaryObjectImpl.java:302)
> at
> org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:205)
> at
> org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:186)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.toString(BinaryObjectImpl.java:919)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.toString(TxEntryValueHolder.java:161)
> ...{code}
> On the client side, it could be looked like a hanging transaction because we
> waiting on:
> {code:java}
> tx.commitAsync().get();{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10191) Incorrect comparison of lists in RendezvousAffinityFunctionSimpleBenchmark#testAffinityCompatibility
[
https://issues.apache.org/jira/browse/IGNITE-10191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10191:
Ignite Flags: (was: Docs Required)
> Incorrect comparison of lists in
> RendezvousAffinityFunctionSimpleBenchmark#testAffinityCompatibility
>
>
> Key: IGNITE-10191
> URL: https://issues.apache.org/jira/browse/IGNITE-10191
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> RendezvousAffinityFunctionSimpleBenchmark#testAffinityCompatibility (in
> current codebase muted by renaming to {{_testAffinityCompatibility}}) looks
> troublesome: apparent bug is incorrect comparison of lists expecting elements
> to be always in the same order which doesn't look like the case for the
> tested API:
> {code}List> assignment0 =
> assignPartitions(aff0, nodes, null, backups, 0).get2();
> List> assignment1 =
> assignPartitions(aff1, nodes, null, backups, 0).get2();
> assertEquals (assignment0, assignment1);
> {code}
> Though test kept failing even after I experimented with replacing comparison
> to one that was insensitive to the order of list elements.
> Brief checking of code intended to be tested suggests that maybe it isn't
> even supposed to be deterministic - in case if this is correct test should be
> very thoroughly redesigned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10183) [Test Failed] IgniteClientReconnectCacheTest.testReconnectOperationInProgress flaky fails on TC.
[
https://issues.apache.org/jira/browse/IGNITE-10183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-10183:
--
Description:
IgniteClientReconnectCacheTest.testReconnectOperationInProgress fails sometimes
in master (see [recent failures on
TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=-1285534571845460301&order=TEST_STATUS_DESC&branch_IgniteTests24Java8=%3Cdefault%3E&itemsCount=50]).
Test fails only for cache with {{TRANSACTIONAL_SNAPSHOT}} atomicity mode.
Typical output:
{noformat}
[2018-11-07 23:13:00,579][ERROR][main][root] Test failed.
class org.apache.ignite.IgniteCheckedException: class
org.apache.ignite.transactions.TransactionRollbackException: Transaction has
been rolled back: 2e10370f661--0920-4f4e--0026
at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:261)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:191)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkOperationInProgressFails(IgniteClientReconnectCacheTest.java:1421)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectOperationInProgress(IgniteClientReconnectCacheTest.java:869)
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:2208)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.cache.CacheException: class
org.apache.ignite.transactions.TransactionRollbackException: Transaction has
been rolled back: 2e10370f661--0920-4f4e--0026
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:834)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:832)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest$25.call(IgniteClientReconnectCacheTest.java:1406)
at
org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:1003)
at
org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1299)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
Caused by: class org.apache.ignite.transactions.TransactionRollbackException:
Transaction has been rolled back:
2e10370f661--0920-4f4e--0026
at
org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:922)
at
org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:920)
... 10 more
Caused by: class
org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
Transaction has been rolled back:
2e10370f661--0920-4f4e--0026
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4282)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2503)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2484)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2461)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1105)
... 7 more
Caused by: class org.apache.ignite.IgniteCheckedException: Cannot serialize
transaction due to write conflict (transaction is marked for rollback)
at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:261)
at
org.apache.ignite.internal.util.future.GridFuture
[jira] [Commented] (IGNITE-7955) MVCC TX: cache peek for key-value API
[
https://issues.apache.org/jira/browse/IGNITE-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679965#comment-16679965
]
Ignite TC Bot commented on IGNITE-7955:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2265095&buildTypeId=IgniteTests24Java8_RunAll]
> MVCC TX: cache peek for key-value API
> -
>
> Key: IGNITE-7955
> URL: https://issues.apache.org/jira/browse/IGNITE-7955
> Project: Ignite
> Issue Type: Task
> Components: cache, mvcc
>Reporter: Alexander Paschenko
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
>
> We need to implement MVCC-compatible cache peek operation for key-value API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10195) Cannot create caches with different names but with same indexed types and schema name
[
https://issues.apache.org/jira/browse/IGNITE-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-10195:
---
Description:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{code}
node.createCache(new CacheConfiguration()
.setName("PERSON_1")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
node.createCache(new CacheConfiguration()
.setName("PERSON_2")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
{code}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation
{color:#bbb529}@QuerySqlField{color}({color:#d0d0ff}index {color}=
{color:#cc7832}true{color})). Here is definition of Person class:
{color:#cc7832}public static class {color}PersonKey {
{color:#bbb529}@QuerySqlField{color} {color:#cc7832}public long
{color}{color:#9876aa}id{color}{color:#cc7832};{color}
{color:#629755}/**{color}{color:#629755} * Constructor.{color}{color:#629755}
*{color}{color:#629755} * {color}{color:#629755}@param {color}{color:#8a653b}id
{color}{color:#629755}ID.{color}{color:#629755} */{color}
{color:#ffc66d}PersonKey{color}({color:#cc7832}long {color}id) {
{color:#cc7832}this{color}.{color:#9876aa}id {color}=
id{color:#cc7832};{color} }
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public int {color}{color:#ffc66d}hashCode{color}() {
{color:#cc7832}return
{color}({color:#cc7832}int{color}){color:#9876aa}id{color}{color:#cc7832};{color}
}
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public boolean
{color}{color:#ffc66d}equals{color}(Object obj) {
{color:#cc7832}return {color}obj != {color:#cc7832}null {color}&& obj
{color:#cc7832}instanceof {color}PersonKey &&
(F.eq({color:#9876aa}id{color}{color:#cc7832},
{color}((PersonKey)obj).{color:#9876aa}id{color})){color:#cc7832};{color} }
}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values?
was:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{code|lang=java}
node.createCache(new CacheConfiguration()
.setName("PERSON_1")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
node.createCache(new CacheConfiguration()
.setName("PERSON_2")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
{code}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation
{color:#bbb529}@QuerySqlField{color}({color:#d0d0ff}index {color}=
{color:#cc7832}true{color})). Here is definition of Person class:
{color:#cc7832}public static class {color}PersonKey {
{color:#bbb529}@QuerySqlField{color} {color:#cc7832}public long
{color}{color:#9876aa}id{color}{color:#cc7832};{color}
{color:#629755}/**{color}{color:#629755} * Constructor.{color}{color:#629755}
*{color}{color:#629755} * {color}{color:#629755}@param {color}{color:#8a653b}id
{color}{color:#629755}ID.{color}{color:#629755} */{color}
{color:#ffc66d}PersonKey{color}({color:#cc7832}long {color}id) {
{color:#cc7832}this{color}.{color:#9876aa}id {color}=
id{color:#cc7832};{color} }
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public int {color}{color:#ffc66d}hashCode{color}() {
{color:#cc7832}return
{color}({color:#cc7832}int{color}){color:#9876aa}id{color}{color:#cc7832};{color}
}
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public boolean
{color}{color:#ffc66d}equals{color}(Object obj) {
{color:#cc7832}return {color}obj != {color:#cc7832}null {color}&& obj
{color:#cc7832}instanceof {color}PersonKey &&
(F.eq({color:#9876aa}id{color}{color:#cc7832},
{color}((PersonKey)obj).{color:#9876aa}id{color})){color:#cc7832};{color} }
}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values?
> Cannot create caches with different names but with same indexed types and
> schema name
> -
>
> Key: IGNITE-10195
> URL: https://issues.apache.org/jira/browse/IGNITE-10195
> Project: Ignite
> Issue Type: Impr
[jira] [Comment Edited] (IGNITE-10118) JDBC v2: metadata.getSchemas returns cache names instead of schema names
[
https://issues.apache.org/jira/browse/IGNITE-10118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679880#comment-16679880
]
Pavel Kuznetsov edited comment on IGNITE-10118 at 11/8/18 3:08 PM:
---
In the same way as in IGNITE-9989 I got rid of distributed task that collects
metadata. Used ignite instance of JdbcConnection and iterated over
{{DynamicCacheDescriptor}} s to get schema names.
was (Author: pkouznet):
In the same way as in IGNITE-9989 I got rid of distributed task that collects
metadata. Used ignite instance of JdbcConnection and iterated over
{{DynamicCacheDescriptor}}s to get schema names.
> JDBC v2: metadata.getSchemas returns cache names instead of schema names
>
>
> Key: IGNITE-10118
> URL: https://issues.apache.org/jira/browse/IGNITE-10118
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Affects Versions: 2.6
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
>
> jdbc v2 returns list of cache names instead of list of schemas.
> It is correct only if we have a cache and table created in it using cache API.
> If we create tables using ddl we expect to see "PUBLIC" schema name in
> results of {{connection.getMetadata().getSchemas()}} not
> "SQL_PUBLIC_TABLENAME"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10167) MVCC-compatible IgniteCache.localEntries
[
https://issues.apache.org/jira/browse/IGNITE-10167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679747#comment-16679747
]
Ivan Pavlukhin commented on IGNITE-10167:
-
Observation: {{localEntries}} are not so widely used in tests. So, it might not
be a big blocker on the way of adopting existing tests for MVCC.
> MVCC-compatible IgniteCache.localEntries
>
>
> Key: IGNITE-10167
> URL: https://issues.apache.org/jira/browse/IGNITE-10167
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Priority: Major
>
> IgniteCache API method {{localEntries}} should be supported. The idea is to
> provide an entries iterator seeing latest committed versions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10118) JDBC v2: metadata.getSchemas returns cache names instead of schema names
[
https://issues.apache.org/jira/browse/IGNITE-10118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679880#comment-16679880
]
Pavel Kuznetsov edited comment on IGNITE-10118 at 11/8/18 3:09 PM:
---
In the same way as in IGNITE-9989 I got rid of distributed task that collects
metadata. Used ignite instance of JdbcConnection and iterated over
{{DynamicCacheDescriptor}} collection to get schema names.
was (Author: pkouznet):
In the same way as in IGNITE-9989 I got rid of distributed task that collects
metadata. Used ignite instance of JdbcConnection and iterated over
{{DynamicCacheDescriptor}} s to get schema names.
> JDBC v2: metadata.getSchemas returns cache names instead of schema names
>
>
> Key: IGNITE-10118
> URL: https://issues.apache.org/jira/browse/IGNITE-10118
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Affects Versions: 2.6
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
>
> jdbc v2 returns list of cache names instead of list of schemas.
> It is correct only if we have a cache and table created in it using cache API.
> If we create tables using ddl we expect to see "PUBLIC" schema name in
> results of {{connection.getMetadata().getSchemas()}} not
> "SQL_PUBLIC_TABLENAME"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10154) Critical worker liveness check configuration is non-trivial and inconsistent
[
https://issues.apache.org/jira/browse/IGNITE-10154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679579#comment-16679579
]
Andrey Gura commented on IGNITE-10154:
--
Agree, it's breaking change. Solution: add
{{FailureType.SYSTEM_WORKER_BLOCKED}} to
{{AbstractFailureHandler.ignoredFailureTypes}} by default.
> Critical worker liveness check configuration is non-trivial and inconsistent
>
>
> Key: IGNITE-10154
> URL: https://issues.apache.org/jira/browse/IGNITE-10154
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Artem Budnikov
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.7
>
>
> The way the critical thread liveness check is configured has a number of
> usability issues.
> 1) By default, the liveness check is disabled (i.e. if no failure handler is
> specified in the configuration). However, if you specify any handler
> (including the default one), liveness check gets enabled (which is something
> the users may not want) unless you disable it explicitly.
> 2) Users that use Ignite 2.6 with a configured failure handler will get this
> check enabled after migrating to Ignite 2.7.
> In the two cases above, the functionality changes in a non-trivial way.
> Ideally, we need an option that enables this functionality explicitly. A
> possible example would be to keep liveness check disabled until the user sets
> the systemWorkerBlockedTimeout to a positive value. (Or the other way around:
> enable liveness check by default until the user explicitly disables it).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10195) Cannot create caches with different names but with same indexed types and schema name
[
https://issues.apache.org/jira/browse/IGNITE-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-10195:
---
Description:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{code}
{color:#9876aa}node{color}.createCache({color:#cc7832}new
{color}CacheConfiguration()
.setName({color:#9876aa}"PERSON_1"{color})
.setIndexedTypes(Key.{color:#cc7832}class,{color}
Person.{color:#cc7832}class{color})
.setSqlSchema(QueryUtils.{color:#9876aa}DFLT_SCHEMA{color})){color:#cc7832};{color}{color:#9876aa}node{color}.createCache({color:#cc7832}new
{color}CacheConfiguration()
.setName({color:#9876aa}"PERSON_2"{color})
.setIndexedTypes({color:#cc7832}Key.class, Person.class{color})
.setSqlSchema(QueryUtils.{color:#9876aa}DFLT_SCHEMA{color})){color:#cc7832};{color}
{code}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation
{color:#bbb529}@QuerySqlField{color}({color:#d0d0ff}index {color}=
{color:#cc7832}true{color})). Here is definition of Person class:
{color:#cc7832}public static class {color}PersonKey {
{color:#bbb529}@QuerySqlField{color} {color:#cc7832}public long
{color}{color:#9876aa}id{color}{color:#cc7832};{color}
{color:#629755}/**{color}{color:#629755} * Constructor.{color}{color:#629755}
*{color}{color:#629755} * {color}{color:#629755}@param {color}{color:#8a653b}id
{color}{color:#629755}ID.{color}{color:#629755} */{color}
{color:#ffc66d}PersonKey{color}({color:#cc7832}long {color}id) {
{color:#cc7832}this{color}.{color:#9876aa}id {color}=
id{color:#cc7832};{color} }
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public int {color}{color:#ffc66d}hashCode{color}() {
{color:#cc7832}return
{color}({color:#cc7832}int{color}){color:#9876aa}id{color}{color:#cc7832};{color}
}
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public boolean
{color}{color:#ffc66d}equals{color}(Object obj) {
{color:#cc7832}return {color}obj != {color:#cc7832}null {color}&& obj
{color:#cc7832}instanceof {color}PersonKey &&
(F.eq({color:#9876aa}id{color}{color:#cc7832},
{color}((PersonKey)obj).{color:#9876aa}id{color})){color:#cc7832};{color} }
}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values?
was:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{color:#9876aa}node{color}.createCache({color:#cc7832}new
{color}CacheConfiguration()
.setName({color:#9876aa}"PERSON_1"{color})
.setIndexedTypes(Key.{color:#cc7832}class,{color}
Person.{color:#cc7832}class{color})
.setSqlSchema(QueryUtils.{color:#9876aa}DFLT_SCHEMA{color})){color:#cc7832};{color}{color:#9876aa}node{color}.createCache({color:#cc7832}new
{color}CacheConfiguration()
.setName({color:#9876aa}"PERSON_2"{color})
.setIndexedTypes({color:#cc7832}Key.class, Person.class{color})
.setSqlSchema(QueryUtils.{color:#9876aa}DFLT_SCHEMA{color})){color:#cc7832};{color}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation
{color:#bbb529}@QuerySqlField{color}({color:#d0d0ff}index {color}=
{color:#cc7832}true{color})). Here is definition of Person class:
{color:#cc7832}public static class {color}PersonKey {
{color:#bbb529}@QuerySqlField{color} {color:#cc7832}public long
{color}{color:#9876aa}id{color}{color:#cc7832};{color}
{color:#629755}/**{color}{color:#629755} * Constructor.{color}{color:#629755}
*{color}{color:#629755} * {color}{color:#629755}@param {color}{color:#8a653b}id
{color}{color:#629755}ID.{color}{color:#629755} */{color}
{color:#ffc66d}PersonKey{color}({color:#cc7832}long {color}id) {
{color:#cc7832}this{color}.{color:#9876aa}id {color}=
id{color:#cc7832};{color} }
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public int {color}{color:#ffc66d}hashCode{color}() {
{color:#cc7832}return
{color}({color:#cc7832}int{color}){color:#9876aa}id{color}{color:#cc7832};{color}
}
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public boolean
{color}{color:#ffc66d}equals{color}(Object obj) {
{color:#cc7832}return {color}obj != {color:#cc7832}null {color}&& obj
{color:#cc7832}instanceof {color}PersonKey &&
(F.eq({color:#9876aa}id{color}{color:#cc7832},
{co
[jira] [Updated] (IGNITE-10183) [Test Failed] IgniteClientReconnectCacheTest.testReconnectOperationInProgress flaky fails on TC.
[
https://issues.apache.org/jira/browse/IGNITE-10183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-10183:
--
Labels: MakeTeamcityGreenAgain (was: )
> [Test Failed] IgniteClientReconnectCacheTest.testReconnectOperationInProgress
> flaky fails on TC.
>
>
> Key: IGNITE-10183
> URL: https://issues.apache.org/jira/browse/IGNITE-10183
> Project: Ignite
> Issue Type: Bug
> Components: cache, mvcc
>Affects Versions: 2.7
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteClientReconnectCacheTest.testReconnectOperationInProgress fails
> sometimes in master (see [recent failures on
> TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=-1285534571845460301&order=TEST_STATUS_DESC&branch_IgniteTests24Java8=%3Cdefault%3E&itemsCount=50]).
> Test fails only for cache with {{TRANSACTIONAL_SNAPSHOT}} atomicity mode.
> Typical output:
> {noformat}
> [2018-11-08 12:49:51,871][ERROR][main][root] Test failed.
> class org.apache.ignite.IgniteCheckedException: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 6643ab2f661--0920-e484--0010
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:261)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:191)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkOperationInProgressFails(IgniteClientReconnectCacheTest.java:1421)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectOperationInProgress(IgniteClientReconnectCacheTest.java:869)
> 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:2208)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.cache.CacheException: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 6643ab2f661--0920-e484--0010
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:834)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:832)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest$25.call(IgniteClientReconnectCacheTest.java:1406)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:1003)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1299)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
> Caused by: class org.apache.ignite.transactions.TransactionRollbackException:
> Transaction has been rolled back:
> 6643ab2f661--0920-e484--0010
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:922)
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:920)
> ... 10 more
> Caused by: class
> org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
> Transaction has been rolled back:
> 6643ab2f661--0920-e484--0010
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4282)
> at
> org.apache.ignite.in
[jira] [Commented] (IGNITE-9840) Possible deadlock on transactional future on client node in case of network problems or long GC pauses
[
https://issues.apache.org/jira/browse/IGNITE-9840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679520#comment-16679520
]
Ignite TC Bot commented on IGNITE-9840:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Binary Objects (Simple Mapper Basic){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2265108]]
* IgniteBinarySimpleNameMapperBasicTestSuite:
BPlusTreeReuseSelfTest.testMassiveRemove2_false - 0,0% fails in last 100 master
runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2256192&buildTypeId=IgniteTests24Java8_RunAll]
> Possible deadlock on transactional future on client node in case of network
> problems or long GC pauses
> --
>
> Key: IGNITE-9840
> URL: https://issues.apache.org/jira/browse/IGNITE-9840
> Project: Ignite
> Issue Type: Bug
> Components: clients
>Affects Versions: 2.6
>Reporter: Andrey Aleksandrov
>Assignee: Ilya Lantukh
>Priority: Critical
> Fix For: 2.8
>
>
> Steps to reproduce:
> 1)Start the server node with next timeouts. DefaultTxTimeout should be
> greater than other:
>
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> On the server side you should create a cache with next parameters:
>
>
> {code:java}
>
>
>
>
>
>
> {code}
> 2)After that start the client with the next code:
> {code:java}
> IgniteCache cache = ignite.getOrCreateCache("CACHE");
> try (Transaction tx = ignite.transactions().txStart()) {
> cache.put("Key", new Object());
> System.out.println("Stop me");
> //here we will get long GC pause on server side
> Thread.sleep(1);
> // Commit the transaction.
> tx.commitAsync().get();
> }
> {code}
>
> On step "Stop me" you should suspend all the thread on the server side to
> emulate the networking problem or long GC pause on the server side.
> Finally, you will face in client node next:
> {code:java}
> [2018-10-10 16:46:10,157][ERROR][nio-acceptor-tcp-comm-#28%GRIDC1%][root]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker
> [name=grid-timeout-worker, igniteInstanceName=GRIDC1, finished=false,
> heartbeatTs=1539179057570]]]
> {code}
> Also, the similar issue could be reproduced in 2.4. In both cases looks like
> we have a deadlock during trying to display the TxEntryValueHolder. Looks
> like this values are already used by the transaction with long
> DefaultTxTimeout .
> {code:java}
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata0(CacheObjectBinaryProcessorImpl.java:526)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:510)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:193)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1265)
> at org.apache.ignite.internal.binary.BinaryUtils.type(BinaryUtils.java:2407)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.rawType(BinaryObjectImpl.java:302)
> at
> org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:205)
> at
> org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:186)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.toString(BinaryObjectImpl.java:919)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.toString(TxEntryValueHolder.java:161)
> ...{code}
> On the client side, it could be looked like a hanging transaction because we
> waiting on:
> {code:java}
> tx.commitAsync().get();{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-6145) JDBC thin: support connection pooling
[ https://issues.apache.org/jira/browse/IGNITE-6145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679659#comment-16679659 ] kcheng.mvp edited comment on IGNITE-6145 at 11/8/18 12:03 PM: -- right now IGNITE-6140 fix in 2.7, not sure the coming release support connection pool or not? was (Author: kcheng.mvp): right now IGNITE-6140 not sure 2.7 support connection pool or not? > JDBC thin: support connection pooling > - > > Key: IGNITE-6145 > URL: https://issues.apache.org/jira/browse/IGNITE-6145 > Project: Ignite > Issue Type: Task > Components: jdbc >Affects Versions: 2.1 >Reporter: Taras Ledkov >Priority: Major > > W have to support connection pool to JDBC compliance. > At the very least we must test ourselves with well-known pooling providers > (DBCP, c3p0). > This is blocked by IGNITE-6140 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9996) Investigate possible performance drop in FSYNC mode for ignite-2.7 compared to ignite-2.6
[ https://issues.apache.org/jira/browse/IGNITE-9996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679643#comment-16679643 ] Ilya Suntsov commented on IGNITE-9996: -- Last results were attached. I didn't use encrypted caches. > Investigate possible performance drop in FSYNC mode for ignite-2.7 compared > to ignite-2.6 > - > > Key: IGNITE-9996 > URL: https://issues.apache.org/jira/browse/IGNITE-9996 > Project: Ignite > Issue Type: Task >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.7 > > Attachments: Screen Shot 2018-10-29 at 3.30.51 PM.png, Screen Shot > 2018-10-31 at 10.30.26 AM.png, Screen Shot 2018-11-08 at 2.38.06 PM.png > > > As per the latest reports we probably have a performance drop around 5-8% on > write benchmarks in FSYNC mode. The cause needs to be investigated and fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8469) Non-heap memory leak for calling cluster activation multi times
[
https://issues.apache.org/jira/browse/IGNITE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679644#comment-16679644
]
Maxim Muzafarov edited comment on IGNITE-8469 at 11/8/18 11:40 AM:
---
[~mshonichev]
If you are checking the 2.7 release branch it seems to me that it's not
possible to run a different cluster on the same PDS files (don't know if this
correct). This was my case.
was (Author: mmuzaf):
[~mshonichev]
If you are checking the 2.7 release branch it seems to me that it's not
possible to run a different cluster on the same PDS files (don't know if this
correct). This is was my case.
> Non-heap memory leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.7
>
>
> Calling multiple time cluster (with enabled persistence and started client
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory
> leak.
> Line
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}}
> looks suspicious because of in case method
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}}
> callled multi times (e.g. activate(true) called multi times) we lost info
> about allocated regions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10199) unexpected result from QueryCursor.getAll() in IgniteSqlSplitterSelfTest#testMergeJoin
[
https://issues.apache.org/jira/browse/IGNITE-10199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10199:
Ignite Flags: (was: Docs Required)
> unexpected result from QueryCursor.getAll() in
> IgniteSqlSplitterSelfTest#testMergeJoin
> --
>
> Key: IGNITE-10199
> URL: https://issues.apache.org/jira/browse/IGNITE-10199
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteSqlSplitterSelfTest#testMergeJoin (in current codebase muted by
> renaming to {{_testMergeJoin}}) fails with message:
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at
> org.apache.ignite.internal.processors.query.IgniteSqlSplitterSelfTest.testMergeJoin(IgniteSqlSplitterSelfTest.java:182)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Test code referred by above message is last assert in below snippet: {code}
> String qry = "select o1.* from Org o1, " +
> "(select max(o.name) as name, o.id from Org o group by o.id)
> o2 " +
> "where o1.id = o2.id";
> List> plan = c.query(new SqlFieldsQuery("explain " + qry)
> .setEnforceJoinOrder(true)).getAll();
> X.println("Plan: " + plan);
> String map0 = (String)plan.get(0).get(0);
> String map1 = (String)plan.get(1).get(0);
> String rdc = (String)plan.get(2).get(0);
> assertTrue(map0.contains("ORDER BY"));
> assertTrue(map1.contains("ORDER BY"));
> {code}
> Note git history appears to refer mute in [commit
> 58e57fd|https://github.com/apache/ignite/commit/70eed75422ea50a7bb9dbe539e2b9a62458e57fd].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10184) Missed TODO: IGNITE-5380 uncomment after fix
Ryabov Dmitrii created IGNITE-10184:
---
Summary: Missed TODO: IGNITE-5380 uncomment after fix
Key: IGNITE-10184
URL: https://issues.apache.org/jira/browse/IGNITE-10184
Project: Ignite
Issue Type: Test
Reporter: Ryabov Dmitrii
Ticket is resolved, so test
{{SqlSchemaSelfTest._testTypeConflictInPublicSchema}} should be renamed (remove
"_") and fixed - this test should check that second cache creation throws
exception about conflict in the schema.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10187) Partition data can be lost after recover from WAL and no data were ever checkpointed.
Andrew Mashenkov created IGNITE-10187: - Summary: Partition data can be lost after recover from WAL and no data were ever checkpointed. Key: IGNITE-10187 URL: https://issues.apache.org/jira/browse/IGNITE-10187 Project: Ignite Issue Type: Bug Components: persistence Reporter: Andrew Mashenkov Steps to reproduce: 1. Start a node. 2. Disable checkpoints. 3. Put some data. 4. Flush WAL. 5. Restart node. 6. Next put hangs sporadically forever awaiting for next topology that will never happens. The issue caused by ClusterTopologyException thrown due to partition MOVING state, however it is expected partition to be in OWNING state. The root cause is partition doesn't restore OWNING state after recover from WAL as it was not checkpointed or contains no data when checkpoint occurs (partition was in initial state). Seems, forcing checkpoint before disabling it resolves the issue. See CacheMvccTxFailoverTest.testSingleNodeTxMissedCommitNoCheckpoint(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10190) [TC Bot] Failed tests don't count as blockers if they were created in the PR
Ryabov Dmitrii created IGNITE-10190: --- Summary: [TC Bot] Failed tests don't count as blockers if they were created in the PR Key: IGNITE-10190 URL: https://issues.apache.org/jira/browse/IGNITE-10190 Project: Ignite Issue Type: Bug Reporter: Ryabov Dmitrii Assignee: Ryabov Dmitrii Failed tests don't count as blockers if they were created in the PR. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8871) TDE - Phase-1. Documentation
[ https://issues.apache.org/jira/browse/IGNITE-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov reassigned IGNITE-8871: -- Assignee: Artem Budnikov (was: Nikolay Izhikov) > TDE - Phase-1. Documentation > > > Key: IGNITE-8871 > URL: https://issues.apache.org/jira/browse/IGNITE-8871 > Project: Ignite > Issue Type: Sub-task > Components: documentation >Affects Versions: 2.5 >Reporter: Nikolay Izhikov >Assignee: Artem Budnikov >Priority: Major > Labels: documentation > Fix For: 2.7 > > > TDE feature should be documented. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10195) Cannot create caches with different names but with same indexed types and schema name
[
https://issues.apache.org/jira/browse/IGNITE-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Platonov updated IGNITE-10195:
-
Description:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{code:java}
node.createCache(new CacheConfiguration()
.setName("PERSON_1")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
node.createCache(new CacheConfiguration()
.setName("PERSON_2")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
{code}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation @QuerySqlField(index =
true)). Here is definition of Person class:
{code:java}
public static class PersonKey {
@QuerySqlField
public long id;
/**
* Constructor.
*
* @param id ID.
*/
PersonKey(long id) {
this.id = id;
}
/** {@inheritDoc} */
Override public int hashCode() {
return (int)id;
}
/** {@inheritDoc} */
@Override public boolean equals(Object obj) {
return obj != null && obj instanceof PersonKey && (F.eq(id,
((PersonKey)obj).id));
}
}{code}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values?
was:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{code:java}
node.createCache(new CacheConfiguration()
.setName("PERSON_1")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
node.createCache(new CacheConfiguration()
.setName("PERSON_2")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
{code}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation @QuerySqlField(index =
true)). Here is definition of Person class:
{code:java}
public static class PersonKey {
@QuerySqlField
public long id;
/**
* Constructor.
*
* @param id ID.
*/
PersonKey(long id) {
this.id = id;
}
/** {@inheritDoc} */
@Override public int hashCode() {
return (int)id;
}
/** {@inheritDoc} */
@Override public boolean equals(Object obj) {
return obj != null && obj instanceof PersonKey && (F.eq(id,
((PersonKey)obj).id));
}
}{code}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values?
> Cannot create caches with different names but with same indexed types and
> schema name
> -
>
> Key: IGNITE-10195
> URL: https://issues.apache.org/jira/browse/IGNITE-10195
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Platonov
>Priority: Major
>
> Cannot create caches with different names but with same indexed types and
> schema name. For example, such code will throw exception
> "javax.cache.CacheException: Table already exists: PERSON".
>
> {code:java}
> node.createCache(new CacheConfiguration()
> .setName("PERSON_1")
> .setIndexedTypes(Key.class, Person.class)
> .setSqlSchema(QueryUtils.DFLT_SCHEMA));
> node.createCache(new CacheConfiguration()
> .setName("PERSON_2")
> .setIndexedTypes(Key.class, Person.class)
> .setSqlSchema(QueryUtils.DFLT_SCHEMA));
> {code}
>
> If I set table name manually by setQueryEntities(...) then
> "javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
> thrown (Value has field with "origId" and annotation @QuerySqlField(index =
> true)). Here is definition of Person class:
>
> {code:java}
> public static class PersonKey {
> @QuerySqlField
> public long id;
> /**
> * Constructor.
> *
> * @param id ID.
> */
> PersonKey(long id) {
> this.id = id;
> }
> /** {@inheritDoc} */
> Override public int hashCode() {
> return (int)id;
> }
> /** {@inheritDoc} */
> @Override public boolean equals(Object obj) {
> return obj != null && obj instanceof PersonKey && (F.eq(id,
> ((PersonKey)obj).id));
> }
> }{code}
> Such behavior seems to be usability bug. Why I cannot create two caches with
> different names but with same indexed values?
--
This message was sent by Atlassian JIRA
(v7.6.3#
[jira] [Updated] (IGNITE-10182) Generalize GridInternalSubscriptionProcessor.
[ https://issues.apache.org/jira/browse/IGNITE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10182: -- Labels: refactoring (was: ) > Generalize GridInternalSubscriptionProcessor. > - > > Key: IGNITE-10182 > URL: https://issues.apache.org/jira/browse/IGNITE-10182 > Project: Ignite > Issue Type: Improvement >Reporter: Andrew Mashenkov >Priority: Minor > Labels: refactoring > > For now GridInternalSubscriptionProcessor allows 2 hardcoded types of > subscribers. > Let's avoid hardcoded types usage. > Suggest to introduce marker interface InternalSubscriber, and export only > next processor methods. > Register new subscriber: > registerSubscriber(InternalSubscriber) > Notify all subscribers of given type with applying some closure: > nofitySubscribers(Class, Closure) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9996) Investigate possible performance drop in FSYNC mode for ignite-2.7 compared to ignite-2.6
[ https://issues.apache.org/jira/browse/IGNITE-9996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Suntsov updated IGNITE-9996: - Attachment: Screen Shot 2018-11-08 at 2.38.06 PM.png > Investigate possible performance drop in FSYNC mode for ignite-2.7 compared > to ignite-2.6 > - > > Key: IGNITE-9996 > URL: https://issues.apache.org/jira/browse/IGNITE-9996 > Project: Ignite > Issue Type: Task >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.7 > > Attachments: Screen Shot 2018-10-29 at 3.30.51 PM.png, Screen Shot > 2018-10-31 at 10.30.26 AM.png, Screen Shot 2018-11-08 at 2.38.06 PM.png > > > As per the latest reports we probably have a performance drop around 5-8% on > write benchmarks in FSYNC mode. The cause needs to be investigated and fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10191) Incorrect comparison of lists in RendezvousAffinityFunctionSimpleBenchmark#testAffinityCompatibility
Oleg Ignatenko created IGNITE-10191:
---
Summary: Incorrect comparison of lists in
RendezvousAffinityFunctionSimpleBenchmark#testAffinityCompatibility
Key: IGNITE-10191
URL: https://issues.apache.org/jira/browse/IGNITE-10191
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Oleg Ignatenko
RendezvousAffinityFunctionSimpleBenchmark#testAffinityCompatibility (in current
codebase muted by renaming to {{_testAffinityCompatibility}}) looks
troublesome: apparent bug is incorrect comparison of lists expecting elements
to be always in the same order which doesn't look like the case for the tested
API:
{code}List> assignment0 = assignPartitions(aff0,
nodes, null, backups, 0).get2();
List> assignment1 = assignPartitions(aff1,
nodes, null, backups, 0).get2();
assertEquals (assignment0, assignment1);
{code}
Though test kept failing even after I experimented with replacing comparison to
one that was insensitive to the order of list elements.
Brief checking of code intended to be tested suggests that maybe it isn't even
supposed to be deterministic - in case if this is correct test should be very
thoroughly redesigned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10195) Cannot create caches with different names but with same indexed types and schema name
[
https://issues.apache.org/jira/browse/IGNITE-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Platonov updated IGNITE-10195:
-
Description:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{code:java}
node.createCache(new CacheConfiguration()
.setName("PERSON_1")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
node.createCache(new CacheConfiguration()
.setName("PERSON_2")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
{code}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation @QuerySqlField(index =
true)). Here is definition of Person class:
{code:java}
public static class PersonKey {
@QuerySqlField
public long id;
/**
* Constructor.
*
* @param id ID.
*/
PersonKey(long id) {
this.id = id;
}
/** {@inheritDoc} */
@Override public int hashCode() {
return (int)id;
}
/** {@inheritDoc} */
@Override public boolean equals(Object obj) {
return obj != null && obj instanceof PersonKey && (F.eq(id,
((PersonKey)obj).id));
}
}{code}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values?
was:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{code:java}
node.createCache(new CacheConfiguration()
.setName("PERSON_1")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
node.createCache(new CacheConfiguration()
.setName("PERSON_2")
.setIndexedTypes(Key.class, Person.class)
.setSqlSchema(QueryUtils.DFLT_SCHEMA));
{code}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation @QuerySqlField(index =
true)). Here is definition of Person class:
{code:java}
public static class PersonKey {
@QuerySqlField public long id; /** * Constructor. * * @param id ID. */
PersonKey(long id) {
this.id = id; }
/** {@inheritDoc{color:#629755}} */
@Override public int hashCode() {
return (int)id; }
/** {@inheritDoc{color:#629755}} */
@Override public boolean equals(Object obj) {
return obj != null && obj instanceof PersonKey && (F.eq(id,
((PersonKey)obj).id)); }
}{code}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values?
> Cannot create caches with different names but with same indexed types and
> schema name
> -
>
> Key: IGNITE-10195
> URL: https://issues.apache.org/jira/browse/IGNITE-10195
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Platonov
>Priority: Major
>
> Cannot create caches with different names but with same indexed types and
> schema name. For example, such code will throw exception
> "javax.cache.CacheException: Table already exists: PERSON".
>
> {code:java}
> node.createCache(new CacheConfiguration()
> .setName("PERSON_1")
> .setIndexedTypes(Key.class, Person.class)
> .setSqlSchema(QueryUtils.DFLT_SCHEMA));
> node.createCache(new CacheConfiguration()
> .setName("PERSON_2")
> .setIndexedTypes(Key.class, Person.class)
> .setSqlSchema(QueryUtils.DFLT_SCHEMA));
> {code}
>
> If I set table name manually by setQueryEntities(...) then
> "javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
> thrown (Value has field with "origId" and annotation @QuerySqlField(index =
> true)). Here is definition of Person class:
>
> {code:java}
> public static class PersonKey {
> @QuerySqlField
> public long id;
> /**
> * Constructor.
> *
> * @param id ID.
> */
> PersonKey(long id) {
> this.id = id;
> }
> /** {@inheritDoc} */
> @Override public int hashCode() {
> return (int)id;
> }
> /** {@inheritDoc} */
> @Override public boolean equals(Object obj) {
> return obj != null && obj instanceof PersonKey && (F.eq(id,
> ((PersonKey)obj).id));
> }
> }{code}
> Such behavior seems to be usability bug. Why I cannot create two caches with
> different names but with same indexed values?
--
This message was sent by A
[jira] [Updated] (IGNITE-10195) Cannot create caches with different names but with same indexed types and schema name
[
https://issues.apache.org/jira/browse/IGNITE-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Platonov updated IGNITE-10195:
-
Description:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: PERSON".
{color:#9876aa}node{color}.createCache({color:#cc7832}new
{color}CacheConfiguration()
.setName({color:#9876aa}"PERSON_1"{color})
.setIndexedTypes(Key.{color:#cc7832}class,{color}
Person.{color:#cc7832}class{color})
.setSqlSchema(QueryUtils.{color:#9876aa}DFLT_SCHEMA{color})){color:#cc7832};{color}{color:#9876aa}node{color}.createCache({color:#cc7832}new
{color}CacheConfiguration()
.setName({color:#9876aa}"PERSON_2"{color})
.setIndexedTypes({color:#cc7832}Key.class, Person.class{color})
.setSqlSchema(QueryUtils.{color:#9876aa}DFLT_SCHEMA{color})){color:#cc7832};{color}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation
{color:#bbb529}@QuerySqlField{color}({color:#d0d0ff}index {color}=
{color:#cc7832}true{color})). Here is definition of Person class:
{color:#cc7832}public static class {color}PersonKey {
{color:#bbb529}@QuerySqlField{color} {color:#cc7832}public long
{color}{color:#9876aa}id{color}{color:#cc7832};{color}
{color:#629755}/**{color}{color:#629755} * Constructor.{color}{color:#629755}
*{color}{color:#629755} * {color}{color:#629755}@param {color}{color:#8a653b}id
{color}{color:#629755}ID.{color}{color:#629755} */{color}
{color:#ffc66d}PersonKey{color}({color:#cc7832}long {color}id) {
{color:#cc7832}this{color}.{color:#9876aa}id {color}=
id{color:#cc7832};{color} }
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public int {color}{color:#ffc66d}hashCode{color}() {
{color:#cc7832}return
{color}({color:#cc7832}int{color}){color:#9876aa}id{color}{color:#cc7832};{color}
}
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
@Override {color:#cc7832}public boolean
{color}{color:#ffc66d}equals{color}(Object obj) {
{color:#cc7832}return {color}obj != {color:#cc7832}null {color}&& obj
{color:#cc7832}instanceof {color}PersonKey &&
(F.eq({color:#9876aa}id{color}{color:#cc7832},
{color}((PersonKey)obj).{color:#9876aa}id{color})){color:#cc7832};{color} }
}
Such behavior seems to be usability bug. Why I cannot create two caches with
different names but with same indexed values.
was:
Cannot create caches with different names but with same indexed types and
schema name. For example, such code will throw exception
"javax.cache.CacheException: Table already exists: VALUE".
{color:#9876aa}node{color}.createCache({color:#cc7832}new
{color}CacheConfiguration()
.setName({color:#9876aa}"PERSON_1"{color})
.setIndexedTypes(Key.{color:#cc7832}class,{color}
Person.{color:#cc7832}class{color})
.setSqlSchema(QueryUtils.{color:#9876aa}DFLT_SCHEMA{color})){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#9876aa}node{color}.createCache({color:#cc7832}new
{color}CacheConfiguration()
.setName({color:#9876aa}"PERSON_2"{color})
.setIndexedTypes({color:#cc7832}Key.class, Person.class{color})
.setSqlSchema(QueryUtils.{color:#9876aa}DFLT_SCHEMA{color})){color:#cc7832};{color}
If I set table name manually by setQueryEntities(...) then
"javax.cache.CacheException: Index already exists: PERSON_ORGID_IDX" wil be
thrown (Value has field with "origId" and annotation
{color:#bbb529}@QuerySqlField{color}({color:#d0d0ff}index {color}=
{color:#cc7832}true{color})). Here is definition of Person class:
{color:#cc7832}public static class {color}PersonKey {
{color:#bbb529}@QuerySqlField
{color} {color:#cc7832}public long
{color}{color:#9876aa}id{color}{color:#cc7832};
{color}{color:#cc7832}
{color} {color:#629755}/**
{color}{color:#629755} * Constructor.
{color}{color:#629755} *
{color}{color:#629755} * {color}{color:#629755}@param {color}{color:#8a653b}id
{color}{color:#629755}ID.
{color}{color:#629755} */
{color} {color:#ffc66d}PersonKey{color}({color:#cc7832}long {color}id) {
{color:#cc7832}this{color}.{color:#9876aa}id {color}= id{color:#cc7832};
{color} }
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
{color} {color:#bbb529}@Override {color}{color:#cc7832}public int
{color}{color:#ffc66d}hashCode{color}() {
{color:#cc7832}return
{color}({color:#cc7832}int{color}){color:#9876aa}id{color}{color:#cc7832};
{color} }
{color:#629755}/** {{color}{color:#629755}@inheritDoc{color}{color:#629755}} */
{color} {color:#bbb529}@Override {color}{color:#cc7832}public boolean
{color}{color:#ffc66d}equals{color}(Object obj) {
{color:#cc7832}return {color}obj != {color:#cc7832}null {color}&& obj
{col
[jira] [Updated] (IGNITE-10183) [Test Failed] IgniteClientReconnectCacheTest.testReconnectOperationInProgress flaky fails on TC.
[
https://issues.apache.org/jira/browse/IGNITE-10183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-10183:
--
Ignite Flags: (was: Docs Required)
> [Test Failed] IgniteClientReconnectCacheTest.testReconnectOperationInProgress
> flaky fails on TC.
>
>
> Key: IGNITE-10183
> URL: https://issues.apache.org/jira/browse/IGNITE-10183
> Project: Ignite
> Issue Type: Bug
> Components: cache, mvcc
>Affects Versions: 2.7
>Reporter: Pavel Pereslegin
>Priority: Major
>
> IgniteClientReconnectCacheTest.testReconnectOperationInProgress fails
> sometimes in master.
> [Recent failures on
> TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=-1285534571845460301&order=TEST_STATUS_DESC&branch_IgniteTests24Java8=%3Cdefault%3E&itemsCount=50].
> Test fails only for cache with {{TRANSACTIONAL_SNAPSHOT}} atomicity mode.
> Typical output:
> {noformat}
> [2018-11-08 12:49:51,871][ERROR][main][root] Test failed.
> class org.apache.ignite.IgniteCheckedException: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 6643ab2f661--0920-e484--0010
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:261)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:191)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkOperationInProgressFails(IgniteClientReconnectCacheTest.java:1421)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectOperationInProgress(IgniteClientReconnectCacheTest.java:869)
> 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:2208)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.cache.CacheException: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 6643ab2f661--0920-e484--0010
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:834)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:832)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest$25.call(IgniteClientReconnectCacheTest.java:1406)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:1003)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1299)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
> Caused by: class org.apache.ignite.transactions.TransactionRollbackException:
> Transaction has been rolled back:
> 6643ab2f661--0920-e484--0010
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:922)
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:920)
> ... 10 more
> Caused by: class
> org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
> Transaction has been rolled back:
> 6643ab2f661--0920-e484--0010
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4282)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCac
[jira] [Assigned] (IGNITE-10196) Remove kafka-clients-*-test dependency
[ https://issues.apache.org/jira/browse/IGNITE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Pudov reassigned IGNITE-10196: Assignee: Maxim Pudov > Remove kafka-clients-*-test dependency > -- > > Key: IGNITE-10196 > URL: https://issues.apache.org/jira/browse/IGNITE-10196 > Project: Ignite > Issue Type: Bug > Components: build >Affects Versions: 2.7 >Reporter: Sergey Kozlov >Assignee: Maxim Pudov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10118) JDBC v2: metadata.getSchemas returns cache names instead of schema names
[
https://issues.apache.org/jira/browse/IGNITE-10118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679880#comment-16679880
]
Pavel Kuznetsov commented on IGNITE-10118:
--
In the same way as in IGNITE-9989 I got rid of distributed task that collects
metadata. Used ignite instance of JdbcConnection and iterated over
{{DynamicCacheDescriptor}}s to get schema names.
> JDBC v2: metadata.getSchemas returns cache names instead of schema names
>
>
> Key: IGNITE-10118
> URL: https://issues.apache.org/jira/browse/IGNITE-10118
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Affects Versions: 2.6
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
>
> jdbc v2 returns list of cache names instead of list of schemas.
> It is correct only if we have a cache and table created in it using cache API.
> If we create tables using ddl we expect to see "PUBLIC" schema name in
> results of {{connection.getMetadata().getSchemas()}} not
> "SQL_PUBLIC_TABLENAME"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10196) Remove kafka-clients-*-test dependency
Sergey Kozlov created IGNITE-10196: -- Summary: Remove kafka-clients-*-test dependency Key: IGNITE-10196 URL: https://issues.apache.org/jira/browse/IGNITE-10196 Project: Ignite Issue Type: Bug Components: build Affects Versions: 2.7 Reporter: Sergey Kozlov Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6600) Web Console: Make a design of 403 and 404 pages
[ https://issues.apache.org/jira/browse/IGNITE-6600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679557#comment-16679557 ] Alexander Kalinin commented on IGNITE-6600: --- [~pkonstantinov] Please test that redirection works on the last successful visited page. If user tries to go directly to 404 or 403 page redirection goes to default-state. > Web Console: Make a design of 403 and 404 pages > --- > > Key: IGNITE-6600 > URL: https://issues.apache.org/jira/browse/IGNITE-6600 > Project: Ignite > Issue Type: Task > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Alexander Kalinin >Priority: Minor > Attachments: 403-page.png, 404-page.png > > Original Estimate: 8h > Time Spent: 8h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10191) Incorrect comparison of lists in RendezvousAffinityFunctionSimpleBenchmark#testAffinityCompatibility
[
https://issues.apache.org/jira/browse/IGNITE-10191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10191:
Labels: MakeTeamcityGreenAgain (was: )
> Incorrect comparison of lists in
> RendezvousAffinityFunctionSimpleBenchmark#testAffinityCompatibility
>
>
> Key: IGNITE-10191
> URL: https://issues.apache.org/jira/browse/IGNITE-10191
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> RendezvousAffinityFunctionSimpleBenchmark#testAffinityCompatibility (in
> current codebase muted by renaming to {{_testAffinityCompatibility}}) looks
> troublesome: apparent bug is incorrect comparison of lists expecting elements
> to be always in the same order which doesn't look like the case for the
> tested API:
> {code}List> assignment0 =
> assignPartitions(aff0, nodes, null, backups, 0).get2();
> List> assignment1 =
> assignPartitions(aff1, nodes, null, backups, 0).get2();
> assertEquals (assignment0, assignment1);
> {code}
> Though test kept failing even after I experimented with replacing comparison
> to one that was insensitive to the order of list elements.
> Brief checking of code intended to be tested suggests that maybe it isn't
> even supposed to be deterministic - in case if this is correct test should be
> very thoroughly redesigned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10197) unexpected IllegalArgumentException in IgniteDbPutGetAbstractTest#testRandomPutGetRemove
[
https://issues.apache.org/jira/browse/IGNITE-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10197:
Ignite Flags: (was: Docs Required)
> unexpected IllegalArgumentException in
> IgniteDbPutGetAbstractTest#testRandomPutGetRemove
>
>
> Key: IGNITE-10197
> URL: https://issues.apache.org/jira/browse/IGNITE-10197
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteDbPutGetAbstractTest#testRandomPutGetRemove (in current codebase muted
> by renaming to {{_testRandomPutGetRemove}}) fails with IAE:
> {noformat}java.lang.IllegalArgumentException: Ouch! Argument is invalid:
> Cache name must not be null or empty.
> at
> org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.validateCacheName(GridCacheUtils.java:1600)
> at org.apache.ignite.internal.IgniteKernal.cache(IgniteKernal.java:2901)
> at
> org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.cache(IgniteDbPutGetAbstractTest.java:74)
> at
> org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.testRandomPutGetRemove(IgniteDbPutGetAbstractTest.java:814)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
> at java.lang.Thread.run(Thread.java:745){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10192) OptimizedMarshallerTest#testAllocationOverflow throws OOME instead of expected IOE
[
https://issues.apache.org/jira/browse/IGNITE-10192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10192:
Affects Version/s: 2.6
> OptimizedMarshallerTest#testAllocationOverflow throws OOME instead of
> expected IOE
> --
>
> Key: IGNITE-10192
> URL: https://issues.apache.org/jira/browse/IGNITE-10192
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> OptimizedMarshallerTest#_testAllocationOverflow (in current codebase muted by
> renaming to {{_testAllocationOverflow}}) throws OOME instead of expected IOE
> when trying to marshal {{HugeObject}} - which in turn writes 4 times {{new
> byte\[1 << 31 - 2]}}.
> Note test javadocs say: "WARNING! Requires a lot of heap space. Should not be
> run on CI."
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10106) Cache 5 test suite optimization
[
https://issues.apache.org/jira/browse/IGNITE-10106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679894#comment-16679894
]
Ignite TC Bot commented on IGNITE-10106:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries (Binary Objects Simple Mapper){color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2271181]]
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteSqlSplitterSelfTest.testReplicatedTablesUsingPartitionedCacheSegmentedClient
- 0,0% fails in last 100 master runs.
{color:#d04437}MVCC Queries{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=2271133]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccContinuousWithTransformerReplicatedSelfTest.testContinuousWithTransformerKeepBinaryAsync
- 0,0% fails in last 100 master runs.
{color:#d04437}Cache (Restarts) 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2271147]]
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2271189&buildTypeId=IgniteTests24Java8_RunAll]
> Cache 5 test suite optimization
> ---
>
> Key: IGNITE-10106
> URL: https://issues.apache.org/jira/browse/IGNITE-10106
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Platonov
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> We need to investigate how to optimize these tests:
> |CacheSerializableTransactionsTest.testGetRemoveTxNearCache2|
> |[CacheSerializableTransactionsTest.testGetRemoveTxNearCache1|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]|
> |CacheSerializableTransactionsTest.testRandomOperations|
> |[CacheSerializableTransactionsTest.testIncrementTxRestart|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]|
> |CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockNodeRestart|
> |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockFromClientsNodeRestart|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]|
> |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockWithNonSerializable|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]|
> |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockGetPut|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]|
> |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockFromClients|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]|
> |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlock|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]|
> and optimize them.
--
This
[jira] [Updated] (IGNITE-10198) test cases fail in TcpDiscoveryMultiThreadedTest: testCustomEventOnJoinCoordinatorStop and testClientContinuousQueryCoordinatorStop
[
https://issues.apache.org/jira/browse/IGNITE-10198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10198:
Ignite Flags: (was: Docs Required)
> test cases fail in TcpDiscoveryMultiThreadedTest:
> testCustomEventOnJoinCoordinatorStop and
> testClientContinuousQueryCoordinatorStop
> ---
>
> Key: IGNITE-10198
> URL: https://issues.apache.org/jira/browse/IGNITE-10198
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> * TcpDiscoveryMultiThreadedTest#testCustomEventOnJoinCoordinatorStop (in
> current codebase muted by renaming to
> {{_testCustomEventOnJoinCoordinatorStop}}) fails to start client cache:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to start client cache
> (a cache with the given name is not started): default
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:261)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:172)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runMultiThreadedAsync$96d302c5$1(GridTestUtils.java:856)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:395)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:349)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:337)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:507)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:486)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:1011)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1299)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
> Caused by: org.apache.ignite.cache.CacheExistsException: Failed to start
> client cache (a cache with the given name is not started): default
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5287)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$dynamicStartCache$20(GridCacheProcessor.java:3606)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3635)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3543)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.publicJCache(GridCacheProcessor.java:4680)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.publicJCache(GridCacheProcessor.java:4651)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:3313)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoveryMultiThreadedTest$7.call(TcpDiscoveryMultiThreadedTest.java:548)
> ... 1 more{noformat}
> * TcpDiscoveryMultiThreadedTest#testClientContinuousQueryCoordinatorStop (in
> current codebase muted by renaming to
> {{_testClientContinuousQueryCoordinatorStop}}) fails because client node
> disconnected: {noformat}
> class org.apache.ignite.IgniteCheckedException: Client node disconnected.
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:261)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:172)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runMultiThreadedAsync$96d302c5$1(GridTestUtils.java:856)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:395)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:349)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:337)
> at
> org.apache.ignite.internal.util.future.GridFut
[jira] [Updated] (IGNITE-10197) unexpected IllegalArgumentException in IgniteDbPutGetAbstractTest#testRandomPutGetRemove
[
https://issues.apache.org/jira/browse/IGNITE-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10197:
Description:
IgniteDbPutGetAbstractTest#testRandomPutGetRemove (in current codebase muted by
renaming to {{_testRandomPutGetRemove}}) fails with IAE:
{noformat}java.lang.IllegalArgumentException: Ouch! Argument is invalid: Cache
name must not be null or empty.
at
org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:109)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.validateCacheName(GridCacheUtils.java:1600)
at org.apache.ignite.internal.IgniteKernal.cache(IgniteKernal.java:2901)
at
org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.cache(IgniteDbPutGetAbstractTest.java:74)
at
org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.testRandomPutGetRemove(IgniteDbPutGetAbstractTest.java:814)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
at java.lang.Thread.run(Thread.java:745){noformat}
Note a while ago this test was muted by adding underscore prefix to its name
per [commit
2e343b6|https://github.com/apache/ignite/commit/4282d802f16188cdea05d6b2d2c0f3c222e343b6]
was:
IgniteDbPutGetAbstractTest#testRandomPutGetRemove (in current codebase muted by
renaming to {{_testRandomPutGetRemove}}) fails with IAE:
{noformat}java.lang.IllegalArgumentException: Ouch! Argument is invalid: Cache
name must not be null or empty.
at
org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:109)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.validateCacheName(GridCacheUtils.java:1600)
at org.apache.ignite.internal.IgniteKernal.cache(IgniteKernal.java:2901)
at
org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.cache(IgniteDbPutGetAbstractTest.java:74)
at
org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.testRandomPutGetRemove(IgniteDbPutGetAbstractTest.java:814)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
at java.lang.Thread.run(Thread.java:745){noformat}
> unexpected IllegalArgumentException in
> IgniteDbPutGetAbstractTest#testRandomPutGetRemove
>
>
> Key: IGNITE-10197
> URL: https://issues.apache.org/jira/browse/IGNITE-10197
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteDbPutGetAbstractTest#testRandomPutGetRemove (in current codebase muted
> by renaming to {{_testRandomPutGetRemove}}) fails with IAE:
> {noformat}java.lang.IllegalArgumentException: Ouch! Argument is invalid:
> Cache name must not be null or empty.
> at
> org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.validateCacheName(GridCacheUtils.java:1600)
> at org.apache.ignite.internal.IgniteKernal.cache(IgniteKernal.java:2901)
> at
> org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.cache(IgniteDbPutGetAbstractTest.java:74)
> at
> org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.testRandomPutGetRemove(IgniteDbPutGetAbstractTest.java:814)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.
[jira] [Assigned] (IGNITE-9840) Possible deadlock on transactional future on client node in case of network problems or long GC pauses
[
https://issues.apache.org/jira/browse/IGNITE-9840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Lantukh reassigned IGNITE-9840:
Assignee: Ilya Lantukh (was: Alexey Stelmak)
> Possible deadlock on transactional future on client node in case of network
> problems or long GC pauses
> --
>
> Key: IGNITE-9840
> URL: https://issues.apache.org/jira/browse/IGNITE-9840
> Project: Ignite
> Issue Type: Bug
> Components: clients
>Affects Versions: 2.6
>Reporter: Andrey Aleksandrov
>Assignee: Ilya Lantukh
>Priority: Critical
> Fix For: 2.8
>
>
> Steps to reproduce:
> 1)Start the server node with next timeouts. DefaultTxTimeout should be
> greater than other:
>
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> On the server side you should create a cache with next parameters:
>
>
> {code:java}
>
>
>
>
>
>
> {code}
> 2)After that start the client with the next code:
> {code:java}
> IgniteCache cache = ignite.getOrCreateCache("CACHE");
> try (Transaction tx = ignite.transactions().txStart()) {
> cache.put("Key", new Object());
> System.out.println("Stop me");
> //here we will get long GC pause on server side
> Thread.sleep(1);
> // Commit the transaction.
> tx.commitAsync().get();
> }
> {code}
>
> On step "Stop me" you should suspend all the thread on the server side to
> emulate the networking problem or long GC pause on the server side.
> Finally, you will face in client node next:
> {code:java}
> [2018-10-10 16:46:10,157][ERROR][nio-acceptor-tcp-comm-#28%GRIDC1%][root]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker
> [name=grid-timeout-worker, igniteInstanceName=GRIDC1, finished=false,
> heartbeatTs=1539179057570]]]
> {code}
> Also, the similar issue could be reproduced in 2.4. In both cases looks like
> we have a deadlock during trying to display the TxEntryValueHolder. Looks
> like this values are already used by the transaction with long
> DefaultTxTimeout .
> {code:java}
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata0(CacheObjectBinaryProcessorImpl.java:526)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:510)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:193)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1265)
> at org.apache.ignite.internal.binary.BinaryUtils.type(BinaryUtils.java:2407)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.rawType(BinaryObjectImpl.java:302)
> at
> org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:205)
> at
> org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:186)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.toString(BinaryObjectImpl.java:919)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.toString(TxEntryValueHolder.java:161)
> ...{code}
> On the client side, it could be looked like a hanging transaction because we
> waiting on:
> {code:java}
> tx.commitAsync().get();{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10187) Partition data can be lost after recover from WAL and no data were ever checkpointed.
[ https://issues.apache.org/jira/browse/IGNITE-10187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10187: -- Ignite Flags: (was: Docs Required) > Partition data can be lost after recover from WAL and no data were ever > checkpointed. > - > > Key: IGNITE-10187 > URL: https://issues.apache.org/jira/browse/IGNITE-10187 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Andrew Mashenkov >Priority: Major > > Steps to reproduce: > 1. Start a node. > 2. Disable checkpoints. > 3. Put some data. > 4. Flush WAL. > 5. Restart node. > 6. Next put hangs sporadically forever awaiting for next topology that will > never happens. > The issue caused by ClusterTopologyException thrown due to partition MOVING > state, however it is expected partition to be in OWNING state. > The root cause is partition doesn't restore OWNING state after recover from > WAL as it was not checkpointed or contains no data when checkpoint occurs > (partition was in initial state). > > Seems, forcing checkpoint before disabling it resolves the issue. See > CacheMvccTxFailoverTest.testSingleNodeTxMissedCommitNoCheckpoint(). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8469) Non-heap memory leak for calling cluster activation multi times
[
https://issues.apache.org/jira/browse/IGNITE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679644#comment-16679644
]
Maxim Muzafarov commented on IGNITE-8469:
-
[~mshonichev]
If you are checking the 2.7 release branch it seems to me that it's not
possible to run a different cluster on the same PDS files (don't know if this
correct). This is was my case.
> Non-heap memory leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.7
>
>
> Calling multiple time cluster (with enabled persistence and started client
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory
> leak.
> Line
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}}
> looks suspicious because of in case method
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}}
> callled multi times (e.g. activate(true) called multi times) we lost info
> about allocated regions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10197) unexpected IllegalArgumentException in IgniteDbPutGetAbstractTest#testRandomPutGetRemove
Oleg Ignatenko created IGNITE-10197:
---
Summary: unexpected IllegalArgumentException in
IgniteDbPutGetAbstractTest#testRandomPutGetRemove
Key: IGNITE-10197
URL: https://issues.apache.org/jira/browse/IGNITE-10197
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Oleg Ignatenko
IgniteDbPutGetAbstractTest#testRandomPutGetRemove (in current codebase muted by
renaming to {{_testRandomPutGetRemove}}) fails with IAE:
{noformat}java.lang.IllegalArgumentException: Ouch! Argument is invalid: Cache
name must not be null or empty.
at
org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:109)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.validateCacheName(GridCacheUtils.java:1600)
at org.apache.ignite.internal.IgniteKernal.cache(IgniteKernal.java:2901)
at
org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.cache(IgniteDbPutGetAbstractTest.java:74)
at
org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.testRandomPutGetRemove(IgniteDbPutGetAbstractTest.java:814)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
at java.lang.Thread.run(Thread.java:745){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-7861) Web console: invalid column on Activity details modal
[ https://issues.apache.org/jira/browse/IGNITE-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov resolved IGNITE-7861. Resolution: Fixed > Web console: invalid column on Activity details modal > - > > Key: IGNITE-7861 > URL: https://issues.apache.org/jira/browse/IGNITE-7861 > Project: Ignite > Issue Type: Bug >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: Selection_094.png, screenshot-1.png, screenshot-2.png > > > Many items do not have right description -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9840) Possible deadlock on transactional future on client node in case of network problems or long GC pauses
[
https://issues.apache.org/jira/browse/IGNITE-9840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-9840:
-
Ignite Flags: (was: Docs Required)
> Possible deadlock on transactional future on client node in case of network
> problems or long GC pauses
> --
>
> Key: IGNITE-9840
> URL: https://issues.apache.org/jira/browse/IGNITE-9840
> Project: Ignite
> Issue Type: Bug
> Components: clients
>Affects Versions: 2.6
>Reporter: Andrey Aleksandrov
>Assignee: Ilya Lantukh
>Priority: Critical
> Fix For: 2.8
>
>
> Steps to reproduce:
> 1)Start the server node with next timeouts. DefaultTxTimeout should be
> greater than other:
>
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> On the server side you should create a cache with next parameters:
>
>
> {code:java}
>
>
>
>
>
>
> {code}
> 2)After that start the client with the next code:
> {code:java}
> IgniteCache cache = ignite.getOrCreateCache("CACHE");
> try (Transaction tx = ignite.transactions().txStart()) {
> cache.put("Key", new Object());
> System.out.println("Stop me");
> //here we will get long GC pause on server side
> Thread.sleep(1);
> // Commit the transaction.
> tx.commitAsync().get();
> }
> {code}
>
> On step "Stop me" you should suspend all the thread on the server side to
> emulate the networking problem or long GC pause on the server side.
> Finally, you will face in client node next:
> {code:java}
> [2018-10-10 16:46:10,157][ERROR][nio-acceptor-tcp-comm-#28%GRIDC1%][root]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker
> [name=grid-timeout-worker, igniteInstanceName=GRIDC1, finished=false,
> heartbeatTs=1539179057570]]]
> {code}
> Also, the similar issue could be reproduced in 2.4. In both cases looks like
> we have a deadlock during trying to display the TxEntryValueHolder. Looks
> like this values are already used by the transaction with long
> DefaultTxTimeout .
> {code:java}
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata0(CacheObjectBinaryProcessorImpl.java:526)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:510)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:193)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1265)
> at org.apache.ignite.internal.binary.BinaryUtils.type(BinaryUtils.java:2407)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.rawType(BinaryObjectImpl.java:302)
> at
> org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:205)
> at
> org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:186)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.toString(BinaryObjectImpl.java:919)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.toString(TxEntryValueHolder.java:161)
> ...{code}
> On the client side, it could be looked like a hanging transaction because we
> waiting on:
> {code:java}
> tx.commitAsync().get();{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10183) [Test Failed] IgniteClientReconnectCacheTest.testReconnectOperationInProgress flaky fails on TC.
[
https://issues.apache.org/jira/browse/IGNITE-10183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-10183:
--
Description:
IgniteClientReconnectCacheTest.testReconnectOperationInProgress fails sometimes
in master (see [recent failures on
TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=-1285534571845460301&order=TEST_STATUS_DESC&branch_IgniteTests24Java8=%3Cdefault%3E&itemsCount=50]).
Test fails only for cache with {{TRANSACTIONAL_SNAPSHOT}} atomicity mode.
Typical output:
{noformat}
[2018-11-08 12:49:51,871][ERROR][main][root] Test failed.
class org.apache.ignite.IgniteCheckedException: class
org.apache.ignite.transactions.TransactionRollbackException: Transaction has
been rolled back: 6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:261)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:191)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkOperationInProgressFails(IgniteClientReconnectCacheTest.java:1421)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectOperationInProgress(IgniteClientReconnectCacheTest.java:869)
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:2208)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.cache.CacheException: class
org.apache.ignite.transactions.TransactionRollbackException: Transaction has
been rolled back: 6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:834)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:832)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest$25.call(IgniteClientReconnectCacheTest.java:1406)
at
org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:1003)
at
org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1299)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
Caused by: class org.apache.ignite.transactions.TransactionRollbackException:
Transaction has been rolled back:
6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:922)
at
org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:920)
... 10 more
Caused by: class
org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
Transaction has been rolled back:
6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4282)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2503)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2484)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2461)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1105)
... 7 more
Caused by: class org.apache.ignite.IgniteCheckedException: Cannot serialize
transaction due to write conflict (transaction is marked for rollback)
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
at
org.
[jira] [Created] (IGNITE-10199) unexpected result from QueryCursor.getAll() in IgniteSqlSplitterSelfTest#testMergeJoin
Oleg Ignatenko created IGNITE-10199:
---
Summary: unexpected result from QueryCursor.getAll() in
IgniteSqlSplitterSelfTest#testMergeJoin
Key: IGNITE-10199
URL: https://issues.apache.org/jira/browse/IGNITE-10199
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Oleg Ignatenko
IgniteSqlSplitterSelfTest#testMergeJoin (in current codebase muted by renaming
to {{_testMergeJoin}}) fails with message:
{noformat}
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at
org.apache.ignite.internal.processors.query.IgniteSqlSplitterSelfTest.testMergeJoin(IgniteSqlSplitterSelfTest.java:182)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Test code referred by above message is last assert in below snippet: {code}
String qry = "select o1.* from Org o1, " +
"(select max(o.name) as name, o.id from Org o group by o.id) o2
" +
"where o1.id = o2.id";
List> plan = c.query(new SqlFieldsQuery("explain " + qry)
.setEnforceJoinOrder(true)).getAll();
X.println("Plan: " + plan);
String map0 = (String)plan.get(0).get(0);
String map1 = (String)plan.get(1).get(0);
String rdc = (String)plan.get(2).get(0);
assertTrue(map0.contains("ORDER BY"));
assertTrue(map1.contains("ORDER BY"));
{code}
Note git history appears to refer mute in [commit
58e57fd|https://github.com/apache/ignite/commit/70eed75422ea50a7bb9dbe539e2b9a62458e57fd].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10183) [Test Failed] IgniteClientReconnectCacheTest.testReconnectOperationInProgress flaky fails on TC.
[
https://issues.apache.org/jira/browse/IGNITE-10183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-10183:
--
Description:
IgniteClientReconnectCacheTest.testReconnectOperationInProgress fails sometimes
in master (see [recent failures on
TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=-1285534571845460301&order=TEST_STATUS_DESC&branch_IgniteTests24Java8=%3Cdefault%3E&itemsCount=50]).
Test fails only for cache with {{TRANSACTIONAL_SNAPSHOT}} atomicity mode.
Typical output:
{noformat}
[2018-11-08 12:49:51,871][ERROR][main][root] Test failed.
class org.apache.ignite.IgniteCheckedException: class
org.apache.ignite.transactions.TransactionRollbackException: Transaction has
been rolled back: 6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:261)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:191)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkOperationInProgressFails(IgniteClientReconnectCacheTest.java:1421)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectOperationInProgress(IgniteClientReconnectCacheTest.java:869)
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:2208)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.cache.CacheException: class
org.apache.ignite.transactions.TransactionRollbackException: Transaction has
been rolled back: 6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:834)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:832)
at
org.apache.ignite.internal.IgniteClientReconnectCacheTest$25.call(IgniteClientReconnectCacheTest.java:1406)
at
org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:1003)
at
org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1299)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
Caused by: class org.apache.ignite.transactions.TransactionRollbackException:
Transaction has been rolled back:
6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:922)
at
org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:920)
... 10 more
Caused by: class
org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
Transaction has been rolled back:
6643ab2f661--0920-e484--0010
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4282)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2503)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2484)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2461)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1105)
... 7 more
Caused by: class org.apache.ignite.IgniteCheckedException: Cannot serialize
transaction due to write conflict (transaction is marked for rollback)
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
at
org.
[jira] [Updated] (IGNITE-10197) unexpected IllegalArgumentException in IgniteDbPutGetAbstractTest#testRandomPutGetRemove
[
https://issues.apache.org/jira/browse/IGNITE-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10197:
Labels: MakeTeamcityGreenAgain (was: )
> unexpected IllegalArgumentException in
> IgniteDbPutGetAbstractTest#testRandomPutGetRemove
>
>
> Key: IGNITE-10197
> URL: https://issues.apache.org/jira/browse/IGNITE-10197
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteDbPutGetAbstractTest#testRandomPutGetRemove (in current codebase muted
> by renaming to {{_testRandomPutGetRemove}}) fails with IAE:
> {noformat}java.lang.IllegalArgumentException: Ouch! Argument is invalid:
> Cache name must not be null or empty.
> at
> org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.validateCacheName(GridCacheUtils.java:1600)
> at org.apache.ignite.internal.IgniteKernal.cache(IgniteKernal.java:2901)
> at
> org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.cache(IgniteDbPutGetAbstractTest.java:74)
> at
> org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.testRandomPutGetRemove(IgniteDbPutGetAbstractTest.java:814)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
> at java.lang.Thread.run(Thread.java:745){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10118) JDBC v2: metadata.getSchemas returns cache names instead of schema names
[
https://issues.apache.org/jira/browse/IGNITE-10118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov reassigned IGNITE-10118:
Assignee: Pavel Kuznetsov
[~tledkov-gridgain] , Could you please take a look at the patch?
> JDBC v2: metadata.getSchemas returns cache names instead of schema names
>
>
> Key: IGNITE-10118
> URL: https://issues.apache.org/jira/browse/IGNITE-10118
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Affects Versions: 2.6
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
>
> jdbc v2 returns list of cache names instead of list of schemas.
> It is correct only if we have a cache and table created in it using cache API.
> If we create tables using ddl we expect to see "PUBLIC" schema name in
> results of {{connection.getMetadata().getSchemas()}} not
> "SQL_PUBLIC_TABLENAME"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10171) Running queries descriptor (GridRunningQueryInfo) contains generated SQL text instead of original SQL text
[
https://issues.apache.org/jira/browse/IGNITE-10171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679717#comment-16679717
]
Ignite TC Bot commented on IGNITE-10171:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 2{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2270753]]
* IgniteBinaryCacheQueryTestSuite2:
IgniteCacheQueryMultiThreadedSelfTest.testMultiThreadedSqlFieldsQuery - 0,0%
fails in last 100 master runs.
{color:#d04437}MVCC Queries{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2270777]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccContinuousWithTransformerClientSelfTest.testContinuousWithTransformerAndRegularListenerAsync
- 0,0% fails in last 100 master runs.
{color:#d04437}Cache 3{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2270796]]
* IgniteBinaryObjectsCacheTestSuite3:
IgniteCacheGroupsTest.testEntriesTtlAtomicPartitioned - 0,0% fails in last 100
master runs.
{color:#d04437}Cache 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2270795]]
* IgniteCacheTestSuite2: GridNearCacheStoreUpdateTest.testAtomicUpdateNear -
0,0% fails in last 100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2270833&buildTypeId=IgniteTests24Java8_RunAll]
> Running queries descriptor (GridRunningQueryInfo) contains generated SQL text
> instead of original SQL text
> --
>
> Key: IGNITE-10171
> URL: https://issues.apache.org/jira/browse/IGNITE-10171
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.8
>
>
> Running queries descriptors ({{GridRunningQueryInfo}}) for SQL queries
> received by {{GridQueryProcessor#runningQueries()}} method contains SQL text
> generated from parsed query structure. For diagnostic purposes it's better to
> store original SQL query text instaed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10181) [Tc Bot] Add fail-rate handling for test's page
PetrovMikhail created IGNITE-10181: -- Summary: [Tc Bot] Add fail-rate handling for test's page Key: IGNITE-10181 URL: https://issues.apache.org/jira/browse/IGNITE-10181 Project: Ignite Issue Type: Task Reporter: PetrovMikhail Assignee: PetrovMikhail -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9590) MVCC: Cleanup old rows in the vacuum thread.
[ https://issues.apache.org/jira/browse/IGNITE-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9590: - Description: When updating writer thread should iterate over the set of the last versions in order to find an appropriate version for its MVCC snapshot. During this iteration it collects invisible to anybody versions (their xid_max version is less than cleanup). When all outdated versions found, writer thread cleanups these rows - removes it from indexes and from pagestore. It would be more efficient if writer thread does not cleanup old rows by itself, but rather delegate it to vacuum workers: instead of cleaning just put it to cleanup queue. in case of significant backpressure during active updates, when cleanup workers can't keep up with removing outdated rows and cleanup queue is too big, writer threads can cleanup this rows by itself to prevent memory and performance problems. Upd: Also we can acquire checkpointReadLock for a fix-sized batch of cleaning versions Vacuum.cleanup() rather than for every single remove or rather than removing all outdated version at once. See TxLog.removeUntil() method. was: When updating writer thread should iterate over the set of the last versions in order to find an appropriate version for its MVCC snapshot. During this iteration it collects invisible to anybody versions (their xid_max version is less than cleanup). When all outdated versions found, writer thread cleanups these rows - removes it from indexes and from pagestore. It would be more efficient if writer thread does not cleanup old rows by itself, but rather delegate it to vacuum workers: instead of cleaning just put it to cleanup queue. in case of significant backpressure during active updates, when cleanup workers can't keep up with removing outdated rows and cleanup queue is too big, writer threads can cleanup this rows by itself to prevent memory and performance problems. > MVCC: Cleanup old rows in the vacuum thread. > > > Key: IGNITE-9590 > URL: https://issues.apache.org/jira/browse/IGNITE-9590 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Roman Kondakov >Priority: Major > Labels: performance > > When updating writer thread should iterate over the set of the last versions > in order to find an appropriate version for its MVCC snapshot. During this > iteration it collects invisible to anybody versions (their xid_max version is > less than cleanup). When all outdated versions found, writer thread cleanups > these rows - removes it from indexes and from pagestore. > It would be more efficient if writer thread does not cleanup old rows by > itself, but rather delegate it to vacuum workers: instead of cleaning just > put it to cleanup queue. > in case of significant backpressure during active updates, when cleanup > workers can't keep up with removing outdated rows and cleanup queue is too > big, writer threads can cleanup this rows by itself to prevent memory and > performance problems. > Upd: Also we can acquire checkpointReadLock for a fix-sized batch of cleaning > versions Vacuum.cleanup() rather than for every single remove or rather than > removing all outdated version at once. See TxLog.removeUntil() method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10154) Critical worker liveness check configuration is non-trivial and inconsistent
[ https://issues.apache.org/jira/browse/IGNITE-10154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679636#comment-16679636 ] ASF GitHub Bot commented on IGNITE-10154: - GitHub user agura opened a pull request: https://github.com/apache/ignite/pull/5350 IGNITE-10154 FailureType.SYSTEM_WORKER_BLOCKED always must be in ignoredFailureTypes due to a backward compatibility … You can merge this pull request into a Git repository by running: $ git pull https://github.com/agura/incubator-ignite ignite-10154 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5350.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 #5350 commit a92afd10070cebca9c0c7acbe0ff53cd53b1644c Author: Andrey Gura Date: 2018-11-08T11:31:18Z IGNITE-10154 FailureType.SYSTEM_WORKER_BLOCKED always must be in ignoredFailureType due to a backward compatibility > Critical worker liveness check configuration is non-trivial and inconsistent > > > Key: IGNITE-10154 > URL: https://issues.apache.org/jira/browse/IGNITE-10154 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Artem Budnikov >Assignee: Andrey Gura >Priority: Major > Fix For: 2.7 > > > The way the critical thread liveness check is configured has a number of > usability issues. > 1) By default, the liveness check is disabled (i.e. if no failure handler is > specified in the configuration). However, if you specify any handler > (including the default one), liveness check gets enabled (which is something > the users may not want) unless you disable it explicitly. > 2) Users that use Ignite 2.6 with a configured failure handler will get this > check enabled after migrating to Ignite 2.7. > In the two cases above, the functionality changes in a non-trivial way. > Ideally, we need an option that enables this functionality explicitly. A > possible example would be to keep liveness check disabled until the user sets > the systemWorkerBlockedTimeout to a positive value. (Or the other way around: > enable liveness check by default until the user explicitly disables it). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
