[jira] [Commented] (IGNITE-11942) IGFS and Hadoop Accelerator Discontinuation

2020-04-13 Thread Aleksey Zinoviev (Jira)


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

Aleksey Zinoviev commented on IGNITE-11942:
---

Yes, we could remove, no blockers now!




> IGFS and Hadoop Accelerator Discontinuation
> ---
>
> Key: IGNITE-11942
> URL: https://issues.apache.org/jira/browse/IGNITE-11942
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis A. Magda
>Assignee: Anton Kalashnikov
>Priority: Blocker
> Fix For: 2.9
>
>
> The community has voted for the following decision:
> * IGFS and In-Memory Hadoop Accelerator components are to be discontinued and 
> no longer supported by the community 
> * The existing source code of IGFS and In-Memory Hadoop Accelerator is to be 
> removed from Ignite master. Before that, a special branch like 
> "ignite-igfs-and-hadoop-accelerator" to be forked off the master in order to 
> preserve the sources in Git history for those who might need it. 
> The voting thread:
> http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Complete-Discontinuation-of-IGFS-and-Hadoop-Accelerator-td42405.html
> Once the changes are made for Ignite 2.8, please contact Denis Magda to 
> update a public documentation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (IGNITE-12852) Comma in field is not supported by COPY command

2020-04-13 Thread YuJue Li (Jira)


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

YuJue Li reassigned IGNITE-12852:
-

Assignee: YuJue Li  (was: Anton Kurbanov)

> Comma in field is not supported by COPY command
> ---
>
> Key: IGNITE-12852
> URL: https://issues.apache.org/jira/browse/IGNITE-12852
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: YuJue Li
>Assignee: YuJue Li
>Priority: Critical
> Fix For: 2.8.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); 
>  
> a.csv: 
> 1,"a,b",2 
>  
> COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; 
>  
> The copy command fails because there is a comma in the second field,but this 
> is a fully legal and compliant CSV format



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (IGNITE-11302) idleConnectionTimeout TcpComm different on server and client (client default > server custom) lead to wait until client timeout on server side

2020-04-13 Thread Dmitriy Sorokin (Jira)


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

Dmitriy Sorokin reassigned IGNITE-11302:


Assignee: Dmitriy Sorokin

> idleConnectionTimeout TcpComm different on server and client (client default 
> > server custom) lead to wait until client timeout on server side
> --
>
> Key: IGNITE-11302
> URL: https://issues.apache.org/jira/browse/IGNITE-11302
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: ARomantsov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> Server config:
> 
>  class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
> 
> 
> 
> Client config
> 
>  class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
> 
> 
> Server wait until default idleConnectionTimeout (10 m) for client fail.
> If both config with idleConnectionTimeout=1 s - ignite worked according to 
> config



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-11862) Cache stopping on supplier during rebalance causes NPE and supplying failure.

2020-04-13 Thread Dmitriy Sorokin (Jira)


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

Dmitriy Sorokin resolved IGNITE-11862.
--
Resolution: Cannot Reproduce

> Cache stopping on supplier during rebalance causes NPE and supplying failure.
> -
>
> Key: IGNITE-11862
> URL: https://issues.apache.org/jira/browse/IGNITE-11862
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> {noformat}
> [21:12:14]W: [org.apache.ignite:ignite-core] [2019-05-20 
> 21:12:14,376][ERROR][sys-#60310%distributed.CacheParallelStartTest0%][GridDhtPartitionSupplier]
>  Failed to continue supplying [grp=static-cache-group45, 
> demander=ed1c0109-8721-4cd8-80d9-d36e8251, top
> Ver=AffinityTopologyVersion [topVer=2, minorTopVer=0], topic=0]
> [21:12:14]W: [org.apache.ignite:ignite-core] java.lang.NullPointerException
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.CacheGroupContext.addRebalanceSupplyEvent(CacheGroupContext.java:525)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:422)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:397)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:455)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:440)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1141)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1706)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1566)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2795)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1523)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4500(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1492)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> java.lang.Thread.run(Thread.java:748)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Reopened] (IGNITE-11862) Cache stopping on supplier during rebalance causes NPE and supplying failure.

2020-04-13 Thread Dmitriy Sorokin (Jira)


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

Dmitriy Sorokin reopened IGNITE-11862:
--

> Cache stopping on supplier during rebalance causes NPE and supplying failure.
> -
>
> Key: IGNITE-11862
> URL: https://issues.apache.org/jira/browse/IGNITE-11862
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> {noformat}
> [21:12:14]W: [org.apache.ignite:ignite-core] [2019-05-20 
> 21:12:14,376][ERROR][sys-#60310%distributed.CacheParallelStartTest0%][GridDhtPartitionSupplier]
>  Failed to continue supplying [grp=static-cache-group45, 
> demander=ed1c0109-8721-4cd8-80d9-d36e8251, top
> Ver=AffinityTopologyVersion [topVer=2, minorTopVer=0], topic=0]
> [21:12:14]W: [org.apache.ignite:ignite-core] java.lang.NullPointerException
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.CacheGroupContext.addRebalanceSupplyEvent(CacheGroupContext.java:525)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:422)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:397)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:455)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:440)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1141)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1706)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1566)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2795)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1523)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4500(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1492)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> java.lang.Thread.run(Thread.java:748)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-12775) Update URLs and other content on Ignite downloads page

2020-04-13 Thread Denis A. Magda (Jira)


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

Denis A. Magda edited comment on IGNITE-12775 at 4/13/20, 11:44 PM:


[~mmuzaf], thanks for taking my feedback into consideration. The changes look 
good to me. Let's wait while Peter responds in regards to the GCE and then feel 
free to merge the changes.

Please ping me once the changes get to the master, I will do a final check of 
the live website. Just email or Slack me privately.


was (Author: dmagda):
[~mmuzaf], thanks for taking my feedback into consideration. The changes look 
good to me. Let's wait while Peter responds in regards to the GCE and then feel 
free to merge the changes.

Please ping me once the changes get to the master, I'd like to do a quick check 
of a live website. Just email or Slack me privately.

> Update URLs and other content on Ignite downloads page
> --
>
> Key: IGNITE-12775
> URL: https://issues.apache.org/jira/browse/IGNITE-12775
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis A. Magda
>Assignee: Maxim Muzafarov
>Priority: Blocker
> Fix For: 2.8.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As per ASF INFRA advise/request, the downloads page needs to be adjusted this 
> way:
> * PGP/SHA512 stuff should refer to downloads.apache.org instead of 
> www.apache.org/dist/ 
> * I could not find a link to the KEYS file.
> * The page links to NIGHTLY builds; these must not be promoted to the
> general public
> * the page does not describe how to verify downloads, and only
> mentions verification for binary downloads. Users should be urged to
> verify all downloads.
> * the 'pgp' link for apache-ignite-fabric-2.4.0-bin.zip points to the
> zip file, likewise for apache-ignite-fabric-2.3.0-bin.zip
> * apache-ignite-1.3.0-src.zip and earlier are incubating releases,
> however the link text does not make this clear.
> * the docker and cloud image links don't have sigs or hashes



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-12775) Update URLs and other content on Ignite downloads page

2020-04-13 Thread Denis A. Magda (Jira)


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

Denis A. Magda edited comment on IGNITE-12775 at 4/13/20, 11:43 PM:


[~mmuzaf], thanks for taking my feedback into consideration. The changes look 
good to me. Let's wait while Peter responds in regards to the GCE and then feel 
free to merge the changes.

Please ping me once the changes get to the master, I'd like to do a quick check 
of a live website. Just email or Slack me privately.


was (Author: dmagda):
[~mmuzaf], thanks for taking my feedback into consideration. The changes look 
good to me. Let's wait while Peter responds in regards to the GCE and then feel 
free to merge the changes.

Please ping me while the changes get to the master, I'd like to do a quick 
check of a live website. Just email or Slack me privately.

> Update URLs and other content on Ignite downloads page
> --
>
> Key: IGNITE-12775
> URL: https://issues.apache.org/jira/browse/IGNITE-12775
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis A. Magda
>Assignee: Maxim Muzafarov
>Priority: Blocker
> Fix For: 2.8.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As per ASF INFRA advise/request, the downloads page needs to be adjusted this 
> way:
> * PGP/SHA512 stuff should refer to downloads.apache.org instead of 
> www.apache.org/dist/ 
> * I could not find a link to the KEYS file.
> * The page links to NIGHTLY builds; these must not be promoted to the
> general public
> * the page does not describe how to verify downloads, and only
> mentions verification for binary downloads. Users should be urged to
> verify all downloads.
> * the 'pgp' link for apache-ignite-fabric-2.4.0-bin.zip points to the
> zip file, likewise for apache-ignite-fabric-2.3.0-bin.zip
> * apache-ignite-1.3.0-src.zip and earlier are incubating releases,
> however the link text does not make this clear.
> * the docker and cloud image links don't have sigs or hashes



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12775) Update URLs and other content on Ignite downloads page

