[jira] [Commented] (IGNITE-9700) Remove configurable values from mesos pom.xml
[ https://issues.apache.org/jira/browse/IGNITE-9700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701498#comment-16701498 ] ASF GitHub Bot commented on IGNITE-9700: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4838 > Remove configurable values from mesos pom.xml > - > > Key: IGNITE-9700 > URL: https://issues.apache.org/jira/browse/IGNITE-9700 > Project: Ignite > Issue Type: Bug >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Minor > Fix For: 2.8 > > > pom.xml contains urls and paths that can be configured when building, but it > introduces git changes with every build. > Need to update the links in the file and remove them from build process, > since the whole process depends on the the links and will not likely be > changed in near future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10433) Web Console: "Import models" dialog doesn't unsubscribe from watching agent after closing
[ https://issues.apache.org/jira/browse/IGNITE-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-10433. --- Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Looks good to me. [~pkonstantinov], please retest. > Web Console: "Import models" dialog doesn't unsubscribe from watching agent > after closing > - > > Key: IGNITE-10433 > URL: https://issues.apache.org/jira/browse/IGNITE-10433 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.8 > > > Noticed the next behaviour: > # Open configuration page or cluster edit page. > # Click import when agent is not run. > # Click *Back* button to close *Connection to Ignite Web Agent is not > established* dialog. > # Start and stop web-agent. > *Connection to Ignite Web Agent is not established* dialog is shown. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10433) Web Console: "Import models" dialog doesn't unsubscribe from watching agent after closing
Alexey Kuznetsov created IGNITE-10433: - Summary: Web Console: "Import models" dialog doesn't unsubscribe from watching agent after closing Key: IGNITE-10433 URL: https://issues.apache.org/jira/browse/IGNITE-10433 Project: Ignite Issue Type: Task Components: wizards Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 2.8 Noticed the next behaviour: # Open configuration page or cluster edit page. # Click import when agent is not run. # Click *Back* button to close *Connection to Ignite Web Agent is not established* dialog. # Start and stop web-agent. *Connection to Ignite Web Agent is not established* dialog is shown. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9700) Remove configurable values from mesos pom.xml
[ https://issues.apache.org/jira/browse/IGNITE-9700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701490#comment-16701490 ] Roman Shtykh commented on IGNITE-9700: -- [~ilyak] No problem, busy release ;) Thanks for looking! > Remove configurable values from mesos pom.xml > - > > Key: IGNITE-9700 > URL: https://issues.apache.org/jira/browse/IGNITE-9700 > Project: Ignite > Issue Type: Bug >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Minor > Fix For: 2.8 > > > pom.xml contains urls and paths that can be configured when building, but it > introduces git changes with every build. > Need to update the links in the file and remove them from build process, > since the whole process depends on the the links and will not likely be > changed in near future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10298) Possible deadlock between restore partition states and checkpoint begin
[
https://issues.apache.org/jira/browse/IGNITE-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-10298:
--
Ignite Flags: (was: Docs Required)
> Possible deadlock between restore partition states and checkpoint begin
> ---
>
> Key: IGNITE-10298
> URL: https://issues.apache.org/jira/browse/IGNITE-10298
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Critical
> Fix For: 2.8
>
>
> There is possible deadlock between "restorePartitionStates" phase during
> caches starting and currently running checkpointer:
> {noformat}
> "db-checkpoint-thread-#50" #89 prio=5 os_prio=0 tid=0x1ad57800
> nid=0x2b58 waiting on condition [0x7e42e000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xddabfcc8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.ignite.internal.util.IgniteUtils.await(IgniteUtils.java:7515)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1331)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.fullSize(GridCacheOffheapManager.java:1459)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3397)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3009)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2934)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> "exchange-worker-#42" #69 prio=5 os_prio=0 tid=0x1c1cd800 nid=0x259c
> waiting on condition [0x249ae000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x80b634a0> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1328)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1212)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.initialUpdateCounter(GridCacheOffheapManager.java:1537)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.onPartitionInitialCounterUpdated(GridCacheOffheapManager.java:633)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2365)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1174)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1119)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtParti
[jira] [Commented] (IGNITE-9980) Modify ./control.sh --cache idle_verify --dump print to diff mode (user persistant only/user not-persistent only/system only) cache
[
https://issues.apache.org/jira/browse/IGNITE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701466#comment-16701466
]
Ignite TC Bot commented on IGNITE-9980:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Inspections] Core{color} [[tests 0 BuildFailureOnMetric
|https://ci.ignite.apache.org/viewLog.html?buildId=2409726]]
{color:#d04437}Queries 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2409657]]
* IgniteBinaryCacheQueryTestSuite2:
IgniteCacheQueryStopOnCancelOrTimeoutDistributedJoinSelfTest.testCancel1 - 0,0%
fails in last 100 master runs.
{color:#d04437}MVCC Cache{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2409679]]
* IgniteCacheMvccTestSuite:
CacheMvccPartitionedCoordinatorFailoverTest.testPutAllGetAll_ClientServer_Backups1_RestartCoordinator_GetPut_Persistence
- 0,0% fails in last 100 master runs.
{color:#d04437}Platform .NET (Integrations){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2409721]]
* dll: IgniteSessionStateStoreProviderTest.TestCaching - 0,0% fails in last 100
master runs.
{color:#d04437}PDS 4{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2409717]]
*
IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testConcurrentJoinAndActivate
(last started)
{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2409730&buildTypeId=IgniteTests24Java8_RunAll]
> Modify ./control.sh --cache idle_verify --dump print to diff mode (user
> persistant only/user not-persistent only/system only) cache
> ---
>
> Key: IGNITE-9980
> URL: https://issues.apache.org/jira/browse/IGNITE-9980
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: ARomantsov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
>
> It will be cool , if control.sh --cache idle_verify can show
> persistent/not-persistent/system caches and it will be impliments due utility
> flag
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9980) Modify ./control.sh --cache idle_verify --dump print to diff mode (user persistant only/user not-persistent only/system only) cache
[ https://issues.apache.org/jira/browse/IGNITE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701463#comment-16701463 ] Vladislav Pyatkov commented on IGNITE-9980: --- I have apply additional changes and prepared TC. All **Possible Blockers** are not related to my changes. > Modify ./control.sh --cache idle_verify --dump print to diff mode (user > persistant only/user not-persistent only/system only) cache > --- > > Key: IGNITE-9980 > URL: https://issues.apache.org/jira/browse/IGNITE-9980 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: ARomantsov >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.8 > > > It will be cool , if control.sh --cache idle_verify can show > persistent/not-persistent/system caches and it will be impliments due utility > flag -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10432) regression on sqlline
[
https://issues.apache.org/jira/browse/IGNITE-10432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-10432:
--
Ignite Flags: (was: Docs Required)
> regression on sqlline
> --
>
> Key: IGNITE-10432
> URL: https://issues.apache.org/jira/browse/IGNITE-10432
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Pavel Konstantinov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Fix For: 2.7
>
>
> I've tried to execute our example using sqlline and got the following error:
> {code}
> 2787/5325INSERT INTO City(ID, Name, CountryCode, District, Population)
> VALUES (2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);
> Error: Value for a column 'DISTRICT' is too long. Maximum length: 20, actual
> length: 21 (state=23000,code=4008)
> Aborting command set because "force" is false and command failed: "INSERT
> INTO City(ID, Name, CountryCode, District, Population) VALUES
> (2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);"
> 0: jdbc:ignite:thin://127.0.0.1:10800>
> {code}
> To reproduce:
> # start one ignite node (version 2.7)
> # start sqlline (sqlline.bat -u jdbc:ignite:thin://127.0.0.1:10800)
> # execute in sqlline the command: !run ../examples/sql/world.sql
> The same on 2.6 or 2.5 worked w\o error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10432) regression on sqlline
[
https://issues.apache.org/jira/browse/IGNITE-10432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Konstantinov updated IGNITE-10432:
Description:
I've tried to execute our example using sqlline and got the following error:
{code}
2787/5325INSERT INTO City(ID, Name, CountryCode, District, Population)
VALUES (2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);
Error: Value for a column 'DISTRICT' is too long. Maximum length: 20, actual
length: 21 (state=23000,code=4008)
Aborting command set because "force" is false and command failed: "INSERT INTO
City(ID, Name, CountryCode, District, Population) VALUES
(2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);"
0: jdbc:ignite:thin://127.0.0.1:10800>
{code}
To reproduce:
# start one ignite node (version 2.7)
# start sqlline (sqlline.bat -u jdbc:ignite:thin://127.0.0.1:10800)
# execute in sqlline the command: !run ../examples/sql/world.sql
The same on 2.6 or 2.5 worked w\o error.
was:
I've tried to execute our example using sqlline and got the following error:
{code}
2787/5325INSERT INTO City(ID, Name, CountryCode, District, Population)
VALUES (2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);
Error: Value for a column 'DISTRICT' is too long. Maximum length: 20, actual
length: 21 (state=23000,code=4008)
Aborting command set because "force" is false and command failed: "INSERT INTO
City(ID, Name, CountryCode, District, Population) VALUES
(2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);"
0: jdbc:ignite:thin://127.0.0.1:10800>
{code}
To reproduce:
# start one ignite node (version 2.7)
# start sqlline (sqlline.bat -u jdbc:ignite:thin://127.0.0.1:10800)
# execute in sqlline the command: !run ../examples/sql/world.sql
> regression on sqlline
> --
>
> Key: IGNITE-10432
> URL: https://issues.apache.org/jira/browse/IGNITE-10432
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Pavel Konstantinov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Fix For: 2.7
>
>
> I've tried to execute our example using sqlline and got the following error:
> {code}
> 2787/5325INSERT INTO City(ID, Name, CountryCode, District, Population)
> VALUES (2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);
> Error: Value for a column 'DISTRICT' is too long. Maximum length: 20, actual
> length: 21 (state=23000,code=4008)
> Aborting command set because "force" is false and command failed: "INSERT
> INTO City(ID, Name, CountryCode, District, Population) VALUES
> (2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);"
> 0: jdbc:ignite:thin://127.0.0.1:10800>
> {code}
> To reproduce:
> # start one ignite node (version 2.7)
> # start sqlline (sqlline.bat -u jdbc:ignite:thin://127.0.0.1:10800)
> # execute in sqlline the command: !run ../examples/sql/world.sql
> The same on 2.6 or 2.5 worked w\o error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10432) regression on sqlline
[
https://issues.apache.org/jira/browse/IGNITE-10432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Konstantinov updated IGNITE-10432:
Description:
I've tried to execute our example using sqlline and got the following error:
{code}
2787/5325INSERT INTO City(ID, Name, CountryCode, District, Population)
VALUES (2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);
Error: Value for a column 'DISTRICT' is too long. Maximum length: 20, actual
length: 21 (state=23000,code=4008)
Aborting command set because "force" is false and command failed: "INSERT INTO
City(ID, Name, CountryCode, District, Population) VALUES
(2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);"
0: jdbc:ignite:thin://127.0.0.1:10800>
{code}
To reproduce:
# start one ignite node (version 2.7)
# start sqlline (sqlline.bat -u jdbc:ignite:thin://127.0.0.1:10800)
# execute in sqlline the command: !run ../examples/sql/world.sql
was:
I've tried to execute our example using sqlline and got the following error:
{code}
2787/5325INSERT INTO City(ID, Name, CountryCode, District, Population)
VALUES (2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);
Error: Value for a column 'DISTRICT' is too long. Maximum length: 20, actual
length: 21 (state=23000,code=4008)
Aborting command set because "force" is false and command failed: "INSERT INTO
City(ID, Name, CountryCode, District, Population) VALUES
(2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);"
0: jdbc:ignite:thin://127.0.0.1:10800>
{code}
To reproduce:
# start one ignite node (version 2.7)
# start sqlline (sqlline.bat -u jdbc:ignite:thin://127.0.0.1:10800)
# execute in sqlline the command:
> regression on sqlline
> --
>
> Key: IGNITE-10432
> URL: https://issues.apache.org/jira/browse/IGNITE-10432
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Pavel Konstantinov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Fix For: 2.7
>
>
> I've tried to execute our example using sqlline and got the following error:
> {code}
> 2787/5325INSERT INTO City(ID, Name, CountryCode, District, Population)
> VALUES (2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);
> Error: Value for a column 'DISTRICT' is too long. Maximum length: 20, actual
> length: 21 (state=23000,code=4008)
> Aborting command set because "force" is false and command failed: "INSERT
> INTO City(ID, Name, CountryCode, District, Population) VALUES
> (2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);"
> 0: jdbc:ignite:thin://127.0.0.1:10800>
> {code}
> To reproduce:
> # start one ignite node (version 2.7)
> # start sqlline (sqlline.bat -u jdbc:ignite:thin://127.0.0.1:10800)
> # execute in sqlline the command: !run ../examples/sql/world.sql
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10432) regression on sqlline
[
https://issues.apache.org/jira/browse/IGNITE-10432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Konstantinov updated IGNITE-10432:
Description:
I've tried to execute our example using sqlline and got the following error:
{code}
2787/5325INSERT INTO City(ID, Name, CountryCode, District, Population)
VALUES (2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);
Error: Value for a column 'DISTRICT' is too long. Maximum length: 20, actual
length: 21 (state=23000,code=4008)
Aborting command set because "force" is false and command failed: "INSERT INTO
City(ID, Name, CountryCode, District, Population) VALUES
(2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);"
0: jdbc:ignite:thin://127.0.0.1:10800>
{code}
To reproduce:
# start one ignite node (version 2.7)
# start sqlline (sqlline.bat -u jdbc:ignite:thin://127.0.0.1:10800)
# execute in sqlline the command:
was:
{code}
2787/5325INSERT INTO City(ID, Name, CountryCode, District, Population)
VALUES (2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);
Error: Value for a column 'DISTRICT' is too long. Maximum length: 20, actual
length: 21 (state=23000,code=4008)
Aborting command set because "force" is false and command failed: "INSERT INTO
City(ID, Name, CountryCode, District, Population) VALUES
(2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);"
0: jdbc:ignite:thin://127.0.0.1:10800>
{code}
> regression on sqlline
> --
>
> Key: IGNITE-10432
> URL: https://issues.apache.org/jira/browse/IGNITE-10432
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Pavel Konstantinov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Fix For: 2.7
>
>
> I've tried to execute our example using sqlline and got the following error:
> {code}
> 2787/5325INSERT INTO City(ID, Name, CountryCode, District, Population)
> VALUES (2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);
> Error: Value for a column 'DISTRICT' is too long. Maximum length: 20, actual
> length: 21 (state=23000,code=4008)
> Aborting command set because "force" is false and command failed: "INSERT
> INTO City(ID, Name, CountryCode, District, Population) VALUES
> (2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);"
> 0: jdbc:ignite:thin://127.0.0.1:10800>
> {code}
> To reproduce:
> # start one ignite node (version 2.7)
> # start sqlline (sqlline.bat -u jdbc:ignite:thin://127.0.0.1:10800)
> # execute in sqlline the command:
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10432) regression on sqlline
Pavel Konstantinov created IGNITE-10432:
---
Summary: regression on sqlline
Key: IGNITE-10432
URL: https://issues.apache.org/jira/browse/IGNITE-10432
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.7
Reporter: Pavel Konstantinov
Assignee: Vladimir Ozerov
Fix For: 2.7
{code}
2787/5325INSERT INTO City(ID, Name, CountryCode, District, Population)
VALUES (2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);
Error: Value for a column 'DISTRICT' is too long. Maximum length: 20, actual
length: 21 (state=23000,code=4008)
Aborting command set because "force" is false and command failed: "INSERT INTO
City(ID, Name, CountryCode, District, Population) VALUES
(2769,'Sokoto','NGA','Sokoto & Kebbi & Zam',204900);"
0: jdbc:ignite:thin://127.0.0.1:10800>
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10356) JDBC thin driver returns wrong data type for Date and Decimal SQL type
[
https://issues.apache.org/jira/browse/IGNITE-10356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701318#comment-16701318
]
Ray commented on IGNITE-10356:
--
[~vozerov]
The Run All has finished, there's a lot of failed tests in other modules.
Most of them looks flaky to me.
What's the next step here?
> JDBC thin driver returns wrong data type for Date and Decimal SQL type
> --
>
> Key: IGNITE-10356
> URL: https://issues.apache.org/jira/browse/IGNITE-10356
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.6, 2.7
>Reporter: Ray
>Assignee: Ray
>Priority: Critical
> Fix For: 2.8
>
>
> JDBC thin driver will return wrong metadata for column type when user creates
> a table with Date and Decimal type.
>
> Steps to reproduce.
> 1. Start one node and create table using this command
> create table a(a varchar, b decimal,c date, primary key(a));
> 2. Run "!desc a" to show the metadata of table a
> This results is as follows:
> TABLE_CAT
> TABLE_SCHEM PUBLIC
> TABLE_NAME A
> COLUMN_NAME A
> DATA_TYPE 12
> TYPE_NAME VARCHAR
> COLUMN_SIZE null
> BUFFER_LENGTH null
> DECIMAL_DIGITS null
> NUM_PREC_RADIX 10
> NULLABLE 1
> REMARKS
> COLUMN_DEF
> SQL_DATA_TYPE 12
> SQL_DATETIME_SUB null
> CHAR_OCTET_LENGTH 2147483647
> ORDINAL_POSITION 1
> IS_NULLABLE YES
> SCOPE_CATLOG
> SCOPE_SCHEMA
> SCOPE_TABLE
> SOURCE_DATA_TYPE null
> IS_AUTOINCREMENT NO
> IS_GENERATEDCOLUMN NO
> TABLE_CAT
> TABLE_SCHEM PUBLIC
> TABLE_NAME A
> COLUMN_NAME B
> {color:#d04437}DATA_TYPE {color}
> {color:#d04437}TYPE_NAME OTHER{color}
> COLUMN_SIZE null
> BUFFER_LENGTH null
> DECIMAL_DIGITS null
> NUM_PREC_RADIX 10
> NULLABLE 1
> REMARKS
> COLUMN_DEF
> {color:#d04437}SQL_DATA_TYPE {color}
> SQL_DATETIME_SUB null
> CHAR_OCTET_LENGTH 2147483647
> ORDINAL_POSITION 2
> IS_NULLABLE YES
> SCOPE_CATLOG
> SCOPE_SCHEMA
> SCOPE_TABLE
> SOURCE_DATA_TYPE null
> IS_AUTOINCREMENT NO
> IS_GENERATEDCOLUMN NO
> TABLE_CAT
> TABLE_SCHEM PUBLIC
> TABLE_NAME A
> COLUMN_NAME C
> {color:#d04437}DATA_TYPE {color}
> {color:#d04437}TYPE_NAME OTHER{color}
> COLUMN_SIZE null
> BUFFER_LENGTH null
> DECIMAL_DIGITS null
> NUM_PREC_RADIX 10
> NULLABLE 1
> REMARKS
> {color:#33}COLUMN_DEF{color}
> {color:#d04437} SQL_DATA_TYPE {color}
> SQL_DATETIME_SUB null
> CHAR_OCTET_LENGTH 2147483647
> ORDINAL_POSITION 3
> IS_NULLABLE YES
> SCOPE_CATLOG
> SCOPE_SCHEMA
> SCOPE_TABLE
> SOURCE_DATA_TYPE null
> IS_AUTOINCREMENT NO
> IS_GENERATEDCOLUMN NO
>
> Column b and c has the wrong DATA_TYPE and TYPE_NAME.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10354) Failing client node due to not receiving metrics updates
[
https://issues.apache.org/jira/browse/IGNITE-10354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701287#comment-16701287
]
Ignite TC Bot commented on IGNITE-10354:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Inspections] Core{color} [[tests 0 BuildFailureOnMetric
|https://ci.ignite.apache.org/viewLog.html?buildId=2406418]]
{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2405014&buildTypeId=IgniteTests24Java8_RunAll]
> Failing client node due to not receiving metrics updates
>
>
> Key: IGNITE-10354
> URL: https://issues.apache.org/jira/browse/IGNITE-10354
> Project: Ignite
> Issue Type: Bug
> Components: clients
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Attachments: ClientDisconnectedTest.java
>
>
> In some cases after the coordinator change, the client node can be failed
> before it can establish a connection to another server from the cluster.
> {code:java}
> [2018-11-21 12:21:45,769][WARN
> ][tcp-disco-msg-worker-#15%server-b%][TestTcpDiscoverySpi] Failing client
> node due to not receiving metrics updates from client node within
> 'IgniteConfiguration.clientFailureDetectionTimeout' (consider increasing
> configuration property) [timeout=1, node=TcpDiscoveryNode
> [id=dc739711-f685-45e8-9017-1f91b1d86c8c, addrs=[0:0:0:0:0:0:0:1, 10.0.75.1,
> 127.0.0.1, 192.168.1.51, 192.168.192.1], sockAddrs=[/0:0:0:0:0:0:0:1:0,
> LAPTOP-6FN8RAOS/10.0.75.1:0, /127.0.0.1:0, /192.168.192.1:0,
> /192.168.1.51:0], discPort=0, order=2, intOrder=2,
> lastExchangeTime=1542774105666, loc=false, ver=2.4.0#20180830-sha1:345c0a7c,
> isClient=true]]
> [2018-11-21 12:21:45,791][INFO
> ][tcp-client-disco-msg-worker-#10%client%][TestTcpDiscoverySpi] Client node
> disconnected from cluster, will try to reconnect with new id
> [newId=46812956-2fc4-4b74-9909-d523a547ba0e,
> prevId=dc739711-f685-45e8-9017-1f91b1d86c8c, locNode=TcpDiscoveryNode
> [id=dc739711-f685-45e8-9017-1f91b1d86c8c, addrs=[0:0:0:0:0:0:0:1, 10.0.75.1,
> 127.0.0.1, 192.168.1.51, 192.168.192.1], sockAddrs=[/0:0:0:0:0:0:0:1:0,
> LAPTOP-6FN8RAOS/10.0.75.1:0, /127.0.0.1:0, /192.168.192.1:0,
> /192.168.1.51:0], discPort=0, order=2, intOrder=0,
> lastExchangeTime=1542774104031, loc=true, ver=2.4.0#20180830-sha1:345c0a7c,
> isClient=true]]
> {code}
> It looks like a race condition.
> Steps to reproduce:
> 1. Start server A.
> 2. Start client.
> 3. Start server B.
> 4. Stop server A.
> If add Thread.sleep(1) between (3) and (4) then the client node won't be
> disconnected from the cluster.
> Reproducer is attached [^ClientDisconnectedTest.java].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10354) Failing client node due to not receiving metrics updates
[
https://issues.apache.org/jira/browse/IGNITE-10354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701293#comment-16701293
]
Roman Guseinov commented on IGNITE-10354:
-
`[Inspections] Core` shows the error `Redundant suppression` in
GridTcpCommunicationSpiRecoverySelfTest:109. This class wasn't touched by
current PR.
> Failing client node due to not receiving metrics updates
>
>
> Key: IGNITE-10354
> URL: https://issues.apache.org/jira/browse/IGNITE-10354
> Project: Ignite
> Issue Type: Bug
> Components: clients
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Attachments: ClientDisconnectedTest.java
>
>
> In some cases after the coordinator change, the client node can be failed
> before it can establish a connection to another server from the cluster.
> {code:java}
> [2018-11-21 12:21:45,769][WARN
> ][tcp-disco-msg-worker-#15%server-b%][TestTcpDiscoverySpi] Failing client
> node due to not receiving metrics updates from client node within
> 'IgniteConfiguration.clientFailureDetectionTimeout' (consider increasing
> configuration property) [timeout=1, node=TcpDiscoveryNode
> [id=dc739711-f685-45e8-9017-1f91b1d86c8c, addrs=[0:0:0:0:0:0:0:1, 10.0.75.1,
> 127.0.0.1, 192.168.1.51, 192.168.192.1], sockAddrs=[/0:0:0:0:0:0:0:1:0,
> LAPTOP-6FN8RAOS/10.0.75.1:0, /127.0.0.1:0, /192.168.192.1:0,
> /192.168.1.51:0], discPort=0, order=2, intOrder=2,
> lastExchangeTime=1542774105666, loc=false, ver=2.4.0#20180830-sha1:345c0a7c,
> isClient=true]]
> [2018-11-21 12:21:45,791][INFO
> ][tcp-client-disco-msg-worker-#10%client%][TestTcpDiscoverySpi] Client node
> disconnected from cluster, will try to reconnect with new id
> [newId=46812956-2fc4-4b74-9909-d523a547ba0e,
> prevId=dc739711-f685-45e8-9017-1f91b1d86c8c, locNode=TcpDiscoveryNode
> [id=dc739711-f685-45e8-9017-1f91b1d86c8c, addrs=[0:0:0:0:0:0:0:1, 10.0.75.1,
> 127.0.0.1, 192.168.1.51, 192.168.192.1], sockAddrs=[/0:0:0:0:0:0:0:1:0,
> LAPTOP-6FN8RAOS/10.0.75.1:0, /127.0.0.1:0, /192.168.192.1:0,
> /192.168.1.51:0], discPort=0, order=2, intOrder=0,
> lastExchangeTime=1542774104031, loc=true, ver=2.4.0#20180830-sha1:345c0a7c,
> isClient=true]]
> {code}
> It looks like a race condition.
> Steps to reproduce:
> 1. Start server A.
> 2. Start client.
> 3. Start server B.
> 4. Stop server A.
> If add Thread.sleep(1) between (3) and (4) then the client node won't be
> disconnected from the cluster.
> Reproducer is attached [^ClientDisconnectedTest.java].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8542) [ML] Add OneVsRest Trainer to handle cases with multiple class labels in dataset
[ https://issues.apache.org/jira/browse/IGNITE-8542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701137#comment-16701137 ] ASF GitHub Bot commented on IGNITE-8542: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5512 > [ML] Add OneVsRest Trainer to handle cases with multiple class labels in > dataset > > > Key: IGNITE-8542 > URL: https://issues.apache.org/jira/browse/IGNITE-8542 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.8 > > > method extractClassLabels in LogRegressionMultiClassTrainer and in > SVMLinearMultiClassClassificationTrainer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10352) Cache get request can be mapped to node while partition in MOVING state
[
https://issues.apache.org/jira/browse/IGNITE-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701133#comment-16701133
]
ASF GitHub Bot commented on IGNITE-10352:
-
GitHub user dgovorukhin opened a pull request:
https://github.com/apache/ignite/pull/5519
IGNITE-10352 Final version
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10352-final
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5519.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 #5519
commit 6fd4f0121092eeadccb885e3f46ec872f88718ee
Author: Dmitriy Govorukhin
Date: 2018-11-23T21:44:28Z
IGNITE-10352 add test
Signed-off-by: Dmitriy Govorukhin
commit dceb2ad5d951e69f58f265e28f8ce5af4aed6009
Author: Dmitriy Govorukhin
Date: 2018-11-27T21:41:01Z
IGNITE-10352 refactoring GridPartitionedGetFuture
Signed-off-by: Dmitriy Govorukhin
commit 64eaeb955998df2aca21fab0e2c871a41e321894
Author: Dmitriy Govorukhin
Date: 2018-11-27T22:00:52Z
IGNITE-10352 refactoring GridPartitionedGetFuture + minor changes
Signed-off-by: Dmitriy Govorukhin
commit 3ab78b360bf58dbb11ea3ba803cdfefc2977c7ca
Author: Dmitriy Govorukhin
Date: 2018-11-27T22:07:09Z
IGNITE-10352 refactoring GridPartitionedGetFuture + remove serUuid
Signed-off-by: Dmitriy Govorukhin
commit fe2c0c888fe65e2eb4b0d491c4655d2fd429ad9d
Author: Dmitriy Govorukhin
Date: 2018-11-27T22:44:24Z
IGNITE-10352 refactoring GridPartitionedSingleGetFuture
Signed-off-by: Dmitriy Govorukhin
> Cache get request can be mapped to node while partition in MOVING state
> ---
>
> Key: IGNITE-10352
> URL: https://issues.apache.org/jira/browse/IGNITE-10352
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
>
> Cache get request can be mapped to node while partition in MOVING state.
> It leads to assertions like quoted below and eventually to failure handler
> action.
> {noformat}
> java.lang.AssertionError: Wrong ready topology version for invalid partitions
> response [topVer=AffinityTopologyVersion [topVer=19, minorTopVer=0],
> req=GridNearSingleGetRequest [futId=1542371256329, key=KeyCacheObjectImpl
> [part=4595,
> val=com.sbt.cdm.api.model.published.ae.PublishedOperationCondition,
> hasValBytes=true], flags=1, topVer=AffinityTopologyVersion [topVer=19,
> minorTopVer=0], subjId=ea523c3a-4d22-4a3c-b1b0-3137da762021, taskNameHash=0,
> createTtl=-1, accessTtl=-1, mvccSnapshot=null]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:975)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$6.apply(GridDhtCacheAdapter.java:938)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:938)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:152)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:150)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2349)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.i
[jira] [Commented] (IGNITE-10413) Perform cache validation logic on primary node instead of near node
[ https://issues.apache.org/jira/browse/IGNITE-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701097#comment-16701097 ] Ivan Rakov commented on IGNITE-10413: - Another version of fix: https://github.com/apache/ignite/pull/5518 > Perform cache validation logic on primary node instead of near node > --- > > Key: IGNITE-10413 > URL: https://issues.apache.org/jira/browse/IGNITE-10413 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > Fix For: 2.8 > > > Exchange is completed on clients asynchronously, that's why we can perform > outdated validation when near node is client. > We have to execute validation on dht node instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10413) Perform cache validation logic on primary node instead of near node
[ https://issues.apache.org/jira/browse/IGNITE-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701058#comment-16701058 ] Ivan Rakov commented on IGNITE-10413: - PR: https://github.com/apache/ignite/pull/5502 > Perform cache validation logic on primary node instead of near node > --- > > Key: IGNITE-10413 > URL: https://issues.apache.org/jira/browse/IGNITE-10413 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > Fix For: 2.8 > > > Exchange is completed on clients asynchronously, that's why we can perform > outdated validation when near node is client. > We have to execute validation on dht node instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10429) ML: TensorFlowLocalInferenceExample fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-10429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701034#comment-16701034
]
ASF GitHub Bot commented on IGNITE-10429:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5514
> ML: TensorFlowLocalInferenceExample fails on Windows
>
>
> Key: IGNITE-10429
> URL: https://issues.apache.org/jira/browse/IGNITE-10429
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.8
>Reporter: Anton Dmitriev
>Assignee: Anton Dmitriev
>Priority: Major
> Fix For: 2.8
>
>
> Failure is observed only on Windows - on Linux test passes. Failure message
> says file is in use by another process
> {noformat}
> java.lang.RuntimeException: java.nio.file.FileSystemException:
> C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
> Процесс не может получить доступ к файлу, так как этот файл занят другим
> процессом.
> at
> org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:107)
> at
> org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
> at
> org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
> at
> org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
> at
> org.apache.ignite.ml.inference.util.DirectorySerializerTest.testSerializeDeserializeWithDirectory(DirectorySerializerTest.java:122)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.nio.file.FileSystemException:
> C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
> Процесс не может получить доступ к файлу, так как этот файл занят другим
> процессом.
> at
> sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
> at
> sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
> at
> sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> at java.nio.file.Files.delete(Files.java:1126)
> at
> org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:104)
> ... 26 more
> {noformat}
> Fix is to wrap Scanner usage in try-with-resources
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10079) FileWriteAheadLogManager may return invalid lastCompactedSegment
[
https://issues.apache.org/jira/browse/IGNITE-10079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700963#comment-16700963
]
Ignite TC Bot commented on IGNITE-10079:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Inspections] Core{color} [[tests 0 BuildFailureOnMetric
|https://ci.ignite.apache.org/viewLog.html?buildId=2407804]]
{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2407808&buildTypeId=IgniteTests24Java8_RunAll]
> FileWriteAheadLogManager may return invalid lastCompactedSegment
>
>
> Key: IGNITE-10079
> URL: https://issues.apache.org/jira/browse/IGNITE-10079
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Attachments: WalCompactionAfterRestartTest.java
>
>
> As of current {{master}} branch,
> {{FileWriteAheadLogManager#lastCompactedSegment}} may report -1 even after
> some segments have been actually compressed. Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10298) Possible deadlock between restore partition states and checkpoint begin
[
https://issues.apache.org/jira/browse/IGNITE-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700928#comment-16700928
]
ASF GitHub Bot commented on IGNITE-10298:
-
GitHub user Jokser opened a pull request:
https://github.com/apache/ignite/pull/5517
IGNITE-10298 Cover possible deadlock in case of caches start and frequent
checkpoints
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10298
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5517.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 #5517
commit efe84b1356bbb89ca059691fbbb112716a6aa85c
Author: Pavel Kovalenko
Date: 2018-11-20T17:26:52Z
IGNITE-10298 Cover possible deadlock in case of caches start and frequent
checkpoints.
> Possible deadlock between restore partition states and checkpoint begin
> ---
>
> Key: IGNITE-10298
> URL: https://issues.apache.org/jira/browse/IGNITE-10298
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Critical
> Fix For: 2.8
>
>
> There is possible deadlock between "restorePartitionStates" phase during
> caches starting and currently running checkpointer:
> {noformat}
> "db-checkpoint-thread-#50" #89 prio=5 os_prio=0 tid=0x1ad57800
> nid=0x2b58 waiting on condition [0x7e42e000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xddabfcc8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.ignite.internal.util.IgniteUtils.await(IgniteUtils.java:7515)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1331)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.fullSize(GridCacheOffheapManager.java:1459)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3397)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3009)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2934)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> "exchange-worker-#42" #69 prio=5 os_prio=0 tid=0x1c1cd800 nid=0x259c
> waiting on condition [0x249ae000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x80b634a0> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1328)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1212)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.initialUpdateCounter(GridCache
[jira] [Commented] (IGNITE-3303) Apache Flink Integration - Flink source to run a continuous query against one or multiple caches
[
https://issues.apache.org/jira/browse/IGNITE-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700898#comment-16700898
]
Ignite TC Bot commented on IGNITE-3303:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Inspections] Core{color} [[tests 0 BuildFailureOnMetric
|https://ci.ignite.apache.org/viewLog.html?buildId=2409094]]
{color:#d04437}SPI{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2402589]]
* IgniteSpiTestSuite:
TcpDiscoverySslSelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished -
0,0% fails in last 100 master runs.
* IgniteSpiTestSuite:
TcpDiscoverySslTrustedSelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished
- 0,0% fails in last 100 master runs.
* IgniteSpiTestSuite:
TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished - 0,0%
fails in last 100 master runs.
{color:#d04437}_Licenses Headers_{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2409097]]
{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2402657&buildTypeId=IgniteTests24Java8_RunAll]
> Apache Flink Integration - Flink source to run a continuous query against one
> or multiple caches
>
>
> Key: IGNITE-3303
> URL: https://issues.apache.org/jira/browse/IGNITE-3303
> Project: Ignite
> Issue Type: New Feature
> Components: streaming
>Reporter: Saikat Maitra
>Assignee: Saikat Maitra
>Priority: Major
> Fix For: 2.8
>
> Attachments: Screen Shot 2016-10-07 at 12.44.47 AM.png,
> testFlinkIgniteSourceWithLargeBatch.log, win7.PNG
>
>
> Apache Flink integration
> +++ *Ignite as a bidirectional Connector* +++
> As a Flink source => run a continuous query against one or multiple
> caches [4].
> Related discussion :
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Flink-lt-gt-Apache-Ignite-integration-td8163.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10203) [TC Bot] Support for alternative configurations for PR testing
[ https://issues.apache.org/jira/browse/IGNITE-10203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700878#comment-16700878 ] ASF GitHub Bot commented on IGNITE-10203: - dspavlov commented on issue #78: IGNITE-10203 Support for alternative configurations for PR testing URL: https://github.com/apache/ignite-teamcity-bot/pull/78#issuecomment-442177816 I suggest to - move logic from IgnitedTCImpl to standalone class e.g. BuildTypeSync in build type package - fix the case when service responding [] to a request of contributions. - fix current page (and probably build page) with correct SuiteId displaying or omitting it. 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 > [TC Bot] Support for alternative configurations for PR testing > -- > > Key: IGNITE-10203 > URL: https://issues.apache.org/jira/browse/IGNITE-10203 > Project: Ignite > Issue Type: Task >Reporter: Nikolai Kulagin >Assignee: Nikolai Kulagin >Priority: Major > > Support for alternative configurations for PR testing (for example, > IgniteTests24Java8_RunMl) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10431) Make tests independent of page size
[
https://issues.apache.org/jira/browse/IGNITE-10431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergi Vladykin updated IGNITE-10431:
Summary: Make tests independent of page size (was: Make tests independent
of memory size)
> Make tests independent of page size
> ---
>
> Key: IGNITE-10431
> URL: https://issues.apache.org/jira/browse/IGNITE-10431
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergi Vladykin
>Priority: Major
>
> The following tests were added to Page Compression suite and they fail
> because page size there increased to 8k.
> {code:java}
> org.apache.ignite.testsuites.IgnitePdsCompressionTestSuite2…g.apache.ignite.internal.processors.cache.persistence.db.wal
> (4)
> IgniteWALTailIsReachedDuringIterationOverArchiveTest.testStandAloneIterator
> IgniteWalFormatFileFailoverTest.testFailureHandlerTriggered
> IgniteWalFormatFileFailoverTest.testFailureHandlerTriggeredFsync
> IgniteWalIteratorExceptionDuringReadTest.test
> org.apache.ignite.testsuites.IgnitePdsCompressionTestSuite2…e.ignite.internal.processors.cache.persistence.db.wal.reader
> (9)
> IgniteWalReaderTest.testCheckBoundsIterator
> IgniteWalReaderTest.testFillWalAndReadRecords
> IgniteWalReaderTest.testFillWalForExactSegmentsCount
> IgniteWalReaderTest.testFillWalWithDifferentTypes
> IgniteWalReaderTest.testPutAllTxIntoTwoNodes
> IgniteWalReaderTest.testRemoveOperationPresentedForDataEntry
> IgniteWalReaderTest.testRemoveOperationPresentedForDataEntryForAtomic
> IgniteWalReaderTest.testTxFillWalAndExtractDataRecords
> IgniteWalReaderTest.testTxRecordsReadWoBinaryMeta
> org.apache.ignite.testsuites.IgnitePdsCompressionTestSuite2…ache.ignite.internal.processors.cache.persistence.wal.reader
> (2)
> StandaloneWalRecordsIteratorTest.testCorrectClosingFileDescriptors
> StandaloneWalRecordsIteratorTest.testStrictBounds
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10431) Make tests independent of memory size
Sergi Vladykin created IGNITE-10431:
---
Summary: Make tests independent of memory size
Key: IGNITE-10431
URL: https://issues.apache.org/jira/browse/IGNITE-10431
Project: Ignite
Issue Type: Bug
Reporter: Sergi Vladykin
The following tests were added to Page Compression suite and they fail because
page size there increased to 8k.
{code:java}
org.apache.ignite.testsuites.IgnitePdsCompressionTestSuite2…g.apache.ignite.internal.processors.cache.persistence.db.wal
(4)
IgniteWALTailIsReachedDuringIterationOverArchiveTest.testStandAloneIterator
IgniteWalFormatFileFailoverTest.testFailureHandlerTriggered
IgniteWalFormatFileFailoverTest.testFailureHandlerTriggeredFsync
IgniteWalIteratorExceptionDuringReadTest.test
org.apache.ignite.testsuites.IgnitePdsCompressionTestSuite2…e.ignite.internal.processors.cache.persistence.db.wal.reader
(9)
IgniteWalReaderTest.testCheckBoundsIterator
IgniteWalReaderTest.testFillWalAndReadRecords
IgniteWalReaderTest.testFillWalForExactSegmentsCount
IgniteWalReaderTest.testFillWalWithDifferentTypes
IgniteWalReaderTest.testPutAllTxIntoTwoNodes
IgniteWalReaderTest.testRemoveOperationPresentedForDataEntry
IgniteWalReaderTest.testRemoveOperationPresentedForDataEntryForAtomic
IgniteWalReaderTest.testTxFillWalAndExtractDataRecords
IgniteWalReaderTest.testTxRecordsReadWoBinaryMeta
org.apache.ignite.testsuites.IgnitePdsCompressionTestSuite2…ache.ignite.internal.processors.cache.persistence.wal.reader
(2)
StandaloneWalRecordsIteratorTest.testCorrectClosingFileDescriptors
StandaloneWalRecordsIteratorTest.testStrictBounds
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10330) Implement disk page compression
[ https://issues.apache.org/jira/browse/IGNITE-10330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergi Vladykin updated IGNITE-10330: Description: IEP: [https://cwiki.apache.org/confluence/display/IGNITE/IEP-20%3A+Data+Compression+in+Ignite#IEP-20:DataCompressioninIgnite-Withoutin-memorycompression] Dev: http://apache-ignite-developers.2346864.n4.nabble.com/Disk-page-compression-for-Ignite-persistent-store-td38009.html was: IEP: [https://cwiki.apache.org/confluence/display/IGNITE/IEP-20%3A+Data+Compression+in+Ignite#IEP-20:DataCompressioninIgnite-Withoutin-memorycompression] > Implement disk page compression > --- > > Key: IGNITE-10330 > URL: https://issues.apache.org/jira/browse/IGNITE-10330 > Project: Ignite > Issue Type: New Feature > Components: cache >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Major > Fix For: 2.8 > > > IEP: > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-20%3A+Data+Compression+in+Ignite#IEP-20:DataCompressioninIgnite-Withoutin-memorycompression] > Dev: > http://apache-ignite-developers.2346864.n4.nabble.com/Disk-page-compression-for-Ignite-persistent-store-td38009.html > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10330) Implement disk page compression
[ https://issues.apache.org/jira/browse/IGNITE-10330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergi Vladykin updated IGNITE-10330: Description: IEP: [https://cwiki.apache.org/confluence/display/IGNITE/IEP-20%3A+Data+Compression+in+Ignite#IEP-20:DataCompressioninIgnite-Withoutin-memorycompression] > Implement disk page compression > --- > > Key: IGNITE-10330 > URL: https://issues.apache.org/jira/browse/IGNITE-10330 > Project: Ignite > Issue Type: New Feature > Components: cache >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Major > Fix For: 2.8 > > > IEP: > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-20%3A+Data+Compression+in+Ignite#IEP-20:DataCompressioninIgnite-Withoutin-memorycompression] > > -- 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=16700782#comment-16700782 ] Ilya Kasnacheev commented on IGNITE-9298: - [~deviljelly] [~a-polyakov] [~dpavlov] I have merged two commits together to have two tests, best parameter names, modern USAGE and test included in suite. Please review my changes so that I can merge. I have also removed 'enable ssl' parameter since if you specify keystore it's obvious that you want SSL, and if you don't it's obvious that you're not getting it. So --keystore enables SSL. > 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.8 > > Attachments: Arguments.patch, CommandHandler.patch > > > We required SSL on the connector port and to use control.sh to work with the > baseline configuration. > This morning I added support, see attached patches against 2.6.0 for > org/apache/ignite/internal/commandline/CommandHandler.java > org/apache/ignite/internal/commandline/Arguments.java > No tests, no docs. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9298) control.sh does not support SSL (org.apache.ignite.internal.commandline.CommandHandler)
[ https://issues.apache.org/jira/browse/IGNITE-9298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700776#comment-16700776 ] ASF GitHub Bot commented on IGNITE-9298: GitHub user alamar opened a pull request: https://github.com/apache/ignite/pull/5516 IGNITE-9298 SSL support in control.sh I have merged two commits to get best of two worlds. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9298 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5516.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 #5516 commit 8de5e6fbb9e75deaff80337ae5e72675186653d8 Author: Ilya Kasnacheev Date: 2018-11-27T17:39:19Z IGNITE-9298 SSL support in control.sh > 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.8 > > 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-10193) IgniteBaselineAffinityTopologyActivationTest#testBaselineTopologyHistoryIsDeletedOnBaselineDelete fails asserting bltHist.history().size()
[
https://issues.apache.org/jira/browse/IGNITE-10193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700773#comment-16700773
]
ASF GitHub Bot commented on IGNITE-10193:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5446
> IgniteBaselineAffinityTopologyActivationTest#testBaselineTopologyHistoryIsDeletedOnBaselineDelete
> fails asserting bltHist.history().size()
> --
>
> Key: IGNITE-10193
> URL: https://issues.apache.org/jira/browse/IGNITE-10193
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> IgniteBaselineAffinityTopologyActivationTest#testBaselineTopologyHistoryIsDeletedOnBaselineDelete
> (in current codebase muted by renaming to
> {{_testBaselineTopologyHistoryIsDeletedOnBaselineDelete}}) fails. Test
> javadoc says: "Restore this test when requirements for BaselineTopology
> deletion are clarified and this feature is covered with more tests."
> (javadoc appears to be giving proper reason)
> Failure message: {noformat}
> junit.framework.AssertionFailedError:
> Expected :0
> Actual :2
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest$17.verify(IgniteBaselineAffinityTopologyActivationTest.java:1041)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.verifyBaselineTopologyHistoryOnNodes(IgniteBaselineAffinityTopologyActivationTest.java:693)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.testBaselineTopologyHistoryIsDeletedOnBaselineDelete(IgniteBaselineAffinityTopologyActivationTest.java:1082)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Snippet of code referred to from above message: {code}assertEquals(0,
> bltHist.history().size());{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10193) IgniteBaselineAffinityTopologyActivationTest#testBaselineTopologyHistoryIsDeletedOnBaselineDelete fails asserting bltHist.history().size()
[
https://issues.apache.org/jira/browse/IGNITE-10193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700763#comment-16700763
]
Pavel Kovalenko commented on IGNITE-10193:
--
[~aplatonov] Thank you for contribution. Changes merged to master.
> IgniteBaselineAffinityTopologyActivationTest#testBaselineTopologyHistoryIsDeletedOnBaselineDelete
> fails asserting bltHist.history().size()
> --
>
> Key: IGNITE-10193
> URL: https://issues.apache.org/jira/browse/IGNITE-10193
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> IgniteBaselineAffinityTopologyActivationTest#testBaselineTopologyHistoryIsDeletedOnBaselineDelete
> (in current codebase muted by renaming to
> {{_testBaselineTopologyHistoryIsDeletedOnBaselineDelete}}) fails. Test
> javadoc says: "Restore this test when requirements for BaselineTopology
> deletion are clarified and this feature is covered with more tests."
> (javadoc appears to be giving proper reason)
> Failure message: {noformat}
> junit.framework.AssertionFailedError:
> Expected :0
> Actual :2
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest$17.verify(IgniteBaselineAffinityTopologyActivationTest.java:1041)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.verifyBaselineTopologyHistoryOnNodes(IgniteBaselineAffinityTopologyActivationTest.java:693)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.testBaselineTopologyHistoryIsDeletedOnBaselineDelete(IgniteBaselineAffinityTopologyActivationTest.java:1082)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Snippet of code referred to from above message: {code}assertEquals(0,
> bltHist.history().size());{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10158) Some tests in IgniteCacheAbstractQuerySelfTest are incorrectly muted
[
https://issues.apache.org/jira/browse/IGNITE-10158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700724#comment-16700724
]
ASF GitHub Bot commented on IGNITE-10158:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5344
> Some tests in IgniteCacheAbstractQuerySelfTest are incorrectly muted
>
>
> Key: IGNITE-10158
> URL: https://issues.apache.org/jira/browse/IGNITE-10158
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Some tests in
> [IgniteCacheAbstractQuerySelfTest|https://github.com/apache/ignite/blob/master/modules/indexing/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCacheAbstractQuerySelfTest.java]
> are muted by renaming (prefixing with underscore, {{_test...}} and refer
> invalid JIRA URL in fail parameter
> ("http://atlassian.gridgain.com/jira/browse/GG-11216";).
> - _testDifferentKeyTypes
> this test should change expectation to opposite and after that recovered
> - _testObjectQueryWithSwap and _testTwoObjectsTextSearch
> Need to be properly muted and further investigated, per separate tickets.
> Per my preliminary checks tests fail because
> of wrong cache configuration, although there is also a chance that test
> design is wrong and these should be deleted.
> There is also a dead code there, a private class {{EmptyObject}} - it needs
> to be deleted. Code that was using this class was removed per
> [IGNITE-1232|https://issues.apache.org/jira/browse/IGNITE-1232] ([commit
> 79b8b08|https://github.com/gridgain/apache-ignite/commit/68891e89dd0e0f19321d6a4d45ae7372279b8b08#diff-a2f35b3aa70a70b98ce0cd6a1381d1f7])
> but this private class was forgotten.
> I also searched project code for other occurrences of mentioned troublesome
> fail parameter "GG-11216" and found yet another incorrectly muted test:
> {{IgniteCacheQueryMultiThreadedSelfTest#_testMultiThreadedSwapUnswapLongString}}
> This test should be recovered. It passed on my machine and per my comparison
> with similar test cases {{testMultiThreadedSwapUnswapLong}} and
> {{testMultiThreadedSwapUnswapString}} its design looks fairly reasonable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-1793) [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes
[
https://issues.apache.org/jira/browse/IGNITE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-1793:
---
Fix Version/s: 2.8
> [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC
> sometimes
> -
>
> Key: IGNITE-1793
> URL: https://issues.apache.org/jira/browse/IGNITE-1793
> Project: Ignite
> Issue Type: Test
>Reporter: Artem Shutak
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.8
>
> Attachments: test.logs
>
>
> IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes.
> Test hangs on IgniteCountDownLatch.count() method.
> {noformat}
> Thread [name="test-runner", id=24157, state=WAITING, blockCnt=0, waitCnt=96]
> Lock [object=o.a.i.i.util.future.GridFutureAdapter$ChainFuture@1e542154,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4525)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1544)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:348)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:342)
> at
> o.a.i.i.processors.cache.GridCacheUtils.outTx(GridCacheUtils.java:962)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl.count(GridCacheCountDownLatchImpl.java:143)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkRemovedLatch(IgniteCountDownLatchAbstractSelfTest.java:159)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkCountDown(IgniteCountDownLatchAbstractSelfTest.java:232)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkLatch(IgniteCountDownLatchAbstractSelfTest.java:84)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.testLatch(IgniteCountDownLatchAbstractSelfTest.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
> at
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
> at
> o.a.i.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10106) Cache 5 test suite optimization
[ https://issues.apache.org/jira/browse/IGNITE-10106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700717#comment-16700717 ] ASF GitHub Bot commented on IGNITE-10106: - Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5252 > Cache 5 test suite optimization > --- > > Key: IGNITE-10106 > URL: https://issues.apache.org/jira/browse/IGNITE-10106 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > We need to investigate how to optimize these tests: > |CacheSerializableTransactionsTest.testGetRemoveTxNearCache2| > |[CacheSerializableTransactionsTest.testGetRemoveTxNearCache1|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]| > |CacheSerializableTransactionsTest.testRandomOperations| > |[CacheSerializableTransactionsTest.testIncrementTxRestart|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]| > |CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockNodeRestart| > |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockFromClientsNodeRestart|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]| > |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockWithNonSerializable|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]| > |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockGetPut|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]| > |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockFromClients|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]| > |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlock|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]| > and optimize them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10330) Implement disk page compression
[ https://issues.apache.org/jira/browse/IGNITE-10330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700722#comment-16700722 ] Dmitriy Pavlov commented on IGNITE-10330: - [~sergi.vladykin] I see PR is merged, could you please set the status to Resolved and provide a fixVersion (2.8 I guess) > Implement disk page compression > --- > > Key: IGNITE-10330 > URL: https://issues.apache.org/jira/browse/IGNITE-10330 > Project: Ignite > Issue Type: New Feature > Components: cache >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10158) Some tests in IgniteCacheAbstractQuerySelfTest are incorrectly muted
[
https://issues.apache.org/jira/browse/IGNITE-10158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700721#comment-16700721
]
Pavel Kovalenko commented on IGNITE-10158:
--
[~oignatenko] Thank you for contribution. Changes merged to master.
> Some tests in IgniteCacheAbstractQuerySelfTest are incorrectly muted
>
>
> Key: IGNITE-10158
> URL: https://issues.apache.org/jira/browse/IGNITE-10158
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Some tests in
> [IgniteCacheAbstractQuerySelfTest|https://github.com/apache/ignite/blob/master/modules/indexing/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCacheAbstractQuerySelfTest.java]
> are muted by renaming (prefixing with underscore, {{_test...}} and refer
> invalid JIRA URL in fail parameter
> ("http://atlassian.gridgain.com/jira/browse/GG-11216";).
> - _testDifferentKeyTypes
> this test should change expectation to opposite and after that recovered
> - _testObjectQueryWithSwap and _testTwoObjectsTextSearch
> Need to be properly muted and further investigated, per separate tickets.
> Per my preliminary checks tests fail because
> of wrong cache configuration, although there is also a chance that test
> design is wrong and these should be deleted.
> There is also a dead code there, a private class {{EmptyObject}} - it needs
> to be deleted. Code that was using this class was removed per
> [IGNITE-1232|https://issues.apache.org/jira/browse/IGNITE-1232] ([commit
> 79b8b08|https://github.com/gridgain/apache-ignite/commit/68891e89dd0e0f19321d6a4d45ae7372279b8b08#diff-a2f35b3aa70a70b98ce0cd6a1381d1f7])
> but this private class was forgotten.
> I also searched project code for other occurrences of mentioned troublesome
> fail parameter "GG-11216" and found yet another incorrectly muted test:
> {{IgniteCacheQueryMultiThreadedSelfTest#_testMultiThreadedSwapUnswapLongString}}
> This test should be recovered. It passed on my machine and per my comparison
> with similar test cases {{testMultiThreadedSwapUnswapLong}} and
> {{testMultiThreadedSwapUnswapString}} its design looks fairly reasonable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10430) Ignite.NET Data Region Metrics: PagesRead, PagesWritten, PagesReplaced, OffHeapSize, OffheapUsedSize
Alexey Kukushkin created IGNITE-10430: - Summary: Ignite.NET Data Region Metrics: PagesRead, PagesWritten, PagesReplaced, OffHeapSize, OffheapUsedSize Key: IGNITE-10430 URL: https://issues.apache.org/jira/browse/IGNITE-10430 Project: Ignite Issue Type: Improvement Affects Versions: 2.6 Reporter: Alexey Kukushkin Assignee: Alexey Kukushkin Add Ignite.NET Data Region Metrics presently existing in Java but missing in .NET: PagesRead, PagesWritten, PagesReplaced, OffHeapSize, OffheapUsedSize -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-1793) [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes
[
https://issues.apache.org/jira/browse/IGNITE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov reassigned IGNITE-1793:
--
Assignee: Vladislav Pyatkov
> [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC
> sometimes
> -
>
> Key: IGNITE-1793
> URL: https://issues.apache.org/jira/browse/IGNITE-1793
> Project: Ignite
> Issue Type: Test
>Reporter: Artem Shutak
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.8
>
> Attachments: test.logs
>
>
> IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes.
> Test hangs on IgniteCountDownLatch.count() method.
> {noformat}
> Thread [name="test-runner", id=24157, state=WAITING, blockCnt=0, waitCnt=96]
> Lock [object=o.a.i.i.util.future.GridFutureAdapter$ChainFuture@1e542154,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4525)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1544)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:348)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:342)
> at
> o.a.i.i.processors.cache.GridCacheUtils.outTx(GridCacheUtils.java:962)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl.count(GridCacheCountDownLatchImpl.java:143)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkRemovedLatch(IgniteCountDownLatchAbstractSelfTest.java:159)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkCountDown(IgniteCountDownLatchAbstractSelfTest.java:232)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkLatch(IgniteCountDownLatchAbstractSelfTest.java:84)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.testLatch(IgniteCountDownLatchAbstractSelfTest.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
> at
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
> at
> o.a.i.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10106) Cache 5 test suite optimization
[ https://issues.apache.org/jira/browse/IGNITE-10106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700710#comment-16700710 ] Pavel Kovalenko commented on IGNITE-10106: -- [~aplatonov] Thank you for contribution. Changes merged to master. > Cache 5 test suite optimization > --- > > Key: IGNITE-10106 > URL: https://issues.apache.org/jira/browse/IGNITE-10106 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > We need to investigate how to optimize these tests: > |CacheSerializableTransactionsTest.testGetRemoveTxNearCache2| > |[CacheSerializableTransactionsTest.testGetRemoveTxNearCache1|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]| > |CacheSerializableTransactionsTest.testRandomOperations| > |[CacheSerializableTransactionsTest.testIncrementTxRestart|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]| > |CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockNodeRestart| > |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockFromClientsNodeRestart|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]| > |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockWithNonSerializable|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]| > |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockGetPut|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]| > |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockFromClients|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]| > |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlock|https://ci.ignite.apache.org/viewLog.html?currentGroup=test&scope=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest&pager.currentPage=1&order=DURATION_DESC&recordsPerPage=20&filterText=&status=&buildTypeId=IgniteTests24Java8_Cache5&buildId=2160072&tab=testsInfo]| > and optimize them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10017) Infinite loop with 3rd party persistency and no value for the key in the data store
[ https://issues.apache.org/jira/browse/IGNITE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700694#comment-16700694 ] Pavel Kovalenko commented on IGNITE-10017: -- [~roman_s] Thank you for contribution. I've reviewed your changes. Could you please add the reproducer to your PR to prove that changes work well? Re-run tests and then get the green visa from TC Bot here [mtcga.gridgain.com|https://mtcga.gridgain.com/] . After all, steps are done and green visa appears, I'll merge your changes to master. > Infinite loop with 3rd party persistency and no value for the key in the data > store > --- > > Key: IGNITE-10017 > URL: https://issues.apache.org/jira/browse/IGNITE-10017 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Critical > Attachments: IgniteGetBinaryKeyReadThroughSelfTest.java > > > Basically, it happens because _GridCacheAdapter#clearReservationsIfNeeded_ > fails to clear its local map. > > The problem occurs when _IgniteBiTuple_ is used as a key, but the value for > the key is not available. The execution path goes through > _GridDhtCacheAdapter#getDhtAllAsync_ -> _GridCacheAdapter#getAllAsync0_, for > instance if you have an affinityCall and execute get() from within. > > What happens is > # On get operation, keys are stored in the local map of _GridCacheAdapter_. > For this, _UserKeyCacheObjectImpl#prepareForCache_ creates > _KeyCacheObjectImpl_ with an unmarshalled val (BinaryObject), which is > different from that of _UserKeyCacheObjectImpl_ (val is BiTuple here) that is > used further as a key to retrieve the value from the map. > # _GridCacheAdapter#clearReservationsIfNeeded_ is called to clear the map > from keys for which values were not found. It uses _UserKeyCacheObjectImpl_ > to check the map, but can’t peek and remove even if the key is in the map > (hashes won’t match). The key is left in the map. > # The problem comes with the 2nd get: > - we check if the key is not in the map and create a new one, then BOOM! > loops while _putIfAbsent == null_ succeeds (but it won’t) > All these data types are ok – > [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L212-L239] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8718) Documentation about using of the C++ BinaryWriter/BinaryReader should be updated
[
https://issues.apache.org/jira/browse/IGNITE-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700679#comment-16700679
]
ASF GitHub Bot commented on IGNITE-8718:
Github user isapego closed the pull request at:
https://github.com/apache/ignite/pull/5490
> Documentation about using of the C++ BinaryWriter/BinaryReader should be
> updated
>
>
> Key: IGNITE-8718
> URL: https://issues.apache.org/jira/browse/IGNITE-8718
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.5
>Reporter: Andrey Aleksandrov
>Assignee: Igor Sapego
>Priority: Major
> Labels: c++
> Fix For: 2.8
>
>
> The usage that should be documented:
> 1)In case if you get some writer from BinaryWriter then you started writing
> session. Until method close will not be called for this writer you can't get
> another writer.
>
> For example, next code isn't correct:
> {code:java}
> BinaryMapWriter field1Writer = writer.WriteMap int64_t>("field1", MapType::HASH_MAP); //here you start writing session
> BinaryMapWriter field2Writer = writer.WriteMap int64_t>("field2", MapType::HASH_MAP); //here you start another writing
> session - error
> {code}
> Should be:
>
> {code:java}
> BinaryMapWriter field1Writer = writer.WriteMap int64_t>("field1", MapType::HASH_MAP); //here you start writing session
> //do something
> field1Writer.Close() //here you end writing session
> BinaryMapWriter field2Writer = writer.WriteMap int64_t>("field2", MapType::HASH_MAP); //here you start another writing
> session
> //do something
> field2Writer.Close() //here you end another writing session
> {code}
>
> 2) In case if you get some reader from BinaryWriter then you started reading
> session. Until something will not be read from this reader you can't get
> another reader.
>
> For example, next code isn't correct:
>
> {code:java}
> BinaryMapReader field1Reader = reader.ReadMap int64_t>("field1"); //start reading session
> BinaryMapReader field2Reader = reader.ReadMap int64_t>("field2"); //start another read session - error
> {code}
> Should be for example:
> {code:java}
> BinaryMapReader field1Reader = reader.ReadMap int64_t>("field1"); //start reading session
> ...
> field1Reader.GetNext(key, val); //reading done
> ...
> BinaryMapReader field2Reader = reader.ReadMap int64_t>("field2"); //start another read session
> ...
> field2Reader.GetNext(key, val); //reading done
> ...{code}
>
>
>
> In the case of the writer, it looks like expected. In case of the reader, it
> looks a little bit confusing.
>
> These two behaviors should be described in the documentation as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10348) Safely recreate metastore to mitigate IGNITE-8735
[ https://issues.apache.org/jira/browse/IGNITE-10348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700684#comment-16700684 ] ASF GitHub Bot commented on IGNITE-10348: - GitHub user SpiderRus opened a pull request: https://github.com/apache/ignite/pull/5515 IGNITE-10348 Safely recreate metastore to mitigate IGNITE-8735 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10348 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5515.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 #5515 commit efda38b24ddfc7854b7fc15b43a0863de3420091 Author: Alexey Stelmak Date: 2018-11-27T16:38:53Z Temporary storage > Safely recreate metastore to mitigate IGNITE-8735 > - > > Key: IGNITE-10348 > URL: https://issues.apache.org/jira/browse/IGNITE-10348 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexey Goncharuk >Assignee: Alexey Stelmak >Priority: Critical > Fix For: 2.8 > > > We've fixed the issue IGNITE-8735, so new Ignite deployments are not affected > by this issue, but old deployments still may fail if a wrong page was already > put to the free list. We need to find out a way to repair this situation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10390) BPlusTree#isEmpty() does not release root page
[
https://issues.apache.org/jira/browse/IGNITE-10390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700682#comment-16700682
]
ASF GitHub Bot commented on IGNITE-10390:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5486
> BPlusTree#isEmpty() does not release root page
> --
>
> Key: IGNITE-10390
> URL: https://issues.apache.org/jira/browse/IGNITE-10390
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
>
> {code}
> long rootId, rootPage = acquirePage(rootId = treeMeta.rootId);
> {code}
> The acquired page is never released. Corresponding tests should be added.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7072) IgniteCache.replace(k, v, nv) does not work in binary mode without classes
[
https://issues.apache.org/jira/browse/IGNITE-7072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700681#comment-16700681
]
ASF GitHub Bot commented on IGNITE-7072:
Github user isapego closed the pull request at:
https://github.com/apache/ignite/pull/5064
> IgniteCache.replace(k, v, nv) does not work in binary mode without classes
> --
>
> Key: IGNITE-7072
> URL: https://issues.apache.org/jira/browse/IGNITE-7072
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Pavel Tupitsyn
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.8
>
>
> {{IgniteCache.replace(K key, V oldVal, V newVal)}} method deserializes cache
> values in order to compare them, which causes exception when classes are not
> present on server:
> {code}
> class org.apache.ignite.IgniteCheckedException: Unknown pair [platformId=0,
> typeId=-1690383137]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7260)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.isAll(GridCacheContext.java:1242)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:464)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1223)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:666)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1040)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareAsyncLocal(GridNearTxLocal.java:3452)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareColocatedTx(IgniteTxHandler.java:257)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.proceedPrepare(GridNearOptimisticTxPrepareFuture.java:574)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepareSingle(GridNearOptimisticTxPrepareFuture.java:401)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepare0(GridNearOptimisticTxPrepareFuture.java:344)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepareOnTopology(GridNearOptimisticTxPrepareFutureAdapter.java:137)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepare(GridNearOptimisticTxPrepareFutureAdapter.java:74)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareNearTxLocal(GridNearTxLocal.java:3161)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:3221)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.optimisticPutFuture(GridNearTxLocal.java:2391)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:622)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync(GridNearTxLocal.java:385)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$34.op(GridCacheAdapter.java:2707)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOp.op(GridCacheAdapter.java:5120)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4260)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOpRetryFuture.execute(GridCacheAdapter.java:4841)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4173)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync0(GridCacheAdapter.java:2705)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2689)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.replaceAsync(GridCacheAdapter.java:2776)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.replaceAsync(IgniteCacheProxyImpl.java:1182)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.replaceAsync(GatewayProtectedCacheProxy.java:1082)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutLong(PlatformCache.java:677)
>
[jira] [Commented] (IGNITE-9948) JettyRestProcessorAuthenticationWithTokenSelfTest.testGetOrCreateCache fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-9948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700669#comment-16700669
]
ASF GitHub Bot commented on IGNITE-9948:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5038
> JettyRestProcessorAuthenticationWithTokenSelfTest.testGetOrCreateCache fails
> on TC
> ---
>
> Key: IGNITE-9948
> URL: https://issues.apache.org/jira/browse/IGNITE-9948
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> [Example of
> fail.|https://ci.ignite.apache.org/viewLog.html?buildId=2118632&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_JavaClient#testNameId-4416495803371140089]
> Log details:
> {noformat}
> [2018-10-19 06:59:53,063][ERROR][main][root] Test failed.
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.rest.JettyRestProcessorAbstractSelfTest.checkGetOrCreateAndDestroy(JettyRestProcessorAbstractSelfTest.java:593)
> at
> org.apache.ignite.internal.processors.rest.JettyRestProcessorAbstractSelfTest.testGetOrCreateCache(JettyRestProcessorAbstractSelfTest.java:619)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:142)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2091)
> at java.lang.Thread.run(Thread.java:748){noformat}
> The possible reason is the race between getting cache instance on different
> nodes:
> # Jetty query create cache successfully on one node.
> # PME doesn't have completed.
> # The test fails with NPE while getting the instance of cache on another node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7441) Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property
[ https://issues.apache.org/jira/browse/IGNITE-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700665#comment-16700665 ] ASF GitHub Bot commented on IGNITE-7441: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5482 > Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property > --- > > Key: IGNITE-7441 > URL: https://issues.apache.org/jira/browse/IGNITE-7441 > Project: Ignite > Issue Type: Task > Components: managed services >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Minor > Fix For: 2.8 > > > IGNITE_SERVICES_COMPATIBILITY_MODE system property was introduced to > configure backward compatibility mode for service configuration classes. But > since it was done in 1.9 and current version is completely incompatible with > it, there is no point in keeping this property. > Moreover, it is ignored after IGNITE-5145. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10390) BPlusTree#isEmpty() does not release root page
[
https://issues.apache.org/jira/browse/IGNITE-10390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700674#comment-16700674
]
Ignite TC Bot commented on IGNITE-10390:
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2386301&buildTypeId=IgniteTests24Java8_RunAll]
> BPlusTree#isEmpty() does not release root page
> --
>
> Key: IGNITE-10390
> URL: https://issues.apache.org/jira/browse/IGNITE-10390
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
>
> {code}
> long rootId, rootPage = acquirePage(rootId = treeMeta.rootId);
> {code}
> The acquired page is never released. Corresponding tests should be added.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8718) Documentation about using of the C++ BinaryWriter/BinaryReader should be updated
[
https://issues.apache.org/jira/browse/IGNITE-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-8718:
Fix Version/s: (was: 2.7)
2.8
> Documentation about using of the C++ BinaryWriter/BinaryReader should be
> updated
>
>
> Key: IGNITE-8718
> URL: https://issues.apache.org/jira/browse/IGNITE-8718
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.5
>Reporter: Andrey Aleksandrov
>Assignee: Igor Sapego
>Priority: Major
> Labels: c++
> Fix For: 2.8
>
>
> The usage that should be documented:
> 1)In case if you get some writer from BinaryWriter then you started writing
> session. Until method close will not be called for this writer you can't get
> another writer.
>
> For example, next code isn't correct:
> {code:java}
> BinaryMapWriter field1Writer = writer.WriteMap int64_t>("field1", MapType::HASH_MAP); //here you start writing session
> BinaryMapWriter field2Writer = writer.WriteMap int64_t>("field2", MapType::HASH_MAP); //here you start another writing
> session - error
> {code}
> Should be:
>
> {code:java}
> BinaryMapWriter field1Writer = writer.WriteMap int64_t>("field1", MapType::HASH_MAP); //here you start writing session
> //do something
> field1Writer.Close() //here you end writing session
> BinaryMapWriter field2Writer = writer.WriteMap int64_t>("field2", MapType::HASH_MAP); //here you start another writing
> session
> //do something
> field2Writer.Close() //here you end another writing session
> {code}
>
> 2) In case if you get some reader from BinaryWriter then you started reading
> session. Until something will not be read from this reader you can't get
> another reader.
>
> For example, next code isn't correct:
>
> {code:java}
> BinaryMapReader field1Reader = reader.ReadMap int64_t>("field1"); //start reading session
> BinaryMapReader field2Reader = reader.ReadMap int64_t>("field2"); //start another read session - error
> {code}
> Should be for example:
> {code:java}
> BinaryMapReader field1Reader = reader.ReadMap int64_t>("field1"); //start reading session
> ...
> field1Reader.GetNext(key, val); //reading done
> ...
> BinaryMapReader field2Reader = reader.ReadMap int64_t>("field2"); //start another read session
> ...
> field2Reader.GetNext(key, val); //reading done
> ...{code}
>
>
>
> In the case of the writer, it looks like expected. In case of the reader, it
> looks a little bit confusing.
>
> These two behaviors should be described in the documentation as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5569) TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a cluster DDoS
[ https://issues.apache.org/jira/browse/IGNITE-5569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700647#comment-16700647 ] Alexey Goncharuk commented on IGNITE-5569: -- Cannot merge without conflicts, pull from master is needed. > TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a > cluster DDoS > - > > Key: IGNITE-5569 > URL: https://issues.apache.org/jira/browse/IGNITE-5569 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.8 > > > A firewall configuration issue may effectively lead to a cluster DDoS. The > scheme is as follows: > 1) A node G joins the cluster, and a firewall rule forbids incoming > connection from cluster to this node > 2) Cluster successfully processes NodeAddedMesage and fires a discovery > NODE_JOINED event (not sure why?) > 4) The last node in the ring fails to connect to the newly joined node and > generates NODE_FAILED event > 5) Coordinator drops the connection, joining node attempts to connect again > The issues I see here: > 1) Neither coordinator nor joining node print out the reason why the joining > node failed / did not join. A slight hint (failed to send message to the next > node) is printed on the node with the largest order (the one that attempted > to close the ring), but the root cause (connection refused) is also not > printed > 2) The joining node attempts to connect to the cluster with the same node ID. > This violates an invariant we heavily rely on that once a node ID leaves a > cluster, this ID never comes back again > 3) Each discovery event leads to a partition exchange which blocks all cache > operations for a time interval equal at least to the full ring latency time. > If several nodes are started on a malicious host, this may lead to almost > full cluster degradation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10429) ML: TensorFlowLocalInferenceExample fails on Windows
Anton Dmitriev created IGNITE-10429: --- Summary: ML: TensorFlowLocalInferenceExample fails on Windows Key: IGNITE-10429 URL: https://issues.apache.org/jira/browse/IGNITE-10429 Project: Ignite Issue Type: Bug Components: ml Affects Versions: 2.8 Reporter: Anton Dmitriev Assignee: Anton Dmitriev Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8640) If first createCache fail - Ignite is freezing on next createCache
[
https://issues.apache.org/jira/browse/IGNITE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700629#comment-16700629
]
Ignite TC Bot commented on IGNITE-8640:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Queries{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=2406918]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccPartitionedSqlTxQueriesWithReducerTest.testQueryReducerDeadlockInsertWithStmtTimeout
- 0,0% fails in last 100 master runs.
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2406907]]
* ZookeeperDiscoverySpiTestSuite2:
GridCachePartitionedNodeRestartTest.testRestartWithTxSixNodesTwoBackups - 0,0%
fails in last 100 master runs.
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2406906]]
{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2349880&buildTypeId=IgniteTests24Java8_RunAll]
> If first createCache fail - Ignite is freezing on next createCache
> --
>
> Key: IGNITE-8640
> URL: https://issues.apache.org/jira/browse/IGNITE-8640
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Nikolay Izhikov
>Assignee: Denis Garus
>Priority: Critical
> Fix For: 2.8
>
>
> If first {{createCache}} operation fails on some condition inside
> {{GridCacheProcessor#validate}} then second {{createCache}} will freeze
> forever.
> Reproducer:
> {code:java}
> package org.apache.ignite.internal.processors.cache;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicy;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.testframework.GridTestUtils;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> public class CreateCacheFreezeTest extends GridCommonAbstractTest {
> public void testCreateEncryptedNotPersistedCacheFail() throws Exception {
> IgniteEx ignite = startGrid(0);
>
> GridTestUtils.assertThrowsWithCause(() -> {
> CacheConfiguration cc = new
> CacheConfiguration<>("failed");
> cc.setEvictionPolicy(new FifoEvictionPolicy());
> cc.setOnheapCacheEnabled(false);
> ignite.createCache(cc);
> return 0;
> }, IgniteCheckedException.class);
> IgniteCache cache = ignite.createCache(new
> CacheConfiguration<>("default"));
> assertNotNull(cache);
> }
> }
> {code}
> Log message:
> {noformat}
> [2018-05-29
> 16:38:11,958][ERROR][exchange-worker-#38%cache.CreateCacheFreezeTest0%][GridDhtPartitionsExchangeFuture]
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=DynamicCacheChangeBatch
> [id=67cce1ca361-993dd9c2-f4fe-443b-af43-27e06424e1b0,
> reqs=[DynamicCacheChangeRequest [cacheName=failed, hasCfg=true,
> nodeId=a525b74c-aec5-4c62-855a-ff96ef30, clientStartOnly=false,
> stop=false, destroy=false, disabledAfterStartfalse]],
> exchangeActions=ExchangeActions [startCaches=[failed], stopCaches=null,
> startGrps=[failed], stopGrps=[], resetParts=null, stateChangeRequest=null],
> startCaches=false], affTopVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=a525b74c-aec5-4c62-855a-ff96ef30, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1527601090538, loc=true, ver=2.5.0#19700101-sha1:,
> isClient=false], topVer=1, nodeId8=a525b74c, msg=null,
> type=DISCOVERY_CUSTOM_EVT, tstamp=1527601091938]], nodeId=a525b74c,
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: stopping=false, groupName=null, caches=[]
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:375)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:197)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:828)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions(GridDhtPartitionTopologyImpl.java:369)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.Grid
[jira] [Updated] (IGNITE-10429) ML: TensorFlowLocalInferenceExample fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-10429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10429:
Description:
Failure is observed only on Windows - on Linux test passes. Failure message
says file is in use by another process
{noformat}
java.lang.RuntimeException: java.nio.file.FileSystemException:
C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
Процесс не может получить доступ к файлу, так как этот файл занят другим
процессом.
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:107)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializerTest.testSerializeDeserializeWithDirectory(DirectorySerializerTest.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.nio.file.FileSystemException:
C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
Процесс не может получить доступ к файлу, так как этот файл занят другим
процессом.
at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at
sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
at
sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
at java.nio.file.Files.delete(Files.java:1126)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:104)
... 26 more
{noformat}
Fix is to wrap Scanner usage in try-with-resources
was:
failure message says file is in use by another process
{noformat}
java.lang.RuntimeException: java.nio.file.FileSystemException:
C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
Процесс не может получить доступ к файлу, так как этот файл занят другим
процессом.
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:107)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializerTest.testSerializeDeserializeWithDirectory(DirectorySerializerTest.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.inte
[jira] [Commented] (IGNITE-10429) ML: TensorFlowLocalInferenceExample fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-10429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700625#comment-16700625
]
ASF GitHub Bot commented on IGNITE-10429:
-
GitHub user dmitrievanthony opened a pull request:
https://github.com/apache/ignite/pull/5514
IGNITE-10429: Wrap Scanner in DirectorySerializerTest into
try-with-resources.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10429
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5514.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 #5514
commit 82e5e487744cc5b56232b304eb90f040619272ea
Author: dmitrievanthony
Date: 2018-11-27T16:01:27Z
IGNITE-10429: Wrap Scanner in DirectorySerializerTest into
try-with-resources.
> ML: TensorFlowLocalInferenceExample fails on Windows
>
>
> Key: IGNITE-10429
> URL: https://issues.apache.org/jira/browse/IGNITE-10429
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.8
>Reporter: Anton Dmitriev
>Assignee: Anton Dmitriev
>Priority: Major
> Fix For: 2.8
>
>
> failure message says file is in use by another process
> {noformat}
> java.lang.RuntimeException: java.nio.file.FileSystemException:
> C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
> Процесс не может получить доступ к файлу, так как этот файл занят другим
> процессом.
> at
> org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:107)
> at
> org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
> at
> org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
> at
> org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
> at
> org.apache.ignite.ml.inference.util.DirectorySerializerTest.testSerializeDeserializeWithDirectory(DirectorySerializerTest.java:122)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.nio.file.FileSystemException:
> C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
> Процесс не может получить доступ к файлу, так как этот файл занят другим
> процессом.
> at
> sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
> at
> sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
> at
> sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> at java.nio.file.Files.delete(Files.java:1126)
> at
> org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory
[jira] [Updated] (IGNITE-10429) ML: TensorFlowLocalInferenceExample fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-10429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10429:
Description:
failure message says file is in use by another process
{noformat}
java.lang.RuntimeException: java.nio.file.FileSystemException:
C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
Процесс не может получить доступ к файлу, так как этот файл занят другим
процессом.
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:107)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializerTest.testSerializeDeserializeWithDirectory(DirectorySerializerTest.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.nio.file.FileSystemException:
C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
Процесс не может получить доступ к файлу, так как этот файл занят другим
процессом.
at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at
sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
at
sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
at java.nio.file.Files.delete(Files.java:1126)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:104)
... 26 more
{noformat}
Fix is to wrap Scanner usage in try-with-resources
was:
failure message says file is busy with another process
{noformat}
java.lang.RuntimeException: java.nio.file.FileSystemException:
C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
Процесс не может получить доступ к файлу, так как этот файл занят другим
процессом.
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:107)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializerTest.testSerializeDeserializeWithDirectory(DirectorySerializerTest.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.
[jira] [Updated] (IGNITE-10429) ML: TensorFlowLocalInferenceExample fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-10429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10429:
Description:
failure message says file is busy with another process
{noformat}
java.lang.RuntimeException: java.nio.file.FileSystemException:
C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
Процесс не может получить доступ к файлу, так как этот файл занят другим
процессом.
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:107)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializerTest.testSerializeDeserializeWithDirectory(DirectorySerializerTest.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.nio.file.FileSystemException:
C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
Процесс не может получить доступ к файлу, так как этот файл занят другим
процессом.
at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at
sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
at
sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
at java.nio.file.Files.delete(Files.java:1126)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:104)
... 26 more
{noformat}
Fix is to wrap Scanner usage in try-with-resources
was:
failure message says file is bysy with another process
{noformat}
java.lang.RuntimeException: java.nio.file.FileSystemException:
C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
Процесс не может получить доступ к файлу, так как этот файл занят другим
процессом.
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:107)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializerTest.testSerializeDeserializeWithDirectory(DirectorySerializerTest.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.
[jira] [Updated] (IGNITE-10429) ML: TensorFlowLocalInferenceExample fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-10429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10429:
Description:
failure message says file is bysy with another process
{noformat}
java.lang.RuntimeException: java.nio.file.FileSystemException:
C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
Процесс не может получить доступ к файлу, так как этот файл занят другим
процессом.
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:107)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
at
org.apache.ignite.ml.inference.util.DirectorySerializerTest.testSerializeDeserializeWithDirectory(DirectorySerializerTest.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.nio.file.FileSystemException:
C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
Процесс не может получить доступ к файлу, так как этот файл занят другим
процессом.
at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at
sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
at
sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
at java.nio.file.Files.delete(Files.java:1126)
at
org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:104)
... 26 more
{noformat}
Fix is to wrap Scanner usage in try-with-resources
> ML: TensorFlowLocalInferenceExample fails on Windows
>
>
> Key: IGNITE-10429
> URL: https://issues.apache.org/jira/browse/IGNITE-10429
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.8
>Reporter: Anton Dmitriev
>Assignee: Anton Dmitriev
>Priority: Major
> Fix For: 2.8
>
>
> failure message says file is bysy with another process
> {noformat}
> java.lang.RuntimeException: java.nio.file.FileSystemException:
> C:\Users\Gridgain\AppData\Local\Temp\directory_serializer_test_dst8891183962982271102\a\b\test.txt:
> Процесс не может получить доступ к файлу, так как этот файл занят другим
> процессом.
> at
> org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:107)
> at
> org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
> at
> org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
> at
> org.apache.ignite.ml.inference.util.DirectorySerializer.deleteDirectory(DirectorySerializer.java:99)
> at
> org.apache.ignite.ml.inference.util.DirectorySerializerTest.testSerializeDeserializeWithDirecto
[jira] [Updated] (IGNITE-10429) ML: TensorFlowLocalInferenceExample fails on Windows
[ https://issues.apache.org/jira/browse/IGNITE-10429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Dmitriev updated IGNITE-10429: Ignite Flags: (was: Docs Required) > ML: TensorFlowLocalInferenceExample fails on Windows > > > Key: IGNITE-10429 > URL: https://issues.apache.org/jira/browse/IGNITE-10429 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.8 >Reporter: Anton Dmitriev >Assignee: Anton Dmitriev >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10428) [ML] Add example for OneVsRest trainer/model usage
[ https://issues.apache.org/jira/browse/IGNITE-10428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-10428: -- Component/s: ml > [ML] Add example for OneVsRest trainer/model usage > -- > > Key: IGNITE-10428 > URL: https://issues.apache.org/jira/browse/IGNITE-10428 > Project: Ignite > Issue Type: Task > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.8 > > > This example should use LogReg or SVM or DT to train multiclass model to > distinguish classes on prepared dataset (generate or use wide-known dataset) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10428) [ML] Add example for OneVsRest trainer/model usage
[ https://issues.apache.org/jira/browse/IGNITE-10428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-10428: -- Issue Type: Task (was: Wish) > [ML] Add example for OneVsRest trainer/model usage > -- > > Key: IGNITE-10428 > URL: https://issues.apache.org/jira/browse/IGNITE-10428 > Project: Ignite > Issue Type: Task >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.8 > > > This example should use LogReg or SVM or DT to train multiclass model to > distinguish classes on prepared dataset (generate or use wide-known dataset) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10428) [ML] Add example for OneVsRest trainer/model usage
Aleksey Zinoviev created IGNITE-10428: - Summary: [ML] Add example for OneVsRest trainer/model usage Key: IGNITE-10428 URL: https://issues.apache.org/jira/browse/IGNITE-10428 Project: Ignite Issue Type: Wish Affects Versions: 2.8 Reporter: Aleksey Zinoviev Assignee: Aleksey Zinoviev Fix For: 2.8 This example should use LogReg or SVM or DT to train multiclass model to distinguish classes on prepared dataset (generate or use wide-known dataset) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7441) Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property
[ https://issues.apache.org/jira/browse/IGNITE-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700610#comment-16700610 ] Ilya Kasnacheev commented on IGNITE-7441: - I seem to have merged this change. Vyacheslav, Denis, thank you for this contribution! > Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property > --- > > Key: IGNITE-7441 > URL: https://issues.apache.org/jira/browse/IGNITE-7441 > Project: Ignite > Issue Type: Task > Components: managed services >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Minor > Fix For: 2.8 > > > IGNITE_SERVICES_COMPATIBILITY_MODE system property was introduced to > configure backward compatibility mode for service configuration classes. But > since it was done in 1.9 and current version is completely incompatible with > it, there is no point in keeping this property. > Moreover, it is ignored after IGNITE-5145. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9902) ScanQuery doesn't take lost partitions into account
[ https://issues.apache.org/jira/browse/IGNITE-9902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700600#comment-16700600 ] Ivan Bessonov commented on IGNITE-9902: --- [~aplatonov] I thought that "assertThrows" will be in a loop, not the opposite. There's also no need in keeping "res" var. Please also pass "log" as a first argument of "assertThrows", just in case. I believe there's no need to get another visa, so after your last changes I'm ready to accept this ticket. Thank you! > ScanQuery doesn't take lost partitions into account > --- > > Key: IGNITE-9902 > URL: https://issues.apache.org/jira/browse/IGNITE-9902 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Assignee: Alexey Platonov >Priority: Major > Time Spent: 8h > Remaining Estimate: 0h > > Same as IGNITE-9841, but about scan queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10427) GridClusterStateProcessor#changeGlobalState0() should wrap future before sending ChangeGlobalStateMessage
[ https://issues.apache.org/jira/browse/IGNITE-10427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700593#comment-16700593 ] ASF GitHub Bot commented on IGNITE-10427: - GitHub user antonovsergey93 opened a pull request: https://github.com/apache/ignite/pull/5513 IGNITE-10427 Wrap state change future before sending activation request. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10427 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5513.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 #5513 commit 2653488c9bc575e5bf1c6212bc796bfe8d7a8098 Author: Sergey Antonov Date: 2018-11-27T15:32:57Z IGNITE-10427 Wrap state change future before sending activation request. > GridClusterStateProcessor#changeGlobalState0() should wrap future before > sending ChangeGlobalStateMessage > - > > Key: IGNITE-10427 > URL: https://issues.apache.org/jira/browse/IGNITE-10427 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9700) Remove configurable values from mesos pom.xml
[ https://issues.apache.org/jira/browse/IGNITE-9700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700589#comment-16700589 ] Ilya Kasnacheev commented on IGNITE-9700: - [~roman_s] Looks good to me! Sorry for the delay. > Remove configurable values from mesos pom.xml > - > > Key: IGNITE-9700 > URL: https://issues.apache.org/jira/browse/IGNITE-9700 > Project: Ignite > Issue Type: Bug >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Minor > Fix For: 2.8 > > > pom.xml contains urls and paths that can be configured when building, but it > introduces git changes with every build. > Need to update the links in the file and remove them from build process, > since the whole process depends on the the links and will not likely be > changed in near future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8542) [ML] Add OneVsRest Trainer to handle cases with multiple class labels in dataset
[ https://issues.apache.org/jira/browse/IGNITE-8542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700588#comment-16700588 ] ASF GitHub Bot commented on IGNITE-8542: GitHub user zaleslaw opened a pull request: https://github.com/apache/ignite/pull/5512 IGNITE-8542: [ML] Add OneVsRest Trainer to handle cases with multiple class labels in dataset You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8542 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5512.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 #5512 commit 5122879095068a4ebaa0def4ffcee2ba29b545f4 Author: zaleslaw Date: 2018-11-22T16:59:42Z IGNITE-8542: Added MultiClassModel commit 171f9c310a51585f224e01dc956a663fdbc0b0b5 Author: Zinoviev Alexey Date: 2018-11-25T14:40:17Z Merge branch 'master' into ignite-8542 commit 018e29e92d867a2f64f938c829ff8179a8644b4e Author: Zinoviev Alexey Date: 2018-11-26T11:52:16Z Merge branch 'master' into ignite-8542 commit cc60887e449cf0f4ecf1f11211945606eae1b39b Author: Zinoviev Alexey Date: 2018-11-27T15:25:41Z IGNITE-8542: Added OneVsRest Trainer/MultiClass model > [ML] Add OneVsRest Trainer to handle cases with multiple class labels in > dataset > > > Key: IGNITE-8542 > URL: https://issues.apache.org/jira/browse/IGNITE-8542 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.8 > > > method extractClassLabels in LogRegressionMultiClassTrainer and in > SVMLinearMultiClassClassificationTrainer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10427) GridClusterStateProcessor#changeGlobalState0() should wrap future before sending ChangeGlobalStateMessage
Sergey Antonov created IGNITE-10427: --- Summary: GridClusterStateProcessor#changeGlobalState0() should wrap future before sending ChangeGlobalStateMessage Key: IGNITE-10427 URL: https://issues.apache.org/jira/browse/IGNITE-10427 Project: Ignite Issue Type: Bug Affects Versions: 2.6 Reporter: Sergey Antonov Assignee: Sergey Antonov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9980) Modify ./control.sh --cache idle_verify --dump print to diff mode (user persistant only/user not-persistent only/system only) cache
[
https://issues.apache.org/jira/browse/IGNITE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700565#comment-16700565
]
Sergey Antonov commented on IGNITE-9980:
[~v.pyatkov] The enum used only for single task ({{VisorIdleVerifyDumpTask}})
and you wrote about it. This enum could confuse developers. I think we must
move enum inside {{VisorIdleVerifyDumpTask}} and make it {{public static enum}}
I left a few new comments in PR. P
> Modify ./control.sh --cache idle_verify --dump print to diff mode (user
> persistant only/user not-persistent only/system only) cache
> ---
>
> Key: IGNITE-9980
> URL: https://issues.apache.org/jira/browse/IGNITE-9980
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: ARomantsov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
>
> It will be cool , if control.sh --cache idle_verify can show
> persistent/not-persistent/system caches and it will be impliments due utility
> flag
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9980) Modify ./control.sh --cache idle_verify --dump print to diff mode (user persistant only/user not-persistent only/system only) cache
[
https://issues.apache.org/jira/browse/IGNITE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700565#comment-16700565
]
Sergey Antonov edited comment on IGNITE-9980 at 11/27/18 3:15 PM:
--
[~v.pyatkov] The enum used only for single task ({{VisorIdleVerifyDumpTask}})
and you wrote about it. This enum could confuse developers. I think we must
move enum inside {{VisorIdleVerifyDumpTask}} and make it {{public static enum}}
Also I left a few new comments in PR.
was (Author: antonovsergey93):
[~v.pyatkov] The enum used only for single task ({{VisorIdleVerifyDumpTask}})
and you wrote about it. This enum could confuse developers. I think we must
move enum inside {{VisorIdleVerifyDumpTask}} and make it {{public static enum}}
I left a few new comments in PR. P
> Modify ./control.sh --cache idle_verify --dump print to diff mode (user
> persistant only/user not-persistent only/system only) cache
> ---
>
> Key: IGNITE-9980
> URL: https://issues.apache.org/jira/browse/IGNITE-9980
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: ARomantsov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
>
> It will be cool , if control.sh --cache idle_verify can show
> persistent/not-persistent/system caches and it will be impliments due utility
> flag
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7153) Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for values > 8kb
[
https://issues.apache.org/jira/browse/IGNITE-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700569#comment-16700569
]
Dmitriy Pavlov commented on IGNITE-7153:
Hi [~mcfongtw] could you please move the issue to Patch Available if you're
sure the fix is ready?
> Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for
> values > 8kb
> ---
>
> Key: IGNITE-7153
> URL: https://issues.apache.org/jira/browse/IGNITE-7153
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.3
> Environment: Win, PHP 7, php_redis-3.1.1-7.0
>Reporter: Alexey Popov
>Assignee: Michael Fong
>Priority: Major
> Labels: redis
>
> Exception:
> {noformat}
> [15:03:23,690][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol]
> Failed to process selector key [ses=GridSelectorNioSessionImpl
> [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=28
> lim=8192 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0,
> bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker
> [name=grid-nio-worker-tcp-rest-0, igniteInstanceName=null, finished=false,
> hashCode=396395638, interrupted=false,
> runner=grid-nio-worker-tcp-rest-0-#36]]], writeBuf=null, readBuf=null,
> inRecovery=null, outRecovery=null, super=GridNioSessionImpl
> [locAddr=/127.0.0.1:6380, rmtAddr=/127.0.0.1:51794, createTime=1512734602674,
> closeTime=0, bytesSent=0, bytesRcvd=8192, bytesSent0=0, bytesRcvd0=8192,
> sndSchedTime=1512734602674, lastSndTime=1512734602674,
> lastRcvTime=1512734602674, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser
> [jdkMarshaller=JdkMarshaller [], routerClient=false], directMode=false]],
> accepted=true]]]
> java.nio.BufferUnderflowException
> at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:150)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:70)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3392)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1096)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2272)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> [15:03:23,691][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol]
> Closing NIO session because of unhandled exception.
> class org.apache.ignite.internal.util.nio.GridNioException: null
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2296)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.BufferUnderflowException
> at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
> at
> org.apache.ignite.internal.processors.rest.pr
[jira] [Commented] (IGNITE-9859) add debug logging on refreshPartitions cause
[ https://issues.apache.org/jira/browse/IGNITE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700564#comment-16700564 ] Dmitriy Pavlov commented on IGNITE-9859: [~mshonichev] could you please confirm this ticket was done by you? If so, could you please follow the patch submission process and create PR, start tests? > add debug logging on refreshPartitions cause > > > Key: IGNITE-9859 > URL: https://issues.apache.org/jira/browse/IGNITE-9859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Major > Fix For: 2.5 > > Attachments: > IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9859) add debug logging on refreshPartitions cause
[ https://issues.apache.org/jira/browse/IGNITE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-9859: --- Ignite Flags: (was: Docs Required) > add debug logging on refreshPartitions cause > > > Key: IGNITE-9859 > URL: https://issues.apache.org/jira/browse/IGNITE-9859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Major > Fix For: 2.5 > > Attachments: > IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9980) Modify ./control.sh --cache idle_verify --dump print to diff mode (user persistant only/user not-persistent only/system only) cache
[
https://issues.apache.org/jira/browse/IGNITE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700548#comment-16700548
]
Vladislav Pyatkov commented on IGNITE-9980:
---
[~antonovsergey93] Thank for your review.
I completed most part of the recommendations and restart TC.
But I have disagree which need to moving enum class to internal of
{{VisorIdleVerifyDumpTask, because that makes calls from other class
inconvenient.}}
> Modify ./control.sh --cache idle_verify --dump print to diff mode (user
> persistant only/user not-persistent only/system only) cache
> ---
>
> Key: IGNITE-9980
> URL: https://issues.apache.org/jira/browse/IGNITE-9980
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: ARomantsov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
>
> It will be cool , if control.sh --cache idle_verify can show
> persistent/not-persistent/system caches and it will be impliments due utility
> flag
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9902) ScanQuery doesn't take lost partitions into account
[ https://issues.apache.org/jira/browse/IGNITE-9902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700536#comment-16700536 ] Alexey Platonov commented on IGNITE-9902: - [~ibessonov], thank you for advice, I didn't know about GridTestUtils#assertThrows with error message checking. I've reformatted code in according to your comment. > ScanQuery doesn't take lost partitions into account > --- > > Key: IGNITE-9902 > URL: https://issues.apache.org/jira/browse/IGNITE-9902 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Assignee: Alexey Platonov >Priority: Major > Time Spent: 8h > Remaining Estimate: 0h > > Same as IGNITE-9841, but about scan queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9902) ScanQuery doesn't take lost partitions into account
[
https://issues.apache.org/jira/browse/IGNITE-9902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700532#comment-16700532
]
Ignite TC Bot commented on IGNITE-9902:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2377693&buildTypeId=IgniteTests24Java8_RunAll]
> ScanQuery doesn't take lost partitions into account
> ---
>
> Key: IGNITE-9902
> URL: https://issues.apache.org/jira/browse/IGNITE-9902
> Project: Ignite
> Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Alexey Platonov
>Priority: Major
> Time Spent: 8h
> Remaining Estimate: 0h
>
> Same as IGNITE-9841, but about scan queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10426) [ML] Spread parameter isKeepRawLabels across all models
Aleksey Zinoviev created IGNITE-10426: - Summary: [ML] Spread parameter isKeepRawLabels across all models Key: IGNITE-10426 URL: https://issues.apache.org/jira/browse/IGNITE-10426 Project: Ignite Issue Type: Improvement Components: ml Affects Versions: 2.8 Reporter: Aleksey Zinoviev Assignee: Aleksey Zinoviev Fix For: 2.8 Currently, a few models has the parameter isKeepRawLabels and threshold to change predicted value to one of class labels 1 or 0. Discuss this in dev-list and think how to solve this task to optimize MultiClassModel Possible solution: * add these methods to common model * add this method to MultiClassModel and use reflection to check this parameter in apply method for example -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9980) Modify ./control.sh --cache idle_verify --dump print to diff mode (user persistant only/user not-persistent only/system only) cache
[ https://issues.apache.org/jira/browse/IGNITE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700519#comment-16700519 ] Vyacheslav Koptilin commented on IGNITE-9980: - Hello [~v.pyatkov] , Please take a look at my comments in the pull-request. > Modify ./control.sh --cache idle_verify --dump print to diff mode (user > persistant only/user not-persistent only/system only) cache > --- > > Key: IGNITE-9980 > URL: https://issues.apache.org/jira/browse/IGNITE-9980 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: ARomantsov >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.8 > > > It will be cool , if control.sh --cache idle_verify can show > persistent/not-persistent/system caches and it will be impliments due utility > flag -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8718) Documentation about using of the C++ BinaryWriter/BinaryReader should be updated
[
https://issues.apache.org/jira/browse/IGNITE-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700507#comment-16700507
]
Igor Sapego commented on IGNITE-8718:
-
[~tledkov-gridgain], there are no articles about BinaryWriter/BinaryReader on
readme.io, so nothing to improve here. But of course, there are always place
for improvement, and I'm planning to improve C++ documentation in future.
> Documentation about using of the C++ BinaryWriter/BinaryReader should be
> updated
>
>
> Key: IGNITE-8718
> URL: https://issues.apache.org/jira/browse/IGNITE-8718
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.5
>Reporter: Andrey Aleksandrov
>Assignee: Igor Sapego
>Priority: Major
> Labels: c++
> Fix For: 2.7
>
>
> The usage that should be documented:
> 1)In case if you get some writer from BinaryWriter then you started writing
> session. Until method close will not be called for this writer you can't get
> another writer.
>
> For example, next code isn't correct:
> {code:java}
> BinaryMapWriter field1Writer = writer.WriteMap int64_t>("field1", MapType::HASH_MAP); //here you start writing session
> BinaryMapWriter field2Writer = writer.WriteMap int64_t>("field2", MapType::HASH_MAP); //here you start another writing
> session - error
> {code}
> Should be:
>
> {code:java}
> BinaryMapWriter field1Writer = writer.WriteMap int64_t>("field1", MapType::HASH_MAP); //here you start writing session
> //do something
> field1Writer.Close() //here you end writing session
> BinaryMapWriter field2Writer = writer.WriteMap int64_t>("field2", MapType::HASH_MAP); //here you start another writing
> session
> //do something
> field2Writer.Close() //here you end another writing session
> {code}
>
> 2) In case if you get some reader from BinaryWriter then you started reading
> session. Until something will not be read from this reader you can't get
> another reader.
>
> For example, next code isn't correct:
>
> {code:java}
> BinaryMapReader field1Reader = reader.ReadMap int64_t>("field1"); //start reading session
> BinaryMapReader field2Reader = reader.ReadMap int64_t>("field2"); //start another read session - error
> {code}
> Should be for example:
> {code:java}
> BinaryMapReader field1Reader = reader.ReadMap int64_t>("field1"); //start reading session
> ...
> field1Reader.GetNext(key, val); //reading done
> ...
> BinaryMapReader field2Reader = reader.ReadMap int64_t>("field2"); //start another read session
> ...
> field2Reader.GetNext(key, val); //reading done
> ...{code}
>
>
>
> In the case of the writer, it looks like expected. In case of the reader, it
> looks a little bit confusing.
>
> These two behaviors should be described in the documentation as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8090) Explain disk space compaction by WAL and compaction techniques
[ https://issues.apache.org/jira/browse/IGNITE-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov reassigned IGNITE-8090: -- Assignee: Prachi Garg (was: Artem Budnikov) > Explain disk space compaction by WAL and compaction techniques > -- > > Key: IGNITE-8090 > URL: https://issues.apache.org/jira/browse/IGNITE-8090 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Major > Fix For: 2.7 > > > Explain how WAL occupies the disk space and how to enable the compaction: > https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStore-underthehood-WALHistorySize > There needs to be a special section in WAL documentation as well as in the > capacity planning. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10425) Node failed to add to topology due to problem with detecting local Address
Max Shonichev created IGNITE-10425:
--
Summary: Node failed to add to topology due to problem with
detecting local Address
Key: IGNITE-10425
URL: https://issues.apache.org/jira/browse/IGNITE-10425
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Max Shonichev
Fix For: 2.8
When localhost has resolvable DNS name to 127.0.0.1, running two nodes on with
"localHost" property set to 127.0.0.1 might result in following exception:
{noformat}
Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to add node
to topology because remote node is configured to use loopback address, but
local node is not (consider changing 'localAddress' configuration parameter)
[locNodeAddrs=[prtagent07.gridgain.local/0:0:0:0:0:0:0:1,
prtagent07.gridgain.local/127.0.0.1, /172.25.2.7,
/2001:0:9d38:6abd:24c2:3fcd:53e6:fdf8], rmtNodeAddrs=[127.0.0.1],
creatorNodeId=28c5fc84-30aa-4d24-a576-ac9a866a4a8b]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:970)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:377)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1955)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
... 15 more
{noformat}
This looks extremely silly, both nodes are started locally and still can't
connect to each other
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10250) Ignite Queue hangs after several read/write operations
[
https://issues.apache.org/jira/browse/IGNITE-10250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-10250:
-
Description:
Ignite Queue hangs after several read/write operations. Code to reproduce:
{code:java}
try (Ignite ignite = Ignition.start()) {
IgniteQueue queue = ignite.queue("TEST_QUEUE", 1, new
CollectionConfiguration());
new Thread(() -> {
for (int i = 0;; i++) {
queue.put(i);
System.out.println("Put: " + i);
}
}).start();
new Thread(() -> {
for (int i = 0;; i++) {
queue.take();
System.out.println("Take: " + i);
}
}).start();
Thread.currentThread().join();
}
{code}
*UPDATE AFTER REVIEW*
[~xtern], thank you for investigating this issue, great job!
Unfortunately this hang has a deeper roots and highlights another bug we have
in continuous queries over atomic caches.
Operations of modifying queue header (which results in invoking of CQ listener
and subsequent call to onHeaderChange callback) are performed on a single key
(*queueKey*, see *GridAtomicCacheQueueImpl*) so even if they are called from
different threads they should remain serialized.
But in case of atomic cache on single node CQ listeners are called
synchronously from the same thread that is making operation on the queue and
they are called outside of section where locks on GridCacheMapEntries objects
are held (see method *GridDhtAtomicCache::updateAllAsyncInternal0* and stack
trace below) which breaks guarantee of serialized invocation of listeners.
So we need to fix this behavior of ATOMIC caches and the issue with queues will
disappear without any changes in *onHeaderChanged* callback.
Stack trace of the call looks like this:
{code:java}
java.lang.Thread.State: RUNNABLE
at
org.apache.ignite.internal.processors.datastructures.GridCacheQueueAdapter.onHeaderChanged(GridCacheQueueAdapter.java:517)
at
org.apache.ignite.internal.processors.cache.datastructures.CacheDataStructuresManager$1.onUpdated(CacheDataStructuresManager.java:305)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyLocalListener(CacheContinuousQueryHandler.java:946)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:877)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$600(CacheContinuousQueryHandler.java:85)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$2$1.apply(CacheContinuousQueryHandler.java:437)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$2$1.apply(CacheContinuousQueryHandler.java:432)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.onDone(GridDhtAtomicAbstractUpdateFuture.java:560)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.onDone(GridDhtAtomicAbstractUpdateFuture.java:62)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:452)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:396)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1874)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1150)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke0(GridDhtAtomicCache.java:831)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke(GridDhtAtomicCache.java:787)
at
org.apache.ignite.internal.processors.datastructures.GridAtomicCacheQueueImpl.transformHeade
[jira] [Updated] (IGNITE-10250) Ignite Queue hangs after several read/write operations
[
https://issues.apache.org/jira/browse/IGNITE-10250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-10250:
-
Description:
Ignite Queue hangs after several read/write operations. Code to reproduce:
{code:java}
try (Ignite ignite = Ignition.start()) {
IgniteQueue queue = ignite.queue("TEST_QUEUE", 1, new
CollectionConfiguration());
new Thread(() -> {
for (int i = 0;; i++) {
queue.put(i);
System.out.println("Put: " + i);
}
}).start();
new Thread(() -> {
for (int i = 0;; i++) {
queue.take();
System.out.println("Take: " + i);
}
}).start();
Thread.currentThread().join();
}
{code}
*UPDATE AFTER REVIEW*
[~xtern], thank you for investigating this issue, great job!
Unfortunately this hang has a deeper roots and highlights another bug we have
in continuous queries over atomic caches.
Operation of modifying queue header (which results in invoking of CQ listener
and subsequent call to onHeaderChange callback) is performed on a single key
(queueKey, see *GridAtomicCacheQueueImpl*) so even if they are called from
different threads they should remain serialized.
But in case of atomic cache on single node CQ listeners are called
synchronously from the same thread that is making operation on the queue.
But more important that they are called outside of section where locks on
GridCacheMapEntries objects are held (see method
*GridDhtAtomicCache::updateAllAsyncInternal0* and stack trace below) which
breaks guarantee of serialized invocation of listeners.
So we need to fix this behavior of ATOMIC caches and the issue with queues will
disappear without any changes in *onHeaderChanged* callback.
Stack trace of the call looks like this:
{code:java}
java.lang.Thread.State: RUNNABLE
at
org.apache.ignite.internal.processors.datastructures.GridCacheQueueAdapter.onHeaderChanged(GridCacheQueueAdapter.java:517)
at
org.apache.ignite.internal.processors.cache.datastructures.CacheDataStructuresManager$1.onUpdated(CacheDataStructuresManager.java:305)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyLocalListener(CacheContinuousQueryHandler.java:946)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:877)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$600(CacheContinuousQueryHandler.java:85)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$2$1.apply(CacheContinuousQueryHandler.java:437)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$2$1.apply(CacheContinuousQueryHandler.java:432)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.onDone(GridDhtAtomicAbstractUpdateFuture.java:560)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.onDone(GridDhtAtomicAbstractUpdateFuture.java:62)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:452)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:396)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1874)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1150)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke0(GridDhtAtomicCache.java:831)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke(GridDhtAtomicCache.java:787)
at
org.apache.ignite.internal.processors.datastructures.GridAtomicCacheQueueI
[jira] [Commented] (IGNITE-9902) ScanQuery doesn't take lost partitions into account
[
https://issues.apache.org/jira/browse/IGNITE-9902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700429#comment-16700429
]
Ignite TC Bot commented on IGNITE-9902:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Inspections] Core{color} [[tests 0 BuildFailureOnMetric
|https://ci.ignite.apache.org/viewLog.html?buildId=2405588]]
{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2405588&buildTypeId=IgniteTests24Java8_InspectionsCore]
> ScanQuery doesn't take lost partitions into account
> ---
>
> Key: IGNITE-9902
> URL: https://issues.apache.org/jira/browse/IGNITE-9902
> Project: Ignite
> Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Alexey Platonov
>Priority: Major
> Time Spent: 8h
> Remaining Estimate: 0h
>
> Same as IGNITE-9841, but about scan queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10418) Implement lightweight profiling of messages processing
[ https://issues.apache.org/jira/browse/IGNITE-10418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700419#comment-16700419 ] ASF GitHub Bot commented on IGNITE-10418: - GitHub user ascherbakoff opened a pull request: https://github.com/apache/ignite/pull/5509 IGNITE-10418 Lightweight profiling. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10418 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5509.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 #5509 commit ba2840cbf77962afa33277f955d686f5fcf9d0ae Author: Aleksei Scherbakov Date: 2018-11-27T12:28:29Z IGNITE-10418 wip. > Implement lightweight profiling of messages processing > -- > > Key: IGNITE-10418 > URL: https://issues.apache.org/jira/browse/IGNITE-10418 > Project: Ignite > Issue Type: New Feature >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10423) Hangs grid-nio-worker-tcp-comm
[
https://issues.apache.org/jira/browse/IGNITE-10423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700422#comment-16700422
]
ASF GitHub Bot commented on IGNITE-10423:
-
GitHub user akalash opened a pull request:
https://github.com/apache/ignite/pull/5510
IGNITE-10423 print dump thread on workersRegistry
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10423
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5510.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 #5510
commit 147d82b22dee3b79d6ecb19198c802fffaf1cf05
Author: Anton Kalashnikov
Date: 2018-11-27T13:31:36Z
IGNITE-10423 print dump thread on workersRegistry
> Hangs grid-nio-worker-tcp-comm
> --
>
> Key: IGNITE-10423
> URL: https://issues.apache.org/jira/browse/IGNITE-10423
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
>
> {noformat}
> [org.apache.ignite:ignite-core] [2018-11-24
> 04:49:34,736][ERROR][tcp-disco-msg-worker-#89615%replicated.GridCacheReplicatedNodeRestartSelfTest2%][G]
> Blocked system-critical thread has be
> en detected. This can lead to cluster-wide undefined behaviour
> [threadName=grid-nio-worker-tcp-comm-1, blockedFor=11s]
> [org.apache.ignite:ignite-core] [2018-11-24 04:49:44,894][WARN
> ][tcp-disco-msg-worker-#89615%replicated.GridCacheReplicatedNodeRestartSelfTest2%][G]
> Thread [name="grid-nio-worker-tcp-com
> m-1-#454082%replicated.GridCacheReplicatedNodeRestartSelfTest2%", id=562184,
> state=RUNNABLE, blockCnt=1, waitCnt=0]
> [org.apache.ignite:ignite-core] [2018-11-24
> 04:49:44,897][ERROR][tcp-disco-msg-worker-#89615%replicated.GridCacheReplicatedNodeRestartSelfTest2%][IgniteTestResources]
> Critical system err
> or detected. Will be handled accordingly to configured handler
> [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=SingletonSet [SYSTEM_WORKER_BLOCKED]]],
> failureCtx=FailureContext [type=S
> YSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker
> [name=grid-nio-worker-tcp-comm-1,
> igniteInstanceName=replicated.GridCacheReplicatedNodeRestartSelfTest2,
> finished=false, heartbeatTs=154303498488
> 9]]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10424) CacheException thrown instead of SqlException
[
https://issues.apache.org/jira/browse/IGNITE-10424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-10424:
---
Summary: CacheException thrown instead of SqlException (was: expected
SqlException not thrown)
> CacheException thrown instead of SqlException
> -
>
> Key: IGNITE-10424
> URL: https://issues.apache.org/jira/browse/IGNITE-10424
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
> Labels: sql
> Fix For: 2.8
>
>
> When running query
> {noformat}
> SELECT SUM(field2*10) FROM tmp_table_age_name_wage;
> {noformat}
> Apache Ignite 2.4 threw SqlException Numeric value out of range:
> "100";
> Apache Ignite 2.5 does not wrap underlying exception and throws
> javax.cache.CacheException instead
> {noformat}
> SELECT SUM(field2*10) FROM tmp_table_age_name_wage;
> Expected error:
> Numeric value out of range
> Actual error:
> Error: javax.cache.CacheException: Failed to execute map query on remote node
> [nodeId=76cea51c-87a3-4054-b39e-1ad6d01c0df6, errMsg=Failed to execute SQL
> query. Numeric value out of range: "100"; SQL statement:
> SELECT
> SUM(__Z0.FIELD2 * 10) __C0_0
> FROM PUBLIC.TMP_TABLE_AGE_NAME_WAGE __Z0 [22003-195]] (state=5,code=0)
> java.sql.SQLException: javax.cache.CacheException: Failed to execute map
> query on remote node [nodeId=76cea51c-87a3-4054-b39e-1ad6d01c0df6,
> errMsg=Failed to execute SQL query. Numeric value out of range:
> "100"; SQL statement:
> SELECT
> SUM(__Z0.FIELD2 * 10) __C0_0
> FROM PUBLIC.TMP_TABLE_AGE_NAME_WAGE __Z0 [22003-195]]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:779)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:210)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:473)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.runCommands(SqlLine.java:1706)
> at sqlline.Commands.run(Commands.java:1317)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.initArgs(SqlLine.java:595)
> at sqlline.SqlLine.begin(SqlLine.java:643)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10424) expected SqlException not thrown
Max Shonichev created IGNITE-10424:
--
Summary: expected SqlException not thrown
Key: IGNITE-10424
URL: https://issues.apache.org/jira/browse/IGNITE-10424
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Max Shonichev
Fix For: 2.8
When running query
{noformat}
SELECT SUM(field2*10) FROM tmp_table_age_name_wage;
{noformat}
Apache Ignite 2.4 threw SqlException Numeric value out of range:
"100";
Apache Ignite 2.5 does not wrap underlying exception and throws
javax.cache.CacheException instead
{noformat}
SELECT SUM(field2*10) FROM tmp_table_age_name_wage;
Expected error:
Numeric value out of range
Actual error:
Error: javax.cache.CacheException: Failed to execute map query on remote node
[nodeId=76cea51c-87a3-4054-b39e-1ad6d01c0df6, errMsg=Failed to execute SQL
query. Numeric value out of range: "100"; SQL statement:
SELECT
SUM(__Z0.FIELD2 * 10) __C0_0
FROM PUBLIC.TMP_TABLE_AGE_NAME_WAGE __Z0 [22003-195]] (state=5,code=0)
java.sql.SQLException: javax.cache.CacheException: Failed to execute map query
on remote node [nodeId=76cea51c-87a3-4054-b39e-1ad6d01c0df6, errMsg=Failed to
execute SQL query. Numeric value out of range: "100"; SQL statement:
SELECT
SUM(__Z0.FIELD2 * 10) __C0_0
FROM PUBLIC.TMP_TABLE_AGE_NAME_WAGE __Z0 [22003-195]]
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:779)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:210)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:473)
at sqlline.Commands.execute(Commands.java:823)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.runCommands(SqlLine.java:1706)
at sqlline.Commands.run(Commands.java:1317)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
at sqlline.SqlLine.dispatch(SqlLine.java:791)
at sqlline.SqlLine.initArgs(SqlLine.java:595)
at sqlline.SqlLine.begin(SqlLine.java:643)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10424) expected SqlException not thrown
[
https://issues.apache.org/jira/browse/IGNITE-10424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-10424:
---
Labels: sql (was: )
> expected SqlException not thrown
>
>
> Key: IGNITE-10424
> URL: https://issues.apache.org/jira/browse/IGNITE-10424
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
> Labels: sql
> Fix For: 2.8
>
>
> When running query
> {noformat}
> SELECT SUM(field2*10) FROM tmp_table_age_name_wage;
> {noformat}
> Apache Ignite 2.4 threw SqlException Numeric value out of range:
> "100";
> Apache Ignite 2.5 does not wrap underlying exception and throws
> javax.cache.CacheException instead
> {noformat}
> SELECT SUM(field2*10) FROM tmp_table_age_name_wage;
> Expected error:
> Numeric value out of range
> Actual error:
> Error: javax.cache.CacheException: Failed to execute map query on remote node
> [nodeId=76cea51c-87a3-4054-b39e-1ad6d01c0df6, errMsg=Failed to execute SQL
> query. Numeric value out of range: "100"; SQL statement:
> SELECT
> SUM(__Z0.FIELD2 * 10) __C0_0
> FROM PUBLIC.TMP_TABLE_AGE_NAME_WAGE __Z0 [22003-195]] (state=5,code=0)
> java.sql.SQLException: javax.cache.CacheException: Failed to execute map
> query on remote node [nodeId=76cea51c-87a3-4054-b39e-1ad6d01c0df6,
> errMsg=Failed to execute SQL query. Numeric value out of range:
> "100"; SQL statement:
> SELECT
> SUM(__Z0.FIELD2 * 10) __C0_0
> FROM PUBLIC.TMP_TABLE_AGE_NAME_WAGE __Z0 [22003-195]]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:779)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:210)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:473)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.runCommands(SqlLine.java:1706)
> at sqlline.Commands.run(Commands.java:1317)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.initArgs(SqlLine.java:595)
> at sqlline.SqlLine.begin(SqlLine.java:643)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10418) Implement lightweight profiling of messages processing
[ https://issues.apache.org/jira/browse/IGNITE-10418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov updated IGNITE-10418: --- Summary: Implement lightweight profiling of messages processing (was: Implement lightweight profiling for message processing) > Implement lightweight profiling of messages processing > -- > > Key: IGNITE-10418 > URL: https://issues.apache.org/jira/browse/IGNITE-10418 > Project: Ignite > Issue Type: New Feature >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8212) Binary Client Protocol spec: Key-Value Queries clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700399#comment-16700399 ] Artem Budnikov commented on IGNITE-8212: [~isapego] I addressed the points mentioned in the description and updated the page. Please review. > Binary Client Protocol spec: Key-Value Queries clarifications > - > > Key: IGNITE-8212 > URL: https://issues.apache.org/jira/browse/IGNITE-8212 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > https://apacheignite.readme.io/v2.4/docs/binary-client-protocol-key-value-operations > - all operations - "Flag. Pass 0 for default, or 1 to keep the value in > binary form": > -- remove words about binary form and keep "Pass 0 for default" for all > operations where this flag has no meaning. > -- clarify about binary form in operations where it has a meaning. > - OP_CACHE_GET: clarify that null is returned if the provided key does not > exist in the cache. > - OP_CACHE_GET_AND_PUT: clarify that new entry is created, if the provided > key does not exist in the cache, and null is returned in this case. > - OP_CACHE_GET_AND_REPLACE: > -- "if and only if there is a value currently mapped for that key" - is > confusing. Is it possible that an existing key has no associated value? > Suggest to rephrase as "if and only if the key exists in the cache" > -- clarify that null is returned if the key does not exist in the cache. > - OP_CACHE_GET_AND_REMOVE: clarify that null is returned if the key does not > exist in the cache. > - OP_CACHE_PUT_IF_ABSENT: clarify what is "Success Flag" - true if the new > entry is created, false if the specified key already exists in the cache. > - OP_CACHE_GET_AND_PUT_IF_ABSENT: "Previously contained value regardless of > whether put happened or not" - is confusing. Suggest to rewrite "the current > value associated with the key if it already exists in the cache, null if the > new entry is created". > - OP_CACHE_GET_SIZE: clarify Peek modes > - OP_CACHE_CLEAR_XXX and OP_CACHE_REMOVE_XXX: > -- what is the difference between the corresponding operations? Only in > notifying / not notifying listeners and cache writers? Or there are other > differences not clarified by the spec? > -- (the operations could be combined in one set - with a flag required/not > required notifications) > -- there is OP_CACHE_REMOVE_IF_EQUALS. But there is no > OP_CACHE_CLEAR_IF_EQUALS. Is it intentional? > -- OP_CACHE_REMOVE_KEY and OP_CACHE_REMOVE_IF_EQUALS have "Value indicating > whether remove happened" in the response. But OP_CACHE_CLEAR_KEY does not > have such a flag in the response. Is it intentional? > -- OP_CACHE_CLEAR_KEYS, OP_CACHE_REMOVE_KEYS: clarify that even if some of > the specified keys do not exist other entries are removed anyway. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8212) Binary Client Protocol spec: Key-Value Queries clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov reassigned IGNITE-8212: -- Assignee: Igor Sapego (was: Artem Budnikov) > Binary Client Protocol spec: Key-Value Queries clarifications > - > > Key: IGNITE-8212 > URL: https://issues.apache.org/jira/browse/IGNITE-8212 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > https://apacheignite.readme.io/v2.4/docs/binary-client-protocol-key-value-operations > - all operations - "Flag. Pass 0 for default, or 1 to keep the value in > binary form": > -- remove words about binary form and keep "Pass 0 for default" for all > operations where this flag has no meaning. > -- clarify about binary form in operations where it has a meaning. > - OP_CACHE_GET: clarify that null is returned if the provided key does not > exist in the cache. > - OP_CACHE_GET_AND_PUT: clarify that new entry is created, if the provided > key does not exist in the cache, and null is returned in this case. > - OP_CACHE_GET_AND_REPLACE: > -- "if and only if there is a value currently mapped for that key" - is > confusing. Is it possible that an existing key has no associated value? > Suggest to rephrase as "if and only if the key exists in the cache" > -- clarify that null is returned if the key does not exist in the cache. > - OP_CACHE_GET_AND_REMOVE: clarify that null is returned if the key does not > exist in the cache. > - OP_CACHE_PUT_IF_ABSENT: clarify what is "Success Flag" - true if the new > entry is created, false if the specified key already exists in the cache. > - OP_CACHE_GET_AND_PUT_IF_ABSENT: "Previously contained value regardless of > whether put happened or not" - is confusing. Suggest to rewrite "the current > value associated with the key if it already exists in the cache, null if the > new entry is created". > - OP_CACHE_GET_SIZE: clarify Peek modes > - OP_CACHE_CLEAR_XXX and OP_CACHE_REMOVE_XXX: > -- what is the difference between the corresponding operations? Only in > notifying / not notifying listeners and cache writers? Or there are other > differences not clarified by the spec? > -- (the operations could be combined in one set - with a flag required/not > required notifications) > -- there is OP_CACHE_REMOVE_IF_EQUALS. But there is no > OP_CACHE_CLEAR_IF_EQUALS. Is it intentional? > -- OP_CACHE_REMOVE_KEY and OP_CACHE_REMOVE_IF_EQUALS have "Value indicating > whether remove happened" in the response. But OP_CACHE_CLEAR_KEY does not > have such a flag in the response. Is it intentional? > -- OP_CACHE_CLEAR_KEYS, OP_CACHE_REMOVE_KEYS: clarify that even if some of > the specified keys do not exist other entries are removed anyway. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10422) Make {{ignite_inspection.xml}} configuration default on the project level
[
https://issues.apache.org/jira/browse/IGNITE-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10422:
-
Ignite Flags: (was: Docs Required)
> Make {{ignite_inspection.xml}} configuration default on the project level
> -
>
> Key: IGNITE-10422
> URL: https://issues.apache.org/jira/browse/IGNITE-10422
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: inspections
>
> IntelliJ IDEA can perform static code analysis by applying _inspections_ to
> the project code. The inspection analysis process can be easily run from both
> the IDE and the command line. The command line usage of IntelliJ IDEA
> inspections already configured as daily [Inspections(Core)
> TeamCity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv]
> suite. This approach has proven its convenience and efficiency as part of
> the _TC.Bot_.
> As for the next step, I propose to improve personal productivity of writing
> code by making *{{ignite_inspection.xml}}* configuration default on the
> project level.
> According to [IntelliJ IDEA
> documentation|https://www.jetbrains.com/help/idea/code-inspection.html], the
> inspection profile is recommended to be placed to
> *{{/.idea/inspectionProfiles}}* with name *{{Project_Default.xml}}*.
> This project profile will be shared and accessible for the team members via
> VCS by default.
> Note.
> The build and test procedure of Apache Ignite project will remain IDE
> independent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10423) Hangs grid-nio-worker-tcp-comm
Anton Kalashnikov created IGNITE-10423:
--
Summary: Hangs grid-nio-worker-tcp-comm
Key: IGNITE-10423
URL: https://issues.apache.org/jira/browse/IGNITE-10423
Project: Ignite
Issue Type: Bug
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov
{noformat}
[org.apache.ignite:ignite-core] [2018-11-24
04:49:34,736][ERROR][tcp-disco-msg-worker-#89615%replicated.GridCacheReplicatedNodeRestartSelfTest2%][G]
Blocked system-critical thread has be
en detected. This can lead to cluster-wide undefined behaviour
[threadName=grid-nio-worker-tcp-comm-1, blockedFor=11s]
[org.apache.ignite:ignite-core] [2018-11-24 04:49:44,894][WARN
][tcp-disco-msg-worker-#89615%replicated.GridCacheReplicatedNodeRestartSelfTest2%][G]
Thread [name="grid-nio-worker-tcp-com
m-1-#454082%replicated.GridCacheReplicatedNodeRestartSelfTest2%", id=562184,
state=RUNNABLE, blockCnt=1, waitCnt=0]
[org.apache.ignite:ignite-core] [2018-11-24
04:49:44,897][ERROR][tcp-disco-msg-worker-#89615%replicated.GridCacheReplicatedNodeRestartSelfTest2%][IgniteTestResources]
Critical system err
or detected. Will be handled accordingly to configured handler
[hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=SingletonSet [SYSTEM_WORKER_BLOCKED]]],
failureCtx=FailureContext [type=S
YSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker
[name=grid-nio-worker-tcp-comm-1,
igniteInstanceName=replicated.GridCacheReplicatedNodeRestartSelfTest2,
finished=false, heartbeatTs=154303498488
9]]]
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10330) Implement disk page compression
[ https://issues.apache.org/jira/browse/IGNITE-10330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700388#comment-16700388 ] Ivan Pavlukhin commented on IGNITE-10330: - [~sergi.vladykin] Could you please add links to IEP and dev-list discussion? > Implement disk page compression > --- > > Key: IGNITE-10330 > URL: https://issues.apache.org/jira/browse/IGNITE-10330 > Project: Ignite > Issue Type: New Feature > Components: cache >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10422) Make {{ignite_inspection.xml}} configuration default on the project level
[
https://issues.apache.org/jira/browse/IGNITE-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10422:
-
Description:
IntelliJ IDEA can perform static code analysis by applying _inspections_ to the
project code. The inspection analysis process can be easily run from both the
IDE and the command line. The command line usage of IntelliJ IDEA inspections
already configured as daily [Inspections(Core)
TeamCity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv]
suite. This approach has proven its convenience and efficiency as part of the
_TC.Bot_.
As for the next step, I propose to improve personal productivity of writing
code by making *{{ignite_inspection.xml}}* configuration default on the project
level.
According to [IntelliJ IDEA
documentation|https://www.jetbrains.com/help/idea/code-inspection.html], the
inspection profile is recommended to be placed to
*{{/.idea/inspectionProfiles}}* with name *{{Project_Default.xml}}*.
This project profile will be shared and accessible for the team members via VCS
by default.
Note.
The build and test procedure of Apache Ignite project will remain IDE
independent.
was:
IntelliJ IDEA can perform static code analysis by applying _inspections_ to the
project code. The inspection analysis process can be easily run from both the
IDE and the command line. The command line usage of IntelliJ IDEA inspections
already configured as daily [Inspections(Core)
TeamCity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv]
suite. This approach has proven its convenience and efficiency as part of the
_TC.Bot_.
As for the next step, I propose to improve personal productivity of writing
code by making *{{ignite_inspection.xml}}* configuration default on the project
level.
According to [IntelliJ IDEA
documentation|https://www.jetbrains.com/help/idea/code-inspection.html], the
inspection profile is recommended to be placed placed to
*{{/.idea/inspectionProfiles}}* with name *{{Project_Default.xml}}*.
This project profile will be shared and accessible for the team members via VCS
by default.
Note.
The build and test procedure of Apache Ignite project will remain IDE
independent.
> Make {{ignite_inspection.xml}} configuration default on the project level
> -
>
> Key: IGNITE-10422
> URL: https://issues.apache.org/jira/browse/IGNITE-10422
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: inspections
>
> IntelliJ IDEA can perform static code analysis by applying _inspections_ to
> the project code. The inspection analysis process can be easily run from both
> the IDE and the command line. The command line usage of IntelliJ IDEA
> inspections already configured as daily [Inspections(Core)
> TeamCity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv]
> suite. This approach has proven its convenience and efficiency as part of
> the _TC.Bot_.
> As for the next step, I propose to improve personal productivity of writing
> code by making *{{ignite_inspection.xml}}* configuration default on the
> project level.
> According to [IntelliJ IDEA
> documentation|https://www.jetbrains.com/help/idea/code-inspection.html], the
> inspection profile is recommended to be placed to
> *{{/.idea/inspectionProfiles}}* with name *{{Project_Default.xml}}*.
> This project profile will be shared and accessible for the team members via
> VCS by default.
> Note.
> The build and test procedure of Apache Ignite project will remain IDE
> independent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10422) Make {{ignite_inspection.xml}} configuration default on the project level
[
https://issues.apache.org/jira/browse/IGNITE-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10422:
-
Description:
IntelliJ IDEA can perform static code analysis by applying _inspections_ to the
project code. The inspection analysis process can be easily run from both the
IDE and the command line. The command line usage of IntelliJ IDEA inspections
already configured as daily [Inspections(Core)
TeamCity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv]
suite. This approach has proven its convenience and efficiency as part of the
_TC.Bot_.
As for the next step, I propose to improve personal productivity of writing
code by making *{{ignite_inspection.xml}}* configuration default on the project
level.
According to [IntelliJ IDEA
documentation|https://www.jetbrains.com/help/idea/code-inspection.html], the
inspection profile is recommended to be placed placed to
*{{/.idea/inspectionProfiles}}* with name *{{Project_Default.xml}}*.
This project profile will be shared and accessible for the team members via VCS
by default.
Note.
The build and test procedure of Apache Ignite project will remain IDE
independent.
was:
IntelliJ IDEA can perform static code analysis by applying _inspections_ to the
project code. The inspection analysis process can be easily run from both the
IDE and the command line. The command line usage of IntelliJ IDEA inspections
already configured as daily [Inspections(Core)
TeamCity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv]
suite. This approach has proven its convenience and efficiency as part of the
_TC.Bot_.
As for the next step, I propose to improve personal productivity of writing
code by making *{{ignite_inspection.xml}}* configuration default on the project
level.
According to [IntelliJ IDEA
documentation|https://www.jetbrains.com/help/idea/code-inspection.html] the
inspection profile should be placed to *{{/.idea/inspectionProfiles}}*
with name *{{Project_Default.xml}}*. This project profile will be shared and
accessible for the team members via VCS by default.
Note.
The build and test procedure of Apache Ignite project will remain IDE
independent.
> Make {{ignite_inspection.xml}} configuration default on the project level
> -
>
> Key: IGNITE-10422
> URL: https://issues.apache.org/jira/browse/IGNITE-10422
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: inspections
>
> IntelliJ IDEA can perform static code analysis by applying _inspections_ to
> the project code. The inspection analysis process can be easily run from both
> the IDE and the command line. The command line usage of IntelliJ IDEA
> inspections already configured as daily [Inspections(Core)
> TeamCity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv]
> suite. This approach has proven its convenience and efficiency as part of
> the _TC.Bot_.
> As for the next step, I propose to improve personal productivity of writing
> code by making *{{ignite_inspection.xml}}* configuration default on the
> project level.
> According to [IntelliJ IDEA
> documentation|https://www.jetbrains.com/help/idea/code-inspection.html], the
> inspection profile is recommended to be placed placed to
> *{{/.idea/inspectionProfiles}}* with name *{{Project_Default.xml}}*.
> This project profile will be shared and accessible for the team members via
> VCS by default.
> Note.
> The build and test procedure of Apache Ignite project will remain IDE
> independent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10422) Make {{ignite_inspection.xml}} configuration default on the project level
[
https://issues.apache.org/jira/browse/IGNITE-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700381#comment-16700381
]
Oleg Ignatenko edited comment on IGNITE-10422 at 11/27/18 1:00 PM:
---
probably worth noting that in (unlikely) case that someone needs to ignore
project default inspections profile or use some other profile instead, Idea
provides means to do so.
Also a while ago this suggestion was discussed at dev list
[here|http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tt27709.html#a33793]
and per my reading there were no objections against proposed change.
was (Author: oignatenko):
probably worth noting that in (unlikely) case that someone needs to ignore
project default inspections profile or use some other profile instead, Idea
provides means to do so
> Make {{ignite_inspection.xml}} configuration default on the project level
> -
>
> Key: IGNITE-10422
> URL: https://issues.apache.org/jira/browse/IGNITE-10422
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: inspections
>
> IntelliJ IDEA can perform static code analysis by applying _inspections_ to
> the project code. The inspection analysis process can be easily run from both
> the IDE and the command line. The command line usage of IntelliJ IDEA
> inspections already configured as daily [Inspections(Core)
> TeamCity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv]
> suite. This approach has proven its convenience and efficiency as part of
> the _TC.Bot_.
> As for the next step, I propose to improve personal productivity of writing
> code by making *{{ignite_inspection.xml}}* configuration default on the
> project level.
> According to [IntelliJ IDEA
> documentation|https://www.jetbrains.com/help/idea/code-inspection.html] the
> inspection profile should be placed to
> *{{/.idea/inspectionProfiles}}* with name *{{Project_Default.xml}}*.
> This project profile will be shared and accessible for the team members via
> VCS by default.
> Note.
> The build and test procedure of Apache Ignite project will remain IDE
> independent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10422) Make {{ignite_inspection.xml}} configuration default on the project level
Maxim Muzafarov created IGNITE-10422:
Summary: Make {{ignite_inspection.xml}} configuration default on
the project level
Key: IGNITE-10422
URL: https://issues.apache.org/jira/browse/IGNITE-10422
Project: Ignite
Issue Type: Task
Reporter: Maxim Muzafarov
IntelliJ IDEA can perform static code analysis by applying _inspections_ to the
project code. The inspection analysis process can be easily run from both the
IDE and the command line. The command line usage of IntelliJ IDEA inspections
already configured as daily [Inspections(Core)
TeamCity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv]
suite. This approach has proven its convenience and efficiency as part of the
_TC.Bot_.
As for the next step, I propose to improve personal productivity of writing
code by making *{{ignite_inspection.xml}}* configuration default on the project
level.
According to [IntelliJ IDEA
documentation|https://www.jetbrains.com/help/idea/code-inspection.html] the
inspection profile should be placed to *{{/.idea/inspectionProfiles}}*
with name *{{Project_Default.xml}}*. This project profile will be shared and
accessible for the team members via VCS by default.
Note.
The build and test procedure of Apache Ignite project will remain IDE
independent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10422) Make {{ignite_inspection.xml}} configuration default on the project level
[
https://issues.apache.org/jira/browse/IGNITE-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700381#comment-16700381
]
Oleg Ignatenko commented on IGNITE-10422:
-
probably worth noting that in (unlikely) case that someone needs to ignore
project default inspections profile or use some other profile instead, Idea
provides means to do so
> Make {{ignite_inspection.xml}} configuration default on the project level
> -
>
> Key: IGNITE-10422
> URL: https://issues.apache.org/jira/browse/IGNITE-10422
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: inspections
>
> IntelliJ IDEA can perform static code analysis by applying _inspections_ to
> the project code. The inspection analysis process can be easily run from both
> the IDE and the command line. The command line usage of IntelliJ IDEA
> inspections already configured as daily [Inspections(Core)
> TeamCity|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv]
> suite. This approach has proven its convenience and efficiency as part of
> the _TC.Bot_.
> As for the next step, I propose to improve personal productivity of writing
> code by making *{{ignite_inspection.xml}}* configuration default on the
> project level.
> According to [IntelliJ IDEA
> documentation|https://www.jetbrains.com/help/idea/code-inspection.html] the
> inspection profile should be placed to
> *{{/.idea/inspectionProfiles}}* with name *{{Project_Default.xml}}*.
> This project profile will be shared and accessible for the team members via
> VCS by default.
> Note.
> The build and test procedure of Apache Ignite project will remain IDE
> independent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9948) JettyRestProcessorAuthenticationWithTokenSelfTest.testGetOrCreateCache fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-9948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700380#comment-16700380
]
Eduard Shangareev edited comment on IGNITE-9948 at 11/27/18 12:55 PM:
--
Looks good. Thank you for the contribution!
was (Author: edshanggg):
Looks good. Thank you for contribution!
> JettyRestProcessorAuthenticationWithTokenSelfTest.testGetOrCreateCache fails
> on TC
> ---
>
> Key: IGNITE-9948
> URL: https://issues.apache.org/jira/browse/IGNITE-9948
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> [Example of
> fail.|https://ci.ignite.apache.org/viewLog.html?buildId=2118632&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_JavaClient#testNameId-4416495803371140089]
> Log details:
> {noformat}
> [2018-10-19 06:59:53,063][ERROR][main][root] Test failed.
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.rest.JettyRestProcessorAbstractSelfTest.checkGetOrCreateAndDestroy(JettyRestProcessorAbstractSelfTest.java:593)
> at
> org.apache.ignite.internal.processors.rest.JettyRestProcessorAbstractSelfTest.testGetOrCreateCache(JettyRestProcessorAbstractSelfTest.java:619)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:142)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2091)
> at java.lang.Thread.run(Thread.java:748){noformat}
> The possible reason is the race between getting cache instance on different
> nodes:
> # Jetty query create cache successfully on one node.
> # PME doesn't have completed.
> # The test fails with NPE while getting the instance of cache on another node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
