[jira] [Assigned] (IGNITE-9680) Web console: add component for status output
[ https://issues.apache.org/jira/browse/IGNITE-9680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-9680: Assignee: Alexander Kalinin (was: Ilya Borisov) [~alexdel] please review. > Web console: add component for status output > > > Key: IGNITE-9680 > URL: https://issues.apache.org/jira/browse/IGNITE-9680 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexander Kalinin >Priority: Minor > > Create a component that output status: > 1. It should accept a list of possible statuses as an argument, each item > should specify label to display, model value, color (red, green or regular) > and whether to show an inline spinner or not. > 2. It should also accept status value as an argument. > 3. Given that same the status might be displayed in various places, provide a > way to omit repeating lengthy statuses list argument. Maybe a component > factory that binds statuses to a new component? > 4. The new component should be based on either _ignite-status_ component or > supersede it. > Use the new component in: > 1. Connected clusters dialog. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5935) MVCC TX: Tx recovery protocol
[ https://issues.apache.org/jira/browse/IGNITE-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-5935: --- Description: Transaction recovery procedure is initiated when near node failed before transaction was finished. In MVCC transactions _partition update counter_ modification is started on prepare phase. If a transaction was prepared at least on one node we need to finish _partition update counter_ modification consistently on all participating nodes. Also recovered transaction should be removed from active transactions list on mvcc coordinator. was: Transaction recovery procedure is initiated when near node failed before transaction was finished. In MVCC transactions _partition update counter_ modification is started on prepare phase. If a transaction was prepared at least on one node we need to finish _partition update counter_ modification consistently on all participating nodes. > MVCC TX: Tx recovery protocol > - > > Key: IGNITE-5935 > URL: https://issues.apache.org/jira/browse/IGNITE-5935 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Semen Boikov >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.7 > > > Transaction recovery procedure is initiated when near node failed before > transaction was finished. > In MVCC transactions _partition update counter_ modification is started on > prepare phase. If a transaction was prepared at least on one node we need to > finish _partition update counter_ modification consistently on all > participating nodes. > Also recovered transaction should be removed from active transactions list on > mvcc coordinator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9207) Update Web Console dependencies
[ https://issues.apache.org/jira/browse/IGNITE-9207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin updated IGNITE-9207: -- Remaining Estimate: 2h Original Estimate: 2h > Update Web Console dependencies > --- > > Key: IGNITE-9207 > URL: https://issues.apache.org/jira/browse/IGNITE-9207 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexander Kalinin >Priority: Major > Fix For: 2.7 > > Original Estimate: 2h > Remaining Estimate: 2h > > Update package.json to latest versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9552) Web console: add TypeScript support
[ https://issues.apache.org/jira/browse/IGNITE-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16628306#comment-16628306 ] Ilya Borisov commented on IGNITE-9552: -- Added support for unit tests written in TS. > Web console: add TypeScript support > --- > > Key: IGNITE-9552 > URL: https://issues.apache.org/jira/browse/IGNITE-9552 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.8 > > Original Estimate: 48h > Time Spent: 3.5h > Remaining Estimate: 13.75h > > What to do: > 1. ✔ Add TypeScript preset to babel config. > 2. ✔ Update webpack configs to load .ts files with babel-loader. > 3. ✔ Make sure eslint lint .ts files -- 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&focusedCommentId=16628303#comment-16628303 ] Nikolay Izhikov commented on IGNITE-8331: - Looks good to me. Hello, [~vozerov]. Can you take a look at new SQL error codes? Are they make sense to you? Declaration - https://github.com/apache/ignite/pull/4689/files#diff-5b413c984e074a6d507f37edb258d37eR110 Usage - https://github.com/apache/ignite/pull/4689/files#diff-7ceb1ea0d6263a418e6e49e70ce4bed3R599 > 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&focusedCommentId=16628303#comment-16628303 ] Nikolay Izhikov edited comment on IGNITE-8331 at 9/26/18 6:37 AM: -- Looks good to me. Hello, [~vozerov]. Can you take a look at new SQL error codes? Are they make sense to you? I want to merge this PR if you have no objections. Declaration - https://github.com/apache/ignite/pull/4689/files#diff-5b413c984e074a6d507f37edb258d37eR110 Usage - https://github.com/apache/ignite/pull/4689/files#diff-7ceb1ea0d6263a418e6e49e70ce4bed3R599 was (Author: nizhikov): Looks good to me. Hello, [~vozerov]. Can you take a look at new SQL error codes? Are they make sense to you? Declaration - https://github.com/apache/ignite/pull/4689/files#diff-5b413c984e074a6d507f37edb258d37eR110 Usage - https://github.com/apache/ignite/pull/4689/files#diff-7ceb1ea0d6263a418e6e49e70ce4bed3R599 > 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-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches
[
https://issues.apache.org/jira/browse/IGNITE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16628203#comment-16628203
]
Ignite TC Bot commented on IGNITE-7196:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Hadoop{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1942720]]
{color:#d04437}Platform C++ (Windows x86){color} [[tests 4 TIMEOUT , Out Of
Memory Error , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1942747]]
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionExp - 6,0%
fails in last 100 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionFloor - 6,0%
fails in last 100 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionLog - 6,0%
fails in last 100 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionDegrees -
5,0% fails in last 100 master runs.
{color:#d04437}PDS (Direct IO) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1942756]]
* IgnitePdsNativeIoTestSuite:
IgnitePdsDestroyCacheTest.testDestroyCachesAbruptly - 0,0% fails in last 100
master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1942804&buildTypeId=IgniteTests24Java8_RunAll]
> Exchange can stuck and wait while new node restoring state from disk and
> starting caches
>
>
> Key: IGNITE-7196
> URL: https://issues.apache.org/jira/browse/IGNITE-7196
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Maxim Muzafarov
>Priority: Critical
> Fix For: 2.7
>
>
> Exchange can stuck and wait while new node restoring state from disk and
> starting caches, there's a log snippet from a just joined new node that shows
> the issue:
> [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started
> exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0],
> crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1,
> customEvt=null, allowMerge=true]
> [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager]
> Resolved page store work directory:
> /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463
> [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager]
> Resolved write ahead log work directory:
> /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463
> [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager]
> Resolved write ahead log archive directory:
> /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463
> [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager]
> Started write-ahead log manager [mode=DEFAULT]
> [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl]
> Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4
> KiB, checkpointBuffer=100.0 MiB]
> [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl]
> Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6
> MiB, checkpointBuffer=896.0 MiB]
> [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
> Read checkpoint status
> [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin,
>
> endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin]
> [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
> Checking memory state [lastValidPos=FileWALPointer [idx=3582,
> fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer
> [idx=3629, fileOffset=50829700, len=9229, forceFlush=false],
> lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af]
> [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
> Ignite node stopped in the middle of checkpoint. Will restore memory state
> and finish checkpoint on node start.
> [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/172.31.20.209:48100,
> rmtAddr=/172.31.17.115:57148]
> [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
> Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af,
> pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229,
> forceFlush=false]]
> [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatab
[jira] [Created] (IGNITE-9695) Add a way to prevent per-cache WAL disabling in WalStateManager
Andrey Kuznetsov created IGNITE-9695:
Summary: Add a way to prevent per-cache WAL disabling in
WalStateManager
Key: IGNITE-9695
URL: https://issues.apache.org/jira/browse/IGNITE-9695
Project: Ignite
Issue Type: Task
Affects Versions: 2.6
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
Fix For: 2.8
When this prevention is on, {{WalStateManager.init()}} should return an
error-holding future immediately.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9540) MVCC TX: make cache invoke\invokeAll operations support Mvcc tx mode.
[ https://issues.apache.org/jira/browse/IGNITE-9540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627732#comment-16627732 ] ASF GitHub Bot commented on IGNITE-9540: GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/4832 IGNITE-9540: MVCC TX: make cache invoke\invokeAll operations support Mvcc tx mode. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9540 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4832.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 #4832 commit b7d84760eb8dde4b1a922b4ee54885e86644e858 Author: Andrey V. Mashenkov Date: 2018-09-06T07:45:56Z IGNITE-7764: WIP. Tests added. Signed-off-by: Andrey V. Mashenkov commit 98ba5dc4e99e571056f4c0d7061c87f68c0d0aff Author: Andrey V. Mashenkov Date: 2018-09-06T14:28:53Z IGNITE-7764: WIP. Fix Get\GetAll operations. Signed-off-by: Andrey V. Mashenkov commit b88c8b8aa37a493adb64e572e82e7e15c8be88e7 Author: Andrey V. Mashenkov Date: 2018-09-07T19:26:49Z IGNITE-7764: WIP. Fix Put\PutAll operations. Naive implementation, optimization needed. Signed-off-by: Andrey V. Mashenkov commit 09c0a2e8d321da968900af247f41b281cf505599 Author: Andrey V. Mashenkov Date: 2018-09-08T15:01:38Z IGNITE-7764: WIP. Fix test. Signed-off-by: Andrey V. Mashenkov commit 7971694048ab344353808072cbd8826ac958a48d Author: Andrey V. Mashenkov Date: 2018-09-10T10:06:06Z IGNITE-7764: WIP. Refactored query enlist futures. Generify query enlist futures. Signed-off-by: Andrey V. Mashenkov commit a06e80d0a3040e467163359016d5fb2cab8eb8a4 Author: Andrey V. Mashenkov Date: 2018-09-12T14:12:45Z IGNITE-7764: WIP. Implemented MVCC protocol for basic put\putAll\remove\removeAll operations. Signed-off-by: Andrey V. Mashenkov commit 043d42cda73c8d11ec270c8c5739f2d34d58d9fe Author: Andrey V. Mashenkov Date: 2018-09-12T16:33:10Z IGNITE-7764: WIP. Added tests to suite. Signed-off-by: Andrey V. Mashenkov commit 3dffd70991cd782197749575770187705f780c52 Author: Andrey V. Mashenkov Date: 2018-09-13T10:06:06Z IGNITE-7764: WIP. Added tests for remove\removeAll. Signed-off-by: Andrey V. Mashenkov commit bfeed7184bece6b05fac3f2dbcee9e221f50 Author: Andrey V. Mashenkov Date: 2018-09-13T12:20:14Z IGNITE-7764: WIP. Added tests for getAndPut\getAndRemove\putIfAbsent. Added muted test replace/getAndReplace. Signed-off-by: Andrey V. Mashenkov commit 7133ee487ce23a18b60f5fd9980db9a1bf204f25 Author: Andrey V. Mashenkov Date: 2018-09-13T14:07:10Z IGNITE-7764: WIP. Fix tests. Signed-off-by: Andrey V. Mashenkov commit 04925e8795a0db146aa9caf53e3aafadae4dea8c Author: Andrey V. Mashenkov Date: 2018-09-13T15:14:28Z IGNITE-7764: WIP. Mute tests. Signed-off-by: Andrey V. Mashenkov commit f06157575650f5948f5c94a696f546b087d6a455 Author: Andrey V. Mashenkov Date: 2018-09-13T17:52:54Z IGNITE-7764: WIP. Fixed putIfAbsent/replace/getAndReplace. Signed-off-by: Andrey V. Mashenkov commit 8f4bafadeb22e3a420090a674e1c803d3add16c9 Author: Andrey V. Mashenkov Date: 2018-09-14T15:19:39Z IGNITE-7764: WIP. Fixed putIfAbsent/replace/getAndReplace. Signed-off-by: Andrey V. Mashenkov commit 8de70951b5864484fb552087eecf08fa45ace39b Author: Andrey V. Mashenkov Date: 2018-09-14T15:36:00Z IGNITE-7764: WIP. Minor. Signed-off-by: Andrey V. Mashenkov commit bb8f375c9aed9d61a56b75513108e256b9c31a84 Author: Andrey V. Mashenkov Date: 2018-09-14T16:00:10Z IGNITE-7764: WIP. Enable Full API MVCC tests. Signed-off-by: Andrey V. Mashenkov commit a96a6e618bba269ef8c83185a352e5f6df2a1464 Author: Andrey V. Mashenkov Date: 2018-09-14T16:18:50Z IGNITE-7764: WIP. Minors & Styles. Signed-off-by: Andrey V. Mashenkov commit 7e5ca350360b56696f4238c97b5b8b7ee41d976f Author: Andrey V. Mashenkov Date: 2018-09-14T17:41:03Z IGNITE-7764: WIP. Minors. Signed-off-by: Andrey V. Mashenkov commit f65324b1c69458128b5f5a2a0917bc1fe49e2cc1 Author: Andrey V. Mashenkov Date: 2018-09-14T17:53:12Z IGNITE-7764: WIP. Minors after rebase. Signed-off-by: Andrey V. Mashenkov commit 83116012412a4f24de8df2b64d953385060e8724 Author: Andrey V. Mashenkov Date: 2018-09-17T09:25:37Z IGNITE-7764: WIP. Minors. Signed-off-by: Andrey V. Mashenkov commit 0bd02e8939010891854b856c8d77f7f49f13d651 Author: Andrey V. Mashenkov Date: 2018-09-17T10:10:17Z IGNITE-7764: WIP. Minors. Signed-off-by: Andrey V. Mashenkov c
[jira] [Commented] (IGNITE-9658) Add ability to disable memory deallocation on deactivation.
[
https://issues.apache.org/jira/browse/IGNITE-9658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627697#comment-16627697
]
Ignite TC Bot commented on IGNITE-9658:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=1933202]]
* exe: CancellationTest.TestTask - 0,0% fails in last 100 master runs.
{color:#d04437}PDS (Direct IO) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1939050]]
* IgnitePdsNativeIoTestSuite:
IgnitePdsCacheConfigurationFileConsistencyCheckTest.testCorruptedCacheConfigurationsValidation
- 0,0% fails in last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1933256&buildTypeId=IgniteTests24Java8_RunAll]
> 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
>Priority: Major
> 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] [Commented] (IGNITE-9693) Scale up wal compression workers to increase performance
[ https://issues.apache.org/jira/browse/IGNITE-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627695#comment-16627695 ] ASF GitHub Bot commented on IGNITE-9693: GitHub user ivandasch opened a pull request: https://github.com/apache/ignite/pull/4831 IGNITE-9693 wip. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9693 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4831.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 #4831 commit 905315d0bafb37dfb188945ae7c873490de24f8f Author: Ivan Daschinskiy Date: 2018-09-25T17:31:27Z IGNITE-9693 wip. > Scale up wal compression workers to increase performance > > > Key: IGNITE-9693 > URL: https://issues.apache.org/jira/browse/IGNITE-9693 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Kosarev >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9573) ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite
[ https://issues.apache.org/jira/browse/IGNITE-9573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627693#comment-16627693 ] ASF GitHub Bot commented on IGNITE-9573: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4755 > ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite > -- > > Key: IGNITE-9573 > URL: https://issues.apache.org/jira/browse/IGNITE-9573 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Due to proliferation of static fields in Zk and Security code it fails when a > part of suite and/or will cause other tests to fail. Needs to be fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9573) ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite
[ https://issues.apache.org/jira/browse/IGNITE-9573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-9573: --- Fix Version/s: 2.8 > ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite > -- > > Key: IGNITE-9573 > URL: https://issues.apache.org/jira/browse/IGNITE-9573 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Due to proliferation of static fields in Zk and Security code it fails when a > part of suite and/or will cause other tests to fail. Needs to be fixed. -- 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&focusedCommentId=16627658#comment-16627658
]
ASF GitHub Bot commented on IGNITE-9541:
asfgit closed pull request #18: IGNITE-9541 Hotfix for old cache
URL: https://github.com/apache/ignite-teamcity-bot/pull/18
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
index 33497bb..837a9dc 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
@@ -443,50 +443,59 @@ private boolean isHistoryAgeLessThanSecs(SuiteInBranch
key, int seconds, Expirab
idUntil = idUntil == -2 ? buildRefs.size() - 1 : idUntil;
}
-if (idSince == -1 || idUntil == -1)
-return Collections.emptyList();
-else if (idSince == -3 || idUntil == -3) {
+if (idSince == -3 || idUntil == -3) {
AtomicBoolean stopFilter = new AtomicBoolean();
AtomicBoolean addBuild = new AtomicBoolean();
-return buildRefs.stream()
-.filter(b -> {
-if (stopFilter.get())
-return addBuild.get();
-
-Build build = getBuild(b.href);
-
-if (build == null || build.isFakeStub())
-return false;
+return buildRefs.stream()
+.filter(b -> {
+if (stopFilter.get())
+return addBuild.get();
-Date date = build.getFinishDate();
+Build build = getBuild(b.href);
-if (sinceDate != null && untilDate != null)
-return (date.after(sinceDate) ||
date.equals(sinceDate)) &&
-(date.before(untilDate) ||
date.equals(untilDate));
-else if (sinceDate != null) {
-if (date.after(sinceDate) ||
date.equals(sinceDate)) {
-stopFilter.set(true);
-addBuild.set(true);
+if (build == null || build.isFakeStub())
+return false;
-return true;
-}
+Date date = build.getFinishDate();
-return false;
-}
+if (sinceDate != null && untilDate != null)
+if ((date.after(sinceDate) ||
date.equals(sinceDate)) &&
+(date.before(untilDate) ||
date.equals(untilDate)))
+return true;
else {
if (date.after(untilDate)) {
stopFilter.set(true);
addBuild.set(false);
-
-return false;
}
+return false;
+}
+else if (sinceDate != null) {
+if (date.after(sinceDate) ||
date.equals(sinceDate)) {
+stopFilter.set(true);
+addBuild.set(true);
+
return true;
}
-})
-.collect(Collectors.toList());
-}
+
+return false;
+}
+else {
+if (date.after(untilDate)) {
+stopFilter.set(true);
+addBuild.set(false);
+
+return false;
+}
+
+return true;
+}
+})
+.collect(Collectors.toList());
+}
+else if (idSince == -1 || idUntil == -1)
+return Collections.emptyList();
else
return buildRefs.subList(idSince, idUntil + 1);
}
-
[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&focusedCommentId=16627643#comment-16627643 ] ASF GitHub Bot commented on IGNITE-9541: zzzadruga opened a new pull request #18: IGNITE-9541 Hotfix for old cache URL: https://github.com/apache/ignite-teamcity-bot/pull/18 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] [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&focusedCommentId=16627632#comment-16627632 ] Ilya Kasnacheev commented on IGNITE-9298: - [~deviljelly] please include the test from 2nd commit into your commit, or devise your own test which actually checks this functionality. There's also an issue of extra changes in the commit. > 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-9155) Exception during cluster state change terminates ExchangeWorker
[ https://issues.apache.org/jira/browse/IGNITE-9155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627624#comment-16627624 ] Eduard Shangareev commented on IGNITE-9155: --- Looks good. [~agoncharuk], [~DmitriyGovorukhin], guys, please help with merge. > Exception during cluster state change terminates ExchangeWorker > --- > > Key: IGNITE-9155 > URL: https://issues.apache.org/jira/browse/IGNITE-9155 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh >Priority: Major > > After IGNITE-8311 we throw an exception in ExchangeFuture instead swallowing > it. > ClusterStateChangeProcessor has it's own exception handling mechanism, which > doesn't require ExchangeWorker termination (and leaving node in broken state). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9155) Exception during cluster state change terminates ExchangeWorker
[ https://issues.apache.org/jira/browse/IGNITE-9155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627629#comment-16627629 ] Eduard Shangareev commented on IGNITE-9155: --- https://ci.ignite.apache.org/viewLog.html?buildId=1931985&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_RunAll > Exception during cluster state change terminates ExchangeWorker > --- > > Key: IGNITE-9155 > URL: https://issues.apache.org/jira/browse/IGNITE-9155 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh >Priority: Major > > After IGNITE-8311 we throw an exception in ExchangeFuture instead swallowing > it. > ClusterStateChangeProcessor has it's own exception handling mechanism, which > doesn't require ExchangeWorker termination (and leaving node in broken state). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9649) Rework logging in important places
[ https://issues.apache.org/jira/browse/IGNITE-9649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627607#comment-16627607 ] ASF GitHub Bot commented on IGNITE-9649: GitHub user Jokser opened a pull request: https://github.com/apache/ignite/pull/4830 IGNITE-9649 Debug logs enhacement You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9649 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4830.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 #4830 commit 2a20c08467a4a205fbe4ef901f6035439a0f2f4f Author: Pavel Kovalenko Date: 2018-09-20T14:55:16Z IGNITE-9649 WIP commit 4af3db3d844e56847cf59250c6e095526c643799 Author: Pavel Kovalenko Date: 2018-09-24T12:44:05Z IGNITE-9649 WIP commit 90f484c13ce4f55c450e6fcfaba720343af1a822 Author: Pavel Kovalenko Date: 2018-09-24T15:06:36Z IGNITE-9649 Move partition related abstractions to separate package. commit ff3754b6a07da68db55facec9a18f42b9e6bdb7d Author: Pavel Kovalenko Date: 2018-09-25T12:09:41Z IGNITE-9492 More logs. commit 21084513ac3b145c3068f63bd8cb9b1667223518 Author: Pavel Kovalenko Date: 2018-09-25T16:29:14Z IGNITE-9649 WIP > Rework logging in important places > -- > > Key: IGNITE-9649 > URL: https://issues.apache.org/jira/browse/IGNITE-9649 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.0 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.8 > > > Currently, we have insufficient, incomplete or too sufficient logs at DEBUG > and TRACE levels. > We should revisit and rework logging in important places of product: > 1) Partitions Map Exchange > 2) Rebalance > 3) Partitions workflow > 4) Time logging for critical places -- 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&focusedCommentId=16627599#comment-16627599
]
ASF GitHub Bot commented on IGNITE-9541:
asfgit closed pull request #17: IGNITE-9541 Hotfix
URL: https://github.com/apache/ignite-teamcity-bot/pull/17
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgniteTeamcityConnection.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgniteTeamcityConnection.java
index 9ddd68a..65ece8d 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgniteTeamcityConnection.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgniteTeamcityConnection.java
@@ -486,7 +486,8 @@ public String basicAuthToken() {
String branchFilter = isNullOrEmpty(branchName) ? "" :",branch:" +
branchName;
String sinceDateFilter = sinceDate == null ? "" : ",sinceDate:" +
getDateYyyyMmDdTHhMmSsZ(sinceDate);
String untilDateFilter = untilDate == null ? "" : ",untilDate:" +
getDateYyyyMmDdTHhMmSsZ(untilDate);
-String buildNoFilter = sinceBuildId == null ? "" : ",sinceBuild:(id:"
+ sinceBuildId + ")";
+String buildNoFilter = sinceBuildId == null ||
!(sinceDateFilter.isEmpty() && untilDateFilter.isEmpty()) ?
+"" : ",sinceBuild:(id:" + sinceBuildId + ")";
return sendGetXmlParseJaxb(host + "app/rest/latest/builds"
+ "?locator="
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-8738) Improve coordinator change information
[
https://issues.apache.org/jira/browse/IGNITE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-8738:
-
Fix Version/s: 2.7
> Improve coordinator change information
> --
>
> Key: IGNITE-8738
> URL: https://issues.apache.org/jira/browse/IGNITE-8738
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Evgenii Zagumennov
>Priority: Major
> Fix For: 2.7
>
> Time Spent: 16h
> Remaining Estimate: 0h
>
> When topology changes and coordinator is also changed, we need to print out
> this alongside with topology information.
> An example of such message:
> {{Coordinator changed [prev=node.tostring(), cur=node.tostr()]}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9686) JDK9: pass JVM options to new process when start remote test node
[
https://issues.apache.org/jira/browse/IGNITE-9686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627574#comment-16627574
]
ASF GitHub Bot commented on IGNITE-9686:
GitHub user tledkov-gridgain opened a pull request:
https://github.com/apache/ignite/pull/4829
IGNITE-9686: JDK9: pass jdk9 specific JVM options to new process when…
… start Ignite test node in separate JVM
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9686
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4829.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 #4829
commit 43c6300d1b226c6d0e0952311cff019ecc986d7a
Author: tledkov-gridgain
Date: 2018-09-25T16:07:23Z
IGNITE-9686: JDK9: pass jdk9 specific JVM options to new process when start
Ignite test node in separate JVM
> JDK9: pass JVM options to new process when start remote test node
> -
>
> Key: IGNITE-9686
> URL: https://issues.apache.org/jira/browse/IGNITE-9686
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> The JVM options must be passed to new process when remote test node is
> started.
> See {{GridAbstractTest#startRemoteGrid}} methods.
> Affects tests:
> {code}
> GridClosureProcessorRemoteTest
> IgniteHadoopFileSystemClientBasedOpenTest
> IgniteWalRecoveryTest
> IgniteWalRecoveryWithCompactionTest
> IgnitePdsRebalancingOnNotStableTopologyTest
> CacheScanQueryFailoverTest
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9691) AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize uses outdated assumption about exception message
[ https://issues.apache.org/jira/browse/IGNITE-9691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627545#comment-16627545 ] ASF GitHub Bot commented on IGNITE-9691: GitHub user oignatenko opened a pull request: https://github.com/apache/ignite/pull/4828 IGNITE-9691 testConcurrentAuthorize uses outdated assumption about exception message You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9691 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4828.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 #4828 commit 1eeca908a8076a8317947dac8a46845964d1d7ea Author: Oleg Ignatenko Date: 2018-08-23T13:13:28Z IGNITE-9348 ML examples improvements - wip (logging improved) -- verified with diffs overview, executing the examples and studying execution logs commit e50b89c392568ba9b93935c4fa6c7f7f93f5ec6f Author: Oleg Ignatenko Date: 2018-08-23T14:45:57Z Revert "IGNITE-9348 ML examples improvements" This reverts commit 1eeca908a8076a8317947dac8a46845964d1d7ea. commit 474024b4c5bbdb3c0a4ed2f0a66238c8054c6674 Author: Oleg Ignatenko Date: 2018-08-23T14:57:34Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 9642b233b5701bdad47ebea163079160227c582a Author: Oleg Ignatenko Date: 2018-08-28T14:01:11Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 7fc16d013ab725d2ff2e1a1b042c983f11d0c4d4 Author: Oleg Ignatenko Date: 2018-08-28T15:13:02Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit d2caba67b156674f051f50faebeafe0871bf0914 Author: Oleg Ignatenko Date: 2018-08-29T13:14:07Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 16775dff51d71ea68b4a3dea98be552130c493ed Author: Oleg Ignatenko Date: 2018-08-30T09:00:56Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit aedb59929974fe205b949225c1a338c68c60cfc8 Author: Oleg Ignatenko Date: 2018-08-30T09:42:38Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 39c6482fcdca506aa33011ed21c98060b4a8c68b Author: Oleg Ignatenko Date: 2018-08-30T11:28:05Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 33b32a2760a6559c78283b927e3191180d8ed9e1 Author: Oleg Ignatenko Date: 2018-08-30T12:31:16Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 9531028ddd1aef9e95f7e8c8b528086739bbb1b0 Author: Oleg Ignatenko Date: 2018-08-30T14:06:34Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 28f22c6e2fffcb82717ba5da7be2cfd39715c4e3 Author: Oleg Ignatenko Date: 2018-08-30T16:41:51Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit aacac88db519187413b0fc5ff9d0e55b8f8cff22 Author: Oleg Ignatenko Date: 2018-08-31T10:12:32Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 897f920dde46022849b13f9fb86dba8e54119a56 Author: Oleg Ignatenko Date: 2018-08-31T13:57:14Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 114c79e54c1b316006ccc3ff22d20d902f9313df Author: Oleg Ignatenko Date: 2018-08-31T17:39:16Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit fd6b659bb8be1992618ce4ce91f568a0988b3afa Author: Oleg Ignatenko Date: 2018-09-02T06:11:42Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 6ae6d1d3cf9743d8d466be0330511ddc8589e944 Author: Oleg Ignatenko Date: 2018-09-03T10:27:35Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit e8b27dbd3d0c1cbdb7a7659175f5c7bb447482bf Author: Oleg Ignatenko Date: 2018-09-04T09:49:44Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 622c82efdd0aa182fadea6b7ffa5d4615521a3f5 Author: Oleg Ignatenko Date: 2018-09-05T10:50:28Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit fb844fe3751e2e8ae87e6b8030b0e4bd659df9c2 Author: Oleg Ignatenko Date: 2018-09-05T11:45:58Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 480ed78869277d7e32f725ab71bec9621f1ac03a Author: Oleg Ignatenko Date: 2018-09-06T07:52:55Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit c99762498f617c0e98ea3062a43c0b30092166ef Author: Oleg Ignatenko Date: 2018-09-06T14:45:04Z Merge branch 'master' of https://github.com/apache/ignite into master-ml commit 2e17175225c72f747d370b5fee96f8be69d6
[jira] [Issue Comment Deleted] (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:all-tabpanel
]
Alexand Polyakov updated IGNITE-9549:
-
Comment: was deleted
(was: for documentation:
Сбор информации о распределении партиций.
control.sh cache distribution nodeId|null [cacheName1,...,cacheNameN]
[--user-attributes attributeName1[,...,attributeNameN]]
nodeId|null - должен быть указан идентификатор узла или null - запуск на всех
узлах
[cacheName1,...,cacheNameN] имя одного или нескольки кешей, параметр не
обязателен
[--user-attributes attributeName1[,...,attributeNameN]] - дополнительные
атрибуты которые будут считаны с узла
(org.apache.ignite.cluster.ClusterNode#attribute) и добавлены в результат
вывод cache distribution
[groupId,partition,nodeId,primary,state,updateCounter,partitionSize,nodeAddresses]
[next group: id=1544803905, name=default]
1544803905,0,12f01a16,B,OWNING,4,4,[127.0.0.1]
1544803905,0,3d85277a,P,OWNING,4,4,[127.0.0.1]
1544803905,1,12f01a16,P,OWNING,4,4,[127.0.0.1]
если настроен user-attributes то будут соответствующие дополнительные колонки
[groupId,partition,nodeId,primary,state,updateCounter,partitionSize,nodeAddresses,CELL,ZONE,DC]
[next group: id=1544803905, name=default]
1544803905,0,12f01a16,B,OWNING,4,4,[127.0.0.1],1,2,3
1544803905,0,3d85277a,P,OWNING,4,4,[127.0.0.1],1,2,1
1544803905,1,12f01a16,P,OWNING,4,4,[127.0.0.1],1,2,1
1544803905,1,3d85277a,B,OWNING,4,4,[127.0.0.1],1,2,3
partitionSize - количество элементов в партиции
Cброс LOST-партиций (org.apache.ignite.Ignite#resetLostPartitions)
control.sh cache reset_lost_partitions cacheName1[,...,cacheNameN]
cacheName1[,...,cacheNameN] - имена кешей, поле обязательно, минимум 1 кеш
вывод cache reset_lost_partitions
Reset LOST-partitions performed successfully. Cache group (name = 'default', id
= 1544803905), caches ([default]).
Reset LOST-partitions performed successfully. Cache group (name =
'ignite-sys-cache', id = -2100569601), caches ([ignite-sys-cache]))
> 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
> Fix For: 2.7
>
>
> 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-9305) Wrong off-heap size is reported for a node
[
https://issues.apache.org/jira/browse/IGNITE-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627539#comment-16627539
]
Dmitriy Pavlov commented on IGNITE-9305:
Thank you, [~xtern], it seems it is not related to the fix.
> Wrong off-heap size is reported for a node
> --
>
> Key: IGNITE-9305
> URL: https://issues.apache.org/jira/browse/IGNITE-9305
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Denis Magda
>Assignee: Pavel Pereslegin
>Priority: Blocker
> Fix For: 2.7
>
>
> Was troubleshooting an Ignite deployment today and couldn't find out from the
> logs what was the actual off-heap space used.
> Those were the given memory resoures (Ignite 2.6):
> {code}
> [2018-08-16 15:07:49,961][INFO ][main][GridDiscoveryManager] Topology
> snapshot [ver=1, servers=1, clients=0, CPUs=64, offheap=30.0GB, heap=24.0GB]
> {code}
> And that weird stuff was reported by the node (pay attention to the last
> line):
> {code}
> [2018-08-16 15:45:50,211][INFO
> ][grid-timeout-worker-#135%cluster_31-Dec-2017%][IgniteKernal%cluster_31-Dec-2017]
>
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=c033026e, name=cluster_31-Dec-2017, uptime=00:38:00.257]
> ^-- H/N/C [hosts=1, nodes=1, CPUs=64]
> ^-- CPU [cur=0.03%, avg=5.54%, GC=0%]
> ^-- PageMemory [pages=6997377]
> ^-- Heap [used=9706MB, free=61.18%, comm=22384MB]
> ^-- Non heap [used=144MB, free=-1%, comm=148MB] - this line is always the
> same!
> {code}
> Had to change the code by using
> {code}dataRegion.getPhysicalMemoryPages(){code} to find out that actual
> off-heap usage size was
> {code}
> >>> Physical Memory Size: 28651614208 => 27324 MB, 26 GB
> {code}
> The logs have to report the following instead:
> {code}
> ^-- Off-heap {Data Region 1} [used={dataRegion1.getPhysicalMemorySize()},
> free=X%, comm=dataRegion1.maxSize()]
> ^-- Off-heap {Data Region 2} [used={dataRegion2.getPhysicalMemorySize()},
> free=X%, comm=dataRegion2.maxSize()]
> {code}
> If Ignite persistence is enabled then the following extra lines have to be
> added to see the disk used space:
> {code}
> ^-- Ignite persistence {Data Region 1}:
> used={dataRegion1.getTotalAllocatedSize() -
> dataRegion1.getPhysicalMemorySize()}
> ^-- Ignite persistence {Data Region 2}
> [used={dataRegion2.getTotalAllocatedSize() -
> dataRegion2.getPhysicalMemorySize()}]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9305) Wrong off-heap size is reported for a node
[
https://issues.apache.org/jira/browse/IGNITE-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627537#comment-16627537
]
Pavel Pereslegin commented on IGNITE-9305:
--
[~dpavlov], I updated test results, but it seems like the "MVCC Queries" suite
is flaky.
> Wrong off-heap size is reported for a node
> --
>
> Key: IGNITE-9305
> URL: https://issues.apache.org/jira/browse/IGNITE-9305
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Denis Magda
>Assignee: Pavel Pereslegin
>Priority: Blocker
> Fix For: 2.7
>
>
> Was troubleshooting an Ignite deployment today and couldn't find out from the
> logs what was the actual off-heap space used.
> Those were the given memory resoures (Ignite 2.6):
> {code}
> [2018-08-16 15:07:49,961][INFO ][main][GridDiscoveryManager] Topology
> snapshot [ver=1, servers=1, clients=0, CPUs=64, offheap=30.0GB, heap=24.0GB]
> {code}
> And that weird stuff was reported by the node (pay attention to the last
> line):
> {code}
> [2018-08-16 15:45:50,211][INFO
> ][grid-timeout-worker-#135%cluster_31-Dec-2017%][IgniteKernal%cluster_31-Dec-2017]
>
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=c033026e, name=cluster_31-Dec-2017, uptime=00:38:00.257]
> ^-- H/N/C [hosts=1, nodes=1, CPUs=64]
> ^-- CPU [cur=0.03%, avg=5.54%, GC=0%]
> ^-- PageMemory [pages=6997377]
> ^-- Heap [used=9706MB, free=61.18%, comm=22384MB]
> ^-- Non heap [used=144MB, free=-1%, comm=148MB] - this line is always the
> same!
> {code}
> Had to change the code by using
> {code}dataRegion.getPhysicalMemoryPages(){code} to find out that actual
> off-heap usage size was
> {code}
> >>> Physical Memory Size: 28651614208 => 27324 MB, 26 GB
> {code}
> The logs have to report the following instead:
> {code}
> ^-- Off-heap {Data Region 1} [used={dataRegion1.getPhysicalMemorySize()},
> free=X%, comm=dataRegion1.maxSize()]
> ^-- Off-heap {Data Region 2} [used={dataRegion2.getPhysicalMemorySize()},
> free=X%, comm=dataRegion2.maxSize()]
> {code}
> If Ignite persistence is enabled then the following extra lines have to be
> added to see the disk used space:
> {code}
> ^-- Ignite persistence {Data Region 1}:
> used={dataRegion1.getTotalAllocatedSize() -
> dataRegion1.getPhysicalMemorySize()}
> ^-- Ignite persistence {Data Region 2}
> [used={dataRegion2.getTotalAllocatedSize() -
> dataRegion2.getPhysicalMemorySize()}]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9305) Wrong off-heap size is reported for a node
[
https://issues.apache.org/jira/browse/IGNITE-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627532#comment-16627532
]
Ignite TC Bot commented on IGNITE-9305:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Queries{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=1936881]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccPartitionedSqlCoordinatorFailoverTest.testReadInProgressCoordinatorFailsSimple_FromClient
- 0,0% fails in last 100 master runs.
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlCoordinatorFailoverTest.testReadInProgressCoordinatorFailsSimple_FromClient
- 0,0% fails in last 100 master runs.
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlTxQueriesWithReducerTest.testQueryReducerDeadlockInsert -
0,0% fails in last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1936882&buildTypeId=IgniteTests24Java8_RunAll]
> Wrong off-heap size is reported for a node
> --
>
> Key: IGNITE-9305
> URL: https://issues.apache.org/jira/browse/IGNITE-9305
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Denis Magda
>Assignee: Pavel Pereslegin
>Priority: Blocker
> Fix For: 2.7
>
>
> Was troubleshooting an Ignite deployment today and couldn't find out from the
> logs what was the actual off-heap space used.
> Those were the given memory resoures (Ignite 2.6):
> {code}
> [2018-08-16 15:07:49,961][INFO ][main][GridDiscoveryManager] Topology
> snapshot [ver=1, servers=1, clients=0, CPUs=64, offheap=30.0GB, heap=24.0GB]
> {code}
> And that weird stuff was reported by the node (pay attention to the last
> line):
> {code}
> [2018-08-16 15:45:50,211][INFO
> ][grid-timeout-worker-#135%cluster_31-Dec-2017%][IgniteKernal%cluster_31-Dec-2017]
>
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=c033026e, name=cluster_31-Dec-2017, uptime=00:38:00.257]
> ^-- H/N/C [hosts=1, nodes=1, CPUs=64]
> ^-- CPU [cur=0.03%, avg=5.54%, GC=0%]
> ^-- PageMemory [pages=6997377]
> ^-- Heap [used=9706MB, free=61.18%, comm=22384MB]
> ^-- Non heap [used=144MB, free=-1%, comm=148MB] - this line is always the
> same!
> {code}
> Had to change the code by using
> {code}dataRegion.getPhysicalMemoryPages(){code} to find out that actual
> off-heap usage size was
> {code}
> >>> Physical Memory Size: 28651614208 => 27324 MB, 26 GB
> {code}
> The logs have to report the following instead:
> {code}
> ^-- Off-heap {Data Region 1} [used={dataRegion1.getPhysicalMemorySize()},
> free=X%, comm=dataRegion1.maxSize()]
> ^-- Off-heap {Data Region 2} [used={dataRegion2.getPhysicalMemorySize()},
> free=X%, comm=dataRegion2.maxSize()]
> {code}
> If Ignite persistence is enabled then the following extra lines have to be
> added to see the disk used space:
> {code}
> ^-- Ignite persistence {Data Region 1}:
> used={dataRegion1.getTotalAllocatedSize() -
> dataRegion1.getPhysicalMemorySize()}
> ^-- Ignite persistence {Data Region 2}
> [used={dataRegion2.getTotalAllocatedSize() -
> dataRegion2.getPhysicalMemorySize()}]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9694) Do not block reading queries on exchange events that don't change data visibility
Ivan Bessonov created IGNITE-9694: - Summary: Do not block reading queries on exchange events that don't change data visibility Key: IGNITE-9694 URL: https://issues.apache.org/jira/browse/IGNITE-9694 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Assignee: Ivan Bessonov In current implementation there might be situations where reading operation waits, for example, exchange of client join event. Such events should not block read operations. In theory - the only operation that has to block reading (except for writing) is "node left" for server (or baseline server in case of persistent setup). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9381) p2p does not undeploy ScanQuery IgniteBiPredicate filter on client node disconnect
[ https://issues.apache.org/jira/browse/IGNITE-9381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627500#comment-16627500 ] Sergey Antonov edited comment on IGNITE-9381 at 9/25/18 3:23 PM: - [~agoncharuk], TC was finished running tests. The TC report looks good. was (Author: antonovsergey93): [~agoncharuk], TC was finished running test. The TC report looks good. > p2p does not undeploy ScanQuery IgniteBiPredicate filter on client node > disconnect > -- > > Key: IGNITE-9381 > URL: https://issues.apache.org/jira/browse/IGNITE-9381 > Project: Ignite > Issue Type: Bug >Reporter: Andrew Medvedev >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.7 > > Attachments: AndmedScanFilterClassLoadingTest.java, snapshots.xml > > > Once deployed via scan query, an IgniteBiPredicate filter does not change if > client reconnects (with a modified filter) > Steps to reproduce: > * start server node in separate jvm with attached configuration (persistence > enabled) > * run attached reproducer AndmedScanFilterClassLoadingTest. It includes a > task and a scan filter, both print "FOO" on server side > * modify FOO -> BAR for both > * re-run modifed AndmedScanFilterClassLoadingTest . > Expected: Both print "BAR". > Actual behavior: task prints "BAR", scan filter prints "FOO" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9686) JDK9: pass JVM options to new process when start remote test node
[
https://issues.apache.org/jira/browse/IGNITE-9686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-9686:
-
Description:
The JVM options must be passed to new process when remote test node is started.
See {{GridAbstractTest#startRemoteGrid}} methods.
Affects tests:
{code}
GridClosureProcessorRemoteTest
IgniteHadoopFileSystemClientBasedOpenTest
IgniteWalRecoveryTest
IgniteWalRecoveryWithCompactionTest
IgnitePdsRebalancingOnNotStableTopologyTest
CacheScanQueryFailoverTest
{code}
was:
The JVM options must be passed to new process when remote test node is started.
See {{GridAbstractTest#startRemoteGrid}} methods.
Affects tests:
{code}
GridClosureProcessorRemoteTest
IgniteHadoopFileSystemClientBasedOpenTest
IgniteWalRecoveryTest
IgniteWalRecoveryWithCompactionTest
IgnitePdsRebalancingOnNotStableTopologyTest
CacheScanQueryFailoverTest
{code}
> JDK9: pass JVM options to new process when start remote test node
> -
>
> Key: IGNITE-9686
> URL: https://issues.apache.org/jira/browse/IGNITE-9686
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> The JVM options must be passed to new process when remote test node is
> started.
> See {{GridAbstractTest#startRemoteGrid}} methods.
> Affects tests:
> {code}
> GridClosureProcessorRemoteTest
> IgniteHadoopFileSystemClientBasedOpenTest
> IgniteWalRecoveryTest
> IgniteWalRecoveryWithCompactionTest
> IgnitePdsRebalancingOnNotStableTopologyTest
> CacheScanQueryFailoverTest
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9381) p2p does not undeploy ScanQuery IgniteBiPredicate filter on client node disconnect
[ https://issues.apache.org/jira/browse/IGNITE-9381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627500#comment-16627500 ] Sergey Antonov commented on IGNITE-9381: [~agoncharuk], TC was finished running test. The TC report looks good. > p2p does not undeploy ScanQuery IgniteBiPredicate filter on client node > disconnect > -- > > Key: IGNITE-9381 > URL: https://issues.apache.org/jira/browse/IGNITE-9381 > Project: Ignite > Issue Type: Bug >Reporter: Andrew Medvedev >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.7 > > Attachments: AndmedScanFilterClassLoadingTest.java, snapshots.xml > > > Once deployed via scan query, an IgniteBiPredicate filter does not change if > client reconnects (with a modified filter) > Steps to reproduce: > * start server node in separate jvm with attached configuration (persistence > enabled) > * run attached reproducer AndmedScanFilterClassLoadingTest. It includes a > task and a scan filter, both print "FOO" on server side > * modify FOO -> BAR for both > * re-run modifed AndmedScanFilterClassLoadingTest . > Expected: Both print "BAR". > Actual behavior: task prints "BAR", scan filter prints "FOO" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9686) JDK9: pass JVM options to new process when start remote test node
[
https://issues.apache.org/jira/browse/IGNITE-9686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-9686:
-
Description:
The JVM options must be passed to new process when remote test node is started.
See {{GridAbstractTest#startRemoteGrid}} methods.
Affects tests:
{code}
GridClosureProcessorRemoteTest
IgniteHadoopFileSystemClientBasedOpenTest
IgniteWalRecoveryTest
IgniteWalRecoveryWithCompactionTest
IgnitePdsRebalancingOnNotStableTopologyTest
CacheScanQueryFailoverTest
{code}
was:
The JVM options must be passed to new process when remote test node is started.
See {{GridAbstractTest#startRemoteGrid}} methods.
Affects tests:
{code}
IgniteHadoopFileSystemClientBasedOpenTest
IgniteWalRecoveryTest
IgniteWalRecoveryWithCompactionTest
IgnitePdsRebalancingOnNotStableTopologyTest
CacheScanQueryFailoverTest
{code}
> JDK9: pass JVM options to new process when start remote test node
> -
>
> Key: IGNITE-9686
> URL: https://issues.apache.org/jira/browse/IGNITE-9686
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> The JVM options must be passed to new process when remote test node is
> started.
> See {{GridAbstractTest#startRemoteGrid}} methods.
> Affects tests:
> {code}
> GridClosureProcessorRemoteTest
> IgniteHadoopFileSystemClientBasedOpenTest
> IgniteWalRecoveryTest
> IgniteWalRecoveryWithCompactionTest
> IgnitePdsRebalancingOnNotStableTopologyTest
> CacheScanQueryFailoverTest
> {code}
--
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&focusedCommentId=16627484#comment-16627484
]
Alexand Polyakov commented on IGNITE-9549:
--
for documentation:
Сбор информации о распределении партиций.
control.sh cache distribution nodeId|null [cacheName1,...,cacheNameN]
[--user-attributes attributeName1[,...,attributeNameN]]
nodeId|null - должен быть указан идентификатор узла или null - запуск на всех
узлах
[cacheName1,...,cacheNameN] имя одного или нескольки кешей, параметр не
обязателен
[--user-attributes attributeName1[,...,attributeNameN]] - дополнительные
атрибуты которые будут считаны с узла
(org.apache.ignite.cluster.ClusterNode#attribute) и добавлены в результат
вывод cache distribution
[groupId,partition,nodeId,primary,state,updateCounter,partitionSize,nodeAddresses]
[next group: id=1544803905, name=default]
1544803905,0,12f01a16,B,OWNING,4,4,[127.0.0.1]
1544803905,0,3d85277a,P,OWNING,4,4,[127.0.0.1]
1544803905,1,12f01a16,P,OWNING,4,4,[127.0.0.1]
если настроен user-attributes то будут соответствующие дополнительные колонки
[groupId,partition,nodeId,primary,state,updateCounter,partitionSize,nodeAddresses,CELL,ZONE,DC]
[next group: id=1544803905, name=default]
1544803905,0,12f01a16,B,OWNING,4,4,[127.0.0.1],1,2,3
1544803905,0,3d85277a,P,OWNING,4,4,[127.0.0.1],1,2,1
1544803905,1,12f01a16,P,OWNING,4,4,[127.0.0.1],1,2,1
1544803905,1,3d85277a,B,OWNING,4,4,[127.0.0.1],1,2,3
partitionSize - количество элементов в партиции
Cброс LOST-партиций (org.apache.ignite.Ignite#resetLostPartitions)
control.sh cache reset_lost_partitions cacheName1[,...,cacheNameN]
cacheName1[,...,cacheNameN] - имена кешей, поле обязательно, минимум 1 кеш
вывод cache reset_lost_partitions
Reset LOST-partitions performed successfully. Cache group (name = 'default', id
= 1544803905), caches ([default]).
Reset LOST-partitions performed successfully. Cache group (name =
'ignite-sys-cache', id = -2100569601), caches ([ignite-sys-cache])
> 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
> Fix For: 2.7
>
>
> 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-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&focusedCommentId=16627472#comment-16627472 ] ASF GitHub Bot commented on IGNITE-9541: zzzadruga opened a new pull request #17: IGNITE-9541 Hotfix URL: https://github.com/apache/ignite-teamcity-bot/pull/17 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] [Assigned] (IGNITE-9247) CPP Thin: implement GetAll
[ https://issues.apache.org/jira/browse/IGNITE-9247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-9247: --- Assignee: Igor Sapego > CPP Thin: implement GetAll > -- > > Key: IGNITE-9247 > URL: https://issues.apache.org/jira/browse/IGNITE-9247 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Stanislav Lukyanov >Assignee: Igor Sapego >Priority: Major > > Need to implement GetAll in C++ Thin client. > Currently, there is no way to extract values from cache via C++ Thin client > without knowing the keys beforehand. GetAll would be the easiest way to do > that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9418) Avoid initialize file page store manager for caches during PME synchronously
[ https://issues.apache.org/jira/browse/IGNITE-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny reassigned IGNITE-9418: -- Assignee: Stanilovsky Evgeny > Avoid initialize file page store manager for caches during PME synchronously > > > Key: IGNITE-9418 > URL: https://issues.apache.org/jira/browse/IGNITE-9418 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Stanilovsky Evgeny >Priority: Critical > Fix For: 2.8 > > > Currently, we do creation for partition and index files during PME for > starting caches at the beginning of > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#readCheckpointAndRestoreMemory > method. > We should avoid this because sometimes it took a long time as we perform > writing to disk. > If the cache was registered during PME we should initialize page store lazy > or asynchronously. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9573) ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite
[ https://issues.apache.org/jira/browse/IGNITE-9573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627450#comment-16627450 ] Ilya Kasnacheev commented on IGNITE-9573: - [~dpavlov] can you please take it forward? > ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite > -- > > Key: IGNITE-9573 > URL: https://issues.apache.org/jira/browse/IGNITE-9573 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Minor > Labels: MakeTeamcityGreenAgain > > Due to proliferation of static fields in Zk and Security code it fails when a > part of suite and/or will cause other tests to fail. Needs to be fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9693) Scale up wal compression workers to increase performance
[ https://issues.apache.org/jira/browse/IGNITE-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-9693: - Summary: Scale up wal compression workers to increase performance (was: Scale up wal compression workers to increase perormance) > Scale up wal compression workers to increase performance > > > Key: IGNITE-9693 > URL: https://issues.apache.org/jira/browse/IGNITE-9693 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Kosarev >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9693) Scale up wal compression workers to increase perormance
[ https://issues.apache.org/jira/browse/IGNITE-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-9693: - Fix Version/s: 2.8 > Scale up wal compression workers to increase perormance > --- > > Key: IGNITE-9693 > URL: https://issues.apache.org/jira/browse/IGNITE-9693 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Kosarev >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9314) MVCC TX: Datastreamer operations
[
https://issues.apache.org/jira/browse/IGNITE-9314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9314:
Fix Version/s: (was: 2.7)
2.8
> MVCC TX: Datastreamer operations
>
>
> Key: IGNITE-9314
> URL: https://issues.apache.org/jira/browse/IGNITE-9314
> Project: Ignite
> Issue Type: Task
> Components: mvcc, sql
>Reporter: Igor Seliverstov
>Priority: Major
> Fix For: 2.8
>
>
> Need to change DataStreamer semantics (make it transactional)
> Currently clients can see DataStreamer partial writes and two subsequent
> selects, which are run in scope of one transaction at load time, may return
> different results.
> Related thread:
>
> [http://apache-ignite-developers.2346864.n4.nabble.com/MVCC-and-IgniteDataStreamer-td32340.html]
> Also there is a problem when {{DataStreamer}} with {{allowOverwrite ==
> false}} does not insert value when versions for entry exist but they all are
> aborted. Proper transactional semantics should developed for such case. After
> that attention should be put on Cache.size method behavior. Cache.size
> addressed in https://issues.apache.org/jira/browse/IGNITE-8149 could be
> decremented improperly in
> {{org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManager#mvccRemoveAll}}
> method (called during streamer processing) when all existing mvcc row
> versions are aborted or last committed one is _remove_ version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9644) SQL: local DML query should pin affected partitions
[ https://issues.apache.org/jira/browse/IGNITE-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9644: Fix Version/s: (was: 2.7) 2.8 > SQL: local DML query should pin affected partitions > --- > > Key: IGNITE-9644 > URL: https://issues.apache.org/jira/browse/IGNITE-9644 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Sergey Grimstad >Priority: Major > Fix For: 2.8 > > > Related to IGNITE-7039. Need to expand for DML. Commented out test market as > TODO: IGNITE-9644 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9643) [TC Bot] update cwiki
[ https://issues.apache.org/jira/browse/IGNITE-9643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryabov Dmitrii reassigned IGNITE-9643: -- Assignee: Ryabov Dmitrii > [TC Bot] update cwiki > - > > Key: IGNITE-9643 > URL: https://issues.apache.org/jira/browse/IGNITE-9643 > Project: Ignite > Issue Type: Task >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > > We need to update [wiki > page|https://cwiki.apache.org/confluence/display/IGNITE/Make+Teamcity+Green+Again#MakeTeamcityGreenAgain-MTCGABot] > with latest changes and new implemented features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9693) Scale up wal compression workers to increase perormance
[ https://issues.apache.org/jira/browse/IGNITE-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-9693: Assignee: Ivan Daschinskiy > Scale up wal compression workers to increase perormance > --- > > Key: IGNITE-9693 > URL: https://issues.apache.org/jira/browse/IGNITE-9693 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Kosarev >Assignee: Ivan Daschinskiy >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9693) Scale up wal compression workers to increase perormance
Sergey Kosarev created IGNITE-9693: -- Summary: Scale up wal compression workers to increase perormance Key: IGNITE-9693 URL: https://issues.apache.org/jira/browse/IGNITE-9693 Project: Ignite Issue Type: Improvement Reporter: Sergey Kosarev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches
[ https://issues.apache.org/jira/browse/IGNITE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627420#comment-16627420 ] Dmitriy Pavlov commented on IGNITE-7196: [~Mmuzaf] if all tests passed you can re-issue TC Bot visa and it will be green. > Exchange can stuck and wait while new node restoring state from disk and > starting caches > > > Key: IGNITE-7196 > URL: https://issues.apache.org/jira/browse/IGNITE-7196 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Maxim Muzafarov >Priority: Critical > Fix For: 2.7 > > > Exchange can stuck and wait while new node restoring state from disk and > starting caches, there's a log snippet from a just joined new node that shows > the issue: > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1, > customEvt=null, allowMerge=true] > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager] > Resolved page store work directory: > /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log work directory: > /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log archive directory: > /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Started write-ahead log manager [mode=DEFAULT] > [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4 > KiB, checkpointBuffer=100.0 MiB] > [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6 > MiB, checkpointBuffer=896.0 MiB] > [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Read checkpoint status > [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin, > > endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin] > [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Checking memory state [lastValidPos=FileWALPointer [idx=3582, > fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer > [idx=3629, fileOffset=50829700, len=9229, forceFlush=false], > lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af] > [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Ignite node stopped in the middle of checkpoint. Will restore memory state > and finish checkpoint on node start. > [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.17.115:57148] > [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af, > pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229, > forceFlush=false]] > [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Finished applying memory changes [changesApplied=165103, time=8189ms] > [21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.28.10:47964] > [21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.27.101:46000] > [21:36:33,019][WARNING][main][GridCachePartitionExchangeManager] Failed to > wait for initial partition map exchange. Possible reasons are: > ^-- Transactions in deadlock. > ^-- Long running transactions (ignore if this is the case). > ^-- Unreleased explicit locks. > [21:36:53,021][WARNING][main][GridCachePartitionExchangeManager] Still > waiting for initial partition map exchange > [fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent > [evtNode=TcpDiscoveryNode [id=3ac1160e-0de4-41bc-a366-59292c9f03c1, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.31.20.209], > sockAddrs
[jira] [Commented] (IGNITE-8485) TDE - Phase-1
[ https://issues.apache.org/jira/browse/IGNITE-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627410#comment-16627410 ] Vladimir Ozerov commented on IGNITE-8485: - [~NIzhikov], thank you. Now encryption part looks good to me. Need review from storage experts. > TDE - Phase-1 > - > > Key: IGNITE-8485 > URL: https://issues.apache.org/jira/browse/IGNITE-8485 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Critical > Fix For: 2.7 > > > Basic support for a Transparent Data Encryption should be implemented: > 1. Usage of standard JKS, Java Security. > 2. Persistent Data Encryption/Decryption. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9683) Create manual pinger for ZK client
[ https://issues.apache.org/jira/browse/IGNITE-9683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627411#comment-16627411 ] Pavel Kovalenko commented on IGNITE-9683: - Note: 1) Ready changes are available in branch ignite-2.5.1-p12-zk-pinger 2) Add configuration property to enable/disable pinger. > Create manual pinger for ZK client > -- > > Key: IGNITE-9683 > URL: https://issues.apache.org/jira/browse/IGNITE-9683 > Project: Ignite > Issue Type: Improvement > Components: cache, zookeeper >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Priority: Major > Fix For: 2.7 > > > Connection loss with Zookeeper more than ZK session timeout for server nodes > is unacceptable. To improve durability of connrction, we need to keep session > with ZK as long possible. We need to introduce manual pinger additionally to > ZK client and ping ZK server with simple request each tick time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9538) MVCC TX: Send partition update counters to backup nodes on prepare state.
[ https://issues.apache.org/jira/browse/IGNITE-9538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9538: Ignite Flags: (was: Docs Required) > MVCC TX: Send partition update counters to backup nodes on prepare state. > - > > Key: IGNITE-9538 > URL: https://issues.apache.org/jira/browse/IGNITE-9538 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Igor Seliverstov >Assignee: Roman Kondakov >Priority: Major > Fix For: 2.7 > > > There are several issues with partition update counters consistency in > transactional caches. The next approach solves most of them: > # Count per-partition updates > # on prepare state on primary node update current partition counter > incrementing it by per-partition updates count and send initial value with > updates count to backup nodes > # on backup nodes hold all pending updates and update partition update > counter applying the lowest gapless update (on tx finish). > # on historical rebalance use partition update counter as start point. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9492) Refactor processing SingleMessage with exchangeId==null
[ https://issues.apache.org/jira/browse/IGNITE-9492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627404#comment-16627404 ] Pavel Kovalenko commented on IGNITE-9492: - [~agoncharuk] Ignoring Full Message has been reworked. Now we accumulate and delay changes received from full messages with exchange id == null and apply changes after exchange is done. All tests have passed. Could you please look again? > Refactor processing SingleMessage with exchangeId==null > --- > > Key: IGNITE-9492 > URL: https://issues.apache.org/jira/browse/IGNITE-9492 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.7 > > > Currently, after each PME coordinator spend a lot of time on processing > correcting Single messages (with exchange id == null). This leads to growing > inbound/outbound messages queue and delaying other coordinator-aware > processes. > Processing single messages with exchange id == null are not so important to > give all available resources to it. We should limit the number of sys-threads > which are able to process such single messages. > We shouldn't create a big SingleMessages for each of partition state change > and use more shrinked/tiny messages for that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9418) Avoid initialize file page store manager for caches during PME synchronously
[ https://issues.apache.org/jira/browse/IGNITE-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627398#comment-16627398 ] ASF GitHub Bot commented on IGNITE-9418: GitHub user zstan opened a pull request: https://github.com/apache/ignite/pull/4827 IGNITE-9418 initialize cache persistent storage concurrently. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9418 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4827.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 #4827 commit 14a06ea3dea5cfc7cab9e499e8b54759554b36fd Author: Evgeny Stanilovskiy Date: 2018-09-25T13:49:29Z IGNITE-9418 initialize cache persistent storage concurrently. > Avoid initialize file page store manager for caches during PME synchronously > > > Key: IGNITE-9418 > URL: https://issues.apache.org/jira/browse/IGNITE-9418 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Priority: Critical > Fix For: 2.8 > > > Currently, we do creation for partition and index files during PME for > starting caches at the beginning of > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#readCheckpointAndRestoreMemory > method. > We should avoid this because sometimes it took a long time as we perform > writing to disk. > If the cache was registered during PME we should initialize page store lazy > or asynchronously. -- 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:
Fix Version/s: (was: 2.7)
2.8
> 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
> Fix For: 2.8
>
>
> The test
> IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.testJoinQueryUnstableTopology
> is flaky in master. [Example of
> fail|https://ci.ignite.apache.org/viewLog.html?buildId=1910548&tab=buildResultsDiv&buildTypeId=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] [Created] (IGNITE-9692) Cache creation request may be missed on coordinator change
Vyacheslav Daradur created IGNITE-9692: -- Summary: Cache creation request may be missed on coordinator change Key: IGNITE-9692 URL: https://issues.apache.org/jira/browse/IGNITE-9692 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.6 Reporter: Vyacheslav Daradur Attachments: CacheCreationOnCoordinatorChange.java Request of cache creation may be missed in case of coordinator change. Reproducer: [^CacheCreationOnCoordinatorChange.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7764) MVCC TX: make cache basic operations support Mvcc tx mode.
[ https://issues.apache.org/jira/browse/IGNITE-7764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627373#comment-16627373 ] Andrew Mashenkov commented on IGNITE-7764: -- [~vozerov], # I've fix "Contains" operations and add some tests. # For now, we always enlist updates in given order via setting "GridNearTxEnlistFuture.sequential" flag to true. This flag is always true for query updates as we do not know full data set at a time future has been created. For putAll (and other batch operations) full update map is known and we can make per-node batches full filled before send, but unordered updates can cause a deadlock and we have to discuss this optimization. Fixed and IGNITE-9688 was created. 3 & 4.Fixed. 5. IGNITE-9689 has been created. 6. IGNITE-9690 has been created. > MVCC TX: make cache basic operations support Mvcc tx mode. > -- > > Key: IGNITE-7764 > URL: https://issues.apache.org/jira/browse/IGNITE-7764 > Project: Ignite > Issue Type: New Feature > Components: mvcc, sql >Reporter: Roman Kondakov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.7 > > > We need to implement an MVCC-compatible locking protocol for Key-Value API. > At the moment during transactions with KV operations if entry we are going to > change is unlocked we do not check if it has been changed by the previous > transaction. See IGNITE-6935. > > Lets make get/getAll, put/PutAll/getAndPut, remove/removeAll/getAndRemove > operations consistent with SQL queries in MVCC mode at first > as it blocks many other tickets. Other operations can be implemented within > separate tickets in parallel once this ticket will be resolved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7764) MVCC TX: make cache basic operations support Mvcc tx mode.
[ https://issues.apache.org/jira/browse/IGNITE-7764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627373#comment-16627373 ] Andrew Mashenkov edited comment on IGNITE-7764 at 9/25/18 1:36 PM: --- [~vozerov], # I've fixed "Contains" operations and add some tests. # For now, we always enlist updates in given order via setting "GridNearTxEnlistFuture.sequential" flag to true. This flag is always true for query updates as we do not know full data set at a time future has been created. For putAll (and other batch operations) full update map is known and we can make per-node batches full filled before send, but unordered updates can cause a deadlock and we have to discuss this optimization. Fixed and IGNITE-9688 was created. 3 & 4.Fixed. 5. IGNITE-9689 has been created. 6. IGNITE-9690 has been created. was (Author: amashenkov): [~vozerov], # I've fix "Contains" operations and add some tests. # For now, we always enlist updates in given order via setting "GridNearTxEnlistFuture.sequential" flag to true. This flag is always true for query updates as we do not know full data set at a time future has been created. For putAll (and other batch operations) full update map is known and we can make per-node batches full filled before send, but unordered updates can cause a deadlock and we have to discuss this optimization. Fixed and IGNITE-9688 was created. 3 & 4.Fixed. 5. IGNITE-9689 has been created. 6. IGNITE-9690 has been created. > MVCC TX: make cache basic operations support Mvcc tx mode. > -- > > Key: IGNITE-7764 > URL: https://issues.apache.org/jira/browse/IGNITE-7764 > Project: Ignite > Issue Type: New Feature > Components: mvcc, sql >Reporter: Roman Kondakov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.7 > > > We need to implement an MVCC-compatible locking protocol for Key-Value API. > At the moment during transactions with KV operations if entry we are going to > change is unlocked we do not check if it has been changed by the previous > transaction. See IGNITE-6935. > > Lets make get/getAll, put/PutAll/getAndPut, remove/removeAll/getAndRemove > operations consistent with SQL queries in MVCC mode at first > as it blocks many other tickets. Other operations can be implemented within > separate tickets in parallel once this ticket will be resolved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches
[
https://issues.apache.org/jira/browse/IGNITE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627370#comment-16627370
]
Maxim Muzafarov commented on IGNITE-7196:
-
[~DmitriyGovorukhin]
I've re-run these suites:
[Cache 5 - #3864 (25 Sep 18
15:12)|https://ci.ignite.apache.org/viewLog.html?buildId=1939408&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Cache5]
– all tests passed.
[SPI - #3410 (25 Sep 18
03:46)|https://ci.ignite.apache.org/viewLog.html?buildId=1934176&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Spi]
– {{testNoServerOnHost}} test passed accoring suite report.
[SPI - #3425 (25 Sep 18
15:12)|https://ci.ignite.apache.org/viewLog.html?buildId=1939410&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Spi]
– some tests failed due to infrastructure problem - {{Caused by:
java.net.BindException: Address already in use}}
> Exchange can stuck and wait while new node restoring state from disk and
> starting caches
>
>
> Key: IGNITE-7196
> URL: https://issues.apache.org/jira/browse/IGNITE-7196
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Maxim Muzafarov
>Priority: Critical
> Fix For: 2.7
>
>
> Exchange can stuck and wait while new node restoring state from disk and
> starting caches, there's a log snippet from a just joined new node that shows
> the issue:
> [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started
> exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0],
> crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1,
> customEvt=null, allowMerge=true]
> [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager]
> Resolved page store work directory:
> /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463
> [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager]
> Resolved write ahead log work directory:
> /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463
> [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager]
> Resolved write ahead log archive directory:
> /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463
> [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager]
> Started write-ahead log manager [mode=DEFAULT]
> [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl]
> Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4
> KiB, checkpointBuffer=100.0 MiB]
> [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl]
> Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6
> MiB, checkpointBuffer=896.0 MiB]
> [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
> Read checkpoint status
> [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin,
>
> endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin]
> [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
> Checking memory state [lastValidPos=FileWALPointer [idx=3582,
> fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer
> [idx=3629, fileOffset=50829700, len=9229, forceFlush=false],
> lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af]
> [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
> Ignite node stopped in the middle of checkpoint. Will restore memory state
> and finish checkpoint on node start.
> [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/172.31.20.209:48100,
> rmtAddr=/172.31.17.115:57148]
> [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
> Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af,
> pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229,
> forceFlush=false]]
> [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
> Finished applying memory changes [changesApplied=165103, time=8189ms]
> [21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/172.31.20.209:48100,
> rmtAddr=/172.31.28.10:47964]
> [21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/172.31.20.209:48100,
> rmtAddr=/172.3
[jira] [Commented] (IGNITE-9573) ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite
[ https://issues.apache.org/jira/browse/IGNITE-9573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627369#comment-16627369 ] Ivan Bessonov commented on IGNITE-9573: --- [~ilyak] looks good, thank you! > ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite > -- > > Key: IGNITE-9573 > URL: https://issues.apache.org/jira/browse/IGNITE-9573 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Minor > Labels: MakeTeamcityGreenAgain > > Due to proliferation of static fields in Zk and Security code it fails when a > part of suite and/or will cause other tests to fail. Needs to be fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9691) AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize uses outdated assumption about exception message
[
https://issues.apache.org/jira/browse/IGNITE-9691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-9691:
---
Fix Version/s: 2.7
> AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize uses outdated
> assumption about exception message
> ---
>
> Key: IGNITE-9691
> URL: https://issues.apache.org/jira/browse/IGNITE-9691
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Test {{AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize}} that
> was introduced per IGNITE-7436 uses particular assumption about exception
> message thrown from method
> [GridIoManager.send|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/communication/GridIoManager.java]:
> {code}
> // Skip exception if server down.
> if (!e.getMessage().contains("Failed to send message
> (node may have left the grid or "
> + "TCP connection cannot be established due to
> firewall issues)")) {
> e.printStackTrace();
> fail("Unexpected exception: " + e.getMessage());
> }
> // ...{code}
> This expectation appears to be broken by changes introduced per IGNITE-4191
> which added yet another exception message that may occur in above piece of
> test code:
> {code}
> if (!ctx.discovery().alive(node))
> throw new ClusterTopologyCheckedException("Failed to send
> message, node left: " + node.id(), e);{code}
> (above code was added at line 1664 in {{GridIoManager.java}})
> Regression wasn't immediately discovered because of indeterministic test
> scenario which made new failures appear randomly and mixed with passes when
> particular condition was missed in the course of test execution.
> Test needs to be updated to accommodate the changes in codebase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9691) AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize uses outdated assumption about exception message
[
https://issues.apache.org/jira/browse/IGNITE-9691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-9691:
---
Ignite Flags: (was: Docs Required)
> AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize uses outdated
> assumption about exception message
> ---
>
> Key: IGNITE-9691
> URL: https://issues.apache.org/jira/browse/IGNITE-9691
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Test {{AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize}} that
> was introduced per IGNITE-7436 uses particular assumption about exception
> message thrown from method
> [GridIoManager.send|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/communication/GridIoManager.java]:
> {code}
> // Skip exception if server down.
> if (!e.getMessage().contains("Failed to send message
> (node may have left the grid or "
> + "TCP connection cannot be established due to
> firewall issues)")) {
> e.printStackTrace();
> fail("Unexpected exception: " + e.getMessage());
> }
> // ...{code}
> This expectation appears to be broken by changes introduced per IGNITE-4191
> which added yet another exception message that may occur in above piece of
> test code:
> {code}
> if (!ctx.discovery().alive(node))
> throw new ClusterTopologyCheckedException("Failed to send
> message, node left: " + node.id(), e);{code}
> (above code was added at line 1664 in {{GridIoManager.java}})
> Regression wasn't immediately discovered because of indeterministic test
> scenario which made new failures appear randomly and mixed with passes when
> particular condition was missed in the course of test execution.
> Test needs to be updated to accommodate the changes in codebase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9691) AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize uses outdated assumption about exception message
[
https://issues.apache.org/jira/browse/IGNITE-9691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko reassigned IGNITE-9691:
--
Assignee: Oleg Ignatenko
> AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize uses outdated
> assumption about exception message
> ---
>
> Key: IGNITE-9691
> URL: https://issues.apache.org/jira/browse/IGNITE-9691
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Test {{AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize}} that
> was introduced per IGNITE-7436 uses particular assumption about exception
> message thrown from method
> [GridIoManager.send|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/communication/GridIoManager.java]:
> {code}
> // Skip exception if server down.
> if (!e.getMessage().contains("Failed to send message
> (node may have left the grid or "
> + "TCP connection cannot be established due to
> firewall issues)")) {
> e.printStackTrace();
> fail("Unexpected exception: " + e.getMessage());
> }
> // ...{code}
> This expectation appears to be broken by changes introduced per IGNITE-4191
> which added yet another exception message that may occur in above piece of
> test code:
> {code}
> if (!ctx.discovery().alive(node))
> throw new ClusterTopologyCheckedException("Failed to send
> message, node left: " + node.id(), e);{code}
> (above code was added at line 1664 in {{GridIoManager.java}})
> Regression wasn't immediately discovered because of indeterministic test
> scenario which made new failures appear randomly and mixed with passes when
> particular condition was missed in the course of test execution.
> Test needs to be updated to accommodate the changes in codebase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9691) AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize uses outdated assumption about exception message
[
https://issues.apache.org/jira/browse/IGNITE-9691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-9691:
---
Labels: MakeTeamcityGreenAgain (was: )
> AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize uses outdated
> assumption about exception message
> ---
>
> Key: IGNITE-9691
> URL: https://issues.apache.org/jira/browse/IGNITE-9691
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Test {{AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize}} that
> was introduced per IGNITE-7436 uses particular assumption about exception
> message thrown from method
> [GridIoManager.send|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/communication/GridIoManager.java]:
> {code}
> // Skip exception if server down.
> if (!e.getMessage().contains("Failed to send message
> (node may have left the grid or "
> + "TCP connection cannot be established due to
> firewall issues)")) {
> e.printStackTrace();
> fail("Unexpected exception: " + e.getMessage());
> }
> // ...{code}
> This expectation appears to be broken by changes introduced per IGNITE-4191
> which added yet another exception message that may occur in above piece of
> test code:
> {code}
> if (!ctx.discovery().alive(node))
> throw new ClusterTopologyCheckedException("Failed to send
> message, node left: " + node.id(), e);{code}
> (above code was added at line 1664 in {{GridIoManager.java}})
> Regression wasn't immediately discovered because of indeterministic test
> scenario which made new failures appear randomly and mixed with passes when
> particular condition was missed in the course of test execution.
> Test needs to be updated to accommodate the changes in codebase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9691) AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize uses outdated assumption about exception message
Oleg Ignatenko created IGNITE-9691:
--
Summary:
AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize uses outdated
assumption about exception message
Key: IGNITE-9691
URL: https://issues.apache.org/jira/browse/IGNITE-9691
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Oleg Ignatenko
Test {{AuthenticationProcessorNodeRestartTest.testConcurrentAuthorize}} that
was introduced per IGNITE-7436 uses particular assumption about exception
message thrown from method
[GridIoManager.send|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/communication/GridIoManager.java]:
{code}
// Skip exception if server down.
if (!e.getMessage().contains("Failed to send message (node
may have left the grid or "
+ "TCP connection cannot be established due to firewall
issues)")) {
e.printStackTrace();
fail("Unexpected exception: " + e.getMessage());
}
// ...{code}
This expectation appears to be broken by changes introduced per IGNITE-4191
which added yet another exception message that may occur in above piece of test
code:
{code}
if (!ctx.discovery().alive(node))
throw new ClusterTopologyCheckedException("Failed to send
message, node left: " + node.id(), e);{code}
(above code was added at line 1664 in {{GridIoManager.java}})
Regression wasn't immediately discovered because of indeterministic test
scenario which made new failures appear randomly and mixed with passes when
particular condition was missed in the course of test execution.
Test needs to be updated to accommodate the changes in codebase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9690) MVCC: Check mvcc operations behavior with LOST partitions.
Andrew Mashenkov created IGNITE-9690: Summary: MVCC: Check mvcc operations behavior with LOST partitions. Key: IGNITE-9690 URL: https://issues.apache.org/jira/browse/IGNITE-9690 Project: Ignite Issue Type: Task Components: cache, mvcc Reporter: Andrew Mashenkov Fix For: 2.8 We have to analyze mvcc behaviour in case of lost partition for different lost policies for both cases SQL and KV API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9689) MVCC: Optimize filter usage in MvccUpdateDataRow.
[ https://issues.apache.org/jira/browse/IGNITE-9689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9689: - Fix Version/s: 2.8 > MVCC: Optimize filter usage in MvccUpdateDataRow. > - > > Key: IGNITE-9689 > URL: https://issues.apache.org/jira/browse/IGNITE-9689 > Project: Ignite > Issue Type: Improvement > Components: cache, mvcc >Reporter: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > PutIfAbsent and all Replace operation uses filter for previous values checks. > When filter has provided then we have to retrieve full row (instead of > header) just to apply the filter. > However, in most of cases filter doesn't need a value itself, but just a fact > if previous value exists. > There is unused class > org.apache.ignite.internal.processors.cache.CacheOperationFilter enum that > can be used for optimization. We can just compare filter type and visitor > resultType to make a decision in CacheDataStore.mvccUpdate\mvccRemove methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9689) MVCC: Optimize filter usage in MvccUpdateDataRow.
[ https://issues.apache.org/jira/browse/IGNITE-9689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9689: - Component/s: mvcc cache > MVCC: Optimize filter usage in MvccUpdateDataRow. > - > > Key: IGNITE-9689 > URL: https://issues.apache.org/jira/browse/IGNITE-9689 > Project: Ignite > Issue Type: Improvement > Components: cache, mvcc >Reporter: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > PutIfAbsent and all Replace operation uses filter for previous values checks. > When filter has provided then we have to retrieve full row (instead of > header) just to apply the filter. > However, in most of cases filter doesn't need a value itself, but just a fact > if previous value exists. > There is unused class > org.apache.ignite.internal.processors.cache.CacheOperationFilter enum that > can be used for optimization. We can just compare filter type and visitor > resultType to make a decision in CacheDataStore.mvccUpdate\mvccRemove methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9688) MVCC: Implement out-of-order enlist optimization for bulk cache operations.
[ https://issues.apache.org/jira/browse/IGNITE-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9688: - Fix Version/s: 2.8 > MVCC: Implement out-of-order enlist optimization for bulk cache operations. > --- > > Key: IGNITE-9688 > URL: https://issues.apache.org/jira/browse/IGNITE-9688 > Project: Ignite > Issue Type: Improvement > Components: cache, mvcc >Reporter: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > For now, we always enlist updates in given order via setting > "GridNearTxEnlistFuture.sequential" flag to true. > This flag is always true for query updates as we do not know full data set at > a time future has been created. > For putAll (and other batch operations) full update map is known and we can > make per-node batches full filled before send. > E.g. we can send batches to nodes one by one regarding primary node order. > This optimization has to be disscussed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9689) MVCC: Optimize filter usage in MvccUpdateDataRow.
[ https://issues.apache.org/jira/browse/IGNITE-9689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9689: - Ignite Flags: (was: Docs Required) > MVCC: Optimize filter usage in MvccUpdateDataRow. > - > > Key: IGNITE-9689 > URL: https://issues.apache.org/jira/browse/IGNITE-9689 > Project: Ignite > Issue Type: Improvement > Components: cache, mvcc >Reporter: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > PutIfAbsent and all Replace operation uses filter for previous values checks. > When filter has provided then we have to retrieve full row (instead of > header) just to apply the filter. > However, in most of cases filter doesn't need a value itself, but just a fact > if previous value exists. > There is unused class > org.apache.ignite.internal.processors.cache.CacheOperationFilter enum that > can be used for optimization. We can just compare filter type and visitor > resultType to make a decision in CacheDataStore.mvccUpdate\mvccRemove methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9689) MVCC: Optimize filter usage in MvccUpdateDataRow.
Andrew Mashenkov created IGNITE-9689: Summary: MVCC: Optimize filter usage in MvccUpdateDataRow. Key: IGNITE-9689 URL: https://issues.apache.org/jira/browse/IGNITE-9689 Project: Ignite Issue Type: Improvement Reporter: Andrew Mashenkov PutIfAbsent and all Replace operation uses filter for previous values checks. When filter has provided then we have to retrieve full row (instead of header) just to apply the filter. However, in most of cases filter doesn't need a value itself, but just a fact if previous value exists. There is unused class org.apache.ignite.internal.processors.cache.CacheOperationFilter enum that can be used for optimization. We can just compare filter type and visitor resultType to make a decision in CacheDataStore.mvccUpdate\mvccRemove methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9668) Comment JIRA from pr.html
[
https://issues.apache.org/jira/browse/IGNITE-9668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627350#comment-16627350
]
ASF GitHub Bot commented on IGNITE-9668:
asfgit closed pull request #16: IGNITE-9668 Comment JIRA from pr.html
URL: https://github.com/apache/ignite-teamcity-bot/pull/16
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
index e1b709e..0adf3fb 100644
--- a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
+++ b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
@@ -189,10 +189,7 @@ private BranchesTracked getTrackedBranches() {
return false;
}
-if ("finished".equals(build.state))
-return teamcity.sendJiraComment(ticket, comment);
-
-return false;
+return teamcity.sendJiraComment(ticket, comment);
}
}
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/rest/TriggerBuild.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/rest/TriggerBuild.java
index f5619ef..a4c66e6 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/rest/TriggerBuild.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/rest/TriggerBuild.java
@@ -98,7 +98,6 @@ public SimpleResult commentJira(
@NotNull
public SimpleResult commentJiraEx(@QueryParam("serverId") @Nullable String
srvId, @QueryParam("branchName") @Nullable String branchForTc,
@QueryParam("suiteId") @Nullable String suiteId, @QueryParam("ticketId")
@Nullable String ticketId) {
-System.out.println("commentJira ");
final ICredentialsProv prov = ICredentialsProv.get(req);
if (!prov.hasAccess(srvId))
diff --git a/ignite-tc-helper-web/src/main/webapp/js/testfails-2.1.js
b/ignite-tc-helper-web/src/main/webapp/js/testfails-2.1.js
index 67d5c18..7974fca 100644
--- a/ignite-tc-helper-web/src/main/webapp/js/testfails-2.1.js
+++ b/ignite-tc-helper-web/src/main/webapp/js/testfails-2.1.js
@@ -35,6 +35,10 @@ class Settings {
isGithubAvailable() {
return this.javaFlags & 2
};
+
+isJiraAvailable() {
+return this.javaFlags & 4
+};
}
//@param results - TestFailuresSummary
@@ -159,13 +163,22 @@ function showChainCurrentStatusData(server, settings) {
}
res += "";
-if (settings.isGithubAvailable()) {
-g_srv_to_notify_git = server;
-res += "Update PR status";
+
+// if (settings.isGithubAvailable()) {
+// g_srv_to_notify_git = server;
+// res += "Update PR status";
+// }
+
+if (settings.isJiraAvailable()) {
+res += "Comment JIRA";
}
if (isDefinedAndFilled(server.baseBranchForTc)) {
-if (settings.isGithubAvailable())
+// if (settings.isGithubAvailable())
+// res+="";
+
+if (settings.isJiraAvailable())
res+="";
res += "Base branch";
@@ -409,19 +422,43 @@ function commentJira(serverId, suiteId, branchName,
ticketId) {
"branchName": branchName,
"ticketId": ticketId
},
-success: function(result) {$("#notifyJira").html("");
+success: function(result) {
+$("#notifyJira").html("");
+
+var needTicketId = result.result.lastIndexOf("enter ticket id")
!== -1;
+
+if (needTicketId) {
+var buttons = {
+"Retry": function () {
+$(this).dialog("close");
+
+ticketId = $("#enterTicketId").val();
+
+commentJira(serverId, suiteId, branchName, ticketId)
+},
+"Cancel": function () {
+$(this).dialog("close");
+}
+}
+}
+else {
+buttons = {
+"Ok": function () {
+$(this).dialog("close");
+}
+}
+}
+
var dialog = $("#triggerDialog");
dialog.html("Trigger builds at server: " + serverId + "" +
-" Suite: " + suiteId + "Branch:" + branchName + "Top:
" +
-" Result: " + result.result);
+" Suite: " + suiteId + "Branch:" + branchName +
+" Result: " + result.result +
+(needTicketId ? ("Enter JIRA ticket number: ") : ""));
+
dialog.dialog({
modal: true,
-
[jira] [Commented] (IGNITE-8146) JDK9: IgniteUtils classLoaderUrls() JDK9 bug
[ https://issues.apache.org/jira/browse/IGNITE-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627344#comment-16627344 ] ASF GitHub Bot commented on IGNITE-8146: GitHub user tledkov-gridgain opened a pull request: https://github.com/apache/ignite/pull/4826 IGNITE-8146: JDK9: fix gathering class loader's URLs You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8146 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4826.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 #4826 commit 8424d7c66972985dbfea57943c97bc77b4d12f30 Author: tledkov-gridgain Date: 2018-09-25T13:10:17Z IGNITE-8146: JDK9: fix gathering class loader's URLs > JDK9: IgniteUtils classLoaderUrls() JDK9 bug > > > Key: IGNITE-8146 > URL: https://issues.apache.org/jira/browse/IGNITE-8146 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.4 >Reporter: Sujit Kumar Mahapatra >Assignee: Taras Ledkov >Priority: Trivial > Labels: jdk9 > Original Estimate: 48h > Remaining Estimate: 48h > > Reporting a probable miss that breaks JDK9 compatibility. > As part of [this > commit|https://github.com/apache/ignite/commit/ee2a6f7c3f2e3c9bd8dc61c8dbdf171e933d9481#diff-309ab4ef2fc61d6b2570d390acfb9bd6] > in > [ignite|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52]/modules/core/src/main/java/org/apache/ignite/internal/util/*IgniteUtils.java,* > below lines will throw *ClassCastException* in JDK9 during runtime. > _return ((URLClassLoader)urlClsLdrField.get(clsLdr)).getURLs();_ > > Here, _urlClsLdrField.get(clsLdr)_ return an object of type > "___java.base/jdk.internal.loader.URLClassPath_" which can't be cast to > "_URLClassLoader"._ > > The fix seems to be to introduce another reflection call to invoke _getURLs_ > method of the internal _URLClassPath_ class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8146) JDK9: IgniteUtils classLoaderUrls() JDK9 bug
[
https://issues.apache.org/jira/browse/IGNITE-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627342#comment-16627342
]
Taras Ledkov commented on IGNITE-8146:
--
The option {{--add-opens java.base/jdk.internal.loader=ALL-UNNAMED }} must be
added.
Full options list:
{code}
--add-opens java.base/jdk.internal.loader=ALL-UNNAMED
--add-exports java.base/jdk.internal.misc=ALL-UNNAMED
--add-exports java.base/sun.nio.ch=ALL-UNNAMED
--add-exports java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED
--add-exports jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
--add-exports java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED
--add-modules java.xml.bind
{code}
> JDK9: IgniteUtils classLoaderUrls() JDK9 bug
>
>
> Key: IGNITE-8146
> URL: https://issues.apache.org/jira/browse/IGNITE-8146
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.4
>Reporter: Sujit Kumar Mahapatra
>Assignee: Taras Ledkov
>Priority: Trivial
> Labels: jdk9
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Reporting a probable miss that breaks JDK9 compatibility.
> As part of [this
> commit|https://github.com/apache/ignite/commit/ee2a6f7c3f2e3c9bd8dc61c8dbdf171e933d9481#diff-309ab4ef2fc61d6b2570d390acfb9bd6]
> in
> [ignite|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52]/modules/core/src/main/java/org/apache/ignite/internal/util/*IgniteUtils.java,*
> below lines will throw *ClassCastException* in JDK9 during runtime.
> _return ((URLClassLoader)urlClsLdrField.get(clsLdr)).getURLs();_
>
> Here, _urlClsLdrField.get(clsLdr)_ return an object of type
> "___java.base/jdk.internal.loader.URLClassPath_" which can't be cast to
> "_URLClassLoader"._
>
> The fix seems to be to introduce another reflection call to invoke _getURLs_
> method of the internal _URLClassPath_ class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8146) JDK9: IgniteUtils classLoaderUrls() JDK9 bug
[
https://issues.apache.org/jira/browse/IGNITE-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627342#comment-16627342
]
Taras Ledkov edited comment on IGNITE-8146 at 9/25/18 1:13 PM:
---
The option {{--add-opens java.base/jdk.internal.loader=ALL-UNNAMED}} must be
added.
Full options list:
{code}
--add-opens java.base/jdk.internal.loader=ALL-UNNAMED
--add-exports java.base/jdk.internal.misc=ALL-UNNAMED
--add-exports java.base/sun.nio.ch=ALL-UNNAMED
--add-exports java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED
--add-exports jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
--add-exports java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED
--add-modules java.xml.bind
{code}
was (Author: tledkov-gridgain):
The option {{--add-opens java.base/jdk.internal.loader=ALL-UNNAMED }} must be
added.
Full options list:
{code}
--add-opens java.base/jdk.internal.loader=ALL-UNNAMED
--add-exports java.base/jdk.internal.misc=ALL-UNNAMED
--add-exports java.base/sun.nio.ch=ALL-UNNAMED
--add-exports java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED
--add-exports jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
--add-exports java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED
--add-modules java.xml.bind
{code}
> JDK9: IgniteUtils classLoaderUrls() JDK9 bug
>
>
> Key: IGNITE-8146
> URL: https://issues.apache.org/jira/browse/IGNITE-8146
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.4
>Reporter: Sujit Kumar Mahapatra
>Assignee: Taras Ledkov
>Priority: Trivial
> Labels: jdk9
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Reporting a probable miss that breaks JDK9 compatibility.
> As part of [this
> commit|https://github.com/apache/ignite/commit/ee2a6f7c3f2e3c9bd8dc61c8dbdf171e933d9481#diff-309ab4ef2fc61d6b2570d390acfb9bd6]
> in
> [ignite|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52]/modules/core/src/main/java/org/apache/ignite/internal/util/*IgniteUtils.java,*
> below lines will throw *ClassCastException* in JDK9 during runtime.
> _return ((URLClassLoader)urlClsLdrField.get(clsLdr)).getURLs();_
>
> Here, _urlClsLdrField.get(clsLdr)_ return an object of type
> "___java.base/jdk.internal.loader.URLClassPath_" which can't be cast to
> "_URLClassLoader"._
>
> The fix seems to be to introduce another reflection call to invoke _getURLs_
> method of the internal _URLClassPath_ class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-5935) MVCC TX: Tx recovery protocol
[ https://issues.apache.org/jira/browse/IGNITE-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-5935: --- Description: Transaction recovery procedure is initiated when near node failed before transaction was finished. In MVCC transactions _partition update counter_ modification is started on prepare phase. If a transaction was prepared at least on one node we need to finish _partition update counter_ modification consistently on all participating nodes. was: Tx recovery doesn't work properly for txs over MVCC enabled caches using Cache API. It requires MvccSnapshot which may not be acquired at recovery time. Need to implement logic for checking whether snapshot was already gotten by one of tx participants and use existing one, request and spread between participants a new snapshot otherwise. > MVCC TX: Tx recovery protocol > - > > Key: IGNITE-5935 > URL: https://issues.apache.org/jira/browse/IGNITE-5935 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Semen Boikov >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.7 > > > Transaction recovery procedure is initiated when near node failed before > transaction was finished. > In MVCC transactions _partition update counter_ modification is started on > prepare phase. If a transaction was prepared at least on one node we need to > finish _partition update counter_ modification consistently on all > participating nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9688) MVCC: Implement out-of-order enlist optimization for bulk cache operations.
Andrew Mashenkov created IGNITE-9688: Summary: MVCC: Implement out-of-order enlist optimization for bulk cache operations. Key: IGNITE-9688 URL: https://issues.apache.org/jira/browse/IGNITE-9688 Project: Ignite Issue Type: Improvement Components: cache, mvcc Reporter: Andrew Mashenkov For now, we always enlist updates in given order via setting "GridNearTxEnlistFuture.sequential" flag to true. This flag is always true for query updates as we do not know full data set at a time future has been created. For putAll (and other batch operations) full update map is known and we can make per-node batches full filled before send. E.g. we can send batches to nodes one by one regarding primary node order. This optimization has to be disscussed. -- 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&focusedCommentId=16627334#comment-16627334
]
ASF GitHub Bot commented on IGNITE-9541:
asfgit closed pull request #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
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
index 6be0446..4151793 100644
--- a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
+++ b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
@@ -18,6 +18,7 @@
package org.apache.ignite.ci;
import java.io.File;
+import java.util.Date;
import java.util.List;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutorService;
@@ -54,6 +55,7 @@
public interface ITeamcity extends AutoCloseable {
String DEFAULT = "";
+
long DEFAULT_BUILDS_COUNT = 1000;
CompletableFuture> getProjectSuites(String projectId);
@@ -61,45 +63,45 @@
String serverId();
/**
- * @param projectId suite ID (string without spaces)
- * @param branch
- * @return list of builds in historical order, recent builds coming last
+ * @param projectId Suite ID (string without spaces).
+ * @param branch Branch in TC identification.
+ * @return List of builds in historical order, recent builds coming last.
*/
default List getFinishedBuilds(String projectId, String branch) {
-return getFinishedBuilds(projectId, branch, null, null);
+return getFinishedBuilds(projectId, branch, null, null, null);
};
/**
* @param projectId suite ID (string without spaces).
* @param branch Branch name in TC identification.
- * @param cnt builds count.
+ * @param sinceDate Since date.
+ * @param untilDate Until date.
* @param sinceBuildId Some build ID in the past to to use as minimal
build to export.
* @return list of builds in historical order, recent builds coming last.
*/
-List getFinishedBuilds(String projectId, String branch, Long
cnt, Integer sinceBuildId);
+List getFinishedBuilds(String projectId, String branch, Date
sinceDate, Date untilDate, Integer sinceBuildId);
/**
- * Includes snapshot dependencies failed builds into list
+ * Includes snapshot dependencies failed builds into list.
*
- * @param projectId suite ID (string without spaces)
- * @param branch branch in TC identification
- * @return list of builds in historical order, recent builds coming last
+ * @param projectId suite ID (string without spaces).
+ * @param branch branch in TC identification.
+ * @return list of builds in historical order, recent builds coming last.
*/
default List getFinishedBuildsIncludeSnDepFailed(String
projectId, String branch){
-return getFinishedBuildsIncludeSnDepFailed(projectId, branch, null,
null);
+return getFinishedBuildsIncludeSnDepFailed(projectId, branch, null);
};
/**
* Includes 'snapshot dependencies failed' builds into list.
* loads build history with following parameter:
defaultFilter:false,state:finished
*
- * @param projectId suite ID (string without spaces)
- * @param branch branch in TC identification
- * @param cnt builds count
- * @param sinceBuildId limit builds export with some build number, not
operational for Persistent connection
- * @return list of builds in historical order, recent builds coming last
+ * @param projectId suite ID (string without spaces).
+ * @param branch branch in TC identification.
+ * @param sinceBuildId limit builds export with some build number, not
operational for Persistent connection.
+ * @return list of builds in historical order, recent builds coming last.
*/
-List getFinishedBuildsIncludeSnDepFailed(String projectId,
String branch, Long cnt, Integer sinceBuildId);
+List getFinishedBuildsIncludeSnDepFailed(String projectId,
String branch, Integer sinceBuildId);
/** */
CompletableFuture> getRunningBuilds(@Nullable String
branch);
@@ -107,8 +109,24 @@
/** */
CompletableFuture> getQueuedBuilds(@Nullable String branch);
-default int[] getBuildNumbersFromHistory(String projectId, String
branchNameForHist, Long cnt) {
-return getFinishedBuilds(projectId, branchNameForHist, cnt,
null).stream().mapToInt(BuildRef::getId).toArray();
+/**
+ * @pa
[jira] [Resolved] (IGNITE-7405) [ML] Distributed MLP cleanup/refactoring phase 2
[ https://issues.apache.org/jira/browse/IGNITE-7405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak resolved IGNITE-7405. Resolution: Won't Fix > [ML] Distributed MLP cleanup/refactoring phase 2 > > > Key: IGNITE-7405 > URL: https://issues.apache.org/jira/browse/IGNITE-7405 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.4 >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > Fix For: 2.7 > > > All refactoring which is not done in IGNITE-7350. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8679) Integration with tensorflow datasets
[ https://issues.apache.org/jira/browse/IGNITE-8679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak resolved IGNITE-8679. Resolution: Done Assignee: Anton Dmitriev (was: Artem Malykh) done via https://github.com/tensorflow/tensorflow/pull/22210 > Integration with tensorflow datasets > > > Key: IGNITE-8679 > URL: https://issues.apache.org/jira/browse/IGNITE-8679 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Anton Dmitriev >Priority: Major > Fix For: 2.7 > > > Add support of Apache Ignite caches as the source of data. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9432) Investigate ability to make ScanQuery faster
[ https://issues.apache.org/jira/browse/IGNITE-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-9432: --- Fix Version/s: (was: 2.7) 2.8 > Investigate ability to make ScanQuery faster > > > Key: IGNITE-9432 > URL: https://issues.apache.org/jira/browse/IGNITE-9432 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.7 >Reporter: Anton Dmitriev >Priority: Major > Fix For: 2.8 > > > When we make ScanQuery via Binary Client Protocol it works very slowly in > case we need to retrieve a big amount of objects (all objects in our case). > The most slower part is a waiting for response from Apache Ignite. This also > mentioned on devlist > [http://apache-ignite-developers.2346864.n4.nabble.com/How-to-reduce-Scan-Query-execution-time-td34212.html]. > To reproduce the problem we've prepared a small example: > [slow-scan-query-reproducer|https://github.com/dmitrievanthony/slow-scan-query-reproducer]. > In this example we creates a cache with 500 objects 1Mb each (on localhost), > we make ScanQuery with different page sizes and calculate time between the > moment when the request has been sent and the moment when the response is > ready to be receive. The measurements are here: > Page size 5 Mb, waiting time 119.85 ± 6.72 ms > Page size 10 Mb, waiting time 157.70 ± 15.35 ms > Page size 20 Mb, waiting time 204.50 ± 19.18 ms > Page size 50 Mb, waiting time 264.70 ± 22.30 ms > Page size 100 Mb, waiting time 463.35 ± 17.12 ms > Page size 150 Mb, waiting time 672.50 ± 21.98 ms > As result we spend ~4ms per every megabyte on _something_. It means that we > will be able to achieve 250Mb/s throughput in best case. It's too slow, isn't > it? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9416) [ML] Update distribution approach for TensorFlow module
[ https://issues.apache.org/jira/browse/IGNITE-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak resolved IGNITE-9416. Resolution: Won't Fix will be done in https://issues.apache.org/jira/browse/IGNITE-9685 > [ML] Update distribution approach for TensorFlow module > --- > > Key: IGNITE-9416 > URL: https://issues.apache.org/jira/browse/IGNITE-9416 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.7 >Reporter: Anton Dmitriev >Priority: Major > Fix For: 2.7 > > > So far we package "ignite-tf.sh" into zip file in "ignite-tensorflow" module. > We need to define right approach to do it so that users are able to use it > easily the same way as other Ignite command line tools. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7593) Improve data used in DecisionTreesExample
[
https://issues.apache.org/jira/browse/IGNITE-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Babak updated IGNITE-7593:
---
Fix Version/s: (was: 2.7)
2.8
> Improve data used in DecisionTreesExample
> -
>
> Key: IGNITE-7593
> URL: https://issues.apache.org/jira/browse/IGNITE-7593
> Project: Ignite
> Issue Type: Task
> Components: ml
>Affects Versions: 2.4
>Reporter: Oleg Ignatenko
>Assignee: Artem Malykh
>Priority: Major
> Fix For: 2.8
>
>
> Data currently used in {{DecisionTreesExample}} looks not quite optimal:
> # It is large, as evidenced in the warning in javadocs: "It is recommended to
> start at least one node prior to launching this example if you intend to run
> it with default memory settings."
> # It makes example run for quite a long time.
> # It doesn't have license (likely meaning "all rights reserved" by default)
> which makes it troublesome to include in project sources so that current
> approach is to prompt user to download it, additionally complicated by making
> example skip when run unattended from {{IgniteExamplesMLTestSuite}}.
> Suggest to find or construct a smaller data for this example which would
> still make sense to demonstrate how algorithm works and in the same time
> would be 1) easier on memory usage, 2) quicker to run and 3) would allow
> carrying it within project instead of prompting user to download it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9415) [ML] Using sparce vectors in LSQR and MLP
[ https://issues.apache.org/jira/browse/IGNITE-9415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-9415: --- Fix Version/s: (was: 2.7) 2.8 > [ML] Using sparce vectors in LSQR and MLP > - > > Key: IGNITE-9415 > URL: https://issues.apache.org/jira/browse/IGNITE-9415 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Alexey Platonov >Priority: Minor > Fix For: 2.8 > > > We need to investigate and apply sparce vectors support in BLAS for LSQR and > MLP (or implement own version) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9514) [ML] Reduce time for the updating models on many partitions
[ https://issues.apache.org/jira/browse/IGNITE-9514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627296#comment-16627296 ] ASF GitHub Bot commented on IGNITE-9514: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4788 > [ML] Reduce time for the updating models on many partitions > --- > > Key: IGNITE-9514 > URL: https://issues.apache.org/jira/browse/IGNITE-9514 > Project: Ignite > Issue Type: Task > Components: ml >Affects Versions: 2.7 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9683) Create manual pinger for ZK client
[ https://issues.apache.org/jira/browse/IGNITE-9683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627284#comment-16627284 ] Andrey Kuznetsov edited comment on IGNITE-9683 at 9/25/18 12:51 PM: [~Jokser], Zookeeper docs [1] mention ping requests built into Zk client: "The session is kept alive by requests sent by the client. If the session is idle for a period of time that would timeout the session, the client will send a PING request to keep the session alive. This PING request not only allows the ZooKeeper server to know that the client is still active, but it also allows the client to verify that its connection to the ZooKeeper server is still active. The timing of the PING is conservative enough to ensure reasonable time to detect a dead connection and reconnect to a new server." Is this statement outdated, or "reasonable time" is not suitable for Discovery SPI? [1] https://zookeeper.apache.org/doc/r3.4.13/zookeeperProgrammers.html was (Author: andrey-kuznetsov): [~Jokser], Zookeeper docs [1] mention ping requests built into Zk client: "The session is kept alive by requests sent by the client. If the session is idle for a period of time that would timeout the session, the client will send a PING request to keep the session alive. This PING request not only allows the ZooKeeper server to know that the client is still active, but it also allows the client to verify that its connection to the ZooKeeper server is still active. The timing of the PING is conservative enough to ensure reasonable time to detect a dead connection and reconnect to a new server." Is this statement outdated, or "reasonable time" is not suitable for Discovery SPI? > Create manual pinger for ZK client > -- > > Key: IGNITE-9683 > URL: https://issues.apache.org/jira/browse/IGNITE-9683 > Project: Ignite > Issue Type: Improvement > Components: cache, zookeeper >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Priority: Major > Fix For: 2.7 > > > Connection loss with Zookeeper more than ZK session timeout for server nodes > is unacceptable. To improve durability of connrction, we need to keep session > with ZK as long possible. We need to introduce manual pinger additionally to > ZK client and ping ZK server with simple request each tick time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9683) Create manual pinger for ZK client
[
https://issues.apache.org/jira/browse/IGNITE-9683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627284#comment-16627284
]
Andrey Kuznetsov edited comment on IGNITE-9683 at 9/25/18 12:51 PM:
[~Jokser], Zookeeper docs [1] mention ping requests built into Zk client:
"The session is kept alive by requests sent by the client. If the session is
idle for a period of time that would timeout the session, the client will send
a PING request to keep the session alive. This PING request not only allows the
ZooKeeper server to know that the client is still active, but it also allows
the client to verify that its connection to the ZooKeeper server is still
active. The timing of the PING is conservative enough to ensure reasonable time
to detect a dead connection and reconnect to a new server."
Is this statement outdated, or "reasonable time" is not suitable for Discovery
SPI?
was (Author: andrey-kuznetsov):
[~Jokser], Zookeeper docs [1] mention ping requests built into Zk client:
{noformat}
The session is kept alive by requests sent by the client. If the session is
idle for a period of time that would timeout the session, the client will send
a PING request to keep the session alive. This PING request not only allows the
ZooKeeper server to know that the client is still active, but it also allows
the client to verify that its connection to the ZooKeeper server is still
active. The timing of the PING is conservative enough to ensure reasonable time
to detect a dead connection and reconnect to a new server.
{noformat}
Is this statement outdated, or "reasonable time" is not suitable for Discovery
SPI?
> Create manual pinger for ZK client
> --
>
> Key: IGNITE-9683
> URL: https://issues.apache.org/jira/browse/IGNITE-9683
> Project: Ignite
> Issue Type: Improvement
> Components: cache, zookeeper
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Priority: Major
> Fix For: 2.7
>
>
> Connection loss with Zookeeper more than ZK session timeout for server nodes
> is unacceptable. To improve durability of connrction, we need to keep session
> with ZK as long possible. We need to introduce manual pinger additionally to
> ZK client and ping ZK server with simple request each tick time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9683) Create manual pinger for ZK client
[
https://issues.apache.org/jira/browse/IGNITE-9683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627284#comment-16627284
]
Andrey Kuznetsov commented on IGNITE-9683:
--
[~Jokser], Zookeeper docs [1] mention ping requests built into Zk client:
{noformat}
The session is kept alive by requests sent by the client. If the session is
idle for a period of time that would timeout the session, the client will send
a PING request to keep the session alive. This PING request not only allows the
ZooKeeper server to know that the client is still active, but it also allows
the client to verify that its connection to the ZooKeeper server is still
active. The timing of the PING is conservative enough to ensure reasonable time
to detect a dead connection and reconnect to a new server.
{noformat}
Is this statement outdated, or "reasonable time" is not suitable for Discovery
SPI?
> Create manual pinger for ZK client
> --
>
> Key: IGNITE-9683
> URL: https://issues.apache.org/jira/browse/IGNITE-9683
> Project: Ignite
> Issue Type: Improvement
> Components: cache, zookeeper
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Priority: Major
> Fix For: 2.7
>
>
> Connection loss with Zookeeper more than ZK session timeout for server nodes
> is unacceptable. To improve durability of connrction, we need to keep session
> with ZK as long possible. We need to introduce manual pinger additionally to
> ZK client and ping ZK server with simple request each tick time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9573) ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite
[ https://issues.apache.org/jira/browse/IGNITE-9573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627279#comment-16627279 ] Ilya Kasnacheev commented on IGNITE-9573: - [~ibessonov] thank you for noticing, I have replaced it with field. > ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite > -- > > Key: IGNITE-9573 > URL: https://issues.apache.org/jira/browse/IGNITE-9573 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Minor > Labels: MakeTeamcityGreenAgain > > Due to proliferation of static fields in Zk and Security code it fails when a > part of suite and/or will cause other tests to fail. Needs to be fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9414) [ML] Using sparce vectors in Tree-based algorithms.
[ https://issues.apache.org/jira/browse/IGNITE-9414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-9414: --- Fix Version/s: (was: 2.7) 2.8 > [ML] Using sparce vectors in Tree-based algorithms. > --- > > Key: IGNITE-9414 > URL: https://issues.apache.org/jira/browse/IGNITE-9414 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Alexey Platonov >Priority: Minor > Fix For: 2.8 > > > We need to support sparce vectors in DecisionTrees, RF, GDB -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9413) [ML] Learning rate optimization for GDB.
[ https://issues.apache.org/jira/browse/IGNITE-9413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-9413: --- Fix Version/s: (was: 2.7) 2.8 > [ML] Learning rate optimization for GDB. > > > Key: IGNITE-9413 > URL: https://issues.apache.org/jira/browse/IGNITE-9413 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.8 > > > We need to support learning rate optimization while training for MSE-loss and > Log-loss -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9687) JDK9: JTA tests failed
Taras Ledkov created IGNITE-9687:
Summary: JDK9: JTA tests failed
Key: IGNITE-9687
URL: https://issues.apache.org/jira/browse/IGNITE-9687
Project: Ignite
Issue Type: Task
Affects Versions: 2.6
Reporter: Taras Ledkov
Assignee: Taras Ledkov
JTA tests fail on JDK9 with error:
{{java.lang.NoClassDefFoundError: javax/rmi/PortableRemoteObject}}
the option {{--add-modules java.se.ee}}
changes the error to:
{{java.lang.NoClassDefFoundError: javax/transaction/UserTransaction}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9514) [ML] Reduce time for the updating models on many partitions
[ https://issues.apache.org/jira/browse/IGNITE-9514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-9514: - Affects Version/s: 2.7 Fix Version/s: 2.7 > [ML] Reduce time for the updating models on many partitions > --- > > Key: IGNITE-9514 > URL: https://issues.apache.org/jira/browse/IGNITE-9514 > Project: Ignite > Issue Type: Task > Components: ml >Affects Versions: 2.7 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8146) JDK9: IgniteUtils classLoaderUrls() JDK9 bug
[ https://issues.apache.org/jira/browse/IGNITE-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-8146: - Summary: JDK9: IgniteUtils classLoaderUrls() JDK9 bug (was: IgniteUtils classLoaderUrls() JDK9 bug) > JDK9: IgniteUtils classLoaderUrls() JDK9 bug > > > Key: IGNITE-8146 > URL: https://issues.apache.org/jira/browse/IGNITE-8146 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.4 >Reporter: Sujit Kumar Mahapatra >Assignee: Taras Ledkov >Priority: Trivial > Labels: jdk9 > Original Estimate: 48h > Remaining Estimate: 48h > > Reporting a probable miss that breaks JDK9 compatibility. > As part of [this > commit|https://github.com/apache/ignite/commit/ee2a6f7c3f2e3c9bd8dc61c8dbdf171e933d9481#diff-309ab4ef2fc61d6b2570d390acfb9bd6] > in > [ignite|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52]/modules/core/src/main/java/org/apache/ignite/internal/util/*IgniteUtils.java,* > below lines will throw *ClassCastException* in JDK9 during runtime. > _return ((URLClassLoader)urlClsLdrField.get(clsLdr)).getURLs();_ > > Here, _urlClsLdrField.get(clsLdr)_ return an object of type > "___java.base/jdk.internal.loader.URLClassPath_" which can't be cast to > "_URLClassLoader"._ > > The fix seems to be to introduce another reflection call to invoke _getURLs_ > method of the internal _URLClassPath_ class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9686) JDK9: pass JVM options to new process when start remote test node
[
https://issues.apache.org/jira/browse/IGNITE-9686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-9686:
-
Description:
The JVM options must be passed to new process when remote test node is started.
See {{GridAbstractTest#startRemoteGrid}} methods.
Affects tests:
{code}
IgniteHadoopFileSystemClientBasedOpenTest
IgniteWalRecoveryTest
IgniteWalRecoveryWithCompactionTest
IgnitePdsRebalancingOnNotStableTopologyTest
CacheScanQueryFailoverTest
{code}
was:
The JVM options must be passed to new process when remote test node is started.
See {{GridAbstractTest#startRemoteGrid}} methods.
Affects tests:
{code}
IgniteHadoopFileSystemClientBasedOpenTest
IgniteWalRecoveryTest
IgniteWalRecoveryWithCompactionTest
IgnitePdsRebalancingOnNotStableTopologyTest
CacheScanQueryFailoverTest
{code}
> JDK9: pass JVM options to new process when start remote test node
> -
>
> Key: IGNITE-9686
> URL: https://issues.apache.org/jira/browse/IGNITE-9686
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> The JVM options must be passed to new process when remote test node is
> started.
> See {{GridAbstractTest#startRemoteGrid}} methods.
> Affects tests:
> {code}
> IgniteHadoopFileSystemClientBasedOpenTest
> IgniteWalRecoveryTest
> IgniteWalRecoveryWithCompactionTest
> IgnitePdsRebalancingOnNotStableTopologyTest
> CacheScanQueryFailoverTest
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9686) JDK9: pass JVM options to new process when start remote test node
[
https://issues.apache.org/jira/browse/IGNITE-9686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-9686:
-
Description:
The JVM options must be passed to new process when remote test node is started.
See {{GridAbstractTest#startRemoteGrid}} methods.
Affects tests:
{code}
IgniteHadoopFileSystemClientBasedOpenTest
IgniteWalRecoveryTest
IgniteWalRecoveryWithCompactionTest
IgnitePdsRebalancingOnNotStableTopologyTest
CacheScanQueryFailoverTest
{code}
was:
The JVM options must be passed to new process when remote test node is started.
See {{GridAbstractTest#startRemoteGrid}},
{{org.apache.ignite.testframework.junits.GridAbstractTest#startRemoteGrid(java.lang.String,
org.apache.ignite.configuration.IgniteConfiguration,
org.apache.ignite.internal.processors.resource.GridSpringResourceContext)}}
Affects tests:
{code}
IgniteHadoopFileSystemClientBasedOpenTest
{code}
> JDK9: pass JVM options to new process when start remote test node
> -
>
> Key: IGNITE-9686
> URL: https://issues.apache.org/jira/browse/IGNITE-9686
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> The JVM options must be passed to new process when remote test node is
> started.
> See {{GridAbstractTest#startRemoteGrid}} methods.
> Affects tests:
> {code}
> IgniteHadoopFileSystemClientBasedOpenTest
> IgniteWalRecoveryTest
> IgniteWalRecoveryWithCompactionTest
> IgnitePdsRebalancingOnNotStableTopologyTest
> CacheScanQueryFailoverTest
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9686) JDK9: pass JVM options to new process when start remote test node
[
https://issues.apache.org/jira/browse/IGNITE-9686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-9686:
-
Description:
The JVM options must be passed to new process when remote test node is started.
See {{GridAbstractTest#startRemoteGrid}},
{{org.apache.ignite.testframework.junits.GridAbstractTest#startRemoteGrid(java.lang.String,
org.apache.ignite.configuration.IgniteConfiguration,
org.apache.ignite.internal.processors.resource.GridSpringResourceContext)}}
Affects tests:
{code}
IgniteHadoopFileSystemClientBasedOpenTest
{code}
was:
The JVM options must be passed to new process when remote test node is started.
See {{GridAbstractTest#startRemoteGrid}}
Affects tests:
{code}
IgniteHadoopFileSystemClientBasedOpenTest
{code}
> JDK9: pass JVM options to new process when start remote test node
> -
>
> Key: IGNITE-9686
> URL: https://issues.apache.org/jira/browse/IGNITE-9686
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> The JVM options must be passed to new process when remote test node is
> started.
> See {{GridAbstractTest#startRemoteGrid}},
> {{org.apache.ignite.testframework.junits.GridAbstractTest#startRemoteGrid(java.lang.String,
> org.apache.ignite.configuration.IgniteConfiguration,
> org.apache.ignite.internal.processors.resource.GridSpringResourceContext)}}
> Affects tests:
> {code}
> IgniteHadoopFileSystemClientBasedOpenTest
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9686) JDK9: pass JVM options to new process when start remote test node
Taras Ledkov created IGNITE-9686:
Summary: JDK9: pass JVM options to new process when start remote
test node
Key: IGNITE-9686
URL: https://issues.apache.org/jira/browse/IGNITE-9686
Project: Ignite
Issue Type: Task
Affects Versions: 2.6
Reporter: Taras Ledkov
Assignee: Taras Ledkov
The JVM options must be passed to new process when remote test node is started.
See {{GridAbstractTest#startRemoteGrid}}
Affects tests:
{code}
IgniteHadoopFileSystemClientBasedOpenTest
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9685) [ML] Add ignite-tensorflow module to build artifacts
Yury Babak created IGNITE-9685: -- Summary: [ML] Add ignite-tensorflow module to build artifacts Key: IGNITE-9685 URL: https://issues.apache.org/jira/browse/IGNITE-9685 Project: Ignite Issue Type: New Feature Components: ml Reporter: Yury Babak Assignee: Peter Ivanov Fix For: 2.7 We want to release Apache Ignite TensorFlow Integration Module with other Ignite tools. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9681) Wrong GIT config in Team City release archive
[
https://issues.apache.org/jira/browse/IGNITE-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ivanov resolved IGNITE-9681.
--
Resolution: Fixed
Reconfigured VCS to use native checkout without mirror:
https://ci.ignite.apache.org/viewLog.html?buildId=1938354.
> Wrong GIT config in Team City release archive
> -
>
> Key: IGNITE-9681
> URL: https://issues.apache.org/jira/browse/IGNITE-9681
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Nikolay Izhikov
>Assignee: Peter Ivanov
>Priority: Blocker
> Fix For: 2.7
>
>
> Release archive created by "[Prepare Vote #1] Java &.Net & C++ (Complete
> assembly)" [1] contains wrong .git/config. It includes local Team City path
> and doesn't work properly on release manager local environment.
> Example of config file(lfs section is Team City specifi):
> {noformat}
> [core]
> repositoryformatversion = 0
> filemode = false
> bare = false
> logallrefupdates = true
> sparseCheckout = true
> [remote "origin"]
> url = https://git-wip-us.apache.org/repos/asf/ignite
> fetch = +refs/heads/*:refs/remotes/origin/*
> [lfs]
> storage = /data/teamcity/system/git/git-E4D58B67.git/lfs
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> {noformat}
> [1]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9684) JDK9: pass JVM options to created process at HadoopCommandLineTest#createProcessBuilder
[
https://issues.apache.org/jira/browse/IGNITE-9684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-9684:
-
Description:
To support JDK9 the JVM options must be passed to created process:
see {{HadoopCommandLineTest#createProcessBuilder}}
Because lauched process fails with
{code}
IllegalAccessException: class org.apache.ignite.internal.util.GridUnsafe cannot
access class jdk.internal.misc.SharedSecrets (in module java.base) because
module java.base does not export jdk.internal.misc to unnamed module
{code}
was:
To support JDK9 the JVM options must be passed to created process:
see {{HadoopCommandLineTest#createProcessBuilder}}
Because lauched process fails with
IllegalAccessException: class org.apache.ignite.internal.util.GridUnsafe cannot
access class jdk.internal.misc.SharedSecrets (in module java.base) because
module java.base does not export jdk.internal.misc to unnamed module
> JDK9: pass JVM options to created process at
> HadoopCommandLineTest#createProcessBuilder
> ---
>
> Key: IGNITE-9684
> URL: https://issues.apache.org/jira/browse/IGNITE-9684
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> To support JDK9 the JVM options must be passed to created process:
> see {{HadoopCommandLineTest#createProcessBuilder}}
> Because lauched process fails with
> {code}
> IllegalAccessException: class org.apache.ignite.internal.util.GridUnsafe
> cannot access class jdk.internal.misc.SharedSecrets (in module java.base)
> because module java.base does not export jdk.internal.misc to unnamed module
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9670) JDK9: supports hadoop Ignite module
[
https://issues.apache.org/jira/browse/IGNITE-9670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-9670:
-
Ignite Flags: (was: Docs Required)
> JDK9: supports hadoop Ignite module
> ---
>
> Key: IGNITE-9670
> URL: https://issues.apache.org/jira/browse/IGNITE-9670
> Project: Ignite
> Issue Type: Task
> Components: hadoop
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.7
>
>
> # Hadoop processor doens't start with error: {{class
> org.apache.ignite.IgniteCheckedException: Java version 9 and above is not
> supported.}}
> # Hadoop tests aren't run from IDEA because used classloaders chain is
> changed (related to IGNITE-8146).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9684) JDK9: pass JVM options to created process at HadoopCommandLineTest#createProcessBuilder
[
https://issues.apache.org/jira/browse/IGNITE-9684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-9684:
-
Affects Version/s: 2.6
> JDK9: pass JVM options to created process at
> HadoopCommandLineTest#createProcessBuilder
> ---
>
> Key: IGNITE-9684
> URL: https://issues.apache.org/jira/browse/IGNITE-9684
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> To support JDK9 the JVM options must be passed to created process:
> see {{HadoopCommandLineTest#createProcessBuilder}}
> Because lauched process fails with
> {code}
> IllegalAccessException: class org.apache.ignite.internal.util.GridUnsafe
> cannot access class jdk.internal.misc.SharedSecrets (in module java.base)
> because module java.base does not export jdk.internal.misc to unnamed module
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9684) JDK9: pass JVM options to created process at HadoopCommandLineTest#createProcessBuilder
[
https://issues.apache.org/jira/browse/IGNITE-9684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-9684:
-
Ignite Flags: (was: Docs Required)
> JDK9: pass JVM options to created process at
> HadoopCommandLineTest#createProcessBuilder
> ---
>
> Key: IGNITE-9684
> URL: https://issues.apache.org/jira/browse/IGNITE-9684
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> To support JDK9 the JVM options must be passed to created process:
> see {{HadoopCommandLineTest#createProcessBuilder}}
> Because lauched process fails with
> {code}
> IllegalAccessException: class org.apache.ignite.internal.util.GridUnsafe
> cannot access class jdk.internal.misc.SharedSecrets (in module java.base)
> because module java.base does not export jdk.internal.misc to unnamed module
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