2020-04-13 Thread Denis A. Magda (Jira)


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

Denis A. Magda commented on IGNITE-12775:
-

[~mmuzaf], thanks for taking my feedback into consideration. The changes look 
good to me. Let's wait while Peter responds in regards to the GCE and then feel 
free to merge the changes.

Please ping me while the changes get to the master, I'd like to do a quick 
check of a live website. Just email or Slack me privately.

> Update URLs and other content on Ignite downloads page
> --
>
> Key: IGNITE-12775
> URL: https://issues.apache.org/jira/browse/IGNITE-12775
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis A. Magda
>Assignee: Maxim Muzafarov
>Priority: Blocker
> Fix For: 2.8.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As per ASF INFRA advise/request, the downloads page needs to be adjusted this 
> way:
> * PGP/SHA512 stuff should refer to downloads.apache.org instead of 
> www.apache.org/dist/ 
> * I could not find a link to the KEYS file.
> * The page links to NIGHTLY builds; these must not be promoted to the
> general public
> * the page does not describe how to verify downloads, and only
> mentions verification for binary downloads. Users should be urged to
> verify all downloads.
> * the 'pgp' link for apache-ignite-fabric-2.4.0-bin.zip points to the
> zip file, likewise for apache-ignite-fabric-2.3.0-bin.zip
> * apache-ignite-1.3.0-src.zip and earlier are incubating releases,
> however the link text does not make this clear.
> * the docker and cloud image links don't have sigs or hashes



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash

2020-04-13 Thread Dmitriy Sorokin (Jira)


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

Dmitriy Sorokin resolved IGNITE-8625.
-
Resolution: Cannot Reproduce

> Dynamic SQL index recreate after cache clear may result in AssertionError or 
> JVM crash
> --
>
> Key: IGNITE-8625
> URL: https://issues.apache.org/jira/browse/IGNITE-8625
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence, sql
>Reporter: Ivan Rakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, sql-stability
> Fix For: 2.9, 2.8.1
>
> Attachments: dyn_idx_reproducer.patch
>
>
> After recreation of previously dropped SQL index (in persistent mode), root 
> page of new index B+ tree may contain links to data entries from previous 
> index tree. If these entries were removed or relocated to another data page, 
> attempt to dereference these links may throw AssertionError or even cause JVM 
> crash.
> Patch with reproducer is attached.
> P.S. Please note that with IGNITE-4958 fix old invalid links may refer to 
> non-data page - it might have been recycled into page with any other type. 
> Such case will cause AssertionError on page read lock attempt. Rolling back 
> IGNITE-4958 may help with debugging.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash

2020-04-13 Thread Dmitriy Sorokin (Jira)


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

Dmitriy Sorokin commented on IGNITE-8625:
-

I investigated this issue using the attached reproducer and ready to list 
several facts:

