[jira] [Updated] (IGNITE-8119) NPE on clear DB and unclear WAL/WAL_ARCHIVE

[Alexander Belyak (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Belyak updated IGNITE-8119:
-
Attachment: ClearTestP.java

> NPE on clear DB and unclear WAL/WAL_ARCHIVE
> ---
>
> Key: IGNITE-8119
> URL: https://issues.apache.org/jira/browse/IGNITE-8119
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Priority: Major
> Attachments: ClearTestP.java
>
>
> 1) Start grid (1 node will be enought), activate it and populate some data
> 2) Stop node and clear db folder
> 3) Start grid and activate it
> Expected result:
> Error about inconsistent storage configuration with/without start node with 
> such store
> Actual result:
> Exchange-worker on node stop with NPE, this can hang whole cluster from 
> complete any PME operations.
> {noformat}
> Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1, 
> minorTopVer=1], ...
> java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyUpdate(GridCacheDatabaseSharedManager.java:2354)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2099)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1325)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1113)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1063)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:661)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2329)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8119) NPE on clear DB and unclear WAL/WAL_ARCHIVE

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-8119:


 Summary: NPE on clear DB and unclear WAL/WAL_ARCHIVE
 Key: IGNITE-8119
 URL: https://issues.apache.org/jira/browse/IGNITE-8119
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.4
Reporter: Alexander Belyak
 Attachments: ClearTestP.java

1) Start grid (1 node will be enought), activate it and populate some data
2) Stop node and clear db folder
3) Start grid and activate it
Expected result:
Error about inconsistent storage configuration with/without start node with 
such store
Actual result:
Exchange-worker on node stop with NPE, this can hang whole cluster from 
complete any PME operations.
{noformat}
Failed to reinitialize local partitions (preloading will be stopped): 
GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1, 
minorTopVer=1], ...
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyUpdate(GridCacheDatabaseSharedManager.java:2354)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2099)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1325)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1113)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1063)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:661)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2329)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-8072) SQL query with multiple JOIN and subquery with UNION produces "Column not found" exception

[Pavel Vinokurov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423393#comment-16423393
 ] 

Pavel Vinokurov edited comment on IGNITE-8072 at 4/3/18 4:43 AM:
-

If the one of caches is replicated, the query work on the 1.9 version. 


was (Author: pvinokurov):
If the one of caches is replicated, the query work on the 1.9.1 version. 

> SQL query with multiple JOIN and subquery with UNION produces "Column not 
> found" exception
> --
>
> Key: IGNITE-8072
> URL: https://issues.apache.org/jira/browse/IGNITE-8072
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1, 2.3, 2.4
>Reporter: Pavel Vinokurov
>Priority: Major
>
> Initial script:
> CREATE TABLE Person(id INTEGER PRIMARY KEY, company_id INTEGER);
> CREATE TABLE Company(id INTEGER PRIMARY KEY, name VARCHAR);
> CREATE TABLE Department(id INTEGER PRIMARY KEY, company_id INTEGER);
> Query:
> select * from 
> (
> select 
>p.id as id,
>p.company_id as company_id 
>from person p 
>union  
> select
>p.id as id,
>p.company_id as company_id 
>from person p 
> ) p
> left join company c on p.company_id=c.id
> left join department d on p.company_id=d.id
> Result:
> SEVERE: Failed to run map query on local node.
> class org.apache.ignite.IgniteCheckedException: Failed to parse SQL query: 
> SELECT
> C__Z3.NAME __C2_0,
> D__Z4.ID __C2_1,
> D__Z4.COMPANY_ID __C2_2,
> C__Z3.ID __C2_3
> FROM PUBLIC.COMPANY C__Z3 
>  LEFT OUTER JOIN PUBLIC.DEPARTMENT D__Z4 
>  ON P__Z2.COMPANY_ID = D__Z4.ID
> ORDER BY 4



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8118) sqlline.bat throws NPE under PowerShell in corner case

[Pavel Konstantinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Konstantinov updated IGNITE-8118:
---
Summary: sqlline.bat throws NPE under PowerShell in corner case  (was: 
sqlline.bat throws NPE under PowerShell)

> sqlline.bat throws NPE under PowerShell in corner case
> --
>
> Key: IGNITE-8118
> URL: https://issues.apache.org/jira/browse/IGNITE-8118
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> {code}
> .\sqlline.bat -u 
> "'jdbc:ignite:thin://18.17.12.22:9652?user=ignite=111'"
> No known driver to handle "'jdbc:ignite:thin://18.17.12.22:9652?user=ignite". 
> Searching for known drivers...
> java.lang.NullPointerException
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8118) sqlline.bat throws NPE under PowerShell

[Pavel Konstantinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Konstantinov updated IGNITE-8118:
---
Fix Version/s: 2.5

> sqlline.bat throws NPE under PowerShell
> ---
>
> Key: IGNITE-8118
> URL: https://issues.apache.org/jira/browse/IGNITE-8118
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> {code}
> .\sqlline.bat -u 
> "'jdbc:ignite:thin://18.17.12.22:9652?user=ignite=111'"
> No known driver to handle "'jdbc:ignite:thin://18.17.12.22:9652?user=ignite". 
> Searching for known drivers...
> java.lang.NullPointerException
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8118) sqlline.bat throws NPE under PowerShell

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8118:
--

 Summary: sqlline.bat throws NPE under PowerShell
 Key: IGNITE-8118
 URL: https://issues.apache.org/jira/browse/IGNITE-8118
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov


{code}
.\sqlline.bat -u 
"'jdbc:ignite:thin://18.17.12.22:9652?user=ignite=111'"
No known driver to handle "'jdbc:ignite:thin://18.17.12.22:9652?user=ignite". 
Searching for known drivers...
java.lang.NullPointerException
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8117) Slow Ignite Cache with multi-nodes

