[jira] [Created] (IGNITE-11894) Add fetchSize to JDBC cache stores
Stanislav Lukyanov created IGNITE-11894: --- Summary: Add fetchSize to JDBC cache stores Key: IGNITE-11894 URL: https://issues.apache.org/jira/browse/IGNITE-11894 Project: Ignite Issue Type: Improvement Components: cache Reporter: Stanislav Lukyanov JDBC's PreparedStatement accepts a fetchSize parameter which defines how many rows will be loaded from the DB at a time. Currently the only way to change that is by specifying it in a customer implementation of the JdbcDialect::fetchSize method (and even then it seems not be be used in some cases). Would be good to have a fetchSize property in all of JDBC-based cache stores. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (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=16855917#comment-16855917 ] Ivan Fedotov edited comment on IGNITE-11708 at 6/4/19 5:42 PM: --- [~Pavlukhin], I fixed some moments after TC results: * added ConfigVariationsExecutionTest to testSuite [1] * ignored cache test in MVCC [2] * make dummyCfg non-static: since testCfg already is not static, now static dummyCfg is not necessary [3]. TC Bot gives me 2 blockers: code style and .Net Inspections, but both of them have a lot of recent failures (76 and 37 % respectively) [4]. [1] https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-e36adf615dfcc36775e2edd132042b4aR234 [2] https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-1cf9dd56dece1e687eada1c9cbc3388eR91 [3] https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-cd3a07ce10f21d396c1eac0c328850e0L376 [4] https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6434/head=Latest was (Author: ivanan.fed): [~Pavlukhin], I fixed some moments after TC results: * added ConfigVariationsExecutionTest to testSuite [1] * ignored cache test in MVCC [2] * make dummyCfg non-static: science testCfg already is not static, now static dummyCfg is not necessary [3]. TC Bot gives me 2 blockers: code style and .Net Inspections, but both of them have a lot of recent failures (76 and 37 % respectively) [4]. [1] https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-e36adf615dfcc36775e2edd132042b4aR234 [2] https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-1cf9dd56dece1e687eada1c9cbc3388eR91 [3] https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-cd3a07ce10f21d396c1eac0c328850e0L376 [4] https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6434/head=Latest > 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=16855917#comment-16855917 ] Ivan Fedotov commented on IGNITE-11708: --- [~Pavlukhin], I fixed some moments after TC results: * added ConfigVariationsExecutionTest to testSuite [1] * ignored cache test in MVCC [2] * make dummyCfg non-static: science testCfg already is not static, now static dummyCfg is not necessary [3]. TC Bot gives me 2 blockers: code style and .Net Inspections, but both of them have a lot of recent failures (76 and 37 % respectively) [4]. [1] https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-e36adf615dfcc36775e2edd132042b4aR234 [2] https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-1cf9dd56dece1e687eada1c9cbc3388eR91 [3] https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-cd3a07ce10f21d396c1eac0c328850e0L376 [4] https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6434/head=Latest > 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=16855906#comment-16855906
]
Ignite TC Bot commented on IGNITE-11708:
{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=4040424]]
{color:#d04437}[Check Code Style]{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4040427]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4039303buildTypeId=IgniteTests24Java8_RunAll]
> 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] [Created] (IGNITE-11893) .NET enum platform compatibility
Alexandr Shapkin created IGNITE-11893: - Summary: .NET enum platform compatibility Key: IGNITE-11893 URL: https://issues.apache.org/jira/browse/IGNITE-11893 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 2.7 Reporter: Alexandr Shapkin Let's make some warnings about platform compatibility. [https://apacheignite-net.readme.io/docs/platform-interoperability] We have a writeEnum/readEnum methods. In java writeEnum can write only ordinal value, but in .NET we can assign any number to the enumValue. So any custom enum-to-primitive value binding would not be taken into account. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11848) [IEP-35] Monitoring Phase 1
[ https://issues.apache.org/jira/browse/IGNITE-11848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855858#comment-16855858 ] Nikolay Izhikov commented on IGNITE-11848: -- [~dpavlov] Thanks! > [IEP-35] Monitoring Phase 1 > -- > > Key: IGNITE-11848 > URL: https://issues.apache.org/jira/browse/IGNITE-11848 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Umbrella ticket for the IEP-35. Monitoring and profiling. > Phase 1 should include: > * NextGen monitoring subsystem implementation to manage > ** metrics > ** -lists- (will be implemented in the following tickets) > ** exporters > * JMX, SQLView, Log exporters > * Migration of existing metrics to new manager > * -Lists for all Ignite user API- -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11848) [IEP-35] Monitoring Phase 1
[ https://issues.apache.org/jira/browse/IGNITE-11848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855855#comment-16855855 ] Dmitriy Pavlov commented on IGNITE-11848: - TC Bot run-all contains a number of suited failed with compilation failure > [IEP-35] Monitoring Phase 1 > -- > > Key: IGNITE-11848 > URL: https://issues.apache.org/jira/browse/IGNITE-11848 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Umbrella ticket for the IEP-35. Monitoring and profiling. > Phase 1 should include: > * NextGen monitoring subsystem implementation to manage > ** metrics > ** -lists- (will be implemented in the following tickets) > ** exporters > * JMX, SQLView, Log exporters > * Migration of existing metrics to new manager > * -Lists for all Ignite user API- -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11892) Incorrect assert in wal scanner test
Anton Kalashnikov created IGNITE-11892:
--
Summary: 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
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] [Created] (IGNITE-11891) Multi-column index - query out of memory
João Fonsecs created IGNITE-11891:
-
Summary: 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 Fonsecs
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-11778) [TC Bot] Implement unconditional blockers and add license check suites to blockers
[ https://issues.apache.org/jira/browse/IGNITE-11778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855777#comment-16855777 ] Dmitriy Pavlov commented on IGNITE-11778: - It can be configured now. > [TC Bot] Implement unconditional blockers and add license check suites to > blockers > -- > > Key: IGNITE-11778 > URL: https://issues.apache.org/jira/browse/IGNITE-11778 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Minor > > License by RAT plugin validation should be also > - considered as a blocker in PR validation > - introduced failure should cause notification on tracked branches -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11875) Thin client is unable to authenticate with long password
[
https://issues.apache.org/jira/browse/IGNITE-11875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855773#comment-16855773
]
Igor Sapego commented on IGNITE-11875:
--
[~ptupitsyn] done. [~DmitriyGovorukhin] can you take a look on Java part please?
> Thin client is unable to authenticate with long password
>
>
> Key: IGNITE-11875
> URL: https://issues.apache.org/jira/browse/IGNITE-11875
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, odbc, thin client
>Affects Versions: 2.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Token authentication could use long usernames/passwords, that leads to
> "Invalid handshake message"
> ClientListenerNioServerBuffer:
> {code:java}
> if (cnt == msgSize) {
> byte[] data0 = data;
> reset();
> return data0;
> }
> else {
> if (checkHandshake && cnt > 0 && (msgSize >
> ClientListenerNioListener.MAX_HANDSHAKE_MSG_SIZE
> || data[0] != ClientListenerRequest.HANDSHAKE))
> throw new IgniteCheckedException("Invalid handshake message");
> return null;
> }
> {code}
> The reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11875) Thin client is unable to authenticate with long password
[
https://issues.apache.org/jira/browse/IGNITE-11875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-11875:
-
Reviewer: Dmitriy Govorukhin
> Thin client is unable to authenticate with long password
>
>
> Key: IGNITE-11875
> URL: https://issues.apache.org/jira/browse/IGNITE-11875
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, odbc, thin client
>Affects Versions: 2.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Token authentication could use long usernames/passwords, that leads to
> "Invalid handshake message"
> ClientListenerNioServerBuffer:
> {code:java}
> if (cnt == msgSize) {
> byte[] data0 = data;
> reset();
> return data0;
> }
> else {
> if (checkHandshake && cnt > 0 && (msgSize >
> ClientListenerNioListener.MAX_HANDSHAKE_MSG_SIZE
> || data[0] != ClientListenerRequest.HANDSHAKE))
> throw new IgniteCheckedException("Invalid handshake message");
> return null;
> }
> {code}
> The reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11890) Metrics documentation
Nikolay Izhikov created IGNITE-11890: Summary: Metrics documentation Key: IGNITE-11890 URL: https://issues.apache.org/jira/browse/IGNITE-11890 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Ignite should provide full user documentation about existing metrics: * ClusterMetrics * CacheMetrics * CacheGroupMetrics * DataRegionMetrics * DataStorageMetrics * etc... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10687) Document new JMX bean wchih expose IO statistics.
[ https://issues.apache.org/jira/browse/IGNITE-10687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Gura resolved IGNITE-10687. -- Resolution: Won't Fix > Document new JMX bean wchih expose IO statistics. > -- > > Key: IGNITE-10687 > URL: https://issues.apache.org/jira/browse/IGNITE-10687 > Project: Ignite > Issue Type: Task > Components: documentation, sql >Reporter: Yury Gerzhedovich >Priority: Major > Fix For: 2.8 > > > We need to document a new JMX bean which expose Input/Output statistics. > Start point is > [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/mxbean/IoStatisticsMetricsMXBean.java] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IGNITE-10687) Document new JMX bean wchih expose IO statistics.
[ https://issues.apache.org/jira/browse/IGNITE-10687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Gura reopened IGNITE-10687: -- > Document new JMX bean wchih expose IO statistics. > -- > > Key: IGNITE-10687 > URL: https://issues.apache.org/jira/browse/IGNITE-10687 > Project: Ignite > Issue Type: Task > Components: documentation, sql >Reporter: Yury Gerzhedovich >Priority: Major > Fix For: 2.8 > > > We need to document a new JMX bean which expose Input/Output statistics. > Start point is > [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/mxbean/IoStatisticsMetricsMXBean.java] > -- 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=16855614#comment-16855614 ] Nikolay Izhikov commented on IGNITE-11881: -- [~zaleslaw], [~chief] Your changes from IGNITE-10803 brokes Spark Data Frame examples. Can you, please, clarify the rational behind jackson dependencies? I tried to generate javadoc and it's look OK. > 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 > > # 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-10803) [ML] Add prototype LogReg loading from PMML format
[ https://issues.apache.org/jira/browse/IGNITE-10803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855612#comment-16855612 ] Nikolay Izhikov commented on IGNITE-10803: -- [~zaleslaw] Your changes(jackson dependency) brokes Spark Data Frame examples Can you, please, clarify the rational behind jackson dependencies? I tried to generate javadoc and it's look OK. Also, it's not recommended to use direct version in module dependency, we have another version of jackson in parent pom. > [ML] Add prototype LogReg loading from PMML format > -- > > Key: IGNITE-10803 > URL: https://issues.apache.org/jira/browse/IGNITE-10803 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.8 > > > Generate or get existing PMML model for known dataset to load and predict new > data in Ignite -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10912) Huge discovery messages slow down node joining/dynamic cache start and corresponding PME
[ https://issues.apache.org/jira/browse/IGNITE-10912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-10912: -- Assignee: (was: Vladislav Pyatkov) > Huge discovery messages slow down node joining/dynamic cache start and > corresponding PME > > > Key: IGNITE-10912 > URL: https://issues.apache.org/jira/browse/IGNITE-10912 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Priority: Major > Fix For: 2.8 > > > WIth large topology and large number of caches/groups node join message can > reach a size > 30M due to a large amount of transferred discovery data. > It adds overhead on ring traversal and slows down "node join" PME. > Possible solution: > # introduce DiscoveryDataMessage for transferring discovery related data > which doesn't increment topology version. After all nodes wil have > corressponding discovery data start actual joining. Discovery data probably > should be stored off-heap(or even on disk) to avoid heap usage bursts on > joining of multiple nodes. > # Add compression to discovery data. > Same problem for CacheAffinityChangeMessage (PME after late affinity) and > dynamic cache start message (if starting many caches). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
