[jira] [Created] (IGNITE-11897) Use `bytearray` as a Python type for Ignite `ByteArray`
Dmitry Melnichuk created IGNITE-11897: - Summary: Use `bytearray` as a Python type for Ignite `ByteArray` Key: IGNITE-11897 URL: https://issues.apache.org/jira/browse/IGNITE-11897 Project: Ignite Issue Type: Improvement Components: thin client Reporter: Dmitry Melnichuk Assignee: Dmitry Melnichuk This optimization will allow client to read and write `ByteArray` values without iterating over single bytes, thereby improving performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11784) Replace TcpDiscoveryNode to nodeId in TcpDiscoveryMessages
[
https://issues.apache.org/jira/browse/IGNITE-11784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov reassigned IGNITE-11784:
-
Assignee: Denis Chudov (was: Sergey Antonov)
> Replace TcpDiscoveryNode to nodeId in TcpDiscoveryMessages
> --
>
> Key: IGNITE-11784
> URL: https://issues.apache.org/jira/browse/IGNITE-11784
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
>
> {{TcpDiscoveryDuplicateIdMessage}} and {{TcpDiscoveryStatusCheckMessage}}
> have TcpDiscoveryNode field. TcpDiscoveryNode could be huge object due to
> node attributes. We could sent only nodeId and get TcpDiscoveryNode from
> {{TcpDiscoveryNodesRing}} on target node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11895) .NET Resharper inspections got broken after update
[
https://issues.apache.org/jira/browse/IGNITE-11895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856778#comment-16856778
]
Ignite TC Bot commented on IGNITE-11895:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4047709]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 3 TIMEOUT
|https://ci.ignite.apache.org/viewLog.html?buildId=4047716]]
{color:#d04437}Platform .NET{color} [[tests 0 TIMEOUT
|https://ci.ignite.apache.org/viewLog.html?buildId=4047715]]
{color:#d04437}Scala (Examples){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=4047665]]
* ScalarExamplesSelfTestSuite:
ScalarExamplesMultiNodeSelfTest.initializationError
* ScalarExamplesSelfTestSuite: ScalarExamplesSelfTest.initializationError
{color:#d04437}[Check Code Style]{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4047743]]
{color:#d04437}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4047672]]
* IgniteBasicTestSuite:
DynamicProxySerializationMultiJvmSelfTest.testBinaryMarshaller
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4047744buildTypeId=IgniteTests24Java8_RunAll]
> .NET Resharper inspections got broken after update
> --
>
> Key: IGNITE-11895
> URL: https://issues.apache.org/jira/browse/IGNITE-11895
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.7
>Reporter: Alexandr Shapkin
>Assignee: Alexandr Shapkin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Resharper Inspection add new violation after migration from 2018.1.4 to
> version 2019.1
> Lets suppress this new warning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11857) Investigate performance drop after IGNITE-10078
[ https://issues.apache.org/jira/browse/IGNITE-11857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856759#comment-16856759 ] Aleksey Plekhanov commented on IGNITE-11857: [~ustas], [~ascherbakov] do you have any new results? What branches have you compared when getting performance drop? > Investigate performance drop after IGNITE-10078 > --- > > Key: IGNITE-11857 > URL: https://issues.apache.org/jira/browse/IGNITE-11857 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Aleksey Plekhanov >Priority: Major > Attachments: ignite-config.xml, > run.properties.tx-optimistic-put-b-backup > > > After IGNITE-10078 yardstick tests show performance drop up to 8% in some > scenarios: > * tx-optim-repRead-put-get > * tx-optimistic-put > * tx-putAll > Partially this is due new update counter implementation, but not only. > Investigation is required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10801) Upgrade H2 version up to 1.4.199
[ https://issues.apache.org/jira/browse/IGNITE-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10801: -- Ignite Flags: (was: Docs Required) > Upgrade H2 version up to 1.4.199 > > > Key: IGNITE-10801 > URL: https://issues.apache.org/jira/browse/IGNITE-10801 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Antonov >Priority: Critical > Labels: sql > Fix For: 2.8 > > > After h2 1.4.199 release we should upgrade h2 version using in AI, because of > important bugs will be fixed there. For example > https://github.com/h2database/h2database/issues/1057 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10801) Upgrade H2 version up to 1.4.199
[ https://issues.apache.org/jira/browse/IGNITE-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10801: -- Description: After h2 1.4.199 release we should upgrade h2 version using in AI, because of important bugs will be fixed there. For example https://github.com/h2database/h2database/issues/1057 (was: After h2 1.4.198 release we should upgrade h2 version using in AI, because of important bugs will be fixed there. For example https://github.com/h2database/h2database/issues/1057) > Upgrade H2 version up to 1.4.199 > > > Key: IGNITE-10801 > URL: https://issues.apache.org/jira/browse/IGNITE-10801 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Antonov >Priority: Critical > Labels: sql > Fix For: 2.8 > > > After h2 1.4.199 release we should upgrade h2 version using in AI, because of > important bugs will be fixed there. For example > https://github.com/h2database/h2database/issues/1057 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10801) Upgrade H2 version up to 1.4.199
[ https://issues.apache.org/jira/browse/IGNITE-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10801: -- Summary: Upgrade H2 version up to 1.4.199 (was: Upgrade H2 version up to 1.4.198) > Upgrade H2 version up to 1.4.199 > > > Key: IGNITE-10801 > URL: https://issues.apache.org/jira/browse/IGNITE-10801 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Antonov >Priority: Critical > Labels: sql > Fix For: 2.8 > > > After h2 1.4.198 release we should upgrade h2 version using in AI, because of > important bugs will be fixed there. For example > https://github.com/h2database/h2database/issues/1057 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11891) Multi-column index - query out of memory
[
https://issues.apache.org/jira/browse/IGNITE-11891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11891:
--
Labels: performance (was: )
> Multi-column index - query out of memory
>
>
> Key: IGNITE-11891
> URL: https://issues.apache.org/jira/browse/IGNITE-11891
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: João Fonseca
>Priority: Major
> Labels: performance
>
> My application uses a table for logging events. Something like:
>
> {noformat}
> create table event (
> id bigint not null,
> level varchar(8) not null,
> timestamp bigint not null,
> message varchar(4096) not null,
> primary key (id)
> ) ;
> {noformat}
> I have two indexes:
>
> {noformat}
> create index index_event_timestamp on event (timestamp desc)
> create index index_event_level on event (level, timestamp desc)
> {noformat}
> The idea is to support both the following queries:
>
> {noformat}
> select * from event order by timestamp desc limit 25
> select * from event where level = 'WARNING' order by timestamp desc limit 25
> {noformat}
> Once the table size increases to several million records, the second query
> generates OOM on the server. From what I can see (from the explain results),
> the index_event_level is used to fetch records with WARNING level, but the
> timestamp column available with the index is not used in the "order by"
> clause. The server attempts to fetch all records and then sort them by
> timestamp, despite the index already doing this...
> I removed the second index as a work-around, and the query runs faster on the
> first index - it scans index_event_timestamp, and retrieves the records with
> level=WARNING. It's smart to realize that the scan results are already sorted
> correctly.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11891) Multi-column index - query out of memory
[
https://issues.apache.org/jira/browse/IGNITE-11891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11891:
--
Ignite Flags: (was: Docs Required)
> Multi-column index - query out of memory
>
>
> Key: IGNITE-11891
> URL: https://issues.apache.org/jira/browse/IGNITE-11891
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: João Fonseca
>Priority: Major
>
> My application uses a table for logging events. Something like:
>
> {noformat}
> create table event (
> id bigint not null,
> level varchar(8) not null,
> timestamp bigint not null,
> message varchar(4096) not null,
> primary key (id)
> ) ;
> {noformat}
> I have two indexes:
>
> {noformat}
> create index index_event_timestamp on event (timestamp desc)
> create index index_event_level on event (level, timestamp desc)
> {noformat}
> The idea is to support both the following queries:
>
> {noformat}
> select * from event order by timestamp desc limit 25
> select * from event where level = 'WARNING' order by timestamp desc limit 25
> {noformat}
> Once the table size increases to several million records, the second query
> generates OOM on the server. From what I can see (from the explain results),
> the index_event_level is used to fetch records with WARNING level, but the
> timestamp column available with the index is not used in the "order by"
> clause. The server attempts to fetch all records and then sort them by
> timestamp, despite the index already doing this...
> I removed the second index as a work-around, and the query runs faster on the
> first index - it scans index_event_timestamp, and retrieves the records with
> level=WARNING. It's smart to realize that the scan results are already sorted
> correctly.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11891) Multi-column index - query out of memory
[
https://issues.apache.org/jira/browse/IGNITE-11891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11891:
--
Issue Type: Improvement (was: Bug)
> Multi-column index - query out of memory
>
>
> Key: IGNITE-11891
> URL: https://issues.apache.org/jira/browse/IGNITE-11891
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7
>Reporter: João Fonseca
>Priority: Major
> Labels: performance
>
> My application uses a table for logging events. Something like:
>
> {noformat}
> create table event (
> id bigint not null,
> level varchar(8) not null,
> timestamp bigint not null,
> message varchar(4096) not null,
> primary key (id)
> ) ;
> {noformat}
> I have two indexes:
>
> {noformat}
> create index index_event_timestamp on event (timestamp desc)
> create index index_event_level on event (level, timestamp desc)
> {noformat}
> The idea is to support both the following queries:
>
> {noformat}
> select * from event order by timestamp desc limit 25
> select * from event where level = 'WARNING' order by timestamp desc limit 25
> {noformat}
> Once the table size increases to several million records, the second query
> generates OOM on the server. From what I can see (from the explain results),
> the index_event_level is used to fetch records with WARNING level, but the
> timestamp column available with the index is not used in the "order by"
> clause. The server attempts to fetch all records and then sort them by
> timestamp, despite the index already doing this...
> I removed the second index as a work-around, and the query runs faster on the
> first index - it scans index_event_timestamp, and retrieves the records with
> level=WARNING. It's smart to realize that the scan results are already sorted
> correctly.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11891) Multi-column index - query out of memory
[
https://issues.apache.org/jira/browse/IGNITE-11891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856747#comment-16856747
]
Andrew Mashenkov commented on IGNITE-11891:
---
[~joao_g_fonseca],
Nice to hear you've found workaroud!
Thanks for the information, we'll keep in mind this use case.
> Multi-column index - query out of memory
>
>
> Key: IGNITE-11891
> URL: https://issues.apache.org/jira/browse/IGNITE-11891
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: João Fonseca
>Priority: Major
>
> My application uses a table for logging events. Something like:
>
> {noformat}
> create table event (
> id bigint not null,
> level varchar(8) not null,
> timestamp bigint not null,
> message varchar(4096) not null,
> primary key (id)
> ) ;
> {noformat}
> I have two indexes:
>
> {noformat}
> create index index_event_timestamp on event (timestamp desc)
> create index index_event_level on event (level, timestamp desc)
> {noformat}
> The idea is to support both the following queries:
>
> {noformat}
> select * from event order by timestamp desc limit 25
> select * from event where level = 'WARNING' order by timestamp desc limit 25
> {noformat}
> Once the table size increases to several million records, the second query
> generates OOM on the server. From what I can see (from the explain results),
> the index_event_level is used to fetch records with WARNING level, but the
> timestamp column available with the index is not used in the "order by"
> clause. The server attempts to fetch all records and then sort them by
> timestamp, despite the index already doing this...
> I removed the second index as a work-around, and the query runs faster on the
> first index - it scans index_event_timestamp, and retrieves the records with
> level=WARNING. It's smart to realize that the scan results are already sorted
> correctly.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10619) Add support files transmission between nodes over connection via CommunicationSpi
[ https://issues.apache.org/jira/browse/IGNITE-10619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856744#comment-16856744 ] Nikolay Izhikov commented on IGNITE-10619: -- [~Mmuzaf] I will take a look, shortly. > Add support files transmission between nodes over connection via > CommunicationSpi > - > > Key: IGNITE-10619 > URL: https://issues.apache.org/jira/browse/IGNITE-10619 > Project: Ignite > Issue Type: Sub-task > Components: persistence >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-28 > > Partition preloader must support cache partition file relocation from one > cluster node to another (the zero copy algorithm [1] assume to be used by > default). To achieve this, the file transfer machinery must be implemented at > Apache Ignite over Communication SPI. > _CommunicationSpi_ > Ignite's Comminication SPI must support to: > * establishing channel connections to the remote node to an arbitrary topic > (GridTopic) with predefined processing policy; > * listening incoming channel creation events and registering connection > handlers on the particular node; > * an arbitrary set of channel parameters on connection handshake; > _FileTransmitProcessor_ > The file transmission manager must support to: > * using different approaches of incoming data handling – buffered and direct > (zero-copy approach of FileChannel#transferTo); > * transferring data by chunks of predefined size with saving intermediate > results; > * re-establishing connection if an error occurs and continue file > upload\download; > * limiting connection bandwidth (upload and download) at runtime; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11891) Multi-column index - query out of memory
[
https://issues.apache.org/jira/browse/IGNITE-11891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856733#comment-16856733
]
João Fonseca commented on IGNITE-11891:
---
In the H2 documentation, I found this:
[http://www.h2database.com/html/performance.html]
{noformat}
Multi-column indexes are used if all or the first columns of the index are
used. Both equality lookup and range scans are supported. Indexes are used to
order result sets, but only if the condition uses the same index or no index at
all.
{noformat}
I changed my query to
{code:java}
select * from event where level = 'WARNING' order by level, timestamp desc
limit 25
{code}
Adding the level column explicitly to the order by clause solves the problem,
the query just dumps the results straight out of the index, without trying to
sort the results.
I guess this makes sense, although the optimiser should be smart enough to do
this automatically. If the original query was
{code:java}
select * from event where level in ( 'WARNING', 'INFO' ) order by timestamp
desc limit 25
{code}
the index could not be dumped directly, as the WARNING and INFO records are
stored in different locations of the index.
Thanks for the discussion, which enabled me to understand this issue a lot
better. I'm not sure anymore if this qualifies as a bug. At most, it's
something that could be optimised.
> Multi-column index - query out of memory
>
>
> Key: IGNITE-11891
> URL: https://issues.apache.org/jira/browse/IGNITE-11891
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: João Fonseca
>Priority: Major
>
> My application uses a table for logging events. Something like:
>
> {noformat}
> create table event (
> id bigint not null,
> level varchar(8) not null,
> timestamp bigint not null,
> message varchar(4096) not null,
> primary key (id)
> ) ;
> {noformat}
> I have two indexes:
>
> {noformat}
> create index index_event_timestamp on event (timestamp desc)
> create index index_event_level on event (level, timestamp desc)
> {noformat}
> The idea is to support both the following queries:
>
> {noformat}
> select * from event order by timestamp desc limit 25
> select * from event where level = 'WARNING' order by timestamp desc limit 25
> {noformat}
> Once the table size increases to several million records, the second query
> generates OOM on the server. From what I can see (from the explain results),
> the index_event_level is used to fetch records with WARNING level, but the
> timestamp column available with the index is not used in the "order by"
> clause. The server attempts to fetch all records and then sort them by
> timestamp, despite the index already doing this...
> I removed the second index as a work-around, and the query runs faster on the
> first index - it scans index_event_timestamp, and retrieves the records with
> level=WARNING. It's smart to realize that the scan results are already sorted
> correctly.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10913) Reduce heap occupation by o.a.i.i.processors.cache.persistence.file.FilePageStore instances.
[ https://issues.apache.org/jira/browse/IGNITE-10913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856725#comment-16856725 ] Denis Chudov commented on IGNITE-10913: --- Performance check detected no significant difference with master. > Reduce heap occupation by > o.a.i.i.processors.cache.persistence.file.FilePageStore instances. > > > Key: IGNITE-10913 > URL: https://issues.apache.org/jira/browse/IGNITE-10913 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Denis Chudov >Priority: Major > Fix For: 2.8 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > With large topology and large amount of caches/partitions and enabled > persistence could be millions of FilePageStore objects in heap (for each > partition). > Each instance has a reference to a File (field cfgFile) storing as String > absolute path to a partition. > Also internal File inplementation (on example UnixFile) also allocates space > for file path. > I observed about 2Gb of heap space occupied by these objects in one of > environments. > Solution: dereference (set to null) cfgFile after object creation, create > File object lazily on demand when needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11892) Incorrect assert in wal scanner test
[
https://issues.apache.org/jira/browse/IGNITE-11892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856723#comment-16856723
]
Dmitriy Govorukhin commented on IGNITE-11892:
-
[~akalashnikov] Looks good to me, merged to master.
> Incorrect assert in wal scanner test
> -
>
> Key: IGNITE-11892
> URL: https://issues.apache.org/jira/browse/IGNITE-11892
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://ci.ignite.apache.org/viewLog.html?buildId=4038516=IgniteTests24Java8_Pds2
> {noformat}
> junit.framework.AssertionFailedError: Next WAL record :: Record : PAGE_RECORD
> - Unable to convert to string representation.
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.scanner.WalScannerTest.shouldDumpToFileFoundRecord(WalScannerTest.java:254)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11892) Incorrect assert in wal scanner test
[
https://issues.apache.org/jira/browse/IGNITE-11892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-11892:
Ignite Flags: (was: Docs Required)
> Incorrect assert in wal scanner test
> -
>
> Key: IGNITE-11892
> URL: https://issues.apache.org/jira/browse/IGNITE-11892
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://ci.ignite.apache.org/viewLog.html?buildId=4038516=IgniteTests24Java8_Pds2
> {noformat}
> junit.framework.AssertionFailedError: Next WAL record :: Record : PAGE_RECORD
> - Unable to convert to string representation.
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.scanner.WalScannerTest.shouldDumpToFileFoundRecord(WalScannerTest.java:254)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11892) Incorrect assert in wal scanner test
[
https://issues.apache.org/jira/browse/IGNITE-11892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-11892:
Fix Version/s: 2.8
> Incorrect assert in wal scanner test
> -
>
> Key: IGNITE-11892
> URL: https://issues.apache.org/jira/browse/IGNITE-11892
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://ci.ignite.apache.org/viewLog.html?buildId=4038516=IgniteTests24Java8_Pds2
> {noformat}
> junit.framework.AssertionFailedError: Next WAL record :: Record : PAGE_RECORD
> - Unable to convert to string representation.
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.scanner.WalScannerTest.shouldDumpToFileFoundRecord(WalScannerTest.java:254)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11891) Multi-column index - query out of memory
[
https://issues.apache.org/jira/browse/IGNITE-11891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856708#comment-16856708
]
João Fonseca commented on IGNITE-11891:
---
I used "explain sql ..." and verified that it uses the index_event_level index.
But from what I understood, it seems to only use it to fetch records where
level=WARNING, without taking into account that those results are already
ordered correctly.
A second stage in the execution will then try to order the results by
timestamp, which is unnecessary. Because the table contains millions of WARNING
records, the server dies with an OOM error.
In practice, Ignite behaves as though the index is just "(level)", not "(level,
timestamp desc)".
> Multi-column index - query out of memory
>
>
> Key: IGNITE-11891
> URL: https://issues.apache.org/jira/browse/IGNITE-11891
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: João Fonseca
>Priority: Major
>
> My application uses a table for logging events. Something like:
>
> {noformat}
> create table event (
> id bigint not null,
> level varchar(8) not null,
> timestamp bigint not null,
> message varchar(4096) not null,
> primary key (id)
> ) ;
> {noformat}
> I have two indexes:
>
> {noformat}
> create index index_event_timestamp on event (timestamp desc)
> create index index_event_level on event (level, timestamp desc)
> {noformat}
> The idea is to support both the following queries:
>
> {noformat}
> select * from event order by timestamp desc limit 25
> select * from event where level = 'WARNING' order by timestamp desc limit 25
> {noformat}
> Once the table size increases to several million records, the second query
> generates OOM on the server. From what I can see (from the explain results),
> the index_event_level is used to fetch records with WARNING level, but the
> timestamp column available with the index is not used in the "order by"
> clause. The server attempts to fetch all records and then sort them by
> timestamp, despite the index already doing this...
> I removed the second index as a work-around, and the query runs faster on the
> first index - it scans index_event_timestamp, and retrieves the records with
> level=WARNING. It's smart to realize that the scan results are already sorted
> correctly.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11891) Multi-column index - query out of memory
[
https://issues.apache.org/jira/browse/IGNITE-11891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856678#comment-16856678
]
Andrew Mashenkov commented on IGNITE-11891:
---
[~joao_g_fonseca], have you tried to use index-hints [#1] to force
'index_event_level'?
Ignite relies on H2 query execution pipeline and I'd think it should be fixed
in H2 at first.
Only then this issue can be resolved in Ignite with upgrading H2 dependency.
[1]
https://apacheignite.readme.io/v2.0/docs/sql-performance-and-debugging#index-hints
> Multi-column index - query out of memory
>
>
> Key: IGNITE-11891
> URL: https://issues.apache.org/jira/browse/IGNITE-11891
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: João Fonseca
>Priority: Major
>
> My application uses a table for logging events. Something like:
>
> {noformat}
> create table event (
> id bigint not null,
> level varchar(8) not null,
> timestamp bigint not null,
> message varchar(4096) not null,
> primary key (id)
> ) ;
> {noformat}
> I have two indexes:
>
> {noformat}
> create index index_event_timestamp on event (timestamp desc)
> create index index_event_level on event (level, timestamp desc)
> {noformat}
> The idea is to support both the following queries:
>
> {noformat}
> select * from event order by timestamp desc limit 25
> select * from event where level = 'WARNING' order by timestamp desc limit 25
> {noformat}
> Once the table size increases to several million records, the second query
> generates OOM on the server. From what I can see (from the explain results),
> the index_event_level is used to fetch records with WARNING level, but the
> timestamp column available with the index is not used in the "order by"
> clause. The server attempts to fetch all records and then sort them by
> timestamp, despite the index already doing this...
> I removed the second index as a work-around, and the query runs faster on the
> first index - it scans index_event_timestamp, and retrieves the records with
> level=WARNING. It's smart to realize that the scan results are already sorted
> correctly.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11896) [TC Bot] Comment JIRA may not work for case aliased TC is used
Dmitriy Pavlov created IGNITE-11896: --- Summary: [TC Bot] Comment JIRA may not work for case aliased TC is used Key: IGNITE-11896 URL: https://issues.apache.org/jira/browse/IGNITE-11896 Project: Ignite Issue Type: Bug Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov 'Comment JIRA' will not work for PR -less contribution in pr.html report -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10847) Web console: failed to download the mongodb on Ubuntu 18.04
[
https://issues.apache.org/jira/browse/IGNITE-10847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-10847:
--
Fix Version/s: 2.8
> Web console: failed to download the mongodb on Ubuntu 18.04
> ---
>
> Key: IGNITE-10847
> URL: https://issues.apache.org/jira/browse/IGNITE-10847
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> I tried to run 'web console direct install' and faced with an error
> downloading of MongoDB due to there is no corresponding version for that OS.
> {code}
> name: 'StatusCodeError',
> statusCode: 403,
> message: '403 - " encoding=\\"UTF-8\\"?>\\nAccessDeniedAccess
> Denied4B7715F9CDA5127BzuhNAWP7FGOgDLjkNJ3y71iU+wxcWKR5F5kI4LoO1SqCdt+aPeLZXnJko5S0ji2zx5zkJaCZX3g="',
> error: ' encoding="UTF-8"?>\nAccessDeniedAccess
> Denied4B7715F9CDA5127BzuhNAWP7FGOgDLjkNJ3y71iU+wxcWKR5F5kI4LoO1SqCdt+aPeLZXnJko5S0ji2zx5zkJaCZX3g=',
> options:
>{ uri:
> 'https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-ubuntu1804-3.4.7.tgz.md5',
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-11851) Cache does not exist after first IgniteContinuousQueryConfigVariationsSuite tests batch
[ https://issues.apache.org/jira/browse/IGNITE-11851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov resolved IGNITE-11851. --- Resolution: Not A Bug > Cache does not exist after first IgniteContinuousQueryConfigVariationsSuite > tests batch > --- > > Key: IGNITE-11851 > URL: https://issues.apache.org/jira/browse/IGNITE-11851 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > > IgniteContinuousQueryConfigVariationsSuite tests are generated dynamically. > The first batch (12 tests) runs without problems, but on next batches we got > an exception - default cache does not exist and we can not invoke unrwap() > method on it [1]. > It seems that cache is destroyed after the first batch and is not created on > the next one. > [1] > [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L212] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856594#comment-16856594 ] Ivan Pavlukhin commented on IGNITE-11708: - [~ivanan.fed], perfect! Merged to master. > Unable to run tests in IgniteConfigVariationsAbstractTest subclasses > > > Key: IGNITE-11708 > URL: https://issues.apache.org/jira/browse/IGNITE-11708 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep30 > Attachments: read_through_eviction_self_test.patch, > tx_out_test_fixed.patch > > Time Spent: 3h 50m > Remaining Estimate: 0h > > It seems that test classes that extend from > IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test > annotation. > It is easy to check: if throw exception in any test methods, nothing will > happen. > Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], > maybe it destroys existing test workflow. > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10281) Log to file all jars in classpath on start node.
[ https://issues.apache.org/jira/browse/IGNITE-10281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856585#comment-16856585 ] Ivan Bessonov commented on IGNITE-10281: [~Denis Chudov] looks good, thank you! > Log to file all jars in classpath on start node. > > > Key: IGNITE-10281 > URL: https://issues.apache.org/jira/browse/IGNITE-10281 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Denis Chudov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > We should print all jars in classpath for analize jar's hell. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11844) Should to filtered indexes by cache name instead of validate all caches in group
[ https://issues.apache.org/jira/browse/IGNITE-11844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856576#comment-16856576 ] Andrey Kalinin commented on IGNITE-11844: - [~v.pyatkov], looks reasonable. Fixed. > Should to filtered indexes by cache name instead of validate all caches in > group > > > Key: IGNITE-11844 > URL: https://issues.apache.org/jira/browse/IGNITE-11844 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Andrey Kalinin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > control.sh utility method validate_indexes checks all indexes of all caches > in group. Just do specify one caches (from generic group) in caches list, > then all indexes from all caches (that group) will be start to validate and > this can consume more time, than checks indexes only specified caches. > Will be correct to validate only indexes of specified caches, for the purpose > need to filtered caches, by list from parameters, in shared group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11895) .NET Resharper inspections got broken after update
Alexandr Shapkin created IGNITE-11895: - Summary: .NET Resharper inspections got broken after update Key: IGNITE-11895 URL: https://issues.apache.org/jira/browse/IGNITE-11895 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.7 Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin Resharper Inspection add new violation after migration from 2018.1.4 to version 2019.1 Lets suppress this new warning -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11881) Spark Data Frame examples not working
[ https://issues.apache.org/jira/browse/IGNITE-11881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856572#comment-16856572 ] Nikolay Izhikov commented on IGNITE-11881: -- Examples suite - https://ci.ignite.apache.org/viewLog.html?buildId=4047100=queuedBuildOverviewTab > Spark Data Frame examples not working > - > > Key: IGNITE-11881 > URL: https://issues.apache.org/jira/browse/IGNITE-11881 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Blocker > Time Spent: 10m > Remaining Estimate: 0h > > # Spark Data Frames examples fail. > # Spark Data Frame examples don't execute on TC. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11844) Should to filtered indexes by cache name instead of validate all caches in group
[
https://issues.apache.org/jira/browse/IGNITE-11844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856566#comment-16856566
]
Vladislav Pyatkov commented on IGNITE-11844:
[~6uest] I look at your commit and have one question:
Why you using {{ThreadLocalRandom}}, when the method
({{testValidateSingleCacheShouldNotTriggerCacheGroupValidation()}}) can be used
from one thread only? Is rely necessary to use random values here? (I think
predefined values will be enough there - for example i instead of
{{rand.nextInt()}}.)
> Should to filtered indexes by cache name instead of validate all caches in
> group
>
>
> Key: IGNITE-11844
> URL: https://issues.apache.org/jira/browse/IGNITE-11844
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Andrey Kalinin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> control.sh utility method validate_indexes checks all indexes of all caches
> in group. Just do specify one caches (from generic group) in caches list,
> then all indexes from all caches (that group) will be start to validate and
> this can consume more time, than checks indexes only specified caches.
> Will be correct to validate only indexes of specified caches, for the purpose
> need to filtered caches, by list from parameters, in shared group.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11844) Should to filtered indexes by cache name instead of validate all caches in group
[
https://issues.apache.org/jira/browse/IGNITE-11844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856566#comment-16856566
]
Vladislav Pyatkov edited comment on IGNITE-11844 at 6/5/19 10:12 AM:
-
[~6uest] I look at your commit and have one question:
Why you using {{ThreadLocalRandom}}, when the method
({{testValidateSingleCacheShouldNotTriggerCacheGroupValidation()}}) can be used
from one thread only? Is rely necessary to use random values here? (I think
predefined values will be enough there - for example {{i}} instead of
{{rand.nextInt()}}).
was (Author: v.pyatkov):
[~6uest] I look at your commit and have one question:
Why you using {{ThreadLocalRandom}}, when the method
({{testValidateSingleCacheShouldNotTriggerCacheGroupValidation()}}) can be used
from one thread only? Is rely necessary to use random values here? (I think
predefined values will be enough there - for example {{i}} instead of
{{rand.nextInt()}}.)
> Should to filtered indexes by cache name instead of validate all caches in
> group
>
>
> Key: IGNITE-11844
> URL: https://issues.apache.org/jira/browse/IGNITE-11844
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Andrey Kalinin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> control.sh utility method validate_indexes checks all indexes of all caches
> in group. Just do specify one caches (from generic group) in caches list,
> then all indexes from all caches (that group) will be start to validate and
> this can consume more time, than checks indexes only specified caches.
> Will be correct to validate only indexes of specified caches, for the purpose
> need to filtered caches, by list from parameters, in shared group.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11844) Should to filtered indexes by cache name instead of validate all caches in group
[
https://issues.apache.org/jira/browse/IGNITE-11844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856566#comment-16856566
]
Vladislav Pyatkov edited comment on IGNITE-11844 at 6/5/19 10:12 AM:
-
[~6uest] I look at your commit and have one question:
Why you using {{ThreadLocalRandom}}, when the method
({{testValidateSingleCacheShouldNotTriggerCacheGroupValidation()}}) can be used
from one thread only? Is rely necessary to use random values here? (I think
predefined values will be enough there - for example {{i}} instead of
{{rand.nextInt()}}.)
was (Author: v.pyatkov):
[~6uest] I look at your commit and have one question:
Why you using {{ThreadLocalRandom}}, when the method
({{testValidateSingleCacheShouldNotTriggerCacheGroupValidation()}}) can be used
from one thread only? Is rely necessary to use random values here? (I think
predefined values will be enough there - for example i instead of
{{rand.nextInt()}}.)
> Should to filtered indexes by cache name instead of validate all caches in
> group
>
>
> Key: IGNITE-11844
> URL: https://issues.apache.org/jira/browse/IGNITE-11844
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Andrey Kalinin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> control.sh utility method validate_indexes checks all indexes of all caches
> in group. Just do specify one caches (from generic group) in caches list,
> then all indexes from all caches (that group) will be start to validate and
> this can consume more time, than checks indexes only specified caches.
> Will be correct to validate only indexes of specified caches, for the purpose
> need to filtered caches, by list from parameters, in shared group.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11750) Implement locked pages info dump for long-running B+Tree operations
[
https://issues.apache.org/jira/browse/IGNITE-11750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856559#comment-16856559
]
Dmitriy Govorukhin commented on IGNITE-11750:
-
[~sergey-chugunov] Thanks for the review! Merged to master.
> Implement locked pages info dump for long-running B+Tree operations
> ---
>
> Key: IGNITE-11750
> URL: https://issues.apache.org/jira/browse/IGNITE-11750
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I've stumbled upon an incident where a batch of Ignite threads were hanging
> on BPlusTree operations trying to acquire read or write lock on pages. From
> the thread dump it is impossible to check if there is an issue with
> {{OffheapReadWriteLock}} or there is a subtle deadlock in the tree.
> I suggest we implement a timeout for page lock acquire and tracking of locked
> pages. This should be relatively easy to implement in {{PageHandler}} (the
> only thing to consider is performance degradation). If a timeout occurs, we
> should print all the locks currently owned by a thread. This way we should be
> able to determine if there is a deadlock in the {{BPlusTree}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11844) Should to filtered indexes by cache name instead of validate all caches in group
[ https://issues.apache.org/jira/browse/IGNITE-11844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856550#comment-16856550 ] Andrey Kalinin commented on IGNITE-11844: - [~v.pyatkov] please review. > Should to filtered indexes by cache name instead of validate all caches in > group > > > Key: IGNITE-11844 > URL: https://issues.apache.org/jira/browse/IGNITE-11844 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Andrey Kalinin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > control.sh utility method validate_indexes checks all indexes of all caches > in group. Just do specify one caches (from generic group) in caches list, > then all indexes from all caches (that group) will be start to validate and > this can consume more time, than checks indexes only specified caches. > Will be correct to validate only indexes of specified caches, for the purpose > need to filtered caches, by list from parameters, in shared group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856549#comment-16856549 ] Ivan Fedotov commented on IGNITE-11708: --- [~Pavlukhin], Sure, code style fixed. Visa has attached above. > Unable to run tests in IgniteConfigVariationsAbstractTest subclasses > > > Key: IGNITE-11708 > URL: https://issues.apache.org/jira/browse/IGNITE-11708 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep30 > Attachments: read_through_eviction_self_test.patch, > tx_out_test_fixed.patch > > Time Spent: 3h 50m > Remaining Estimate: 0h > > It seems that test classes that extend from > IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test > annotation. > It is easy to check: if throw exception in any test methods, nothing will > happen. > Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], > maybe it destroys existing test workflow. > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856545#comment-16856545
]
Ignite TC Bot commented on IGNITE-11708:
{panel:title=-- Run :: All (Nightly): Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=4046627]]
{panel}
[TeamCity *-- Run :: All (Nightly)*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4039310buildTypeId=IgniteTests24Java8_RunAllNightly]
> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
>
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep30
> Attachments: read_through_eviction_self_test.patch,
> tx_out_test_fixed.patch
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> It seems that test classes that extend from
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test
> annotation.
> It is easy to check: if throw exception in any test methods, nothing will
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1],
> maybe it destroys existing test workflow.
> [1]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11881) Spark Data Frame examples not working
[ https://issues.apache.org/jira/browse/IGNITE-11881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856546#comment-16856546 ] Nikolay Izhikov commented on IGNITE-11881: -- Javadoc suite for the patch - https://ci.ignite.apache.org/viewLog.html?buildId=4046980=queuedBuildOverviewTab > Spark Data Frame examples not working > - > > Key: IGNITE-11881 > URL: https://issues.apache.org/jira/browse/IGNITE-11881 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Blocker > Time Spent: 10m > Remaining Estimate: 0h > > # Spark Data Frames examples fail. > # Spark Data Frame examples don't execute on TC. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11844) Should to filtered indexes by cache name instead of validate all caches in group
[
https://issues.apache.org/jira/browse/IGNITE-11844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856533#comment-16856533
]
Ignite TC Bot commented on IGNITE-11844:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=4045983]]
{color:#d04437}MVCC PDS 4{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4045985]]
{color:#d04437}[Check Code Style]{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4045986]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4039941buildTypeId=IgniteTests24Java8_RunAll]
> Should to filtered indexes by cache name instead of validate all caches in
> group
>
>
> Key: IGNITE-11844
> URL: https://issues.apache.org/jira/browse/IGNITE-11844
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Andrey Kalinin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> control.sh utility method validate_indexes checks all indexes of all caches
> in group. Just do specify one caches (from generic group) in caches list,
> then all indexes from all caches (that group) will be start to validate and
> this can consume more time, than checks indexes only specified caches.
> Will be correct to validate only indexes of specified caches, for the purpose
> need to filtered caches, by list from parameters, in shared group.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856483#comment-16856483
]
Ivan Pavlukhin commented on IGNITE-11708:
-
[~ivanan.fed], it seems that [Code
Style|https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=4040427&_focus=331]
failure is related to current PR.
It claims
{quote}
[ERROR]
/opt/buildagent/work/69588afcb2ab3382/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java:82:
'METHOD_DEF' should be separated from previous statement. [EmptyLineSeparator]
{quote}
Also could you please attach a visa from _Nightly_ build (it seems that it
shows the same results)?
> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
>
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep30
> Attachments: read_through_eviction_self_test.patch,
> tx_out_test_fixed.patch
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> It seems that test classes that extend from
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test
> annotation.
> It is easy to check: if throw exception in any test methods, nothing will
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1],
> maybe it destroys existing test workflow.
> [1]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