[Rick Lin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick Lin updated IGNITE-8117:
-
Priority: Major  (was: Minor)

> Slow Ignite Cache with multi-nodes
> --
>
> Key: IGNITE-8117
> URL: https://issues.apache.org/jira/browse/IGNITE-8117
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, jdbc
> Environment: OS: Ubuntn 14.04.3 LTS
> JAVA: JDK 1.7
> Ignite: 2.4
>  
>  
>  
>Reporter: Rick Lin
>Priority: Major
> Fix For: 2.4
>
> Attachments: WriteKV.java
>
>
> Dear sir,
> I am running Ignite in my project about  with three nodes:
> {color:#14892c}Three nodes: "ubuntu7","ubuntu8","ubuntu9"{color}
> {color:#14892c}cacheConf.setIndexedTypes(String.class, String.class){color}
> {color:#14892c}cacheConf.setCacheMode(CacheMode.PARTITIONED);{color}
> {color:#14892c}cacheConf.setAtomicityMode(CacheAtomicityMode.ATOMIC);{color}
> When using above setting for
>  * Put,
>  * putAll,
>  * SqlFieldsQuery,
>  * IgniteJdbcThinDriver,
>  * IgniteDataStreamer add
>  * IgniteDataStreamer addAll
> , there are a situation about data latency, and the experiment results are in 
> the following.
> One node(ubuntu7)
> |*milliseconds*|*1,000*|*10,000*|*100,000*|*500,000*|*1,000,000*|
> |*Put*|401|1,108|3,874|12,636|23,561|
> |*putAll*|146|428|2,092|8,940|17,854|
> |*SqlFieldsQuery*|282|943|4,522|20,821|41,223|
> |*IgniteJdbcThinDriver*|491|1,581|8,938|41,429|80,599|
> |*IgniteDataStreamer*
> *Add*|152|439|2,161|7,374|12,296|
> |*IgniteDataStreamer*
> *addAll*|101|234|2,028|5,037|9,181|
>  
> Two nodes(ubuntu7 write and ubuntu8)
> |*milliseconds*|*1,000*|*10,000*|*100,000*|*500,000*|*1,000,000*|
> |*Put*|1,185|5,481|26,142|-|-|
> |*putAll*|107|292|1,785|-|-|
> |*SqlFieldsQuery*|786|3,195|30,528|-|-|
> |*IgniteJdbcThinDriver*|859|3,569|34,080|-|-|
> |*IgniteDataStreamer*
> *add*|169|410|1389|-|-|
> |*IgniteDataStreamer*
> *addAll*|99|206|988|-|-|
>  
> Three nodes(ubuntu7 write, ubuntu8, and ubuntu9)
> |*milliseconds*|*1,000*|*10,000*|*100,000*|*500,000*|*1,000,000*|
> |*Put*|1,664|7,794|41,116|-|-|
> |*putAll*|101|294|1,911|-|-|
> |*SqlFieldsQuery*|1,086|5,718|41,997|-|-|
> |*IgniteJdbcThinDriver*|1,247|4,899|48,566|-|-|
> |*IgniteDataStreamer*
> *add*|168|385|1,364|-|-|
> |*IgniteDataStreamer*
> *addAll*|86|249|905|-|-|
> From above results, these tables show that the three ways: put, 
> SqlFieldsQuery, IgniteJdbcThinDriver have gradually bad performance on data 
> latency  with increasing ignite server nodes, and the other ways: putAll, 
> IgniteDataStreameradd, and IgniteDataStreameraddAll have better performances.
> I don't know if the testing via my java codes are suitable and correct to 
> show these results or not.
> Here, i provide my codes to reproduce my experimental situation.
> {color:#14892c}*Attached is my codes for your reference.*{color}
> if any further information is needed, I am glad to be informed and will 
> provide to you as soon as possible.
> If you have any idea about this issue, I am looking forward to hearing from 
> you.
> Yours sincerely,
> Rick
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-8072) SQL query with multiple JOIN and subquery with UNION produces "Column not found" exception

[Pavel Vinokurov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423393#comment-16423393
 ] 

Pavel Vinokurov edited comment on IGNITE-8072 at 4/3/18 3:43 AM:
-

If the one of caches is replicated, the query work on the 1.9.1 version. 


was (Author: pvinokurov):
If the cache is replicated, the query work on the 1.9.1 version. 

> SQL query with multiple JOIN and subquery with UNION produces "Column not 
> found" exception
> --
>
> Key: IGNITE-8072
> URL: https://issues.apache.org/jira/browse/IGNITE-8072
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1, 2.3, 2.4
>Reporter: Pavel Vinokurov
>Priority: Major
>
> Initial script:
> CREATE TABLE Person(id INTEGER PRIMARY KEY, company_id INTEGER);
> CREATE TABLE Company(id INTEGER PRIMARY KEY, name VARCHAR);
> CREATE TABLE Department(id INTEGER PRIMARY KEY, company_id INTEGER);
> Query:
> select * from 
> (
> select 
>p.id as id,
>p.company_id as company_id 
>from person p 
>union  
> select
>p.id as id,
>p.company_id as company_id 
>from person p 
> ) p
> left join company c on p.company_id=c.id
> left join department d on p.company_id=d.id
> Result:
> SEVERE: Failed to run map query on local node.
> class org.apache.ignite.IgniteCheckedException: Failed to parse SQL query: 
> SELECT
> C__Z3.NAME __C2_0,
> D__Z4.ID __C2_1,
> D__Z4.COMPANY_ID __C2_2,
> C__Z3.ID __C2_3
> FROM PUBLIC.COMPANY C__Z3 
>  LEFT OUTER JOIN PUBLIC.DEPARTMENT D__Z4 
>  ON P__Z2.COMPANY_ID = D__Z4.ID
> ORDER BY 4



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423426#comment-16423426
 ] 

ASF GitHub Bot commented on IGNITE-7944:


GitHub user gromtech opened a pull request:

https://github.com/apache/ignite/pull/3737

IGNITE-7944 Disconnected client node tries to send JOB_CANCEL message

* Skip sending messages if client disconnected.
* Throw IgniteCheckedException if a client node is disconnected and 
communication client is null.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-7944

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3737.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 #3737


commit e043f87b34178d7e010c5e5396382aa557e5486f
Author: Roman Guseinov 
Date:   2018-03-16T02:55:18Z

IGNITE-7944 Disconnected client node tries to send JOB_CANCEL message

* Skip sending message if client disconnected.
* Throw IgniteCheckedException if a client node is disconnected and 
communication client is null.




> Disconnected client node tries to send JOB_CANCEL message
> -
>
> Key: IGNITE-7944
> URL: https://issues.apache.org/jira/browse/IGNITE-7944
> Project: Ignite
>  Issue Type: Bug
>  Components: messaging
>Affects Versions: 1.9, 2.3
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.5
>
> Attachments: Reproducer7944.java
>
>
> In case the network is blocked (socket connections not closed) and failure is 
> detected, tcp-client-disco-msg-worker thread can be stuck in process of 
> TcpClient creating:
> {code:java}
> "tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
> os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - locked <0x7fa140f520c0> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
> - locked <0x7fa140f520b0> (a java.lang.Object)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
> at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It looks like msg-worker is trying to send JOB_CANCEL message for each job 
> with timeout equals failureDetectionTimeout.
> Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8117) Slow Ignite Cache with multi-nodes

[Rick Lin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick Lin updated IGNITE-8117:
-
Component/s: jdbc

> Slow Ignite Cache with multi-nodes
> --
>
> Key: IGNITE-8117
> URL: https://issues.apache.org/jira/browse/IGNITE-8117
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, jdbc
> Environment: OS: Ubuntn 14.04.3 LTS
> JAVA: JDK 1.7
> Ignite: 2.4
>  
>  
>  
>Reporter: Rick Lin
>Priority: Minor
> Fix For: 2.4
>
> Attachments: WriteKV.java
>
>
> Dear sir,
> I am running Ignite in my project about  with three nodes:
> {color:#14892c}Three nodes: "ubuntu7","ubuntu8","ubuntu9"{color}
> {color:#14892c}cacheConf.setIndexedTypes(String.class, String.class){color}
> {color:#14892c}cacheConf.setCacheMode(CacheMode.PARTITIONED);{color}
> {color:#14892c}cacheConf.setAtomicityMode(CacheAtomicityMode.ATOMIC);{color}
> When using above setting for
>  * Put,
>  * putAll,
>  * SqlFieldsQuery,
>  * IgniteJdbcThinDriver,
>  * IgniteDataStreamer add
>  * IgniteDataStreamer addAll
> , there are a situation about data latency, and the experiment results are in 
> the following.
> One node(ubuntu7)
> |*milliseconds*|*1,000*|*10,000*|*100,000*|*500,000*|*1,000,000*|
> |*Put*|401|1,108|3,874|12,636|23,561|
> |*putAll*|146|428|2,092|8,940|17,854|
> |*SqlFieldsQuery*|282|943|4,522|20,821|41,223|
> |*IgniteJdbcThinDriver*|491|1,581|8,938|41,429|80,599|
> |*IgniteDataStreamer*
> *Add*|152|439|2,161|7,374|12,296|
> |*IgniteDataStreamer*
> *addAll*|101|234|2,028|5,037|9,181|
>  
> Two nodes(ubuntu7 write and ubuntu8)
> |*milliseconds*|*1,000*|*10,000*|*100,000*|*500,000*|*1,000,000*|
> |*Put*|1,185|5,481|26,142|-|-|
> |*putAll*|107|292|1,785|-|-|
> |*SqlFieldsQuery*|786|3,195|30,528|-|-|
> |*IgniteJdbcThinDriver*|859|3,569|34,080|-|-|
> |*IgniteDataStreamer*
> *add*|169|410|1389|-|-|
> |*IgniteDataStreamer*
> *addAll*|99|206|988|-|-|
>  
> Three nodes(ubuntu7 write, ubuntu8, and ubuntu9)
> |*milliseconds*|*1,000*|*10,000*|*100,000*|*500,000*|*1,000,000*|
> |*Put*|1,664|7,794|41,116|-|-|
> |*putAll*|101|294|1,911|-|-|
> |*SqlFieldsQuery*|1,086|5,718|41,997|-|-|
> |*IgniteJdbcThinDriver*|1,247|4,899|48,566|-|-|
> |*IgniteDataStreamer*
> *add*|168|385|1,364|-|-|
> |*IgniteDataStreamer*
> *addAll*|86|249|905|-|-|
> From above results, these tables show that the three ways: put, 
> SqlFieldsQuery, IgniteJdbcThinDriver have gradually bad performance on data 
> latency  with increasing ignite server nodes, and the other ways: putAll, 
> IgniteDataStreameradd, and IgniteDataStreameraddAll have better performances.
> I don't know if the testing via my java codes are suitable and correct to 
> show these results or not.
> Here, i provide my codes to reproduce my experimental situation.
> {color:#14892c}*Attached is my codes for your reference.*{color}
> if any further information is needed, I am glad to be informed and will 
> provide to you as soon as possible.
> If you have any idea about this issue, I am looking forward to hearing from 
> you.
> Yours sincerely,
> Rick
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8117) Slow Ignite Cache with multi-nodes

[Rick Lin (JIRA)]

Rick Lin created IGNITE-8117:


 Summary: Slow Ignite Cache with multi-nodes
 Key: IGNITE-8117
 URL: https://issues.apache.org/jira/browse/IGNITE-8117
 Project: Ignite
  Issue Type: Improvement
  Components: cache
 Environment: OS: Ubuntn 14.04.3 LTS

JAVA: JDK 1.7

Ignite: 2.4

 

 

 
Reporter: Rick Lin
 Fix For: 2.4
 Attachments: WriteKV.java

Dear sir,

I am running Ignite in my project about  with three nodes:

{color:#14892c}Three nodes: "ubuntu7","ubuntu8","ubuntu9"{color}

{color:#14892c}cacheConf.setIndexedTypes(String.class, String.class){color}

{color:#14892c}cacheConf.setCacheMode(CacheMode.PARTITIONED);{color}

{color:#14892c}cacheConf.setAtomicityMode(CacheAtomicityMode.ATOMIC);{color}

When using above setting for
 * Put,
 * putAll,
 * SqlFieldsQuery,
 * IgniteJdbcThinDriver,
 * IgniteDataStreamer add
 * IgniteDataStreamer addAll

, there are a situation about data latency, and the experiment results are in 
the following.

One node(ubuntu7)
|*milliseconds*|*1,000*|*10,000*|*100,000*|*500,000*|*1,000,000*|
|*Put*|401|1,108|3,874|12,636|23,561|
|*putAll*|146|428|2,092|8,940|17,854|
|*SqlFieldsQuery*|282|943|4,522|20,821|41,223|
|*IgniteJdbcThinDriver*|491|1,581|8,938|41,429|80,599|
|*IgniteDataStreamer*
*Add*|152|439|2,161|7,374|12,296|
|*IgniteDataStreamer*
*addAll*|101|234|2,028|5,037|9,181|

 

Two nodes(ubuntu7 write and ubuntu8)
|*milliseconds*|*1,000*|*10,000*|*100,000*|*500,000*|*1,000,000*|
|*Put*|1,185|5,481|26,142|-|-|
|*putAll*|107|292|1,785|-|-|
|*SqlFieldsQuery*|786|3,195|30,528|-|-|
|*IgniteJdbcThinDriver*|859|3,569|34,080|-|-|
|*IgniteDataStreamer*
*add*|169|410|1389|-|-|
|*IgniteDataStreamer*
*addAll*|99|206|988|-|-|

 

Three nodes(ubuntu7 write, ubuntu8, and ubuntu9)
|*milliseconds*|*1,000*|*10,000*|*100,000*|*500,000*|*1,000,000*|
|*Put*|1,664|7,794|41,116|-|-|
|*putAll*|101|294|1,911|-|-|
|*SqlFieldsQuery*|1,086|5,718|41,997|-|-|
|*IgniteJdbcThinDriver*|1,247|4,899|48,566|-|-|
|*IgniteDataStreamer*
*add*|168|385|1,364|-|-|
|*IgniteDataStreamer*
*addAll*|86|249|905|-|-|

>From above results, these tables show that the three ways: put, 
>SqlFieldsQuery, IgniteJdbcThinDriver have gradually bad performance on data 
>latency  with increasing ignite server nodes, and the other ways: putAll, 
>IgniteDataStreameradd, and IgniteDataStreameraddAll have better performances.

I don't know if the testing via my java codes are suitable and correct to show 
these results or not.

Here, i provide my codes to reproduce my experimental situation.

{color:#14892c}*Attached is my codes for your reference.*{color}

if any further information is needed, I am glad to be informed and will provide 
to you as soon as possible.

If you have any idea about this issue, I am looking forward to hearing from you.

Yours sincerely,

Rick

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8072) SQL query with multiple JOIN and subquery with UNION produces "Column not found" exception

[Pavel Vinokurov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423393#comment-16423393
 ] 

Pavel Vinokurov commented on IGNITE-8072:
-

If the cache is replicated, the query work on the 1.9.1 version. 

> SQL query with multiple JOIN and subquery with UNION produces "Column not 
> found" exception
> --
>
> Key: IGNITE-8072
> URL: https://issues.apache.org/jira/browse/IGNITE-8072
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1, 2.3, 2.4
>Reporter: Pavel Vinokurov
>Priority: Major
>
> Initial script:
> CREATE TABLE Person(id INTEGER PRIMARY KEY, company_id INTEGER);
> CREATE TABLE Company(id INTEGER PRIMARY KEY, name VARCHAR);
> CREATE TABLE Department(id INTEGER PRIMARY KEY, company_id INTEGER);
> Query:
> select * from 
> (
> select 
>p.id as id,
>p.company_id as company_id 
>from person p 
>union  
> select
>p.id as id,
>p.company_id as company_id 
>from person p 
> ) p
> left join company c on p.company_id=c.id
> left join department d on p.company_id=d.id
> Result:
> SEVERE: Failed to run map query on local node.
> class org.apache.ignite.IgniteCheckedException: Failed to parse SQL query: 
> SELECT
> C__Z3.NAME __C2_0,
> D__Z4.ID __C2_1,
> D__Z4.COMPANY_ID __C2_2,
> C__Z3.ID __C2_3
> FROM PUBLIC.COMPANY C__Z3 
>  LEFT OUTER JOIN PUBLIC.DEPARTMENT D__Z4 
>  ON P__Z2.COMPANY_ID = D__Z4.ID
> ORDER BY 4



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8099) Web console: wrong editing behavior in case of incorrect field value

[Pavel Konstantinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Konstantinov updated IGNITE-8099:
---
Fix Version/s: 2.5

> Web console: wrong editing behavior in case of incorrect field value
> 
>
> Key: IGNITE-8099
> URL: https://issues.apache.org/jira/browse/IGNITE-8099
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.5
>
>
> For reproduce just try to edit 'Key Type' field of Model



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[Roman Guseinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Guseinov updated IGNITE-7944:
---
Component/s: messaging

> Disconnected client node tries to send JOB_CANCEL message
> -
>
> Key: IGNITE-7944
> URL: https://issues.apache.org/jira/browse/IGNITE-7944
> Project: Ignite
>  Issue Type: Bug
>  Components: messaging
>Affects Versions: 1.9, 2.3
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.5
>
> Attachments: Reproducer7944.java
>
>
> In case the network is blocked (socket connections not closed) and failure is 
> detected, tcp-client-disco-msg-worker thread can be stuck in process of 
> TcpClient creating:
> {code:java}
> "tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
> os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - locked <0x7fa140f520c0> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
> - locked <0x7fa140f520b0> (a java.lang.Object)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
> at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It looks like msg-worker is trying to send JOB_CANCEL message for each job 
> with timeout equals failureDetectionTimeout.
> Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[Roman Guseinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Guseinov updated IGNITE-7944:
---
Fix Version/s: 2.5

> Disconnected client node tries to send JOB_CANCEL message
> -
>
> Key: IGNITE-7944
> URL: https://issues.apache.org/jira/browse/IGNITE-7944
> Project: Ignite
>  Issue Type: Bug
>  Components: messaging
>Affects Versions: 1.9, 2.3
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.5
>
> Attachments: Reproducer7944.java
>
>
> In case the network is blocked (socket connections not closed) and failure is 
> detected, tcp-client-disco-msg-worker thread can be stuck in process of 
> TcpClient creating:
> {code:java}
> "tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
> os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - locked <0x7fa140f520c0> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
> - locked <0x7fa140f520b0> (a java.lang.Object)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
> at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It looks like msg-worker is trying to send JOB_CANCEL message for each job 
> with timeout equals failureDetectionTimeout.
> Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7931) Wrong arguments for ConcurrentHashMap

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422999#comment-16422999
 ] 

ASF GitHub Bot commented on IGNITE-7931:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3646


>  Wrong arguments for ConcurrentHashMap
> --
>
> Key: IGNITE-7931
> URL: https://issues.apache.org/jira/browse/IGNITE-7931
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Trivial
> Fix For: 2.5
>
>
> When creating ConcurrentHashMap:
> {code:java|title=BinaryUtils.java}
> new ConcurrentHashMap<>(U.capacity((map).size()));{code}
> [1], [2] `U.capacity` returns capacity that is sufficient to keep the map 
> from being resized. In ConcurrentHashMap this is unnecessary because 
> recalculation already performs in the constructor.
>  Similar problem in GridConcurrentHashSet because inside it implements 
> ConcurrentHashMap:
> {code:java|title=DataStreamerImpl.java}
> keys = new GridConcurrentHashSet<>(entries.size(), 
> U.capacity(entries.size()), 1);{code}
> [3],[4] result of `U.capacity` is passed as `loadFactor` value. When 
> loadFactor == U.capacity, initial size of table is 1. 
>  This leads to performance penalty due to rehashing of internal map.
>  
> [1][https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L670]
> [2][https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L688|https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L670]
> [3][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L633]
> [4][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L574]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (IGNITE-6168) Ability to use TLS client authentication in the TcpDiscoverySpi

[Jens Borgland (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Borgland closed IGNITE-6168.
-

Seems to be working as expected. Thank you for the swift resolution!

> Ability to use TLS client authentication in the TcpDiscoverySpi
> ---
>
> Key: IGNITE-6168
> URL: https://issues.apache.org/jira/browse/IGNITE-6168
> Project: Ignite
>  Issue Type: Wish
>Affects Versions: 2.1
>Reporter: Jens Borgland
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.3
>
>
> I'm working on an application where we use mutual TLS to protect the 
> communication (of different kinds) between the components. It seems like 
> Ignite uses mutual TLS for the TcpCommunicationSpi but not for the 
> TcpDiscoverySpi. Would it be possible to add this ability (one way could 
> perhaps be by implementing IGNITE-6167 so that it can be done through a 
> custom socket factory)?
> I'm aware that there are other client authentication options for the 
> discovery SPI but it would be nice to be able to use the same mechanism 
> everywhere.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7931) Wrong arguments for ConcurrentHashMap

[Nikolay Izhikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422978#comment-16422978
 ] 

Nikolay Izhikov commented on IGNITE-7931:
-

TeamCity - 
https://ci.ignite.apache.org/viewLog.html?buildId=1172948=buildResultsDiv=IgniteTests24Java8_RunAll

>  Wrong arguments for ConcurrentHashMap
> --
>
> Key: IGNITE-7931
> URL: https://issues.apache.org/jira/browse/IGNITE-7931
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Trivial
> Fix For: 2.5
>
>
> When creating ConcurrentHashMap:
> {code:java|title=BinaryUtils.java}
> new ConcurrentHashMap<>(U.capacity((map).size()));{code}
> [1], [2] `U.capacity` returns capacity that is sufficient to keep the map 
> from being resized. In ConcurrentHashMap this is unnecessary because 
> recalculation already performs in the constructor.
>  Similar problem in GridConcurrentHashSet because inside it implements 
> ConcurrentHashMap:
> {code:java|title=DataStreamerImpl.java}
> keys = new GridConcurrentHashSet<>(entries.size(), 
> U.capacity(entries.size()), 1);{code}
> [3],[4] result of `U.capacity` is passed as `loadFactor` value. When 
> loadFactor == U.capacity, initial size of table is 1. 
>  This leads to performance penalty due to rehashing of internal map.
>  
> [1][https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L670]
> [2][https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L688|https://github.com/1vanan/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L670]
> [3][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L633]
> [4][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L574]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8116) Historic WAL rebalance fails

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-8116:
-

 Summary: Historic WAL rebalance fails
 Key: IGNITE-8116
 URL: https://issues.apache.org/jira/browse/IGNITE-8116
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Reporter: Eduard Shangareev
 Fix For: 2.5


So, my reproducer fails because rebalance is never completed. 

Rebalance fails with next error:
{code}
Exception in thread "sys-#95%wal.IgniteWalRebalanceTest0%" 
java.lang.AssertionError
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:390)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:364)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:372)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:357)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1603)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2752)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1516)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$10.run(GridIoManager.java:1485)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}

Reproducer:

{code}
/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.apache.ignite.internal.processors.cache.persistence.db.wal;

import java.util.concurrent.TimeUnit;
import org.apache.ignite.IgniteCache;
import org.apache.ignite.cache.CacheAtomicityMode;
import org.apache.ignite.cache.CacheMode;
import org.apache.ignite.cache.CacheRebalanceMode;
import org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction;
import org.apache.ignite.cache.query.annotations.QuerySqlField;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.DataRegionConfiguration;
import org.apache.ignite.configuration.DataStorageConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.configuration.WALMode;
import org.apache.ignite.internal.IgniteEx;
import org.apache.ignite.internal.util.typedef.internal.S;
import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;

import static 
org.apache.ignite.IgniteSystemProperties.IGNITE_PDS_WAL_REBALANCE_THRESHOLD;

/**
 * Historic WAL rebalance test
 */
public class IgniteWalRebalanceTest extends GridCommonAbstractTest {
/** Cache name. */
private static final String CACHE_NAME = "cache";

/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String gridName) 
throws Exception {
System.setProperty(IGNITE_PDS_WAL_REBALANCE_THRESHOLD, "0"); //to make 
all rebalance wal-based

IgniteConfiguration cfg = super.getConfiguration(gridName);

CacheConfiguration ccfg = new 

[jira] [Commented] (IGNITE-8071) Add tests for failure handlers

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422943#comment-16422943
 ] 

Andrey Gura commented on IGNITE-8071:
-

Please, see my comments in Upsource.

> Add tests for failure handlers
> --
>
> Key: IGNITE-8071
> URL: https://issues.apache.org/jira/browse/IGNITE-8071
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Dmitriy Sorokin
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> Different failure handlers were implemented due to IEP-14 (IGNITE-6890). 
> Tests should be added for this implementations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7481) Suspended transaction rollbacs incorrectly

[Nikolay Izhikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422939#comment-16422939
 ] 

Nikolay Izhikov commented on IGNITE-7481:
-

[~Alexey Kuznetsov] I don't like current implementation.

We have to fix the described issue as is.
>From my point of view, the root of the problem is next: Transaction doesn't 
>get resumed on timeout.
To fix a metric issue and all other possible issues we have to {{resume}} 
suspended transaction prior to other timeout actions.

Thoughts?

> Suspended transaction rollbacs incorrectly  
> 
>
> Key: IGNITE-7481
> URL: https://issues.apache.org/jira/browse/IGNITE-7481
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> When we suspend transaction, and then timeout occures , transaction would be 
> rollbacked incorrectly.
> One of incorrect behaviors : rollback\end tx metrics are not incremented.
> Thre reason is that transactionMap is cleared when we suspend transaction.
> We need not clear transactionMap.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8102) IgnitePdsCorruptedStoreTest.testNodeInvalidatedWhenPersistenceIsCorrupted failed in Direct IO 2 suite

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-8102:
---
Priority: Critical  (was: Major)

> IgnitePdsCorruptedStoreTest.testNodeInvalidatedWhenPersistenceIsCorrupted 
> failed in Direct IO 2 suite
> -
>
> Key: IGNITE-8102
> URL: https://issues.apache.org/jira/browse/IGNITE-8102
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
>PDS (Direct IO) [2] [ tests 1 ] 
>   IgnitePdsNativeIoTestSuite2: 
> IgnitePdsCorruptedStoreTest.testNodeInvalidatedWhenPersistenceIsCorrupted 
> (master fail rate 6,8%)  
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7830903222674504151=pull%2F3624%2Fhead=testDetails_IgniteTests24Java8=%3Cdefault%3E
> Failure contains suspicious error:
> {noformat}
> [2018-04-01 
> 15:35:51,704][ERROR][exchange-worker-#25589%persistence.IgnitePdsCorruptedStoreTest0%][IgniteTestResources]
>  Critical failure. Will be handled accordingly to configured handler 
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
> [type=CRITICAL_ERROR, err=java.lang.IllegalStateException: Page is broken. 
> Can't restore it from WAL. (grpId = -1368047377, pageId = 100020008).]] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8102) IgnitePdsCorruptedStoreTest.testNodeInvalidatedWhenPersistenceIsCorrupted failed in Direct IO 2 suite

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422897#comment-16422897
 ] 

Dmitriy Pavlov commented on IGNITE-8102:


Occurred outside Direct IO
https://ci.ignite.apache.org/viewLog.html?buildId=1171450

{noformat}
[2018-04-01 
21:31:09,165][ERROR][exchange-worker-#25355%persistence.IgnitePdsCorruptedStoreTest0%][IgniteTestResources]
 Critical failure. Will be handled accordingly to configured handler [hnd=class 
o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
[type=CRITICAL_ERROR, err=java.lang.IllegalStateException: Page is broken. 
Can't restore it from WAL. (grpId = -1368047377, pageId = 100020008).]] 
{noformat}

> IgnitePdsCorruptedStoreTest.testNodeInvalidatedWhenPersistenceIsCorrupted 
> failed in Direct IO 2 suite
> -
>
> Key: IGNITE-8102
> URL: https://issues.apache.org/jira/browse/IGNITE-8102
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>PDS (Direct IO) [2] [ tests 1 ] 
>   IgnitePdsNativeIoTestSuite2: 
> IgnitePdsCorruptedStoreTest.testNodeInvalidatedWhenPersistenceIsCorrupted 
> (master fail rate 6,8%)  
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7830903222674504151=pull%2F3624%2Fhead=testDetails_IgniteTests24Java8=%3Cdefault%3E
> Failure contains suspicious error:
> {noformat}
> [2018-04-01 
> 15:35:51,704][ERROR][exchange-worker-#25589%persistence.IgnitePdsCorruptedStoreTest0%][IgniteTestResources]
>  Critical failure. Will be handled accordingly to configured handler 
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
> [type=CRITICAL_ERROR, err=java.lang.IllegalStateException: Page is broken. 
> Can't restore it from WAL. (grpId = -1368047377, pageId = 100020008).]] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8078) Add new metrics for data storage

[Dmitriy Govorukhin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Govorukhin updated IGNITE-8078:
---
Description: 
1. Create new MXbean for each index, IndexMxBean
{code}
class IndexMxBean{
/** The number of PUT operations on the index. */
long getProcessedPuts();
/** The number of GET operations on the index. */
long getProcessedGets();
/** The total index size in bytes. */
long getIndexSize();
/** Index name.*/
String getName();
}
{code}

2. Add new metrics for data storage and cache group.
{code}
class CacheGroupMetricsMXBean{
/** The total index size in bytes */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes for reuse list.*/
long getReuseListSize();
/** Total size in bytes. */
long getTotalSize();
/** Total size in bytes for pure data.*/
long getDataSize();
/** CacheGroup type. PARTITIONED, REPLICATED, LOCAL.*/
String getType();
/** Partitions currently assigned to the local node in this cache group. */
int[] getPartitions();
}
{code}

{code}
class DataRegionMXBean{
/** Total size in bytes for indexes. */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes. */
long getTotalSize();
/** Total size in bytes for pure data.*/
long getDataSize();
/** Total size in bytes for pure data.*/
long getDataPagesSize();
/** Total used offheap size in bytes. */
long getOffheapUsedSize();
/** The number of read pages from last restart. */
long getPagesRead();
/** The number of writen pages from last restart. */
long getPagesWriten();
/** The number of replaced pages from last restart . */
long getPagesReplaced();
/** Total dirty pages for the next checkpoint. */
long getDirtyPagesForNextCheckpoint();
}
{code}

{code}
class DataStorageMXbean{
/** Total size in bytes for indexes. */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes for all storages. */
long getTotalSize();
/** Total offheap size in bytes. */
long getOffHeapSize();
/** Total used offheap size in bytes for all data regions. */
long getOffheapUsedSize();
/** Total size in bytes for pure data.*/
long getDataSize();
/** The number of read pages from last restart. */
long getPagesRead();
/** The number of writen pages from last restart. */
long getPagesWriten();
/** The number of replaced pages from last restart. */
long getPagesReplaced();
/** Total checkpoint time from last restart. */
long getCheckpointTotalTime();
/** Total dirty pages for the next checkpoint. */
long getDirtyPagesForNextCheckpoint();
/** Total size in bytes for storage wal files. */
long getWalTotalSize();
/** Time of the last WAL segment rollover. */
long getWalLastSwitchTime();
}
{code}

{code}
class IgniteMxBean {
/** Returns string containing Node ID, Consistent ID, Node Order */
String getCurrentCoordinator();
}
{code}

Depricate CacheMetrics.getRebalancingPartitionsCount(); and move to 
CacheGroupMetricsMXBean.getRebalancingPartitionsCount();

  was:
1. Create new MXbean for each index, IndexMxBean
{code}
class IndexMxBean{
/** The number of PUT operations on the index. */
long getProcessedPuts();
/** The number of GET operations on the index. */
long getProcessedGets();
/** The total index size in bytes. */
long getIndexSize();
/** Index name.*/
String getName();
}
{code}

2. Add new metrics for data storage and cache group.
{code}
class CacheGroupMetricsMXBean{
/** The total index size in bytes */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes for reuse list.*/
long getReuseListSize();
/** Total size in bytes. */
long getTotalSize();
/** Total size in bytes for pure data.*/
long getDataSize();
/** CacheGroup type. PARTITIONED, REPLICATED, LOCAL.*/
String getType();
/** Partitions currently assigned to the local node in this cache group. */
int[] getPartitions();
}
{code}

{code}
class DataRegionMXBean{
/** Total size in bytes for indexes. */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes. */
long getTotalSize();
/** Total size in bytes for pure data.*/
long getDataSize();
/** Total used offheap size in bytes. */
long getOffheapUsedSize();
/** The number of read pages from last restart. */
long getPagesRead();
/** The number of writen pages from last restart. */
long getPagesWriten();
/** The number of replaced pages from last restart . */
long getPagesReplaced();
/** Total dirty pages for the next checkpoint. */
long getDirtyPagesForNextCheckpoint();
}
{code}

{code}
class DataStorageMXbean{
/** Total size in bytes for indexes. */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes for all storages. */
long getTotalSize();
/** 

[jira] [Updated] (IGNITE-8078) Add new metrics for data storage

[Dmitriy Govorukhin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Govorukhin updated IGNITE-8078:
---
Description: 
1. Create new MXbean for each index, IndexMxBean
{code}
class IndexMxBean{
/** The number of PUT operations on the index. */
long getProcessedPuts();
/** The number of GET operations on the index. */
long getProcessedGets();
/** The total index size in bytes. */
long getIndexSize();
/** Index name.*/
String getName();
}
{code}

2. Add new metrics for data storage and cache group.
{code}
class CacheGroupMetricsMXBean{
/** The total index size in bytes */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes for reuse list.*/
long getReuseListSize();
/** Total size in bytes. */
long getTotalSize();
/** Total size in bytes for pure data.*/
long getDataSize();
/** Total size in bytes for data pages.*/
long getDataPagesSize();
/** CacheGroup type. PARTITIONED, REPLICATED, LOCAL.*/
String getType();
/** Partitions currently assigned to the local node in this cache group. */
int[] getPartitions();
}
{code}

{code}
class DataRegionMXBean{
/** Total size in bytes for indexes. */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes. */
long getTotalSize();
/** Total size in bytes for pure data.*/
long getDataSize();
/** Total size in bytes for data pages.*/
long getDataPagesSize();
/** Total used offheap size in bytes. */
long getOffheapUsedSize();
/** The number of read pages from last restart. */
long getPagesRead();
/** The number of writen pages from last restart. */
long getPagesWriten();
/** The number of replaced pages from last restart . */
long getPagesReplaced();
/** Total dirty pages for the next checkpoint. */
long getDirtyPagesForNextCheckpoint();
}
{code}

{code}
class DataStorageMXbean{
/** Total size in bytes for indexes. */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes for all storages. */
long getTotalSize();
/** Total offheap size in bytes. */
long getOffHeapSize();
/** Total used offheap size in bytes for all data regions. */
long getOffheapUsedSize();
/** Total size in bytes for pure data.*/
long getDataSize();
/** The number of read pages from last restart. */
long getPagesRead();
/** The number of writen pages from last restart. */
long getPagesWriten();
/** The number of replaced pages from last restart. */
long getPagesReplaced();
/** Total checkpoint time from last restart. */
long getCheckpointTotalTime();
/** Total dirty pages for the next checkpoint. */
long getDirtyPagesForNextCheckpoint();
/** Total size in bytes for storage wal files. */
long getWalTotalSize();
/** Time of the last WAL segment rollover. */
long getWalLastSwitchTime();
}
{code}

{code}
class IgniteMxBean {
/** Returns string containing Node ID, Consistent ID, Node Order */
String getCurrentCoordinator();
}
{code}

Depricate CacheMetrics.getRebalancingPartitionsCount(); and move to 
CacheGroupMetricsMXBean.getRebalancingPartitionsCount();

  was:
1. Create new MXbean for each index, IndexMxBean
{code}
class IndexMxBean{
/** The number of PUT operations on the index. */
long getProcessedPuts();
/** The number of GET operations on the index. */
long getProcessedGets();
/** The total index size in bytes. */
long getIndexSize();
/** Index name.*/
String getName();
}
{code}

2. Add new metrics for data storage and cache group.
{code}
class CacheGroupMetricsMXBean{
/** The total index size in bytes */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes for reuse list.*/
long getReuseListSize();
/** Total size in bytes. */
long getTotalSize();
/** Total size in bytes for pure data.*/
long getDataSize();
/** CacheGroup type. PARTITIONED, REPLICATED, LOCAL.*/
String getType();
/** Partitions currently assigned to the local node in this cache group. */
int[] getPartitions();
}
{code}

{code}
class DataRegionMXBean{
/** Total size in bytes for indexes. */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes. */
long getTotalSize();
/** Total size in bytes for pure data.*/
long getDataSize();
/** Total size in bytes for pure data.*/
long getDataPagesSize();
/** Total used offheap size in bytes. */
long getOffheapUsedSize();
/** The number of read pages from last restart. */
long getPagesRead();
/** The number of writen pages from last restart. */
long getPagesWriten();
/** The number of replaced pages from last restart . */
long getPagesReplaced();
/** Total dirty pages for the next checkpoint. */
long getDirtyPagesForNextCheckpoint();
}
{code}

{code}
class DataStorageMXbean{
/** Total size in bytes for indexes. */
long getIndexesSize();
/** Total size 

[jira] [Updated] (IGNITE-8078) Add new metrics for data storage

[Dmitriy Govorukhin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Govorukhin updated IGNITE-8078:
---
Description: 
1. Create new MXbean for each index, IndexMxBean
{code}
class IndexMxBean{
/** The number of PUT operations on the index. */
long getProcessedPuts();
/** The number of GET operations on the index. */
long getProcessedGets();
/** The total index size in bytes. */
long getIndexSize();
/** Index name.*/
String getName();
}
{code}

2. Add new metrics for data storage and cache group.
{code}
class CacheGroupMetricsMXBean{
/** The total index size in bytes */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes for reuse list.*/
long getReuseListSize();
/** Total size in bytes. */
long getTotalSize();
/** Total size in bytes for pure data.*/
long getDataSize();
/** CacheGroup type. PARTITIONED, REPLICATED, LOCAL.*/
String getType();
/** Partitions currently assigned to the local node in this cache group. */
int[] getPartitions();
}
{code}

{code}
class DataRegionMXBean{
/** Total size in bytes for indexes. */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes. */
long getTotalSize();
/** Total size in bytes for pure data.*/
long getDataSize();
/** Total used offheap size in bytes. */
long getOffheapUsedSize();
/** The number of read pages from last restart. */
long getPagesRead();
/** The number of writen pages from last restart. */
long getPagesWriten();
/** The number of replaced pages from last restart . */
long getPagesReplaced();
/** Total dirty pages for the next checkpoint. */
long getDirtyPagesForNextCheckpoint();
}
{code}

{code}
class DataStorageMXbean{
/** Total size in bytes for indexes. */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes for all storages. */
long getTotalSize();
/** Total offheap size in bytes. */
long getOffHeapSize();
/** Total used offheap size in bytes for all data regions. */
long getOffheapUsedSize();
/** Total size in bytes for pure data.*/
long getDataSize();
/** The number of read pages from last restart. */
long getPagesRead();
/** The number of writen pages from last restart. */
long getPagesWriten();
/** The number of replaced pages from last restart. */
long getPagesReplaced();
/** Total checkpoint time from last restart. */
long getCheckpointTotalTime();
/** Total dirty pages for the next checkpoint. */
long getDirtyPagesForNextCheckpoint();
/** Total size in bytes for storage wal files. */
long getWalTotalSize();
/** Time of the last WAL segment rollover. */
long getWalLastSwitchTime();
}
{code}

{code}
class IgniteMxBean {
/** Returns string containing Node ID, Consistent ID, Node Order */
String getCurrentCoordinator();
}
{code}

Depricate CacheMetrics.getRebalancingPartitionsCount(); and move to 
CacheGroupMetricsMXBean.getRebalancingPartitionsCount();

  was:
1. Create new MXbean for each index, IndexMxBean
{code}
class IndexMxBean{
/** The number of PUT operations on the index. */
long getProcessedPuts();
/** The number of GET operations on the index. */
long getProcessedGets();
/** The total index size in bytes. */
long getIndexSize();
/** Index name.*/
String getName();
}
{code}

2. Add new metrics for data storage and cache group.
{code}
class CacheGroupMetricsMXBean{
/** The total index size in bytes */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes. */
long getTotalSize();
/** Total size in bytes for pure data.*/
long getDataSize();
/** CacheGroup type. PARTITIONED, REPLICATED, LOCAL.*/
String getType();
/** Partitions currently assigned to the local node in this cache group. */
int[] getPartitions();
}
{code}

{code}
class DataRegionMXBean{
/** Total size in bytes for indexes. */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes. */
long getTotalSize();
/** Total size in bytes for pure data.*/
long getDataSize();
/** Total used offheap size in bytes. */
long getOffheapUsedSize();
/** The number of read pages from last restart. */
long getPagesRead();
/** The number of writen pages from last restart. */
long getPagesWriten();
/** The number of replaced pages from last restart . */
long getPagesReplaced();
/** Total dirty pages for the next checkpoint. */
long getDirtyPagesForNextCheckpoint();
}
{code}

{code}
class DataStorageMXbean{
/** Total size in bytes for indexes. */
long getIndexesSize();
/** Total size in bytes for primary key indexes. */
long getPKIndexesSize();
/** Total size in bytes for all storages. */
long getTotalSize();
/** Total offheap size in bytes. */
long getOffHeapSize();
/** Total used offheap size in bytes for all data regions. */
long 

[jira] [Commented] (IGNITE-7831) Throw Exceptions instead of AssertionErrors when reading from corrupted persistence

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422857#comment-16422857
 ] 

Andrey Gura commented on IGNITE-7831:
-

[~alex_pl] LGTM! Merged into master branch. Thanks for contribution!

> Throw Exceptions instead of AssertionErrors when reading from corrupted 
> persistence
> ---
>
> Key: IGNITE-7831
> URL: https://issues.apache.org/jira/browse/IGNITE-7831
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> There are a few places in our code where we explicitly throw AssertionErrors 
> due to inability to correctly read data from persistence and many more places 
> where we make assertions based on read values.
> Assertions are used to indicate problems in internal logic, while persistence 
> might also get corrupted by various external reasons. It also makes uniform 
> handling of such issues considerably harder, because exception handling logic 
> in Ignite ignores Errors. If we want to improve stability and minimize 
> consequenses of pesistence corruption, we should replace all those 
> AssertionErrors and asserts with Exceptions, so that current exception 
> handling mechanisms could be reduce. In a number of situations it means that 
> instead of causing cluster-wide hang-up problematic node will be 
> automatically killed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7904) ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() throws IgniteException

[Stanislav Lukyanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422813#comment-16422813
 ] 

Stanislav Lukyanov commented on IGNITE-7904:


[~dpavlov], could you please review the changes?

> ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() 
> throws IgniteException
> -
>
> Key: IGNITE-7904
> URL: https://issues.apache.org/jira/browse/IGNITE-7904
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
>
> ComputeTask.result() javadoc says: "Throws: IgniteException - If handling a 
> job result caused an error effectively rejecting a failover. This exception 
> will be thrown out of ComputeTaskFuture.get() method."
> However, GridFutureAdapter calls IgniteUtils.cast(Throwable) on the exception 
> before throwing it from get(), and the latter method trims the stack trace to 
> the first occurence of an IgniteCheckedException. Because of that, get() 
> throws not the IgniteException thrown from the ComputeTask.result() but one 
> of its causes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6827) Configurable rollback for long running transactions before partition exchange

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422805#comment-16422805
 ] 

Andrey Gura commented on IGNITE-6827:
-

[~ascherbakov] I've reviewed changes and have some comments.

First of all, it seems strange that {{rollbackOnTopologyChangeTimeout}} 
parameter is part of {{TransactionConfiguration}}. Actually PME uses this value 
and it is PME's responsibility to rollback transactions, so timeout should be 
parameter of exchange.

{{GridDistributedTxFinishRequest}} contains new field {{timedout}}. I believe 
that we can use bit from {{flags}} field instead of new boolean field. In this 
case message format will n't be changed.

Some minor comments:

* Some TODO's added but isn't resolved in classes: {{IgniteTxManager}}, 
{{GridCacheAdapter}}, {{GridCAcheMvccManager}}.
* {{IgniteTxAdapter.remainingTime}}: {{timedOut}} flag value checking is 
redundant because the same work will be done in couple lines below.
* {{GridCachePartitionExchangeManager.body0()}}: two calls of 
{{cfg.getTransactionConfiguration().getRollbackOnTopologyChangeTimeout()}} can 
be rewritten in more concise and convenient form:

Before:

{code:java}
boolean rollbackEnabled = 
cfg.getTransactionConfiguration().getRollbackOnTopologyChangeTimeout() > 0;

final long dumpTimeout = 2 * 
cctx.gridConfig().getNetworkTimeout();

long nextDumpTime = 0;

while (true) {
try {
resVer = exchFut.get(rollbackEnabled ? 
cfg.getTransactionConfiguration().
getRollbackOnTopologyChangeTimeout() : 
dumpTimeout, TimeUnit.MILLISECONDS);

break;
}
{code}

After: 

{code:java}
long rollbackTimeout = 
cfg.getTransactionConfiguration().getRollbackOnTopologyChangeTimeout();

final long dumpTimeout = 2 * 
cctx.gridConfig().getNetworkTimeout();

long nextDumpTime = 0;

while (true) {
try {
resVer = exchFut.get(rollbackTimeout > 0 ? 
rollbackTimeout : dumpTimeout, TimeUnit.MILLISECONDS);

break;
}
{code}

> Configurable rollback for long running transactions before partition exchange
> -
>
> Key: IGNITE-6827
> URL: https://issues.apache.org/jira/browse/IGNITE-6827
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.5
>
>
> Currently long running / buggy user transactions force partition exchange 
> block on waiting for 
> org.apache.ignite.internal.processors.cache.GridCacheSharedContext#partitionReleaseFuture,
>  preventing all grid progress.
> I suggest introducing new global flag in TransactionConfiguration, like 
> {{txRollbackTimeoutOnTopologyChange}}
> which will rollback exchange blocking transaction after the timeout.
> Still need to think what to do with other topology locking activities.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8106) In control.sh -active, exception will be eaten and not displayed

[Ilya Kasnacheev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Kasnacheev reassigned IGNITE-8106:
---

Assignee: Ilya Kasnacheev

> In control.sh -active, exception will be eaten and not displayed
> 
>
> Key: IGNITE-8106
> URL: https://issues.apache.org/jira/browse/IGNITE-8106
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>
> Here is the relevant code from GridChangeStateCommandHandler:
> {code}
> sb.a(e.getMessage()).a("\n").a("suppressed: \n");
> for (Throwable t:e.getSuppressed())
> sb.a(t.getMessage()).a("\n");
> {code}
> However, before that code the exception will pass through 
> IgniteUtils.convertException(), which will wrap the old 
> IgniteCheckedException with suppressed parts with a new IgniteException with 
> 0 suppressed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8106) In control.sh -active, exception will be eaten and not displayed

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422788#comment-16422788
 ] 

ASF GitHub Bot commented on IGNITE-8106:


GitHub user alamar opened a pull request:

https://github.com/apache/ignite/pull/3735

IGNITE-8106 Collect suppressed exceptions from causes.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8106

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3735.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 #3735


commit 1421c53bb2fff8a64afdb9719d20794f4890feb1
Author: Ilya Kasnacheev 
Date:   2018-04-02T17:06:50Z

IGNITE-8106 Collect suppressed exceptions from causes.




> In control.sh -active, exception will be eaten and not displayed
> 
>
> Key: IGNITE-8106
> URL: https://issues.apache.org/jira/browse/IGNITE-8106
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Priority: Minor
>
> Here is the relevant code from GridChangeStateCommandHandler:
> {code}
> sb.a(e.getMessage()).a("\n").a("suppressed: \n");
> for (Throwable t:e.getSuppressed())
> sb.a(t.getMessage()).a("\n");
> {code}
> However, before that code the exception will pass through 
> IgniteUtils.convertException(), which will wrap the old 
> IgniteCheckedException with suppressed parts with a new IgniteException with 
> 0 suppressed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9) Need to implement IngniteReentrantReadWriteLock

[Anton Vinogradov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422747#comment-16422747
 ] 

Anton Vinogradov commented on IGNITE-9:
---

I think there is no need to wait for new implementation
We have to implement IngniteReentrantReadWriteLock using current implementation.

> Need to implement IngniteReentrantReadWriteLock
> ---
>
> Key: IGNITE-9
> URL: https://issues.apache.org/jira/browse/IGNITE-9
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Yakov Zhdanov
>Priority: Major
>
> See org.apache.ignite.IgniteLock for reference



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[Ryabov Dmitrii (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422748#comment-16422748
 ] 

Ryabov Dmitrii commented on IGNITE-6802:


[~dpavlov], thank you for merge)

> NullPointerException when WAL store and WAL archive paths are same 
> ---
>
> Key: IGNITE-6802
> URL: https://issues.apache.org/jira/browse/IGNITE-6802
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.2
>Reporter: Alexey Kukushkin
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie, usability
> Fix For: 2.5
>
>
> Configuring WAL store and WAL archive paths to be the same results in 
> NullPointerException. We should display a meaningful error about the 
> misconfiguration instead.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
> The thread includes the reproducer code and stack trace. I was able to 
> reproduce the issue with today's (31-Oct-2017) Apache master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422744#comment-16422744
 ] 

ASF GitHub Bot commented on IGNITE-6802:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3021


> NullPointerException when WAL store and WAL archive paths are same 
> ---
>
> Key: IGNITE-6802
> URL: https://issues.apache.org/jira/browse/IGNITE-6802
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.2
>Reporter: Alexey Kukushkin
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie, usability
> Fix For: 2.5
>
>
> Configuring WAL store and WAL archive paths to be the same results in 
> NullPointerException. We should display a meaningful error about the 
> misconfiguration instead.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
> The thread includes the reproducer code and stack trace. I was able to 
> reproduce the issue with today's (31-Oct-2017) Apache master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[Ryabov Dmitrii (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422734#comment-16422734
 ] 

Ryabov Dmitrii commented on IGNITE-6802:


[~dpavlov], I applied last proposal.

> NullPointerException when WAL store and WAL archive paths are same 
> ---
>
> Key: IGNITE-6802
> URL: https://issues.apache.org/jira/browse/IGNITE-6802
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.2
>Reporter: Alexey Kukushkin
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie, usability
> Fix For: 2.5
>
>
> Configuring WAL store and WAL archive paths to be the same results in 
> NullPointerException. We should display a meaningful error about the 
> misconfiguration instead.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
> The thread includes the reproducer code and stack trace. I was able to 
> reproduce the issue with today's (31-Oct-2017) Apache master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8112) DirectIO artifact is not published in the maven repository

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422728#comment-16422728
 ] 

Dmitriy Pavlov commented on IGNITE-8112:


What do you think if we run PDS tests on branch? Or we can be pretty sure this 
change is safe to merge w/o testing?

> DirectIO artifact is not published in the maven repository
> --
>
> Key: IGNITE-8112
> URL: https://issues.apache.org/jira/browse/IGNITE-8112
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8115) Add a warning on local node startup if the node is not in Baseline

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422686#comment-16422686
 ] 

Dmitriy Pavlov commented on IGNITE-8115:


I think it may be reasonable to add instructions text or links to docs, as 
ticket is labeled newbie.

> Add a warning on local node startup if the node is not in Baseline
> --
>
> Key: IGNITE-8115
> URL: https://issues.apache.org/jira/browse/IGNITE-8115
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: newbie
>
> The message should contain instructions on how to add the node to baseline.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8111) Add extra validation for WAL segment size

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-8111:
---
Fix Version/s: 2.5