1. Before the fix IGNITE-4958 (change {{0bdfa20c}}) the test failed with AE on 
code line
{code:java}
assert len >= 0;
{code}
of method {{PageUtils#getBytes(long, int, int)}}, sometimes causing the JVM 
crash on further execution;

2. After the fix IGNITE-4958 till the IGNITE-12061 (change {{dde81742}}) the 
test failed with AE on code line
{code:java}
assert pageAddr != 0L : nextLink;
{code}
of method {{CacheDataRowAdapter#initFromLink(CacheGroupContext, 
GridCacheSharedContext, PageMemory, RowData)}} 
({{CacheDataRowAdapter#doInitFromLink(...)}} since the fix IGNITE-10798, change 
{{bc209d08}});

3. Finally, since the fix IGNITE-12061 till the current master branch the test 
stopped falling, so I think that this issue was fixed too.

> Dynamic SQL index recreate after cache clear may result in AssertionError or 
> JVM crash
> --
>
> Key: IGNITE-8625
> URL: https://issues.apache.org/jira/browse/IGNITE-8625
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence, sql
>Reporter: Ivan Rakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, sql-stability
> Fix For: 2.9, 2.8.1
>
> Attachments: dyn_idx_reproducer.patch
>
>
> After recreation of previously dropped SQL index (in persistent mode), root 
> page of new index B+ tree may contain links to data entries from previous 
> index tree. If these entries were removed or relocated to another data page, 
> attempt to dereference these links may throw AssertionError or even cause JVM 
> crash.
> Patch with reproducer is attached.
> P.S. Please note that with IGNITE-4958 fix old invalid links may refer to 
> non-data page - it might have been recycled into page with any other type. 
> Such case will cause AssertionError on page read lock attempt. Rolling back 
> IGNITE-4958 may help with debugging.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-11942) IGFS and Hadoop Accelerator Discontinuation

2020-04-13 Thread Denis A. Magda (Jira)


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

Denis A. Magda commented on IGNITE-11942:
-

Removed IGFS and Hadoop Accelerator from the documentation navigation tree. The 
pages were not removed physically but made hidden. This will let capturing 
traffic from searches and point out to the page describing how to accelerate 
Hadoop with Ignite properly: 
https://ignite.apache.org/use-cases/hadoop-acceleration.html

Those who will land on those pages will see the following text in the header of 
the hidden pages:
_IGFS and Hadoop accelerator are to be discontinued soon: 
https://issues.apache.org/jira/browse/IGNITE-11942
Contact the Ignite community for alternate solutions. Some of the solutions 
will be documented later.​ _

[~zaleslaw], can we proceed with the IGFS and Accelerator removal from the 
master? Guess, the TF integration was the only blocker.

> IGFS and Hadoop Accelerator Discontinuation
> ---
>
> Key: IGNITE-11942
> URL: https://issues.apache.org/jira/browse/IGNITE-11942
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis A. Magda
>Assignee: Anton Kalashnikov
>Priority: Blocker
> Fix For: 2.9
>
>
> The community has voted for the following decision:
> * IGFS and In-Memory Hadoop Accelerator components are to be discontinued and 
> no longer supported by the community 
> * The existing source code of IGFS and In-Memory Hadoop Accelerator is to be 
> removed from Ignite master. Before that, a special branch like 
> "ignite-igfs-and-hadoop-accelerator" to be forked off the master in order to 
> preserve the sources in Git history for those who might need it. 
> The voting thread:
> http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Complete-Discontinuation-of-IGFS-and-Hadoop-Accelerator-td42405.html
> Once the changes are made for Ignite 2.8, please contact Denis Magda to 
> update a public documentation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

2020-04-13 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin updated IGNITE-12894:
--
Description: 
h2. Repro Steps

Execute the below steps in default service deployment mode and in 
discovery-based service deployment mode. 
 Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to 
switch to the discovery-based service deployment mode.
 * Create a service initializing an {{IgniteAtomicService}} in method 
{{Service#init()}} and using the {{IgniteAtomicService}} in a business method.
 * Start an Ignite node with the service specified in the IgniteConfiguration
 * Invoke the service's business method on the Ignite node

h3. Actual Result
h4. In Default Service Deployment Mode

Deadlock on the business method invocation
h4. In Discovery-Based Service Deployment Mode

The method invocation fails with {{IgniteException: Failed to find deployed 
service: IgniteTestService}}
h2. Reproducer
h3. Test.java
{code:java}
public interface Test {
String sayHello(String name);
}
{code}
h3. IgniteTestService.java
{code:java}
public class IgniteTestService implements Test, Service {
private @IgniteInstanceResource Ignite ignite;
private IgniteAtomicSequence seq;

@Override public void cancel(ServiceContext ctx) {
}

@Override public void init(ServiceContext ctx) throws InterruptedException {
seq = ignite.atomicSequence("TestSeq", 0, true);
}

@Override public void execute(ServiceContext ctx) {
}

@Override public String sayHello(String name) {
return "Hello, " + name + "! #" + seq.getAndIncrement();
}
}
{code}
h3. Reproducer.java
{code:java}
public class Reproducer {
public static void main(String[] args) {
IgniteConfiguration igniteCfg = new IgniteConfiguration()
.setServiceConfiguration(
new ServiceConfiguration()
.setName(IgniteTestService.class.getSimpleName())
.setMaxPerNodeCount(1)
.setTotalCount(0)
.setService(new IgniteTestService())
)
.setDiscoverySpi(
new TcpDiscoverySpi()
.setIpFinder(new 
TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
);

try (Ignite ignite = Ignition.start(igniteCfg)) {

ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
Test.class, false)
.sayHello("World");
}
}
}
{code}
h2. Workaround

Specifying a service wait timeout solves the problem in the discovery-based 
service deployment mode (but not in the default deployment mode):
{code:java}

ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
Test.class, false, 1_000)
.sayHello("World");
{code}
This workaround cannot be used in Ignite.NET clients since .NET 
{{GetServiceProxy}} API does not support the service wait timeout, which is 
hard-coded to 0 on the server side.
h2. Full Exception in Discovery-Based Service Deployment Mode
{noformat}
[01:08:54,653][SEVERE][services-deployment-worker-#52][IgniteServiceProcessor] 
Failed to initialize service (service will not be deployed): IgniteTestService
class org.apache.ignite.IgniteInterruptedException: Got interrupted while 
waiting for future to complete.
at 
org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:888)
at 
org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:886)
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1062)
at 
org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3999)
at 
org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3985)
at Sandbox.Net.IgniteTestService.init(IgniteTestService.java:17)
at 
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.redeploy(IgniteServiceProcessor.java:1188)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.lambda$processDeploymentActions$5(ServiceDeploymentTask.java:318)
at java.base/java.util.HashMap.forEach(HashMap.java:1336)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.processDeploymentActions(ServiceDeploymentTask.java:302)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.init(ServiceDeploymentTask.java:262)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentManager$ServicesDeploymentWorker.body(ServiceDeploymentManager.java:475)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.base/java.lang.Thread.run(Thread.java:834)
[01:08:54,712][SEVERE][exchange-worker-#42][GridDhtPartitionsExchangeFuture] 
Failed to reinitialize local partitions 

[jira] [Updated] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

2020-04-13 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin updated IGNITE-12894:
--
Description: 
h2. Repro Steps

Execute the below steps in default service deployment mode and in 
discovery-based service deployment mode. 
 Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to 
switch to the discovery-based service deployment mode.
 * Create a service initializing an IgniteAtomicService in method 
Service#init() and using the IgniteAtomicService in a business method.
 * Start an Ignite node with the service specified in the IgniteConfiguration
 * Invoke the service's business method on the Ignite node

h3. Actual Result
h4. In Default Service Deployment Mode

Deadlock on the business method invocation
h4. In Discovery-Based Service Deployment Mode

The method invocation fails with {{IgniteException: Failed to find deployed 
service: IgniteTestService}}
h2. Reproducer
h3. Test.java
{code:java}
public interface Test {
String sayHello(String name);
}
{code}
h3. IgniteTestService.java
{code:java}
public class IgniteTestService implements Test, Service {
private @IgniteInstanceResource Ignite ignite;
private IgniteAtomicSequence seq;

@Override public void cancel(ServiceContext ctx) {
}

@Override public void init(ServiceContext ctx) throws InterruptedException {
seq = ignite.atomicSequence("TestSeq", 0, true);
}

@Override public void execute(ServiceContext ctx) {
}

@Override public String sayHello(String name) {
return "Hello, " + name + "! #" + seq.getAndIncrement();
}
}
{code}
h3. Reproducer.java
{code:java}
public class Reproducer {
public static void main(String[] args) {
IgniteConfiguration igniteCfg = new IgniteConfiguration()
.setServiceConfiguration(
new ServiceConfiguration()
.setName(IgniteTestService.class.getSimpleName())
.setMaxPerNodeCount(1)
.setTotalCount(0)
.setService(new IgniteTestService())
)
.setDiscoverySpi(
new TcpDiscoverySpi()
.setIpFinder(new 
TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
);

try (Ignite ignite = Ignition.start(igniteCfg)) {

ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
Test.class, false)
.sayHello("World");
}
}
}
{code}
h2. Workaround

Specifying a service wait timeout solves the problem in the discovery-based 
service deployment mode (but not in the default deployment mode):
{code:java}

ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
Test.class, false, 1_000)
.sayHello("World");
{code}
This workaround cannot be used in Ignite.NET clients since .NET 
{{GetServiceProxy}} API does not support the service wait timeout, which is 
hard-coded to 0 on the server side.
h2. Full Exception in Discovery-Based Service Deployment Mode
{noformat}
[01:08:54,653][SEVERE][services-deployment-worker-#52][IgniteServiceProcessor] 
Failed to initialize service (service will not be deployed): IgniteTestService
class org.apache.ignite.IgniteInterruptedException: Got interrupted while 
waiting for future to complete.
at 
org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:888)
at 
org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:886)
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1062)
at 
org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3999)
at 
org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3985)
at Sandbox.Net.IgniteTestService.init(IgniteTestService.java:17)
at 
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.redeploy(IgniteServiceProcessor.java:1188)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.lambda$processDeploymentActions$5(ServiceDeploymentTask.java:318)
at java.base/java.util.HashMap.forEach(HashMap.java:1336)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.processDeploymentActions(ServiceDeploymentTask.java:302)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.init(ServiceDeploymentTask.java:262)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentManager$ServicesDeploymentWorker.body(ServiceDeploymentManager.java:475)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.base/java.lang.Thread.run(Thread.java:834)
[01:08:54,712][SEVERE][exchange-worker-#42][GridDhtPartitionsExchangeFuture] 
Failed to reinitialize local partitions (rebalancing will 

[jira] [Updated] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

2020-04-13 Thread Alexey Kukushkin (Jira)


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

Alexey Kukushkin updated IGNITE-12894:
--
Description: 
h2. Repro Steps
Execute the below steps in default service deployment mode and in 
discovery-based service deployment mode. 
Use the {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to 
switch to the discovery-based service deployment mode.
 * Create a service initializing an IgniteAtomicService in method 
Service#init() and using the IgniteAtomicService in a business method.
 * Start an Ignite node with the service specified in the IgniteConfiguration
 * Invoke the service's business method on the Ignite node

h3. Actual Result
h4. In Default Service Deployment Mode
Deadlock on the business method invocation
h4. In Discovery-Based Service Deployment Mode
The method invocation fails with {{IgniteException: Failed to find deployed 
service: IgniteTestService}}

h2. Reproducer
h3. Test.java
{code:java}
public interface Test {
String sayHello(String name);
}
{code}

h3. IgniteTestService.java
{code:java}
public class IgniteTestService implements Test, Service {
private @IgniteInstanceResource Ignite ignite;
private IgniteAtomicSequence seq;

@Override public void cancel(ServiceContext ctx) {
}

@Override public void init(ServiceContext ctx) throws InterruptedException {
seq = ignite.atomicSequence("TestSeq", 0, true);
}

@Override public void execute(ServiceContext ctx) {
}

@Override public String sayHello(String name) {
return "Hello, " + name + "! #" + seq.getAndIncrement();
}
}
{code}

h3. Reproducer.java
{code:java}
public class Reproducer {
public static void main(String[] args) {
IgniteConfiguration igniteCfg = new IgniteConfiguration()
.setServiceConfiguration(
new ServiceConfiguration()
.setName(IgniteTestService.class.getSimpleName())
.setMaxPerNodeCount(1)
.setTotalCount(0)
.setService(new IgniteTestService())
)
.setDiscoverySpi(
new TcpDiscoverySpi()
.setIpFinder(new 
TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
);

try (Ignite ignite = Ignition.start(igniteCfg)) {

ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
Test.class, false)
.sayHello("World");
}
}
}
{code}

h2. Workaround
Specifying a service wait timeout solves the problem in the discovery-based 
service deployment mode (but not in the default deployment mode):
{code:java}

ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
Test.class, false, 1_000)
.sayHello("World");
{code}

This workaround cannot be used in Ignite.NET clients since .NET 
{{GetServiceProxy}} API does not support the service wait timeout, which is 
hard-coded to 0 on the server side.

h2. Full Exception in Discovery-Based Service Deployment Mode
{noformat}
[01:08:54,653][SEVERE][services-deployment-worker-#52][IgniteServiceProcessor] 
Failed to initialize service (service will not be deployed): IgniteTestService
class org.apache.ignite.IgniteInterruptedException: Got interrupted while 
waiting for future to complete.
at 
org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:888)
at 
org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:886)
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1062)
at 
org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3999)
at 
org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3985)
at Sandbox.Net.IgniteTestService.init(IgniteTestService.java:17)
at 
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.redeploy(IgniteServiceProcessor.java:1188)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.lambda$processDeploymentActions$5(ServiceDeploymentTask.java:318)
at java.base/java.util.HashMap.forEach(HashMap.java:1336)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.processDeploymentActions(ServiceDeploymentTask.java:302)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.init(ServiceDeploymentTask.java:262)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentManager$ServicesDeploymentWorker.body(ServiceDeploymentManager.java:475)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.base/java.lang.Thread.run(Thread.java:834)
[01:08:54,712][SEVERE][exchange-worker-#42][GridDhtPartitionsExchangeFuture] 
Failed to reinitialize local partitions (rebalancing 

[jira] [Created] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

2020-04-13 Thread Alexey Kukushkin (Jira)
Alexey Kukushkin created IGNITE-12894:
-

 Summary: Cannot use IgniteAtomicSequence in Ignite services
 Key: IGNITE-12894
 URL: https://issues.apache.org/jira/browse/IGNITE-12894
 Project: Ignite
  Issue Type: Bug
  Components: compute
Affects Versions: 2.8
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


h2. Repro Steps
Execute the below steps in default service deployment mode and in 
discovery-based service deployment mode. 
Use the {{ -DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to 
switch to the discovery-based service deployment mode.
 * Create a service initializing an IgniteAtomicService in method 
Service#init() and using the IgniteAtomicService in a business method.
 * Start an Ignite node with the service specified in the IgniteConfiguration
 * Invoke the service's business method on the Ignite node

h3. Actual Result
h4. In Default Service Deployment Mode
Deadlock on the business method invocation
h4. In Discovery-Based Service Deployment Mode
The method invocation fails with {{IgniteException: Failed to find deployed 
service: IgniteTestService}}

h2. Reproducer
h3. Test.java
{code:java}
public interface Test {
String sayHello(String name);
}
{code}

h3. IgniteTestService.java
{code:java}
public class IgniteTestService implements Test, Service {
private @IgniteInstanceResource Ignite ignite;
private IgniteAtomicSequence seq;

@Override public void cancel(ServiceContext ctx) {
}

@Override public void init(ServiceContext ctx) throws InterruptedException {
seq = ignite.atomicSequence("TestSeq", 0, true);
}

@Override public void execute(ServiceContext ctx) {
}

@Override public String sayHello(String name) {
return "Hello, " + name + "! #" + seq.getAndIncrement();
}
}
{code}

h3. Reproducer.java
{code:java}
public class Reproducer {
public static void main(String[] args) {
IgniteConfiguration igniteCfg = new IgniteConfiguration()
.setServiceConfiguration(
new ServiceConfiguration()
.setName(IgniteTestService.class.getSimpleName())
.setMaxPerNodeCount(1)
.setTotalCount(0)
.setService(new IgniteTestService())
)
.setDiscoverySpi(
new TcpDiscoverySpi()
.setIpFinder(new 
TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
);

try (Ignite ignite = Ignition.start(igniteCfg)) {

ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
Test.class, false)
.sayHello("World");
}
}
}
{code}

h2. Workaround
Specifying a service wait timeout solves the problem in the discovery-based 
service deployment mode (but not in the default deployment mode):
{code:java}

ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
Test.class, false, 1_000)
.sayHello("World");
{code}

This workaround cannot be used in Ignite.NET clients since .NET 
{{GetServiceProxy}} API does not support the service wait timeout, which is 
hard-coded to 0 on the server side.

h2. Full Exception in Discovery-Based Service Deployment Mode
{noformat}
[01:08:54,653][SEVERE][services-deployment-worker-#52][IgniteServiceProcessor] 
Failed to initialize service (service will not be deployed): IgniteTestService
class org.apache.ignite.IgniteInterruptedException: Got interrupted while 
waiting for future to complete.
at 
org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:888)
at 
org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:886)
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1062)
at 
org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3999)
at 
org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3985)
at Sandbox.Net.IgniteTestService.init(IgniteTestService.java:17)
at 
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.redeploy(IgniteServiceProcessor.java:1188)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.lambda$processDeploymentActions$5(ServiceDeploymentTask.java:318)
at java.base/java.util.HashMap.forEach(HashMap.java:1336)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.processDeploymentActions(ServiceDeploymentTask.java:302)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.init(ServiceDeploymentTask.java:262)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentManager$ServicesDeploymentWorker.body(ServiceDeploymentManager.java:475)
at 

