Re: Launched Ignite meetups and redesigned events pages
Hi Igniters, Mauricio, Ignacio, and Denis, Thank you all for updating these pages. I would like to stress just one thing: should you have in mind some topic you can run talk about, please feel absolutely free to fill submission proposal. To submit proposal you need to fill in this form https://docs.google.com/forms/d/e/1FAIpQLSdiY7movHKvyWg3gOVedHgukJJnNiaejSO_X838vBseL9VmiQ/viewform . Sincerely, Dmitriy Pavlov вт, 7 янв. 2020 г. в 02:48, Denis Magda : > Igniters, > > I've just merged changes contributed by Mauricio and Ignacio, who helped > us to prepare professional webpages for Ignite meetup groups around the > world [1] and for Ignite events [2]. Now you can easily enroll in a meetup > group nearby or sign up for an upcoming event to be hosted one of our > experts. > > Please check them out and share your feedback. In the meantime, three of > us are going to carry on with optimizations and changes making the website > more useful for developers as well as more searchable/discoverable from > various search engines. > > [1] https://ignite.apache.org/meetup-groups.html > [2] https://ignite.apache.org/events.html > > - > Denis >
[ANNOUNCE] New Apache Ignite PMC member: Saikat Maitra
Hello Ignite Community, The Project Management Committee (PMC) for Apache Ignite has invited Saikat Maitra to join the PMC as a new member and we are pleased to announce that he has accepted. Saikat joined the community a long time ago and earned the role of a committer by integrating Ignite with various streaming technologies. Since those times Saikat keeps maintaining his contributions and helps newcomers with their first tasks and reviews. Also, he is involved in a much larger modularization initiative and does his first public presentations about Apache Ignite. Being a PMC member enables assistance with the management and to guide the direction of the project. Best Regards, Dmitriy Pavlov on behalf of Apache Ignite PMC
Re: [ANNOUNCE] New Apache Ignite PMC member: Saikat Maitra
Saikat, Congratulations and many thanks for your efforts! чт, 9 янв. 2020 г. в 13:20, Dmitriy Pavlov : > > Hello Ignite Community, > > > > The Project Management Committee (PMC) for Apache Ignite has invited Saikat > Maitra to join the PMC as a new member and we are pleased to announce that > he has accepted. > > > > Saikat joined the community a long time ago and earned the role of a > committer by integrating Ignite with various streaming technologies. Since > those times Saikat keeps maintaining his contributions and helps newcomers > with their first tasks and reviews. Also, he is involved in a much larger > modularization initiative and does his first public presentations about > Apache Ignite. > > > > Being a PMC member enables assistance with the management and to guide the > direction of the project. > > > > Best Regards, > > Dmitriy Pavlov > > on behalf of Apache Ignite PMC -- Best regards, Ivan Pavlukhin
Re: Partition reserve/release asymmetry
Hello Anton, Thanks for digging into this. The logic with checking the reservations count seems fishy to me as well, so I have no objections with the suggested change. This "if" statement does not answer why the partition was being destroyed during the commit, though. Does the issue reproduce in subsequent runs? The logic around reserve/release seems ok to me, however, the eviction/renting code looks overly complicated, perhaps, there is a bug somewhere there? I think we can add an assertion to GridDhtLocalPartition#destroy() method to check that reservations is 0 when this method is called (there is a check for EVICTED state already there) --AG чт, 9 янв. 2020 г. в 09:45, Anton Vinogradov : > Folks, > Yardstick run (opt-serial-put-get-1-backup) failed with interesting > exception: > Critical system error detected. Will be handled accordingly to configured > handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], > failureCtx=FailureContext [type=CRITICAL_ERROR, err=class > o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing a > transaction has produced runtime exception]] > class > org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: > Committing a transaction has produced runtime exception > at > > org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800) > at > > org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:838) > at > > org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:893) > at > > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1452) > at > > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1375) > at > > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:123) > at > > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:241) > at > > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:239) > at > > org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142) > at > > org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591) > at > > org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392) > at > > org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318) > at > > org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109) > at > > org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308) > at > > org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1843) > at > > org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1468) > at > > org.apache.ignite.internal.managers.communication.GridIoManager.access$5200(GridIoManager.java:229) > at > > org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1365) > at > > org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:555) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalStateException: Tree is being concurrently > destroyed: tx-p-470##CacheData > at > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.checkDestroyed(BPlusTree.java:1011) > at > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1831) > at > > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1696) > at > > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1679) > at > > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:441) > at > > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:4288) > at > > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:4262) > at > > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerSet(GridCacheMapEntry.java:1540) > at > > org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistribute
Re: How to use spark-2.4 module in Ignite 2.8?
Hi, I've found a bug in pom. It will be fixed on next week in master and release branches. Thank for the message! ср, 18 дек. 2019 г. в 22:11, Denis Magda : > Alexey, Nikolay, > > Could you please step in and shed some light on what has changed with > Spark? Probably, that's an issue that needs to be addressed before the > release. > > - > Denis > > > On Wed, Dec 18, 2019 at 9:26 AM Stefan Miklosovic < > stefan.mikloso...@instaclustr.com> wrote: > >> Hi, >> >> I want to try spark-2.4 module committed recently but I do not see >> spark-2.4 directory in optional dir after I build whole Ignite >> distribution. >> >> I am building like this: >> >> mvn clean install -Pall-java,all-scala,licenses -DskipTests && mvn >> initialize -Prelease >> >> Why is there just "spark" but not "spark-2.4" even "spark-2.4" is in >> all-scala profile? >> >> Cheers >> >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Maxim M. and anyone who is interested, I suggest to include this fix to 2.8 release: https://issues.apache.org/jira/browse/IGNITE-12225 Basically, it's a result of the following discussion: http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Single-point-in-API-for-changing-cluster-state-td43665.html The fix affects public API: IgniteCluster#readOnly methods that work with boolean are replaced with ones that work with enum. If we include it, we won't be obliged to keep deprecated boolean version of API in the code (which is currently present in 2.8 branch) as it wasn't published in any release. On Tue, Dec 31, 2019 at 3:54 PM Ilya Kasnacheev wrote: > Hello! > > I have ran dependency checker plugin and quote the following: > > One or more dependencies were identified with known vulnerabilities in > ignite-urideploy: > One or more dependencies were identified with known vulnerabilities in > ignite-spring: > One or more dependencies were identified with known vulnerabilities in > ignite-spring-data: > One or more dependencies were identified with known vulnerabilities in > ignite-aop: > One or more dependencies were identified with known vulnerabilities in > ignite-visor-console: > > spring-core-4.3.18.RELEASE.jar > (pkg:maven/org.springframework/spring-core@4.3.18.RELEASE, > cpe:2.3:a:pivotal_software:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > cpe:2.3:a:springsource:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > cpe:2.3:a:vmware:springsource_spring_framework:4.3.18:*:*:*:*:*:*:*) : > CVE-2018-15756 > > One or more dependencies were identified with known vulnerabilities in > ignite-spring-data_2.0: > > spring-core-5.0.8.RELEASE.jar > (pkg:maven/org.springframework/spring-core@5.0.8.RELEASE, > cpe:2.3:a:pivotal_software:spring_framework:5.0.8.release:*:*:*:*:*:*:*, > cpe:2.3:a:springsource:spring_framework:5.0.8.release:*:*:*:*:*:*:*, > cpe:2.3:a:vmware:springsource_spring_framework:5.0.8:*:*:*:*:*:*:*) : > CVE-2018-15756 > > One or more dependencies were identified with known vulnerabilities in > ignite-rest-http: > > jetty-server-9.4.11.v20180605.jar > (pkg:maven/org.eclipse.jetty/jetty-server@9.4.11.v20180605, > cpe:2.3:a:eclipse:jetty:9.4.11:20180605:*:*:*:*:*:*, > cpe:2.3:a:jetty:jetty:9.4.11.v20180605:*:*:*:*:*:*:*, > cpe:2.3:a:mortbay_jetty:jetty:9.4.11:20180605:*:*:*:*:*:*) : > CVE-2018-12545, CVE-2019-10241, CVE-2019-10247 > jackson-databind-2.9.6.jar > (pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.6, > cpe:2.3:a:fasterxml:jackson:2.9.6:*:*:*:*:*:*:*, > cpe:2.3:a:fasterxml:jackson-databind:2.9.6:*:*:*:*:*:*:*) : > CVE-2018-1000873, CVE-2018-14718, CVE-2018-14719, CVE-2018-14720, > CVE-2018-14721, CVE-2018-19360, CVE-2018-19361, CVE-2018-19362, > CVE-2019-12086, CVE-2019-12384, CVE-2019-12814, CVE-2019-14379, > CVE-2019-14439, CVE-2019-14540, CVE-2019-16335, CVE-2019-16942, > CVE-2019-16943, CVE-2019-17267, CVE-2019-17531 > > One or more dependencies were identified with known vulnerabilities in > ignite-kubernetes: > One or more dependencies were identified with known vulnerabilities in > ignite-aws: > > jackson-databind-2.9.6.jar > (pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.6, > cpe:2.3:a:fasterxml:jackson:2.9.6:*:*:*:*:*:*:*, > cpe:2.3:a:fasterxml:jackson-databind:2.9.6:*:*:*:*:*:*:*) : > CVE-2018-1000873, CVE-2018-14718, CVE-2018-14719, CVE-2018-14720, > CVE-2018-14721, CVE-2018-19360, CVE-2018-19361, CVE-2018-19362, > CVE-2019-12086, CVE-2019-12384, CVE-2019-12814, CVE-2019-14379, > CVE-2019-14439, CVE-2019-14540, CVE-2019-16335, CVE-2019-16942, > CVE-2019-16943, CVE-2019-17267, CVE-2019-17531 > bcprov-ext-jdk15on-1.54.jar > (pkg:maven/org.bouncycastle/bcprov-ext-jdk15on@1.54) : CVE-2015-6644, > CVE-2016-1000338, CVE-2016-1000339, CVE-2016-1000340, CVE-2016-1000341, > CVE-2016-1000342, CVE-2016-1000343, CVE-2016-1000344, CVE-2016-1000345, > CVE-2016-1000346, CVE-2016-1000352, CVE-2016-2427, CVE-2017-13098, > CVE-2018-1000180, CVE-2018-1000613 > > One or more dependencies were identified with known vulnerabilities in > ignite-gce: > > httpclient-4.0.1.jar (pkg:maven/org.apache.httpcomponents/httpclient@4.0.1 > , > cpe:2.3:a:apache:httpclient:4.0.1:*:*:*:*:*:*:*) : CVE-2011-1498, > CVE-2014-3577, CVE-2015-5262 > guava-jdk5-17.0.jar (pkg:maven/com.google.guava/guava-jdk5@17.0, > cpe:2.3:a:google:guava:17.0:*:*:*:*:*:*:*) : CVE-2018-10237 > > One or more dependencies were identified with known vulnerabilities in > ignite-cloud: > > openstack-keystone-2.0.0.jar > (pkg:maven/org.apache.jclouds.api/openstack-keystone@2.0.0, > cpe:2.3:a:openstack:keystone:2.0.0:*:*:*:*:*:*:*, > cpe:2.3:a:openstack:openstack:2.0.0:*:*:*:*:*:*:*) : CVE-2013-2014, > CVE-2013-4222, CVE-2013-6391, CVE-2014-0204, CVE-2014-3476, CVE-2014-3520, > CVE-2014-3621, CVE-2015-3646, CVE-2015-7546, CVE-2018-14432, CVE-2018-20170 > cloudstack-2.0.0.jar (pkg:maven/org.apache.jclouds.api/cloudstack@2.0.0, > cpe:2.3:a:apache:cloudstack:2.0.0:*:*:*:*:*:*:*) : CVE-2013-2136, > CVE-2013-639
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
+1 чт, 9 янв. 2020 г. в 16:38, Ivan Rakov : > > Maxim M. and anyone who is interested, > > I suggest to include this fix to 2.8 release: > https://issues.apache.org/jira/browse/IGNITE-12225 > Basically, it's a result of the following discussion: > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Single-point-in-API-for-changing-cluster-state-td43665.html > > The fix affects public API: IgniteCluster#readOnly methods that work with > boolean are replaced with ones that work with enum. > If we include it, we won't be obliged to keep deprecated boolean version of > API in the code (which is currently present in 2.8 branch) as it wasn't > published in any release. > > On Tue, Dec 31, 2019 at 3:54 PM Ilya Kasnacheev > wrote: > > > Hello! > > > > I have ran dependency checker plugin and quote the following: > > > > One or more dependencies were identified with known vulnerabilities in > > ignite-urideploy: > > One or more dependencies were identified with known vulnerabilities in > > ignite-spring: > > One or more dependencies were identified with known vulnerabilities in > > ignite-spring-data: > > One or more dependencies were identified with known vulnerabilities in > > ignite-aop: > > One or more dependencies were identified with known vulnerabilities in > > ignite-visor-console: > > > > spring-core-4.3.18.RELEASE.jar > > (pkg:maven/org.springframework/spring-core@4.3.18.RELEASE, > > cpe:2.3:a:pivotal_software:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > > cpe:2.3:a:springsource:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > > cpe:2.3:a:vmware:springsource_spring_framework:4.3.18:*:*:*:*:*:*:*) : > > CVE-2018-15756 > > > > One or more dependencies were identified with known vulnerabilities in > > ignite-spring-data_2.0: > > > > spring-core-5.0.8.RELEASE.jar > > (pkg:maven/org.springframework/spring-core@5.0.8.RELEASE, > > cpe:2.3:a:pivotal_software:spring_framework:5.0.8.release:*:*:*:*:*:*:*, > > cpe:2.3:a:springsource:spring_framework:5.0.8.release:*:*:*:*:*:*:*, > > cpe:2.3:a:vmware:springsource_spring_framework:5.0.8:*:*:*:*:*:*:*) : > > CVE-2018-15756 > > > > One or more dependencies were identified with known vulnerabilities in > > ignite-rest-http: > > > > jetty-server-9.4.11.v20180605.jar > > (pkg:maven/org.eclipse.jetty/jetty-server@9.4.11.v20180605, > > cpe:2.3:a:eclipse:jetty:9.4.11:20180605:*:*:*:*:*:*, > > cpe:2.3:a:jetty:jetty:9.4.11.v20180605:*:*:*:*:*:*:*, > > cpe:2.3:a:mortbay_jetty:jetty:9.4.11:20180605:*:*:*:*:*:*) : > > CVE-2018-12545, CVE-2019-10241, CVE-2019-10247 > > jackson-databind-2.9.6.jar > > (pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.6, > > cpe:2.3:a:fasterxml:jackson:2.9.6:*:*:*:*:*:*:*, > > cpe:2.3:a:fasterxml:jackson-databind:2.9.6:*:*:*:*:*:*:*) : > > CVE-2018-1000873, CVE-2018-14718, CVE-2018-14719, CVE-2018-14720, > > CVE-2018-14721, CVE-2018-19360, CVE-2018-19361, CVE-2018-19362, > > CVE-2019-12086, CVE-2019-12384, CVE-2019-12814, CVE-2019-14379, > > CVE-2019-14439, CVE-2019-14540, CVE-2019-16335, CVE-2019-16942, > > CVE-2019-16943, CVE-2019-17267, CVE-2019-17531 > > > > One or more dependencies were identified with known vulnerabilities in > > ignite-kubernetes: > > One or more dependencies were identified with known vulnerabilities in > > ignite-aws: > > > > jackson-databind-2.9.6.jar > > (pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.6, > > cpe:2.3:a:fasterxml:jackson:2.9.6:*:*:*:*:*:*:*, > > cpe:2.3:a:fasterxml:jackson-databind:2.9.6:*:*:*:*:*:*:*) : > > CVE-2018-1000873, CVE-2018-14718, CVE-2018-14719, CVE-2018-14720, > > CVE-2018-14721, CVE-2018-19360, CVE-2018-19361, CVE-2018-19362, > > CVE-2019-12086, CVE-2019-12384, CVE-2019-12814, CVE-2019-14379, > > CVE-2019-14439, CVE-2019-14540, CVE-2019-16335, CVE-2019-16942, > > CVE-2019-16943, CVE-2019-17267, CVE-2019-17531 > > bcprov-ext-jdk15on-1.54.jar > > (pkg:maven/org.bouncycastle/bcprov-ext-jdk15on@1.54) : CVE-2015-6644, > > CVE-2016-1000338, CVE-2016-1000339, CVE-2016-1000340, CVE-2016-1000341, > > CVE-2016-1000342, CVE-2016-1000343, CVE-2016-1000344, CVE-2016-1000345, > > CVE-2016-1000346, CVE-2016-1000352, CVE-2016-2427, CVE-2017-13098, > > CVE-2018-1000180, CVE-2018-1000613 > > > > One or more dependencies were identified with known vulnerabilities in > > ignite-gce: > > > > httpclient-4.0.1.jar (pkg:maven/org.apache.httpcomponents/httpclient@4.0.1 > > , > > cpe:2.3:a:apache:httpclient:4.0.1:*:*:*:*:*:*:*) : CVE-2011-1498, > > CVE-2014-3577, CVE-2015-5262 > > guava-jdk5-17.0.jar (pkg:maven/com.google.guava/guava-jdk5@17.0, > > cpe:2.3:a:google:guava:17.0:*:*:*:*:*:*:*) : CVE-2018-10237 > > > > One or more dependencies were identified with known vulnerabilities in > > ignite-cloud: > > > > openstack-keystone-2.0.0.jar > > (pkg:maven/org.apache.jclouds.api/openstack-keystone@2.0.0, > > cpe:2.3:a:openstack:keystone:2.0.0:*:*:*:*:*:*:*, > > cpe:2.3:a:openstack:openstack:2.0.0:*:*:*:*:*:*:*) : CVE-2013-2014, > > CVE-2013-4222, CVE-2013-6391, CVE-2014-0204, CVE-2014-3
Hint for user that baseline topology should be changed in order to trigger rebalance
Folks, Since 2.4, Ignite cluster requires baseline topology in persistent mode. That means if user wants to scale cluster and add more nodes, data won't be redistributed among the whole node set until manual call of IgniteCluster#setBaselineTopology. Surely this behavior is well-documented, but don't we need to give user a hint that baseline topology should be managed manually? I think, log message with something like "Current set of nodes differs from baseline topology, please call XXX in order to trigger rebalance and redistribute your data" will make the situation a bit more transparent. Right now we have only this message > [2020-01-07T19:36:45,997][INFO > ][exchange-worker-#39%blue-54.158.100.161%][GridCachePartitionExchangeManager] > Skipping > rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=2, > minorTopVer=0], force=false, evt=NODE_JOINED, node=57bc10fe-1505-4e8e-9987- > 52c9c903c6ef] which doesn't properly explain what's going on.
Re: Hint for user that baseline topology should be changed in order to trigger rebalance
Hello, I think, log > message with something like "Current set of nodes differs from baseline > topology, please call XXX in order to trigger rebalance and redistribute > your data" will make the situation a bit more transparent. Yes, this seems reasonable to me when the baseline auto-adjust feature is disabled. Thanks, S. чт, 9 янв. 2020 г. в 17:21, Ivan Rakov : > Folks, > > Since 2.4, Ignite cluster requires baseline topology in persistent mode. > That means if user wants to scale cluster and add more nodes, data won't be > redistributed among the whole node set until manual call of > IgniteCluster#setBaselineTopology. > > Surely this behavior is well-documented, but don't we need to give user a > hint that baseline topology should be managed manually? I think, log > message with something like "Current set of nodes differs from baseline > topology, please call XXX in order to trigger rebalance and redistribute > your data" will make the situation a bit more transparent. > > Right now we have only this message > > > [2020-01-07T19:36:45,997][INFO > > > ][exchange-worker-#39%blue-54.158.100.161%][GridCachePartitionExchangeManager] > Skipping > > rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=2, > > minorTopVer=0], force=false, evt=NODE_JOINED, > node=57bc10fe-1505-4e8e-9987- > > 52c9c903c6ef] > > which doesn't properly explain what's going on. >
[jira] [Created] (IGNITE-12522) Extend test coverage [IGNITE-12104] Check deployment from cache before to load it from local or version storage
Vladislav Pyatkov created IGNITE-12522: -- Summary: Extend test coverage [IGNITE-12104] Check deployment from cache before to load it from local or version storage Key: IGNITE-12522 URL: https://issues.apache.org/jira/browse/IGNITE-12522 Project: Ignite Issue Type: Improvement Reporter: Vladislav Pyatkov -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Improve logging of Data Region configuration
Hello again! TC passes, review is ready. Your last chance to act before merge! Regards, -- Ilya Kasnacheev вт, 31 дек. 2019 г. в 16:01, Ilya Kasnacheev : > Hello! > > I have prepared a patch, please review. It will look like this: > > Data Regions Started: 4 > ^-- sysMemPlc region [type=internal, persistence=true, lazyAlloc=false, > ... initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=100%, > allocRam=100MB, allocTotal=0MB] > ^-- default region [type=default, persistence=true, lazyAlloc=true, > ... initCfg=30MB, maxCfg=30MB, usedRam=0MB, freeRam=100%, > allocRam=0MB, allocTotal=0MB] > ^-- metastoreMemPlc region [type=internal, persistence=true, > lazyAlloc=false, > ... initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=100%, > allocRam=100MB, allocTotal=0MB] > ^-- TxLog region [type=internal, persistence=true, lazyAlloc=false, > ... initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=100%, > allocRam=100MB, allocTotal=0MB] > ^-- Ignite persistence [used=0MB] > ... > Metrics for local node (to disable set 'metricsLogFrequency' to 0) > ^-- Node [id=9e6c8e45, name=internal.GridNodeMetricsLogPdsSelfTest0, > uptime=00:00:12.271] > ^-- Cluster [hosts=1, CPUs=8, servers=2, clients=0, topVer=2, > minorTopVer=3] > ^-- Network [addrs=[127.0.0.1], localHost=127.0.0.1, discoPort=47500, > commPort=45010] > ^-- CPU [CPUs=8, curLoad=2.7%, avgLoad=3.38%, GC=0%] > ^-- Heap [used=48MB, free=99.32%, comm=564MB] > ^-- Off-heap memory [used=0MB, free=99.96%, allocated=230MB] > ^-- Page memory [pages=34] > ^-- sysMemPlc region [type=internal, persistence=true, lazyAlloc=false, > ... initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=99.98%, > allocRam=100MB, allocTotal=0MB] > ^-- default region [type=default, persistence=true, lazyAlloc=true, > ... initCfg=30MB, maxCfg=30MB, usedRam=0MB, freeRam=99.75%, > allocRam=30MB, allocTotal=0MB] > ^-- metastoreMemPlc region [type=internal, persistence=true, > lazyAlloc=false, > ... initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=99.96%, > allocRam=0MB, allocTotal=0MB] > ^-- TxLog region [type=internal, persistence=true, lazyAlloc=false, > ... initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=100%, > allocRam=100MB, allocTotal=0MB] > ^-- Ignite persistence [used=0MB] > ^-- Outbound messages queue [size=0] > ^-- Public thread pool [active=0, idle=6, qSize=0] > ^-- System thread pool [active=0, idle=8, qSize=0] > ^-- Custom executor 0 [active=0, idle=0, qSize=0] > ^-- Custom executor 1 [active=0, idle=0, qSize=0] > > > Regards, > -- > Ilya Kasnacheev > > > пт, 27 дек. 2019 г. в 15:03, Ilya Kasnacheev : > >> Hello! >> >> I have filed a ticket about this improvement, plan to start on coding. >> >> https://issues.apache.org/jira/browse/IGNITE-12505 >> >> Regards, >> -- >> Ilya Kasnacheev >> >> >> чт, 26 дек. 2019 г. в 12:50, Ilya Kasnacheev : >> >>> Hello! >>> >>> Okay, I will mark default region. >>> >>> We already log information about internal memory regions, so removing it >>> will require a lot of consensus. However, I can clearly map them as system >>> regions when printing. >>> >>> Regards, >>> -- >>> Ilya Kasnacheev >>> >>> >>> чт, 26 дек. 2019 г. в 12:10, Ivan Pavlukhin : >>> Ilya, Indeed the matters can be improved. Is not it useful to mark what region is default? Also some doubts about internal memory regions. It is not obvious that we should print an information about them for every user. If we need to have some determinism about offheap memory than I can think about logging amounts for internal needs of total ones (a sum for all regions). вт, 24 дек. 2019 г. в 15:38, Ilya Kasnacheev : > > Hello! > > It came to my attention that we output data regions' configurations twice > when starting node, but we never output list of data regions (including > system, etc) that were actually started. > > First we have IgniteConfiguration printed (quiet=false): > 2019-07-24 02:33:33.918[INFO ][Thread-139][o.a.i.i.IgniteKernal%GridNodeName > ] IgniteConfiguration [... dfltDataRegConf=DataRegionConfiguration [name= > mem_plc, maxSize=635655159808, initSize=268435456, swapPath=null, > pageEvictionMode=DISABLED, evictionThreshold=0.9, emptyPagesPoolSize=100, > metricsEnabled=true, metricsSubIntervalCount=5, metricsRateTimeInterval=1000 > , persistenceEnabled=true, checkpointPageBufSize=17179869184], storagePath=/ > ssd/data, checkpointFreq=3, lockWaitTime=1, checkpointThreads=4, > checkpointWriteOrder=SEQUENTIAL, walHistSize=2147483647, walSegments=10, > walSegmentSize=1073741824, walPath=/ssd/data/wal, walArchivePath=/sas/ > wal_archive, metricsEnabled=false, walMode=LOG_ONLY, walTlbSize=131072, > walBuffSize=5242880, walFlu
[jira] [Created] (IGNITE-12523) Continuously generated thread dumps in failure processor slow down the whole system
Andrey N. Gura created IGNITE-12523: --- Summary: Continuously generated thread dumps in failure processor slow down the whole system Key: IGNITE-12523 URL: https://issues.apache.org/jira/browse/IGNITE-12523 Project: Ignite Issue Type: Improvement Reporter: Andrey N. Gura Assignee: Andrey N. Gura Fix For: 2.9 A lot of threads (hundreds) build indexes. checkpoint-thread tries acquire write lock but can’t because some threads hold read lock. Moreover, some threads try to acquire read lock too. Failure types SYSTEM_WORKER_BLOCKED and SYSTEM_CRITICAL_OPERATION_TIMEOUT are ignored. checkpoint-thread treated as blocked critical system worker. So failure processor gets thread dump. Threads that waiting on read lock reports about SYSTEM_CRITICAL_OPERATION_TIMEOUT and also get thread dump. Thread dump generation takes from 500 to 1000 ms. All this activity leads to stop-the-world pause and triggers other timeouts. It could take long time because many threads are active and half time is thread dump generation. Root cause problem here is checkpoint read-write lock. Discussed with [~agoncharuk]Alexey Goncharuk and it seems only implementation of fuzzy checkpoint could solve the problem. But it requires big effort. *Solution* Andrey Gura December 20, 2019, 3:18 PM Edited Final solution and implementation: - New system property IGNITE_DUMP_THREADS_ON_FAILURE_THROTTLING_TIMEOUT added. Default value is failure detection timeout. - Each call of FailureProcessor#process(FailureContext, FailureHandler) method checka throttling timeout before thread dump generation. - There is no need to check that failure type is ignored. Throttling will be useful for all cases when context is not invalidated (FailureProcessor.failureCtx != null). - For throttled thread dump we log info message “Thread dump is hidden due to throttling settings. Set IGNITE_DUMP_THREADS_ON_FAILURE_THROTTLING_TIMEOUT property to 0 to see all thread dumps". -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Hint for user that baseline topology should be changed in order to trigger rebalance
Hello! Can we perhaps add this as a blocker to 2.8? Perhaps by correlating with https://issues.apache.org/jira/browse/IGNITE-12504 Regards, -- Ilya Kasnacheev чт, 9 янв. 2020 г. в 17:59, Вячеслав Коптилин : > Hello, > > I think, log > > message with something like "Current set of nodes differs from baseline > > topology, please call XXX in order to trigger rebalance and redistribute > > your data" will make the situation a bit more transparent. > > Yes, this seems reasonable to me when the baseline auto-adjust feature is > disabled. > > Thanks, > S. > > чт, 9 янв. 2020 г. в 17:21, Ivan Rakov : > > > Folks, > > > > Since 2.4, Ignite cluster requires baseline topology in persistent mode. > > That means if user wants to scale cluster and add more nodes, data won't > be > > redistributed among the whole node set until manual call of > > IgniteCluster#setBaselineTopology. > > > > Surely this behavior is well-documented, but don't we need to give user a > > hint that baseline topology should be managed manually? I think, log > > message with something like "Current set of nodes differs from baseline > > topology, please call XXX in order to trigger rebalance and redistribute > > your data" will make the situation a bit more transparent. > > > > Right now we have only this message > > > > > [2020-01-07T19:36:45,997][INFO > > > > > > ][exchange-worker-#39%blue-54.158.100.161%][GridCachePartitionExchangeManager] > > Skipping > > > rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=2, > > > minorTopVer=0], force=false, evt=NODE_JOINED, > > node=57bc10fe-1505-4e8e-9987- > > > 52c9c903c6ef] > > > > which doesn't properly explain what's going on. > > >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
+1 I'm preparing patch for 2.8 branch now. TC Bot visa for 2.8 branch will be at 13 Jan чт, 9 янв. 2020 г., 21:06 Ivan Pavlukhin : > +1 > > чт, 9 янв. 2020 г. в 16:38, Ivan Rakov : > > > > Maxim M. and anyone who is interested, > > > > I suggest to include this fix to 2.8 release: > > https://issues.apache.org/jira/browse/IGNITE-12225 > > Basically, it's a result of the following discussion: > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Single-point-in-API-for-changing-cluster-state-td43665.html > > > > The fix affects public API: IgniteCluster#readOnly methods that work with > > boolean are replaced with ones that work with enum. > > If we include it, we won't be obliged to keep deprecated boolean version > of > > API in the code (which is currently present in 2.8 branch) as it wasn't > > published in any release. > > > > On Tue, Dec 31, 2019 at 3:54 PM Ilya Kasnacheev < > ilya.kasnach...@gmail.com> > > wrote: > > > > > Hello! > > > > > > I have ran dependency checker plugin and quote the following: > > > > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-urideploy: > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-spring: > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-spring-data: > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-aop: > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-visor-console: > > > > > > spring-core-4.3.18.RELEASE.jar > > > (pkg:maven/org.springframework/spring-core@4.3.18.RELEASE, > > > > cpe:2.3:a:pivotal_software:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > > > cpe:2.3:a:springsource:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > > > cpe:2.3:a:vmware:springsource_spring_framework:4.3.18:*:*:*:*:*:*:*) : > > > CVE-2018-15756 > > > > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-spring-data_2.0: > > > > > > spring-core-5.0.8.RELEASE.jar > > > (pkg:maven/org.springframework/spring-core@5.0.8.RELEASE, > > > > cpe:2.3:a:pivotal_software:spring_framework:5.0.8.release:*:*:*:*:*:*:*, > > > cpe:2.3:a:springsource:spring_framework:5.0.8.release:*:*:*:*:*:*:*, > > > cpe:2.3:a:vmware:springsource_spring_framework:5.0.8:*:*:*:*:*:*:*) : > > > CVE-2018-15756 > > > > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-rest-http: > > > > > > jetty-server-9.4.11.v20180605.jar > > > (pkg:maven/org.eclipse.jetty/jetty-server@9.4.11.v20180605, > > > cpe:2.3:a:eclipse:jetty:9.4.11:20180605:*:*:*:*:*:*, > > > cpe:2.3:a:jetty:jetty:9.4.11.v20180605:*:*:*:*:*:*:*, > > > cpe:2.3:a:mortbay_jetty:jetty:9.4.11:20180605:*:*:*:*:*:*) : > > > CVE-2018-12545, CVE-2019-10241, CVE-2019-10247 > > > jackson-databind-2.9.6.jar > > > (pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.6, > > > cpe:2.3:a:fasterxml:jackson:2.9.6:*:*:*:*:*:*:*, > > > cpe:2.3:a:fasterxml:jackson-databind:2.9.6:*:*:*:*:*:*:*) : > > > CVE-2018-1000873, CVE-2018-14718, CVE-2018-14719, CVE-2018-14720, > > > CVE-2018-14721, CVE-2018-19360, CVE-2018-19361, CVE-2018-19362, > > > CVE-2019-12086, CVE-2019-12384, CVE-2019-12814, CVE-2019-14379, > > > CVE-2019-14439, CVE-2019-14540, CVE-2019-16335, CVE-2019-16942, > > > CVE-2019-16943, CVE-2019-17267, CVE-2019-17531 > > > > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-kubernetes: > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-aws: > > > > > > jackson-databind-2.9.6.jar > > > (pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.6, > > > cpe:2.3:a:fasterxml:jackson:2.9.6:*:*:*:*:*:*:*, > > > cpe:2.3:a:fasterxml:jackson-databind:2.9.6:*:*:*:*:*:*:*) : > > > CVE-2018-1000873, CVE-2018-14718, CVE-2018-14719, CVE-2018-14720, > > > CVE-2018-14721, CVE-2018-19360, CVE-2018-19361, CVE-2018-19362, > > > CVE-2019-12086, CVE-2019-12384, CVE-2019-12814, CVE-2019-14379, > > > CVE-2019-14439, CVE-2019-14540, CVE-2019-16335, CVE-2019-16942, > > > CVE-2019-16943, CVE-2019-17267, CVE-2019-17531 > > > bcprov-ext-jdk15on-1.54.jar > > > (pkg:maven/org.bouncycastle/bcprov-ext-jdk15on@1.54) : CVE-2015-6644, > > > CVE-2016-1000338, CVE-2016-1000339, CVE-2016-1000340, CVE-2016-1000341, > > > CVE-2016-1000342, CVE-2016-1000343, CVE-2016-1000344, CVE-2016-1000345, > > > CVE-2016-1000346, CVE-2016-1000352, CVE-2016-2427, CVE-2017-13098, > > > CVE-2018-1000180, CVE-2018-1000613 > > > > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-gce: > > > > > > httpclient-4.0.1.jar > (pkg:maven/org.apache.httpcomponents/httpclient@4.0.1 > > > , > > > cpe:2.3:a:apache:httpclient:4.0.1:*:*:*:*:*:*:*) : CVE-2011-1498, > > > CVE-2014-3577, CVE-2015-5262 > > > guava-jdk5-17.0.jar (pkg:maven/com.google.guava/guava-jdk5@17.0, > > > cpe:2.3:a:google:guava:17.0:*:*:*:*:*:*:*) : CVE-2018-10237 > > > >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
+1 чт, 9 янв. 2020 г. в 18:52, Sergey Antonov : > +1 > > I'm preparing patch for 2.8 branch now. TC Bot visa for 2.8 branch will be > at 13 Jan > > чт, 9 янв. 2020 г., 21:06 Ivan Pavlukhin : > > > +1 > > > > чт, 9 янв. 2020 г. в 16:38, Ivan Rakov : > > > > > > Maxim M. and anyone who is interested, > > > > > > I suggest to include this fix to 2.8 release: > > > https://issues.apache.org/jira/browse/IGNITE-12225 > > > Basically, it's a result of the following discussion: > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Single-point-in-API-for-changing-cluster-state-td43665.html > > > > > > The fix affects public API: IgniteCluster#readOnly methods that work > with > > > boolean are replaced with ones that work with enum. > > > If we include it, we won't be obliged to keep deprecated boolean > version > > of > > > API in the code (which is currently present in 2.8 branch) as it wasn't > > > published in any release. > > > > > > On Tue, Dec 31, 2019 at 3:54 PM Ilya Kasnacheev < > > ilya.kasnach...@gmail.com> > > > wrote: > > > > > > > Hello! > > > > > > > > I have ran dependency checker plugin and quote the following: > > > > > > > > One or more dependencies were identified with known vulnerabilities > in > > > > ignite-urideploy: > > > > One or more dependencies were identified with known vulnerabilities > in > > > > ignite-spring: > > > > One or more dependencies were identified with known vulnerabilities > in > > > > ignite-spring-data: > > > > One or more dependencies were identified with known vulnerabilities > in > > > > ignite-aop: > > > > One or more dependencies were identified with known vulnerabilities > in > > > > ignite-visor-console: > > > > > > > > spring-core-4.3.18.RELEASE.jar > > > > (pkg:maven/org.springframework/spring-core@4.3.18.RELEASE, > > > > > > cpe:2.3:a:pivotal_software:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > > > > cpe:2.3:a:springsource:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > > > > cpe:2.3:a:vmware:springsource_spring_framework:4.3.18:*:*:*:*:*:*:*) > : > > > > CVE-2018-15756 > > > > > > > > One or more dependencies were identified with known vulnerabilities > in > > > > ignite-spring-data_2.0: > > > > > > > > spring-core-5.0.8.RELEASE.jar > > > > (pkg:maven/org.springframework/spring-core@5.0.8.RELEASE, > > > > > > cpe:2.3:a:pivotal_software:spring_framework:5.0.8.release:*:*:*:*:*:*:*, > > > > cpe:2.3:a:springsource:spring_framework:5.0.8.release:*:*:*:*:*:*:*, > > > > cpe:2.3:a:vmware:springsource_spring_framework:5.0.8:*:*:*:*:*:*:*) : > > > > CVE-2018-15756 > > > > > > > > One or more dependencies were identified with known vulnerabilities > in > > > > ignite-rest-http: > > > > > > > > jetty-server-9.4.11.v20180605.jar > > > > (pkg:maven/org.eclipse.jetty/jetty-server@9.4.11.v20180605, > > > > cpe:2.3:a:eclipse:jetty:9.4.11:20180605:*:*:*:*:*:*, > > > > cpe:2.3:a:jetty:jetty:9.4.11.v20180605:*:*:*:*:*:*:*, > > > > cpe:2.3:a:mortbay_jetty:jetty:9.4.11:20180605:*:*:*:*:*:*) : > > > > CVE-2018-12545, CVE-2019-10241, CVE-2019-10247 > > > > jackson-databind-2.9.6.jar > > > > (pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.6, > > > > cpe:2.3:a:fasterxml:jackson:2.9.6:*:*:*:*:*:*:*, > > > > cpe:2.3:a:fasterxml:jackson-databind:2.9.6:*:*:*:*:*:*:*) : > > > > CVE-2018-1000873, CVE-2018-14718, CVE-2018-14719, CVE-2018-14720, > > > > CVE-2018-14721, CVE-2018-19360, CVE-2018-19361, CVE-2018-19362, > > > > CVE-2019-12086, CVE-2019-12384, CVE-2019-12814, CVE-2019-14379, > > > > CVE-2019-14439, CVE-2019-14540, CVE-2019-16335, CVE-2019-16942, > > > > CVE-2019-16943, CVE-2019-17267, CVE-2019-17531 > > > > > > > > One or more dependencies were identified with known vulnerabilities > in > > > > ignite-kubernetes: > > > > One or more dependencies were identified with known vulnerabilities > in > > > > ignite-aws: > > > > > > > > jackson-databind-2.9.6.jar > > > > (pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.6, > > > > cpe:2.3:a:fasterxml:jackson:2.9.6:*:*:*:*:*:*:*, > > > > cpe:2.3:a:fasterxml:jackson-databind:2.9.6:*:*:*:*:*:*:*) : > > > > CVE-2018-1000873, CVE-2018-14718, CVE-2018-14719, CVE-2018-14720, > > > > CVE-2018-14721, CVE-2018-19360, CVE-2018-19361, CVE-2018-19362, > > > > CVE-2019-12086, CVE-2019-12384, CVE-2019-12814, CVE-2019-14379, > > > > CVE-2019-14439, CVE-2019-14540, CVE-2019-16335, CVE-2019-16942, > > > > CVE-2019-16943, CVE-2019-17267, CVE-2019-17531 > > > > bcprov-ext-jdk15on-1.54.jar > > > > (pkg:maven/org.bouncycastle/bcprov-ext-jdk15on@1.54) : > CVE-2015-6644, > > > > CVE-2016-1000338, CVE-2016-1000339, CVE-2016-1000340, > CVE-2016-1000341, > > > > CVE-2016-1000342, CVE-2016-1000343, CVE-2016-1000344, > CVE-2016-1000345, > > > > CVE-2016-1000346, CVE-2016-1000352, CVE-2016-2427, CVE-2017-13098, > > > > CVE-2018-1000180, CVE-2018-1000613 > > > > > > > > One or more dependencies were identified with known vulnerabilities > in > > > > ignite-gce: > > > > > > > > httpclient-4.0.1.jar > > (pkg:maven/org.
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Folks, Let me remind you that we are working on the 2.8 release branch stabilization currently (please, keep it in mind). Do we have a really STRONG reason for adding such a change [1] to the ignite-2.8 branch? This PR [2] doesn't look a very simple +5,517 −2,038, 111 files changed. Do we have customer requests for this feature or maybe users who are waiting for exactly that ENUM values exactly in 2.8 release (not the 2.8.1 for instance)? Can we just simply remove IgniteCluster#readOnly to eliminate any backward compatibility issues between 2.8 and 2.9 releases? Do we have extended test results report (on just only TC.Bot green visa) on this feature to be sure that we will not add any blocker issues to the release? For instance, on pre-production environment. I'd like to notice that we also have more than enough the release blocker issues [3] which are still `in progress` and such a release run becomes endless. Such changes without strong reasons looks too scary for me a special after scope and code freeze dates. Please, dispel my doubts. [1] https://issues.apache.org/jira/browse/IGNITE-12225 [2] https://github.com/apache/ignite/pull/7194 [3] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolvedissues(notrelatedtodocumentation) On Thu, 9 Jan 2020 at 19:01, Alexey Zinoviev wrote: > > +1 > > чт, 9 янв. 2020 г. в 18:52, Sergey Antonov : > > > +1 > > > > I'm preparing patch for 2.8 branch now. TC Bot visa for 2.8 branch will be > > at 13 Jan > > > > чт, 9 янв. 2020 г., 21:06 Ivan Pavlukhin : > > > > > +1 > > > > > > чт, 9 янв. 2020 г. в 16:38, Ivan Rakov : > > > > > > > > Maxim M. and anyone who is interested, > > > > > > > > I suggest to include this fix to 2.8 release: > > > > https://issues.apache.org/jira/browse/IGNITE-12225 > > > > Basically, it's a result of the following discussion: > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Single-point-in-API-for-changing-cluster-state-td43665.html > > > > > > > > The fix affects public API: IgniteCluster#readOnly methods that work > > with > > > > boolean are replaced with ones that work with enum. > > > > If we include it, we won't be obliged to keep deprecated boolean > > version > > > of > > > > API in the code (which is currently present in 2.8 branch) as it wasn't > > > > published in any release. > > > > > > > > On Tue, Dec 31, 2019 at 3:54 PM Ilya Kasnacheev < > > > ilya.kasnach...@gmail.com> > > > > wrote: > > > > > > > > > Hello! > > > > > > > > > > I have ran dependency checker plugin and quote the following: > > > > > > > > > > One or more dependencies were identified with known vulnerabilities > > in > > > > > ignite-urideploy: > > > > > One or more dependencies were identified with known vulnerabilities > > in > > > > > ignite-spring: > > > > > One or more dependencies were identified with known vulnerabilities > > in > > > > > ignite-spring-data: > > > > > One or more dependencies were identified with known vulnerabilities > > in > > > > > ignite-aop: > > > > > One or more dependencies were identified with known vulnerabilities > > in > > > > > ignite-visor-console: > > > > > > > > > > spring-core-4.3.18.RELEASE.jar > > > > > (pkg:maven/org.springframework/spring-core@4.3.18.RELEASE, > > > > > > > > cpe:2.3:a:pivotal_software:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > > > > > cpe:2.3:a:springsource:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > > > > > cpe:2.3:a:vmware:springsource_spring_framework:4.3.18:*:*:*:*:*:*:*) > > : > > > > > CVE-2018-15756 > > > > > > > > > > One or more dependencies were identified with known vulnerabilities > > in > > > > > ignite-spring-data_2.0: > > > > > > > > > > spring-core-5.0.8.RELEASE.jar > > > > > (pkg:maven/org.springframework/spring-core@5.0.8.RELEASE, > > > > > > > > cpe:2.3:a:pivotal_software:spring_framework:5.0.8.release:*:*:*:*:*:*:*, > > > > > cpe:2.3:a:springsource:spring_framework:5.0.8.release:*:*:*:*:*:*:*, > > > > > cpe:2.3:a:vmware:springsource_spring_framework:5.0.8:*:*:*:*:*:*:*) : > > > > > CVE-2018-15756 > > > > > > > > > > One or more dependencies were identified with known vulnerabilities > > in > > > > > ignite-rest-http: > > > > > > > > > > jetty-server-9.4.11.v20180605.jar > > > > > (pkg:maven/org.eclipse.jetty/jetty-server@9.4.11.v20180605, > > > > > cpe:2.3:a:eclipse:jetty:9.4.11:20180605:*:*:*:*:*:*, > > > > > cpe:2.3:a:jetty:jetty:9.4.11.v20180605:*:*:*:*:*:*:*, > > > > > cpe:2.3:a:mortbay_jetty:jetty:9.4.11:20180605:*:*:*:*:*:*) : > > > > > CVE-2018-12545, CVE-2019-10241, CVE-2019-10247 > > > > > jackson-databind-2.9.6.jar > > > > > (pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.6, > > > > > cpe:2.3:a:fasterxml:jackson:2.9.6:*:*:*:*:*:*:*, > > > > > cpe:2.3:a:fasterxml:jackson-databind:2.9.6:*:*:*:*:*:*:*) : > > > > > CVE-2018-1000873, CVE-2018-14718, CVE-2018-14719, CVE-2018-14720, > > > > > CVE-2018-14721, CVE-2018-19360, CVE-2018-19361, CVE-2018-19362, > > > > > CVE-2019-120
Re: [ANNOUNCE] New Apache Ignite PMC member: Saikat Maitra
Congrats, Saikat! Well deserved! - Denis On Thu, Jan 9, 2020 at 2:22 AM Ivan Pavlukhin wrote: > Saikat, > > Congratulations and many thanks for your efforts! > > чт, 9 янв. 2020 г. в 13:20, Dmitriy Pavlov : > > > > Hello Ignite Community, > > > > > > > > The Project Management Committee (PMC) for Apache Ignite has invited > Saikat > > Maitra to join the PMC as a new member and we are pleased to announce > that > > he has accepted. > > > > > > > > Saikat joined the community a long time ago and earned the role of a > > committer by integrating Ignite with various streaming technologies. > Since > > those times Saikat keeps maintaining his contributions and helps > newcomers > > with their first tasks and reviews. Also, he is involved in a much larger > > modularization initiative and does his first public presentations about > > Apache Ignite. > > > > > > > > Being a PMC member enables assistance with the management and to guide > the > > direction of the project. > > > > > > > > Best Regards, > > > > Dmitriy Pavlov > > > > on behalf of Apache Ignite PMC > > > > -- > Best regards, > Ivan Pavlukhin >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Agree, that we could plan 2.8.1 for bug-fixing and 2.9 for new major changes and maybe it will help Ivan to decide move it to next releases. Agree that scope is frozen, agree that it makes the release is hard for our release manager. чт, 9 янв. 2020 г. в 19:38, Maxim Muzafarov : > Folks, > > > Let me remind you that we are working on the 2.8 release branch > stabilization currently (please, keep it in mind). > > > Do we have a really STRONG reason for adding such a change [1] to the > ignite-2.8 branch? This PR [2] doesn't look a very simple +5,517 > −2,038, 111 files changed. > Do we have customer requests for this feature or maybe users who are > waiting for exactly that ENUM values exactly in 2.8 release (not the > 2.8.1 for instance)? > Can we just simply remove IgniteCluster#readOnly to eliminate any > backward compatibility issues between 2.8 and 2.9 releases? > Do we have extended test results report (on just only TC.Bot green > visa) on this feature to be sure that we will not add any blocker > issues to the release? For instance, on pre-production environment. > > I'd like to notice that we also have more than enough the release > blocker issues [3] which are still `in progress` and such a release > run becomes endless. Such changes without strong reasons looks too > scary for me a special after scope and code freeze dates. > > Please, dispel my doubts. > > [1] https://issues.apache.org/jira/browse/IGNITE-12225 > [2] https://github.com/apache/ignite/pull/7194 > [3] > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolvedissues(notrelatedtodocumentation) > > On Thu, 9 Jan 2020 at 19:01, Alexey Zinoviev > wrote: > > > > +1 > > > > чт, 9 янв. 2020 г. в 18:52, Sergey Antonov : > > > > > +1 > > > > > > I'm preparing patch for 2.8 branch now. TC Bot visa for 2.8 branch > will be > > > at 13 Jan > > > > > > чт, 9 янв. 2020 г., 21:06 Ivan Pavlukhin : > > > > > > > +1 > > > > > > > > чт, 9 янв. 2020 г. в 16:38, Ivan Rakov : > > > > > > > > > > Maxim M. and anyone who is interested, > > > > > > > > > > I suggest to include this fix to 2.8 release: > > > > > https://issues.apache.org/jira/browse/IGNITE-12225 > > > > > Basically, it's a result of the following discussion: > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Single-point-in-API-for-changing-cluster-state-td43665.html > > > > > > > > > > The fix affects public API: IgniteCluster#readOnly methods that > work > > > with > > > > > boolean are replaced with ones that work with enum. > > > > > If we include it, we won't be obliged to keep deprecated boolean > > > version > > > > of > > > > > API in the code (which is currently present in 2.8 branch) as it > wasn't > > > > > published in any release. > > > > > > > > > > On Tue, Dec 31, 2019 at 3:54 PM Ilya Kasnacheev < > > > > ilya.kasnach...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hello! > > > > > > > > > > > > I have ran dependency checker plugin and quote the following: > > > > > > > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-urideploy: > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-spring: > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-spring-data: > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-aop: > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-visor-console: > > > > > > > > > > > > spring-core-4.3.18.RELEASE.jar > > > > > > (pkg:maven/org.springframework/spring-core@4.3.18.RELEASE, > > > > > > > > > > > cpe:2.3:a:pivotal_software:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > > > > > > > cpe:2.3:a:springsource:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > > > > > > > cpe:2.3:a:vmware:springsource_spring_framework:4.3.18:*:*:*:*:*:*:*) > > > : > > > > > > CVE-2018-15756 > > > > > > > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-spring-data_2.0: > > > > > > > > > > > > spring-core-5.0.8.RELEASE.jar > > > > > > (pkg:maven/org.springframework/spring-core@5.0.8.RELEASE, > > > > > > > > > > > cpe:2.3:a:pivotal_software:spring_framework:5.0.8.release:*:*:*:*:*:*:*, > > > > > > > cpe:2.3:a:springsource:spring_framework:5.0.8.release:*:*:*:*:*:*:*, > > > > > > > cpe:2.3:a:vmware:springsource_spring_framework:5.0.8:*:*:*:*:*:*:*) : > > > > > > CVE-2018-15756 > > > > > > > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-rest-http: > > > > > > > > > > > > jetty-server-9.4.11.v20180605.jar > > > > > > (pkg:maven/org.eclipse.jetty/jetty-server@9.4.11.v20180605, > > > > > > cpe:2.3:a:eclipse:jetty:9.4.11:20180605:*:*:*:*:*:*, > > > > > > cpe:2.3:a:jetty:jetty:9.4.11.v20180605:*:*:*
Re: Ignite Evolution Direction: short questionary
Ignite dev community, I've closed the questionary and here is raw anonymous data for your reference: https://docs.google.com/document/d/1Rkc82GkNlsVrwXxQgFd8RgFNV_qVwuMhmzaQV2W9ccI/edit?usp=sharing Overall, Ignite is continued to be used heavely for caching scenarios (services, DBs, APIs) with increasing usage of SQL and native persistence. Usability and technical issues are mentioned in relation to these two components. Plus, a plenty of other useful thoughts and suggestions. - Denis On Wed, Dec 4, 2019 at 2:51 PM Denis Magda wrote: > Folks, > > There are many ongoing conversations and activities on the list related to > Ignite's evolution (modularization, 3.0, full-text search support, etc.). > > I'm suggesting to ask our broader user community to contribute by sharing > short feedback and discuss results in several weeks: > > https://docs.google.com/forms/d/e/1FAIpQLSdUveEVXer3lpkyiqfFw4175TvZzGHUOS4snPfnkO0NDku0eQ/viewform > > Ultimately, the project is being developed for the purpose and it will be > right to hear back from those who put Ignite in prod. Please check the > questionary and suggest any changes. It should be short and compact. We'll > send it to the user list and can publish it on the Ignite website. > > - > Denis >
Ignite and Pauseless JVMs for Low-Latency Scenarious: Meetup with Azul
Igniters, Some of you should have come across an article by Simon Ritter describing how Ignite and Azul Zing JVM are used together to power low-latency use cases: https://www.azul.com/igniting-in-memory-performance-with-gridgain-and-zing/ Several of our community members including Pavel Vinokurov and Stan Lukyanov were involved in that project, and this time we are gathering together with Silicon Valley Java Performance meetup group to results in details: https://www.meetup.com/Bay-Area-In-Memory-Computing/events/267751131 The session is to be led by Gil Tene, Azul Systems CTO, Java RockStar and Java Champion, who will cover JVM aspects of the solution. While I will join Gil to explain Ignite internals. RSVP and come over! - Denis
Re: Hint for user that baseline topology should be changed in order to trigger rebalance
Ivan, Igniters, thanks for starting the discussion, How about the following a bit simplified message template? It's assumed the user is aware of what both rebalancing and baseline topology mean. "New server node joined the cluster, add it to the baseline topology manually to trigger data rebalancing [node details]" a complete message will look like this "New server node joined the cluster, add it to the baseline topology manually to trigger data rebalancing [[topVer=2, minorTopVer=0], force=false, evt=NODE_JOINED, node=57bc10fe-1505-4e8e-9987-52c9c903c6ef]] - Denis On Thu, Jan 9, 2020 at 6:21 AM Ivan Rakov wrote: > Folks, > > Since 2.4, Ignite cluster requires baseline topology in persistent mode. > That means if user wants to scale cluster and add more nodes, data won't be > redistributed among the whole node set until manual call of > IgniteCluster#setBaselineTopology. > > Surely this behavior is well-documented, but don't we need to give user a > hint that baseline topology should be managed manually? I think, log > message with something like "Current set of nodes differs from baseline > topology, please call XXX in order to trigger rebalance and redistribute > your data" will make the situation a bit more transparent. > > Right now we have only this message > > > [2020-01-07T19:36:45,997][INFO > > > ][exchange-worker-#39%blue-54.158.100.161%][GridCachePartitionExchangeManager] > Skipping > > rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=2, > > minorTopVer=0], force=false, evt=NODE_JOINED, > node=57bc10fe-1505-4e8e-9987- > > 52c9c903c6ef] > > which doesn't properly explain what's going on. >
Re: Launched Ignite meetups and redesigned events pages
Dmitry, We've also added the reference to the form on the event's webpage. Btw, could you remind me who will be receiving the proposals - you, I and some other folks or all @dev list? - Denis On Thu, Jan 9, 2020 at 1:53 AM Dmitriy Pavlov wrote: > Hi Igniters, Mauricio, Ignacio, and Denis, > > Thank you all for updating these pages. > > I would like to stress just one thing: > should you have in mind some topic you can run talk about, please feel > absolutely free to fill submission proposal. > > To submit proposal you need to fill in this form > > https://docs.google.com/forms/d/e/1FAIpQLSdiY7movHKvyWg3gOVedHgukJJnNiaejSO_X838vBseL9VmiQ/viewform > . > > Sincerely, > Dmitriy Pavlov > > вт, 7 янв. 2020 г. в 02:48, Denis Magda : > > > Igniters, > > > > I've just merged changes contributed by Mauricio and Ignacio, who helped > > us to prepare professional webpages for Ignite meetup groups around the > > world [1] and for Ignite events [2]. Now you can easily enroll in a > meetup > > group nearby or sign up for an upcoming event to be hosted one of our > > experts. > > > > Please check them out and share your feedback. In the meantime, three of > > us are going to carry on with optimizations and changes making the > website > > more useful for developers as well as more searchable/discoverable from > > various search engines. > > > > [1] https://ignite.apache.org/meetup-groups.html > > [2] https://ignite.apache.org/events.html > > > > - > > Denis > > >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Hello, Maxim! > This PR [2] doesn't look a very simple +5,517 −2,038, 111 files changed. Yes, PR is huge, but I wrote a lot of new tests and reworked already presented. Changes in product code are minimal - only 30 changed files in /src/main/ part. And most of them are new control.sh commands and configuration. > Do we have customer requests for this feature or maybe users who are waiting for exactly that ENUM values exactly in 2.8 release (not the 2.8.1 for instance)? Can we introduce in new features in maintanance release (2.8.1)? Cluster read-only mode will be new feature, if we remove IgniteCluster#readOnly in 2.8 release. If all ok with that, lets remove IgniteCluster#readOnly and move ticket [1] to 2.8.1 release. > Do we have extended test results report (on just only TC.Bot green visa) on this feature to be sure that we will not add any blocker issues to the release? I'm preparing patch for 2.8 release and I will get new TC Bot visa vs release branch. [1] https://issues.apache.org/jira/browse/IGNITE-12225 чт, 9 янв. 2020 г. в 19:38, Maxim Muzafarov : > Folks, > > > Let me remind you that we are working on the 2.8 release branch > stabilization currently (please, keep it in mind). > > > Do we have a really STRONG reason for adding such a change [1] to the > ignite-2.8 branch? This PR [2] doesn't look a very simple +5,517 > −2,038, 111 files changed. > Do we have customer requests for this feature or maybe users who are > waiting for exactly that ENUM values exactly in 2.8 release (not the > 2.8.1 for instance)? > Can we just simply remove IgniteCluster#readOnly to eliminate any > backward compatibility issues between 2.8 and 2.9 releases? > Do we have extended test results report (on just only TC.Bot green > visa) on this feature to be sure that we will not add any blocker > issues to the release? For instance, on pre-production environment. > > I'd like to notice that we also have more than enough the release > blocker issues [3] which are still `in progress` and such a release > run becomes endless. Such changes without strong reasons looks too > scary for me a special after scope and code freeze dates. > > Please, dispel my doubts. > > [1] https://issues.apache.org/jira/browse/IGNITE-12225 > [2] https://github.com/apache/ignite/pull/7194 > [3] > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolvedissues(notrelatedtodocumentation) > > On Thu, 9 Jan 2020 at 19:01, Alexey Zinoviev > wrote: > > > > +1 > > > > чт, 9 янв. 2020 г. в 18:52, Sergey Antonov : > > > > > +1 > > > > > > I'm preparing patch for 2.8 branch now. TC Bot visa for 2.8 branch > will be > > > at 13 Jan > > > > > > чт, 9 янв. 2020 г., 21:06 Ivan Pavlukhin : > > > > > > > +1 > > > > > > > > чт, 9 янв. 2020 г. в 16:38, Ivan Rakov : > > > > > > > > > > Maxim M. and anyone who is interested, > > > > > > > > > > I suggest to include this fix to 2.8 release: > > > > > https://issues.apache.org/jira/browse/IGNITE-12225 > > > > > Basically, it's a result of the following discussion: > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Single-point-in-API-for-changing-cluster-state-td43665.html > > > > > > > > > > The fix affects public API: IgniteCluster#readOnly methods that > work > > > with > > > > > boolean are replaced with ones that work with enum. > > > > > If we include it, we won't be obliged to keep deprecated boolean > > > version > > > > of > > > > > API in the code (which is currently present in 2.8 branch) as it > wasn't > > > > > published in any release. > > > > > > > > > > On Tue, Dec 31, 2019 at 3:54 PM Ilya Kasnacheev < > > > > ilya.kasnach...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hello! > > > > > > > > > > > > I have ran dependency checker plugin and quote the following: > > > > > > > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-urideploy: > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-spring: > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-spring-data: > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-aop: > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-visor-console: > > > > > > > > > > > > spring-core-4.3.18.RELEASE.jar > > > > > > (pkg:maven/org.springframework/spring-core@4.3.18.RELEASE, > > > > > > > > > > > cpe:2.3:a:pivotal_software:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > > > > > > > cpe:2.3:a:springsource:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > > > > > > > cpe:2.3:a:vmware:springsource_spring_framework:4.3.18:*:*:*:*:*:*:*) > > > : > > > > > > CVE-2018-15756 > > > > > > > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-spring-data_2
Re: [ANNOUNCE] New Apache Ignite PMC member: Saikat Maitra
Hi Dmitriy, Denis, Ivan, Thank you so much. I am very glad and excited to be a part of Apache Ignite Project Member Committee. I will try my best to assist with project management and guide the direction of the project. Regards, Saikat On Thu, Jan 9, 2020 at 10:51 AM Denis Magda wrote: > Congrats, Saikat! Well deserved! > > - > Denis > > > On Thu, Jan 9, 2020 at 2:22 AM Ivan Pavlukhin wrote: > > > Saikat, > > > > Congratulations and many thanks for your efforts! > > > > чт, 9 янв. 2020 г. в 13:20, Dmitriy Pavlov : > > > > > > Hello Ignite Community, > > > > > > > > > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > Saikat > > > Maitra to join the PMC as a new member and we are pleased to announce > > that > > > he has accepted. > > > > > > > > > > > > Saikat joined the community a long time ago and earned the role of a > > > committer by integrating Ignite with various streaming technologies. > > Since > > > those times Saikat keeps maintaining his contributions and helps > > newcomers > > > with their first tasks and reviews. Also, he is involved in a much > larger > > > modularization initiative and does his first public presentations about > > > Apache Ignite. > > > > > > > > > > > > Being a PMC member enables assistance with the management and to guide > > the > > > direction of the project. > > > > > > > > > > > > Best Regards, > > > > > > Dmitriy Pavlov > > > > > > on behalf of Apache Ignite PMC > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > >
[jira] [Created] (IGNITE-12524) Partition reserve/release symmetry should be checked on release/destroy
Anton Vinogradov created IGNITE-12524: - Summary: Partition reserve/release symmetry should be checked on release/destroy Key: IGNITE-12524 URL: https://issues.apache.org/jira/browse/IGNITE-12524 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Fix For: 2.9 Current code never checks reservations zero bound on release/destroy. Checks should be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[MTCGA]: new failures in builds [4914299] 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-nightly ClusterStateOnStartPropertyTest.testReadOnlyActiveOnStartInMemory https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7018902402127259658&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master-nightly ClusterStateOnStartPropertyTest.testActiveActiveOnStartInMemory https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8676568112351590177&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master-nightly ClusterStateOnStartPropertyTest.testReadOnlyInactiveOnStartInMemory https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6640346842258116429&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master-nightly ActiveOnStartPropertyTest.testInMemoryActive https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=2729395671664878800&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master-nightly ClusterStateOnStartPropertyTest.testReadOnlyInMemory https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8117724908637425685&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master-nightly ClusterStateOnStartPropertyTest.testActiveInactiveOnStartInMemory https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4044980805336691692&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master-nightly ClusterStateOnStartPropertyTest.testActiveInMemory https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8509767272219353358&branch=%3Cdefault%3E&tab=testDetails Changes may lead to failure were done by - ibessonov https://ci.ignite.apache.org/viewModification.html?modId=895311 - ibessonov https://ci.ignite.apache.org/viewModification.html?modId=895338 - sergey antonov https://ci.ignite.apache.org/viewModification.html?modId=895319 - ibessonov https://ci.ignite.apache.org/viewModification.html?modId=895313 - 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 09:46:07 10-01-2020
Re: Partition reserve/release asymmetry
>> Does the issue reproduce in >> subsequent runs? Unfortunately no. We performed 30+ runs without "success". >> I think we can add an assertion to >> GridDhtLocalPartition#destroy() method to check that reservations is 0 Ok, I will check and merge in case of success. Created the Issue to handle this [1]. [1] https://issues.apache.org/jira/browse/IGNITE-12524 On Thu, Jan 9, 2020 at 1:46 PM Alexey Goncharuk wrote: > Hello Anton, > > Thanks for digging into this. The logic with checking the > reservations count seems fishy to me as well, so I have no objections with > the suggested change. This "if" statement does not answer why the partition > was being destroyed during the commit, though. Does the issue reproduce in > subsequent runs? > > The logic around reserve/release seems ok to me, however, the > eviction/renting code looks overly complicated, perhaps, there is a bug > somewhere there? I think we can add an assertion to > GridDhtLocalPartition#destroy() method to check that reservations is 0 when > this method is called (there is a check for EVICTED state already there) > > --AG > > чт, 9 янв. 2020 г. в 09:45, Anton Vinogradov : > > > Folks, > > Yardstick run (opt-serial-put-get-1-backup) failed with interesting > > exception: > > Critical system error detected. Will be handled accordingly to configured > > handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, > > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet > > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], > > failureCtx=FailureContext [type=CRITICAL_ERROR, err=class > > o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing a > > transaction has produced runtime exception]] > > class > > > org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: > > Committing a transaction has produced runtime exception > > at > > > > > org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800) > > at > > > > > org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:838) > > at > > > > > org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:893) > > at > > > > > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1452) > > at > > > > > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1375) > > at > > > > > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:123) > > at > > > > > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:241) > > at > > > > > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:239) > > at > > > > > org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142) > > at > > > > > org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591) > > at > > > > > org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392) > > at > > > > > org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318) > > at > > > > > org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109) > > at > > > > > org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308) > > at > > > > > org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1843) > > at > > > > > org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1468) > > at > > > > > org.apache.ignite.internal.managers.communication.GridIoManager.access$5200(GridIoManager.java:229) > > at > > > > > org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1365) > > at > > > > > org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:555) > > at > > > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) > > at java.lang.Thread.run(Thread.java:748) > > Caused by: java.lang.IllegalStateException: Tree is being concurrently > > destroyed: tx-p-470##CacheData > > at > > > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.checkDestroyed(BPlusTree.java:1011) > > at > > > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1831) > > at > > > > > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1696) > > at > > > > > org.apache.ignite.internal.processors.cache.Ignite
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Hello, Igniters. I’m -1 to include the read-only patch to 2.8. I think we shouldn’t accept any patches to 2.8 except bug fixes for blockers and major issues. Guys, we don’t release Apache Ignite for 13 months! We should focus on the release and make it ASAP. We can’t extend the scope anymore. > 10 янв. 2020 г., в 04:29, Sergey Antonov > написал(а): > > Hello, Maxim! > >> This PR [2] doesn't look a very simple +5,517 −2,038, 111 files > changed. > Yes, PR is huge, but I wrote a lot of new tests and reworked already > presented. Changes in product code are minimal - only 30 changed files in > /src/main/ part. And most of them are new control.sh commands and > configuration. > >> Do we have customer requests for this feature or maybe users who are > waiting for exactly that ENUM values exactly in 2.8 release (not the 2.8.1 > for instance)? > Can we introduce in new features in maintanance release (2.8.1)? Cluster > read-only mode will be new feature, if we remove IgniteCluster#readOnly in > 2.8 release. If all ok with that, lets remove IgniteCluster#readOnly and > move ticket [1] to 2.8.1 release. > >> Do we have extended test results report (on just only TC.Bot green visa) > on this feature to be sure that we will not add any blocker issues to the > release? > I'm preparing patch for 2.8 release and I will get new TC Bot visa vs > release branch. > > [1] https://issues.apache.org/jira/browse/IGNITE-12225 > > > > чт, 9 янв. 2020 г. в 19:38, Maxim Muzafarov : > >> Folks, >> >> >> Let me remind you that we are working on the 2.8 release branch >> stabilization currently (please, keep it in mind). >> >> >> Do we have a really STRONG reason for adding such a change [1] to the >> ignite-2.8 branch? This PR [2] doesn't look a very simple +5,517 >> −2,038, 111 files changed. >> Do we have customer requests for this feature or maybe users who are >> waiting for exactly that ENUM values exactly in 2.8 release (not the >> 2.8.1 for instance)? >> Can we just simply remove IgniteCluster#readOnly to eliminate any >> backward compatibility issues between 2.8 and 2.9 releases? >> Do we have extended test results report (on just only TC.Bot green >> visa) on this feature to be sure that we will not add any blocker >> issues to the release? For instance, on pre-production environment. >> >> I'd like to notice that we also have more than enough the release >> blocker issues [3] which are still `in progress` and such a release >> run becomes endless. Such changes without strong reasons looks too >> scary for me a special after scope and code freeze dates. >> >> Please, dispel my doubts. >> >> [1] https://issues.apache.org/jira/browse/IGNITE-12225 >> [2] https://github.com/apache/ignite/pull/7194 >> [3] >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolvedissues(notrelatedtodocumentation) >> >> On Thu, 9 Jan 2020 at 19:01, Alexey Zinoviev >> wrote: >>> >>> +1 >>> >>> чт, 9 янв. 2020 г. в 18:52, Sergey Antonov : >>> +1 I'm preparing patch for 2.8 branch now. TC Bot visa for 2.8 branch >> will be at 13 Jan чт, 9 янв. 2020 г., 21:06 Ivan Pavlukhin : > +1 > > чт, 9 янв. 2020 г. в 16:38, Ivan Rakov : >> >> Maxim M. and anyone who is interested, >> >> I suggest to include this fix to 2.8 release: >> https://issues.apache.org/jira/browse/IGNITE-12225 >> Basically, it's a result of the following discussion: >> > >> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Single-point-in-API-for-changing-cluster-state-td43665.html >> >> The fix affects public API: IgniteCluster#readOnly methods that >> work with >> boolean are replaced with ones that work with enum. >> If we include it, we won't be obliged to keep deprecated boolean version > of >> API in the code (which is currently present in 2.8 branch) as it >> wasn't >> published in any release. >> >> On Tue, Dec 31, 2019 at 3:54 PM Ilya Kasnacheev < > ilya.kasnach...@gmail.com> >> wrote: >> >>> Hello! >>> >>> I have ran dependency checker plugin and quote the following: >>> >>> One or more dependencies were identified with known >> vulnerabilities in >>> ignite-urideploy: >>> One or more dependencies were identified with known >> vulnerabilities in >>> ignite-spring: >>> One or more dependencies were identified with known >> vulnerabilities in >>> ignite-spring-data: >>> One or more dependencies were identified with known >> vulnerabilities in >>> ignite-aop: >>> One or more dependencies were identified with known >> vulnerabilities in >>> ignite-visor-console: >>> >>> spring-core-4.3.18.RELEASE.jar >>> (pkg:maven/org.springframework/spring-core@4.3.18.RELEASE, >>> > >> cpe:2.3:a:pivotal_software:spring_framework:4.3.18.release:*:*:*:*:*:*:*, >>>
Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Agree with Nikolay, -1 from me, too. >Hello, Igniters. > >I’m -1 to include the read-only patch to 2.8. >I think we shouldn’t accept any patches to 2.8 except bug fixes for blockers >and major issues. > >Guys, we don’t release Apache Ignite for 13 months! >We should focus on the release and make it ASAP. > >We can’t extend the scope anymore. > >> 10 янв. 2020 г., в 04:29, Sergey Antonov < antonovserge...@gmail.com > >> написал(а): >> >> Hello, Maxim! >> >>> This PR [2] doesn't look a very simple +5,517 −2,038, 111 files >> changed. >> Yes, PR is huge, but I wrote a lot of new tests and reworked already >> presented. Changes in product code are minimal - only 30 changed files in >> /src/main/ part. And most of them are new control.sh commands and >> configuration. >> >>> Do we have customer requests for this feature or maybe users who are >> waiting for exactly that ENUM values exactly in 2.8 release (not the 2.8.1 >> for instance)? >> Can we introduce in new features in maintanance release (2.8.1)? Cluster >> read-only mode will be new feature, if we remove IgniteCluster#readOnly in >> 2.8 release. If all ok with that, lets remove IgniteCluster#readOnly and >> move ticket [1] to 2.8.1 release. >> >>> Do we have extended test results report (on just only TC.Bot green visa) >> on this feature to be sure that we will not add any blocker issues to the >> release? >> I'm preparing patch for 2.8 release and I will get new TC Bot visa vs >> release branch. >> >> [1] https://issues.apache.org/jira/browse/IGNITE-12225 >> >> >> >> чт, 9 янв. 2020 г. в 19:38, Maxim Muzafarov < mmu...@apache.org >: >> >>> Folks, >>> >>> >>> Let me remind you that we are working on the 2.8 release branch >>> stabilization currently (please, keep it in mind). >>> >>> >>> Do we have a really STRONG reason for adding such a change [1] to the >>> ignite-2.8 branch? This PR [2] doesn't look a very simple +5,517 >>> −2,038, 111 files changed. >>> Do we have customer requests for this feature or maybe users who are >>> waiting for exactly that ENUM values exactly in 2.8 release (not the >>> 2.8.1 for instance)? >>> Can we just simply remove IgniteCluster#readOnly to eliminate any >>> backward compatibility issues between 2.8 and 2.9 releases? >>> Do we have extended test results report (on just only TC.Bot green >>> visa) on this feature to be sure that we will not add any blocker >>> issues to the release? For instance, on pre-production environment. >>> >>> I'd like to notice that we also have more than enough the release >>> blocker issues [3] which are still `in progress` and such a release >>> run becomes endless. Such changes without strong reasons looks too >>> scary for me a special after scope and code freeze dates. >>> >>> Please, dispel my doubts. >>> >>> [1] https://issues.apache.org/jira/browse/IGNITE-12225 >>> [2] https://github.com/apache/ignite/pull/7194 >>> [3] >>> >>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolvedissues(notrelatedtodocumentation >>> ) >>> >>> On Thu, 9 Jan 2020 at 19:01, Alexey Zinoviev < zaleslaw@gmail.com > >>> wrote: +1 чт, 9 янв. 2020 г. в 18:52, Sergey Antonov < antonovserge...@gmail.com >: > +1 > > I'm preparing patch for 2.8 branch now. TC Bot visa for 2.8 branch >>> will be > at 13 Jan > > чт, 9 янв. 2020 г., 21:06 Ivan Pavlukhin < vololo...@gmail.com >: > >> +1 >> >> чт, 9 янв. 2020 г. в 16:38, Ivan Rakov < ivan.glu...@gmail.com >: >>> >>> Maxim M. and anyone who is interested, >>> >>> I suggest to include this fix to 2.8 release: >>> https://issues.apache.org/jira/browse/IGNITE-12225 >>> Basically, it's a result of the following discussion: >>> >> > >>> >>> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Single-point-in-API-for-changing-cluster-state-td43665.html >>> >>> The fix affects public API: IgniteCluster#readOnly methods that >>> work > with >>> boolean are replaced with ones that work with enum. >>> If we include it, we won't be obliged to keep deprecated boolean > version >> of >>> API in the code (which is currently present in 2.8 branch) as it >>> wasn't >>> published in any release. >>> >>> On Tue, Dec 31, 2019 at 3:54 PM Ilya Kasnacheev < >> ilya.kasnach...@gmail.com > >>> wrote: >>> Hello! I have ran dependency checker plugin and quote the following: One or more dependencies were identified with known >>> vulnerabilities > in ignite-urideploy: One or more dependencies were identified with known >>> vulnerabilities > in ignite-spring: One or more dependencies were identified with known >>> vulnerabilities > in ignite-spring-data: One or more dependencies were identified with known >>> vulnerabilities > in ignite-aop: >>