> Add extra validation for WAL segment size
> -
>
> Key: IGNITE-8111
> URL: https://issues.apache.org/jira/browse/IGNITE-8111
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Ivan Rakov
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Currently we can set extra small DataStorageConfiguration#walSegmentSize (10 
> pages or even less than one page), which will trigger multiple assertion 
> errors in code.
> We have to implement validation on node start that WAL segment size has 
> reasonable value (512KB or more).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (IGNITE-6576) Protect WAL segment size from specifying too low value

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov resolved IGNITE-6576.

   Resolution: Duplicate
Fix Version/s: (was: 2.5)

> Protect WAL segment size from specifying too low value 
> ---
>
> Key: IGNITE-6576
> URL: https://issues.apache.org/jira/browse/IGNITE-6576
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>
> The result of an misprint and autocompletion I've specified WalSegmentSize 
> instead of WalHistorySize to value 1 in the Ignite PDS setup .
> When you configure a WAL segment length in one byte no error is returned. 
> In this case, all segments begin switch (rollover) to the next and no record 
> is generated.
> As a result, a directory is created with hundreds of thousands of files with 
> a length of 0 bytes.
> In this task, it is proposed to limit the minimum of the segment size.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8111) Add extra validation for WAL segment size

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-8111:
---
Description: 
Currently we can set extra small DataStorageConfiguration#walSegmentSize (10 
pages or even less than one page), which will trigger multiple assertion errors 
in code.
We have to implement validation on node start that WAL segment size has 
reasonable value (512KB or more).

  was:
Currently we can set extra small DataStorageConfiguration#walSegmentSize (10 
pages or even less than one page), which will trigger multiple assertion errors 
in code.
We have to implement validation on node start that WAL segment size has 
reasonable value (e.g. more than 512KB).


> Add extra validation for WAL segment size
> -
>
> Key: IGNITE-8111
> URL: https://issues.apache.org/jira/browse/IGNITE-8111
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Ivan Rakov
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Currently we can set extra small DataStorageConfiguration#walSegmentSize (10 
> pages or even less than one page), which will trigger multiple assertion 
> errors in code.
> We have to implement validation on node start that WAL segment size has 
> reasonable value (512KB or more).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8115) Add a warning on local node startup if the node is not in Baseline

[Alexey Goncharuk (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Goncharuk updated IGNITE-8115:
-
Description: The message should contain instructions on how to add the node 
to baseline.

> Add a warning on local node startup if the node is not in Baseline
> --
>
> Key: IGNITE-8115
> URL: https://issues.apache.org/jira/browse/IGNITE-8115
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: newbie
>
> The message should contain instructions on how to add the node to baseline.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[Ryabov Dmitrii (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422673#comment-16422673
 ] 

Ryabov Dmitrii commented on IGNITE-6802:


[~dpavlov], I applied 2 proposals, but about last proposal I answered in 
upsource.

> NullPointerException when WAL store and WAL archive paths are same 
> ---
>
> Key: IGNITE-6802
> URL: https://issues.apache.org/jira/browse/IGNITE-6802
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.2
>Reporter: Alexey Kukushkin
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie, usability
> Fix For: 2.5
>
>
> Configuring WAL store and WAL archive paths to be the same results in 
> NullPointerException. We should display a meaningful error about the 
> misconfiguration instead.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
> The thread includes the reproducer code and stack trace. I was able to 
> reproduce the issue with today's (31-Oct-2017) Apache master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8115) Add a warning on local node startup if the node is not in Baseline

[Alexey Goncharuk (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Goncharuk updated IGNITE-8115:
-
Labels: newbie  (was: )

> Add a warning on local node startup if the node is not in Baseline
> --
>
> Key: IGNITE-8115
> URL: https://issues.apache.org/jira/browse/IGNITE-8115
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: newbie
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8115) Add a warning on local node startup if the node is not in Baseline

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8115:


 Summary: Add a warning on local node startup if the node is not in 
Baseline
 Key: IGNITE-8115
 URL: https://issues.apache.org/jira/browse/IGNITE-8115
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Goncharuk






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (IGNITE-5655) Introduce pluggable string encoder/decoder

[Andrey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Kuznetsov resolved IGNITE-5655.
--
Resolution: Won't Fix

Feature completion requires significant effort, while there is no active 
interest for it in the community.

> Introduce pluggable string encoder/decoder
> --
>
> Key: IGNITE-5655
> URL: https://issues.apache.org/jira/browse/IGNITE-5655
> Project: Ignite
>  Issue Type: New Feature
>  Components: binary
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: iep-2, important
> Fix For: 2.5
>
>
> Currently binary marshaller encodes strings in UTF-8. However, sometimes it 
> makes sense to serialize strings with different encodings to save space. 
> Let's add global property to control String encoding and customize our binary 
> protocol to support it. For instance, we can add another flag 
> {{ENCODED_STRING}}, which will write strings as follows:
> [flag][encoding_flag][str_len][str_bytes]
> First implementation should set preferred encoding for strings in 
> BinaryConfiguration. This setting is optional, default encoding is UTF-8. 
> Currently, the same BinaryConfiguration is used for all cluster nodes, thus 
> no encoding clashes are possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8114) Add fail recovery mechanism to tracking pages

[Eduard Shangareev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422660#comment-16422660
 ] 

Eduard Shangareev commented on IGNITE-8114:
---

PR - https://github.com/apache/ignite/pull/3734
TC - https://ci.ignite.apache.org/viewQueued.html?itemId=1173250

> Add fail recovery mechanism to tracking pages
> -
>
> Key: IGNITE-8114
> URL: https://issues.apache.org/jira/browse/IGNITE-8114
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>
> Now we just assert that last saved tag in tracking page should be not greater 
> than passed one.
> But because of different issues which we don't understand yet, it could 
> happen.
> So, I suggest to handle it by adding new "corruption" state to tracking 
> state. 
> If tracking page is in a corrupted state than we would throw an exception on 
> any querying of the tracking page. Caller will have opportunity to catch the 
> exception and recover page state.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8114) Add fail recovery mechanism to tracking pages

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422656#comment-16422656
 ] 

ASF GitHub Bot commented on IGNITE-8114:


GitHub user EdShangGG opened a pull request:

https://github.com/apache/ignite/pull/3734

IGNITE-8114 Add fail recovery mechanism to tracking pages



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8114

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3734.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 #3734


commit e34a82625d7ade969848cbb9fa1073adb66c80d9
Author: Eduard Shangareev 
Date:   2018-03-14T13:48:23Z

IGNITE-8114 Add fail recovery mechanism to tracking pages




> Add fail recovery mechanism to tracking pages
> -
>
> Key: IGNITE-8114
> URL: https://issues.apache.org/jira/browse/IGNITE-8114
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>
> Now we just assert that last saved tag in tracking page should be not greater 
> than passed one.
> But because of different issues which we don't understand yet, it could 
> happen.
> So, I suggest to handle it by adding new "corruption" state to tracking 
> state. 
> If tracking page is in a corrupted state than we would throw an exception on 
> any querying of the tracking page. Caller will have opportunity to catch the 
> exception and recover page state.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8114) Add fail recovery mechanism to tracking pages

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-8114:
---
Description: 
Now we just assert that last saved tag in tracking page should be not greater 
than passed one.
But because of different issues which we don't understand yet, it could happen.

So, I suggest to handle it by adding new "corruption" state to tracking state. 
If tracking page is in a corrupted state than we would throw an exception on 
any querying of the tracking page. Caller will have opportunity to catch the 
exception and recover page state.

  was:
Now we just assert that last saved tag in tracking page should be not greater 
than passed one.
But because of different issues, it could happen.

So, I suggest to handle it by adding new "corruption" state to tracking page. 
If tracking page is in a corrupted state than we would throw an exception on 
any querying of the tracking page. 


> Add fail recovery mechanism to tracking pages
> -
>
> Key: IGNITE-8114
> URL: https://issues.apache.org/jira/browse/IGNITE-8114
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>
> Now we just assert that last saved tag in tracking page should be not greater 
> than passed one.
> But because of different issues which we don't understand yet, it could 
> happen.
> So, I suggest to handle it by adding new "corruption" state to tracking 
> state. 
> If tracking page is in a corrupted state than we would throw an exception on 
> any querying of the tracking page. Caller will have opportunity to catch the 
> exception and recover page state.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8114) Add fail recovery mechanism to tracking pages