[jira] [Updated] (IGNITE-12893) Add support for the SimplifyBooleanExpression rule to checkstyle

2020-04-13 Thread Maxim Muzafarov (Jira)


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

Maxim Muzafarov updated IGNITE-12893:
-
Fix Version/s: 2.9

> Add support for the SimplifyBooleanExpression rule to checkstyle
> 
>
> Key: IGNITE-12893
> URL: https://issues.apache.org/jira/browse/IGNITE-12893
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
>
> The rule must be supported by the checkstyle according to Ignite coding 
> conventions [1].
> {code}
> 
> {code}
>  
> https://checkstyle.sourceforge.io/config_coding.html#SimplifyBooleanExpression
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Useof%22!%22insteadofexplicit%22==true%22and%22==false%22



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12893) Add support for the SimplifyBooleanExpression rule to checkstyle

2020-04-13 Thread Maxim Muzafarov (Jira)


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

Maxim Muzafarov updated IGNITE-12893:
-
Ignite Flags:   (was: Docs Required,Release Notes Required)

> Add support for the SimplifyBooleanExpression rule to checkstyle
> 
>
> Key: IGNITE-12893
> URL: https://issues.apache.org/jira/browse/IGNITE-12893
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>
> The rule must be supported by the checkstyle according to Ignite coding 
> conventions [1].
> {code}
> 
> {code}
>  
> https://checkstyle.sourceforge.io/config_coding.html#SimplifyBooleanExpression
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Useof%22!%22insteadofexplicit%22==true%22and%22==false%22



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12893) Add support for the SimplifyBooleanExpression rule to checkstyle

2020-04-13 Thread Maxim Muzafarov (Jira)


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

Maxim Muzafarov updated IGNITE-12893:
-
Description: 
The rule must be supported by the checkstyle according to Ignite coding 
conventions [1].

{code}

{code}
 
https://checkstyle.sourceforge.io/config_coding.html#SimplifyBooleanExpression

https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Useof%22!%22insteadofexplicit%22==true%22and%22==false%22

  was:
The rule must be supported by the checkstyle according to Ignite coding 
conventions [1].

{code}

{code}
 
https://checkstyle.sourceforge.io/config_coding.html#SimplifyBooleanExpression

https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Useof%22!%22insteadofexplicit%22==true%22and%22==false%22


> Add support for the SimplifyBooleanExpression rule to checkstyle
> 
>
> Key: IGNITE-12893
> URL: https://issues.apache.org/jira/browse/IGNITE-12893
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>
> The rule must be supported by the checkstyle according to Ignite coding 
> conventions [1].
> {code}
> 
> {code}
>  
> https://checkstyle.sourceforge.io/config_coding.html#SimplifyBooleanExpression
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Useof%22!%22insteadofexplicit%22==true%22and%22==false%22



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-12893) Add support for the SimplifyBooleanExpression rule to checkstyle

2020-04-13 Thread Maxim Muzafarov (Jira)
Maxim Muzafarov created IGNITE-12893:


 Summary: Add support for the SimplifyBooleanExpression rule to 
checkstyle
 Key: IGNITE-12893
 URL: https://issues.apache.org/jira/browse/IGNITE-12893
 Project: Ignite
  Issue Type: Task
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov


The rule must be supported by the checkstyle according to Ignite coding 
conventions [1].

{code}

{code}
 
https://checkstyle.sourceforge.io/config_coding.html#SimplifyBooleanExpression

https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Useof%22!%22insteadofexplicit%22==true%22and%22==false%22



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-12892) Clarify WAL archive size configuration

2020-04-13 Thread Semyon Danilov (Jira)
Semyon Danilov created IGNITE-12892:
---

 Summary: Clarify WAL archive size configuration
 Key: IGNITE-12892
 URL: https://issues.apache.org/jira/browse/IGNITE-12892
 Project: Ignite
  Issue Type: Sub-task
