[jira] [Updated] (IGNITE-9440) control.sh --wal delete do not delete files
[ https://issues.apache.org/jira/browse/IGNITE-9440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov updated IGNITE-9440: - Attachment: TC.png > control.sh --wal delete do not delete files > > > Key: IGNITE-9440 > URL: https://issues.apache.org/jira/browse/IGNITE-9440 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Attachments: TC.png > > > Do not delete the files by the utility on command "control.sh --wal delete". > Remain both checkpoints and wal in the archive. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9382) Node.js fails to process large payloads
[ https://issues.apache.org/jira/browse/IGNITE-9382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh updated IGNITE-9382: - Priority: Critical (was: Major) > Node.js fails to process large payloads > --- > > Key: IGNITE-9382 > URL: https://issues.apache.org/jira/browse/IGNITE-9382 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Roman Shtykh >Assignee: Toru Yabuki >Priority: Critical > > Looks like finalizing response is done too early. > This can be easily checked with an SQL _limit_ 1 and _limit 100_. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8197) ignite won't start with spring-boot 1.5.11 - h2 property NESTED_JOINS doesn't exist
[
https://issues.apache.org/jira/browse/IGNITE-8197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16598228#comment-16598228
]
Dima commented on IGNITE-8197:
--
This setting has been removed from H2
[https://github.com/h2database/h2database/issues/901]
> ignite won't start with spring-boot 1.5.11 - h2 property NESTED_JOINS doesn't
> exist
> ---
>
> Key: IGNITE-8197
> URL: https://issues.apache.org/jira/browse/IGNITE-8197
> Project: Ignite
> Issue Type: Bug
>Reporter: Scott Feldstein
>Priority: Major
> Attachments: spring-boot-ignite.zip
>
>
> I just upgraded to spring-boot 1.5.11 and am seeing the error below. I think
> this is an issue with the version of h2 associated with spring boot 1.5.11.
> In 1.5.10 the h2 version was 1.4.196 and with 1.5.11 it is 1.4.197. The
> NESTED_JOINS property comes from
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing, i assume it
> was deprecated but not sure. When I lock in my h2 version to 1.4.196 by
> overriding the spring-dependencies parent everything works fine
> {code:java}
> Caused by: org.h2.jdbc.JdbcSQLException: Unsupported connection setting
> "NESTED_JOINS" [90113-197]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.message.DbException.get(DbException.java:179)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.message.DbException.get(DbException.java:155)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.engine.ConnectionInfo.readSettingsFromURL(ConnectionInfo.java:268)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.engine.ConnectionInfo.(ConnectionInfo.java:76)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.jdbc.JdbcConnection.(JdbcConnection.java:103)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.Driver.connect(Driver.java:69) ~[h2-1.4.197.jar:1.4.197]
> at java.sql.DriverManager.getConnection(DriverManager.java:664) ~[?:1.8.0_131]
> at java.sql.DriverManager.getConnection(DriverManager.java:270) ~[?:1.8.0_131]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$1.initialValue(IgniteH2Indexing.java:317)
> ~[ignite-indexing-2.4.0.jar:2.4.0]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$1.initialValue(IgniteH2Indexing.java:288)
> ~[ignite-indexing-2.4.0.jar:2.4.0]
> at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:180) ~[?:1.8.0_131]
> at java.lang.ThreadLocal.get(ThreadLocal.java:170) ~[?:1.8.0_131]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$1.get(IgniteH2Indexing.java:290)
> ~[ignite-indexing-2.4.0.jar:2.4.0]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$1.get(IgniteH2Indexing.java:288)
> ~[ignite-indexing-2.4.0.jar:2.4.0]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:514)
> ~[ignite-indexing-2.4.0.jar:2.4.0]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeStatement(IgniteH2Indexing.java:582)
> ~[ignite-indexing-2.4.0.jar:2.4.0]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.createSchema(IgniteH2Indexing.java:551)
> ~[ignite-indexing-2.4.0.jar:2.4.0]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.registerCache(IgniteH2Indexing.java:2667)
> ~[ignite-indexing-2.4.0.jar:2.4.0]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1594)
> ~[ignite-core-2.4.0.jar:2.4.0]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:800)
> ~[ignite-core-2.4.0.jar:2.4.0]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:861)
> ~[ignite-core-2.4.0.jar:2.4.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1158)
> ~[ignite-core-2.4.0.jar:2.4.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1900)
> ~[ignite-core-2.4.0.jar:2.4.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1764)
> ~[ignite-core-2.4.0.jar:2.4.0]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:744)
> ~[ignite-core-2.4.0.jar:2.4.0]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:626)
> ~[ignite-core-2.4.0.jar:2.4.0]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
>
[jira] [Commented] (IGNITE-9440) control.sh --wal delete do not delete files
[ https://issues.apache.org/jira/browse/IGNITE-9440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16598128#comment-16598128 ] ASF GitHub Bot commented on IGNITE-9440: GitHub user a-polyakov opened a pull request: https://github.com/apache/ignite/pull/4656 IGNITE-9440 control.sh --wal delete do not delete files Do not delete the files by the utility on command "control.sh --wal delete". Remain both checkpoints and wal in the archive. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite IGNITE-9440 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4656.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 #4656 commit d7e976b1247c2efc0c35b8fb679130acf5602dfd Author: a-polyakov Date: 2018-08-31T02:18:42Z IGNITE-9440 control.sh --wal delete do not delete files Signed-off-by: a-polyakov > control.sh --wal delete do not delete files > > > Key: IGNITE-9440 > URL: https://issues.apache.org/jira/browse/IGNITE-9440 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > > Do not delete the files by the utility on command "control.sh --wal delete". > Remain both checkpoints and wal in the archive. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9440) control.sh --wal delete do not delete files
Alexand Polyakov created IGNITE-9440: Summary: control.sh --wal delete do not delete files Key: IGNITE-9440 URL: https://issues.apache.org/jira/browse/IGNITE-9440 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Alexand Polyakov Assignee: Alexand Polyakov Do not delete the files by the utility on command "control.sh --wal delete". Remain both checkpoints and wal in the archive. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8286) ScanQuery ignore setLocal with non local partition
[ https://issues.apache.org/jira/browse/IGNITE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16598094#comment-16598094 ] Roman Shtykh commented on IGNITE-8286: -- Hi [~ilantukh] Thanks for getting back to the issue, and please see my comment. > ScanQuery ignore setLocal with non local partition > -- > > Key: IGNITE-8286 > URL: https://issues.apache.org/jira/browse/IGNITE-8286 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Alexander Belyak >Assignee: Roman Shtykh >Priority: Major > Fix For: 2.7 > > > 1) Create partitioned cache on 2+ nodes cluster > 2) Select some partition N, local node should not be OWNER of partition N > 3) execute: cache.query(new ScanQuery<>().setLocal(true).setPartition(N)) > Expected result: > empty result (probaply with logging smth like "Trying to execute local query > with non local partition N") or even throw exception > Actual result: > executing (with ScanQueryFallbackClosableIterator) query on remote node. > Problem is that we execute local query on remote node. > Same behaviour can be achieved if we get empty node list from > GridCacheQueryAdapter.node() by any reasons, for example - if we run "local" > query from non data node from given cache (see > GridDiscoveryNamager.cacheAffinityNode(ClusterNode node, String cacheName) in > GridcacheQueryAdapter.executeScanQuery() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9116) .NET: LINQ: CacheConfiguration.SqlSchema is ignored
[
https://issues.apache.org/jira/browse/IGNITE-9116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597937#comment-16597937
]
ASF GitHub Bot commented on IGNITE-9116:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4642
> .NET: LINQ: CacheConfiguration.SqlSchema is ignored
> ---
>
> Key: IGNITE-9116
> URL: https://issues.apache.org/jira/browse/IGNITE-9116
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.5, 2.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.7
>
>
> {{CacheConfiguration.SqlSchema}} and {{CacheClientConfiguration.SqlSchema}}
> are ignored by LINQ provider, schema name is inferred only from cache name.
> See {{ExpressionWalker.GetTableNameWithSchema}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-9116) .NET: LINQ: CacheConfiguration.SqlSchema is ignored
[
https://issues.apache.org/jira/browse/IGNITE-9116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-9116.
Resolution: Fixed
Merged to master: {{2108b3b836d113d8996c1e558a1681e5ebf251c6}}.
> .NET: LINQ: CacheConfiguration.SqlSchema is ignored
> ---
>
> Key: IGNITE-9116
> URL: https://issues.apache.org/jira/browse/IGNITE-9116
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.5, 2.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.7
>
>
> {{CacheConfiguration.SqlSchema}} and {{CacheClientConfiguration.SqlSchema}}
> are ignored by LINQ provider, schema name is inferred only from cache name.
> See {{ExpressionWalker.GetTableNameWithSchema}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9396) ML Examples: can't run examples, not enough dependencies in pom.xml
[
https://issues.apache.org/jira/browse/IGNITE-9396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596190#comment-16596190
]
Oleg Ignatenko edited comment on IGNITE-9396 at 8/30/18 7:47 PM:
-
I think I managed to reproduce the problem on my machine using IntelliJ Idea
(Ultimate 2018.1).
For that, I first checked what is the documented way to build examples per
[README.txt|https://github.com/apache/ignite/blob/master/examples/README.txt]:
"to start running you simply need to import provided `pom.xml` file into your
favourite IDE." In order to reproduce clean start I removed everything that was
cashed in my local maven repo and invalidated Idea caches. After that I tried
to build and launch an example and got compile errors similar to reported here
(specific example tested was {{KMeansClusterizationExample}} but it probably
doesn't really matter).
To find out how this can be corrected I decided to re-check how we build
[examples at
Teamcity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Examples]
because this way has proven to be clean and reliably working. Checking build
settings at Teamcity it turned out that prior to building examples they run a
maven (install) build for the Ignite. I tried the same on my machine and after
I did the install build of Ignite as described in
[DEVNOTES.txt|https://github.com/apache/ignite/blob/master/DEVNOTES.txt]
examples successfully loaded and built in my IDE and started working as
expected.
So far it looks like root issue is that README instructions in examples are
somewhat incomplete, possibly these can be expanded as follows (text for adding
is in _italic_ font):
{quote}...to start running you simply need to import provided `pom.xml` file
into your favourite IDE.
_Note working with examples assumes that you have Ignite already installed. If
you use source bundle this means it has built as described in DEVNOTES.txt in
Ignite project root._
{quote}
[~dmagda] kindly agreed to discuss these matters on Thursday.
-
Follow-up: per discussion with Denis change suggested above is the wrong way to
address this issue. This is because readme file is intended for end users who
are expected to use release version and because of that would obtain necessary
dependencies straight from maven central. For these users proposed addition
would be superfluous and quite confusing.
Issue described in this ticket concerns only developers who use snapshot
dependencies and because of that can't rely on maven central repository. The
right way to instruct this category of users is to document it in a separate
file (similar to [DEVNOTES.txt in Ignite
root|https://github.com/apache/ignite/blob/master/DEVNOTES.txt]).
was (Author: oignatenko):
I think I managed to reproduce the problem on my machine using IntelliJ Idea
(Ultimate 2018.1).
For that, I first checked what is the documented way to build examples per
[README.txt|https://github.com/apache/ignite/blob/master/examples/README.txt]:
"to start running you simply need to import provided `pom.xml` file into your
favourite IDE." In order to reproduce clean start I removed everything that was
cashed in my local maven repo and invalidated Idea caches. After that I tried
to build and launch an example and got compile errors similar to reported here
(specific example tested was {{KMeansClusterizationExample}} but it probably
doesn't really matter).
To find out how this can be corrected I decided to re-check how we build
[examples at
Teamcity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Examples]
because this way has proven to be clean and reliably working. Checking build
settings at Teamcity it turned out that prior to building examples they run a
maven (install) build for the Ignite. I tried the same on my machine and after
I did the install build of Ignite as described in
[DEVNOTES.txt|https://github.com/apache/ignite/blob/master/DEVNOTES.txt]
examples successfully loaded and built in my IDE and started working as
expected.
So far it looks like root issue is that README instructions in examples are
somewhat incomplete, possibly these can be expanded as follows (text for adding
is in _italic_ font):
{quote}...to start running you simply need to import provided `pom.xml` file
into your favourite IDE.
_Note working with examples assumes that you have Ignite already installed. If
you use source bundle this means it has built as described in DEVNOTES.txt in
Ignite project root._{quote}
[~dmagda] kindly agreed to discuss these matters on Thursday.
> ML Examples: can't run examples, not enough dependencies in pom.xml
> ---
>
> Key: IGNITE-9396
> URL: https://issues.apache.org/jira/browse/IGNITE-9396
> Project: Ignite
>
[jira] [Assigned] (IGNITE-9438) StandaloneWalRecordsIterator file descriptors leak
[
https://issues.apache.org/jira/browse/IGNITE-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura reassigned IGNITE-9438:
---
Assignee: Sergey Antonov
> StandaloneWalRecordsIterator file descriptors leak
> --
>
> Key: IGNITE-9438
> URL: https://issues.apache.org/jira/browse/IGNITE-9438
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.7
>
>
> In {{StandaloneWalRecordsIterator#initReadHandle()}} method are opens file
> descriptor.
> {code:java}
> FileIO fileIO = fd.isCompressed() ? new UnzipFileIO(fd.file()) :
> ioFactory.create(fd.file());
> {code}
> It not used after attempt to read segment header and it don't closed.
> Second time same file descriptor are opens in super method
> {{AbstractWalRecordsIterator#initReadHandle()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9439) Grid hangs after cache start failure.
[ https://issues.apache.org/jira/browse/IGNITE-9439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9439: - Labels: Hanging (was: ) > Grid hangs after cache start failure. > - > > Key: IGNITE-9439 > URL: https://issues.apache.org/jira/browse/IGNITE-9439 > Project: Ignite > Issue Type: Bug > Components: general, mvcc >Affects Versions: 2.6 >Reporter: Andrew Mashenkov >Priority: Blocker > Fix For: 2.7 > > Attachments: failure.txt > > > If cache configuration validation failed on cache start, > then seems exchange future rollback cache starting procedure correctly and > user get expected exception. > But then its starts to initialize broken cache which is unexpected. > We should skip broken caches. > PFA stacktraces. > Steps to reproduce: > - Try start cache with *invalid* configuration and ignore catched exception. > - Next start cache with *valid* configuration will hangs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9439) Grid hangs after cache start failure.
[ https://issues.apache.org/jira/browse/IGNITE-9439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9439: - Ignite Flags: (was: Docs Required) > Grid hangs after cache start failure. > - > > Key: IGNITE-9439 > URL: https://issues.apache.org/jira/browse/IGNITE-9439 > Project: Ignite > Issue Type: Bug > Components: general, mvcc >Affects Versions: 2.6 >Reporter: Andrew Mashenkov >Priority: Blocker > Fix For: 2.7 > > Attachments: failure.txt > > > If cache configuration validation failed on cache start, > then seems exchange future rollback cache starting procedure correctly and > user get expected exception. > But then its starts to initialize broken cache which is unexpected. > We should skip broken caches. > PFA stacktraces. > Steps to reproduce: > - Try start cache with *invalid* configuration and ignore catched exception. > - Next start cache with *valid* configuration will hangs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9439) Grid hangs after cache start failure.
[ https://issues.apache.org/jira/browse/IGNITE-9439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9439: - Component/s: mvcc > Grid hangs after cache start failure. > - > > Key: IGNITE-9439 > URL: https://issues.apache.org/jira/browse/IGNITE-9439 > Project: Ignite > Issue Type: Bug > Components: general, mvcc >Affects Versions: 2.6 >Reporter: Andrew Mashenkov >Priority: Blocker > Fix For: 2.7 > > Attachments: failure.txt > > > If cache configuration validation failed on cache start, > then seems exchange future rollback cache starting procedure correctly and > user get expected exception. > But then its starts to initialize broken cache which is unexpected. > We should skip broken caches. > PFA stacktraces. > Steps to reproduce: > - Try start cache with *invalid* configuration and ignore catched exception. > - Next start cache with *valid* configuration will hangs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9439) Grid hangs after cache start failure.
[ https://issues.apache.org/jira/browse/IGNITE-9439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9439: - Labels: (was: Hanging) > Grid hangs after cache start failure. > - > > Key: IGNITE-9439 > URL: https://issues.apache.org/jira/browse/IGNITE-9439 > Project: Ignite > Issue Type: Bug > Components: general, mvcc >Affects Versions: 2.6 >Reporter: Andrew Mashenkov >Priority: Blocker > Fix For: 2.7 > > Attachments: failure.txt > > > If cache configuration validation failed on cache start, > then seems exchange future rollback cache starting procedure correctly and > user get expected exception. > But then its starts to initialize broken cache which is unexpected. > We should skip broken caches. > PFA stacktraces. > Steps to reproduce: > - Try start cache with *invalid* configuration and ignore catched exception. > - Next start cache with *valid* configuration will hangs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9439) Grid hangs after cache start failure.
[ https://issues.apache.org/jira/browse/IGNITE-9439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9439: - Component/s: general > Grid hangs after cache start failure. > - > > Key: IGNITE-9439 > URL: https://issues.apache.org/jira/browse/IGNITE-9439 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Andrew Mashenkov >Priority: Blocker > Fix For: 2.7 > > Attachments: failure.txt > > > If cache configuration validation failed on cache start, > then seems exchange future rollback cache starting procedure correctly and > user get expected exception. > But then its starts to initialize broken cache which is unexpected. > We should skip broken caches. > PFA stacktraces. > Steps to reproduce: > - Try start cache with *invalid* configuration and ignore catched exception. > - Next start cache with *valid* configuration will hangs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9439) Grid hangs after cache start failure.
Andrew Mashenkov created IGNITE-9439: Summary: Grid hangs after cache start failure. Key: IGNITE-9439 URL: https://issues.apache.org/jira/browse/IGNITE-9439 Project: Ignite Issue Type: Bug Affects Versions: 2.6 Reporter: Andrew Mashenkov Fix For: 2.7 Attachments: failure.txt If cache configuration validation failed on cache start, then seems exchange future rollback cache starting procedure correctly and user get expected exception. But then its starts to initialize broken cache which is unexpected. We should skip broken caches. PFA stacktraces. Steps to reproduce: - Try start cache with *invalid* configuration and ignore catched exception. - Next start cache with *valid* configuration will hangs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9438) StandaloneWalRecordsIterator file descriptors leak
Sergey Antonov created IGNITE-9438:
--
Summary: StandaloneWalRecordsIterator file descriptors leak
Key: IGNITE-9438
URL: https://issues.apache.org/jira/browse/IGNITE-9438
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Sergey Antonov
Fix For: 2.7
In {{StandaloneWalRecordsIterator#initReadHandle()}} method are opens file
descriptor.
{code:java}
FileIO fileIO = fd.isCompressed() ? new UnzipFileIO(fd.file()) :
ioFactory.create(fd.file());
{code}
It not used after attempt to read segment header and it don't closed.
Second time same file descriptor are opens in super method
{{AbstractWalRecordsIterator#initReadHandle()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9437) [ML] Add performance benchmarks
[ https://issues.apache.org/jira/browse/IGNITE-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko updated IGNITE-9437: --- Ignite Flags: (was: Docs Required) > [ML] Add performance benchmarks > --- > > Key: IGNITE-9437 > URL: https://issues.apache.org/jira/browse/IGNITE-9437 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Oleg Ignatenko >Priority: Major > Fix For: 2.7 > > > We want to have some performance benchmarks for ML algorithms -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9437) [ML] Add performance benchmarks
Yury Babak created IGNITE-9437: -- Summary: [ML] Add performance benchmarks Key: IGNITE-9437 URL: https://issues.apache.org/jira/browse/IGNITE-9437 Project: Ignite Issue Type: Improvement Components: ml Reporter: Yury Babak Assignee: Oleg Ignatenko Fix For: 2.7 We want to have some performance benchmarks for ML algorithms -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9237) [ML] Random forest optimization
[ https://issues.apache.org/jira/browse/IGNITE-9237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597640#comment-16597640 ] ASF GitHub Bot commented on IGNITE-9237: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4612 > [ML] Random forest optimization > --- > > Key: IGNITE-9237 > URL: https://issues.apache.org/jira/browse/IGNITE-9237 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.7 > > > We need to implement best split selection by statistics over impurity data > and share this data for several nodes in several trees while learning process. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8149) MVCC TX: Size method should use tx snapshot
[ https://issues.apache.org/jira/browse/IGNITE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597610#comment-16597610 ] ASF GitHub Bot commented on IGNITE-8149: GitHub user pavlukhin opened a pull request: https://github.com/apache/ignite/pull/4654 IGNITE-8149: MVCC TX: Size method should use tx snapshot You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8149 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4654.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 #4654 commit b5ea6e1b5b072995f8e97a19183ebebfbae6cf20 Author: ipavlukhin Date: 2018-08-30T16:00:08Z IGNITE-8149 Cache.size is updated on MVCC transaction commit > MVCC TX: Size method should use tx snapshot > --- > > Key: IGNITE-8149 > URL: https://issues.apache.org/jira/browse/IGNITE-8149 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Igor Seliverstov >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.7 > > > Currently cache.size() returns number of entries in cache trees while there > can be several versions of one key-value pairs. > We should use tx snapshot and count all passed mvcc filter entries instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7265) BPlusTreeSelfTest.testIterateConcurrentPutRemove_1 fails
[
https://issues.apache.org/jira/browse/IGNITE-7265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597604#comment-16597604
]
Alexey Goncharuk commented on IGNITE-7265:
--
Looks like MAX_PER_PAGE is handled incorrectly when MAX_PER_PAGE is equal to 1
- if the tree is printed during the test, there are a lot of empty inner pages.
> BPlusTreeSelfTest.testIterateConcurrentPutRemove_1 fails
>
>
> Key: IGNITE-7265
> URL: https://issues.apache.org/jira/browse/IGNITE-7265
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> {code}
> java.lang.AssertionError: Assertion error on row: 26
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2221)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.put(BPlusTree.java:2156)
> at
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.iterateConcurrentPutRemove(BPlusTreeSelfTest.java:2202)
> at
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.testIterateConcurrentPutRemove_1(BPlusTreeSelfTest.java:2169)
> 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:2008)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1923)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.AssertionError: 27
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusMetaIO.setLevelsCount(BPlusMetaIO.java:98)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusMetaIO.addRoot(BPlusMetaIO.java:155)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AddRoot.run(BPlusTree.java:661)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AddRoot.run(BPlusTree.java:650)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:277)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:241)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$10500(BPlusTree.java:82)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insertWithSplit(BPlusTree.java:3073)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insert(BPlusTree.java:2949)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$2500(BPlusTree.java:2831)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:420)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:401)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5153)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5138)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:342)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:261)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$11100(BPlusTree.java:82)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.tryInsert(BPlusTree.java:3143)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$7500(BPlusTree.java:2831)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2464)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2185)
> ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9436) Compute task may cause a deadlock on node stop.
[ https://issues.apache.org/jira/browse/IGNITE-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9436: - Labels: MakeTeamcityGreenAgain deadlock (was: MakeTeamcityGreenAgain) > Compute task may cause a deadlock on node stop. > --- > > Key: IGNITE-9436 > URL: https://issues.apache.org/jira/browse/IGNITE-9436 > Project: Ignite > Issue Type: Bug > Components: compute >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain, deadlock > > Task that is waiting for async compute call result on reduce may lead to > deadlock on node stop. > This task will hold GridTaskProcessor.readlock and waits for remote call > result on future. > At that time node stopping thread will try to acquire > GridTaskProcessor.writeLock. > GridTaskProcessor job message listener will try to acquire > GridTaskProcessor.readLock with no success. > So, grid can't be stopped as there is a task on fly, but remote call result > also can't be delivered to task. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9436) Compute task may cause a deadlock on node stop.
[ https://issues.apache.org/jira/browse/IGNITE-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9436: - Labels: MakeTeamcityGreenAgain (was: ) > Compute task may cause a deadlock on node stop. > --- > > Key: IGNITE-9436 > URL: https://issues.apache.org/jira/browse/IGNITE-9436 > Project: Ignite > Issue Type: Bug > Components: compute >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Task that is waiting for async compute call result on reduce may lead to > deadlock on node stop. > This task will hold GridTaskProcessor.readlock and waits for remote call > result on future. > At that time node stopping thread will try to acquire > GridTaskProcessor.writeLock. > GridTaskProcessor job message listener will try to acquire > GridTaskProcessor.readLock with no success. > So, grid can't be stopped as there is a task on fly, but remote call result > also can't be delivered to task. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9436) Compute task may cause a deadlock on node stop.
[ https://issues.apache.org/jira/browse/IGNITE-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9436: - Ignite Flags: (was: Docs Required) > Compute task may cause a deadlock on node stop. > --- > > Key: IGNITE-9436 > URL: https://issues.apache.org/jira/browse/IGNITE-9436 > Project: Ignite > Issue Type: Bug > Components: compute >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Task that is waiting for async compute call result on reduce may lead to > deadlock on node stop. > This task will hold GridTaskProcessor.readlock and waits for remote call > result on future. > At that time node stopping thread will try to acquire > GridTaskProcessor.writeLock. > GridTaskProcessor job message listener will try to acquire > GridTaskProcessor.readLock with no success. > So, grid can't be stopped as there is a task on fly, but remote call result > also can't be delivered to task. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9436) Compute task may cause a deadlock on node stop.
Andrew Mashenkov created IGNITE-9436: Summary: Compute task may cause a deadlock on node stop. Key: IGNITE-9436 URL: https://issues.apache.org/jira/browse/IGNITE-9436 Project: Ignite Issue Type: Bug Components: compute Reporter: Andrew Mashenkov Task that is waiting for async compute call result on reduce may lead to deadlock on node stop. This task will hold GridTaskProcessor.readlock and waits for remote call result on future. At that time node stopping thread will try to acquire GridTaskProcessor.writeLock. GridTaskProcessor job message listener will try to acquire GridTaskProcessor.readLock with no success. So, grid can't be stopped as there is a task on fly, but remote call result also can't be delivered to task. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7188) SQL TX: Retry strategy on lock conflicts
[ https://issues.apache.org/jira/browse/IGNITE-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7188: Fix Version/s: (was: 2.7) > SQL TX: Retry strategy on lock conflicts > > > Key: IGNITE-7188 > URL: https://issues.apache.org/jira/browse/IGNITE-7188 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Reporter: Igor Seliverstov >Priority: Major > > We need to provide some strategy to avoid lock conflicts (deadlocks), detect > and hanle them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7371) MVCC TX Repeatable read semantic
[ https://issues.apache.org/jira/browse/IGNITE-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7371: Fix Version/s: (was: 2.7) > MVCC TX Repeatable read semantic > > > Key: IGNITE-7371 > URL: https://issues.apache.org/jira/browse/IGNITE-7371 > Project: Ignite > Issue Type: New Feature > Components: cache, mvcc >Reporter: Igor Seliverstov >Priority: Major > > Repeatable read isolation implies that each GET operation whithin tx gets a > last commited version of entry *at the time the tx was started*. Curentrly we > get a last commited version of entry *at the time the first read operation > invokes on a particular key whithin tx.* We need to fix this unconsistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6921) Optimise tx/queries tracking when mvcc is enabled and local caches are used
[ https://issues.apache.org/jira/browse/IGNITE-6921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6921: Fix Version/s: (was: 2.7) > Optimise tx/queries tracking when mvcc is enabled and local caches are used > --- > > Key: IGNITE-6921 > URL: https://issues.apache.org/jira/browse/IGNITE-6921 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > > Seems we don't need to request mvcc version and track tx/queries on mvcc > coordinator when only local caches are used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7187) SQL TX: Near caches support
[ https://issues.apache.org/jira/browse/IGNITE-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7187: Fix Version/s: (was: 2.7) > SQL TX: Near caches support > --- > > Key: IGNITE-7187 > URL: https://issues.apache.org/jira/browse/IGNITE-7187 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Reporter: Igor Seliverstov >Priority: Major > > Currently near readers don't participate in SQL transactions, we need to > notify near readers on updates. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6458) Implement possibility to manually change mvcc coordinator
[ https://issues.apache.org/jira/browse/IGNITE-6458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6458: Fix Version/s: (was: 2.7) > Implement possibility to manually change mvcc coordinator > - > > Key: IGNITE-6458 > URL: https://issues.apache.org/jira/browse/IGNITE-6458 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Semen Boikov >Priority: Major > > Need provide some ability to manually switch mvcc coordinator, probably via > MBean. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8640) If first createCache fail - Ignite is freezing on next createCache
[
https://issues.apache.org/jira/browse/IGNITE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597543#comment-16597543
]
Ryabov Dmitrii commented on IGNITE-8640:
Fix looks good to me. Tests are good.
> If first createCache fail - Ignite is freezing on next createCache
> --
>
> Key: IGNITE-8640
> URL: https://issues.apache.org/jira/browse/IGNITE-8640
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Nikolay Izhikov
>Assignee: Denis Garus
>Priority: Critical
> Fix For: 2.7
>
>
> If first {{createCache}} operation fails on some condition inside
> {{GridCacheProcessor#validate}} then second {{createCache}} will freeze
> forever.
> Reproducer:
> {code:java}
> package org.apache.ignite.internal.processors.cache;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicy;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.testframework.GridTestUtils;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> public class CreateCacheFreezeTest extends GridCommonAbstractTest {
> public void testCreateEncryptedNotPersistedCacheFail() throws Exception {
> IgniteEx ignite = startGrid(0);
>
> GridTestUtils.assertThrowsWithCause(() -> {
> CacheConfiguration cc = new
> CacheConfiguration<>("failed");
> cc.setEvictionPolicy(new FifoEvictionPolicy());
> cc.setOnheapCacheEnabled(false);
> ignite.createCache(cc);
> return 0;
> }, IgniteCheckedException.class);
> IgniteCache cache = ignite.createCache(new
> CacheConfiguration<>("default"));
> assertNotNull(cache);
> }
> }
> {code}
> Log message:
> {noformat}
> [2018-05-29
> 16:38:11,958][ERROR][exchange-worker-#38%cache.CreateCacheFreezeTest0%][GridDhtPartitionsExchangeFuture]
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=DynamicCacheChangeBatch
> [id=67cce1ca361-993dd9c2-f4fe-443b-af43-27e06424e1b0,
> reqs=[DynamicCacheChangeRequest [cacheName=failed, hasCfg=true,
> nodeId=a525b74c-aec5-4c62-855a-ff96ef30, clientStartOnly=false,
> stop=false, destroy=false, disabledAfterStartfalse]],
> exchangeActions=ExchangeActions [startCaches=[failed], stopCaches=null,
> startGrps=[failed], stopGrps=[], resetParts=null, stateChangeRequest=null],
> startCaches=false], affTopVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=a525b74c-aec5-4c62-855a-ff96ef30, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1527601090538, loc=true, ver=2.5.0#19700101-sha1:,
> isClient=false], topVer=1, nodeId8=a525b74c, msg=null,
> type=DISCOVERY_CUSTOM_EVT, tstamp=1527601091938]], nodeId=a525b74c,
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: stopping=false, groupName=null, caches=[]
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:375)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:197)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:828)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions(GridDhtPartitionTopologyImpl.java:369)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:544)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1190)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:722)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2452)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2332)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
[jira] [Commented] (IGNITE-8149) MVCC TX: Size method should use tx snapshot
[ https://issues.apache.org/jira/browse/IGNITE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597520#comment-16597520 ] Ivan Pavlukhin commented on IGNITE-8149: 4 - updatedCachePartitions -> touchedCachePartitions > MVCC TX: Size method should use tx snapshot > --- > > Key: IGNITE-8149 > URL: https://issues.apache.org/jira/browse/IGNITE-8149 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Igor Seliverstov >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.7 > > > Currently cache.size() returns number of entries in cache trees while there > can be several versions of one key-value pairs. > We should use tx snapshot and count all passed mvcc filter entries instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-4191) SQL: support transactions
[ https://issues.apache.org/jira/browse/IGNITE-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4191: Ignite Flags: Docs Required > SQL: support transactions > - > > Key: IGNITE-4191 > URL: https://issues.apache.org/jira/browse/IGNITE-4191 > Project: Ignite > Issue Type: New Feature > Components: mvcc, sql >Reporter: Denis Magda >Priority: Major > Fix For: 2.7 > > > Presently there is no any way to execute data modification statements and > SELECT queries in a transactional fashion using our JDBC/ODBC drivers and DML > API. > This can be fully supported once MVCC is ready and released. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9435) Document MVCC
Vladimir Ozerov created IGNITE-9435: --- Summary: Document MVCC Key: IGNITE-9435 URL: https://issues.apache.org/jira/browse/IGNITE-9435 Project: Ignite Issue Type: Task Components: documentation, mvcc Reporter: Vladimir Ozerov Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-4191) SQL: support transactions
[ https://issues.apache.org/jira/browse/IGNITE-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-4191. - Resolution: Fixed > SQL: support transactions > - > > Key: IGNITE-4191 > URL: https://issues.apache.org/jira/browse/IGNITE-4191 > Project: Ignite > Issue Type: New Feature > Components: mvcc, sql >Reporter: Denis Magda >Priority: Major > Fix For: 2.7 > > > Presently there is no any way to execute data modification statements and > SELECT queries in a transactional fashion using our JDBC/ODBC drivers and DML > API. > This can be fully supported once MVCC is ready and released. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8886) Simultaneous using of BinaryWriter и BinaryRawWriter leads to BinaryObjectException and OOM
[
https://issues.apache.org/jira/browse/IGNITE-8886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597512#comment-16597512
]
Ilya Kasnacheev commented on IGNITE-8886:
-
[~vozerov] please review deserialization fix!
> Simultaneous using of BinaryWriter и BinaryRawWriter leads to
> BinaryObjectException and OOM
> ---
>
> Key: IGNITE-8886
> URL: https://issues.apache.org/jira/browse/IGNITE-8886
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.5
>Reporter: Roman Guseinov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: binary
> Attachments: BinarylizableInvalidFlag.java, BinarylizableOOM.java,
> Screenshot_20180830_142433.png
>
>
> When we use BinaryWriter and BinaryRawWriter simultaneously inside
> writeBinary method we can get the following exceptions in the process of
> deserializing objects:
> 1. class org.apache.ignite.binary.BinaryObjectException: Invalid flag value:
> 115
> {code:java}
> Exception in thread "main" javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> [typeName=org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag$TestBean]
>at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1302)
>at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1732)
>at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:910)
>at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:608)
>at
> org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag.main(BinarylizableInvalidFlag.java:33)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> deserialize object
> [typeName=org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag$TestBean]
>at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7322)
>at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
>at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:171)
>at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
>at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4563)
>at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4537)
>at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1350)
>at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:907)
>... 2 more
> Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to
> deserialize object
> [typeName=org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag$TestBean]
>at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:909)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
>at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:798)
>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.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1764)
>at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1752)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:679)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.localGet(GridPartitionedSingleGetFuture.java:461)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:342)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:216)
>at
>
[jira] [Commented] (IGNITE-8149) MVCC TX: Size method should use tx snapshot
[ https://issues.apache.org/jira/browse/IGNITE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597508#comment-16597508 ] Igor Seliverstov commented on IGNITE-8149: -- [~Pavlukhin], "updated rows" sounds natural, but I cant say the same about "updated partitions". I would insist to rename the method. > MVCC TX: Size method should use tx snapshot > --- > > Key: IGNITE-8149 > URL: https://issues.apache.org/jira/browse/IGNITE-8149 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Igor Seliverstov >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.7 > > > Currently cache.size() returns number of entries in cache trees while there > can be several versions of one key-value pairs. > We should use tx snapshot and count all passed mvcc filter entries instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8149) MVCC TX: Size method should use tx snapshot
[ https://issues.apache.org/jira/browse/IGNITE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597507#comment-16597507 ] Ivan Pavlukhin commented on IGNITE-8149: 6, 7 - tests added > MVCC TX: Size method should use tx snapshot > --- > > Key: IGNITE-8149 > URL: https://issues.apache.org/jira/browse/IGNITE-8149 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Igor Seliverstov >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.7 > > > Currently cache.size() returns number of entries in cache trees while there > can be several versions of one key-value pairs. > We should use tx snapshot and count all passed mvcc filter entries instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9141) SQL: Trace and test query mapping problems
[
https://issues.apache.org/jira/browse/IGNITE-9141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597448#comment-16597448
]
Sergey Grimstad edited comment on IGNITE-9141 at 8/30/18 2:17 PM:
--
[https://ci.ignite.apache.org/viewLog.html?buildId=1759345;]
failed 7 tests looks flaky and do not reproduce locally
was (Author: sgrimstad):
[https://ci.ignite.apache.org/viewLog.html?buildId=1759345;]
непройденный 7 тестов - флаки и локально не воспроизводятся
> SQL: Trace and test query mapping problems
> --
>
> Key: IGNITE-9141
> URL: https://issues.apache.org/jira/browse/IGNITE-9141
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.6
>Reporter: Vladimir Ozerov
>Assignee: Sergey Grimstad
>Priority: Major
> Labels: sql-stability
> Fix For: 2.7
>
> Attachments: IGNITE-9141__Implemented_.patch
>
>
> One of mandatory steps of SQL query execution is topology mapping - we need
> to select nodes where required caches are located, and make sure that their
> partition distribution is valid for the given SQL query. Once nodes are
> detected, we try to reserve partitions of interest on mapper nodes to make
> sure that they will not be evicted during query execution.
> However, mapping step may fail for many reasons. Most often this is rebalance
> or concurrent node failures. In this case we simply retry the whole query
> execution from scratch. In IGNITE-9114 we ensured that retry cycle is not
> infinite and that root cause of remap is logged. However, original root cause
> of remap is not propagated to client node making the problem hard to debug
> for end users. Also we do not have enough tests for remap events. Let's fix
> this.
> Proposed implementation flow:
> 1) Add {{retryCause: String}} field to {{GridQueryNextPageResponse}} which
> should be populated along with {{retry}} field on mapper node. See
> {{GridMapQueryExecutor#sendRetry}} method to understand what may cause
> retries (failed to reserve partitions or failed to execute non-collocated
> join). Make sure that these error messages are as verbose as possible with
> all necessary details (root cause, cache names, affected partitions, etc).
> 2) Make sure that root cause is set in {{ReduceQueryRun#state}} and then
> propagated to user exception in case of retry timeout.
> 3) Evaluate all places inside
> {{org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query}}
> which may lead to re-try and make sure that root cause is verbose and
> propagated to user exception in case of retry timeout.
> 4) Add tests covering all re-try branches and ensure that query fails after
> timeout and that error message is correct.
> *NB*: Once propagation of error message to reducer is implemented, we may
> remove additional logging altogether.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9433) Refactoring to improve constant usage for file suffixes
[ https://issues.apache.org/jira/browse/IGNITE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597504#comment-16597504 ] ASF GitHub Bot commented on IGNITE-9433: GitHub user voropava opened a pull request: https://github.com/apache/ignite/pull/4652 IGNITE-9433 Extracted zip suffix constant You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9433 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4652.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 #4652 commit 466f485f0c030f542dac5ac34fc10f543d924ec0 Author: Pavel Voronkin Date: 2018-08-30T14:11:38Z IGNITE-9433 Extracted zip suffix constant > Refactoring to improve constant usage for file suffixes > --- > > Key: IGNITE-9433 > URL: https://issues.apache.org/jira/browse/IGNITE-9433 > Project: Ignite > Issue Type: Task >Reporter: Pavel Voronkin >Priority: Major > Fix For: 2.7 > > > We need extract file suffix constants to avoid duplication of string > constants for zip files, like ".zip" and ".tmp" across the project -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9373) MVCC tests fail
[ https://issues.apache.org/jira/browse/IGNITE-9373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9373: - Fix Version/s: 2.7 > MVCC tests fail > --- > > Key: IGNITE-9373 > URL: https://issues.apache.org/jira/browse/IGNITE-9373 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Ivan Pavlukhin >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.7 > > Attachments: MvccTestResults.tar.gz > > > Number of tests in MVCC test suites fail. Most of the fails is a regression > introduces by new changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9302) Java Thin Clients TC configuration hangs because of no timeout on tests
[ https://issues.apache.org/jira/browse/IGNITE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597481#comment-16597481 ] ASF GitHub Bot commented on IGNITE-9302: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4562 > Java Thin Clients TC configuration hangs because of no timeout on tests > --- > > Key: IGNITE-9302 > URL: https://issues.apache.org/jira/browse/IGNITE-9302 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_JavaThinClient=buildTypeHistoryList_IgniteTests24Java8=__all_branches__ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9302) Java Thin Clients TC configuration hangs because of no timeout on tests
[ https://issues.apache.org/jira/browse/IGNITE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9302: - Labels: MakeTeamcityGreenAgain (was: ) > Java Thin Clients TC configuration hangs because of no timeout on tests > --- > > Key: IGNITE-9302 > URL: https://issues.apache.org/jira/browse/IGNITE-9302 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_JavaThinClient=buildTypeHistoryList_IgniteTests24Java8=__all_branches__ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8149) MVCC TX: Size method should use tx snapshot
[ https://issues.apache.org/jira/browse/IGNITE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597477#comment-16597477 ] Ivan Pavlukhin commented on IGNITE-8149: 1 - 3 - done 4 - _involvedPartitions_ name reflects semantics improperly, because only _updated_ ones are tracked here 5 - replaced with lazily initialized volatile 6, 7 - in progress 8 - done 9 - done > MVCC TX: Size method should use tx snapshot > --- > > Key: IGNITE-8149 > URL: https://issues.apache.org/jira/browse/IGNITE-8149 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Igor Seliverstov >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.7 > > > Currently cache.size() returns number of entries in cache trees while there > can be several versions of one key-value pairs. > We should use tx snapshot and count all passed mvcc filter entries instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9433) Refactoring to improve constant usage for file suffixes
[ https://issues.apache.org/jira/browse/IGNITE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597476#comment-16597476 ] ASF GitHub Bot commented on IGNITE-9433: Github user voropava closed the pull request at: https://github.com/apache/ignite/pull/4651 > Refactoring to improve constant usage for file suffixes > --- > > Key: IGNITE-9433 > URL: https://issues.apache.org/jira/browse/IGNITE-9433 > Project: Ignite > Issue Type: Task >Reporter: Pavel Voronkin >Priority: Major > Fix For: 2.7 > > > We need extract file suffix constants to avoid duplication of string > constants for zip files, like ".zip" and ".tmp" across the project -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9302) Java Thin Clients TC configuration hangs because of no timeout on tests
[ https://issues.apache.org/jira/browse/IGNITE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9302: - Fix Version/s: 2.7 > Java Thin Clients TC configuration hangs because of no timeout on tests > --- > > Key: IGNITE-9302 > URL: https://issues.apache.org/jira/browse/IGNITE-9302 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.7 > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_JavaThinClient=buildTypeHistoryList_IgniteTests24Java8=__all_branches__ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9302) Java Thin Clients TC configuration hangs because of no timeout on tests
[ https://issues.apache.org/jira/browse/IGNITE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9302: - Ignite Flags: (was: Docs Required) > Java Thin Clients TC configuration hangs because of no timeout on tests > --- > > Key: IGNITE-9302 > URL: https://issues.apache.org/jira/browse/IGNITE-9302 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.7 > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_JavaThinClient=buildTypeHistoryList_IgniteTests24Java8=__all_branches__ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9434) Create suites for MVCC tests on TC.
[ https://issues.apache.org/jira/browse/IGNITE-9434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9434: - Summary: Create suites for MVCC tests on TC. (was: Create suites for MVCC tests.) > Create suites for MVCC tests on TC. > --- > > Key: IGNITE-9434 > URL: https://issues.apache.org/jira/browse/IGNITE-9434 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Blocker > Labels: MakeTeamcityGreenAgain, teamcity > Fix For: 2.7 > > > MVCC tests suites should be created on Ignite TeamCity. > * org.apache.ignite.testsuites;.MvccQueryTrackerImpl > * org.apache.ignite.jdbc.suite.IgniteJdbcDriverMvccTestSuite > * org.apache.ignite.testsuites.IgniteCacheMvccTestSuite > "MVCC Run All" should be created as well to run mvcc tests only. > Mvcc tests should be added to "Run All" as well. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9434) Create suites for MVCC tests.
Andrew Mashenkov created IGNITE-9434: Summary: Create suites for MVCC tests. Key: IGNITE-9434 URL: https://issues.apache.org/jira/browse/IGNITE-9434 Project: Ignite Issue Type: Task Components: mvcc Reporter: Andrew Mashenkov Fix For: 2.7 MVCC tests suites should be created on Ignite TeamCity. * org.apache.ignite.testsuites;.MvccQueryTrackerImpl * org.apache.ignite.jdbc.suite.IgniteJdbcDriverMvccTestSuite * org.apache.ignite.testsuites.IgniteCacheMvccTestSuite "MVCC Run All" should be created as well to run mvcc tests only. Mvcc tests should be added to "Run All" as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9428) MVCC TX: MvccQueryTrackerImpl.onDone() semantic is broken.
[
https://issues.apache.org/jira/browse/IGNITE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-9428:
-
Summary: MVCC TX: MvccQueryTrackerImpl.onDone() semantic is broken. (was:
MVCC TX: Multiple H2ResultSetIterator closing leads to assertion in
MvccProcessor)
> MVCC TX: MvccQueryTrackerImpl.onDone() semantic is broken.
> --
>
> Key: IGNITE-9428
> URL: https://issues.apache.org/jira/browse/IGNITE-9428
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
>
> Due to IGNITE-9256 patch, multiple {{H2ResultSetIterator#onClose}} invocation
> becomes possible. This can be considered as a {{Closable}} contract violation
> and should be fixed.
> Also this case revealed a bug in {{MvccQueryTrackerImpl}} when multiple
> {{onDone()}} call leads to multiple query finished acks sent back to the
> {{MvccCoordinator}} which leads to the problems with the query tracking and
> assertion errors.
> Reproducer:
> {{CacheMvccSqlTxQueriesAbstractTest#testAccountsTxDmlSumSql_WithRemoves_SingleNode}}
>
>
> Upd: test was fixed in IGNITE-9373. But MvccQueryTrackerImpl.onDone() issue
> is still actual.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9428) MVCC TX: Multiple H2ResultSetIterator closing leads to assertion in MvccProcessor
[
https://issues.apache.org/jira/browse/IGNITE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-9428:
-
Description:
Due to IGNITE-9256 patch, multiple {{H2ResultSetIterator#onClose}} invocation
becomes possible. This can be considered as a {{Closable}} contract violation
and should be fixed.
Also this case revealed a bug in {{MvccQueryTrackerImpl}} when multiple
{{onDone()}} call leads to multiple query finished acks sent back to the
{{MvccCoordinator}} which leads to the problems with the query tracking and
assertion errors.
Reproducer:
{{CacheMvccSqlTxQueriesAbstractTest#testAccountsTxDmlSumSql_WithRemoves_SingleNode}}
Upd: test was fixed in IGNITE-9373. But MvccQueryTrackerImpl.onDone() issue is
still actual.
was:
Due to [IGNITE-9256|https://issues.apache.org/jira/browse/IGNITE-9256] patch,
multiple {{H2ResultSetIterator#onClose}} invocation becomes possible. This can
be considered as a {{Closable}} contract violation and should be fixed.
Also this case revealed a bug in {{MvccQueryTrackerImpl}} when multiple
{{onDone()}} call leads to multiple query finished acks sent back to the
{{MvccCoordinator}} which leads to the problems with the query tracking and
assertion errors.
Reproducer:
{{CacheMvccSqlTxQueriesAbstractTest#testAccountsTxDmlSumSql_WithRemoves_SingleNode}}
> MVCC TX: Multiple H2ResultSetIterator closing leads to assertion in
> MvccProcessor
> -
>
> Key: IGNITE-9428
> URL: https://issues.apache.org/jira/browse/IGNITE-9428
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
>
> Due to IGNITE-9256 patch, multiple {{H2ResultSetIterator#onClose}} invocation
> becomes possible. This can be considered as a {{Closable}} contract violation
> and should be fixed.
> Also this case revealed a bug in {{MvccQueryTrackerImpl}} when multiple
> {{onDone()}} call leads to multiple query finished acks sent back to the
> {{MvccCoordinator}} which leads to the problems with the query tracking and
> assertion errors.
> Reproducer:
> {{CacheMvccSqlTxQueriesAbstractTest#testAccountsTxDmlSumSql_WithRemoves_SingleNode}}
>
>
> Upd: test was fixed in IGNITE-9373. But MvccQueryTrackerImpl.onDone() issue
> is still actual.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9428) MVCC TX: Multiple H2ResultSetIterator closing leads to assertion in MvccProcessor
[
https://issues.apache.org/jira/browse/IGNITE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597462#comment-16597462
]
Andrew Mashenkov commented on IGNITE-9428:
--
I've partially fixed the issue within IGNITE-9373.
Iterator now close correctly, but Issue related to multiple MvccQueryTracker
calls is still actual.
We have to add a close flag to mvcc tracker and have a guarantee that onDone()
call will affect tracker only once.
Also we should correctly handle a case when tracker closes is middle of
initialization, e.g. onDone() is triggered by timeout, but tracker just has
sent a request for mvcc version to coordinator. When tracker will get an Ack it
should release all resources immediately if it was concurrently closed.
> MVCC TX: Multiple H2ResultSetIterator closing leads to assertion in
> MvccProcessor
> -
>
> Key: IGNITE-9428
> URL: https://issues.apache.org/jira/browse/IGNITE-9428
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
>
> Due to [IGNITE-9256|https://issues.apache.org/jira/browse/IGNITE-9256] patch,
> multiple {{H2ResultSetIterator#onClose}} invocation becomes possible. This
> can be considered as a {{Closable}} contract violation and should be fixed.
> Also this case revealed a bug in {{MvccQueryTrackerImpl}} when multiple
> {{onDone()}} call leads to multiple query finished acks sent back to the
> {{MvccCoordinator}} which leads to the problems with the query tracking and
> assertion errors.
> Reproducer:
> {{CacheMvccSqlTxQueriesAbstractTest#testAccountsTxDmlSumSql_WithRemoves_SingleNode}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9433) Refactoring to improve constant usage for file suffixes
[ https://issues.apache.org/jira/browse/IGNITE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597463#comment-16597463 ] ASF GitHub Bot commented on IGNITE-9433: GitHub user voropava opened a pull request: https://github.com/apache/ignite/pull/4651 IGNITE-9433 Extractted zip suffix constant You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9433 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4651.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 #4651 commit a7999cb5646716cd662f21c125df9af68558fddf Author: Pavel Voronkin Date: 2018-08-30T13:37:18Z IGNITE-9433 Extractted zip suffix constant > Refactoring to improve constant usage for file suffixes > --- > > Key: IGNITE-9433 > URL: https://issues.apache.org/jira/browse/IGNITE-9433 > Project: Ignite > Issue Type: Task >Reporter: Pavel Voronkin >Priority: Major > Fix For: 2.7 > > > We need extract file suffix constants to avoid duplication of string > constants for zip files, like ".zip" and ".tmp" across the project -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9093) IgniteDbPutGetWithCacheStoreTest.testReadThrough fails every time when run on master
[ https://issues.apache.org/jira/browse/IGNITE-9093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597456#comment-16597456 ] Ilya Lantukh edited comment on IGNITE-9093 at 8/30/18 1:34 PM: --- [~ilyak], This is not a big issue and your fix looks OK. We do not store in WAL data that was read from external store using read-through mechanics. was (Author: ilantukh): [~ilyak], This is not a big issue and your fix looks OK. > IgniteDbPutGetWithCacheStoreTest.testReadThrough fails every time when run on > master > > > Key: IGNITE-9093 > URL: https://issues.apache.org/jira/browse/IGNITE-9093 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: MakeTeamcityGreenAgain > > Such as in > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Pds1=pull%2F4420%2Fhead=buildTypeStatusDiv > Used to work every time in 2.6 release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9093) IgniteDbPutGetWithCacheStoreTest.testReadThrough fails every time when run on master
[ https://issues.apache.org/jira/browse/IGNITE-9093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597456#comment-16597456 ] Ilya Lantukh commented on IGNITE-9093: -- [~ilyak], This is not a big issue and your fix looks OK. > IgniteDbPutGetWithCacheStoreTest.testReadThrough fails every time when run on > master > > > Key: IGNITE-9093 > URL: https://issues.apache.org/jira/browse/IGNITE-9093 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: MakeTeamcityGreenAgain > > Such as in > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Pds1=pull%2F4420%2Fhead=buildTypeStatusDiv > Used to work every time in 2.6 release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9141) SQL: Trace and test query mapping problems
[
https://issues.apache.org/jira/browse/IGNITE-9141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597448#comment-16597448
]
Sergey Grimstad commented on IGNITE-9141:
-
[https://ci.ignite.apache.org/viewLog.html?buildId=1759345;]
непройденный 7 тестов - флаки и локально не воспроизводятся
> SQL: Trace and test query mapping problems
> --
>
> Key: IGNITE-9141
> URL: https://issues.apache.org/jira/browse/IGNITE-9141
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.6
>Reporter: Vladimir Ozerov
>Assignee: Sergey Grimstad
>Priority: Major
> Labels: sql-stability
> Fix For: 2.7
>
> Attachments: IGNITE-9141__Implemented_.patch
>
>
> One of mandatory steps of SQL query execution is topology mapping - we need
> to select nodes where required caches are located, and make sure that their
> partition distribution is valid for the given SQL query. Once nodes are
> detected, we try to reserve partitions of interest on mapper nodes to make
> sure that they will not be evicted during query execution.
> However, mapping step may fail for many reasons. Most often this is rebalance
> or concurrent node failures. In this case we simply retry the whole query
> execution from scratch. In IGNITE-9114 we ensured that retry cycle is not
> infinite and that root cause of remap is logged. However, original root cause
> of remap is not propagated to client node making the problem hard to debug
> for end users. Also we do not have enough tests for remap events. Let's fix
> this.
> Proposed implementation flow:
> 1) Add {{retryCause: String}} field to {{GridQueryNextPageResponse}} which
> should be populated along with {{retry}} field on mapper node. See
> {{GridMapQueryExecutor#sendRetry}} method to understand what may cause
> retries (failed to reserve partitions or failed to execute non-collocated
> join). Make sure that these error messages are as verbose as possible with
> all necessary details (root cause, cache names, affected partitions, etc).
> 2) Make sure that root cause is set in {{ReduceQueryRun#state}} and then
> propagated to user exception in case of retry timeout.
> 3) Evaluate all places inside
> {{org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query}}
> which may lead to re-try and make sure that root cause is verbose and
> propagated to user exception in case of retry timeout.
> 4) Add tests covering all re-try branches and ensure that query fails after
> timeout and that error message is correct.
> *NB*: Once propagation of error message to reducer is implemented, we may
> remove additional logging altogether.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8318) MVCC TX: Scan query call throws an exception when it is mixed with Key-Value API in the same transaction.
[
https://issues.apache.org/jira/browse/IGNITE-8318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-8318:
-
Fix Version/s: 2.7
> MVCC TX: Scan query call throws an exception when it is mixed with Key-Value
> API in the same transaction.
> --
>
> Key: IGNITE-8318
> URL: https://issues.apache.org/jira/browse/IGNITE-8318
> Project: Ignite
> Issue Type: Bug
> Components: cache, mvcc, sql
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
> Fix For: 2.7
>
>
> Scan queries should not throw Exceptions in key-value API transactions.
> Reproducer: {{CacheMvccTransactionsTest#testPutAllGetAll_SingleNode_Scan}}
>
> This should fix
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccTransactionsTest.testCleanupWaitsForGet1()
> as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-7259) GridIndexRebuildSelfTest hangs
[ https://issues.apache.org/jira/browse/IGNITE-7259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov closed IGNITE-7259. > GridIndexRebuildSelfTest hangs > -- > > Key: IGNITE-7259 > URL: https://issues.apache.org/jira/browse/IGNITE-7259 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Reporter: Vladimir Ozerov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.7 > > Attachments: deadlock-thread-dumps.txt > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-8149) MVCC TX: Size method should use tx snapshot
[ https://issues.apache.org/jira/browse/IGNITE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-8149: --- Comment: was deleted (was: 1 - 3 fixed) > MVCC TX: Size method should use tx snapshot > --- > > Key: IGNITE-8149 > URL: https://issues.apache.org/jira/browse/IGNITE-8149 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Igor Seliverstov >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.7 > > > Currently cache.size() returns number of entries in cache trees while there > can be several versions of one key-value pairs. > We should use tx snapshot and count all passed mvcc filter entries instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8149) MVCC TX: Size method should use tx snapshot
[ https://issues.apache.org/jira/browse/IGNITE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597443#comment-16597443 ] Ivan Pavlukhin commented on IGNITE-8149: 1 - 3 fixed > MVCC TX: Size method should use tx snapshot > --- > > Key: IGNITE-8149 > URL: https://issues.apache.org/jira/browse/IGNITE-8149 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Igor Seliverstov >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.7 > > > Currently cache.size() returns number of entries in cache trees while there > can be several versions of one key-value pairs. > We should use tx snapshot and count all passed mvcc filter entries instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8318) MVCC TX: Scan query call throws an exception when it is mixed with Key-Value API in the same transaction.
[
https://issues.apache.org/jira/browse/IGNITE-8318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov closed IGNITE-8318.
> MVCC TX: Scan query call throws an exception when it is mixed with Key-Value
> API in the same transaction.
> --
>
> Key: IGNITE-8318
> URL: https://issues.apache.org/jira/browse/IGNITE-8318
> Project: Ignite
> Issue Type: Bug
> Components: cache, mvcc, sql
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
>
> Scan queries should not throw Exceptions in key-value API transactions.
> Reproducer: {{CacheMvccTransactionsTest#testPutAllGetAll_SingleNode_Scan}}
>
> This should fix
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccTransactionsTest.testCleanupWaitsForGet1()
> as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-7259) GridIndexRebuildSelfTest hangs
[ https://issues.apache.org/jira/browse/IGNITE-7259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov resolved IGNITE-7259. -- Resolution: Fixed Fixed within IGNITE-9373. > GridIndexRebuildSelfTest hangs > -- > > Key: IGNITE-7259 > URL: https://issues.apache.org/jira/browse/IGNITE-7259 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Reporter: Vladimir Ozerov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.7 > > Attachments: deadlock-thread-dumps.txt > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9373) MVCC tests fail
[ https://issues.apache.org/jira/browse/IGNITE-9373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597440#comment-16597440 ] Andrew Mashenkov commented on IGNITE-9373: -- I've updated PR from master as IGNITE-4191 has been merged recently. * Fixed CacheMvccTransactions hanging. * Fixed GridIndexRebuildSelfTest hanging. (IGNITE-7259) * Fixed incorrect node stopping on tests finish. * Fixed racec in Vacuum with concurrent cache stopping. * Move Mvcc tests to separate test suites. * Fix .NET grid configuration validation. * Fix wrong ScanQuery mvcc snapshot usage. (IGNITE-8318) * Fix incorrect iterator closing when last element has been fetched. (IGNITE-9428 partial fix) * Fix styles. > MVCC tests fail > --- > > Key: IGNITE-9373 > URL: https://issues.apache.org/jira/browse/IGNITE-9373 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Ivan Pavlukhin >Assignee: Andrew Mashenkov >Priority: Major > Attachments: MvccTestResults.tar.gz > > > Number of tests in MVCC test suites fail. Most of the fails is a regression > introduces by new changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8318) MVCC TX: Scan query call throws an exception when it is mixed with Key-Value API in the same transaction.
[
https://issues.apache.org/jira/browse/IGNITE-8318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov resolved IGNITE-8318.
--
Resolution: Duplicate
Fixed within IGNITE-9373.
> MVCC TX: Scan query call throws an exception when it is mixed with Key-Value
> API in the same transaction.
> --
>
> Key: IGNITE-8318
> URL: https://issues.apache.org/jira/browse/IGNITE-8318
> Project: Ignite
> Issue Type: Bug
> Components: cache, mvcc, sql
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
>
> Scan queries should not throw Exceptions in key-value API transactions.
> Reproducer: {{CacheMvccTransactionsTest#testPutAllGetAll_SingleNode_Scan}}
>
> This should fix
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccTransactionsTest.testCleanupWaitsForGet1()
> as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9433) Refactoring to improve constant usage for file suffixes
[ https://issues.apache.org/jira/browse/IGNITE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-9433: --- Description: We need extract file suffix constants to avoid duplication of string constants for zip files, like ".zip" and ".tmp" across the project (was: We need extract file suffix constants to avoid duplication of string constants for zip files, like ".zip" across the project) > Refactoring to improve constant usage for file suffixes > --- > > Key: IGNITE-9433 > URL: https://issues.apache.org/jira/browse/IGNITE-9433 > Project: Ignite > Issue Type: Task >Reporter: Pavel Voronkin >Priority: Major > Fix For: 2.7 > > > We need extract file suffix constants to avoid duplication of string > constants for zip files, like ".zip" and ".tmp" across the project -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8149) MVCC TX: Size method should use tx snapshot
[
https://issues.apache.org/jira/browse/IGNITE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597429#comment-16597429
]
Igor Seliverstov commented on IGNITE-8149:
--
[~Pavlukhin], see my comments below:
1) Move {{applyAndCollectLocalUpdateCounters()}} and
{{txCounters().updateCounters(updCntrs)}} to
{{org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter#applyTxCounters}}
2) Inline
{{org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter#applyUpdateCounters}}
method
3) Inline
{{org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter#applyCacheSizeDeltas}}
method
4)
{{org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalState#updatedCachePartitions}}
- involvedPartitions, I think, much better name
5)
{{org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalStateAdapter#updCacheParts}}
has no sense for non-mvcc transactions and should be initialized lazily
6) What about changes, made by DataStreamer? Appropriate tests are needed.
7) There are no tests for size consistency after just joined node is fully
rebalanced.
8) Inline
{{org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.CacheDataStoreImpl#updateSize0}}
and use
{{org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.CacheDataStoreImpl#updateSize}}
instead
9) Check imports.
> MVCC TX: Size method should use tx snapshot
> ---
>
> Key: IGNITE-8149
> URL: https://issues.apache.org/jira/browse/IGNITE-8149
> Project: Ignite
> Issue Type: Task
> Components: cache, mvcc
>Reporter: Igor Seliverstov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.7
>
>
> Currently cache.size() returns number of entries in cache trees while there
> can be several versions of one key-value pairs.
> We should use tx snapshot and count all passed mvcc filter entries instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9433) Refactoring to improve constant usage for file suffixes
[ https://issues.apache.org/jira/browse/IGNITE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-9433: --- Description: We need extract file suffix constants to avoid duplication of string constants for zip files, like ".zip" across the project > Refactoring to improve constant usage for file suffixes > --- > > Key: IGNITE-9433 > URL: https://issues.apache.org/jira/browse/IGNITE-9433 > Project: Ignite > Issue Type: Task >Reporter: Pavel Voronkin >Priority: Major > Fix For: 2.7 > > > We need extract file suffix constants to avoid duplication of string > constants for zip files, like ".zip" across the project -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9433) Refactoring to improve constant usage for file suffixes
Pavel Voronkin created IGNITE-9433: -- Summary: Refactoring to improve constant usage for file suffixes Key: IGNITE-9433 URL: https://issues.apache.org/jira/browse/IGNITE-9433 Project: Ignite Issue Type: Task Reporter: Pavel Voronkin Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9345) Document custom SQL schemas
[
https://issues.apache.org/jira/browse/IGNITE-9345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597406#comment-16597406
]
Sergey Kozlov edited comment on IGNITE-9345 at 8/30/18 12:54 PM:
-
The example in Spring configuration:
{code:xml}
...
MY_SCHEMA
{code}
url: jdbc:ignite:thin://127.0.0.1/MY_SCHEMA
was (Author: skozlov):
The example in Spring configuration:
{code:xml}
...
MY_SCHEMA
{code}
> Document custom SQL schemas
> ---
>
> Key: IGNITE-9345
> URL: https://issues.apache.org/jira/browse/IGNITE-9345
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> Key highlights:
> 1) DDL operations \{{CREATE TABLE}} and \{{DROP TABLE}} are no longer tied to
> \{{PUBLIC}} schema. They can be executed on any schema. Need to remove this
> from docs (if there is such paragraph)
> 2) Added a property \{{IgniteConfiguration.sqlSchemas}} which creates local
> schemas with provided names.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9345) Document custom SQL schemas
[
https://issues.apache.org/jira/browse/IGNITE-9345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597406#comment-16597406
]
Sergey Kozlov commented on IGNITE-9345:
---
The example in Spring configuration:
{code:xml}
...
MY_SCHEMA
{code}
> Document custom SQL schemas
> ---
>
> Key: IGNITE-9345
> URL: https://issues.apache.org/jira/browse/IGNITE-9345
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> Key highlights:
> 1) DDL operations \{{CREATE TABLE}} and \{{DROP TABLE}} are no longer tied to
> \{{PUBLIC}} schema. They can be executed on any schema. Need to remove this
> from docs (if there is such paragraph)
> 2) Added a property \{{IgniteConfiguration.sqlSchemas}} which creates local
> schemas with provided names.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6552) The ability to set WAL history size in bytes
[
https://issues.apache.org/jira/browse/IGNITE-6552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597373#comment-16597373
]
ASF GitHub Bot commented on IGNITE-6552:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/3559
> The ability to set WAL history size in bytes
>
>
> Key: IGNITE-6552
> URL: https://issues.apache.org/jira/browse/IGNITE-6552
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Affects Versions: 2.2
>Reporter: Vladislav Pyatkov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.7
>
>
> We can set size of WAL history in number of checkpoints.
> {code}
> org.apache.ignite.configuration.PersistentStoreConfiguration#setWalHistorySize
> {code}
> But it is not convenient fro end user. Nobody to say how many checkpoint to
> occur over several minutes.
> I think, it will be better if we will have ability to set WAL history size in
> bytes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-4191) SQL: support transactions
[ https://issues.apache.org/jira/browse/IGNITE-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597374#comment-16597374 ] ASF GitHub Bot commented on IGNITE-4191: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3220 > SQL: support transactions > - > > Key: IGNITE-4191 > URL: https://issues.apache.org/jira/browse/IGNITE-4191 > Project: Ignite > Issue Type: New Feature > Components: mvcc, sql >Reporter: Denis Magda >Priority: Major > Fix For: 2.7 > > > Presently there is no any way to execute data modification statements and > SELECT queries in a transactional fashion using our JDBC/ODBC drivers and DML > API. > This can be fully supported once MVCC is ready and released. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9432) Investigate ability to make ScanQuery faster
[
https://issues.apache.org/jira/browse/IGNITE-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Dmitriev updated IGNITE-9432:
---
Description:
When we make ScanQuery via Binary Client Protocol it works very slowly in case
we need to retrieve a big amount of objects (all objects in our case). The most
slower part is a waiting for response from Apache Ignite. This also mentioned
on devlist
[http://apache-ignite-developers.2346864.n4.nabble.com/How-to-reduce-Scan-Query-execution-time-td34212.html].
To reproduce the problem we've prepared a small example:
[slow-scan-query-reproducer|https://github.com/dmitrievanthony/slow-scan-query-reproducer].
In this example we creates a cache with 500 objects 1Mb each (on localhost),
we make ScanQuery with different page sizes and calculate time between the
moment when the request has been sent and the moment when the response is ready
to be receive. The measurements are here:
Page size 5 Mb, waiting time 119.85 ± 6.72 ms
Page size 10 Mb, waiting time 157.70 ± 15.35 ms
Page size 20 Mb, waiting time 204.50 ± 19.18 ms
Page size 50 Mb, waiting time 264.70 ± 22.30 ms
Page size 100 Mb, waiting time 463.35 ± 17.12 ms
Page size 150 Mb, waiting time 672.50 ± 21.98 ms
As result we spend ~4ms per every megabyte on _something_. It means that we
will be able to achieve 250Mb/s throughput in best case. It's too slow, isn't
it?
was:
When we make ScanQuery via Binary Client Protocol it works very slowly in case
we need to retrieve a big amount of objects (all objects in our case). The most
slower part is a waiting for response from Apache Ignite. This also mentioned
on devlist
[http://apache-ignite-developers.2346864.n4.nabble.com/How-to-reduce-Scan-Query-execution-time-td34212.html].
To reproduce the problem we've prepared a small example:
[slow-scan-query-reproducer|https://github.com/dmitrievanthony/slow-scan-query-reproducer].
In this example we creates a cache with 500 objects 1Mb each (on localhost),
we make ScanQuery with different page sizes and calculate time between the
moment when the request has been sent and the moment when the response is ready
to be receive. The measurements are here:
{{Page size 5 Mb, waiting time 119.85 ± 6.72 ms}}
Page size 10 Mb, waiting time 157.70 ± 15.35 ms
Page size 20 Mb, waiting time 204.50 ± 19.18 ms
Page size 50 Mb, waiting time 264.70 ± 22.30 ms
Page size 100 Mb, waiting time 463.35 ± 17.12 ms
Page size 150 Mb, waiting time 672.50 ± 21.98 ms
As result we spend ~4ms per every megabyte on _something_. It means that we
will be able to achieve 250Mb/s throughput in best case. It's too slow, isn't
it?
> Investigate ability to make ScanQuery faster
>
>
> Key: IGNITE-9432
> URL: https://issues.apache.org/jira/browse/IGNITE-9432
> Project: Ignite
> Issue Type: Improvement
> Components: ml
>Affects Versions: 2.7
>Reporter: Anton Dmitriev
>Priority: Major
> Fix For: 2.7
>
>
> When we make ScanQuery via Binary Client Protocol it works very slowly in
> case we need to retrieve a big amount of objects (all objects in our case).
> The most slower part is a waiting for response from Apache Ignite. This also
> mentioned on devlist
> [http://apache-ignite-developers.2346864.n4.nabble.com/How-to-reduce-Scan-Query-execution-time-td34212.html].
> To reproduce the problem we've prepared a small example:
> [slow-scan-query-reproducer|https://github.com/dmitrievanthony/slow-scan-query-reproducer].
> In this example we creates a cache with 500 objects 1Mb each (on localhost),
> we make ScanQuery with different page sizes and calculate time between the
> moment when the request has been sent and the moment when the response is
> ready to be receive. The measurements are here:
> Page size 5 Mb, waiting time 119.85 ± 6.72 ms
> Page size 10 Mb, waiting time 157.70 ± 15.35 ms
> Page size 20 Mb, waiting time 204.50 ± 19.18 ms
> Page size 50 Mb, waiting time 264.70 ± 22.30 ms
> Page size 100 Mb, waiting time 463.35 ± 17.12 ms
> Page size 150 Mb, waiting time 672.50 ± 21.98 ms
> As result we spend ~4ms per every megabyte on _something_. It means that we
> will be able to achieve 250Mb/s throughput in best case. It's too slow, isn't
> it?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9432) Investigate ability to make ScanQuery faster
[
https://issues.apache.org/jira/browse/IGNITE-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Dmitriev updated IGNITE-9432:
---
Description:
When we make ScanQuery via Binary Client Protocol it works very slowly in case
we need to retrieve a big amount of objects (all objects in our case). The most
slower part is a waiting for response from Apache Ignite. This also mentioned
on devlist
[http://apache-ignite-developers.2346864.n4.nabble.com/How-to-reduce-Scan-Query-execution-time-td34212.html].
To reproduce the problem we've prepared a small example:
[slow-scan-query-reproducer|https://github.com/dmitrievanthony/slow-scan-query-reproducer].
In this example we creates a cache with 500 objects 1Mb each (on localhost),
we make ScanQuery with different page sizes and calculate time between the
moment when the request has been sent and the moment when the response is ready
to be receive. The measurements are here:
{{Page size 5 Mb, waiting time 119.85 ± 6.72 ms}}
Page size 10 Mb, waiting time 157.70 ± 15.35 ms
Page size 20 Mb, waiting time 204.50 ± 19.18 ms
Page size 50 Mb, waiting time 264.70 ± 22.30 ms
Page size 100 Mb, waiting time 463.35 ± 17.12 ms
Page size 150 Mb, waiting time 672.50 ± 21.98 ms
As result we spend ~4ms per every megabyte on _something_. It means that we
will be able to achieve 250Mb/s throughput in best case. It's too slow, isn't
it?
was:
When we make ScanQuery via Binary Client Protocol it works very slowly in case
we need to retrieve a big amount of objects (all objects in our case). The most
slower part is a waiting for response from Apache Ignite. This also mentioned
on devlist
[http://apache-ignite-developers.2346864.n4.nabble.com/How-to-reduce-Scan-Query-execution-time-td34212.html].
To reproduce the problem we've prepared a small example:
[slow-scan-query-reproducer|https://github.com/dmitrievanthony/slow-scan-query-reproducer].
In this example we creates a cache with 500 objects 1Mb each (on localhost),
we make ScanQuery with different page sizes and calculate time between the
moment when the request has been sent and the moment when the response is ready
to be receive. The measurements are here:
{{Page size 5 Mb, waiting time 119.85 ± 6.72 ms}}
{{ Page size 10 Mb, waiting time 157.70 ± 15.35 ms}}
{{ Page size 20 Mb, waiting time 204.50 ± 19.18 ms}}
{{ Page size 50 Mb, waiting time 264.70 ± 22.30 ms}}
{{ Page size 100 Mb, waiting time 463.35 ± 17.12 ms}}
{{ Page size 150 Mb, waiting time 672.50 ± 21.98 ms}}
As result we spend ~4ms per every megabyte on _something_. It means that we
will be able to achieve 250Mb/s throughput in best case. It's too slow, isn't
it?
> Investigate ability to make ScanQuery faster
>
>
> Key: IGNITE-9432
> URL: https://issues.apache.org/jira/browse/IGNITE-9432
> Project: Ignite
> Issue Type: Improvement
> Components: ml
>Affects Versions: 2.7
>Reporter: Anton Dmitriev
>Priority: Major
> Fix For: 2.7
>
>
> When we make ScanQuery via Binary Client Protocol it works very slowly in
> case we need to retrieve a big amount of objects (all objects in our case).
> The most slower part is a waiting for response from Apache Ignite. This also
> mentioned on devlist
> [http://apache-ignite-developers.2346864.n4.nabble.com/How-to-reduce-Scan-Query-execution-time-td34212.html].
> To reproduce the problem we've prepared a small example:
> [slow-scan-query-reproducer|https://github.com/dmitrievanthony/slow-scan-query-reproducer].
> In this example we creates a cache with 500 objects 1Mb each (on localhost),
> we make ScanQuery with different page sizes and calculate time between the
> moment when the request has been sent and the moment when the response is
> ready to be receive. The measurements are here:
> {{Page size 5 Mb, waiting time 119.85 ± 6.72 ms}}
> Page size 10 Mb, waiting time 157.70 ± 15.35 ms
> Page size 20 Mb, waiting time 204.50 ± 19.18 ms
> Page size 50 Mb, waiting time 264.70 ± 22.30 ms
> Page size 100 Mb, waiting time 463.35 ± 17.12 ms
> Page size 150 Mb, waiting time 672.50 ± 21.98 ms
> As result we spend ~4ms per every megabyte on _something_. It means that we
> will be able to achieve 250Mb/s throughput in best case. It's too slow, isn't
> it?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9432) Investigate ability to make ScanQuery faster
Anton Dmitriev created IGNITE-9432:
--
Summary: Investigate ability to make ScanQuery faster
Key: IGNITE-9432
URL: https://issues.apache.org/jira/browse/IGNITE-9432
Project: Ignite
Issue Type: Improvement
Components: ml
Affects Versions: 2.7
Reporter: Anton Dmitriev
Fix For: 2.7
When we make ScanQuery via Binary Client Protocol it works very slowly in case
we need to retrieve a big amount of objects (all objects in our case). The most
slower part is a waiting for response from Apache Ignite. This also mentioned
on devlist
[http://apache-ignite-developers.2346864.n4.nabble.com/How-to-reduce-Scan-Query-execution-time-td34212.html].
To reproduce the problem we've prepared a small example:
[slow-scan-query-reproducer|https://github.com/dmitrievanthony/slow-scan-query-reproducer].
In this example we creates a cache with 500 objects 1Mb each (on localhost),
we make ScanQuery with different page sizes and calculate time between the
moment when the request has been sent and the moment when the response is ready
to be receive. The measurements are here:
{{Page size 5 Mb, waiting time 119.85 ± 6.72 ms}}
{{ Page size 10 Mb, waiting time 157.70 ± 15.35 ms}}
{{ Page size 20 Mb, waiting time 204.50 ± 19.18 ms}}
{{ Page size 50 Mb, waiting time 264.70 ± 22.30 ms}}
{{ Page size 100 Mb, waiting time 463.35 ± 17.12 ms}}
{{ Page size 150 Mb, waiting time 672.50 ± 21.98 ms}}
As result we spend ~4ms per every megabyte on _something_. It means that we
will be able to achieve 250Mb/s throughput in best case. It's too slow, isn't
it?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9420) Move logical recovery phase outside of PME
[ https://issues.apache.org/jira/browse/IGNITE-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko updated IGNITE-9420: Issue Type: Improvement (was: Bug) > Move logical recovery phase outside of PME > -- > > Key: IGNITE-9420 > URL: https://issues.apache.org/jira/browse/IGNITE-9420 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Priority: Major > Fix For: 2.7 > > > Currently, we perform logical recovery in PME here > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#restoreState > We should move logical recovery before discovery manager will start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9165) FindBugs: Methods may fail to close stream in core module
[
https://issues.apache.org/jira/browse/IGNITE-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597361#comment-16597361
]
Denis Garus commented on IGNITE-9165:
-
LGTM
> FindBugs: Methods may fail to close stream in core module
> -
>
> Key: IGNITE-9165
> URL: https://issues.apache.org/jira/browse/IGNITE-9165
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie
> Fix For: 2.7
>
> Attachments:
> findbugs-result-apache-ignite[ignite-core]_2018_08_02_12_38_02.html
>
>
> The method creates an IO stream object, does not assign it to any fields,
> pass it to other methods that might close it, or return it, and does not
> appear to close the stream on all paths out of the method. This may result
> in a file descriptor leak.
> Example:
>
> {code:java}
> // GridCacheAbstractLoadTest#GridCacheAbstractLoadTest()
> try {
> props.load(new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties")));
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
>
> One of possible solutions:
> {code:java}
> try (Reader reader = new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties"))) {
> props.load(reader);
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
> List of classes in "core" module:
>
> +org.apache.ignite.internal:+
> * *BinaryContext*#classesInPackage(String)
> * *GridClientJdkMarshaller*#marshal(Object, int)
> *
> *IgniteExplicitImplicitDeploymentSelfTest*$GridDeploymentResourceTestJob#execute()
> * *OptimizedObjectStreamSelfTest*#testReadLine()
> * *PageIdDistributionTest*#_testRealHistory()
> * *HttpIgniteUpdatesChecker*#getUpdates(boolean)
> * *IpcSharedMemoryNativeLoaderSelfTest*#readStreams(Process)
> +org.apache.ignite:+
> * *GridCacheAbstractLoadTest*#GridCacheAbstractLoadTest()
> * *GridTestUtils*.sslContext()
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8286) ScanQuery ignore setLocal with non local partition
[ https://issues.apache.org/jira/browse/IGNITE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597347#comment-16597347 ] Ilya Lantukh commented on IGNITE-8286: -- [~roman_s], thanks! There is still one minor issue - new field is now immutable, but is still marked as *volatile* instead of *final*. > ScanQuery ignore setLocal with non local partition > -- > > Key: IGNITE-8286 > URL: https://issues.apache.org/jira/browse/IGNITE-8286 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Alexander Belyak >Assignee: Roman Shtykh >Priority: Major > Fix For: 2.7 > > > 1) Create partitioned cache on 2+ nodes cluster > 2) Select some partition N, local node should not be OWNER of partition N > 3) execute: cache.query(new ScanQuery<>().setLocal(true).setPartition(N)) > Expected result: > empty result (probaply with logging smth like "Trying to execute local query > with non local partition N") or even throw exception > Actual result: > executing (with ScanQueryFallbackClosableIterator) query on remote node. > Problem is that we execute local query on remote node. > Same behaviour can be achieved if we get empty node list from > GridCacheQueryAdapter.node() by any reasons, for example - if we run "local" > query from non data node from given cache (see > GridDiscoveryNamager.cacheAffinityNode(ClusterNode node, String cacheName) in > GridcacheQueryAdapter.executeScanQuery() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8158) Missed cleanups if afterTestsStop throws exception
[
https://issues.apache.org/jira/browse/IGNITE-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597341#comment-16597341
]
Maxim Muzafarov commented on IGNITE-8158:
-
[~zzzadruga],
Thank you for providing `StopAllGridsTest.java` example, it helped a lot.
Changes looks good to me.
[~northdragon],
Can you please look at this issue too?
> Missed cleanups if afterTestsStop throws exception
> --
>
> Key: IGNITE-8158
> URL: https://issues.apache.org/jira/browse/IGNITE-8158
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Maxim Muzafarov
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie, test
> Fix For: 2.7
>
> Attachments: StopAllGridsTest.java
>
>
> Method {{afterTestsStopped}} might throw exception. Contibutor should provide
> solution for ensuring that all cleanups in {{tearDown}} method would be
> executed in this case.
> {code:java|title=GridAbstractTest.java}
> /** {@inheritDoc} */
> @Override protected void tearDown() throws Exception {
> ...
> try {
> afterTest();
> }
> finally {
> serializedObj.clear();
> if (isLastTest()) {
> ...
> afterTestsStopped();
> if (startGrid)
> G.stop(getTestIgniteInstanceName(), true);
> // Remove counters.
> tests.remove(getClass());
> // Remove resources cached in static, if any.
> GridClassLoaderCache.clear();
> U.clearClassCache();
> MarshallerExclusions.clearCache();
> BinaryEnumCache.clear();
> }
> Thread.currentThread().setContextClassLoader(clsLdr);
> clsLdr = null;
> cleanReferences();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8886) Simultaneous using of BinaryWriter и BinaryRawWriter leads to BinaryObjectException and OOM
[
https://issues.apache.org/jira/browse/IGNITE-8886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597339#comment-16597339
]
Evgenii Zhuravlev commented on IGNITE-8886:
---
[~ilyak], Thank you for the screenshot with an example, change looks good to me.
> Simultaneous using of BinaryWriter и BinaryRawWriter leads to
> BinaryObjectException and OOM
> ---
>
> Key: IGNITE-8886
> URL: https://issues.apache.org/jira/browse/IGNITE-8886
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.5
>Reporter: Roman Guseinov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: binary
> Attachments: BinarylizableInvalidFlag.java, BinarylizableOOM.java,
> Screenshot_20180830_142433.png
>
>
> When we use BinaryWriter and BinaryRawWriter simultaneously inside
> writeBinary method we can get the following exceptions in the process of
> deserializing objects:
> 1. class org.apache.ignite.binary.BinaryObjectException: Invalid flag value:
> 115
> {code:java}
> Exception in thread "main" javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> [typeName=org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag$TestBean]
>at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1302)
>at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1732)
>at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:910)
>at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:608)
>at
> org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag.main(BinarylizableInvalidFlag.java:33)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> deserialize object
> [typeName=org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag$TestBean]
>at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7322)
>at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
>at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:171)
>at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
>at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4563)
>at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4537)
>at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1350)
>at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:907)
>... 2 more
> Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to
> deserialize object
> [typeName=org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag$TestBean]
>at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:909)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
>at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:798)
>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.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1764)
>at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1752)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:679)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.localGet(GridPartitionedSingleGetFuture.java:461)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:342)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:216)
>at
[jira] [Updated] (IGNITE-8886) Simultaneous using of BinaryWriter и BinaryRawWriter leads to BinaryObjectException and OOM
[
https://issues.apache.org/jira/browse/IGNITE-8886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-8886:
Attachment: Screenshot_20180830_142433.png
> Simultaneous using of BinaryWriter и BinaryRawWriter leads to
> BinaryObjectException and OOM
> ---
>
> Key: IGNITE-8886
> URL: https://issues.apache.org/jira/browse/IGNITE-8886
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.5
>Reporter: Roman Guseinov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: binary
> Attachments: BinarylizableInvalidFlag.java, BinarylizableOOM.java,
> Screenshot_20180830_142433.png
>
>
> When we use BinaryWriter and BinaryRawWriter simultaneously inside
> writeBinary method we can get the following exceptions in the process of
> deserializing objects:
> 1. class org.apache.ignite.binary.BinaryObjectException: Invalid flag value:
> 115
> {code:java}
> Exception in thread "main" javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> [typeName=org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag$TestBean]
>at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1302)
>at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1732)
>at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:910)
>at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:608)
>at
> org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag.main(BinarylizableInvalidFlag.java:33)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> deserialize object
> [typeName=org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag$TestBean]
>at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7322)
>at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
>at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:171)
>at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
>at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4563)
>at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4537)
>at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1350)
>at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:907)
>... 2 more
> Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to
> deserialize object
> [typeName=org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag$TestBean]
>at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:909)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
>at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:798)
>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.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1764)
>at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1752)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:679)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.localGet(GridPartitionedSingleGetFuture.java:461)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:342)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:216)
>at
>
[jira] [Commented] (IGNITE-8886) Simultaneous using of BinaryWriter и BinaryRawWriter leads to BinaryObjectException and OOM
[
https://issues.apache.org/jira/browse/IGNITE-8886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597334#comment-16597334
]
Ilya Kasnacheev commented on IGNITE-8886:
-
!Screenshot_20180830_142433.png!
> Simultaneous using of BinaryWriter и BinaryRawWriter leads to
> BinaryObjectException and OOM
> ---
>
> Key: IGNITE-8886
> URL: https://issues.apache.org/jira/browse/IGNITE-8886
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.5
>Reporter: Roman Guseinov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: binary
> Attachments: BinarylizableInvalidFlag.java, BinarylizableOOM.java,
> Screenshot_20180830_142433.png
>
>
> When we use BinaryWriter and BinaryRawWriter simultaneously inside
> writeBinary method we can get the following exceptions in the process of
> deserializing objects:
> 1. class org.apache.ignite.binary.BinaryObjectException: Invalid flag value:
> 115
> {code:java}
> Exception in thread "main" javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> [typeName=org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag$TestBean]
>at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1302)
>at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1732)
>at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:910)
>at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:608)
>at
> org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag.main(BinarylizableInvalidFlag.java:33)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> deserialize object
> [typeName=org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag$TestBean]
>at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7322)
>at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
>at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:171)
>at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
>at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4563)
>at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4537)
>at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1350)
>at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:907)
>... 2 more
> Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to
> deserialize object
> [typeName=org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag$TestBean]
>at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:909)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
>at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:798)
>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.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1764)
>at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1752)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:679)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.localGet(GridPartitionedSingleGetFuture.java:461)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:342)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:216)
>at
>
[jira] [Commented] (IGNITE-9160) FindBugs: NPE and CCE on equals() methods
[
https://issues.apache.org/jira/browse/IGNITE-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597325#comment-16597325
]
Denis Garus commented on IGNITE-9160:
-
GTM
> FindBugs: NPE and CCE on equals() methods
> -
>
> Key: IGNITE-9160
> URL: https://issues.apache.org/jira/browse/IGNITE-9160
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie
> Fix For: 2.7
>
>
> Some classes have Incorrect equals() method:
> {code:java}
> // GridDhtPartitionMap.java
> @Override public boolean equals(Object o) {
> if (this == o)
> return true;
> GridDhtPartitionMap other = (GridDhtPartitionMap)o;
> return other.nodeId.equals(nodeId) && other.updateSeq == updateSeq;
> }{code}
> In this case, we can get CCE
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(new Object());
> --
> Exception in thread "main" java.lang.ClassCastException: java.lang.Object
> cannot be cast to
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:319)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
> Or NPE
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(null);
> --
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:321)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
> The following code will prevent this
> {code:java}
> if (o == null || getClass() != o.getClass())
> return false;{code}
> + List of classes with similar problems: +
> * *GridTopic$T1-T8* - NPE
> * *GridCachePreloadLifecycleAbstractTest -* NPE
> * *GridDhtPartitionFullMap -* NPE and CCE
> * *GridDhtPartitionMap -* NPE and CCE
> * *OptimizedMarshallerSelfTest -* NPE and CCE
> * *GatewayProtectedCacheProxy -* NPE and CCE
> * *GridNearOptimisticTxPrepareFuture -* NPE and CCE
> * *GridCacheDistributedQueryManager -* NPE and CCE
> * *GridServiceMethodReflectKey -* NPE and CCE
> * *GridListSetSelfTest -* NPE and CCE
> * *GridTestKey -* NPE and CCE
> * *GridCacheMvccCandidate -* CCE
> * *GridDhtPartitionExchangeId -* CCE
> * *GridTuple6 -* CCE
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-9370) Web console: Failed to open demo for Queries page.
[
https://issues.apache.org/jira/browse/IGNITE-9370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov closed IGNITE-9370.
--
Merged to master.
> Web console: Failed to open demo for Queries page.
> --
>
> Key: IGNITE-9370
> URL: https://issues.apache.org/jira/browse/IGNITE-9370
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Andrey Novikov
>Priority: Major
>
> On opening of Queries page in Demo mode only error is shown:
> {code:java}
> Invalid format of message: "node:rest"{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9431) Documentation for zk paths used by ZookeeperDiscovery.
Stanilovsky Evgeny created IGNITE-9431: -- Summary: Documentation for zk paths used by ZookeeperDiscovery. Key: IGNITE-9431 URL: https://issues.apache.org/jira/browse/IGNITE-9431 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 2.6 Reporter: Stanilovsky Evgeny Assignee: Artem Budnikov I found that under /apacheIgnite zk directory, there are also: /jd, /ce, /cp, /ca and some other dirs, from source i found that they take place from : org.apache.ignite.spi.discovery.zk.internal.ZkIgnitePaths. Plz document this paths purpose. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9068) Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed inside guard()/unguard()
[
https://issues.apache.org/jira/browse/IGNITE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597301#comment-16597301
]
Alexey Goncharuk commented on IGNITE-9068:
--
[~ilantukh] Let's add diagnostic information about the threads that are holding
read locks if we fail to acquire the write lock for a long time.
> Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed
> inside guard()/unguard()
> -
>
> Key: IGNITE-9068
> URL: https://issues.apache.org/jira/browse/IGNITE-9068
> Project: Ignite
> Issue Type: Bug
> Components: binary, managed services
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Lantukh
>Priority: Blocker
> Labels: test
> Fix For: 2.7
>
> Attachments: GridServiceDeadlockTest.java, MyService.java
>
>
> When addMeta is called in e.g. service deployment it us executed inside
> guard()/unguard()
> If node will be stopped at this point, Ignite.stop() will hang.
> Consider the following thread dump:
> {code}
> "Thread-1" #57 prio=5 os_prio=0 tid=0x7f7780005000 nid=0x7f26 runnable
> [0x7f766cbef000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0005cb7b0468> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.tryLock(ReentrantReadWriteLock.java:1115)
> at
> org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.tryLock(StripedCompositeReadWriteLock.java:220)
> at
> org.apache.ignite.internal.GridKernalGatewayImpl.tryWriteLock(GridKernalGatewayImpl.java:143)
> // Waiting for lock to cancel futures of BinaryMetadataTransport
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2171)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
> - locked <0x0005cb423f00> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:2033)
> "test-runner-#1%service.GridServiceDeadlockTest%" #13 prio=5 os_prio=0
> tid=0x7f77b87d5800 nid=0x7eb8 waiting on condition [0x7f778cdfc000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> // May never return if there's discovery problems
> 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.addMeta(CacheObjectBinaryProcessorImpl.java:463)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:188)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:802)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:761)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:627)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:174)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:157)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:144)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:82)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10069)
> at
>
[jira] [Assigned] (IGNITE-9428) MVCC TX: Multiple H2ResultSetIterator closing leads to assertion in MvccProcessor
[
https://issues.apache.org/jira/browse/IGNITE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov reassigned IGNITE-9428:
Assignee: Andrew Mashenkov
> MVCC TX: Multiple H2ResultSetIterator closing leads to assertion in
> MvccProcessor
> -
>
> Key: IGNITE-9428
> URL: https://issues.apache.org/jira/browse/IGNITE-9428
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
>
> Due to [IGNITE-9256|https://issues.apache.org/jira/browse/IGNITE-9256] patch,
> multiple {{H2ResultSetIterator#onClose}} invocation becomes possible. This
> can be considered as a {{Closable}} contract violation and should be fixed.
> Also this case revealed a bug in {{MvccQueryTrackerImpl}} when multiple
> {{onDone()}} call leads to multiple query finished acks sent back to the
> {{MvccCoordinator}} which leads to the problems with the query tracking and
> assertion errors.
> Reproducer:
> {{CacheMvccSqlTxQueriesAbstractTest#testAccountsTxDmlSumSql_WithRemoves_SingleNode}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9430) Add ability to override all caches's "rebalanceThrottle" option via JVM node option
[ https://issues.apache.org/jira/browse/IGNITE-9430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ARomantsov updated IGNITE-9430: --- Description: I found ability to set rebalanceThrottle option for any cache , but can we have JVM key for override that parameter for all caches at once (was: I found ability to set rebalanceThrottle option for any cache , but can we have JVM key for override that parameter for all cache at once) > Add ability to override all caches's "rebalanceThrottle" option via JVM node > option > > > Key: IGNITE-9430 > URL: https://issues.apache.org/jira/browse/IGNITE-9430 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.5 >Reporter: ARomantsov >Priority: Major > Fix For: 2.7 > > > I found ability to set rebalanceThrottle option for any cache , but can we > have JVM key for override that parameter for all caches at once -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9430) Add ability to override all caches's "rebalanceThrottle" option via JVM node option
ARomantsov created IGNITE-9430: -- Summary: Add ability to override all caches's "rebalanceThrottle" option via JVM node option Key: IGNITE-9430 URL: https://issues.apache.org/jira/browse/IGNITE-9430 Project: Ignite Issue Type: Improvement Components: general Affects Versions: 2.5 Reporter: ARomantsov Fix For: 2.7 I found ability to set rebalanceThrottle option for any cache , but can we have JVM key for override that parameter for all cache at once -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9427) SQL MVCC: old data read after parallel update with autoCommit=false
[
https://issues.apache.org/jira/browse/IGNITE-9427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597279#comment-16597279
]
Stepan Pilschikov commented on IGNITE-9427:
---
Close ticket
Don't mind of REPEATABLE_READ
If *user_1* make *update* then updated data from *user_2* has come
> SQL MVCC: old data read after parallel update with autoCommit=false
>
>
> Key: IGNITE-9427
> URL: https://issues.apache.org/jira/browse/IGNITE-9427
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.5
>Reporter: Stepan Pilschikov
>Priority: Major
>
> Second user don't seeing first user update right after select before commit
> Table:
> {code:sql}create table test(id int, field_int int, field_var varchar(50),
> primary key (id, field_int)) with "template=replicated,
> ATOMICITY=TRANSACTIONAL{code}
> With one row of data:
> {code:sql}insert into test(id, field_int, field_var) values (1, 1,
> 'test_1'){code}
> With two connections to sqlline
> {code}sqlline.sh --autoCommit=false --color=true --outputFormat=csv
> --showNestedErrs=true --showWarnings=true --verbose=true -u
> jdbc:ignite:thin://127.0.0.1:10800 {code}
> for *user_1* and *user_2*
> *user_1*:
> {code:sql}
> begin transaction;
> select * from test where id = 1 for update;
> {code}
> *user_2*:
> {code:sql}
> update test set field_var = 'updated' where id = 1; - transaction get locked
> {code}
> *user_1*:
> {code:sql}
> commit;
> select * from test; - 1, 1, 'test_1'
> {code}
> *user_2*:
> {code:sql}
> 1 row affected
> commit;
> select * from test; - 1, 1, 'updated'
> {code}
> *user_1*:
> {code:sql}
> select * from test; - 1, 1, 'test_1' < should be 'updated'
> {code}
> if *user_1* do commit then he will be seeing update
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-9427) SQL MVCC: old data read after parallel update with autoCommit=false
[
https://issues.apache.org/jira/browse/IGNITE-9427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stepan Pilschikov closed IGNITE-9427.
-
Ignite Flags: (was: Docs Required)
> SQL MVCC: old data read after parallel update with autoCommit=false
>
>
> Key: IGNITE-9427
> URL: https://issues.apache.org/jira/browse/IGNITE-9427
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.5
>Reporter: Stepan Pilschikov
>Priority: Major
>
> Second user don't seeing first user update right after select before commit
> Table:
> {code:sql}create table test(id int, field_int int, field_var varchar(50),
> primary key (id, field_int)) with "template=replicated,
> ATOMICITY=TRANSACTIONAL{code}
> With one row of data:
> {code:sql}insert into test(id, field_int, field_var) values (1, 1,
> 'test_1'){code}
> With two connections to sqlline
> {code}sqlline.sh --autoCommit=false --color=true --outputFormat=csv
> --showNestedErrs=true --showWarnings=true --verbose=true -u
> jdbc:ignite:thin://127.0.0.1:10800 {code}
> for *user_1* and *user_2*
> *user_1*:
> {code:sql}
> begin transaction;
> select * from test where id = 1 for update;
> {code}
> *user_2*:
> {code:sql}
> update test set field_var = 'updated' where id = 1; - transaction get locked
> {code}
> *user_1*:
> {code:sql}
> commit;
> select * from test; - 1, 1, 'test_1'
> {code}
> *user_2*:
> {code:sql}
> 1 row affected
> commit;
> select * from test; - 1, 1, 'updated'
> {code}
> *user_1*:
> {code:sql}
> select * from test; - 1, 1, 'test_1' < should be 'updated'
> {code}
> if *user_1* do commit then he will be seeing update
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-9427) SQL MVCC: old data read after parallel update with autoCommit=false
[
https://issues.apache.org/jira/browse/IGNITE-9427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stepan Pilschikov resolved IGNITE-9427.
---
Resolution: Not A Problem
> SQL MVCC: old data read after parallel update with autoCommit=false
>
>
> Key: IGNITE-9427
> URL: https://issues.apache.org/jira/browse/IGNITE-9427
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.5
>Reporter: Stepan Pilschikov
>Priority: Major
>
> Second user don't seeing first user update right after select before commit
> Table:
> {code:sql}create table test(id int, field_int int, field_var varchar(50),
> primary key (id, field_int)) with "template=replicated,
> ATOMICITY=TRANSACTIONAL{code}
> With one row of data:
> {code:sql}insert into test(id, field_int, field_var) values (1, 1,
> 'test_1'){code}
> With two connections to sqlline
> {code}sqlline.sh --autoCommit=false --color=true --outputFormat=csv
> --showNestedErrs=true --showWarnings=true --verbose=true -u
> jdbc:ignite:thin://127.0.0.1:10800 {code}
> for *user_1* and *user_2*
> *user_1*:
> {code:sql}
> begin transaction;
> select * from test where id = 1 for update;
> {code}
> *user_2*:
> {code:sql}
> update test set field_var = 'updated' where id = 1; - transaction get locked
> {code}
> *user_1*:
> {code:sql}
> commit;
> select * from test; - 1, 1, 'test_1'
> {code}
> *user_2*:
> {code:sql}
> 1 row affected
> commit;
> select * from test; - 1, 1, 'updated'
> {code}
> *user_1*:
> {code:sql}
> select * from test; - 1, 1, 'test_1' < should be 'updated'
> {code}
> if *user_1* do commit then he will be seeing update
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9411) Lock: make sure lock timeouts works fine
[
https://issues.apache.org/jira/browse/IGNITE-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597270#comment-16597270
]
Ivan Pavlukhin commented on IGNITE-9411:
Locks are handled similarly for following SQL statements: {{INSERT, MERGE,
UPDATE, DELETE, SELECT ... FOR UPDATE}}. Here is the procedure:
_Check if row is already locked. If locked wait lock release. Otherwise place
own lock. Locks are released upon transaction end._
Lock waiting should support timeout. If timeout exceeds transaction should be
marked _rollback-only_. Timeout can be specified per statement or per
transaction.
> Lock: make sure lock timeouts works fine
>
>
> Key: IGNITE-9411
> URL: https://issues.apache.org/jira/browse/IGNITE-9411
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.7
>
>
> In SQL it is not uncommon that locks are taken in arbitrary order, what may
> lead to deadlocks. Fair deadlock detector is good solution in monolithic
> databases - just analyze dependency graph and kill one of conflicting
> transactions.
> We have a ticket to implement distributed deadlock detector in Ignite [1].
> However, this solution is rather complex and may bring some overhead.
> For now it is better to rely on some timeout (global or per-transaction), and
> rollback TX when it fails to lock certain entry for a long time. Probably we
> already have this feature in some form. Need to add verify that it works and
> add more tests if needed.
> [1] https://issues.apache.org/jira/browse/IGNITE-9322
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9273) Logical records are not WAL-logged for LOCAL caches
[ https://issues.apache.org/jira/browse/IGNITE-9273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9273: - Summary: Logical records are not WAL-logged for LOCAL caches (was: IgnitePdsDynamicCacheTest.testRestartAndCreate is very flaky in master) > Logical records are not WAL-logged for LOCAL caches > --- > > Key: IGNITE-9273 > URL: https://issues.apache.org/jira/browse/IGNITE-9273 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > IgnitePdsDynamicCacheTest.testRestartAndCreate is very flaky in master > because of this bug. > Such as: > https://ci.ignite.apache.org/viewLog.html?buildId=1655341=buildResultsDiv=IgniteTests24Java8_Pds1 > https://ci.ignite.apache.org/viewLog.html?buildId=1655880=buildResultsDiv=IgniteTests24Java8_Pds1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9273) Logical records are not WAL-logged for LOCAL caches
[ https://issues.apache.org/jira/browse/IGNITE-9273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597257#comment-16597257 ] Alexey Goncharuk commented on IGNITE-9273: -- Changing the ticket name for easy further searches. > Logical records are not WAL-logged for LOCAL caches > --- > > Key: IGNITE-9273 > URL: https://issues.apache.org/jira/browse/IGNITE-9273 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > IgnitePdsDynamicCacheTest.testRestartAndCreate is very flaky in master > because of this bug. > Such as: > https://ci.ignite.apache.org/viewLog.html?buildId=1655341=buildResultsDiv=IgniteTests24Java8_Pds1 > https://ci.ignite.apache.org/viewLog.html?buildId=1655880=buildResultsDiv=IgniteTests24Java8_Pds1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9273) IgnitePdsDynamicCacheTest.testRestartAndCreate is very flaky in master
[ https://issues.apache.org/jira/browse/IGNITE-9273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9273: - Description: IgnitePdsDynamicCacheTest.testRestartAndCreate is very flaky in master because of this bug. Such as: https://ci.ignite.apache.org/viewLog.html?buildId=1655341=buildResultsDiv=IgniteTests24Java8_Pds1 https://ci.ignite.apache.org/viewLog.html?buildId=1655880=buildResultsDiv=IgniteTests24Java8_Pds1 was: Such as: https://ci.ignite.apache.org/viewLog.html?buildId=1655341=buildResultsDiv=IgniteTests24Java8_Pds1 https://ci.ignite.apache.org/viewLog.html?buildId=1655880=buildResultsDiv=IgniteTests24Java8_Pds1 > IgnitePdsDynamicCacheTest.testRestartAndCreate is very flaky in master > --- > > Key: IGNITE-9273 > URL: https://issues.apache.org/jira/browse/IGNITE-9273 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > IgnitePdsDynamicCacheTest.testRestartAndCreate is very flaky in master > because of this bug. > Such as: > https://ci.ignite.apache.org/viewLog.html?buildId=1655341=buildResultsDiv=IgniteTests24Java8_Pds1 > https://ci.ignite.apache.org/viewLog.html?buildId=1655880=buildResultsDiv=IgniteTests24Java8_Pds1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9429) GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange is flaky
[ https://issues.apache.org/jira/browse/IGNITE-9429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9429: - Description: Test fails with various exception, I see several issues: 1) Atomic structure is accessed during a node stop, which leads to NodeStoppingException (should be ignored) 2) Same race which leads to IllegalStateException: node is stopped 3) Invalid atomic integer increment which rarely leads to "Ignite instance with the same name has already been started" exception > GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange > is flaky > --- > > Key: IGNITE-9429 > URL: https://issues.apache.org/jira/browse/IGNITE-9429 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Test fails with various exception, I see several issues: > 1) Atomic structure is accessed during a node stop, which leads to > NodeStoppingException (should be ignored) > 2) Same race which leads to IllegalStateException: node is stopped > 3) Invalid atomic integer increment which rarely leads to "Ignite instance > with the same name has already been started" exception -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9429) GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange is flaky
[ https://issues.apache.org/jira/browse/IGNITE-9429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9429: - Fix Version/s: 2.7 > GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange > is flaky > --- > > Key: IGNITE-9429 > URL: https://issues.apache.org/jira/browse/IGNITE-9429 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9429) GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange is flaky
[ https://issues.apache.org/jira/browse/IGNITE-9429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9429: - Labels: MakeTeamcityGreenAgain (was: ) > GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange > is flaky > --- > > Key: IGNITE-9429 > URL: https://issues.apache.org/jira/browse/IGNITE-9429 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