[Eduard Shangareev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eduard Shangareev updated IGNITE-8114:
--
Description: 
Now we just assert that last saved tag in tracking page should be not greater 
than passed one.
But because of different issues, it could happen.

So, I suggest to handle it by adding new "corruption" state to tracking page. 
If tracking page is in a corrupted state than we would throw an exception on 
any querying of the tracking page. 

  was:
Now we just assert that last saved tag in tracking page should be not greater 
than passed one.
But because of different issues, it could happen.

So, I suggest to handle it by adding new "corruption" state to tracking state. 
If tracking page is in a corrupted state than we would throw an exception on 
any querying of the tracking page. 


> Add fail recovery mechanism to tracking pages
> -
>
> Key: IGNITE-8114
> URL: https://issues.apache.org/jira/browse/IGNITE-8114
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>
> Now we just assert that last saved tag in tracking page should be not greater 
> than passed one.
> But because of different issues, it could happen.
> So, I suggest to handle it by adding new "corruption" state to tracking page. 
> If tracking page is in a corrupted state than we would throw an exception on 
> any querying of the tracking page. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8114) Add fail recovery mechanism to tracking pages

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-8114:
-

 Summary: Add fail recovery mechanism to tracking pages
 Key: IGNITE-8114
 URL: https://issues.apache.org/jira/browse/IGNITE-8114
 Project: Ignite
  Issue Type: Improvement
Reporter: Eduard Shangareev
Assignee: Eduard Shangareev
 Fix For: 2.5


Now we just assert that last saved tag in tracking page should be not greater 
than passed one.
But because of different issues, it could happen.

So, I suggest to handle it by adding new "corruption" state to tracking state. 
If tracking page is in a corrupted state than we would throw an exception on 
any querying of the tracking page. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8113) ZookeeperClientTest#testReconnect3, testReconnect4 fail on TC

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-8113:
---

 Summary: ZookeeperClientTest#testReconnect3, testReconnect4 fail 
on TC
 Key: IGNITE-8113
 URL: https://issues.apache.org/jira/browse/IGNITE-8113
 Project: Ignite
  Issue Type: Bug
  Components: zookeeper
Reporter: Sergey Chugunov


Tests always fail on TC, testReconnect3 failure is reproducible locally as well.

A message in logs says that ZooKeeper cluster shuts itself down during the test:
{noformat}
[Step 4/5] java.lang.Exception: shutdown Leader! reason: Not sufficient 
followers synced, only synced with sids: [ 11 ]
{noformat}

Most likely there is a bug in test itself, no real functionality is affected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8112) DirectIO artifact is not published in the maven repository

[Vyacheslav Koptilin (JIRA)]

Vyacheslav Koptilin created IGNITE-8112:
---

 Summary: DirectIO artifact is not published in the maven repository
 Key: IGNITE-8112
 URL: https://issues.apache.org/jira/browse/IGNITE-8112
 Project: Ignite
  Issue Type: Bug
  Components: build
Affects Versions: 2.4
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Issue Comment Deleted] (IGNITE-8108) .NET: Fix flaky EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup

[Alexey Popov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Popov updated IGNITE-8108:
-
Comment: was deleted

(was: [~dpavlov], please review & commit)

> .NET: Fix flaky 
> EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup
> --
>
> Key: IGNITE-8108
> URL: https://issues.apache.org/jira/browse/IGNITE-8108
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.5
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
>  Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1171195=IgniteTests24Java8_IgnitePlatformNetIntegrations=buildLog&_focus=6035
> Test uses multicast ipFinder.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8108) .NET: Fix flaky EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup

[Alexey Popov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422622#comment-16422622
 ] 

Alexey Popov commented on IGNITE-8108:
--

[~dpavlov], please review & commit

> .NET: Fix flaky 
> EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup
> --
>
> Key: IGNITE-8108
> URL: https://issues.apache.org/jira/browse/IGNITE-8108
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.5
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
>  Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1171195=IgniteTests24Java8_IgnitePlatformNetIntegrations=buildLog&_focus=6035
> Test uses multicast ipFinder.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-5978) [Test Failed] IgnitePartitionedCountDownLatchSelfTest.testLatchMultinode1

[Vitaliy Biryukov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitaliy Biryukov reassigned IGNITE-5978:


Assignee: Vitaliy Biryukov

> [Test Failed] IgnitePartitionedCountDownLatchSelfTest.testLatchMultinode1
> -
>
> Key: IGNITE-5978
> URL: https://issues.apache.org/jira/browse/IGNITE-5978
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Fails locally.
> Example of failing - 
> http://ci.ignite.apache.org/viewLog.html?buildId=759891=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures#testNameId677264269171099154.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7537) SQL COPY command: implement CSV format options

[Taras Ledkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Taras Ledkov reassigned IGNITE-7537:


Assignee: Taras Ledkov

> SQL COPY command: implement CSV format options
> --
>
> Key: IGNITE-7537
> URL: https://issues.apache.org/jira/browse/IGNITE-7537
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Kirill Shirokov
>Assignee: Taras Ledkov
>Priority: Major
>
> The following options can be implemented for the CSV format:
> * Line separator pattern
> * Field separator pattern
> * Set of quote characters
> * Escape sequence start character
> * Line comment character
> Escape sequences support is important for this feature. There is a draft code 
> for handling escape sequences in a branch called ignite-7372 (see IGNITE-7372 
> for details).
> Syntax example:
> {noformat}
> COPY
> ...
> FORMAT CSV
> [FIELDSEP='column-separators-regexp']
> [LINESEP='row-separators-regexp']
> [QUOTE='quote-chars']
> [ESCAPE='escape-char']
> [COMMENT='line-comment-char']
> {noformat}
> We may also want:
> * Line comments handling
> * Spaces trimming
> * Empty lines skipping



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422605#comment-16422605
 ] 

Dmitriy Pavlov commented on IGNITE-6802:


[~SomeFire] I left several proposals in upsource. Please fix if you're agree.

> NullPointerException when WAL store and WAL archive paths are same 
> ---
>
> Key: IGNITE-6802
> URL: https://issues.apache.org/jira/browse/IGNITE-6802
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.2
>Reporter: Alexey Kukushkin
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie, usability
> Fix For: 2.5
>
>
> Configuring WAL store and WAL archive paths to be the same results in 
> NullPointerException. We should display a meaningful error about the 
> misconfiguration instead.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
> The thread includes the reproducer code and stack trace. I was able to 
> reproduce the issue with today's (31-Oct-2017) Apache master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8071) Add tests for failure handlers

[Dmitriy Sorokin (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422602#comment-16422602
 ] 

Dmitriy Sorokin commented on IGNITE-8071:
-

[~agura], review my patch, please!

> Add tests for failure handlers
> --
>
> Key: IGNITE-8071
> URL: https://issues.apache.org/jira/browse/IGNITE-8071
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Dmitriy Sorokin
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> Different failure handlers were implemented due to IEP-14 (IGNITE-6890). 
> Tests should be added for this implementations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8108) .NET: Fix flaky EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-8108:
---
Labels: MakeTeamcityGreenAgain  (was: )

> .NET: Fix flaky 
> EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup
> --
>
> Key: IGNITE-8108
> URL: https://issues.apache.org/jira/browse/IGNITE-8108
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.5
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
>  Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1171195=IgniteTests24Java8_IgnitePlatformNetIntegrations=buildLog&_focus=6035
> Test uses multicast ipFinder.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8108) .NET: Fix flaky EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422592#comment-16422592
 ] 