Reporter: Semyon Danilov
Assignee: Semyon Danilov


Actual maximum size of WAL archive that can be reserved for historical 
rebalance is calculated as minimum of three properties:
 # DataStorageConfiguration#walHistSize (units: number of checkpoints)
 # DataStorageConfiguration#maxWalArchiveSize (units: bytes)
 # IgniteSystemProperties#IGNITE_PDS_MAX_CHECKPOINT_MEMORY_HISTORY_SIZE (units: 
number of checkpoints)

The logic is a little unclear, so I propose following changes:
 # Stop using walHistSize at all (it's already deprecated) for WAL truncation
 # Use IGNITE_PDS_MAX_CHECKPOINT_MEMORY_HISTORY_SIZE only in case WAL archive 
is managed externally (so we limit the quantity of checkpoints stored in 
memory, but don't remove WAL files)
 # Use -1 for maxWalArchiveSize (instead of Long.MAX_VALUE) to disable WAL 
truncation



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash

2020-04-13 Thread Dmitriy Sorokin (Jira)


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

Dmitriy Sorokin reassigned IGNITE-8625:
---

Assignee: Dmitriy Sorokin  (was: Alexey Stelmak)

> Dynamic SQL index recreate after cache clear may result in AssertionError or 
> JVM crash
> --
>
> Key: IGNITE-8625
> URL: https://issues.apache.org/jira/browse/IGNITE-8625
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence, sql
>Reporter: Ivan Rakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, sql-stability
> Fix For: 2.9, 2.8.1
>
> Attachments: dyn_idx_reproducer.patch
>
>
> After recreation of previously dropped SQL index (in persistent mode), root 
> page of new index B+ tree may contain links to data entries from previous 
> index tree. If these entries were removed or relocated to another data page, 
> attempt to dereference these links may throw AssertionError or even cause JVM 
> crash.
> Patch with reproducer is attached.
> P.S. Please note that with IGNITE-4958 fix old invalid links may refer to 
> non-data page - it might have been recycled into page with any other type. 
> Such case will cause AssertionError on page read lock attempt. Rolling back 
> IGNITE-4958 may help with debugging.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12775) Update URLs and other content on Ignite downloads page

2020-04-13 Thread Maxim Muzafarov (Jira)


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

Maxim Muzafarov commented on IGNITE-12775:
--

[~dmagda]

Thank you for the review. Hopefully, I've resolved your comments.
PR is almost ready, but the only pgp, hash are left to be done for gce binary.

> Update URLs and other content on Ignite downloads page
> --
>
> Key: IGNITE-12775
> URL: https://issues.apache.org/jira/browse/IGNITE-12775
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis A. Magda
>Assignee: Maxim Muzafarov
>Priority: Blocker
> Fix For: 2.8.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As per ASF INFRA advise/request, the downloads page needs to be adjusted this 
> way:
> * PGP/SHA512 stuff should refer to downloads.apache.org instead of 
> www.apache.org/dist/ 
> * I could not find a link to the KEYS file.
> * The page links to NIGHTLY builds; these must not be promoted to the
> general public
> * the page does not describe how to verify downloads, and only
> mentions verification for binary downloads. Users should be urged to
> verify all downloads.
> * the 'pgp' link for apache-ignite-fabric-2.4.0-bin.zip points to the
> zip file, likewise for apache-ignite-fabric-2.3.0-bin.zip
> * apache-ignite-1.3.0-src.zip and earlier are incubating releases,
> however the link text does not make this clear.
> * the docker and cloud image links don't have sigs or hashes



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (IGNITE-12866) CQ fails due to CQ filter deserialization exception.

2020-04-13 Thread Mikhail Petrov (Jira)


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

Mikhail Petrov reassigned IGNITE-12866:
---

Assignee: Mikhail Petrov

> CQ fails due to CQ filter deserialization exception.
> 
>
> Key: IGNITE-12866
> URL: https://issues.apache.org/jira/browse/IGNITE-12866
> Project: Ignite
>  Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
>
> CQ fails if CQ filter deserialization exception occurred on a node that does 
> not match the cache node filter in case cache node filter must be loaded via 
> p2p.
> Reproducer is linked as PR to the ticket.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-1328) OS detection reports Windows 10 as "less rigorously tested"

2020-04-13 Thread Pavel Tupitsyn (Jira)


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

Pavel Tupitsyn resolved IGNITE-1328.

Resolution: Fixed

> OS detection reports Windows 10 as "less rigorously tested"
> ---
>
> Key: IGNITE-1328
> URL: https://issues.apache.org/jira/browse/IGNITE-1328
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Pavel Konstantinov
>Assignee: Pavel Tupitsyn
>Priority: Trivial
> Fix For: 2.9
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Please look at IgniteUtils starting line 320



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-1328) OS detection reports Windows 10 as "less rigorously tested"

2020-04-13 Thread Pavel Tupitsyn (Jira)


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

Pavel Tupitsyn updated IGNITE-1328:
---
Fix Version/s: 2.9

> OS detection reports Windows 10 as "less rigorously tested"
> ---
>
> Key: IGNITE-1328
> URL: https://issues.apache.org/jira/browse/IGNITE-1328
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Pavel Konstantinov
>Assignee: Pavel Tupitsyn
>Priority: Trivial
> Fix For: 2.9
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Please look at IgniteUtils starting line 320



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-1328) OS detection reports Windows 10 as "less rigorously tested"

2020-04-13 Thread Pavel Tupitsyn (Jira)


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

Pavel Tupitsyn updated IGNITE-1328:
---
Release Note: Remove "sufficiently tested OS" diagnostic

> OS detection reports Windows 10 as "less rigorously tested"
> ---
>
> Key: IGNITE-1328
> URL: https://issues.apache.org/jira/browse/IGNITE-1328
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Pavel Konstantinov
>Assignee: Pavel Tupitsyn
>Priority: Trivial
> Fix For: 2.9
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Please look at IgniteUtils starting line 320



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-1328) OS detection reports Windows 10 as "less rigorously tested"

2020-04-13 Thread Pavel Tupitsyn (Jira)


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

Pavel Tupitsyn commented on IGNITE-1328:


Merged to master: 6b6d82a3725a7202ff1effdf905e2463b084cbc7

> OS detection reports Windows 10 as "less rigorously tested"
> ---
>
> Key: IGNITE-1328
> URL: https://issues.apache.org/jira/browse/IGNITE-1328
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Pavel Konstantinov
>Assignee: Pavel Tupitsyn
>Priority: Trivial
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Please look at IgniteUtils starting line 320



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-1328) OS detection reports Windows 10 as "less rigorously tested"

2020-04-13 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-1328:
---

{panel:title=Branch: [pull/7665/head] Base: [master] : Possible Blockers 
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 TIMEOUT , Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=5219033]]

