There were two bugs actually, but the problem is basically the same, just in different cases. SQL + Partition Loss Policies issue (fixed in 2.7) - https://issues.apache.org/jira/browse/IGNITE-8927 (the issue says “hang” but the visible behavior actually varies) SQL + Partition Loss Policies + Native Persistence issue (fixed in 2.8) - https://issues.apache.org/jira/browse/IGNITE-9841
If you don’t use native persistence then various SELECTs should work as you expect on 2.7. If you do need persistence then you could try working with master (e.g. take a nightly build – but don’t use it in any real environments). Stan From: joseheitor Sent: 24 декабря 2018 г. 18:40 To: [email protected] Subject: Re: CAP Theorem (CP? or AP?) Guys, thank you both for your informative and helpful responses. I have explicitly configured the cache-template with the additional property: <property name="partitionLossPolicy" value="READ_WRITE_SAFE"/> And have observed the following behaviour: 1. [OK] Attempting to get a specific record(s) which resides in a lost partition does indeed return an exception, as expected. 2. [?] Doing a SELECT COUNT(*) however, still succeeds without error, but obviously reports the wrong number of total records (understandably). But shouldn't any operation against a cache with lost partitions result in an Exception? How will my application know that the result is valid and can be trusted to be accurate? Another question please - Stanislav, what is the issue with Ignite persistence, that was fixed in 2.7 for in-memory, but will only be fixed for Ignite native persistence in version 2.8...? Thanks, Jose -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