Dmitriy Pavlov commented on IGNITE-8108:


Test has passed. I suggest to merge this change. [~vozerov] are you agree?

> .NET: Fix flaky 
> EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup
> --
>
> Key: IGNITE-8108
> URL: https://issues.apache.org/jira/browse/IGNITE-8108
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.5
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
>  Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1171195=IgniteTests24Java8_IgnitePlatformNetIntegrations=buildLog&_focus=6035
> Test uses multicast ipFinder.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8111) Add extra validation for WAL segment size

[Ivan Rakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422589#comment-16422589
 ] 

Ivan Rakov commented on IGNITE-8111:


The validation should be covered by test.

> Add extra validation for WAL segment size
> -
>
> Key: IGNITE-8111
> URL: https://issues.apache.org/jira/browse/IGNITE-8111
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Ivan Rakov
>Priority: Major
>  Labels: newbie
>
> Currently we can set extra small DataStorageConfiguration#walSegmentSize (10 
> pages or even less than one page), which will trigger multiple assertion 
> errors in code.
> We have to implement validation on node start that WAL segment size has 
> reasonable value (e.g. more than 512KB).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8111) Add extra validation for WAL segment size

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-8111:
--

 Summary: Add extra validation for WAL segment size
 Key: IGNITE-8111
 URL: https://issues.apache.org/jira/browse/IGNITE-8111
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.4
Reporter: Ivan Rakov


Currently we can set extra small DataStorageConfiguration#walSegmentSize (10 
pages or even less than one page), which will trigger multiple assertion errors 
in code.
We have to implement validation on node start that WAL segment size has 
reasonable value (e.g. more than 512KB).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8044) IgniteQueryGenerator.getOptions() method should properly handle empty list of parameters.

[Vyacheslav Koptilin (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422587#comment-16422587
 ] 

Vyacheslav Koptilin commented on IGNITE-8044:
-

I have checked, the test and it doesn't seem that the test failure related to 
the described changes.

> IgniteQueryGenerator.getOptions() method should properly handle empty list of 
> parameters.
> -
>
> Key: IGNITE-8044
> URL: https://issues.apache.org/jira/browse/IGNITE-8044
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Minor
> Fix For: 2.5
>
>
> {{IgniteQueryGenerator.getOptions()}} method does not check that the 
> parameters list can be empty.
> Initial discussion of the issue is available on the user-list: 
> http://apache-ignite-users.70518.x6.nabble.com/ArrayIndexOutOfBoundsException-1-in-IgniteQueryGenerator-getOptions-tt20801.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8110) GridCacheWriteBehindStore.Flusher thread uses the wrong transformation from milliseconds to nanoseconds.

[Vyacheslav Koptilin (JIRA)]

Vyacheslav Koptilin created IGNITE-8110:
---

 Summary: GridCacheWriteBehindStore.Flusher thread uses the wrong 
transformation from milliseconds to nanoseconds.
 Key: IGNITE-8110
 URL: https://issues.apache.org/jira/browse/IGNITE-8110
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.4
Reporter: Vyacheslav Koptilin


The initial value of a cache flushing frequency is defined as follows:
{code}
/** Cache flushing frequence in nanos. */
protected long cacheFlushFreqNanos = cacheFlushFreq * 1000;
{code}

where is {{cacheFlushFreq}} is equal to
{code}
/** Default flush frequency for write-behind cache store in milliseconds. */
public static final long DFLT_WRITE_BEHIND_FLUSH_FREQUENCY = 5000;
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[Ryabov Dmitrii (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422568#comment-16422568
 ] 

Ryabov Dmitrii commented on IGNITE-6802:


> I meant Issue type change from 'bug' to 'test', but not a label.
Label removed.

Can you merge it?

> NullPointerException when WAL store and WAL archive paths are same 
> ---
>
> Key: IGNITE-6802
> URL: https://issues.apache.org/jira/browse/IGNITE-6802
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.2
>Reporter: Alexey Kukushkin
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie, usability
> Fix For: 2.5
>
>
> Configuring WAL store and WAL archive paths to be the same results in 
> NullPointerException. We should display a meaningful error about the 
> misconfiguration instead.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
> The thread includes the reproducer code and stack trace. I was able to 
> reproduce the issue with today's (31-Oct-2017) Apache master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[Ryabov Dmitrii (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryabov Dmitrii updated IGNITE-6802:
---
Labels: newbie usability  (was: newbie test usability)

> NullPointerException when WAL store and WAL archive paths are same 
> ---
>
> Key: IGNITE-6802
> URL: https://issues.apache.org/jira/browse/IGNITE-6802
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.2
>Reporter: Alexey Kukushkin
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie, usability
> Fix For: 2.5
>
>
> Configuring WAL store and WAL archive paths to be the same results in 
> NullPointerException. We should display a meaningful error about the 
> misconfiguration instead.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
> The thread includes the reproducer code and stack trace. I was able to 
> reproduce the issue with today's (31-Oct-2017) Apache master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422557#comment-16422557
 ] 

Dmitriy Pavlov commented on IGNITE-6802:


[~SomeFire], no, there is no need to re-run (if there was no changes).

I meant Issue type change from 'bug' to 'test', but not a label.

> NullPointerException when WAL store and WAL archive paths are same 
> ---
>
> Key: IGNITE-6802
> URL: https://issues.apache.org/jira/browse/IGNITE-6802
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.2
>Reporter: Alexey Kukushkin
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie, test, usability
> Fix For: 2.5
>
>
> Configuring WAL store and WAL archive paths to be the same results in 
> NullPointerException. We should display a meaningful error about the 
> misconfiguration instead.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
> The thread includes the reproducer code and stack trace. I was able to 
> reproduce the issue with today's (31-Oct-2017) Apache master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8109) IgniteCacheEntryListenerAtomicTest#testConcurrentRegisterDeregister timeouts when ZooKeeper Discovery is used

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-8109:
---

 Summary: 
IgniteCacheEntryListenerAtomicTest#testConcurrentRegisterDeregister timeouts 
when ZooKeeper Discovery is used
 Key: IGNITE-8109
 URL: https://issues.apache.org/jira/browse/IGNITE-8109
 Project: Ignite
  Issue Type: Bug
  Components: zookeeper
Reporter: Sergey Chugunov


IgniteCacheEntryListenerAtomicTest#testConcurrentRegisterDeregister test works 
fast when TCP-based Discovery is used but takes a long time to finish on 
ZooKeeper-based Discovery. 

Reproducible locally; usually takes from 3 to 4 minutes for one test, on TC 
fails with 5 minutes timeout.

Investigation of slow down root cause is needed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-6066) Grid hangs on partition map exhcange during failover test with 30 physical caches

[Pavel Pereslegin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-6066:


Assignee: (was: Pavel Pereslegin)

> Grid hangs on partition map exhcange during failover test with 30 physical 
> caches
> -
>
> Key: IGNITE-6066
> URL: https://issues.apache.org/jira/browse/IGNITE-6066
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ksenia Rybakova
>Priority: Major
> Attachments: ignite-base-load-config.xml, 
> ignite-base-load-config_InMemory.xml, run-load.properties, run-load.xml, 
> run-load_InMemory.properties, run-load_InMemory.xml
>
>
> Grid hangs on partition map exhcange during failover test with 30 physical 
> caches. Issue is reproduced with and without PDS.
> Load config with PDS:
> CacheRandomOperationBenchmark
> 7 client nodes, 7 server nodes
> 250K perloading, 500K key range
> 30 physical caches
> 2 backups
> 1 server node is being restarted periodically
> Load config in memory:
> CacheRandomOperationBenchmark
> 5 client nodes, 45 server nodes
> 100K perloading, 200K key range
> 30 physical caches
> 2 backups
> 1 server node is being restarted periodically
> Complete configs are attached.
> Preloading phase is ok, then main test starts and after some time grid hangs.
> One of the servers failed with OutOfMemoryError.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7393) Apache Ignite delivery in RPM / DEB packages

[Peter Ivanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Ivanov updated IGNITE-7393:
-
Summary: Apache Ignite delivery in RPM / DEB packages  (was: Apache Ignite 
delivery in RPM / DEV packages)

> Apache Ignite delivery in RPM / DEB packages
> 
>
> Key: IGNITE-7393
> URL: https://issues.apache.org/jira/browse/IGNITE-7393
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
>
> Aggregation task for first stage of preparing Apache Ignite delivery through 
> RPM / DEB packages.
> Steps:
> # Prepare source-based package build procedures for RPM and DEB.
> # Introduce these build procedures to Release Apache Ignite task in PublicTC.
> # Introduce upload / update schemes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7393) Apache Ignite delivery in RPM / DEB packages

[Peter Ivanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Ivanov updated IGNITE-7393:
-
Fix Version/s: (was: 2.5)

> Apache Ignite delivery in RPM / DEB packages
> 
>
> Key: IGNITE-7393
> URL: https://issues.apache.org/jira/browse/IGNITE-7393
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
>
> Aggregation task for first stage of preparing Apache Ignite delivery through 
> RPM / DEB packages.
> Steps:
> # Prepare source-based package build procedures for RPM and DEB.
> # Introduce these build procedures to Release Apache Ignite task in PublicTC.
> # Introduce upload / update schemes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8108) .NET: Fix flaky EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup

[Alexey Popov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422546#comment-16422546
 ] 

Alexey Popov commented on IGNITE-8108:
--

TC run: 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePlatformNetIntegrations_IgniteTests24Java8=pull%2F3731%2Fhead=buildTypeStatusDiv


> .NET: Fix flaky 
> EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup
> --
>
> Key: IGNITE-8108
> URL: https://issues.apache.org/jira/browse/IGNITE-8108
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.5
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1171195=IgniteTests24Java8_IgnitePlatformNetIntegrations=buildLog&_focus=6035
> Test uses multicast ipFinder.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8108) .NET: Fix flaky EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup

[Alexey Popov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422544#comment-16422544
 ] 

Alexey Popov commented on IGNITE-8108:
--

Changes:
1. Fixed test with default multicast ipFinder
2. Checked & reviewed all other tests

> .NET: Fix flaky 
> EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup
> --
>
> Key: IGNITE-8108
> URL: https://issues.apache.org/jira/browse/IGNITE-8108
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.5
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1171195=IgniteTests24Java8_IgnitePlatformNetIntegrations=buildLog&_focus=6035
> Test uses multicast ipFinder.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8108) .NET: Fix flaky EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422545#comment-16422545
 ] 

ASF GitHub Bot commented on IGNITE-8108:


GitHub user apopovgg opened a pull request:

https://github.com/apache/ignite/pull/3731

IGNITE-8108: .NET: Fix flaky EntityFrameworkCacheInitializationTest.T…

…estConfigurationAndStartup

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8108

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3731.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 #3731


commit 096db41e45d21c386e7e1ff2c661e42492f55dae
Author: apopov 
Date:   2018-04-02T14:12:59Z

IGNITE-8108: .NET: Fix flaky 
EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup




> .NET: Fix flaky 
> EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup
> --
>
> Key: IGNITE-8108
> URL: https://issues.apache.org/jira/browse/IGNITE-8108
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.5
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1171195=IgniteTests24Java8_IgnitePlatformNetIntegrations=buildLog&_focus=6035
> Test uses multicast ipFinder.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8108) .NET: Fix flaky EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup

[Alexey Popov (JIRA)]

Alexey Popov created IGNITE-8108:


 Summary: .NET: Fix flaky 
EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup
 Key: IGNITE-8108
 URL: https://issues.apache.org/jira/browse/IGNITE-8108
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.5
Reporter: Alexey Popov
Assignee: Alexey Popov


https://ci.ignite.apache.org/viewLog.html?buildId=1171195=IgniteTests24Java8_IgnitePlatformNetIntegrations=buildLog&_focus=6035

Test uses multicast ipFinder.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Ivan Fedotov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov reassigned IGNITE-8085:


Assignee: Ivan Fedotov

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> 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:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[Ryabov Dmitrii (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryabov Dmitrii updated IGNITE-6802:
---
Issue Type: Test  (was: Bug)

> NullPointerException when WAL store and WAL archive paths are same 
> ---
>
> Key: IGNITE-6802
> URL: https://issues.apache.org/jira/browse/IGNITE-6802
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.2
>Reporter: Alexey Kukushkin
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie, test, usability
> Fix For: 2.5
>
>
> Configuring WAL store and WAL archive paths to be the same results in 
> NullPointerException. We should display a meaningful error about the 
> misconfiguration instead.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
> The thread includes the reproducer code and stack trace. I was able to 
> reproduce the issue with today's (31-Oct-2017) Apache master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6186) Remove redundant parameter of GridFutureAdapter::unregisterWaiter()

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422308#comment-16422308
 ] 

ASF GitHub Bot commented on IGNITE-6186:


Github user andrey-kuznetsov closed the pull request at:

https://github.com/apache/ignite/pull/2749


> Remove redundant parameter of GridFutureAdapter::unregisterWaiter()
> ---
>
> Key: IGNITE-6186
> URL: https://issues.apache.org/jira/browse/IGNITE-6186
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Minor
> Fix For: 2.5
>
>
> The method is not thread-safe unless actual parameter is currentThread.
> Let future state is a list of listeners and two concurrent threads are 
> removing two adjacent non-root listener nodes from list simultaneously by 
> calling {{unregisterWaiter()}}. Then data race is possible: one of these 
> listeners can survive its removal. If the listener is a thread waiting for 
> completion in {{get0()}} then this race leads at worst case to 1 extra call 
> to {{LockSupport.park()}}, and it's negligible. Otherwise we deal with an 
> arbitrary listener, and its {{apply()}} will be called twice.
> To be precise, this Jira issue does not relate to any existing bug, but it 
> eliminates fragile construct that can explode on future chages/refactorings.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7909) Java code examples are needed for Spark Data Frames.