{color:#d04437}MVCC Cache 7{color} [[tests 0 TIMEOUT , Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=5219059]]

{color:#d04437}Cache 6{color} [[tests 0 Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=5219023]]

{color:#d04437}Streamers{color} [[tests 0 Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=5218983]]

{color:#d04437}Thin Client: Java{color} [[tests 0 Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=5218976]]

{color:#d04437}Cache 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=5219018]]
* IgniteBinaryCacheTestSuite: 
CacheWithDifferentDataRegionConfigurationTest.firstNodeHasDefaultAndSecondWithTwoRegionsDefaultAndPersistenceAcceptable
 - Test has low fail rate in base branch 0,0% and is not flaky

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5219069buildTypeId=IgniteTests24Java8_RunAll]

> OS detection reports Windows 10 as "less rigorously tested"
> ---
>
> Key: IGNITE-1328
> URL: https://issues.apache.org/jira/browse/IGNITE-1328
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Pavel Konstantinov
>Assignee: Pavel Tupitsyn
>Priority: Trivial
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Please look at IgniteUtils starting line 320



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12775) Update URLs and other content on Ignite downloads page

2020-04-13 Thread Denis A. Magda (Jira)


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

Denis A. Magda commented on IGNITE-12775:
-

Maxim, is there still some work underway? I saw the PR and left some notes 
there but the ticket is not in the PATCH_AVAILABLE state.

> Update URLs and other content on Ignite downloads page
> --
>
> Key: IGNITE-12775
> URL: https://issues.apache.org/jira/browse/IGNITE-12775
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis A. Magda
>Assignee: Maxim Muzafarov
>Priority: Blocker
> Fix For: 2.8.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As per ASF INFRA advise/request, the downloads page needs to be adjusted this 
> way:
> * PGP/SHA512 stuff should refer to downloads.apache.org instead of 
> www.apache.org/dist/ 
> * I could not find a link to the KEYS file.
> * The page links to NIGHTLY builds; these must not be promoted to the
> general public
> * the page does not describe how to verify downloads, and only
> mentions verification for binary downloads. Users should be urged to
> verify all downloads.
> * the 'pgp' link for apache-ignite-fabric-2.4.0-bin.zip points to the
> zip file, likewise for apache-ignite-fabric-2.3.0-bin.zip
> * apache-ignite-1.3.0-src.zip and earlier are incubating releases,
> however the link text does not make this clear.
> * the docker and cloud image links don't have sigs or hashes



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-11862) Cache stopping on supplier during rebalance causes NPE and supplying failure.

2020-04-13 Thread Dmitriy Sorokin (Jira)


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

Dmitriy Sorokin resolved IGNITE-11862.
--
Resolution: Fixed

> Cache stopping on supplier during rebalance causes NPE and supplying failure.
> -
>
> Key: IGNITE-11862
> URL: https://issues.apache.org/jira/browse/IGNITE-11862
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> {noformat}
> [21:12:14]W: [org.apache.ignite:ignite-core] [2019-05-20 
> 21:12:14,376][ERROR][sys-#60310%distributed.CacheParallelStartTest0%][GridDhtPartitionSupplier]
>  Failed to continue supplying [grp=static-cache-group45, 
> demander=ed1c0109-8721-4cd8-80d9-d36e8251, top
> Ver=AffinityTopologyVersion [topVer=2, minorTopVer=0], topic=0]
> [21:12:14]W: [org.apache.ignite:ignite-core] java.lang.NullPointerException
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.CacheGroupContext.addRebalanceSupplyEvent(CacheGroupContext.java:525)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:422)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:397)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:455)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:440)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1141)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1706)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1566)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2795)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1523)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4500(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1492)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> java.lang.Thread.run(Thread.java:748)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-11862) Cache stopping on supplier during rebalance causes NPE and supplying failure.

2020-04-13 Thread Dmitriy Sorokin (Jira)


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

Dmitriy Sorokin commented on IGNITE-11862:
--

I investigated this issue and found that NPE was happening on code line 
{code:java}
if (!cctx.config().isEventsDisabled())
{code}
because a {{null}} config value was returned by {{cctx.config()}} call due to 
race between calling {{GridCacheContext#cleanup()}} method.
The reproduction of this issue was disappeared after the change {{79553ada}} 
made at PR [#6688|https://github.com/apache/ignite/pull/6688] of ticket 
IGNITE-3195.

> Cache stopping on supplier during rebalance causes NPE and supplying failure.
> -
>
> Key: IGNITE-11862
> URL: https://issues.apache.org/jira/browse/IGNITE-11862
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> {noformat}
> [21:12:14]W: [org.apache.ignite:ignite-core] [2019-05-20 
> 21:12:14,376][ERROR][sys-#60310%distributed.CacheParallelStartTest0%][GridDhtPartitionSupplier]
>  Failed to continue supplying [grp=static-cache-group45, 
> demander=ed1c0109-8721-4cd8-80d9-d36e8251, top
> Ver=AffinityTopologyVersion [topVer=2, minorTopVer=0], topic=0]
> [21:12:14]W: [org.apache.ignite:ignite-core] java.lang.NullPointerException
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.CacheGroupContext.addRebalanceSupplyEvent(CacheGroupContext.java:525)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:422)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:397)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:455)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:440)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1141)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1706)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1566)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2795)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1523)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4500(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1492)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [21:12:14]W: [org.apache.ignite:ignite-core] at 
> java.lang.Thread.run(Thread.java:748)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-12721) Validation of key length written to Distributed Metastorage

2020-04-13 Thread Ivan Bessonov (Jira)


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

Ivan Bessonov resolved IGNITE-12721.

Release Note: Issue is irrelevant because IGNITE-12726 is already fixed.
  Resolution: Won't Fix

> Validation of key length written to Distributed Metastorage
> ---
>
> Key: IGNITE-12721
> URL: https://issues.apache.org/jira/browse/IGNITE-12721
> Project: Ignite
>  Issue Type: Task
>  Components: persistence
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> DistributedMetastorage functionality introduced in IGNITE-10640 provides 
> convenient way to perform coordinated writes to local MetaStorages on all 
> server nodes but lacks important part: validation of key length.
> Current implementation of MetaStorage doesn't allow keys longer than a 
> specific value (64 bytes minus some prefixes, see source code for details) 
> and throws assertion error on an attempt to write longer key.
> This error from MetaStorage is not propagated to DistributedMetastorage and 
> (in theory) may even cause a node to halt.
> In order to avoid this situation validation of key length should be added 
> right to DistributedMetastorage implementation to enforce "fail-fast" 
> principle and preserve Ignite nodes from potentially dangerous consequences.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (IGNITE-12890) JMX attribute 'getExecutorServiceFormatted' of IgniteMXBean returns getPublicThreadPoolSize() instead of formatted executor service

2020-04-13 Thread Maria Makedonskaya (Jira)


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

Maria Makedonskaya reassigned IGNITE-12890:
---

Assignee: Maria Makedonskaya

> JMX attribute 'getExecutorServiceFormatted' of IgniteMXBean returns 
> getPublicThreadPoolSize() instead of formatted executor service
> ---
>
> Key: IGNITE-12890
> URL: https://issues.apache.org/jira/browse/IGNITE-12890
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maria Makedonskaya
>Assignee: Maria Makedonskaya
>Priority: Major
>
> while testing JmxWorker I found a possible bug in one of attributes of 
> IgniteMXBean
> 1. start ignite node with IGNITE_JMX_PORT=1100
> 2. get ExecutorServiceFormatted attribute via JMX
> {noformat}
> /usr/lib/jvm/java-8-oracle/bin/java -cp 
> ./ignite-test-tools-1.0.0-SNAPSHOT.jar org.apache.ignite.testtools.JmxWorker 
> -host=127.0.0.1 -port=1100 -bean=IgniteKernal -group=Kernal 
> -attribute=ExecutorServiceFormatted
> 8
> {noformat}
> a number does not looks like proper value for string representation of 
> complex object, browsing the code reveals following:
> {noformat}
>  @Override public String getExecutorServiceFormatted() {
>  assert cfg != null;
> return String.valueOf(cfg.getPublicThreadPoolSize());
>  }
> {noformat}
> We should deprecate 'getExecutorServiceFormatted' and create a new method 
> 'getPublicThreadPoolSize'.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12888) Add support for ConstantName to checkstyle rules

2020-04-13 Thread Maxim Muzafarov (Jira)


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

Maxim Muzafarov commented on IGNITE-12888:
--

[~NSAmelchev] 

Hello, can you please review my changes?

> Add support for ConstantName to checkstyle rules
> 
>
> Key: IGNITE-12888
> URL: https://issues.apache.org/jira/browse/IGNITE-12888
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add a new rule to checkstyle according to Apache Ignite naming conventions.
> 
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Naming



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-1328) OS detection reports Windows 10 as "less rigorously tested"

2020-04-13 Thread Pavel Tupitsyn (Jira)


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

Pavel Tupitsyn commented on IGNITE-1328:


Instead of fixing the check, let's just remove it: 
http://apache-ignite-developers.2346864.n4.nabble.com/Remove-quot-This-operating-system-has-been-tested-less-rigorously-quot-diagnostic-td46891.html

> OS detection reports Windows 10 as "less rigorously tested"
> ---
>
> Key: IGNITE-1328
> URL: https://issues.apache.org/jira/browse/IGNITE-1328
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Pavel Konstantinov
>Assignee: Pavel Tupitsyn
>Priority: Trivial
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Please look at IgniteUtils starting line 320



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12840) Leaking H2 internals when querying from pyignite

2020-04-13 Thread Ilya Kasnacheev (Jira)


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

Ilya Kasnacheev updated IGNITE-12840:
-
Ignite Flags:   (was: Release Notes Required)

