[jira] [Commented] (IGNITE-9652) Fix `Missorted modifiers' according inspections profile`
[ https://issues.apache.org/jira/browse/IGNITE-9652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623103#comment-16623103 ] ASF GitHub Bot commented on IGNITE-9652: GitHub user Mmuzaf opened a pull request: https://github.com/apache/ignite/pull/4800 IGNITE-9652: fix missorted modifiers You can merge this pull request into a Git repository by running: $ git pull https://github.com/Mmuzaf/ignite ignite-9652 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4800.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 #4800 commit 76a9d335700ede6b89ab2edfffd607e1ace5ca09 Author: Maxim Muzafarov Date: 2018-09-21T05:48:40Z IGNITE-9652: fix missorted modifiers > Fix `Missorted modifiers' according inspections profile` > > > Key: IGNITE-9652 > URL: https://issues.apache.org/jira/browse/IGNITE-9652 > Project: Ignite > Issue Type: Bug >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Minor > Labels: inspections > > New `Code Inspections` profile can be found > \idea\ignite_inspections.xml. > We need to fix rule `Missorted modifiers` in ignite-core module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-336) We need to add dynamic turn on/off cache statistics for Visor.
[ https://issues.apache.org/jira/browse/IGNITE-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623062#comment-16623062 ] Vasiliy Sisko commented on IGNITE-336: -- 1, 2 fixed. 3 Information about statistics collection on cache does not exists in visor. Possible separate issue should be created. > We need to add dynamic turn on/off cache statistics for Visor. > -- > > Key: IGNITE-336 > URL: https://issues.apache.org/jira/browse/IGNITE-336 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: sprint-2 >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > We need create task to turn on/off of cache statistics collecting. > Create Visor command for toggling. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9565) Update chartjs streaming plugin
[ https://issues.apache.org/jira/browse/IGNITE-9565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9565: Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Update chartjs streaming plugin > --- > > Key: IGNITE-9565 > URL: https://issues.apache.org/jira/browse/IGNITE-9565 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > [https://github.com/nagix/chartjs-plugin-streaming/releases] > Chartjs-streaming plugin now has a ttl property which allows to set maximum > points. > We should update version of plugin and remove our code for stripping extra > points. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9637) SQL: Create suite for data load benchmarks
[ https://issues.apache.org/jira/browse/IGNITE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622777#comment-16622777 ] Pavel Kuznetsov edited comment on IGNITE-9637 at 9/20/18 10:07 PM: --- I've run on the AWS (4 servers m5.2) for the sanity results. ||Benchmark class ||Configuration name||Load time, ms|| |NativePutAllBenchmark |upload-native-putAll |7,472.01| |NativePutBenchmark |upload-native-put |187,832.46| |NativeStreamerBenchmark|upload-native-streamer |2,265.88| |CopyBenchmark |upload-copy|12,476.99| |InsertBenchmark|upload-insert |295,748.12| |InsertBenchmark|upload-sql-streaming |2,838.30| |BatchedInsertBenchmark |upload-batched-insert |15,087.90| was (Author: pkouznet): ||Benchmark class ||Configuration name||Load time, ms|| |NativePutAllBenchmark |upload-native-putAll |7,472.01| |NativePutBenchmark |upload-native-put |187,832.46| |NativeStreamerBenchmark|upload-native-streamer |2,265.88| |CopyBenchmark |upload-copy|12,476.99| |InsertBenchmark|upload-insert |295,748.12| |InsertBenchmark|upload-sql-streaming |2,838.30| |BatchedInsertBenchmark |upload-batched-insert |15,087.90| > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We want to have benchmark suite that measures how long it takes to upload > data to server. > There is existing benchmark code in org.apache.ignite.yardstick.upload > package > 1) Improve data model: > - Add indexes to data model. Number of indexes should be configurable. > - Add missing benchmark that performs putAll > 2) Define parameters to use in benchmarks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9637) SQL: Create suite for data load benchmarks
[ https://issues.apache.org/jira/browse/IGNITE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622777#comment-16622777 ] Pavel Kuznetsov edited comment on IGNITE-9637 at 9/20/18 10:05 PM: --- ||Benchmark class ||Configuration name||Load time, ms|| |NativePutAllBenchmark |upload-native-putAll |7,472.01| |NativePutBenchmark |upload-native-put |187,832.46| |NativeStreamerBenchmark|upload-native-streamer |2,265.88| |CopyBenchmark |upload-copy|12,476.99| |InsertBenchmark|upload-insert |295,748.12| |InsertBenchmark|upload-sql-streaming |2,838.30| |BatchedInsertBenchmark |upload-batched-insert |15,087.90| was (Author: pkouznet): ||Benchmark class |Configuration name |Load time, ms|| |NativePutAllBenchmark |upload-native-putAll |7,472.01| |NativePutBenchmark ||upload-native-put ||187,832.46| |NativeStreamerBenchmark|upload-native-streamer |2,265.88| |CopyBenchmark |upload-copy|12,476.99| |InsertBenchmark|upload-insert |295,748.12| |InsertBenchmark|upload-sql-streaming |2,838.30| |BatchedInsertBenchmark |upload-batched-insert |15,087.90| > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We want to have benchmark suite that measures how long it takes to upload > data to server. > There is existing benchmark code in org.apache.ignite.yardstick.upload > package > 1) Improve data model: > - Add indexes to data model. Number of indexes should be configurable. > - Add missing benchmark that performs putAll > 2) Define parameters to use in benchmarks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9637) SQL: Create suite for data load benchmarks
[ https://issues.apache.org/jira/browse/IGNITE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622777#comment-16622777 ] Pavel Kuznetsov commented on IGNITE-9637: - ||Benchmark class |Configuration name |Load time, ms|| |NativePutAllBenchmark |upload-native-putAll |7,472.01| |NativePutBenchmark |upload-native-put |187,832.46| |NativeStreamerBenchmark|upload-native-streamer |2,265.88| |CopyBenchmark |upload-copy|12,476.99| |InsertBenchmark|upload-insert |295,748.12| |InsertBenchmark|upload-sql-streaming |2,838.30| |BatchedInsertBenchmark |upload-batched-insert |15,087.90| > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We want to have benchmark suite that measures how long it takes to upload > data to server. > There is existing benchmark code in org.apache.ignite.yardstick.upload > package > 1) Improve data model: > - Add indexes to data model. Number of indexes should be configurable. > - Add missing benchmark that performs putAll > 2) Define parameters to use in benchmarks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9637) SQL: Create suite for data load benchmarks
[ https://issues.apache.org/jira/browse/IGNITE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622777#comment-16622777 ] Pavel Kuznetsov edited comment on IGNITE-9637 at 9/20/18 10:04 PM: --- ||Benchmark class |Configuration name |Load time, ms|| |NativePutAllBenchmark |upload-native-putAll |7,472.01| |NativePutBenchmark ||upload-native-put ||187,832.46| |NativeStreamerBenchmark|upload-native-streamer |2,265.88| |CopyBenchmark |upload-copy|12,476.99| |InsertBenchmark|upload-insert |295,748.12| |InsertBenchmark|upload-sql-streaming |2,838.30| |BatchedInsertBenchmark |upload-batched-insert |15,087.90| was (Author: pkouznet): ||Benchmark class |Configuration name |Load time, ms|| |NativePutAllBenchmark |upload-native-putAll |7,472.01| |NativePutBenchmark |upload-native-put |187,832.46| |NativeStreamerBenchmark|upload-native-streamer |2,265.88| |CopyBenchmark |upload-copy|12,476.99| |InsertBenchmark|upload-insert |295,748.12| |InsertBenchmark|upload-sql-streaming |2,838.30| |BatchedInsertBenchmark |upload-batched-insert |15,087.90| > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We want to have benchmark suite that measures how long it takes to upload > data to server. > There is existing benchmark code in org.apache.ignite.yardstick.upload > package > 1) Improve data model: > - Add indexes to data model. Number of indexes should be configurable. > - Add missing benchmark that performs putAll > 2) Define parameters to use in benchmarks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9601) Write rollover WAL record as the last record in current segment
[
https://issues.apache.org/jira/browse/IGNITE-9601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622570#comment-16622570
]
Andrey Gura commented on IGNITE-9601:
-
[~andrey-kuznetsov] I've looked at your change and have the following comments:
* {{FsyncModeFileWriteAheadLogManager}} haы different logic in compare with
{{FileWriteAheadLogManager}}.
* Could you please add multi-threaded test for case of rollover type
{{NEXT_SEGMENT}}? Test must generate some load from thread pool and dedicated
thread must log record with {{NEXT_SEGMENT}} rollover type. After some time or
amount of {{log(rec, NEXT_SEGMENT)}} calls you can check WAL for the following
invariant: every rollover record must be the second record in the WAL segment
(the first record is {{HEADER_RECORD}}).
* Please, fix java doc description of
{{IgniteWriteAheadLogManager.log(WALRecord entry, RolloverType rolloverType)}}
method. Now it is just copy version of {{log(rec)}} method.
> Write rollover WAL record as the last record in current segment
> ---
>
> Key: IGNITE-9601
> URL: https://issues.apache.org/jira/browse/IGNITE-9601
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> Currently, rollover WAL record gets to the next segment when being logged.
> Moreover, the implementation allows data races, and rollover record is not
> necessarily the first record in the next segment. We are to add an option to
> logging facility to allow writing rollover record to the end of the current
> segment; subsequent records should get to the next segment then.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9660) Switch default test FailureHandler to StopNodeFailureHandler
[
https://issues.apache.org/jira/browse/IGNITE-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov updated IGNITE-9660:
-
Issue Type: Task (was: Test)
> Switch default test FailureHandler to StopNodeFailureHandler
>
>
> Key: IGNITE-9660
> URL: https://issues.apache.org/jira/browse/IGNITE-9660
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> {{GridAbstractTest.getFailureHandler()}} returns {{NoOpFailureHandler}}
> instance. This often leads to hiding bugs occurring in tests.
> {{getFailureFailureHandler()}} should return {{StopNodeFailureHandler}}
> instead.
> The change assumes re-checking failed tests and set handler to
> {{NoOpFailureHandler}} in subclasses where it's really a must.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9597) 'size() == 0' replaceable with 'isEmpty()' according inspections profile
[
https://issues.apache.org/jira/browse/IGNITE-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622443#comment-16622443
]
ASF GitHub Bot commented on IGNITE-9597:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4758
> 'size() == 0' replaceable with 'isEmpty()' according inspections profile
>
>
> Key: IGNITE-9597
> URL: https://issues.apache.org/jira/browse/IGNITE-9597
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
> Labels: inspections
> Fix For: 2.7
>
>
> New `Code Inspections` profile can be found
> {{\idea\ignite_inspections.xml}}.
> We need to fix rule `size() == 0' replaceable with 'isEmpty()` in
> {{ignite-core}} module.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9597) 'size() == 0' replaceable with 'isEmpty()' according inspections profile
[
https://issues.apache.org/jira/browse/IGNITE-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-9597:
---
Ignite Flags: (was: Docs Required)
> 'size() == 0' replaceable with 'isEmpty()' according inspections profile
>
>
> Key: IGNITE-9597
> URL: https://issues.apache.org/jira/browse/IGNITE-9597
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
> Labels: inspections
> Fix For: 2.7
>
>
> New `Code Inspections` profile can be found
> {{\idea\ignite_inspections.xml}}.
> We need to fix rule `size() == 0' replaceable with 'isEmpty()` in
> {{ignite-core}} module.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9660) Switch default test FailureHandler to StopNodeFailureHandler
Andrey Kuznetsov created IGNITE-9660:
Summary: Switch default test FailureHandler to
StopNodeFailureHandler
Key: IGNITE-9660
URL: https://issues.apache.org/jira/browse/IGNITE-9660
Project: Ignite
Issue Type: Test
Affects Versions: 2.6
Reporter: Andrey Kuznetsov
Fix For: 2.8
{{GridAbstractTest.getFailureHandler()}} returns {{NoOpFailureHandler}}
instance. This often leads to hiding bugs occurring in tests.
{{getFailureFailureHandler()}} should return {{StopNodeFailureHandler}} instead.
The change assumes re-checking failed tests and set handler to
{{NoOpFailureHandler}} in subclasses where it's really a must.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9597) 'size() == 0' replaceable with 'isEmpty()' according inspections profile
[
https://issues.apache.org/jira/browse/IGNITE-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622406#comment-16622406
]
Ignite TC Bot commented on IGNITE-9597:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Direct IO) 2{color} [[tests 1 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1875911]]
* IgnitePdsNativeIoTestSuite2:
IgnitePdsCorruptedStoreTest.testNodeInvalidatedWhenPersistenceIsCorrupted -
7,0% fails in last 100 master runs.
* IgnitePdsCorruptedStoreTest.testNodeInvalidatedWhenPersistenceIsCorrupted
(last started)
{color:#d04437}Platform .NET{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=1875904]]
* exe: ServicesTest.TestDeployAllException(False) - 0,0% fails in last 100
master runs.
{color:#d04437}Binary Objects (Simple Mapper Basic){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1875855]]
* IgniteBinarySimpleNameMapperBasicTestSuite:
BPlusTreeSelfTest.testSizeForRandomPutRmvMultithreadedAsync_16 - 0,0% fails in
last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1875955buildTypeId=IgniteTests24Java8_RunAll]
> 'size() == 0' replaceable with 'isEmpty()' according inspections profile
>
>
> Key: IGNITE-9597
> URL: https://issues.apache.org/jira/browse/IGNITE-9597
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
> Labels: inspections
> Fix For: 2.7
>
>
> New `Code Inspections` profile can be found
> {{\idea\ignite_inspections.xml}}.
> We need to fix rule `size() == 0' replaceable with 'isEmpty()` in
> {{ignite-core}} module.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8650) ZookeeperDiscovery testClientReconnectMultinode is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-8650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-8650:
---
Fix Version/s: (was: 2.8)
2.7
> ZookeeperDiscovery testClientReconnectMultinode is flaky in master
> --
>
> Key: IGNITE-8650
> URL: https://issues.apache.org/jira/browse/IGNITE-8650
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> The test IgniteClientReconnectCacheTest#testReconnectMultinode(LongHistory)
> periodically fails with timeouts in master.
> From the logs I see that the hang is caused by one of the two assertion
> errors:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1345)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {code}
> or
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.checkClientsStatus(ZookeeperDiscoveryImpl.java:1388)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2300(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$CheckClientsStatusCallback.processResult0(ZookeeperDiscoveryImpl.java:4332)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZkAbstractChildrenCallback.processResult(ZkAbstractChildrenCallback.java:42)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$ChildrenCallbackWrapper.processResult(ZookeeperClient.java:1132)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {code}
> The test failure can be rarely reproduced locally (run repeatedly with CPU
> stress enabled).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9341) Notify metastorage listeners right before start of discovery processor
[ https://issues.apache.org/jira/browse/IGNITE-9341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622283#comment-16622283 ] ASF GitHub Bot commented on IGNITE-9341: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4648 > Notify metastorage listeners right before start of discovery processor > -- > > Key: IGNITE-9341 > URL: https://issues.apache.org/jira/browse/IGNITE-9341 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Ivan Rakov >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.8 > > > onReadyForRead() is called only for inheritors of > MetastorageLifecycleListener interface which are started prior to > GridCacheProcessor. Listeners are notified at the moment of > ReadOnlyMetastorage initialization, which in turn occur during > GridCacheDatabaseSharedManager start. > We can split ReadOnlyMetastorage initialization and notification of listeners > - this will allow all components to subscribe for read-only metastorage ready > event. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9341) Notify metastorage listeners right before start of discovery processor
[ https://issues.apache.org/jira/browse/IGNITE-9341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622278#comment-16622278 ] Ivan Rakov commented on IGNITE-9341: Merged to master, thanks! > Notify metastorage listeners right before start of discovery processor > -- > > Key: IGNITE-9341 > URL: https://issues.apache.org/jira/browse/IGNITE-9341 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Ivan Rakov >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.8 > > > onReadyForRead() is called only for inheritors of > MetastorageLifecycleListener interface which are started prior to > GridCacheProcessor. Listeners are notified at the moment of > ReadOnlyMetastorage initialization, which in turn occur during > GridCacheDatabaseSharedManager start. > We can split ReadOnlyMetastorage initialization and notification of listeners > - this will allow all components to subscribe for read-only metastorage ready > event. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9321) MVCC: support cache events
[
https://issues.apache.org/jira/browse/IGNITE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-9321:
---
Attachment: EventsProblems.java
> MVCC: support cache events
> --
>
> Key: IGNITE-9321
> URL: https://issues.apache.org/jira/browse/IGNITE-9321
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.7
>
> Attachments: EventsProblems.java
>
>
> Currently cache events are not fired for MVCC caches. Need to restore all
> cache events.
> Number of problems were found in Events framework. Let's outline them before
> proceeding with implementation for MVCC caches. Attached reproducer
> demonstrates several problems.
> h2. Bugs
> 1. {{IgniteCache.remove}} fires event regardless entry presence in the cache.
> 2. CACHE_OBJECT_PUT can report {{hasOldValue==true,oldValue==null}} for
> transactional cache.
> See attached reproducer.
> Also it means that test coverage is not sufficient, negative tests could be
> added, event content check could be added.
> h2. Inconsistency
> In current vision for the same operations with different cache modes we will
> see different number of events fired. ATOMIC cache fires events for each
> operation. TRANSACTIONAL cache fires only final changes on commit (_put
> remove put_ on the same key will result in only one CACHE_OBJECT_PUT event)
> and nothing on rollback. Current plan for MVCC is to fire events right away
> with operation, so events for rolled back transactions will be fired as well.
> So, for all 3 modes behavior is different. It looks hardly understandable and
> subsequently could lead to usage errors.
> Additionally there are confusion points for SQL operations. For SELECT
> CACHE_QUERY_OBJECT_READ event is triggered and CACHE_OBJECT_READ is not. For
> DML operations weird mix of events occurs.
> h2. Use cases
> Also it is good to understand in what use cases it is a good idea to use
> IgniteEvents. Audit was mentioned as an example. But it looks like that
> currently events framework solve _beforehand_ audit when event is triggered
> before on actual operation. We could document _when_ each type of event is
> triggered and what _ordering_ guarantees (if any) are there.
> h2. Other
> 1. EVT_CACHE_OBJECT_LOCKED, EVT_CACHE_OBJECT_UNLOCKED provokes questions for
> MVCC. Should we reuse same event for lock while unlock happens implicitly on
> transaction commit? Do we need some specific events?
> 2. EVT_CACHE_ENTRY_CREATED, EVT_CACHE_ENTRY_DESTROYED events are almost
> useless for a user, but it is not obvious immediately.
> 3. {{EventType}} javadoc states that all events are enabled by default,
> {{IgniteEvents}} javadoc states opposite and a latter seems to be true.
> 4. {{IgniteEvents}} facade encapsulates 2 event processing workflows: event
> listening and querying events from _event store_. While workflows are related
> but from the first glance separation between them is not obvious.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9321) MVCC: support cache events
[
https://issues.apache.org/jira/browse/IGNITE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-9321:
---
Description:
Currently cache events are not fired for MVCC caches. Need to restore all cache
events.
Number of problems were found in Events framework. Let's outline them before
proceeding with implementation for MVCC caches. Attached reproducer
demonstrates several problems.
h2. Bugs
1. {{IgniteCache.remove}} fires event regardless entry presence in the cache.
2. CACHE_OBJECT_PUT can report {{hasOldValue==true,oldValue==null}} for
transactional cache.
See attached reproducer.
Also it means that test coverage is not sufficient, negative tests could be
added, event content check could be added.
h2. Inconsistency
In current vision for the same operations with different cache modes we will
see different number of events fired. ATOMIC cache fires events for each
operation. TRANSACTIONAL cache fires only final changes on commit (_put remove
put_ on the same key will result in only one CACHE_OBJECT_PUT event) and
nothing on rollback. Current plan for MVCC is to fire events right away with
operation, so events for rolled back transactions will be fired as well. So,
for all 3 modes behavior is different. It looks hardly understandable and
subsequently could lead to usage errors.
Additionally there are confusion points for SQL operations. For SELECT
CACHE_QUERY_OBJECT_READ event is triggered and CACHE_OBJECT_READ is not. For
DML operations weird mix of events occurs.
h2. Use cases
Also it is good to understand in what use cases it is a good idea to use
IgniteEvents. Audit was mentioned as an example. But it looks like that
currently events framework solve _beforehand_ audit when event is triggered
before on actual operation. We could document _when_ each type of event is
triggered and what _ordering_ guarantees (if any) are there.
h2. Other
1. EVT_CACHE_OBJECT_LOCKED, EVT_CACHE_OBJECT_UNLOCKED provokes questions for
MVCC. Should we reuse same event for lock while unlock happens implicitly on
transaction commit? Do we need some specific events?
2. EVT_CACHE_ENTRY_CREATED, EVT_CACHE_ENTRY_DESTROYED events are almost useless
for a user, but it is not obvious immediately.
3. {{EventType}} javadoc states that all events are enabled by default,
{{IgniteEvents}} javadoc states opposite and a latter seems to be true.
4. {{IgniteEvents}} facade encapsulates 2 event processing workflows: event
listening and querying events from _event store_. While workflows are related
but from the first glance separation between them is not obvious.
was:
Currently cache events are not fired for MVCC caches. Need to restore all cache
events.
Starting point: {{org.apache.ignite.events.EventType#EVTS_CACHE}}. All these
events should work in the same way on both MVCC and non-MVCC caches.
Events are supposed to fire right away without deferring to transaction end
phase.
> MVCC: support cache events
> --
>
> Key: IGNITE-9321
> URL: https://issues.apache.org/jira/browse/IGNITE-9321
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.7
>
>
> Currently cache events are not fired for MVCC caches. Need to restore all
> cache events.
> Number of problems were found in Events framework. Let's outline them before
> proceeding with implementation for MVCC caches. Attached reproducer
> demonstrates several problems.
> h2. Bugs
> 1. {{IgniteCache.remove}} fires event regardless entry presence in the cache.
> 2. CACHE_OBJECT_PUT can report {{hasOldValue==true,oldValue==null}} for
> transactional cache.
> See attached reproducer.
> Also it means that test coverage is not sufficient, negative tests could be
> added, event content check could be added.
> h2. Inconsistency
> In current vision for the same operations with different cache modes we will
> see different number of events fired. ATOMIC cache fires events for each
> operation. TRANSACTIONAL cache fires only final changes on commit (_put
> remove put_ on the same key will result in only one CACHE_OBJECT_PUT event)
> and nothing on rollback. Current plan for MVCC is to fire events right away
> with operation, so events for rolled back transactions will be fired as well.
> So, for all 3 modes behavior is different. It looks hardly understandable and
> subsequently could lead to usage errors.
> Additionally there are confusion points for SQL operations. For SELECT
> CACHE_QUERY_OBJECT_READ event is triggered and CACHE_OBJECT_READ is not. For
> DML operations weird mix of events occurs.
> h2. Use cases
> Also it is good to understand in what use cases it is a good idea to use
> IgniteEvents. Audit was mentioned as an example. But it
[jira] [Updated] (IGNITE-9659) NonCollocatedRetryMessageSelfTest is flaky
[ https://issues.apache.org/jira/browse/IGNITE-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9659: - Labels: MakeTeamcityGreenAgain (was: ) > NonCollocatedRetryMessageSelfTest is flaky > -- > > Key: IGNITE-9659 > URL: https://issues.apache.org/jira/browse/IGNITE-9659 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > > https://ci.ignite.apache.org/viewLog.html?buildId=1881869=buildResultsDiv=IgniteTests24Java8_Queries2#testNameId-2853122976880171731 > A few concerns on the test code: > 1) What is the point of setting an anonymous discovery SPI? The overridden > method is identical to super(), but the new discovery SPI looses test VM IP > finder which is set by default > 2) Looks like there is a race in test communication SPI code - there is an if > - assign block for a volatile variable > 3) The test fails with "Node left during query execution" - since the node is > stopped, this should be either an allowed exception, or the test > communication SPI should be crafted more carefully. > (FYI: Locally I have this test failing with No CacheException emitted. > Collection size=10) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9659) NonCollocatedRetryMessageSelfTest is flaky
[ https://issues.apache.org/jira/browse/IGNITE-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9659: - Ignite Flags: (was: Docs Required) > NonCollocatedRetryMessageSelfTest is flaky > -- > > Key: IGNITE-9659 > URL: https://issues.apache.org/jira/browse/IGNITE-9659 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > > https://ci.ignite.apache.org/viewLog.html?buildId=1881869=buildResultsDiv=IgniteTests24Java8_Queries2#testNameId-2853122976880171731 > A few concerns on the test code: > 1) What is the point of setting an anonymous discovery SPI? The overridden > method is identical to super(), but the new discovery SPI looses test VM IP > finder which is set by default > 2) Looks like there is a race in test communication SPI code - there is an if > - assign block for a volatile variable > 3) The test fails with "Node left during query execution" - since the node is > stopped, this should be either an allowed exception, or the test > communication SPI should be crafted more carefully. > (FYI: Locally I have this test failing with No CacheException emitted. > Collection size=10) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9659) NonCollocatedRetryMessageSelfTest is flaky
Alexey Goncharuk created IGNITE-9659: Summary: NonCollocatedRetryMessageSelfTest is flaky Key: IGNITE-9659 URL: https://issues.apache.org/jira/browse/IGNITE-9659 Project: Ignite Issue Type: Test Reporter: Alexey Goncharuk https://ci.ignite.apache.org/viewLog.html?buildId=1881869=buildResultsDiv=IgniteTests24Java8_Queries2#testNameId-2853122976880171731 A few concerns on the test code: 1) What is the point of setting an anonymous discovery SPI? The overridden method is identical to super(), but the new discovery SPI looses test VM IP finder which is set by default 2) Looks like there is a race in test communication SPI code - there is an if - assign block for a volatile variable 3) The test fails with "Node left during query execution" - since the node is stopped, this should be either an allowed exception, or the test communication SPI should be crafted more carefully. (FYI: Locally I have this test failing with No CacheException emitted. Collection size=10) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9162) Query returns ICE: org.h2.table.TableView cannot be cast
[
https://issues.apache.org/jira/browse/IGNITE-9162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622214#comment-16622214
]
ASF GitHub Bot commented on IGNITE-9162:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4779
> Query returns ICE: org.h2.table.TableView cannot be cast
>
>
> Key: IGNITE-9162
> URL: https://issues.apache.org/jira/browse/IGNITE-9162
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Sergey Kozlov
>Assignee: Sergey Grimstad
>Priority: Critical
> Fix For: 2.7
>
> Attachments: 4779.patch, caches.xml, client.xml, policies.xml,
> server.xml
>
>
> 1. Start 1 Ignite node {{bin/ignite.sh server.xml -v -J-DCONSISTENT_ID=node1}}
> 2. Start sqlline {{bin/sqlline.sh -u
> jdbc:ignite:thin://127.0.0.1/?distributedJoins=true}}
> 3. Execute statements:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> CREATE TABLE t1 ( id INT NOT NULL, int_col1
> INT NOT NULL, PRIMARY KEY (id)) WITH "TEMPLATE=partitioned";
> No rows affected (0,151 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> INSERT INTO t1 (id,int_col1) VALUES
> (1,0),(2,0),(3,0),(4,0);
> 4 rows affected (0,052 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> SELECT * FROM ( SELECT * FROM t1 WHERE
> int_col1 > 0 ORDER BY id ) WHERE int_col1 = 1
> ORDER BY id;
> Error: javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: org.h2.table.TableView cannot be
> cast
> to org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> (state=5,code=0)
> 0: jdbc:ignite:thin://127.0.0.1/>
> {noformat}
> Node log:
> {noformat}
> [12:39:38,162][SEVERE][client-connector-#50][JdbcRequestHandler] Failed to
> execute SQL query [reqId=0, req=JdbcQueryExecuteRequest [schemaName=PUBLIC,
> pageSize=1024, maxRows=0, sqlQry=SELECT * FROM ( SELECT * FROM t1 WHERE
> int_col1 > 0 ORDER BY id ) WHERE int_col1 = 1 ORDER BY id, args=[],
> stmtType=ANY_STATEMENT_TYPE]]
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> org.h2.table.TableView cannot be cast to
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2047)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:456)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:203)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:160)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:44)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteCheckedException:
> org.h2.table.TableView cannot be cast to
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2601)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2044)
> ... 12 more
> Caused by: java.lang.ClassCastException: org.h2.table.TableView cannot be
> cast to org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartitionFromEquality(GridSqlQuerySplitter.java:2336)
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartition(GridSqlQuerySplitter.java:2268)
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.derivePartitionsFromQuery(GridSqlQuerySplitter.java:2250)
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitSelect(GridSqlQuerySplitter.java:1539)
> at
>
[jira] [Commented] (IGNITE-9646) Regression in release build for ignite-aws module
[ https://issues.apache.org/jira/browse/IGNITE-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622210#comment-16622210 ] ASF GitHub Bot commented on IGNITE-9646: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4793 > Regression in release build for ignite-aws module > - > > Key: IGNITE-9646 > URL: https://issues.apache.org/jira/browse/IGNITE-9646 > Project: Ignite > Issue Type: Bug > Components: aws >Reporter: Ilya Kasnacheev >Assignee: Stanislav Lukyanov >Priority: Blocker > Fix For: 2.7 > > > In IGNITE-9073 from pom.xml of ignite-aws jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryS3IpFinder and started from binary build. > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9646) Regression in release build for ignite-aws module
[ https://issues.apache.org/jira/browse/IGNITE-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622205#comment-16622205 ] Dmitriy Pavlov commented on IGNITE-9646: https://ci.ignite.apache.org/viewLog.html?buildId=1915071; tests passed. > Regression in release build for ignite-aws module > - > > Key: IGNITE-9646 > URL: https://issues.apache.org/jira/browse/IGNITE-9646 > Project: Ignite > Issue Type: Bug > Components: aws >Reporter: Ilya Kasnacheev >Assignee: Stanislav Lukyanov >Priority: Blocker > Fix For: 2.7 > > > In IGNITE-9073 from pom.xml of ignite-aws jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryS3IpFinder and started from binary build. > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9646) Regression in release build for ignite-aws module
[ https://issues.apache.org/jira/browse/IGNITE-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-9646. Resolution: Fixed Merged to master, I've also added do not remove comments to warn Igniters about these dependencies in future. > Regression in release build for ignite-aws module > - > > Key: IGNITE-9646 > URL: https://issues.apache.org/jira/browse/IGNITE-9646 > Project: Ignite > Issue Type: Bug > Components: aws >Reporter: Ilya Kasnacheev >Assignee: Stanislav Lukyanov >Priority: Blocker > Fix For: 2.7 > > > In IGNITE-9073 from pom.xml of ignite-aws jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryS3IpFinder and started from binary build. > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8545) If queryParallelism in nodes' caches configurations differ, query may hang, assert or return incomplete results
[ https://issues.apache.org/jira/browse/IGNITE-8545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622199#comment-16622199 ] ASF GitHub Bot commented on IGNITE-8545: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4702 > If queryParallelism in nodes' caches configurations differ, query may hang, > assert or return incomplete results > --- > > Key: IGNITE-8545 > URL: https://issues.apache.org/jira/browse/IGNITE-8545 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.6 >Reporter: Ilya Kasnacheev >Assignee: Maxim Pudov >Priority: Critical > Fix For: 2.7 > > Attachments: IgniteSqlSplitterQueryParallelismTest.java > > > I imagine it should not. See the attached file. > It happens both with client nodes and with server nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9560) Security permissions to restrict arbitrary code exectution
[ https://issues.apache.org/jira/browse/IGNITE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-9560: --- Assignee: Denis Garus > Security permissions to restrict arbitrary code exectution > -- > > Key: IGNITE-9560 > URL: https://issues.apache.org/jira/browse/IGNITE-9560 > Project: Ignite > Issue Type: Task > Components: security >Affects Versions: 2.6 >Reporter: Anton Vinogradov >Assignee: Denis Garus >Priority: Major > Fix For: 2.8 > > > SecurityPermission class should be extended to cover all cases able to cause > arbitrary code execution. > 1) Restriction on listener registration > - IgniteEvents listener > - CQ listener > 2) Restriction on closure (able to be executed on the remote node) execution > - Compute API (seems to be covered, should be rechecked) > - Services > - Entry processor > 3) We have to make sure that cases listed at #1 and #2 are the all possible > cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9560) Security permissions to restrict arbitrary code exectution
[ https://issues.apache.org/jira/browse/IGNITE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622178#comment-16622178 ] Denis Garus commented on IGNITE-9560: - We should: - add permission(s) for the Distributed Messaging functionality that's provided via the IgniteMessaging interface; - split the CACHE_PUT permission to CACHE_PUT for put/putAll operations and CACHE_INVOKE for cache's set of invoking operations. > Security permissions to restrict arbitrary code exectution > -- > > Key: IGNITE-9560 > URL: https://issues.apache.org/jira/browse/IGNITE-9560 > Project: Ignite > Issue Type: Task > Components: security >Affects Versions: 2.6 >Reporter: Anton Vinogradov >Priority: Major > Fix For: 2.8 > > > SecurityPermission class should be extended to cover all cases able to cause > arbitrary code execution. > 1) Restriction on listener registration > - IgniteEvents listener > - CQ listener > 2) Restriction on closure (able to be executed on the remote node) execution > - Compute API (seems to be covered, should be rechecked) > - Services > - Entry processor > 3) We have to make sure that cases listed at #1 and #2 are the all possible > cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8545) If queryParallelism in nodes' caches configurations differ, query may hang, assert or return incomplete results
[
https://issues.apache.org/jira/browse/IGNITE-8545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622174#comment-16622174
]
Ignite TC Bot commented on IGNITE-8545:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache (Failover) 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1870570]]
* CacheAsyncOperationsFailoverTxTest.testAsyncFailover (last started)
{color:#d04437}Queries (Binary Objects Simple Mapper){color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=1870501]]
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
SchemaExchangeSelfTest.testEmptyDynamic - 0,0% fails in last 100 master runs.
{color:#d04437}Platform .NET (Long Running){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=1870549]]
* exe: ExamplesTest.TestRemoteNodes(BinaryModeExample) - 0,0% fails in last 100
master runs.
* exe: ExamplesTest.TestRemoteNodes(LinqExample) - 0,0% fails in last 100
master runs.
* exe: ExamplesTest.TestRemoteNodes(SqlExample) - 0,0% fails in last 100 master
runs.
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1870541]]
* ZookeeperDiscoverySpiTestSuite2:
IgniteClientReconnectCacheTest.testReconnectMultinode - 0,0% fails in last 100
master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteClientReconnectCacheTest.testReconnectMultinodeLongHistory - 0,0% fails
in last 100 master runs.
{color:#d04437}Cache 6{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1870565]]
* IgniteCacheTestSuite6:
TxRollbackAsyncNearCacheTest.testMixedAsyncRollbackTypes - 0,0% fails in last
100 master runs.
{color:#d04437}Cache 7 (With Persistence){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1870585]]
* IgniteCacheTestSuite7:
TxRollbackAsyncWithPersistenceTest.testMixedAsyncRollbackTypes - 0,0% fails in
last 100 master runs.
* IgniteCacheTestSuite7:
TxRollbackAsyncWithPersistenceTest.testSynchronousRollback - 0,0% fails in last
100 master runs.
{color:#d04437}Continuous Query 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1870507]]
* IgniteCacheQuerySelfTestSuite3:
CacheContinuousWithTransformerLocalSelfTest.testContinuousWithTransformerAndRegularListenerKeepBinaryAsync
- 0,0% fails in last 100 master runs.
{color:#d04437}PDS (Indexing){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1870558]]
* IgnitePdsWithIndexingCoreTestSuite:
IgnitePdsAtomicCacheHistoricalRebalancingTest.testPartitionCounterConsistencyOnUnstableTopology
- 0,0% fails in last 100 master runs.
* IgnitePdsWithIndexingCoreTestSuite:
IgnitePdsAtomicCacheHistoricalRebalancingTest.testTopologyChangesWithConstantLoad
- 0,0% fails in last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1870597buildTypeId=IgniteTests24Java8_RunAll]
> If queryParallelism in nodes' caches configurations differ, query may hang,
> assert or return incomplete results
> ---
>
> Key: IGNITE-8545
> URL: https://issues.apache.org/jira/browse/IGNITE-8545
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Assignee: Maxim Pudov
>Priority: Critical
> Fix For: 2.7
>
> Attachments: IgniteSqlSplitterQueryParallelismTest.java
>
>
> I imagine it should not. See the attached file.
> It happens both with client nodes and with server nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9654) Test testJoinQueryUnstableTopology is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622175#comment-16622175
]
ASF GitHub Bot commented on IGNITE-9654:
GitHub user NSAmelchev opened a pull request:
https://github.com/apache/ignite/pull/4797
IGNITE-9654
Fix for the
**IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.testJoinQueryUnstableTopology**
test.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/NSAmelchev/ignite ignite-9654
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4797.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 #4797
commit 8a4c4117ebcb84535c076d1e5997f7215a663102
Author: NSAmelchev
Date: 2018-09-20T15:00:39Z
Fix test.
> Test testJoinQueryUnstableTopology is flaky in master
> -
>
> Key: IGNITE-9654
> URL: https://issues.apache.org/jira/browse/IGNITE-9654
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> The test
> IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.testJoinQueryUnstableTopology
> is flaky in master. [Example of
> fail|https://ci.ignite.apache.org/viewLog.html?buildId=1910548=buildResultsDiv=IgniteTests24Java8_Queries1#testNameId-9054712716754027821].
> Log:
> {noformat}
> Failed to stop grid
> [igniteInstanceName=near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest5,
> cancel=false]
> class org.apache.ignite.internal.IgniteInterruptedCheckedException: sleep
> interrupted
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7704)
> at
> org.apache.ignite.testframework.GridTestUtils.waitForCondition(GridTestUtils.java:1672)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2293)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1155)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1130)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1430)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.access$100(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:35)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest$2.call(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:96)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest$2.call(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:79)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> Caused by: java.lang.InterruptedException: sleep interrupted
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7699)
> ... 9 more
> java.lang.RuntimeException: Not all Ignite instances has been stopped.
> Please, see log for details.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-4750) SQL: Support GROUP_CONCAT function
[ https://issues.apache.org/jira/browse/IGNITE-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622169#comment-16622169 ] ASF GitHub Bot commented on IGNITE-4750: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3185 > SQL: Support GROUP_CONCAT function > -- > > Key: IGNITE-4750 > URL: https://issues.apache.org/jira/browse/IGNITE-4750 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Denis Magda >Assignee: Taras Ledkov >Priority: Major > Labels: sql-engine > Fix For: 2.7 > > > GROUP_CONCAT function is not supported at the moment. Makes sense to fill > this gap: > http://apache-ignite-users.70518.x6.nabble.com/GROUP-CONCAT-function-is-unsupported-td10757.html > Presently the function doc is hidden: > https://apacheignite-sql.readme.io/docs/group_concat > Open it up once the ticket is released. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9546) Document GROUP_CONCAT aggregate function
[
https://issues.apache.org/jira/browse/IGNITE-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9546:
Component/s: documentation
> Document GROUP_CONCAT aggregate function
>
>
> Key: IGNITE-9546
> URL: https://issues.apache.org/jira/browse/IGNITE-9546
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Priority: Major
> Fix For: 2.7
>
>
> We need to document GROUP_CONCAT aggregate function.
> # Explain users that {{DISTINCT}} and {{ORDER BY}} is supported only for
> collocated {{GROUP BY}};
> # String concatenation expressions are separated by {{||}} (not by comma as
> described at the
> [draft|https://dash.readme.io/project/apacheignite-sql/v2.6/docs/group_concat]);
> e.g.: {{GROUP_CONCAT(valueId || '=' || value SEPARATOR '; ')}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9546) Document GROUP_CONCAT aggregate function
[
https://issues.apache.org/jira/browse/IGNITE-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-9546:
---
Assignee: Artem Budnikov
> Document GROUP_CONCAT aggregate function
>
>
> Key: IGNITE-9546
> URL: https://issues.apache.org/jira/browse/IGNITE-9546
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> We need to document GROUP_CONCAT aggregate function.
> # Explain users that {{DISTINCT}} and {{ORDER BY}} is supported only for
> collocated {{GROUP BY}};
> # String concatenation expressions are separated by {{||}} (not by comma as
> described at the
> [draft|https://dash.readme.io/project/apacheignite-sql/v2.6/docs/group_concat]);
> e.g.: {{GROUP_CONCAT(valueId || '=' || value SEPARATOR '; ')}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8331) SQL: Add Decimal precision and scale constraint
[ https://issues.apache.org/jira/browse/IGNITE-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622154#comment-16622154 ] PetrovMikhail edited comment on IGNITE-8331 at 9/20/18 2:53 PM: Cache 6 and Cache 7 tests failed with a link to IGNITE - 8509 PDS(DirectIO) tests failed with a link to IGNITE - 8509 ZooKeeper (Discovery) 1, Queries 1, Queries 2, PDS 2 tests passed locally all failed .Net tests can be found in [https://cwiki.apache.org/confluence/download/attachments/73631266/Ignite%20Teamcity%20-%20current%20failures.pdf?api=v2] was (Author: petrovmikhail): Cache 6 and Cache 7 tests failed with a link to IGNITE - 8509 PDS(DirectIO) tests failed with a link to IGNITE - 8509 ZooKeeper (Discovery) 1, Queries 1, Queries 2, PDS 2 tests passed locally all failed .Net tests can be found in [Ignite Teamcity - PR failures|[https://cwiki.apache.org/confluence/download/attachments/73631266/Ignite%20Teamcity%20-%20current%20failures.pdf?api=v2]] > SQL: Add Decimal precision and scale constraint > --- > > Key: IGNITE-8331 > URL: https://issues.apache.org/jira/browse/IGNITE-8331 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Assignee: PetrovMikhail >Priority: Major > Labels: sql-engine > > We should support DECIMAL(X, Y) syntax. > Currently, we ignore it. > It affects semantics. > E.g., one can insert a DECIMAL with greater precision into a cache/table > without any problems. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8331) SQL: Add Decimal precision and scale constraint
[ https://issues.apache.org/jira/browse/IGNITE-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622154#comment-16622154 ] PetrovMikhail edited comment on IGNITE-8331 at 9/20/18 2:49 PM: Cache 6 and Cache 7 tests failed with a link to IGNITE - 8509 PDS(DirectIO) tests failed with a link to IGNITE - 8509 ZooKeeper (Discovery) 1, Queries 1, Queries 2, PDS 2 tests passed locally all failed .Net tests can be found in [Ignite Teamcity - PR failures|[https://cwiki.apache.org/confluence/download/attachments/73631266/Ignite%20Teamcity%20-%20current%20failures.pdf?api=v2]] was (Author: petrovmikhail): Cache 6 and Cache 7 tests failed with a link to IGNITE - 8509 PDS(DirectIO) tests failed with a link to IGNITE - 8509 ZooKeeper (Discovery) 1, Queries 1, Queries 2, PDS 2 tests passed locally all failed .Net tests can be found in [Ignite Teamcity - PR failures|[https://cwiki.apache.org/confluence/download/attachments/73631266/Ignite%20Teamcity%20-%20current%20failures.pdf?api=v2]] > SQL: Add Decimal precision and scale constraint > --- > > Key: IGNITE-8331 > URL: https://issues.apache.org/jira/browse/IGNITE-8331 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Assignee: PetrovMikhail >Priority: Major > Labels: sql-engine > > We should support DECIMAL(X, Y) syntax. > Currently, we ignore it. > It affects semantics. > E.g., one can insert a DECIMAL with greater precision into a cache/table > without any problems. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8331) SQL: Add Decimal precision and scale constraint
[ https://issues.apache.org/jira/browse/IGNITE-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622154#comment-16622154 ] PetrovMikhail commented on IGNITE-8331: --- Cache 6 and Cache 7 tests failed with a link to IGNITE - 8509 PDS(DirectIO) tests failed with a link to IGNITE - 8509 ZooKeeper (Discovery) 1, Queries 1, Queries 2, PDS 2 tests passed locally all failed .Net tests can be found in [Ignite Teamcity - PR failures|[https://cwiki.apache.org/confluence/download/attachments/73631266/Ignite%20Teamcity%20-%20current%20failures.pdf?api=v2]] > SQL: Add Decimal precision and scale constraint > --- > > Key: IGNITE-8331 > URL: https://issues.apache.org/jira/browse/IGNITE-8331 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Assignee: PetrovMikhail >Priority: Major > Labels: sql-engine > > We should support DECIMAL(X, Y) syntax. > Currently, we ignore it. > It affects semantics. > E.g., one can insert a DECIMAL with greater precision into a cache/table > without any problems. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9658) Add ability to disable memory deallocation on deactivation.
Ivan Daschinskiy created IGNITE-9658: Summary: Add ability to disable memory deallocation on deactivation. Key: IGNITE-9658 URL: https://issues.apache.org/jira/browse/IGNITE-9658 Project: Ignite Issue Type: Improvement Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy Fix For: 2.8 Currently, in some systems (i.e. RHEL 7.4), we can see, that during massive UNSAFE.freeMemory process freezes. This behaviour can lead to SEGMENTATION of node, especcially when ZookeeperDiscoverySPI is used. There should be an abillity to disable memory deallocation during deactivation of cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9654) Test testJoinQueryUnstableTopology is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-9654:
Description:
The test
IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.testJoinQueryUnstableTopology
is flaky in master. [Example of
fail|https://ci.ignite.apache.org/viewLog.html?buildId=1910548=buildResultsDiv=IgniteTests24Java8_Queries1#testNameId-9054712716754027821].
Log:
{noformat}
Failed to stop grid
[igniteInstanceName=near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest5,
cancel=false]
class org.apache.ignite.internal.IgniteInterruptedCheckedException: sleep
interrupted
at
org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7704)
at
org.apache.ignite.testframework.GridTestUtils.waitForCondition(GridTestUtils.java:1672)
at
org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2293)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1155)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1130)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1430)
at
org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.access$100(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:35)
at
org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest$2.call(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:96)
at
org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest$2.call(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:79)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
Caused by: java.lang.InterruptedException: sleep interrupted
at java.lang.Thread.sleep(Native Method)
at
org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7699)
... 9 more
java.lang.RuntimeException: Not all Ignite instances has been stopped. Please,
see log for details.
{noformat}
was:
The test
IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.testJoinQueryUnstableTopology
is flaky in master. [Example of
fail|https://ci.ignite.apache.org/viewLog.html?buildId=1910548=buildResultsDiv=IgniteTests24Java8_Queries1#testNameId-9054712716754027821].
Log:
{noformat}
java.lang.RuntimeException: Not all Ignite instances has been stopped. Please,
see log for details.
{noformat}
> Test testJoinQueryUnstableTopology is flaky in master
> -
>
> Key: IGNITE-9654
> URL: https://issues.apache.org/jira/browse/IGNITE-9654
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> The test
> IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.testJoinQueryUnstableTopology
> is flaky in master. [Example of
> fail|https://ci.ignite.apache.org/viewLog.html?buildId=1910548=buildResultsDiv=IgniteTests24Java8_Queries1#testNameId-9054712716754027821].
> Log:
> {noformat}
> Failed to stop grid
> [igniteInstanceName=near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest5,
> cancel=false]
> class org.apache.ignite.internal.IgniteInterruptedCheckedException: sleep
> interrupted
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7704)
> at
> org.apache.ignite.testframework.GridTestUtils.waitForCondition(GridTestUtils.java:1672)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2293)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1155)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1130)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1430)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.access$100(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:35)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest$2.call(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:96)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest$2.call(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:79)
> at
>
[jira] [Commented] (IGNITE-8552) Unable to use date as primary key
[ https://issues.apache.org/jira/browse/IGNITE-8552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622138#comment-16622138 ] ASF GitHub Bot commented on IGNITE-8552: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4692 > Unable to use date as primary key > - > > Key: IGNITE-8552 > URL: https://issues.apache.org/jira/browse/IGNITE-8552 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Sergey Grimstad >Priority: Blocker > Fix For: 2.7 > > Attachments: IGNITE-8552_implemented.patch > > > It' is unable to create cache via ddl: > create table tab(id date primary key, date_field date); > Result: > ERROR CacheAffinitySharedManager - Failed to initialize cache. Will try to > rollback cache start routine. [cacheName=SQL_PUBLIC_T3] > class org.apache.ignite.IgniteCheckedException: Failed to find value class in > the node classpath (use default marshaller to enable binary objects) : > SQL_PUBLIC_T3_e90848b2_fe30_4adb_a934_6e13ca0eb409 > at > org.apache.ignite.internal.processors.query.QueryUtils.typeForQueryEntity(QueryUtils.java:426) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9549) control.sh add command to collect information on the distribution of partitions and reset lost partitions
[
https://issues.apache.org/jira/browse/IGNITE-9549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622135#comment-16622135
]
Ivan Bessonov commented on IGNITE-9549:
---
* User attributes in CommandHandler should probably be trimmed in line 1630,
just like it's done for cache names. Maybe also check empty attributes.
* "New add user attribute in result" javadoc in CacheArguments doesn't look
clear at all. Something like "Additional user attributes." for both methods
would be better. Please also don't skip dots at the end of sentences.
* CacheDistributionTaskResult, line 308, there's a chance that you'll have
several commas in a row if "userAttribute" is null for some reason.
* CacheResetLostPartitionsTaskResult, line 38, technically you could get NPE
here if I understand it correctly.
* "testCacheDistribution" test has non-intuitive asserts in the end, please
add some clarifying comments.
> control.sh add command to collect information on the distribution of
> partitions and reset lost partitions
> -
>
> Key: IGNITE-9549
> URL: https://issues.apache.org/jira/browse/IGNITE-9549
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexand Polyakov
>Assignee: Alexand Polyakov
>Priority: Major
>
> control.sh add command to collect information on the distribution of
> partitions
> {noformat}
> control.sh --cache distribution nodeId|null [cacheName1[,...,cacheNameN]]
> [--user-attributes userAttribute[,...,userAttributeN]]
> {noformat}
> return
> [next group: id=??, name=??]
> groupId,partition,nodeId,primary,state,updateCounter,size,nodeAddresses[,userAttribute[,...,userAttributeN]]
> ...
> groupId,partition,nodeId,primary,state,updateCounter,size,nodeAddresses[,userAttribute[,...,userAttributeN]]
> reset lost partitions
> {noformat}
> control.sh --cache reset_lost_partitions cacheName1[,...,cacheNameN]
> {noformat}
> return
> Reset LOST-partitions performed successfully. Cache group (name = '??', id =
> ??)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9646) Regression in release build for ignite-aws module
[ https://issues.apache.org/jira/browse/IGNITE-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622130#comment-16622130 ] Stanislav Lukyanov commented on IGNITE-9646: Checked that S3IpFinder works with this patch and doesn't work without it. > Regression in release build for ignite-aws module > - > > Key: IGNITE-9646 > URL: https://issues.apache.org/jira/browse/IGNITE-9646 > Project: Ignite > Issue Type: Bug > Components: aws >Reporter: Ilya Kasnacheev >Assignee: Stanislav Lukyanov >Priority: Blocker > Fix For: 2.7 > > > In IGNITE-9073 from pom.xml of ignite-aws jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryS3IpFinder and started from binary build. > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9519) Composite types should be inlined in index tree
[ https://issues.apache.org/jira/browse/IGNITE-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622122#comment-16622122 ] ASF GitHub Bot commented on IGNITE-9519: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4724 > Composite types should be inlined in index tree > --- > > Key: IGNITE-9519 > URL: https://issues.apache.org/jira/browse/IGNITE-9519 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.6 >Reporter: Yury Gerzhedovich >Assignee: Stanislav Lukyanov >Priority: Major > Fix For: 2.7 > > > Currently in case PK is complex type it can not be keep at inline index. > This is critical performance issue due to for any put or get operation it > cant' be fully comparable and require read full object from the heap or even > disk storage. > To mitigate the problem we need add ability keep complex type (java object) > at inline indexes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8930) ODBC: Cursors are not closed when used through Go
[
https://issues.apache.org/jira/browse/IGNITE-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622113#comment-16622113
]
ASF GitHub Bot commented on IGNITE-8930:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4407
> ODBC: Cursors are not closed when used through Go
> -
>
> Key: IGNITE-8930
> URL: https://issues.apache.org/jira/browse/IGNITE-8930
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.5
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: odbc
> Fix For: 2.7
>
>
> Client used: https://github.com/alexbrainman/odbc
> Example app for reproducing:
> [https://github.com/nombiezinja/ignite-cursor-example]
> After several execution of statements user begins to get the following error:
> {noformat}
> 2018/06/29 20:46:06 SQLExecute: {HY000} Too many open cursors (either close
> other open cursors or increase the limit through
> ClientConnectorConfiguration.maxOpenCursorsPerConnection) [maximum=128,
> current=128]{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9442) Collocated IgniteSet#close is not working on non-affinity node.
[
https://issues.apache.org/jira/browse/IGNITE-9442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622082#comment-16622082
]
Anton Vinogradov commented on IGNITE-9442:
--
[~Mmuzaf],
Could you please prereview the fix?
> Collocated IgniteSet#close is not working on non-affinity node.
> ---
>
> Key: IGNITE-9442
> URL: https://issues.apache.org/jira/browse/IGNITE-9442
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: Reproducer.java
>
>
> Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
> contains non-affinity nodes.
> Steps to reproduce:
> 1. Start cluster with two nodes: server and client.
> 2. Create collocated {{IgniteSet}} on client node.
> 3. Close {{IgniteSet}} on client node.
> 4. Invoke {{add()}} method on closed IgniteSet.
> Expected: {{add()}} throws {{IllegalStateException}}.
> Actual: {{add()}} does not throw exception and put new "orphan" item in the
> datastructure cache.
> Alternatively to client node we can exclude server node by using cache node
> filter, as shown in attached junit reproducer.
> This bug is related to
> [IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
> affects usage of IgniteSet in cluster with non-affinity nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8331) SQL: Add Decimal precision and scale constraint
[
https://issues.apache.org/jira/browse/IGNITE-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622077#comment-16622077
]
Ignite TC Bot commented on IGNITE-8331:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 1{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1913046]]
* GridOrderedMessageCancelSelfTest.testTaskException (last started)
{color:#d04437}Platform .NET{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1913009]]
* exe: DataStorageMetricsTest.TestDataStorageMetrics - 0,0% fails in last 100
master runs.
{color:#d04437}Platform .NET (Long Running){color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=1913012]]
* exe: ExamplesTest.TestRemoteNodes(BinaryModeExample) - 0,0% fails in last 100
master runs.
* exe: ExamplesTest.TestRemoteNodes(LinqExample) - 0,0% fails in last 100
master runs.
* exe: ExamplesTest.TestRemoteNodes(SqlExample) - 0,0% fails in last 100 master
runs.
{color:#d04437}Queries 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1912991]]
* IgniteBinaryCacheQueryTestSuite2:
IgniteCacheQueryNodeRestartSelfTest.testRestarts - 0,0% fails in last 100
master runs.
{color:#d04437}Cache 6{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1913028]]
* IgniteCacheTestSuite6:
TxRollbackAsyncNearCacheTest.testMixedAsyncRollbackTypes - 0,0% fails in last
100 master runs.
{color:#d04437}Cache 7 (With Persistence){color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=1913048]]
* IgniteCacheTestSuite7:
TxRollbackAsyncWithPersistenceTest.testMixedAsyncRollbackTypes - 0,0% fails in
last 100 master runs.
{color:#d04437}PDS (Direct IO) 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1913016]]
* IgnitePdsNativeIoTestSuite2: IgnitePersistentStoreDataStructuresTest.testSet
- 0,0% fails in last 100 master runs.
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1913003]]
* ZookeeperDiscoverySpiTestSuite1: ZookeeperDiscoverySpiTest.testQuorumRestore
- 0,0% fails in last 100 master runs.
{color:#d04437}PDS 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1913020]]
* IgnitePdsTestSuite2: IgnitePersistentStoreDataStructuresTest.testSet - 0,0%
fails in last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1913060buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Add Decimal precision and scale constraint
> ---
>
> Key: IGNITE-8331
> URL: https://issues.apache.org/jira/browse/IGNITE-8331
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: PetrovMikhail
>Priority: Major
> Labels: sql-engine
>
> We should support DECIMAL(X, Y) syntax.
> Currently, we ignore it.
> It affects semantics.
> E.g., one can insert a DECIMAL with greater precision into a cache/table
> without any problems.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9365) Force backups to different AWS availability zones using only Spring XML
[ https://issues.apache.org/jira/browse/IGNITE-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622061#comment-16622061 ] David Harvey commented on IGNITE-9365: -- [~vkulichenko] I pushed a change which implements your very first comment. Your approach makes the misconfiguation case I was worried about observable. > Force backups to different AWS availability zones using only Spring XML > --- > > Key: IGNITE-9365 > URL: https://issues.apache.org/jira/browse/IGNITE-9365 > Project: Ignite > Issue Type: Improvement > Components: cache > Environment: >Reporter: David Harvey >Assignee: David Harvey >Priority: Minor > Fix For: 2.7 > > Attachments: master_947962f785_availability_zones_via_spring.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > As a developer, I want to be able to force cache backups each to a different > "Availability Zone", when I'm running out-of-the-box Ignite, without > additional Jars installed. "Availability zone" is a AWS feature with > different names for the same function by other cloud providers. A single > availability zone has the characteristic that some or all of the EC2 > instances in that zone can fail together due to a single fault. You have no > control over the hosts on which the EC2 instance VMs run on in AWS, except by > controlling the availability zone . > > I could write a few lines of a custom affinityBackupFilter, and configure it > a RendezvousAffinityFunction, but then I have to get it deployed on all nodes > in the cluster, and peer class loading will not work to this. The code to > do this should just be part of Ignite. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8930) ODBC: Cursors are not closed when used through Go
[
https://issues.apache.org/jira/browse/IGNITE-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622038#comment-16622038
]
Taras Ledkov commented on IGNITE-8930:
--
[~isapego], the review summary:
| Code style | OK |
| API compatibility | OK |
| Product behavior | defaults not changed |
| Documentation | not required |
| Binary compatibility | OK |
| Tests | OK |
> ODBC: Cursors are not closed when used through Go
> -
>
> Key: IGNITE-8930
> URL: https://issues.apache.org/jira/browse/IGNITE-8930
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.5
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: odbc
> Fix For: 2.7
>
>
> Client used: https://github.com/alexbrainman/odbc
> Example app for reproducing:
> [https://github.com/nombiezinja/ignite-cursor-example]
> After several execution of statements user begins to get the following error:
> {noformat}
> 2018/06/29 20:46:06 SQLExecute: {HY000} Too many open cursors (either close
> other open cursors or increase the limit through
> ClientConnectorConfiguration.maxOpenCursorsPerConnection) [maximum=128,
> current=128]{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8930) ODBC: Cursors are not closed when used through Go
[
https://issues.apache.org/jira/browse/IGNITE-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622007#comment-16622007
]
Igor Sapego commented on IGNITE-8930:
-
Here is the TC link:
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F4407%2Fhead
> ODBC: Cursors are not closed when used through Go
> -
>
> Key: IGNITE-8930
> URL: https://issues.apache.org/jira/browse/IGNITE-8930
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.5
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: odbc
> Fix For: 2.7
>
>
> Client used: https://github.com/alexbrainman/odbc
> Example app for reproducing:
> [https://github.com/nombiezinja/ignite-cursor-example]
> After several execution of statements user begins to get the following error:
> {noformat}
> 2018/06/29 20:46:06 SQLExecute: {HY000} Too many open cursors (either close
> other open cursors or increase the limit through
> ClientConnectorConfiguration.maxOpenCursorsPerConnection) [maximum=128,
> current=128]{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9541) Add the comparison for two general statistics "RunAll" for master in the date interval
[ https://issues.apache.org/jira/browse/IGNITE-9541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621993#comment-16621993 ] ASF GitHub Bot commented on IGNITE-9541: dspavlov commented on issue #9: IGNITE-9541 Add the comparison for two general statistics "RunAll" for master in the date interval URL: https://github.com/apache/ignite-teamcity-bot/pull/9#issuecomment-423176000 I've applied PR locally and tried it on existing DB. The result is a failure by not found build ``` 'Exception UncheckedIOException: java.io.FileNotFoundException: Service https://ci.ignite.apache.org/app/rest/latest/builds/id:1362502 returned not found error.Responding with error, status code: 404 (Not Found). Details: jetbrains.buildServer.server.rest.errors.NotFoundException: No build found by id '1362502'. Could not find the entity requested. Check the reference is correct and the user has permissions to access the entity. ``` It is quite normal TC Bot has reference to build, but TC don't have it (history in the bot is longer that in TC), so it is up to bot correctly handle absent REST requests. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add the comparison for two general statistics "RunAll" for master in the date > interval > -- > > Key: IGNITE-9541 > URL: https://issues.apache.org/jira/browse/IGNITE-9541 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolai Kulagin >Assignee: Nikolai Kulagin >Priority: Major > > Based on IGNITE-9333 add the comparison for two general statistics "RunAll" > for master in the date interval -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9399) Document new WAL history size configuration parameter
[ https://issues.apache.org/jira/browse/IGNITE-9399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov updated IGNITE-9399: --- Fix Version/s: 2.7 > Document new WAL history size configuration parameter > - > > Key: IGNITE-9399 > URL: https://issues.apache.org/jira/browse/IGNITE-9399 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Alexey Goncharuk >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8619) Remote node could not start in ssh connection
[
https://issues.apache.org/jira/browse/IGNITE-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621980#comment-16621980
]
Oleg Ignatenko commented on IGNITE-8619:
[~ivanan.fed] I re-checked [most recent revisions at
Github|https://github.com/1vanan/ignite/tree/IGNITE-8619] and these look OK
except for few relatively minor issues in
[IgniteProjectionStartStopRestartSelfTest|https://github.com/1vanan/ignite/blob/IGNITE-8619/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java]:
1) there is one unused import 2) first 6 lines in {{startCheckNodes()}} method
are incorrectly indented and 3) Intellij recommends to inline two last
parameters in {{startNodes}} method because these are always the same.
After above issues are addressed, strongly recommend to merge to master. (cc
[~NSAmelchev])
> Remote node could not start in ssh connection
> -
>
> Key: IGNITE-8619
> URL: https://issues.apache.org/jira/browse/IGNITE-8619
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Now there is a problem with launch remote node via ssh. Initially was an
> assumption that it's due to remote process has not enough time to write
> information into log:
> [IGNITE-8085|https://issues.apache.org/jira/browse/IGNITE-8085]. But this
> correction didn't fix [TeamCity
> |https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=testDetails]
> (IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls).
> So it's necessary to make launch remote node via ssh always succesful.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9657) socket leak in TcpDiscoverySpi
Evgenii Zhuravlev created IGNITE-9657: - Summary: socket leak in TcpDiscoverySpi Key: IGNITE-9657 URL: https://issues.apache.org/jira/browse/IGNITE-9657 Project: Ignite Issue Type: Bug Affects Versions: 2.6 Reporter: Evgenii Zhuravlev Assignee: Evgenii Zhuravlev Fix For: 2.7 When host from ipFinder can't be resolved, the socket don't close -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9637) SQL: Create suite for data load benchmarks
[ https://issues.apache.org/jira/browse/IGNITE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621954#comment-16621954 ] Pavel Kuznetsov commented on IGNITE-9637: - [~tledkov] Could you please take a look at the patch too? > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We want to have benchmark suite that measures how long it takes to upload > data to server. > There is existing benchmark code in org.apache.ignite.yardstick.upload > package > 1) Improve data model: > - Add indexes to data model. Number of indexes should be configurable. > - Add missing benchmark that performs putAll > 2) Define parameters to use in benchmarks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9637) SQL: Create suite for data load benchmarks
[ https://issues.apache.org/jira/browse/IGNITE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621954#comment-16621954 ] Pavel Kuznetsov edited comment on IGNITE-9637 at 9/20/18 12:47 PM: --- [~tledkov-gridgain] Could you please take a look at the patch too? was (Author: pkouznet): [~tledkov] Could you please take a look at the patch too? > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We want to have benchmark suite that measures how long it takes to upload > data to server. > There is existing benchmark code in org.apache.ignite.yardstick.upload > package > 1) Improve data model: > - Add indexes to data model. Number of indexes should be configurable. > - Add missing benchmark that performs putAll > 2) Define parameters to use in benchmarks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9030) Apache Ignite 2.7 Linux packages version update
[ https://issues.apache.org/jira/browse/IGNITE-9030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621937#comment-16621937 ] ASF GitHub Bot commented on IGNITE-9030: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4439 > Apache Ignite 2.7 Linux packages version update > --- > > Key: IGNITE-9030 > URL: https://issues.apache.org/jira/browse/IGNITE-9030 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Blocker > Fix For: 2.7 > > > Update DEB and RPM packages' versions in Apache Ignite for the next version > (2.7) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9656) Automate RPM and DEB packages version increase on release
[
https://issues.apache.org/jira/browse/IGNITE-9656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621934#comment-16621934
]
Nikolay Izhikov commented on IGNITE-9656:
-
It should be done in {{update-versions.sh}}
> Automate RPM and DEB packages version increase on release
> -
>
> Key: IGNITE-9656
> URL: https://issues.apache.org/jira/browse/IGNITE-9656
> Project: Ignite
> Issue Type: Task
> Environment: RPM and DEB packages version increase after release
> should be automated and done in the same commit as pom.xml version are
> increased.
>Reporter: Peter Ivanov
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7855) ODBC: Support streaming mode
[ https://issues.apache.org/jira/browse/IGNITE-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621932#comment-16621932 ] Igor Sapego commented on IGNITE-7855: - [~tledkov-gridgain], my comments: 1. Thank you. 2. Added. 3. Removed. 4. Good catch. Fixed. 5. Well, I'd not consider it a bug, as I don't know how it's going to be used in future. Let's just leave it as is for now. > ODBC: Support streaming mode > > > Key: IGNITE-7855 > URL: https://issues.apache.org/jira/browse/IGNITE-7855 > Project: Ignite > Issue Type: New Feature > Components: odbc >Reporter: Vladimir Ozerov >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > We need to support streaming mode in the same way it is done for JDBC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9656) Automate RPM and DEB packages version increase on release
Peter Ivanov created IGNITE-9656: Summary: Automate RPM and DEB packages version increase on release Key: IGNITE-9656 URL: https://issues.apache.org/jira/browse/IGNITE-9656 Project: Ignite Issue Type: Task Environment: RPM and DEB packages version increase after release should be automated and done in the same commit as pom.xml version are increased. Reporter: Peter Ivanov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6173) SQL: do not start caches on client nodes
[
https://issues.apache.org/jira/browse/IGNITE-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621924#comment-16621924
]
Yury Gerzhedovich commented on IGNITE-6173:
---
[~tledkov-gridgain],
I've fixed all your rebukes.
But still investigate reason to use real return value instead of throw
exception inside H2TreeNoDataIndex#find
> SQL: do not start caches on client nodes
>
>
> Key: IGNITE-6173
> URL: https://issues.apache.org/jira/browse/IGNITE-6173
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: sql-stability
>
> When cache is started, this even is distributed through custom discovery
> message. Server nodes start the cache, client nodes do nothing until cache is
> requested explicitly. At the same time H2 database objects are created only
> when cache is really started.
> For this reason query parsing could lead to {{TABLE NOT FOUND}}, {{INDEX NOT
> FOUND}}, etc. errors. If such exception is observed, we force start of all
> known cache on a client and then retry. See
> {{GridCacheProcessor#createMissingQueryCaches}} method.
> First, client node cache start leads to another custom discovery message. So
> query performance may suffer. Second, this is not needed! We already have all
> necessary cache info in discovery.
> Let's try to find a way to use available discovery data and do not start
> cache on a client for SQL query execution.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9589) GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621884#comment-16621884
]
Amelchev Nikita commented on IGNITE-9589:
-
[~agoncharuk], thank you for comments,
I have removed sleep and added util static method that returns free port.
It checks communication ports with the help _new ServerSocket(port)_ to resolve
free port. TC tests are OK ([50 runs and
suite|https://ci.ignite.apache.org/viewLog.html?buildId=1912292=IgniteTests24Java8_Spi=testsInfo]).
Could you review, please?
> GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange is flaky in master
> ---
>
> Key: IGNITE-9589
> URL: https://issues.apache.org/jira/browse/IGNITE-9589
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> The test GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange fails
> periodicaly.
> From the logs, I see that the failure is caused by BindException. It causes
> node start fails because the test port range is 0.
> {noformat}
> [2018-09-13
> 04:06:20,060][ERROR][test-runner-#225862%tcp.GridTcpCommunicationSpiConfigSelfTest%][GridTcpCommunicationSpiConfigSelfTest]
> Failed to start manager: GridManagerAdapter [enabled=true,
> name=o.a.i.i.managers.communication.GridIoManager]
> class org.apache.ignite.IgniteCheckedException: Failed to get SPI attributes.
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.start(GridIoManager.java:262)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1755)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:975)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:673)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:598)
> at org.apache.ignite.Ignition.start(Ignition.java:323)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1370)
> at
> org.apache.ignite.spi.communication.tcp.GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange(GridTcpCommunicationSpiConfigSelfTest.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2177)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to
> initialize TCP server: 0.0.0.0/0.0.0.0
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:2137)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:261)
> ... 20 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to bind to
> any port within range [startPort=47100, portRange=0, locHost=0.0.0.0/0.0.0.0]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetNioServer(TcpCommunicationSpi.java:2450)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:2134)
> ... 21 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> initialize NIO selector.
> at
> org.apache.ignite.internal.util.nio.GridNioServer.createSelector(GridNioServer.java:988)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:342)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:97)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$Builder.build(GridNioServer.java:3669)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetNioServer(TcpCommunicationSpi.java:2415)
> ... 22 more
> Caused by: java.net.BindException: Address already in
[jira] [Commented] (IGNITE-9637) SQL: Create suite for data load benchmarks
[ https://issues.apache.org/jira/browse/IGNITE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621870#comment-16621870 ] Pavel Kuznetsov commented on IGNITE-9637: - created PR on GitHub https://github.com/apache/ignite/pull/4796 > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We want to have benchmark suite that measures how long it takes to upload > data to server. > There is existing benchmark code in org.apache.ignite.yardstick.upload > package > 1) Improve data model: > - Add indexes to data model. Number of indexes should be configurable. > - Add missing benchmark that performs putAll > 2) Define parameters to use in benchmarks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9637) SQL: Create suite for data load benchmarks
[ https://issues.apache.org/jira/browse/IGNITE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621868#comment-16621868 ] ASF GitHub Bot commented on IGNITE-9637: GitHub user pavel-kuznetsov opened a pull request: https://github.com/apache/ignite/pull/4796 IGNITE-9637: Suite for data load benchmarks You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9637 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4796.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 #4796 commit 6dfea795a7628c44b930b4f7cb097725e5d2260d Author: Pavel Kuznetsov Date: 2018-09-19T11:09:54Z ignite-9637: added indexes. "--idx-count" handles how many indexes there is in the data model. commit 71e93a1b32e18fb05183570875d3b6f8646cbfd9 Author: Pavel Kuznetsov Date: 2018-09-19T12:07:17Z ignite-9637: native putAll benchmark. commit 6f40922d883f38cf54abdca2bcada4a0b1fc5c55 Author: Pavel Kuznetsov Date: 2018-09-19T15:13:40Z ignite-9637: benchmark configuration draft. Created configuration for data load benchmarks run that contains one run of each benchmark with some "common" parameters. commit 27bbd1e3bc1d2440f796769d9ba1ba6da712dad7 Author: Pavel Kuznetsov Date: 2018-09-19T18:11:56Z ignite-9637: fixed streaming "ordered" option. "ordered"/"" instead of "ordered on"/"ordered off". By default ordered is now turned off. > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We want to have benchmark suite that measures how long it takes to upload > data to server. > There is existing benchmark code in org.apache.ignite.yardstick.upload > package > 1) Improve data model: > - Add indexes to data model. Number of indexes should be configurable. > - Add missing benchmark that performs putAll > 2) Define parameters to use in benchmarks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9655) SQL: Create benchmark suite for DML operations.
Pavel Kuznetsov created IGNITE-9655: --- Summary: SQL: Create benchmark suite for DML operations. Key: IGNITE-9655 URL: https://issues.apache.org/jira/browse/IGNITE-9655 Project: Ignite Issue Type: Task Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov Create benchmark configuration that contains benchmark runs for DML operations. 1) insert + delete 2) update (single, range with/without contention). Currently we have benchmark code for 1 and 2 without contention. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8507) SQL: Print a warning if SQL index inline size is not sufficient
[ https://issues.apache.org/jira/browse/IGNITE-8507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-8507: --- Assignee: Yury Gerzhedovich > SQL: Print a warning if SQL index inline size is not sufficient > --- > > Key: IGNITE-8507 > URL: https://issues.apache.org/jira/browse/IGNITE-8507 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Yury Gerzhedovich >Priority: Blocker > Fix For: 2.7 > > > "Inline size" is very important optimization. When not used secondary index > lookup may become extraordinary slow. > Let's print a warning when certain indexes cannot hold their values in index > pages, so that user can adjust index configuration accordingly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8580) Print page read/write metrics splitted by type
[ https://issues.apache.org/jira/browse/IGNITE-8580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-8580: --- Assignee: Yury Gerzhedovich > Print page read/write metrics splitted by type > -- > > Key: IGNITE-8580 > URL: https://issues.apache.org/jira/browse/IGNITE-8580 > Project: Ignite > Issue Type: Task > Components: persistence >Reporter: Vladimir Ozerov >Assignee: Yury Gerzhedovich >Priority: Major > Fix For: 2.7 > > > Currently it is impossible to track how many pages of a certain type were > read from or written to disk. This might be very useful for performance > tuning and debugging purposes. E.g. excessive page reads may highlight > missing SQL index. > We need to expose total read/write pages metrics splitted by page type (see > org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO#getType()). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9298) control.sh does not support SSL (org.apache.ignite.internal.commandline.CommandHandler)
[ https://issues.apache.org/jira/browse/IGNITE-9298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-9298: --- Fix Version/s: 2.7 > control.sh does not support SSL > (org.apache.ignite.internal.commandline.CommandHandler) > --- > > Key: IGNITE-9298 > URL: https://issues.apache.org/jira/browse/IGNITE-9298 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.6 >Reporter: Paul Anderson >Assignee: Paul Anderson >Priority: Major > Fix For: 2.7 > > Attachments: Arguments.patch, CommandHandler.patch > > > We required SSL on the connector port and to use control.sh to work with the > baseline configuration. > This morning I added support, see attached patches against 2.6.0 for > org/apache/ignite/internal/commandline/CommandHandler.java > org/apache/ignite/internal/commandline/Arguments.java > No tests, no docs. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9298) control.sh does not support SSL (org.apache.ignite.internal.commandline.CommandHandler)
[ https://issues.apache.org/jira/browse/IGNITE-9298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621817#comment-16621817 ] Dmitriy Pavlov commented on IGNITE-9298: I believe was is not intentionally reassigned, but by default, I'm for the first one to be applied. So [~deviljelly] I would appreciate your efforts to make this contribution perfect and I hope both [~a-polyakov] and [~ilyak] will be reviewers here. [~ilyak] please contact me once you're confident PR from Paul is ready for merge. > control.sh does not support SSL > (org.apache.ignite.internal.commandline.CommandHandler) > --- > > Key: IGNITE-9298 > URL: https://issues.apache.org/jira/browse/IGNITE-9298 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.6 >Reporter: Paul Anderson >Assignee: Paul Anderson >Priority: Major > Attachments: Arguments.patch, CommandHandler.patch > > > We required SSL on the connector port and to use control.sh to work with the > baseline configuration. > This morning I added support, see attached patches against 2.6.0 for > org/apache/ignite/internal/commandline/CommandHandler.java > org/apache/ignite/internal/commandline/Arguments.java > No tests, no docs. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9654) Test testJoinQueryUnstableTopology is flaky in master
Amelchev Nikita created IGNITE-9654:
---
Summary: Test testJoinQueryUnstableTopology is flaky in master
Key: IGNITE-9654
URL: https://issues.apache.org/jira/browse/IGNITE-9654
Project: Ignite
Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
The test
IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.testJoinQueryUnstableTopology
is flaky in master. [Example of
fail|https://ci.ignite.apache.org/viewLog.html?buildId=1910548=buildResultsDiv=IgniteTests24Java8_Queries1#testNameId-9054712716754027821].
Log:
{noformat}
java.lang.RuntimeException: Not all Ignite instances has been stopped. Please,
see log for details.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9298) control.sh does not support SSL (org.apache.ignite.internal.commandline.CommandHandler)
[ https://issues.apache.org/jira/browse/IGNITE-9298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621790#comment-16621790 ] Alexand Polyakov commented on IGNITE-9298: -- as you like, but at least in https://github.com/apache/ignite/pull/4684 I recommend adding a test using ssl (see https://github.com/apache/ignite/blob/a6f25a94aa0885b6fe7f63f638a4f0e67b4a4327/modules/core/SRC/test/Java/org/Apache/ignite/Util/GridCommandHandlerSslTest.java) > control.sh does not support SSL > (org.apache.ignite.internal.commandline.CommandHandler) > --- > > Key: IGNITE-9298 > URL: https://issues.apache.org/jira/browse/IGNITE-9298 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.6 >Reporter: Paul Anderson >Assignee: Paul Anderson >Priority: Major > Attachments: Arguments.patch, CommandHandler.patch > > > We required SSL on the connector port and to use control.sh to work with the > baseline configuration. > This morning I added support, see attached patches against 2.6.0 for > org/apache/ignite/internal/commandline/CommandHandler.java > org/apache/ignite/internal/commandline/Arguments.java > No tests, no docs. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9298) control.sh does not support SSL (org.apache.ignite.internal.commandline.CommandHandler)
[ https://issues.apache.org/jira/browse/IGNITE-9298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov reassigned IGNITE-9298: Assignee: Paul Anderson (was: Alexand Polyakov) > control.sh does not support SSL > (org.apache.ignite.internal.commandline.CommandHandler) > --- > > Key: IGNITE-9298 > URL: https://issues.apache.org/jira/browse/IGNITE-9298 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.6 >Reporter: Paul Anderson >Assignee: Paul Anderson >Priority: Major > Attachments: Arguments.patch, CommandHandler.patch > > > We required SSL on the connector port and to use control.sh to work with the > baseline configuration. > This morning I added support, see attached patches against 2.6.0 for > org/apache/ignite/internal/commandline/CommandHandler.java > org/apache/ignite/internal/commandline/Arguments.java > No tests, no docs. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-4575) Implement wrapper for enums based on H2 user value type
[ https://issues.apache.org/jira/browse/IGNITE-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621770#comment-16621770 ] Mikhail Cherkasov commented on IGNITE-4575: --- [~vozerov] , could you please take a look at this ticket, do we still have blockers from H2 side? if not, might be it makes sense to target it to further release 2.7 or 2.8? > Implement wrapper for enums based on H2 user value type > --- > > Key: IGNITE-4575 > URL: https://issues.apache.org/jira/browse/IGNITE-4575 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Alexander Paschenko >Priority: Major > Labels: sql-engine > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9298) control.sh does not support SSL (org.apache.ignite.internal.commandline.CommandHandler)
[ https://issues.apache.org/jira/browse/IGNITE-9298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621762#comment-16621762 ] Ilya Kasnacheev commented on IGNITE-9298: - [~a-polyakov] [~deviljelly] Can you please make one good commit of two problematic ones? I've commented the latter one. LGTM after fixes, but best to introduce good parts from 1st commit, such as logging > control.sh does not support SSL > (org.apache.ignite.internal.commandline.CommandHandler) > --- > > Key: IGNITE-9298 > URL: https://issues.apache.org/jira/browse/IGNITE-9298 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.6 >Reporter: Paul Anderson >Assignee: Alexand Polyakov >Priority: Major > Attachments: Arguments.patch, CommandHandler.patch > > > We required SSL on the connector port and to use control.sh to work with the > baseline configuration. > This morning I added support, see attached patches against 2.6.0 for > org/apache/ignite/internal/commandline/CommandHandler.java > org/apache/ignite/internal/commandline/Arguments.java > No tests, no docs. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9653) StopNodeOrHaltFailureHandlerTest.testJvmHalted has flaky failures on master branch
[
https://issues.apache.org/jira/browse/IGNITE-9653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov updated IGNITE-9653:
-
Affects Version/s: 2.6
> StopNodeOrHaltFailureHandlerTest.testJvmHalted has flaky failures on master
> branch
> --
>
> Key: IGNITE-9653
> URL: https://issues.apache.org/jira/browse/IGNITE-9653
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.ignite.failure.StopNodeOrHaltFailureHandlerTest.testJvmHalted(StopNodeOrHaltFailureHandlerTest.java:93)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9653) StopNodeOrHaltFailureHandlerTest.testJvmHalted has flaky failures on master branch
[
https://issues.apache.org/jira/browse/IGNITE-9653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov updated IGNITE-9653:
-
Ignite Flags: (was: Docs Required)
> StopNodeOrHaltFailureHandlerTest.testJvmHalted has flaky failures on master
> branch
> --
>
> Key: IGNITE-9653
> URL: https://issues.apache.org/jira/browse/IGNITE-9653
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.ignite.failure.StopNodeOrHaltFailureHandlerTest.testJvmHalted(StopNodeOrHaltFailureHandlerTest.java:93)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9653) StopNodeOrHaltFailureHandlerTest.testJvmHalted has flaky failures on master branch
[
https://issues.apache.org/jira/browse/IGNITE-9653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov updated IGNITE-9653:
-
Description:
{noformat}
junit.framework.AssertionFailedError
at
org.apache.ignite.failure.StopNodeOrHaltFailureHandlerTest.testJvmHalted(StopNodeOrHaltFailureHandlerTest.java:93)
{noformat}
was:
```
junit.framework.AssertionFailedError
at
org.apache.ignite.failure.StopNodeOrHaltFailureHandlerTest.testJvmHalted(StopNodeOrHaltFailureHandlerTest.java:93)
```
> StopNodeOrHaltFailureHandlerTest.testJvmHalted has flaky failures on master
> branch
> --
>
> Key: IGNITE-9653
> URL: https://issues.apache.org/jira/browse/IGNITE-9653
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.ignite.failure.StopNodeOrHaltFailureHandlerTest.testJvmHalted(StopNodeOrHaltFailureHandlerTest.java:93)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9653) StopNodeOrHaltFailureHandlerTest.testJvmHalted has flaky failures on master branch
Andrey Kuznetsov created IGNITE-9653: Summary: StopNodeOrHaltFailureHandlerTest.testJvmHalted has flaky failures on master branch Key: IGNITE-9653 URL: https://issues.apache.org/jira/browse/IGNITE-9653 Project: Ignite Issue Type: Bug Reporter: Andrey Kuznetsov Fix For: 2.8 ``` junit.framework.AssertionFailedError at org.apache.ignite.failure.StopNodeOrHaltFailureHandlerTest.testJvmHalted(StopNodeOrHaltFailureHandlerTest.java:93) ``` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7861) Web console: invalid column on Activity details modal
[ https://issues.apache.org/jira/browse/IGNITE-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621739#comment-16621739 ] Vasiliy Sisko commented on IGNITE-7861: --- Failed to reproduce. Please provide the steps to reproduce after creation of a new user. > Web console: invalid column on Activity details modal > - > > Key: IGNITE-7861 > URL: https://issues.apache.org/jira/browse/IGNITE-7861 > Project: Ignite > Issue Type: Bug >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > Attachments: Selection_094.png, screenshot-1.png, screenshot-2.png > > > Many items do not have right description -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7861) Web console: invalid column on Activity details modal
[ https://issues.apache.org/jira/browse/IGNITE-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-7861: - Assignee: Pavel Konstantinov (was: Vasiliy Sisko) > Web console: invalid column on Activity details modal > - > > Key: IGNITE-7861 > URL: https://issues.apache.org/jira/browse/IGNITE-7861 > Project: Ignite > Issue Type: Bug >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > Attachments: Selection_094.png, screenshot-1.png, screenshot-2.png > > > Many items do not have right description -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6173) SQL: do not start caches on client nodes
[
https://issues.apache.org/jira/browse/IGNITE-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621725#comment-16621725
]
Taras Ledkov commented on IGNITE-6173:
--
[~jooger], my comments:
- please review my minor changes;
- fix javadoc for {{GridCacheProcessor#startLazyCache}} also try to add more
info to differ {{startLazyCache}} and {{lazyCacheStart}};
- {{QueryUtils#typeForQueryEntity}} what for the {{GridKernalContext ctx}}
parameter is added? Looks like the kernal contexr is always available via
{{GridCacheContextInfo}}.
- May {{H2CacheUtils#checkAndInitLazyCache}} be moved to {{H2Utils}}? I cannot
see huge semantic difference between these utility methods.
- Why {{H2TreeNoDataIndex#find}} don't throw {{IgniteSQLException("Shouldn't be
invoked")}}? Is no-data index is really used to fetch data?
> SQL: do not start caches on client nodes
>
>
> Key: IGNITE-6173
> URL: https://issues.apache.org/jira/browse/IGNITE-6173
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: sql-stability
>
> When cache is started, this even is distributed through custom discovery
> message. Server nodes start the cache, client nodes do nothing until cache is
> requested explicitly. At the same time H2 database objects are created only
> when cache is really started.
> For this reason query parsing could lead to {{TABLE NOT FOUND}}, {{INDEX NOT
> FOUND}}, etc. errors. If such exception is observed, we force start of all
> known cache on a client and then retry. See
> {{GridCacheProcessor#createMissingQueryCaches}} method.
> First, client node cache start leads to another custom discovery message. So
> query performance may suffer. Second, this is not needed! We already have all
> necessary cache info in discovery.
> Let's try to find a way to use available discovery data and do not start
> cache on a client for SQL query execution.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9652) Fix `Missorted modifiers' according inspections profile`
Maxim Muzafarov created IGNITE-9652: --- Summary: Fix `Missorted modifiers' according inspections profile` Key: IGNITE-9652 URL: https://issues.apache.org/jira/browse/IGNITE-9652 Project: Ignite Issue Type: Bug Reporter: Maxim Muzafarov Assignee: Maxim Muzafarov New `Code Inspections` profile can be found \idea\ignite_inspections.xml. We need to fix rule `Missorted modifiers` in ignite-core module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
[ https://issues.apache.org/jira/browse/IGNITE-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621716#comment-16621716 ] ASF GitHub Bot commented on IGNITE-5553: Github user xtern closed the pull request at: https://github.com/apache/ignite/pull/3587 > Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error > - > > Key: IGNITE-5553 > URL: https://issues.apache.org/jira/browse/IGNITE-5553 > Project: Ignite > Issue Type: Bug > Components: data structures, persistence >Affects Versions: 2.1 >Reporter: Dmitriy Pavlov >Assignee: Pavel Pereslegin >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test, test-fail > Fix For: 2.7 > > > h2. Notes-4435 > When IgniteSet is restored from persistence, size of set is always 0, [link > to test > history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails]. > h2. Detailed description > Unlike *IgniteQueue* which uses separate cache key to store its size > *IgniteSet* stores it in a field of some class. > Test from the link above shows very clearly that after restoring memory state > from PDS all set values are restored correctly but size is lost. > h2. Proposed solution > One possible solution might be to do the same thing as *IgniteQueue* does: > size of *IgniteSet* must be stored is cache instead of volatile in-memory > fields of random classes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6346) Distributed set does not work in REPLICATED mode
[
https://issues.apache.org/jira/browse/IGNITE-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621715#comment-16621715
]
ASF GitHub Bot commented on IGNITE-6346:
Github user xtern closed the pull request at:
https://github.com/apache/ignite/pull/4711
> Distributed set does not work in REPLICATED mode
>
>
> Key: IGNITE-6346
> URL: https://issues.apache.org/jira/browse/IGNITE-6346
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: vk
>Priority: Major
> Attachments: Reproducer.java
>
>
> When {{IgniteSet}} is created with {{REPLICATED}} cache mode, any attempt to
> read it fails with exception:
> {noformat}
> Exception in thread "main" class org.apache.ignite.IgniteException: Cluster
> group is empty.
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:48)
> at ReplicatedSet.main(ReplicatedSet.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: class
> org.apache.ignite.internal.cluster.ClusterGroupEmptyCheckedException: Cluster
> group is empty.
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.execute0(GridCacheQueryAdapter.java:481)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.execute(GridCacheQueryAdapter.java:442)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetImpl.iterator0(GridCacheSetImpl.java:420)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetImpl.iterator(GridCacheSetImpl.java:375)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetProxy.iterator(GridCacheSetProxy.java:342)
> ... 6 more
> {noformat}
> To reproduce run the following code:
> {code}
> Ignition.start(new IgniteConfiguration().setIgniteInstanceName("server-1"));
> Ignition.start(new IgniteConfiguration().setIgniteInstanceName("server-2"));
> Ignition.setClientMode(true);
> Ignite ignite = Ignition.start();
> IgniteSet set = ignite.set("my-set", new
> CollectionConfiguration().setCacheMode(CacheMode.REPLICATED));
> for (String s : set) {
> System.out.println(s);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7251) Remove term "fabric" from Ignite deliverables
[
https://issues.apache.org/jira/browse/IGNITE-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621699#comment-16621699
]
Anton Vinogradov commented on IGNITE-7251:
--
[~vveider]
We already started RC creation and check due to scope freeze.
This check seems to be useless until this task merged.
> Remove term "fabric" from Ignite deliverables
> -
>
> Key: IGNITE-7251
> URL: https://issues.apache.org/jira/browse/IGNITE-7251
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Blocker
> Labels: important
> Fix For: 2.7
>
>
> Apache Ignite binary releases still include “fabric” word in their names:
> https://ignite.apache.org/download.cgi#binaries
> For instance, this is a full name of the previous release -
> apache-ignite-fabric-2.3.0-bin.
> It’s a little oversight on our side because the project has not been
> positioned as a fabric for a while.
> Remove “fabric” from the name and have the binary releases named as -
> {{apache-ignite-\{version}-bin}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9569) Web console: use $inject for DI instead of arrays
[
https://issues.apache.org/jira/browse/IGNITE-9569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Borisov reassigned IGNITE-9569:
Assignee: Alexey Kuznetsov (was: Ilya Borisov)
[~kuaw26] please review. I've also increased type coverage in places, partly as
an example of how to reference some Ignite service types.
> Web console: use $inject for DI instead of arrays
> -
>
> Key: IGNITE-9569
> URL: https://issues.apache.org/jira/browse/IGNITE-9569
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> To do:
> 1. Remove provider registration by array spread, like this:
> {code:java}
> .service(...serviceArray){code}
> Instead, use the canonical AngularJS approach:
> {code:java}
> .service('SeriveName', Service){code}
> 2. Do not use array Di syntax for exported symbols:
> {code:java}
> export ['IgniteVersion', 'Confirm', function directive (version,
> confirm){}]{code}
> Instead, use $inject property:
> {code:java}
> export function directive(version, confirm) {}
> directive.$inject = ['IgniteVersion', 'Confirm']{code}
>
> Motivation:
> The changes above will make older providers accessible to TypeScript, which
> in turn will allow to increase type coverage.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9569) Web console: use $inject for DI instead of arrays
[
https://issues.apache.org/jira/browse/IGNITE-9569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621588#comment-16621588
]
ASF GitHub Bot commented on IGNITE-9569:
GitHub user Klaster1 opened a pull request:
https://github.com/apache/ignite/pull/4794
IGNITE-9569 Web console: update DI approach and increase type coverage
@akuznetsov-gridgain please review.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9569
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4794.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 #4794
commit a43b3bac80f99ca1a741e460942efae5257d04b3
Author: Ilya Borisov
Date: 2018-09-19T10:03:10Z
IGNITE-9569 Update directives/service DI and types defined in app.js.
commit 45783bcac2fd28af77858299551cd3f59e8862df
Author: Ilya Borisov
Date: 2018-09-20T04:22:46Z
IGNITE-9569 Update more directives/service DI and types defined in app.js.
> Web console: use $inject for DI instead of arrays
> -
>
> Key: IGNITE-9569
> URL: https://issues.apache.org/jira/browse/IGNITE-9569
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> To do:
> 1. Remove provider registration by array spread, like this:
> {code:java}
> .service(...serviceArray){code}
> Instead, use the canonical AngularJS approach:
> {code:java}
> .service('SeriveName', Service){code}
> 2. Do not use array Di syntax for exported symbols:
> {code:java}
> export ['IgniteVersion', 'Confirm', function directive (version,
> confirm){}]{code}
> Instead, use $inject property:
> {code:java}
> export function directive(version, confirm) {}
> directive.$inject = ['IgniteVersion', 'Confirm']{code}
>
> Motivation:
> The changes above will make older providers accessible to TypeScript, which
> in turn will allow to increase type coverage.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
