[jira] [Commented] (IGNITE-11942) IGFS and Hadoop Accelerator Discontinuation
[ 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
[ 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
[ 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.
[ 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.
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
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
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
[ 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
[ 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.
[ 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"
[ 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"
[ 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"
[ 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"
[ 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"
[ 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
[ 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.
[ 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.
[ 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
[ 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
[ 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
[ 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"
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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.
[ 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.
[ 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.
[ 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.
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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)