> Leaking H2 internals when querying from pyignite
> 
>
> Key: IGNITE-12840
> URL: https://issues.apache.org/jira/browse/IGNITE-12840
> Project: Ignite
>  Issue Type: Bug
>  Components: clients, python
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments: TEST_TABLE.sql, read_cache_insert_update_table.py, 
> test_insert_in_cache.py
>
>
> I am sharing a slightly modified reproducer from userlist.
> To run:
> Start a node (with JVM_OPTS=-Xmx512m to see it most clearly).
> Run a .sql file with sqlline (!run)
> python3 test_insert_in_cache.py
> in parallel terminal: python3 read_cache_insert_update_table.py
> Then you should observe slowing down and long GC pauses on server node. jmap 
> will collect ever-increasing heap dumps.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12840) Leaking H2 internals when querying from pyignite

2020-04-13 Thread Ilya Kasnacheev (Jira)


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

Ilya Kasnacheev updated IGNITE-12840:
-
Fix Version/s: (was: 2.8.1)

> Leaking H2 internals when querying from pyignite
> 
>
> Key: IGNITE-12840
> URL: https://issues.apache.org/jira/browse/IGNITE-12840
> Project: Ignite
>  Issue Type: Bug
>  Components: clients, python
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Priority: Critical
> Attachments: TEST_TABLE.sql, read_cache_insert_update_table.py, 
> test_insert_in_cache.py
>
>
> I am sharing a slightly modified reproducer from userlist.
> To run:
> Start a node (with JVM_OPTS=-Xmx512m to see it most clearly).
> Run a .sql file with sqlline (!run)
> python3 test_insert_in_cache.py
> in parallel terminal: python3 read_cache_insert_update_table.py
> Then you should observe slowing down and long GC pauses on server node. jmap 
> will collect ever-increasing heap dumps.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-12840) Leaking H2 internals when querying from pyignite

2020-04-13 Thread Ilya Kasnacheev (Jira)


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

Ilya Kasnacheev resolved IGNITE-12840.
--
Resolution: Duplicate

> Leaking H2 internals when querying from pyignite
> 
>
> Key: IGNITE-12840
> URL: https://issues.apache.org/jira/browse/IGNITE-12840
> Project: Ignite
>  Issue Type: Bug
>  Components: clients, python
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments: TEST_TABLE.sql, read_cache_insert_update_table.py, 
> test_insert_in_cache.py
>
>
> I am sharing a slightly modified reproducer from userlist.
> To run:
> Start a node (with JVM_OPTS=-Xmx512m to see it most clearly).
> Run a .sql file with sqlline (!run)
> python3 test_insert_in_cache.py
> in parallel terminal: python3 read_cache_insert_update_table.py
> Then you should observe slowing down and long GC pauses on server node. jmap 
> will collect ever-increasing heap dumps.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12888) Add support for ConstantName to checkstyle rules

2020-04-13 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-12888:


{panel:title=Branch: [pull/7662/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5217287buildTypeId=IgniteTests24Java8_RunAll]

> Add support for ConstantName to checkstyle rules
> 
>
> Key: IGNITE-12888
> URL: https://issues.apache.org/jira/browse/IGNITE-12888
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add a new rule to checkstyle according to Apache Ignite naming conventions.
> 
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Naming



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-12891) Add userAttributes map to all GridClient messages

2020-04-13 Thread Oleg Ostanin (Jira)
Oleg Ostanin created IGNITE-12891:
-

 Summary: Add userAttributes map to all GridClient messages
 Key: IGNITE-12891
 URL: https://issues.apache.org/jira/browse/IGNITE-12891
 Project: Ignite
  Issue Type: Bug
Reporter: Oleg Ostanin
Assignee: Oleg Ostanin


Currently we are only sending userAttributes map in GridClient TOPOLOGY 
message. In some particular circumstances it can lead to an authentication 
failure.

Reproducer:

https://github.com/oleg-ostanin/ignite/blob/gridclient-fail-reproducer/modules/core/src/test/java/org/apache/ignite/internal/processors/security/client/AdditionalSecurityCheckGridClientTest.java



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12840) Leaking H2 internals when querying from pyignite

2020-04-13 Thread Ilya Kasnacheev (Jira)


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

Ilya Kasnacheev commented on IGNITE-12840:
--

I believe it is a duplicate of IGNITE-12848

> Leaking H2 internals when querying from pyignite
> 
>
> Key: IGNITE-12840
> URL: https://issues.apache.org/jira/browse/IGNITE-12840
> Project: Ignite
>  Issue Type: Bug
>  Components: clients, python
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments: TEST_TABLE.sql, read_cache_insert_update_table.py, 
> test_insert_in_cache.py
>
>
> I am sharing a slightly modified reproducer from userlist.
> To run:
> Start a node (with JVM_OPTS=-Xmx512m to see it most clearly).
> Run a .sql file with sqlline (!run)
> python3 test_insert_in_cache.py
> in parallel terminal: python3 read_cache_insert_update_table.py
> Then you should observe slowing down and long GC pauses on server node. jmap 
> will collect ever-increasing heap dumps.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12793) Deadlock in the System Pool on Metadata processing

2020-04-13 Thread Sergey Kosarev (Jira)


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

Sergey Kosarev commented on IGNITE-12793:
-

[~sergey-chugunov] , one more question.

I found method that heplepd me as temporary work-around: 
org.apache.ignite.internal.binary.BinaryContext#registerUserTypesSchema

I added it after starting of every client node(of course  I also registeed user 
types in BinaryConfiguration before).

((CacheObjectBinaryProcessorImpl)ignite0.context().cacheObjects()).binaryContext().registerUserTypesSchema();

 

I found that 
org.apache.ignite.internal.binary.BinaryContext#registerUserTypesSchema is 
executed on start of thin client 
(org.apache.ignite.internal.client.thin.TcpIgniteClient#TcpIgniteClient).

 

Do you know why this method is not executing on usual (thick) client start?

 

> Deadlock in the System Pool on Metadata processing
> --
>
> Key: IGNITE-12793
> URL: https://issues.apache.org/jira/browse/IGNITE-12793
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.8, 2.7.6
>Reporter: Sergey Kosarev
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.9
>
> Attachments: ignite-12793-threaddump.txt
>
>
> I've recently tried to apply Ilya's idea 
> (https://issues.apache.org/jira/browse/IGNITE-12663) of minimizing thread 
> pools and tried to set system pool to 3 in my own tests.
>  It caused deadlock on a client node and I think it can happen not only on 
> such small pool values.
> Details are following:
>  I'm not using persistence currently (if it matters).
>  On the client note I use ignite compute to call a job on every server node 
> (there are 3 server nodes in the tests).
> Then I've found in logs:
>  {{[10:55:21] : [Step 1/1] [2020-03-13 10:55:21,773]
> {grid-timeout-worker-#8}
> [WARN] [o.a.i.i.IgniteKernal] - Possible thread pool starvation detected (no 
> task completed in last 3ms, is system thread pool size large enough?)
>  [10:55:21] : [Step 1/1] ^-- System thread pool [active=3, idle=0, qSize=9]}}
> I see in threaddumps that all 3 system pool workers do the same - processing 
> of job responses:
>  {{ "sys-#26" #605 daemon prio=5 os_prio=0 tid=0x64a0a800 nid=0x1f34 
> waiting on condition [0x7b91d000]
>  java.lang.Thread.State: WAITING (parking)
>  at sun.misc.Unsafe.park(Native Method)
>  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
>  at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:749)
>  at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:250)
>  at 
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1169)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:285)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:184)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
>  at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
>  at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
>  at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
>  at 
> 

[jira] [Commented] (IGNITE-12500) IgniteProxy should be injected into non-system types only.

2020-04-13 Thread Denis Garus (Jira)


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

Denis Garus commented on IGNITE-12500:
--

Resolved inside  IGNITE-12342.

> IgniteProxy should be injected into non-system types only.
> --
>
> Key: IGNITE-12500
> URL: https://issues.apache.org/jira/browse/IGNITE-12500
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Denis Garus
>Assignee: Denis Garus
>Priority: Major
>  Labels: iep-38
>
> When the Ignite Sandbox is enabled, the GridResourceProxiedIgniteInjector 
> should inject an IgniteProxy into non-system types only.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12500) IgniteProxy should be injected into non-system types only.

2020-04-13 Thread Denis Garus (Jira)


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

Denis Garus updated IGNITE-12500:
-
Ignite Flags:   (was: Docs Required,Release Notes Required)

> IgniteProxy should be injected into non-system types only.
> --
>
> Key: IGNITE-12500
> URL: https://issues.apache.org/jira/browse/IGNITE-12500
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Denis Garus
>Assignee: Denis Garus
>Priority: Major
>  Labels: iep-38
>
> When the Ignite Sandbox is enabled, the GridResourceProxiedIgniteInjector 
> should inject an IgniteProxy into non-system types only.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-12500) IgniteProxy should be injected into non-system types only.