[Vitaliy Osipov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitaliy Osipov reassigned IGNITE-7909:
--

Assignee: (was: Vitaliy Osipov)

> Java code examples are needed for Spark Data Frames.
> 
>
> Key: IGNITE-7909
> URL: https://issues.apache.org/jira/browse/IGNITE-7909
> Project: Ignite
>  Issue Type: Improvement
>  Components: spark
>Affects Versions: 2.5
>Reporter: Akmal Chaudhri
>Priority: Major
> Attachments: JavaIgniteCatalogExample.java, 
> JavaIgniteDataFrameExample.java, JavaIgniteDataFrameWriteExample.java
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Existing Scala code examples have been developed to illustrate Ignite support 
> for Spark Data Frames. But Java code examples are also required. Some Java 
> code has already been developed but requires further testing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7909) Java code examples are needed for Spark Data Frames.

[Vitaliy Osipov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitaliy Osipov reassigned IGNITE-7909:
--

Assignee: Vitaliy Osipov  (was: Akmal Chaudhri)

> Java code examples are needed for Spark Data Frames.
> 
>
> Key: IGNITE-7909
> URL: https://issues.apache.org/jira/browse/IGNITE-7909
> Project: Ignite
>  Issue Type: Improvement
>  Components: spark
>Affects Versions: 2.5
>Reporter: Akmal Chaudhri
>Assignee: Vitaliy Osipov
>Priority: Major
> Attachments: JavaIgniteCatalogExample.java, 
> JavaIgniteDataFrameExample.java, JavaIgniteDataFrameWriteExample.java
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Existing Scala code examples have been developed to illustrate Ignite support 
> for Spark Data Frames. But Java code examples are also required. Some Java 
> code has already been developed but requires further testing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8107) Drop cache with SQL table, recreate table on a different cache - cluster fails to activate

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422253#comment-16422253
 ] 

Ilya Kasnacheev commented on IGNITE-8107:
-

[~dmekhanikov] discovered this issue.

> Drop cache with SQL table, recreate table on a different cache - cluster 
> fails to activate
> --
>
> Key: IGNITE-8107
> URL: https://issues.apache.org/jira/browse/IGNITE-8107
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Ilya Kasnacheev
>Priority: Major
>
> This is a bizzare twist on IGNITE-8021
> Imagine you have a cache "tbl" created by public API with corresponding table 
> "tbl".TBL. You also have PDS. Drop this cache, CREATE TABLE TBL with 
> corresponding SQL_PUBLIC_TBL cache. It would work, but if you shut down 
> cluster and try to bring it online, it will fail to activate:
> {code}SchemaOperationException [code=3, msg=Table already exists: TBL]{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8107) Drop cache with SQL table, recreate table on a different cache - cluster fails to activate

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-8107:
---

 Summary: Drop cache with SQL table, recreate table on a different 
cache - cluster fails to activate
 Key: IGNITE-8107
 URL: https://issues.apache.org/jira/browse/IGNITE-8107
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Ilya Kasnacheev


This is a bizzare twist on IGNITE-8021

Imagine you have a cache "tbl" created by public API with corresponding table 
"tbl".TBL. You also have PDS. Drop this cache, CREATE TABLE TBL with 
corresponding SQL_PUBLIC_TBL cache. It would work, but if you shut down cluster 
and try to bring it online, it will fail to activate:

{code}SchemaOperationException [code=3, msg=Table already exists: TBL]{code}






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8106) In control.sh -active, exception will be eaten and not displayed

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422249#comment-16422249
 ] 

Ilya Kasnacheev commented on IGNITE-8106:
-

Discovered by [~dmekhanikov]

> In control.sh -active, exception will be eaten and not displayed
> 
>
> Key: IGNITE-8106
> URL: https://issues.apache.org/jira/browse/IGNITE-8106
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Priority: Minor
>
> Here is the relevant code from GridChangeStateCommandHandler:
> {code}
> sb.a(e.getMessage()).a("\n").a("suppressed: \n");
> for (Throwable t:e.getSuppressed())
> sb.a(t.getMessage()).a("\n");
> {code}
> However, before that code the exception will pass through 
> IgniteUtils.convertException(), which will wrap the old 
> IgniteCheckedException with suppressed parts with a new IgniteException with 
> 0 suppressed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8106) In control.sh -active, exception will be eaten and not displayed

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-8106:
---

 Summary: In control.sh -active, exception will be eaten and not 
displayed
 Key: IGNITE-8106
 URL: https://issues.apache.org/jira/browse/IGNITE-8106
 Project: Ignite
  Issue Type: Bug
  Components: clients
Affects Versions: 2.5
Reporter: Ilya Kasnacheev


Here is the relevant code from GridChangeStateCommandHandler:
{code}
sb.a(e.getMessage()).a("\n").a("suppressed: \n");

for (Throwable t:e.getSuppressed())
sb.a(t.getMessage()).a("\n");
{code}

However, before that code the exception will pass through 
IgniteUtils.convertException(), which will wrap the old IgniteCheckedException 
with suppressed parts with a new IgniteException with 0 suppressed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[Ryabov Dmitrii (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422247#comment-16422247
 ] 

Ryabov Dmitrii commented on IGNITE-6802:


[~dpavlov], here is TC run [1] for PDS indexing for 23 march. Do I need to 
refresh it?

[1] 
https://ci.ignite.apache.org/viewLog.html?buildId=1153759=buildResultsDiv=IgniteTests24Java8_IgnitePdsIndexing

> NullPointerException when WAL store and WAL archive paths are same 
> ---
>
> Key: IGNITE-6802
> URL: https://issues.apache.org/jira/browse/IGNITE-6802
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Alexey Kukushkin
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie, test, usability
> Fix For: 2.5
>
>
> Configuring WAL store and WAL archive paths to be the same results in 
> NullPointerException. We should display a meaningful error about the 
> misconfiguration instead.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
> The thread includes the reproducer code and stack trace. I was able to 
> reproduce the issue with today's (31-Oct-2017) Apache master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[Ryabov Dmitrii (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryabov Dmitrii updated IGNITE-6802:
---
Labels: newbie test usability  (was: newbie usability)

> NullPointerException when WAL store and WAL archive paths are same 
> ---
>
> Key: IGNITE-6802
> URL: https://issues.apache.org/jira/browse/IGNITE-6802
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Alexey Kukushkin
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie, test, usability
> Fix For: 2.5
>
>
> Configuring WAL store and WAL archive paths to be the same results in 
> NullPointerException. We should display a meaningful error about the 
> misconfiguration instead.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
> The thread includes the reproducer code and stack trace. I was able to 
> reproduce the issue with today's (31-Oct-2017) Apache master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-5504) Failures in GridTcpCommunicationSpiRecoverySelfTest

[Ryabov Dmitrii (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422241#comment-16422241
 ] 

Ryabov Dmitrii commented on IGNITE-5504:


Ok for me.

> Failures in GridTcpCommunicationSpiRecoverySelfTest
> ---
>
> Key: IGNITE-5504
> URL: https://issues.apache.org/jira/browse/IGNITE-5504
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vladimir Ozerov
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.5
>
>
> Reproducible only on TeamCity.
> Affected tests:
> {{GridTcpCommunicationSpiRecoverySelfTest.testBlockRead1}}
> {{GridTcpCommunicationSpiRecoverySelfTest.testBlockRead2}}
> {{GridTcpCommunicationSpiRecoverySelfTest.testBlockRead3}}
> Root cause:
> {code}
> [2017-06-14 18:16:30,016][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: Failed to wait for session close
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at 
> org.apache.ignite.spi.communication.tcp.GridTcpCommunicationSpiRecoverySelfTest.testBlockRead1(GridTcpCommunicationSpiRecoverySelfTest.java:333)
> 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 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1992)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:131)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1907)
> at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7963) Futures from DataStreamer.addData() fail to complete if DataStreamer.flush() is never called

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422240#comment-16422240
 ] 

Dmitriy Pavlov commented on IGNITE-7963:


[~ilyak], are test passing now?

> Futures from DataStreamer.addData() fail to complete if DataStreamer.flush() 
> is never called
> 
>
> Key: IGNITE-7963
> URL: https://issues.apache.org/jira/browse/IGNITE-7963
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>  Labels: usability
>
> DataStreamer.addData() will return futures for operation.
> Thus the naive use of DataStreamer will look like this:
> {code}
> for (Data d : data)
>  futs.add(dataStreamer.addData(d));
> for (IgniteFuture f : futs)
> f.get();
> dataStreamer.close();
> {code}
> However, this does not work. Unless flush is called (manual or otherwisE), 
> futures are not being processed. This code will likely hang on f.get().
> The solution, IMHO, is to introduce dataStreamer-flushing clause in f.get().



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-7963) Futures from DataStreamer.addData() fail to complete if DataStreamer.flush() is never called

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422240#comment-16422240
 ] 

Dmitriy Pavlov edited comment on IGNITE-7963 at 4/2/18 1:15 PM:


[~ilyak], are tests passing now?


was (Author: dpavlov):
[~ilyak], are test passing now?

> Futures from DataStreamer.addData() fail to complete if DataStreamer.flush() 
> is never called
> 
>
> Key: IGNITE-7963
> URL: https://issues.apache.org/jira/browse/IGNITE-7963
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>  Labels: usability
>
> DataStreamer.addData() will return futures for operation.
> Thus the naive use of DataStreamer will look like this:
> {code}
> for (Data d : data)
>  futs.add(dataStreamer.addData(d));
> for (IgniteFuture f : futs)
> f.get();
> dataStreamer.close();
> {code}
> However, this does not work. Unless flush is called (manual or otherwisE), 
> futures are not being processed. This code will likely hang on f.get().
> The solution, IMHO, is to introduce dataStreamer-flushing clause in f.get().



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422238#comment-16422238
 ] 

Dmitriy Pavlov commented on IGNITE-6802:


[~SomeFire], ok, could you share TC run for this new suite (PDS indexing) and 
set Patch Available

You could aslo change issue type to 'test'.

> NullPointerException when WAL store and WAL archive paths are same 
> ---
>
> Key: IGNITE-6802
> URL: https://issues.apache.org/jira/browse/IGNITE-6802
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Alexey Kukushkin
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie, usability
> Fix For: 2.5
>
>
> Configuring WAL store and WAL archive paths to be the same results in 
> NullPointerException. We should display a meaningful error about the 
> misconfiguration instead.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
> The thread includes the reproducer code and stack trace. I was able to 
> reproduce the issue with today's (31-Oct-2017) Apache master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6630) Incorrect time units of average transaction commit/rollback duration cache metrics.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422232#comment-16422232
 ] 

ASF GitHub Bot commented on IGNITE-6630:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/2854


