[jira] [Created] (IGNITE-12542) Some tests failed after due to incompatible changes in IGNITE-12108 and IGNITE-11987
Ivan Bessonov created IGNITE-12542: -- Summary: Some tests failed after due to incompatible changes in IGNITE-12108 and IGNITE-11987 Key: IGNITE-12542 URL: https://issues.apache.org/jira/browse/IGNITE-12542 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Assignee: Ivan Bessonov [https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ComputeGrid?branch=%3Cdefault%3E&buildTypeTab=overview&mode=builds] [https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Basic1?branch=%3Cdefault%3E&buildTypeTab=overview&mode=builds] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[MTCGA]: new failures in builds [4928914, 4928878] 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. *New test failure in master GridResourceProcessorSelfTest.testInjectResourceToAnnotatedField https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-1197954869405330412&branch=%3Cdefault%3E&tab=testDetails *New test failure in master GridResourceProcessorSelfTest.testInjectResourceInnerClasses https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4259828379345345823&branch=%3Cdefault%3E&tab=testDetails *New test failure in master GridResourceProcessorSelfTest.testInjectResourceToAnnotatedMethod https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-2647264403097053328&branch=%3Cdefault%3E&tab=testDetails *New test failure in master GridResourceProcessorSelfTest.testInjectResourceGridTaskAndJob https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=2266178563380816265&branch=%3Cdefault%3E&tab=testDetails *New test failure in master GridResourceProcessorSelfTest.testInjectResourcePerformance https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4340898541242121943&branch=%3Cdefault%3E&tab=testDetails *New test failure in master GridResourceProcessorSelfTest.testInjectResourceMultiThreaded https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-502477925023973012&branch=%3Cdefault%3E&tab=testDetails Changes may lead to failure were done by - ivan bessonov https://ci.ignite.apache.org/viewModification.html?modId=895469 - ilya kasnacheev https://ci.ignite.apache.org/viewModification.html?modId=895451 - alexey zinoviev https://ci.ignite.apache.org/viewModification.html?modId=895441 *New test failure in master-nightly GridTimeoutProcessorSelfTest.testTimeoutsMultithreaded https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8836900726107399485&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridTimeoutProcessorSelfTest.testTimeoutNeverCalled https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8964923182010890693&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridTimeoutProcessorSelfTest.testTimeoutObjectAdapterMultithreaded https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=2387114214355720438&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridTimeoutProcessorSelfTest.testTimeoutCallOnce https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7812436655645182815&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridTimeoutProcessorSelfTest.testTimeoutSameEndTime https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4489634307846388362&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridTimeoutProcessorSelfTest.testTimeouts https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7158711825921100549&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridTimeoutProcessorSelfTest.testTimeoutNeverCalledMultithreaded https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6352863300037764827&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridTimeoutProcessorSelfTest.testCancelingWithClearedInterruptedFlag https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-368950304280736555&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridJobMetricsProcessorLoadTest.testJobMetricsMultiThreaded https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-387262067566320855&branch=%3Cdefault%3E&tab=testDetails Changes may lead to failure were done by - ivan bessonov https://ci.ignite.apache.org/viewModification.html?modId=895469 - ilya kasnacheev https://ci.ignite.apache.org/viewModification.html?modId=895451 - alexey zinoviev https://ci.ignite.apache.org/viewModification.html?modId=895441 - 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-tea
Re: Incorrect fillFactor/memory usage metric
Thanks very much for your thoughts on this. I can confirm that the use of getTotalUsedPages() does indeed allow us to calculate a memory consumption metric that reduces as cache data is purged. I will comment on and close the Jira ticket. This is great news. Just one thought, in case there's any work in this area still under way - perhaps it would be worth adding explicit methods on the metrics interface to get used/free memory as per this calculation? It strikes me that these metrics are absolutely critical for many use cases - but obtaining them is not currently obvious or always reliable. I'm very happy for my test (see jira) to be included in the test suite if that's useful? Regards, Colin. -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: IGNITE-12361 Migrate Flume module to ignite-extensions
Saikat, Thanks for working on this! I'll do my best to take a look at it this week. --AG пн, 13 янв. 2020 г. в 21:37, Denis Magda : > Alex Goncharuk, Nikolay Izhikov, > > Could you possibly check the changes or suggest any other > committer/contributor for that? > > - > Denis > > > On Sun, Jan 12, 2020 at 9:31 AM Saikat Maitra > wrote: > >> Hello, >> >> These PRs are part of Modularization effort >> >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations >> >> If the changes looks good, I can go ahead and merge the changes. >> >> Regards, >> Saikat >> >> On Sun, Jan 5, 2020 at 1:08 PM Saikat Maitra >> wrote: >> >> > Hi, >> > >> > I have raised PR for Ignite Flume migration to Ignite Extensions repo. >> > >> > Jira https://issues.apache.org/jira/browse/IGNITE-12361 >> > >> > PR https://github.com/apache/ignite-extensions/pull/4 >> > https://github.com/apache/ignite/pull/7227 >> > >> > Please review and share feedback. >> > >> > This is part of our Modularization effort for Streamer modules >> > >> > https://issues.apache.org/jira/browse/IGNITE-12355 >> > >> > Regards, >> > Saikat >> > >> >
Slim binary release and docker image for Apache Ignite
Igniters, I would like to discuss with the community a possibility to create additional 'slim' binary releases and docker images for Apache Ignite. The reason is two-fold: * The full set of 3rd party libraries distributed with Apache Ignite looks too large for me. I know there is an ongoing activity towards more clear Ignite modularization [1][2][3], but this seems to be quite a long process. On the other hand, creating a slim release may give an immediate benefit to the users who are interested in a smaller image. For example, removing the benchmarks alone from the binary release saves 80M. * As Ilya Kasnacheev demonstrated [4], the more 3rd party libraries we have, the more potential vulnerabilities will show up in audit tools. This may be a formal barrier for Apache Ignite adoption and moving to production for many users. Having a slim image with the minimum number of dependencies (yet complete enough to fit the majority of use-cases) significantly reduces this risk. I wonder what community thinks regarding this idea? Given the recent study of Apache Ignite use-cases, I suggest the following list of modules to be included to the slim release/image (a subject to discuss, of course): * ignite-core * ignite-indexing * ignite-rest-http * ignite-spring * ignite-log4j * ignite-log4j2 * ignite-slf4j * ignite-urideploy * ignite-kubernetes * ignite-opencensus [1] http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-3-0-and-to-be-removed-list-td42330.html [2] http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12358-Migrate-ZeroMQ-module-to-ignite-extensions-td45067.html [3] http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html [4] http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-td43616i100.html#a44994 --AG
[MTCGA]: new failures in builds [4928876] 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. *New test failure in master-nightly GridManagerStopSelfTest.testStopLoadBalancingManager https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=9127136323493307012&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridPortProcessorSelfTest.testB https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7606733905090920683&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridPortProcessorSelfTest.testA https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-2572375979752951976&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridManagerStopSelfTest.testStopCollisionManager https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-5159214873680406079&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridFutureAdapterSelfTest.testListenNotify https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8595268834442081924&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridManagerStopSelfTest.testStopDeploymentManager https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-3807581235952863033&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridManagerStopSelfTest.testStopCommunicationManager https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4172259971914015165&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridManagerStopSelfTest.testStopFailoverManager https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4356500808656328030&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridManagerStopSelfTest.testStopEventStorageManager https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8772179139219191705&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridManagerStopSelfTest.testStopCheckpointManager https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5497220150877478286&branch=%3Cdefault%3E&tab=testDetails *New test failure in master-nightly GridManagerStopSelfTest.testStopDiscoveryManager https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=2054926974017275097&branch=%3Cdefault%3E&tab=testDetails Changes may lead to failure were done by - ivan bessonov https://ci.ignite.apache.org/viewModification.html?modId=895469 - ilya kasnacheev https://ci.ignite.apache.org/viewModification.html?modId=895451 - alexey zinoviev https://ci.ignite.apache.org/viewModification.html?modId=895441 - 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 13:18:39 15-01-2020
Re: Hint for user that baseline topology should be changed in order to trigger rebalance
Hello folks! I'm a new community member and tried to solve the issue as a first introduction task. I've got this log message: "Local node is not included in Baseline Topology and will not be used for data storage. Use control.(sh|bat) script or IgniteCluster interface to include the node to Baseline Topology." when started an additional node after a cluster was activated. I suppose the message explains the situation quite well. -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-12543) When put List>, the data was increased much larger.
LEE PYUNG BEOM created IGNITE-12543: --- Summary: When put List>, the data was increased much larger. Key: IGNITE-12543 URL: https://issues.apache.org/jira/browse/IGNITE-12543 Project: Ignite Issue Type: Bug Components: thin client Affects Versions: 2.6 Reporter: LEE PYUNG BEOM When using Java Thin Client with Ignite 2.6, When I put data in the form List>, the size of the original 200KB data was increased to 50MB when inquired by Ignite servers. On the Heap Dump, the list element was repeatedly accumulated, increasing the data size. Under network monitoring, normal size was measured during transmission from the client to the server. Do you have a history of reported issues? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12544) [TCBOT] Trigger build confirmation modal has wrong position.
Andrey Mashenkov created IGNITE-12544: - Summary: [TCBOT] Trigger build confirmation modal has wrong position. Key: IGNITE-12544 URL: https://issues.apache.org/jira/browse/IGNITE-12544 Project: Ignite Issue Type: Task Reporter: Andrey Mashenkov For now, after pressing "Re-run possible blockers" button I observe browser scroll down page to it's center to render confirmation modal. Trigger build confirmation modal on "/prs.html" page should be centered over the screen (browser window) rather than page itself. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Slim binary release and docker image for Apache Ignite
Hello! This is a reasonable idea. I think we should also drop benchmarks/ directory from that build, it's 60M of (potentially vulnerable) JARs that are not needed by an average developer's use cases. Regards, -- Ilya Kasnacheev ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk : > Igniters, > > I would like to discuss with the community a possibility to create > additional 'slim' binary releases and docker images for Apache Ignite. The > reason is two-fold: > * The full set of 3rd party libraries distributed with Apache Ignite looks > too large for me. I know there is an ongoing activity towards more clear > Ignite modularization [1][2][3], but this seems to be quite a long process. > On the other hand, creating a slim release may give an immediate benefit to > the users who are interested in a smaller image. For example, removing the > benchmarks alone from the binary release saves 80M. > * As Ilya Kasnacheev demonstrated [4], the more 3rd party libraries we > have, the more potential vulnerabilities will show up in audit tools. This > may be a formal barrier for Apache Ignite adoption and moving to production > for many users. Having a slim image with the minimum number of dependencies > (yet complete enough to fit the majority of use-cases) significantly > reduces this risk. > > I wonder what community thinks regarding this idea? Given the recent study > of Apache Ignite use-cases, I suggest the following list of modules to be > included to the slim release/image (a subject to discuss, of course): > * ignite-core > * ignite-indexing > * ignite-rest-http > * ignite-spring > * ignite-log4j > * ignite-log4j2 > * ignite-slf4j > * ignite-urideploy > * ignite-kubernetes > * ignite-opencensus > > [1] > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-3-0-and-to-be-removed-list-td42330.html > [2] > > http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12358-Migrate-ZeroMQ-module-to-ignite-extensions-td45067.html > [3] > > http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html > [4] > > http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-td43616i100.html#a44994 > > --AG >
Re: Slim binary release and docker image for Apache Ignite
I like the idea, current distribution is certainly too big. Here is a list of jar files we include in NuGet package: cache-api-1.0.0.jar commons-codec-1.11.jar commons-logging-1.1.1.jar h2-1.4.197.jar ignite-core-2.9.0-SNAPSHOT.jar ignite-indexing-2.9.0-SNAPSHOT.jar ignite-shmem-1.0.0.jar ignite-spring-2.9.0-SNAPSHOT.jar lucene-analyzers-common-7.4.0.jar lucene-core-7.4.0.jar lucene-queryparser-7.4.0.jar spring-aop-4.3.18.RELEASE.jar spring-beans-4.3.18.RELEASE.jar spring-context-4.3.18.RELEASE.jar spring-core-4.3.18.RELEASE.jar spring-expression-4.3.18.RELEASE.jar spring-jdbc-4.3.18.RELEASE.jar spring-tx-4.3.18.RELEASE.jar Those are required for SQL and Spring configs to work properly, maybe we want to include them into the slim distro as well. On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev wrote: > Hello! > > This is a reasonable idea. > > I think we should also drop benchmarks/ directory from that build, it's 60M > of (potentially vulnerable) JARs that are not needed by an average > developer's use cases. > > Regards, > -- > Ilya Kasnacheev > > > ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk >: > > > Igniters, > > > > I would like to discuss with the community a possibility to create > > additional 'slim' binary releases and docker images for Apache Ignite. > The > > reason is two-fold: > > * The full set of 3rd party libraries distributed with Apache Ignite > looks > > too large for me. I know there is an ongoing activity towards more clear > > Ignite modularization [1][2][3], but this seems to be quite a long > process. > > On the other hand, creating a slim release may give an immediate benefit > to > > the users who are interested in a smaller image. For example, removing > the > > benchmarks alone from the binary release saves 80M. > > * As Ilya Kasnacheev demonstrated [4], the more 3rd party libraries we > > have, the more potential vulnerabilities will show up in audit tools. > This > > may be a formal barrier for Apache Ignite adoption and moving to > production > > for many users. Having a slim image with the minimum number of > dependencies > > (yet complete enough to fit the majority of use-cases) significantly > > reduces this risk. > > > > I wonder what community thinks regarding this idea? Given the recent > study > > of Apache Ignite use-cases, I suggest the following list of modules to be > > included to the slim release/image (a subject to discuss, of course): > > * ignite-core > > * ignite-indexing > > * ignite-rest-http > > * ignite-spring > > * ignite-log4j > > * ignite-log4j2 > > * ignite-slf4j > > * ignite-urideploy > > * ignite-kubernetes > > * ignite-opencensus > > > > [1] > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-3-0-and-to-be-removed-list-td42330.html > > [2] > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12358-Migrate-ZeroMQ-module-to-ignite-extensions-td45067.html > > [3] > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html > > [4] > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-td43616i100.html#a44994 > > > > --AG > > >
Re: Slim binary release and docker image for Apache Ignite
Hello! Pavel, I believe these JARs are fully covered by the list of modules specified above. Regards, -- Ilya Kasnacheev ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn : > I like the idea, current distribution is certainly too big. > > Here is a list of jar files we include in NuGet package: > > cache-api-1.0.0.jar > commons-codec-1.11.jar > commons-logging-1.1.1.jar > h2-1.4.197.jar > ignite-core-2.9.0-SNAPSHOT.jar > ignite-indexing-2.9.0-SNAPSHOT.jar > ignite-shmem-1.0.0.jar > ignite-spring-2.9.0-SNAPSHOT.jar > lucene-analyzers-common-7.4.0.jar > lucene-core-7.4.0.jar > lucene-queryparser-7.4.0.jar > spring-aop-4.3.18.RELEASE.jar > spring-beans-4.3.18.RELEASE.jar > spring-context-4.3.18.RELEASE.jar > spring-core-4.3.18.RELEASE.jar > spring-expression-4.3.18.RELEASE.jar > spring-jdbc-4.3.18.RELEASE.jar > spring-tx-4.3.18.RELEASE.jar > > Those are required for SQL and Spring configs to work properly, > maybe we want to include them into the slim distro as well. > > On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev > > wrote: > > > Hello! > > > > This is a reasonable idea. > > > > I think we should also drop benchmarks/ directory from that build, it's > 60M > > of (potentially vulnerable) JARs that are not needed by an average > > developer's use cases. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk < > alexey.goncha...@gmail.com > > >: > > > > > Igniters, > > > > > > I would like to discuss with the community a possibility to create > > > additional 'slim' binary releases and docker images for Apache Ignite. > > The > > > reason is two-fold: > > > * The full set of 3rd party libraries distributed with Apache Ignite > > looks > > > too large for me. I know there is an ongoing activity towards more > clear > > > Ignite modularization [1][2][3], but this seems to be quite a long > > process. > > > On the other hand, creating a slim release may give an immediate > benefit > > to > > > the users who are interested in a smaller image. For example, removing > > the > > > benchmarks alone from the binary release saves 80M. > > > * As Ilya Kasnacheev demonstrated [4], the more 3rd party libraries we > > > have, the more potential vulnerabilities will show up in audit tools. > > This > > > may be a formal barrier for Apache Ignite adoption and moving to > > production > > > for many users. Having a slim image with the minimum number of > > dependencies > > > (yet complete enough to fit the majority of use-cases) significantly > > > reduces this risk. > > > > > > I wonder what community thinks regarding this idea? Given the recent > > study > > > of Apache Ignite use-cases, I suggest the following list of modules to > be > > > included to the slim release/image (a subject to discuss, of course): > > > * ignite-core > > > * ignite-indexing > > > * ignite-rest-http > > > * ignite-spring > > > * ignite-log4j > > > * ignite-log4j2 > > > * ignite-slf4j > > > * ignite-urideploy > > > * ignite-kubernetes > > > * ignite-opencensus > > > > > > [1] > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-3-0-and-to-be-removed-list-td42330.html > > > [2] > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12358-Migrate-ZeroMQ-module-to-ignite-extensions-td45067.html > > > [3] > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html > > > [4] > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-td43616i100.html#a44994 > > > > > > --AG > > > > > >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Hello again! I have prepared a patch that bumps some dependencies to their latest versions: https://issues.apache.org/jira/browse/IGNITE-12540 Please consider its inclusion to 2.8, and provide review if you are positive. Regards, -- Ilya Kasnacheev вт, 31 дек. 2019 г. в 15:54, Ilya Kasnacheev : > 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-6398, CVE-2014-0031, CVE-2014-9593, CVE-2015-3252 > docker-2.0.0.jar (pkg:maven/org.apache.jclouds.api/docker@2.0.0, > cpe:2.3:a:docker:docker:2.0.0:*:*:*:*:*:*:*) : CVE-2018-10892, > CVE-2019-13139, CVE-2019-13509, CVE-2019-15752, CVE-2019-16884, > CVE-2019-5736 > guava-16.0.1.jar (pkg:maven/com.google.guava/guava@16.0.1, > cpe:2.3:a:google:guava:16.0.1:*:*:*:*:*:*:*) : CVE-
Re: Slim binary release and docker image for Apache Ignite
Alex,
I'm on your end and support the proposal. Could you also clarify if you
suggest we keeping or removing C++ and .NET thick clients?
Speaking of the naming, how about titling such packages as 'core' instead
of 'slim', i.e., 'apache-ignite-core-{version}'?
-
Denis
On Wed, Jan 15, 2020 at 5:17 AM Ilya Kasnacheev
wrote:
> Hello!
>
> Pavel, I believe these JARs are fully covered by the list of modules
> specified above.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn :
>
> > I like the idea, current distribution is certainly too big.
> >
> > Here is a list of jar files we include in NuGet package:
> >
> > cache-api-1.0.0.jar
> > commons-codec-1.11.jar
> > commons-logging-1.1.1.jar
> > h2-1.4.197.jar
> > ignite-core-2.9.0-SNAPSHOT.jar
> > ignite-indexing-2.9.0-SNAPSHOT.jar
> > ignite-shmem-1.0.0.jar
> > ignite-spring-2.9.0-SNAPSHOT.jar
> > lucene-analyzers-common-7.4.0.jar
> > lucene-core-7.4.0.jar
> > lucene-queryparser-7.4.0.jar
> > spring-aop-4.3.18.RELEASE.jar
> > spring-beans-4.3.18.RELEASE.jar
> > spring-context-4.3.18.RELEASE.jar
> > spring-core-4.3.18.RELEASE.jar
> > spring-expression-4.3.18.RELEASE.jar
> > spring-jdbc-4.3.18.RELEASE.jar
> > spring-tx-4.3.18.RELEASE.jar
> >
> > Those are required for SQL and Spring configs to work properly,
> > maybe we want to include them into the slim distro as well.
> >
> > On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > >
> > wrote:
> >
> > > Hello!
> > >
> > > This is a reasonable idea.
> > >
> > > I think we should also drop benchmarks/ directory from that build, it's
> > 60M
> > > of (potentially vulnerable) JARs that are not needed by an average
> > > developer's use cases.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > >
> > > > Igniters,
> > > >
> > > > I would like to discuss with the community a possibility to create
> > > > additional 'slim' binary releases and docker images for Apache
> Ignite.
> > > The
> > > > reason is two-fold:
> > > > * The full set of 3rd party libraries distributed with Apache Ignite
> > > looks
> > > > too large for me. I know there is an ongoing activity towards more
> > clear
> > > > Ignite modularization [1][2][3], but this seems to be quite a long
> > > process.
> > > > On the other hand, creating a slim release may give an immediate
> > benefit
> > > to
> > > > the users who are interested in a smaller image. For example,
> removing
> > > the
> > > > benchmarks alone from the binary release saves 80M.
> > > > * As Ilya Kasnacheev demonstrated [4], the more 3rd party libraries
> we
> > > > have, the more potential vulnerabilities will show up in audit tools.
> > > This
> > > > may be a formal barrier for Apache Ignite adoption and moving to
> > > production
> > > > for many users. Having a slim image with the minimum number of
> > > dependencies
> > > > (yet complete enough to fit the majority of use-cases) significantly
> > > > reduces this risk.
> > > >
> > > > I wonder what community thinks regarding this idea? Given the recent
> > > study
> > > > of Apache Ignite use-cases, I suggest the following list of modules
> to
> > be
> > > > included to the slim release/image (a subject to discuss, of course):
> > > > * ignite-core
> > > > * ignite-indexing
> > > > * ignite-rest-http
> > > > * ignite-spring
> > > > * ignite-log4j
> > > > * ignite-log4j2
> > > > * ignite-slf4j
> > > > * ignite-urideploy
> > > > * ignite-kubernetes
> > > > * ignite-opencensus
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-3-0-and-to-be-removed-list-td42330.html
> > > > [2]
> > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12358-Migrate-ZeroMQ-module-to-ignite-extensions-td45067.html
> > > > [3]
> > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html
> > > > [4]
> > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-td43616i100.html#a44994
> > > >
> > > > --AG
> > > >
> > >
> >
>
[jira] [Created] (IGNITE-12545) Introduce listener interface for components to react to partition map exchange events
Ivan Rakov created IGNITE-12545: --- Summary: Introduce listener interface for components to react to partition map exchange events Key: IGNITE-12545 URL: https://issues.apache.org/jira/browse/IGNITE-12545 Project: Ignite Issue Type: Bug Reporter: Ivan Rakov It would be handly to have listener interface for components that should react to PME instead of just adding more and more calls to GridDhtPartitionsExchangeFuture. In general, there are four possible moments when a compnent can be notified: on exchnage init (before and after topologies are updates and exchange latch is acquired) and on exchange done (before and after readyTopVer is incremented and user operations are unlocked). -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Slim binary release and docker image for Apache Ignite
Hello!
I think we should name it "core" since we already have ignite-core and it
will be confusing. Maybe we should go full 00s and call it "lite"?
I also think we should keep both .Net and C++. .Net is runnable out of box
which is awesome, and C++ needs building but it is rather small in source
form.
I also suggest a different change to build process. Let's ship C++ with
automake, etc, already run, for all binary packaging options? WDYT? I can
assist in build process tuning.
Regards,
--
Ilya Kasnacheev
ср, 15 янв. 2020 г. в 17:18, Denis Magda :
> Alex,
>
> I'm on your end and support the proposal. Could you also clarify if you
> suggest we keeping or removing C++ and .NET thick clients?
>
> Speaking of the naming, how about titling such packages as 'core' instead
> of 'slim', i.e., 'apache-ignite-core-{version}'?
>
>
> -
> Denis
>
>
> On Wed, Jan 15, 2020 at 5:17 AM Ilya Kasnacheev >
> wrote:
>
> > Hello!
> >
> > Pavel, I believe these JARs are fully covered by the list of modules
> > specified above.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn :
> >
> > > I like the idea, current distribution is certainly too big.
> > >
> > > Here is a list of jar files we include in NuGet package:
> > >
> > > cache-api-1.0.0.jar
> > > commons-codec-1.11.jar
> > > commons-logging-1.1.1.jar
> > > h2-1.4.197.jar
> > > ignite-core-2.9.0-SNAPSHOT.jar
> > > ignite-indexing-2.9.0-SNAPSHOT.jar
> > > ignite-shmem-1.0.0.jar
> > > ignite-spring-2.9.0-SNAPSHOT.jar
> > > lucene-analyzers-common-7.4.0.jar
> > > lucene-core-7.4.0.jar
> > > lucene-queryparser-7.4.0.jar
> > > spring-aop-4.3.18.RELEASE.jar
> > > spring-beans-4.3.18.RELEASE.jar
> > > spring-context-4.3.18.RELEASE.jar
> > > spring-core-4.3.18.RELEASE.jar
> > > spring-expression-4.3.18.RELEASE.jar
> > > spring-jdbc-4.3.18.RELEASE.jar
> > > spring-tx-4.3.18.RELEASE.jar
> > >
> > > Those are required for SQL and Spring configs to work properly,
> > > maybe we want to include them into the slim distro as well.
> > >
> > > On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > This is a reasonable idea.
> > > >
> > > > I think we should also drop benchmarks/ directory from that build,
> it's
> > > 60M
> > > > of (potentially vulnerable) JARs that are not needed by an average
> > > > developer's use cases.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com
> > > > >:
> > > >
> > > > > Igniters,
> > > > >
> > > > > I would like to discuss with the community a possibility to create
> > > > > additional 'slim' binary releases and docker images for Apache
> > Ignite.
> > > > The
> > > > > reason is two-fold:
> > > > > * The full set of 3rd party libraries distributed with Apache
> Ignite
> > > > looks
> > > > > too large for me. I know there is an ongoing activity towards more
> > > clear
> > > > > Ignite modularization [1][2][3], but this seems to be quite a long
> > > > process.
> > > > > On the other hand, creating a slim release may give an immediate
> > > benefit
> > > > to
> > > > > the users who are interested in a smaller image. For example,
> > removing
> > > > the
> > > > > benchmarks alone from the binary release saves 80M.
> > > > > * As Ilya Kasnacheev demonstrated [4], the more 3rd party
> libraries
> > we
> > > > > have, the more potential vulnerabilities will show up in audit
> tools.
> > > > This
> > > > > may be a formal barrier for Apache Ignite adoption and moving to
> > > > production
> > > > > for many users. Having a slim image with the minimum number of
> > > > dependencies
> > > > > (yet complete enough to fit the majority of use-cases)
> significantly
> > > > > reduces this risk.
> > > > >
> > > > > I wonder what community thinks regarding this idea? Given the
> recent
> > > > study
> > > > > of Apache Ignite use-cases, I suggest the following list of modules
> > to
> > > be
> > > > > included to the slim release/image (a subject to discuss, of
> course):
> > > > > * ignite-core
> > > > > * ignite-indexing
> > > > > * ignite-rest-http
> > > > > * ignite-spring
> > > > > * ignite-log4j
> > > > > * ignite-log4j2
> > > > > * ignite-slf4j
> > > > > * ignite-urideploy
> > > > > * ignite-kubernetes
> > > > > * ignite-opencensus
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-3-0-and-to-be-removed-list-td42330.html
> > > > > [2]
> > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12358-Migrate-ZeroMQ-module-to-ignite-extensions-td45067.html
> > > > > [3]
> > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html
> > > > > [4]
> > > > >
> > > > >
> > > >
> > >
Re: Slim binary release and docker image for Apache Ignite
+1 for slim binary
Plus docker-slim
Plus RPM / DEB packages modularisation like PHP distribution — with core and
lots of integrations / modules.
> On 15 Jan 2020, at 17:40, Ilya Kasnacheev wrote:
>
> Hello!
>
> I think we should name it "core" since we already have ignite-core and it
> will be confusing. Maybe we should go full 00s and call it "lite"?
>
> I also think we should keep both .Net and C++. .Net is runnable out of box
> which is awesome, and C++ needs building but it is rather small in source
> form.
>
> I also suggest a different change to build process. Let's ship C++ with
> automake, etc, already run, for all binary packaging options? WDYT? I can
> assist in build process tuning.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 15 янв. 2020 г. в 17:18, Denis Magda :
>
>> Alex,
>>
>> I'm on your end and support the proposal. Could you also clarify if you
>> suggest we keeping or removing C++ and .NET thick clients?
>>
>> Speaking of the naming, how about titling such packages as 'core' instead
>> of 'slim', i.e., 'apache-ignite-core-{version}'?
>>
>>
>> -
>> Denis
>>
>>
>> On Wed, Jan 15, 2020 at 5:17 AM Ilya Kasnacheev >>
>> wrote:
>>
>>> Hello!
>>>
>>> Pavel, I believe these JARs are fully covered by the list of modules
>>> specified above.
>>>
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>>
>>>
>>> ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn :
>>>
I like the idea, current distribution is certainly too big.
Here is a list of jar files we include in NuGet package:
cache-api-1.0.0.jar
commons-codec-1.11.jar
commons-logging-1.1.1.jar
h2-1.4.197.jar
ignite-core-2.9.0-SNAPSHOT.jar
ignite-indexing-2.9.0-SNAPSHOT.jar
ignite-shmem-1.0.0.jar
ignite-spring-2.9.0-SNAPSHOT.jar
lucene-analyzers-common-7.4.0.jar
lucene-core-7.4.0.jar
lucene-queryparser-7.4.0.jar
spring-aop-4.3.18.RELEASE.jar
spring-beans-4.3.18.RELEASE.jar
spring-context-4.3.18.RELEASE.jar
spring-core-4.3.18.RELEASE.jar
spring-expression-4.3.18.RELEASE.jar
spring-jdbc-4.3.18.RELEASE.jar
spring-tx-4.3.18.RELEASE.jar
Those are required for SQL and Spring configs to work properly,
maybe we want to include them into the slim distro as well.
On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
>>> ilya.kasnach...@gmail.com
>
wrote:
> Hello!
>
> This is a reasonable idea.
>
> I think we should also drop benchmarks/ directory from that build,
>> it's
60M
> of (potentially vulnerable) JARs that are not needed by an average
> developer's use cases.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk <
alexey.goncha...@gmail.com
>> :
>
>> Igniters,
>>
>> I would like to discuss with the community a possibility to create
>> additional 'slim' binary releases and docker images for Apache
>>> Ignite.
> The
>> reason is two-fold:
>> * The full set of 3rd party libraries distributed with Apache
>> Ignite
> looks
>> too large for me. I know there is an ongoing activity towards more
clear
>> Ignite modularization [1][2][3], but this seems to be quite a long
> process.
>> On the other hand, creating a slim release may give an immediate
benefit
> to
>> the users who are interested in a smaller image. For example,
>>> removing
> the
>> benchmarks alone from the binary release saves 80M.
>> * As Ilya Kasnacheev demonstrated [4], the more 3rd party
>> libraries
>>> we
>> have, the more potential vulnerabilities will show up in audit
>> tools.
> This
>> may be a formal barrier for Apache Ignite adoption and moving to
> production
>> for many users. Having a slim image with the minimum number of
> dependencies
>> (yet complete enough to fit the majority of use-cases)
>> significantly
>> reduces this risk.
>>
>> I wonder what community thinks regarding this idea? Given the
>> recent
> study
>> of Apache Ignite use-cases, I suggest the following list of modules
>>> to
be
>> included to the slim release/image (a subject to discuss, of
>> course):
>> * ignite-core
>> * ignite-indexing
>> * ignite-rest-http
>> * ignite-spring
>> * ignite-log4j
>> * ignite-log4j2
>> * ignite-slf4j
>> * ignite-urideploy
>> * ignite-kubernetes
>> * ignite-opencensus
>>
>> [1]
>>
>>
>
>>>
>> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-3-0-and-to-be-removed-list-td42330.html
>> [2]
>>
>>
>
>>>
>> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12358-Migrate-ZeroMQ-module-to-ignite-extensions-td45067.html
>> [3]
>>
>>
>
>>>
>> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-t
[jira] [Created] (IGNITE-12546) Prevent partitions owned by other nodes switch their state to MOVING due to counter difference on node join.
Alexey Scherbakov created IGNITE-12546: -- Summary: Prevent partitions owned by other nodes switch their state to MOVING due to counter difference on node join. Key: IGNITE-12546 URL: https://issues.apache.org/jira/browse/IGNITE-12546 Project: Ignite Issue Type: Improvement Affects Versions: 2.7.6 Reporter: Alexey Scherbakov Assignee: Alexey Scherbakov Fix For: 2.9 When node joins it's expected that MOVING partitions can only belong to joining node. But if somehow counters are desynced other nodes can switch state of owning partitions to MOVING too, causing spurious rebalancing and assertions on mapping to moving primary. Possible solution: exclude other nodes partitions from switching state to MOVING on node join. This only affects persistent groups. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Thanks, Ilya. It would be really great to have your patch included into 2.8 scope. I'd like to give my two cent as well. For example we have vulnerable dependencies here: modules/cassandra/store/pom.xml - commons-beanutils modules/zookeeper/pom.xml - transitive Jackson from Curator I'd suggest to uprgrade commons-beanutils:commons-beanutils to 1.9.4 and override com.fasterxml.jackson.core:jackson-databind to our common jackson version from other modules. -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: Slim binary release and docker image for Apache Ignite
I'm +1 for "SLIM" it is a common name in Docker world.
On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov wrote:
> +1 for slim binary
> Plus docker-slim
> Plus RPM / DEB packages modularisation like PHP distribution — with core
> and lots of integrations / modules.
>
> > On 15 Jan 2020, at 17:40, Ilya Kasnacheev
> wrote:
> >
> > Hello!
> >
> > I think we should name it "core" since we already have ignite-core and it
> > will be confusing. Maybe we should go full 00s and call it "lite"?
> >
> > I also think we should keep both .Net and C++. .Net is runnable out of
> box
> > which is awesome, and C++ needs building but it is rather small in source
> > form.
> >
> > I also suggest a different change to build process. Let's ship C++ with
> > automake, etc, already run, for all binary packaging options? WDYT? I can
> > assist in build process tuning.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 15 янв. 2020 г. в 17:18, Denis Magda :
> >
> >> Alex,
> >>
> >> I'm on your end and support the proposal. Could you also clarify if you
> >> suggest we keeping or removing C++ and .NET thick clients?
> >>
> >> Speaking of the naming, how about titling such packages as 'core'
> instead
> >> of 'slim', i.e., 'apache-ignite-core-{version}'?
> >>
> >>
> >> -
> >> Denis
> >>
> >>
> >> On Wed, Jan 15, 2020 at 5:17 AM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> >>>
> >> wrote:
> >>
> >>> Hello!
> >>>
> >>> Pavel, I believe these JARs are fully covered by the list of modules
> >>> specified above.
> >>>
> >>> Regards,
> >>> --
> >>> Ilya Kasnacheev
> >>>
> >>>
> >>> ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn :
> >>>
> I like the idea, current distribution is certainly too big.
>
> Here is a list of jar files we include in NuGet package:
>
> cache-api-1.0.0.jar
> commons-codec-1.11.jar
> commons-logging-1.1.1.jar
> h2-1.4.197.jar
> ignite-core-2.9.0-SNAPSHOT.jar
> ignite-indexing-2.9.0-SNAPSHOT.jar
> ignite-shmem-1.0.0.jar
> ignite-spring-2.9.0-SNAPSHOT.jar
> lucene-analyzers-common-7.4.0.jar
> lucene-core-7.4.0.jar
> lucene-queryparser-7.4.0.jar
> spring-aop-4.3.18.RELEASE.jar
> spring-beans-4.3.18.RELEASE.jar
> spring-context-4.3.18.RELEASE.jar
> spring-core-4.3.18.RELEASE.jar
> spring-expression-4.3.18.RELEASE.jar
> spring-jdbc-4.3.18.RELEASE.jar
> spring-tx-4.3.18.RELEASE.jar
>
> Those are required for SQL and Spring configs to work properly,
> maybe we want to include them into the slim distro as well.
>
> On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
> >>> ilya.kasnach...@gmail.com
> >
> wrote:
>
> > Hello!
> >
> > This is a reasonable idea.
> >
> > I think we should also drop benchmarks/ directory from that build,
> >> it's
> 60M
> > of (potentially vulnerable) JARs that are not needed by an average
> > developer's use cases.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> >> :
> >
> >> Igniters,
> >>
> >> I would like to discuss with the community a possibility to create
> >> additional 'slim' binary releases and docker images for Apache
> >>> Ignite.
> > The
> >> reason is two-fold:
> >> * The full set of 3rd party libraries distributed with Apache
> >> Ignite
> > looks
> >> too large for me. I know there is an ongoing activity towards more
> clear
> >> Ignite modularization [1][2][3], but this seems to be quite a long
> > process.
> >> On the other hand, creating a slim release may give an immediate
> benefit
> > to
> >> the users who are interested in a smaller image. For example,
> >>> removing
> > the
> >> benchmarks alone from the binary release saves 80M.
> >> * As Ilya Kasnacheev demonstrated [4], the more 3rd party
> >> libraries
> >>> we
> >> have, the more potential vulnerabilities will show up in audit
> >> tools.
> > This
> >> may be a formal barrier for Apache Ignite adoption and moving to
> > production
> >> for many users. Having a slim image with the minimum number of
> > dependencies
> >> (yet complete enough to fit the majority of use-cases)
> >> significantly
> >> reduces this risk.
> >>
> >> I wonder what community thinks regarding this idea? Given the
> >> recent
> > study
> >> of Apache Ignite use-cases, I suggest the following list of modules
> >>> to
> be
> >> included to the slim release/image (a subject to discuss, of
> >> course):
> >> * ignite-core
> >> * ignite-indexing
> >> * ignite-rest-http
> >> * ignite-spring
> >> * ignite-log4j
> >> * ignite-log4j2
> >> * ignite-slf4j
> >> * ignite-urideploy
> >> * ignite-kubernetes
> >> * ignite-opencensus
> >>
> >> [1]
> >>
> >>
> >
>
[DISCUSSION] API to KILL any user started computation
Hello, Igniters. As you may know, we put a lot of effort to improve Ignite metric and diagnostic API. We have created the following API: * Metric manager * System view manager As far as I know, we would have tracing capabilities soon. I think it's time to take the next step. We should provide to the administrator the API to cancel(stop, kill) arbitrary user started computation. Right now we have API to do it for: * transactions `TransactionsMXBean#getActiveTransactions`. * SQL queries: `KILL QUERY` sql command and visor task - `VisorQueryCancelTask` Please, note, these features are implemented via different API. I think we should introduce uniform Cancel API for the following computations: * service. * specific service method execution. * compute job(compute task). * query(scan, continuous, text). We should also rework kill transaction and kill SQL queries API to make them similar to each other. I have plans to write an IEP for it and implement it. What do you think?
[MTCGA]: new failures in builds [4926613] 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. *New stable failure of a flaky test in master-nightly GridTimeoutProcessorSelfTest.testAddRemoveInterleaving https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7465161825263047806&branch=%3Cdefault%3E&tab=testDetails Changes may lead to failure were done by - nikolay https://ci.ignite.apache.org/viewModification.html?modId=895426 - 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 01:18:40 16-01-2020
Re: Please a reviewer for the case IGNITE-12518
Hi Luis, Thank you for sharing the details on the changes. I reviewed the dependencies that you shared in the jira issue and wanted to discuss on the changes. The purpose of ignite-rest-http is to provide a web based interface to easily access and use the ignite features and the changes you suggested can be built as part of separate application and ignite-rest-http can be used as an add on dependency. This will help keep ignite-rest-http module as minimal and thin as possible. Please review and share your thoughts. Regards, Saikat On Mon, Jan 13, 2020 at 7:24 PM Luis Arce wrote: > Hi Saikat, > I add information for evidence for the changes of ignite rest-http module. > > 1. Can you please share more information on the issue that will be resolved > with this change? > R: This change add the possibility for publish war files with webpages in > JSF or webservices JaxWS inside of the jetty server embedded. > When the WAR file is loade automatically attached the JNDI for lockup to > Ignite DataBase to the context of the page. > (I have a mvc4 application with ignite as a backend, with it change i dont > need a primary web server). > > [image: imagen.png] > > [image: imagen.png] > > My webpage > [image: imagen.png] > > My mvc4 > [image: imagen.png] > > The WebService > > [image: imagen.png] > The WSDL > [image: imagen.png] > > SoapUI > [image: imagen.png] > > TestSuite SoapUI > [image: imagen.png] > > > > > *Luis Arce Martínez*Licenciado e Ingeniero en Informática y Gestión > 09-57861903 > Linkedin: > https://cl.linkedin.com/in/luisalejandroarcemartinez > > > > > > El dom., 12 ene. 2020 a las 14:43, Saikat Maitra () > escribió: > >> Hi Luis, >> >> 1. Can you please share more information on the issue that will be >> resolved >> with this change? >> 2. To accommodate the change, would you be able to raise a PR please. >> Please take a look into the PR process >> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute >> 3. Can you please add tests and execute the related testsuite in teamcity >> https://ci.ignite.apache.org/ >> >> Regards, >> Saikat >> >> On Fri, Jan 10, 2020 at 5:39 PM Luis Arce wrote: >> >> > Dear community, >> > >> > I made modifications to the module rest-http. >> > It works correctly. >> > Is possible if anybody take my case for the review? >> > >> > The modifications are: >> > Support for webpages (test with jsf and primefaces), support for root >> > context. >> > Support to JaxWS with RI version. >> > Support for access to Ignite database with JNDI and basic connection >> > pooling' >> > >> > Se despide Atentamente, >> > >> > >> > *Luis Arce Martínez*Licenciado e Ingeniero en Informática y Gestión >> > 09-57861903 >> > Linkedin: >> > https://cl.linkedin.com/in/luisalejandroarcemartinez >> > >> >
Re: IGNITE-12361 Migrate Flume module to ignite-extensions
Hi Denis, Alexey Thank you so much for your email. I really appreciate it. Regards, Saikat On Wed, Jan 15, 2020 at 4:11 AM Alexey Goncharuk wrote: > Saikat, > > Thanks for working on this! I'll do my best to take a look at it this week. > > --AG > > пн, 13 янв. 2020 г. в 21:37, Denis Magda : > > > Alex Goncharuk, Nikolay Izhikov, > > > > Could you possibly check the changes or suggest any other > > committer/contributor for that? > > > > - > > Denis > > > > > > On Sun, Jan 12, 2020 at 9:31 AM Saikat Maitra > > wrote: > > > >> Hello, > >> > >> These PRs are part of Modularization effort > >> > >> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations > >> > >> If the changes looks good, I can go ahead and merge the changes. > >> > >> Regards, > >> Saikat > >> > >> On Sun, Jan 5, 2020 at 1:08 PM Saikat Maitra > >> wrote: > >> > >> > Hi, > >> > > >> > I have raised PR for Ignite Flume migration to Ignite Extensions repo. > >> > > >> > Jira https://issues.apache.org/jira/browse/IGNITE-12361 > >> > > >> > PR https://github.com/apache/ignite-extensions/pull/4 > >> > https://github.com/apache/ignite/pull/7227 > >> > > >> > Please review and share feedback. > >> > > >> > This is part of our Modularization effort for Streamer modules > >> > > >> > https://issues.apache.org/jira/browse/IGNITE-12355 > >> > > >> > Regards, > >> > Saikat > >> > > >> > > >
[jira] [Created] (IGNITE-12547) Excessive AtomicLong instantiations leads to GC pressure.
Stanilovsky Evgeny created IGNITE-12547: --- Summary: Excessive AtomicLong instantiations leads to GC pressure. Key: IGNITE-12547 URL: https://issues.apache.org/jira/browse/IGNITE-12547 Project: Ignite Issue Type: Improvement Components: persistence Affects Versions: 2.7.6 Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny Fix For: 2.9 Excessive AtomicLong usage, i.e. AtomicLong[] leads to GC pressure and further starvation log messages, it would be more effective to replace AtomicLong[] with AtomicLongArray. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12548) Possible tx desync during recovery on near node left.
Alexey Scherbakov created IGNITE-12548: -- Summary: Possible tx desync during recovery on near node left. Key: IGNITE-12548 URL: https://issues.apache.org/jira/browse/IGNITE-12548 Project: Ignite Issue Type: Bug Affects Versions: 2.7.6 Reporter: Alexey Scherbakov Assignee: Alexey Scherbakov Fix For: 2.9 The problem appears if a transaction is starting to rollback in PREPARED state for some reason and concurrently near node is left triggering tx recovery protocol. Consider having two enlisted keys from different partitions mapped to different nodes N1 and N2. Due to race N1 local tx can be rolled back while N2 local tx is committed breaking tx atomicity guarantee. -- This message was sent by Atlassian Jira (v8.3.4#803005)