2020-04-13 Thread Denis Garus (Jira)


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

Denis Garus resolved IGNITE-12500.
--
Resolution: Fixed

> IgniteProxy should be injected into non-system types only.
> --
>
> Key: IGNITE-12500
> URL: https://issues.apache.org/jira/browse/IGNITE-12500
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Denis Garus
>Assignee: Denis Garus
>Priority: Major
>  Labels: iep-38
>
> When the Ignite Sandbox is enabled, the GridResourceProxiedIgniteInjector 
> should inject an IgniteProxy into non-system types only.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12884) Extend debug output for restorePartitionStates method.

2020-04-13 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-12884:


{panel:title=Branch: [pull/7657/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5211482buildTypeId=IgniteTests24Java8_RunAll]

> Extend debug output for restorePartitionStates method.
> --
>
> Key: IGNITE-12884
> URL: https://issues.apache.org/jira/browse/IGNITE-12884
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.8
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Minor
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There is a frequently need to investigate grid initializing time. Possibility 
> to know additionally restored partitions size would be helpful.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12793) Deadlock in the System Pool on Metadata processing

2020-04-13 Thread Sergey Kosarev (Jira)


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

Sergey Kosarev commented on IGNITE-12793:
-

[~sergey-chugunov], sounds good. I agree with your solution.

 

  

 

> Deadlock in the System Pool on Metadata processing
> --
>
> Key: IGNITE-12793
> URL: https://issues.apache.org/jira/browse/IGNITE-12793
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.8, 2.7.6
>Reporter: Sergey Kosarev
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.9
>
> Attachments: ignite-12793-threaddump.txt
>
>
> I've recently tried to apply Ilya's idea 
> (https://issues.apache.org/jira/browse/IGNITE-12663) of minimizing thread 
> pools and tried to set system pool to 3 in my own tests.
>  It caused deadlock on a client node and I think it can happen not only on 
> such small pool values.
> Details are following:
>  I'm not using persistence currently (if it matters).
>  On the client note I use ignite compute to call a job on every server node 
> (there are 3 server nodes in the tests).
> Then I've found in logs:
>  {{[10:55:21] : [Step 1/1] [2020-03-13 10:55:21,773]
> {grid-timeout-worker-#8}
> [WARN] [o.a.i.i.IgniteKernal] - Possible thread pool starvation detected (no 
> task completed in last 3ms, is system thread pool size large enough?)
>  [10:55:21] : [Step 1/1] ^-- System thread pool [active=3, idle=0, qSize=9]}}
> I see in threaddumps that all 3 system pool workers do the same - processing 
> of job responses:
>  {{ "sys-#26" #605 daemon prio=5 os_prio=0 tid=0x64a0a800 nid=0x1f34 
> waiting on condition [0x7b91d000]
>  java.lang.Thread.State: WAITING (parking)
>  at sun.misc.Unsafe.park(Native Method)
>  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
>  at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:749)
>  at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:250)
>  at 
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1169)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:285)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:184)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
>  at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
>  at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
>  at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>  at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:306)
>  at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:100)
>  at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
>  at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10493)
>  at 
> 

[jira] [Commented] (IGNITE-12885) Checkpoint thread executes partitions fsync in single thread

2020-04-13 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-12885:


{panel:title=Branch: [pull/7658/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5211635buildTypeId=IgniteTests24Java8_RunAll]

> Checkpoint thread executes partitions fsync in single thread
> 
>
> Key: IGNITE-12885
> URL: https://issues.apache.org/jira/browse/IGNITE-12885
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It should use "asyncRunner" if it was configured, this will optimize 
> checkpoint speed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-10011) Pages leak suspicion in PDS

2020-04-13 Thread Alexey Goncharuk (Jira)


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

Alexey Goncharuk commented on IGNITE-10011:
---

[~ilyak] I think the PR requires additional work as there were multiple failing 
tests needed to be investigated in the PR. I've abandoned it as I had no time 
to investigate further. However, the logic around free list changes a couple of 
times since last year, so perhaps the fix is no longer relevant and the issue 
is no longer valid.
As for the test - I believe it can be fairly easy to implement.

> Pages leak suspicion in PDS
> ---
>
> Key: IGNITE-10011
> URL: https://issues.apache.org/jira/browse/IGNITE-10011
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Ilya Kasnacheev
>Priority: Critical
>  Labels: performance
> Fix For: 2.9, 2.8.1
>
> Attachments: Main.java
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> See the attached Main which adds 500k records to 3 caches, then clears them, 
> rinse, repeat.
> When ran with default settings, totalAllocatedSize will slowly double over 
> the course of a few hours and then continue to grow.
> When ran with 2 FreeList buckets, it will double every time, 600M -> 1200M -> 
> 1800M -> etc.
> See the userlist discussion



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12857) Add ability to put non-primitive data types via HTTP-REST

2020-04-13 Thread Ignite TC Bot (Jira)


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

Ignite TC Bot commented on IGNITE-12857:


{panel:title=Branch: [pull/7648/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5217403buildTypeId=IgniteTests24Java8_RunAll]

> Add ability to put non-primitive data types via HTTP-REST
> -
>
> Key: IGNITE-12857
> URL: https://issues.apache.org/jira/browse/IGNITE-12857
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Reporter: Aleksey Plekhanov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, we can get values with non-primitive data types via HTTP REST, 
> they are represented in JSON form, but we can't put such values into the 
> cache. Put can be used only with a limited set of data types (see 
> {{GridJettyRestHandler#convert}}).
> The ability to put non-primitive data types should be added (binary object 
> should be created from JSON).
> We should also check that the get operation for such data types after put 
> returns data in the same form. And inserted values correctly matched to query 
> entities for the cache (we should be able to select inserted data via SQL). 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (IGNITE-12637) IgniteSparkSession doesn't start the clients on really distributed cluster

2020-04-13 Thread Yaroslav Molochkov (Jira)


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

Yaroslav Molochkov reassigned IGNITE-12637:
---

Assignee: Yaroslav Molochkov

> IgniteSparkSession doesn't start the clients on really distributed cluster
> --
>
> Key: IGNITE-12637
> URL: https://issues.apache.org/jira/browse/IGNITE-12637
> Project: Ignite
>  Issue Type: Bug
>  Components: spark
>Affects Versions: 2.7.6
>Reporter: Andrey Aleksandrov
>Assignee: Yaroslav Molochkov
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> Next code:
> IgniteSparkSession igniteSession = IgniteSparkSession.builder()
>    .appName("Spark Ignite example")
>    .igniteConfig(configPath)
>    .getOrCreate();
> Throws:
> class org.apache.ignite.IgniteIllegalStateException: Ignite instance with 
> provided name doesn't exist. Did you call Ignition.start(..) to start an 
> Ignite instance? [name=grid]
> Client config was located in all Spark nodes at the same place. 
> When I ran these tests on the same host with several local executors then it 
> worked. But if executors were located on different hosts then it didn't.
> DataFrame API works fine with the same config.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12739) Optimistic serializable transactions may fail infinitely when read-through is enabled

2020-04-13 Thread Anton Vinogradov (Jira)


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

Anton Vinogradov commented on IGNITE-12739:
---

Merged to master.

Thanks for your contribution.

> Optimistic serializable transactions may fail infinitely when read-through is 
> enabled
> -
>
> Key: IGNITE-12739
> URL: https://issues.apache.org/jira/browse/IGNITE-12739
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Goncharuk
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Attachments: ReplicatedOptimisticTxTest.java
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> In current design it is possible that the same key-value pair will be stored 
> with different versions on primary and backup nodes. For example, a 
> read-through is invoked separately on primary backup and values are stored 
> with node local version.
> With this precondition, if an optimistic serializable transaction is started 
> from a backup node, the serializable check version is read from backup, but 
> validated on primary node, which will fail the transaction with optimistic 
> read/write conflict exception until the versions are overwritten to the same 
> value (for example, via a pessimistic transaction).
> While we need to additionally investigate whether we want to change the 
> read-through logic to ensure the same value and version on all nodes, this 
> particular scenario should be fixed by always enforcing reading from a 
> primary node inside an optimistic serializable transaction.
> The reproducer is attached. A known workaround is to disable read load 
> balancing by setting "-DIGNITE_READ_LOAD_BALANCING=false" system property.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)