> Incorrect time units of average transaction commit/rollback duration cache 
> metrics.
> ---
>
> Key: IGNITE-6630
> URL: https://issues.apache.org/jira/browse/IGNITE-6630
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
>  Labels: metrics, newbie
> Fix For: 2.5
>
>
> AverageTxCommitTime and AverageTxRollbackTime metrics in CacheMetrics counts 
> in milliseconds instead of microseconds as pointed in javadoc.
> Simple junit reproducer:
> {code:java}
> public class CacheMetricsTxAvgTimeTest extends GridCommonAbstractTest {
> /** */
> private  CacheConfiguration cacheConfiguration(String name) {
> CacheConfiguration cacheConfiguration = new 
> CacheConfiguration<>(name);
> cacheConfiguration.setCacheMode(CacheMode.PARTITIONED);
> cacheConfiguration.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheConfiguration.setStatisticsEnabled(true);
> return cacheConfiguration;
> }
> /** */
> public void testTxCommitDuration() throws Exception {
> try ( Ignite node = startGrid(0)) {
> IgniteCache cache = 
> node.createCache(cacheConfiguration(DEFAULT_CACHE_NAME));
> try (Transaction tx = node.transactions().txStart()) {
> cache.put(1, 1);
> // Await 1 second.
> U.sleep(1_000);
> tx.commit();
> }
> // Documentation says that this metric is in microseconds.
> float commitTime = cache.metrics().getAverageTxCommitTime();
> // But this assertion will fail because it in milliseconds and 
> returns only ~1000.
> assert commitTime >= 1_000_000;
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8105) Close() while auto activate

[Alexander Belyak (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Belyak updated IGNITE-8105:
-
Attachment: FastRestartTest.java

> Close() while auto activate
> ---
>
> Key: IGNITE-8105
> URL: https://issues.apache.org/jira/browse/IGNITE-8105
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Priority: Minor
> Attachments: FastRestartTest.java
>
>
> 1) Start one node, activate, fill some data
> 2) Close node
> 3) Start node and right after start call close()
> Expected result:
> Node start and close correctly (maybe with auto activate/deactivate, maybe 
> without)
> Actual result:
> Node start and throw java.nio.channels.ClosedByInterruptException in 
> activation process cause close() process close checkpoint file channel
> Expection is:
> {noformat}
> [2018-04-02 
> 19:57:27,831][ERROR][exchange-worker-#94%srv1%][GridCachePartitionExchangeManager]
>  Failed to wait for completion of partition map exchange (preloading will not 
> start): GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryCustomEvent 
> [customMsg=null, affTopVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=a9fa729f-613f-496b-8e7c-e53142817226, addrs=[0:0:0:0:0:0:0:1%lo, 
> 10.0.3.1, 10.38.184.66, 10.42.1.107, 127.0.0.1, 172.17.0.1], 
> sockAddrs=[/10.38.184.66:47500, /172.17.0.1:47500, /0:0:0:0:0:0:0:1%lo:47500, 
> /10.0.3.1:47500, /10.42.1.107:47500, /127.0.0.1:47500], discPort=47500, 
> order=1, intOrder=1, lastExchangeTime=1522673846477, loc=true, 
> ver=2.4.0#19700101-sha1:, isClient=false], topVer=1, 
> nodeId8=a9fa729f, msg=null, type=DISCOVERY_CUSTOM_EVT, 
> tstamp=1522673847732]], crd=TcpDiscoveryNode 
> [id=a9fa729f-613f-496b-8e7c-e53142817226, addrs=[0:0:0:0:0:0:0:1%lo, 
> 10.0.3.1, 10.38.184.66, 10.42.1.107, 127.0.0.1, 172.17.0.1], 
> sockAddrs=[/10.38.184.66:47500, /172.17.0.1:47500, /0:0:0:0:0:0:0:1%lo:47500, 
> /10.0.3.1:47500, /10.42.1.107:47500, /127.0.0.1:47500], discPort=47500, 
> order=1, intOrder=1, lastExchangeTime=1522673846477, loc=true, 
> ver=2.4.0#19700101-sha1:, isClient=false], 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent [customMsg=null, 
> affTopVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=a9fa729f-613f-496b-8e7c-e53142817226, addrs=[0:0:0:0:0:0:0:1%lo, 
> 10.0.3.1, 10.38.184.66, 10.42.1.107, 127.0.0.1, 172.17.0.1], 
> sockAddrs=[/10.38.184.66:47500, /172.17.0.1:47500, /0:0:0:0:0:0:0:1%lo:47500, 
> /10.0.3.1:47500, /10.42.1.107:47500, /127.0.0.1:47500], discPort=47500, 
> order=1, intOrder=1, lastExchangeTime=1522673846477, loc=true, 
> ver=2.4.0#19700101-sha1:, isClient=false], topVer=1, 
> nodeId8=a9fa729f, msg=null, type=DISCOVERY_CUSTOM_EVT, 
> tstamp=1522673847732]], nodeId=a9fa729f, evt=DISCOVERY_CUSTOM_EVT], 
> added=true, initFut=GridFutureAdapter [ignoreInterrupts=false, state=DONE, 
> res=false, hash=791289709], init=false, lastVer=null, 
> partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=1, minorTopVer=1], futures=[ExplicitLockReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], futures=[]], 
> TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
> futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=1, minorTopVer=1], futures=[]], DataStreamerReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], futures=[, 
> exchActions=null, affChangeMsg=null, initTs=1522673847742, 
> centralizedAff=false, changeGlobalStateE=class o.a.i.IgniteCheckedException: 
> Failed to read checkpoint pointer from marker file: 
> /tmp/test/srv1/db/cons_srv1/cp/1522673842894-84776dc9-6fac-4aa0-804c-f56cbee68c12-START.bin,
>  done=true, state=CRD, evtLatch=0, remaining=[], super=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=class o.a.i.IgniteCheckedException: 
> Failed to read checkpoint pointer from marker file: 
> /tmp/test/srv1/db/cons_srv1/cp/1522673842894-84776dc9-6fac-4aa0-804c-f56cbee68c12-START.bin,
>  hash=1311860231]]
> class org.apache.ignite.IgniteCheckedException: Failed to read checkpoint 
> pointer from marker file: 
> /tmp/test/srv1/db/cons_srv1/cp/1522673842894-84776dc9-6fac-4aa0-804c-f56cbee68c12-START.bin
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readPointer(GridCacheDatabaseSharedManager.java:1794)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointStatus(GridCacheDatabaseSharedManager.java:1764)
>   at 
> 

[jira] [Updated] (IGNITE-8104) Proper toString() implementation for IgniteConfiguration properties

[Ivan Fedotov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-8104:
-
Environment: (was: In continuing of ticket Ignite-5798 'Logging Ignite 
configuration at startup' [1] it's necessary to make proper {{toString()}} 
implementation for every every logged configuration component, such the every 
meaningful property should be properly logged.

[1]https://issues.apache.org/jira/browse/IGNITE-5798)

> Proper toString() implementation for IgniteConfiguration properties
> ---
>
> Key: IGNITE-8104
> URL: https://issues.apache.org/jira/browse/IGNITE-8104
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8105) Close() while auto activate

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-8105:


 Summary: Close() while auto activate
 Key: IGNITE-8105
 URL: https://issues.apache.org/jira/browse/IGNITE-8105
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.4
Reporter: Alexander Belyak


1) Start one node, activate, fill some data
2) Close node
3) Start node and right after start call close()
Expected result:
Node start and close correctly (maybe with auto activate/deactivate, maybe 
without)
Actual result:
Node start and throw java.nio.channels.ClosedByInterruptException in activation 
process cause close() process close checkpoint file channel
Expection is:
{noformat}
[2018-04-02 
19:57:27,831][ERROR][exchange-worker-#94%srv1%][GridCachePartitionExchangeManager]
 Failed to wait for completion of partition map exchange (preloading will not 
start): GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryCustomEvent 
[customMsg=null, affTopVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=a9fa729f-613f-496b-8e7c-e53142817226, addrs=[0:0:0:0:0:0:0:1%lo, 10.0.3.1, 
10.38.184.66, 10.42.1.107, 127.0.0.1, 172.17.0.1], 
sockAddrs=[/10.38.184.66:47500, /172.17.0.1:47500, /0:0:0:0:0:0:0:1%lo:47500, 
/10.0.3.1:47500, /10.42.1.107:47500, /127.0.0.1:47500], discPort=47500, 
order=1, intOrder=1, lastExchangeTime=1522673846477, loc=true, 
ver=2.4.0#19700101-sha1:, isClient=false], topVer=1, nodeId8=a9fa729f, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1522673847732]], 
crd=TcpDiscoveryNode [id=a9fa729f-613f-496b-8e7c-e53142817226, 
addrs=[0:0:0:0:0:0:0:1%lo, 10.0.3.1, 10.38.184.66, 10.42.1.107, 127.0.0.1, 
172.17.0.1], sockAddrs=[/10.38.184.66:47500, /172.17.0.1:47500, 
/0:0:0:0:0:0:0:1%lo:47500, /10.0.3.1:47500, /10.42.1.107:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1522673846477, loc=true, ver=2.4.0#19700101-sha1:, 
isClient=false], exchId=GridDhtPartitionExchangeId 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
discoEvt=DiscoveryCustomEvent [customMsg=null, 
affTopVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=a9fa729f-613f-496b-8e7c-e53142817226, addrs=[0:0:0:0:0:0:0:1%lo, 10.0.3.1, 
10.38.184.66, 10.42.1.107, 127.0.0.1, 172.17.0.1], 
sockAddrs=[/10.38.184.66:47500, /172.17.0.1:47500, /0:0:0:0:0:0:0:1%lo:47500, 
/10.0.3.1:47500, /10.42.1.107:47500, /127.0.0.1:47500], discPort=47500, 
order=1, intOrder=1, lastExchangeTime=1522673846477, loc=true, 
ver=2.4.0#19700101-sha1:, isClient=false], topVer=1, nodeId8=a9fa729f, 
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1522673847732]], nodeId=a9fa729f, 
evt=DISCOVERY_CUSTOM_EVT], added=true, initFut=GridFutureAdapter 
[ignoreInterrupts=false, state=DONE, res=false, hash=791289709], init=false, 
lastVer=null, partReleaseFut=PartitionReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
futures=[ExplicitLockReleaseFuture [topVer=AffinityTopologyVersion [topVer=1, 
minorTopVer=1], futures=[]], TxReleaseFuture [topVer=AffinityTopologyVersion 
[topVer=1, minorTopVer=1], futures=[]], AtomicUpdateReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], futures=[]], 
DataStreamerReleaseFuture [topVer=AffinityTopologyVersion [topVer=1, 
minorTopVer=1], futures=[, exchActions=null, affChangeMsg=null, 
initTs=1522673847742, centralizedAff=false, changeGlobalStateE=class 
o.a.i.IgniteCheckedException: Failed to read checkpoint pointer from marker 
file: 
/tmp/test/srv1/db/cons_srv1/cp/1522673842894-84776dc9-6fac-4aa0-804c-f56cbee68c12-START.bin,
 done=true, state=CRD, evtLatch=0, remaining=[], super=GridFutureAdapter 
[ignoreInterrupts=false, state=DONE, res=class o.a.i.IgniteCheckedException: 
Failed to read checkpoint pointer from marker file: 
/tmp/test/srv1/db/cons_srv1/cp/1522673842894-84776dc9-6fac-4aa0-804c-f56cbee68c12-START.bin,
 hash=1311860231]]
class org.apache.ignite.IgniteCheckedException: Failed to read checkpoint 
pointer from marker file: 
/tmp/test/srv1/db/cons_srv1/cp/1522673842894-84776dc9-6fac-4aa0-804c-f56cbee68c12-START.bin
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readPointer(GridCacheDatabaseSharedManager.java:1794)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointStatus(GridCacheDatabaseSharedManager.java:1764)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1321)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1114)
at 

[jira] [Updated] (IGNITE-8104) Proper toString() implementation for IgniteConfiguration properties

[Ivan Fedotov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-8104:
-
Description: 
In continuing of ticket Ignite-5798 'Logging Ignite configuration at startup' 
[1] it's necessary to make proper {{toString()}} implementation for every every 
logged configuration component, such the every meaningful property should be 
properly logged.

[1]https://issues.apache.org/jira/browse/IGNITE-5798

> Proper toString() implementation for IgniteConfiguration properties
> ---
>
> Key: IGNITE-8104
> URL: https://issues.apache.org/jira/browse/IGNITE-8104
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Priority: Major
>
> In continuing of ticket Ignite-5798 'Logging Ignite configuration at startup' 
> [1] it's necessary to make proper {{toString()}} implementation for every 
> every logged configuration component, such the every meaningful property 
> should be properly logged.
> [1]https://issues.apache.org/jira/browse/IGNITE-5798



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (IGNITE-5798) Logging Ignite configuration at startup

[Ivan Fedotov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov closed IGNITE-5798.


IgniteConfiguration is logging at startup.

> Logging Ignite configuration at startup
> ---
>
> Key: IGNITE-5798
> URL: https://issues.apache.org/jira/browse/IGNITE-5798
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexandr Kuramshin
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: easyfix, newbie
> Fix For: 2.5
>
>
> I've found that IgniteConfiguration is not logged even when 
> -DIGNITE_QUIET=false
> When we starting Ignite with path to the xml, or InputStream, we have to 
> ensure, that all configuration options were properly read. And also we would 
> like to know actual values of uninitialized configuration properties (default 
> values), which will be set only after Ignite get started.
> Monitoring tools, like Visor or WebConsole, do not show all configuration 
> options. And even though they will be updated to show all properties, when 
> new configuration options appear, then tools update will be needed.
> Logging IgniteConfiguration at startup gives a possibility to ensure that the 
> right grid configuration has been applied and leads to better user support 
> based on log analyzing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-5798) Logging Ignite configuration at startup

[Ivan Fedotov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1646#comment-1646
 ] 

Ivan Fedotov commented on IGNITE-5798:
--

[~ein], ok, I made ticket for it - 
https://issues.apache.org/jira/browse/IGNITE-8104.

> Logging Ignite configuration at startup
> ---
>
> Key: IGNITE-5798
> URL: https://issues.apache.org/jira/browse/IGNITE-5798
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexandr Kuramshin
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: easyfix, newbie
> Fix For: 2.5
>
>
> I've found that IgniteConfiguration is not logged even when 
> -DIGNITE_QUIET=false
> When we starting Ignite with path to the xml, or InputStream, we have to 
> ensure, that all configuration options were properly read. And also we would 
> like to know actual values of uninitialized configuration properties (default 
> values), which will be set only after Ignite get started.
> Monitoring tools, like Visor or WebConsole, do not show all configuration 
> options. And even though they will be updated to show all properties, when 
> new configuration options appear, then tools update will be needed.
> Logging IgniteConfiguration at startup gives a possibility to ensure that the 
> right grid configuration has been applied and leads to better user support 
> based on log analyzing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8104) Proper toString() implementation for IgniteConfiguration properties

[Ivan Fedotov (JIRA)]

Ivan Fedotov created IGNITE-8104:


 Summary: Proper toString() implementation for IgniteConfiguration 
properties
 Key: IGNITE-8104
 URL: https://issues.apache.org/jira/browse/IGNITE-8104
 Project: Ignite
  Issue Type: Improvement
 Environment: In continuing of ticket Ignite-5798 'Logging Ignite 
configuration at startup' [1] it's necessary to make proper {{toString()}} 
implementation for every every logged configuration component, such the every 
meaningful property should be properly logged.

[1]https://issues.apache.org/jira/browse/IGNITE-5798
Reporter: Ivan Fedotov






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (IGNITE-5798) Logging Ignite configuration at startup

[Ivan Fedotov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov resolved IGNITE-5798.
--
Resolution: Fixed

Ignite Configuration is logging at startup [1]

[1]https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L804

> Logging Ignite configuration at startup
> ---
>
> Key: IGNITE-5798
> URL: https://issues.apache.org/jira/browse/IGNITE-5798
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexandr Kuramshin
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: easyfix, newbie
> Fix For: 2.5
>
>
> I've found that IgniteConfiguration is not logged even when 
> -DIGNITE_QUIET=false
> When we starting Ignite with path to the xml, or InputStream, we have to 
> ensure, that all configuration options were properly read. And also we would 
> like to know actual values of uninitialized configuration properties (default 
> values), which will be set only after Ignite get started.
> Monitoring tools, like Visor or WebConsole, do not show all configuration 
> options. And even though they will be updated to show all properties, when 
> new configuration options appear, then tools update will be needed.
> Logging IgniteConfiguration at startup gives a possibility to ensure that the 
> right grid configuration has been applied and leads to better user support 
> based on log analyzing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7904) ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() throws IgniteException

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1642#comment-1642
 ] 

Ilya Kasnacheev commented on IGNITE-7904:
-

[~slukyanov] looks good to me now!

> ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() 
> throws IgniteException
> -
>
> Key: IGNITE-7904
> URL: https://issues.apache.org/jira/browse/IGNITE-7904
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
>
> ComputeTask.result() javadoc says: "Throws: IgniteException - If handling a 
> job result caused an error effectively rejecting a failover. This exception 
> will be thrown out of ComputeTaskFuture.get() method."
> However, GridFutureAdapter calls IgniteUtils.cast(Throwable) on the exception 
> before throwing it from get(), and the latter method trims the stack trace to 
> the first occurence of an IgniteCheckedException. Because of that, get() 
> throws not the IgniteException thrown from the ComputeTask.result() but one 
> of its causes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)