[jira] [Created] (IGNITE-11734) IgniteCache.replace(k, v, nv) requires classes when element is null or old value - null
Vladislav Pyatkov created IGNITE-11734: -- Summary: IgniteCache.replace(k, v, nv) requires classes when element is null or old value - null Key: IGNITE-11734 URL: https://issues.apache.org/jira/browse/IGNITE-11734 Project: Ignite Issue Type: Bug Reporter: Vladislav Pyatkov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11735) Safely handle new closures of IGNITE-11392 in mixed cluster environment
Ivan Rakov created IGNITE-11735: --- Summary: Safely handle new closures of IGNITE-11392 in mixed cluster environment Key: IGNITE-11735 URL: https://issues.apache.org/jira/browse/IGNITE-11735 Project: Ignite Issue Type: Improvement Reporter: Ivan Rakov Assignee: Denis Chudov Fix For: 2.8 Under IGNITE-11392 we have added two new closures (FetchActiveTxOwnerTraceClosure and TxOwnerDumpRequestAllowedSettingClosure). In case we'll assemble mixed cluster (some nodes contain the patch, some don't), we may bump into situation when closures are sent to node that doesn't contain corresponding classes in classpath. Normally, closurer will be deployed to "old" node via peer-to-peer class deployment. However, p2p may be disabled in configuration, which will cause ClassNotFoundException on "old" node. We should register IGNITE-11392 in IgniteFeatures (recent example: IGNITE-11598) and filter out nodes that don't support new feature before sending compute. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: New Committer: Vyacheslav Daradur
Well done Slava! It was great working with you on the service grid redesign. Looking forward to seeing new commits from you! Denis чт, 11 апр. 2019 г. в 18:27, Denis Magda : > Well deserved, Vyacheslav! Thanks for hardening Service Grid pushing it to > a completely next level! > > - > Denis > > > On Thu, Apr 11, 2019 at 7:00 AM Dmitriy Pavlov wrote: > > > Dear Ignite Developers, > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > Vyacheslav Daradur to become a committer and we are pleased to announce > > that he has accepted. Apache Ignite PMC appreciates Vyacheslav’s > > contribution to service grid redesign (is was collaborative efforts. BTW, > > thanks to everyone involved), compatibility test framework, contribution > to > > community development, and to abbreviation plugin. > > > > Being a committer enables easier contribution to the project since there > is > > no need to go via the patch submission process. This should enable better > > productivity. > > > > Please join me in welcoming Vyacheslav, and congratulating him on the new > > role in the Apache Ignite Community. > > > > Best Regards, > > Dmitriy Pavlov > > on behalf of the Apache Ignite PMC > > >
Re: Ignite 2.7.5 Release scope
Hi Igniters, A bit of update: Last change fixing GridUnsafe for Java 12 was merged to master and to 2.7.5 Overnight run contains a number of failures considered as blockers by Apache Ignite Teamcity Bot (comparing to 2.7): - Platform .NET (Inspections) always failed- Critical F.R.: 100,0% - Platform C++ (Linux Clang) & Platform C++ (Linux)* failed in most cases - Critical F.R.: 60,0% - Disk Page Compressions - Module is N/A in 2.7.5 - [Inspections] Core - always failed - Hibernate 5.3 - Module is N/A in 2.7.5 - Platform C++ (Win x64 | Release) - also failed in 2.7 And 2 more tests failure considered as blockers (now it is in re-run state). If re-run shows these tests are passing I proceed with RC preparation. Sincerely, Dmitriy Pavlov вт, 9 апр. 2019 г. в 10:03, Dmitriy Pavlov : > Hi, Nikolay, > > thanks for offering help. > > Performance testing of new fix seems to be almost done. > > After merging of the last ticket (I hope it will be tomorrow) I will > continue with RC building. There can be some issues related to scripts. > > Sincerely, > Dmitriy Pavlov > > вт, 9 апр. 2019 г. в 09:53, Nikolay Izhikov : > >> Hello, Dmitriy. >> >> Any news about release? >> Do you need assistance with it? >> >> вт, 2 апр. 2019 г. в 20:04, Dmitriy Pavlov : >> >> > Ivan P., it seems the netty approach you've proposed works well. Thank >> you. >> > >> > Igniters, please take a look at following fix: >> > https://github.com/apache/ignite/pull/6384 >> > It allows us to start under Java 12 and under Java 11- (as it). >> > >> > Sincerely, >> > Dmitriy Pavlov >> > >> > пт, 29 мар. 2019 г. в 22:57, Dmitriy Pavlov : >> > >> > > Denis, the issue here is that we don't know for sure. We see just one >> > > blocking issue with accessing NioAccessObject. >> > > >> > > And there are 3 different scenario related to this issue fix: >> > > - fixes won't help, and we should find out other options on how to >> create >> > > a direct buffer from pointer - needed for durable memory, Java 12 goes >> > to a >> > > later release. >> > > - some fix would help, but other issues come, Java 12 goes to some >> later >> > > release >> > > - some from proposed fixes works, nothing else needs to be done - 1-2 >> > days >> > > >> > > If it latest scenario, I would include as much as we can (1-2 days >> extra >> > > are comparable with minimal voting time). >> > > >> > > BTW, I've checked scripts it does not work for me, I will ask Andrey >> > > G/Peter for advice on Monday. >> > > >> > > Sincerely, >> > > Dmitriy Pavlov >> > > >> > > >> > > пт, 29 мар. 2019 г. в 20:47, Denis Magda : >> > > >> > >> Folks, >> > >> >> > >> What are the efforts to support Java 12? Let's do 2.7.6 shortly if >> the >> > >> fixes are time-consuming. >> > >> >> > >> - >> > >> Denis >> > >> >> > >> >> > >> On Fri, Mar 29, 2019 at 10:08 AM Dmitriy Pavlov >> > >> wrote: >> > >> >> > >> > Hi Igniters, >> > >> > >> > >> > I would like to announce code freeze for 2.7.5. Only one open >> ticket >> > is >> > >> > there (reopened): >> https://issues.apache.org/jira/browse/IGNITE-11600 >> > >> (if >> > >> > we >> > >> > can't start using Java 12 we should clearly state it in >> scripts/code). >> > >> > >> > >> > We're entering to Stabilization phase for >> > >> > >> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.5 >> > >> and >> > >> > only blockers may be included into scope. See >> > >> > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process >> > for >> > >> > more >> > >> > details. >> > >> > >> > >> > Sincerely, >> > >> > Dmitriy Pavlov >> > >> > >> > >> > пт, 29 мар. 2019 г. в 13:51, Dmitriy Pavlov : >> > >> > >> > >> > > Hi Denis, >> > >> > > >> > >> > > I'm not talking about months. In this discussion, Andrey and Ivan >> > >> > proposed >> > >> > > a couple of fixes that may help. >> > >> > > >> > >> > > It will require a day or two to check if it helps. If it not >> helpful >> > >> then >> > >> > > we should modify startup scripts to say clearly that Java 12 is >> not >> > >> > > supported. >> > >> > > >> > >> > > Now under Java 12 Ignite suggests to set startup parameters, but >> > even >> > >> > with >> > >> > > correct parameters, it fails and says please set parameters. >> Totally >> > >> > > unclear for end-user. >> > >> > > >> > >> > > I've reopened https://issues.apache.org/jira/browse/IGNITE-11600 >> > >> > > >> > >> > > Sincerely, >> > >> > > Dmitriy Pavlov >> > >> > > >> > >> > > чт, 28 мар. 2019 г. в 18:51, Denis Magda : >> > >> > > >> > >> > >> If the failure handler improvements will lower down a number of >> > >> > >> false-positive cluster shutdowns then I'm for the fix inclusion >> to >> > >> the >> > >> > >> release. >> > >> > >> >> > >> > >> As for Java 12, I would put to the next release that we can make >> > >> shortly >> > >> > >> after this one. We don't need to wait for months if there are >> some >> > >> > urgent >> > >> > >> fixes. >> > >> > >> >> > >> > >> - >> > >> > >> Denis >> > >> > >> >> > >> > >> >> > >> >
Re: Consistency check and fix (review request)
Folks, I've checked the tx benchmarks and found no performance drop. Also, see no issues at TC results. So, seems, code ready to be merged. Everyone interested, please share any objections about - public API - test coverage - implementation approach On Wed, Apr 3, 2019 at 5:46 PM Anton Vinogradov wrote: > Nikolay, > > This is not a PoC, but the final solution (I hope so:) ) required the > review. > LWW means Last Write Wins, detailed explanation can be found at IEP-31. > > On Wed, Apr 3, 2019 at 5:24 PM Nikolay Izhikov > wrote: > >> Hello, Anton. >> >> Thanks for the PoC. >> >> > finds correct values according to LWW strategy >> >> Can you, please, clarify what is LWW strategy? >> >> В Ср, 03/04/2019 в 17:19 +0300, Anton Vinogradov пишет: >> > Ilya, >> > >> > This is impossible due to a conflict between some isolation levels and >> > get-with-consistency expectations. >> > Basically, it's impossible to perform get-with-consistency after the >> other >> > get at !READ_COMMITTED transaction. >> > The problem here is that value should be cached according to the >> isolation >> > level, so get-with-consistency is restricted in this case. >> > Same problem we have at case get-with-consistency after put, so we have >> > restriction here too. >> > So, the order matter. :) >> > >> > See OperationRestrictionsCacheConsistencyTest [1] for details. >> > >> > [1] >> > >> https://github.com/apache/ignite/blob/8b0b0c3e1bde93ff9c4eb5667d794dd64a8b06f0/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/consistency/OperationRestrictionsCacheConsistencyTest.java >> > >> > On Wed, Apr 3, 2019 at 4:54 PM Ilya Kasnacheev < >> ilya.kasnach...@gmail.com> >> > wrote: >> > >> > > Hello! >> > > >> > > Sounds useful especially for new feature development. >> > > >> > > Can you do a run of all tests with cache.forConsistency(), see if >> there are >> > > cases that fail? >> > > >> > > Regards, >> > > -- >> > > Ilya Kasnacheev >> > > >> > > >> > > ср, 3 апр. 2019 г. в 16:17, Anton Vinogradov : >> > > >> > > > Igniters, >> > > > >> > > > Sometimes, at real deployment, we're faced with inconsistent state >> across >> > > > the topology. >> > > > This means that somehow we have different values for the same key at >> > > > different nodes. >> > > > This is an extremely rare situation, but, when you have thousands of >> > > > terabytes of data, this can be a real problem. >> > > > >> > > > Apache Ignite provides a consistency guarantee, each affinity node >> should >> > > > contain the same value for the same key, at least eventually. >> > > > But this guarantee can be violated because of bugs, see IEP-31 [1] >> for >> > > > details. >> > > > >> > > > So, I created the issue [2] to handle such situations. >> > > > The main idea is to have a special cache.withConsistency() proxy >> allows >> > > > checking a fix inconsistency on get operation. >> > > > >> > > > I've created PR [3] with following improvements (when >> > > > cache.withConsistency() proxy used): >> > > > >> > > > - PESSIMISTIC && !READ_COMMITTED transaction >> > > > -- checks values across the topology (under locks), >> > > > -- finds correct values according to LWW strategy, >> > > > -- records special event in case consistency violation found >> (contains >> > > > inconsistent map > and last values ), >> > > > -- enlists writes with latest value for each inconsistent key, so >> it will >> > > > be written on tx.commit(). >> > > > >> > > > - OPTIMISTIC || READ_COMMITTED transactions >> > > > -- checks values across the topology (not under locks, so >> false-positive >> > > > case is possible), >> > > > -- starts PESSIMISTIC && SERIALIZABLE (at separate thread) >> transaction >> > > >> > > for >> > > > each possibly broken key and fixes it on a commit if necessary. >> > > > -- original transaction performs get-after-fix and can be continued >> if >> > > >> > > the >> > > > fix does not conflict with isolation level. >> > > > >> > > > Future plans >> > > > - Consistency guard (special process periodically checks we have no >> > > > inconsistency). >> > > > - MVCC support. >> > > > - Atomic caches support. >> > > > - Thin client support. >> > > > - SQL support. >> > > > - Read-with-consistency before the write operation. >> > > > - Single key read-with-consistency optimization, now the collection >> > > > approach used each time. >> > > > - Do not perform read-with-consistency for the key in case it was >> > > > consistently read some time ago. >> > > > >> > > > [1] >> > > > >> > > > >> > > >> > > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-31+Consistency+check+and+fix >> > > > [2] https://issues.apache.org/jira/browse/IGNITE-10663 >> > > > [3] https://github.com/apache/ignite/pull/5656 >> > > > >> >
[jira] [Created] (IGNITE-11736) Make the TeamCity console quiet.
Stepachev Maksim created IGNITE-11736: - Summary: Make the TeamCity console quiet. Key: IGNITE-11736 URL: https://issues.apache.org/jira/browse/IGNITE-11736 Project: Ignite Issue Type: Improvement Reporter: Stepachev Maksim Assignee: Stepachev Maksim As a result of this discussion: [https://lists.apache.org/list.html?dev@ignite.apache.org:lte=1M:Make%20the%20TeamCity%20console%20quiet.] 1. Rollover will be locked. Pros: Only one big file in an archive. Cons: Max size of the file isn't limited. 2. Run all will contain a parameter for switch off the quiet mode. 3. New config: log4j-tc-test.xml for TeamCity environment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11737) Apache Ignite 2.7.5 Linux packages version update
Peter Ivanov created IGNITE-11737: - Summary: Apache Ignite 2.7.5 Linux packages version update Key: IGNITE-11737 URL: https://issues.apache.org/jira/browse/IGNITE-11737 Project: Ignite Issue Type: Task Reporter: Peter Ivanov Assignee: Peter Ivanov Update DEB and RPM packages' versions in Apache Ignite for the next version (2.7.5) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11738) Incorrect check ObjectInput.available() in CacheMetricsSnapshot
Dmitriy Govorukhin created IGNITE-11738: --- Summary: Incorrect check ObjectInput.available() in CacheMetricsSnapshot Key: IGNITE-11738 URL: https://issues.apache.org/jira/browse/IGNITE-11738 Project: Ignite Issue Type: Bug Reporter: Dmitriy Govorukhin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11739) Refactoring of cache lifecycle and cache configuration management code
Sergey Chugunov created IGNITE-11739: Summary: Refactoring of cache lifecycle and cache configuration management code Key: IGNITE-11739 URL: https://issues.apache.org/jira/browse/IGNITE-11739 Project: Ignite Issue Type: Task Components: cache Reporter: Sergey Chugunov h2. Problem Currently code responsible for cache lifecycle and configuration management is spread across different entities (e.g. GridCacheProcessor, GridCacheAffinityManager, ClusterCachesInfo and so on). Cache configuration data is duplicated multiple times and presented in different forms from StoredCacheData to CacheGroupDescriptor to DynamicCacheDescriptor to ClusterCachesInfo. Altogether there is no entity nor abstraction which contains most of the logic of managing cache state and config and provides a clean API for this purpose. All this makes it hard to maintain the code, fix bugs and make improvements so need for refactoring and benefits from it are obvious. h2. Approaches # Build state machine manipulating immutable state objects to reflect transitions between states. # Concentrate all cache-related info into a new (abstraction like cache container) or existing (e.g. cache context) mutable entity and manipulate that entity to reflect evolution of cache. # Some mix of these two approaches. There are already plenty of entities like CacheInfo or CacheDescriptor with names suggesting they contain information about cache. The problem though is that each of these entities manages only some part of information. Regardless of which approach is used clear and well documented API should be provided for managing lifecycle and configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[MTCGA]: new failures in builds [3493640] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *Recently contributed test failed in master tests.CassandraDirectPersistenceTest https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=668958014111408205&branch=%3Cdefault%3E&tab=testDetails No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 08:53:19 13-04-2019
