[MTCGA]: new failures in builds [4293729] 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 IgniteConfigurationTest.TestSpringXml https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2423313125230633239=%3Cdefault%3E=testDetails Changes may lead to failure were done by - sergey.chugu...@gmail.com https://ci.ignite.apache.org/viewModification.html?modId=887407 - 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 07:18:47 09-07-2019
[MTCGA]: new failures in builds [4293730] 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 IgnitionStartTest.TestIgniteStartsFromSpringXml https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5370188720469073545=%3Cdefault%3E=testDetails Changes may lead to failure were done by - sergey.chugu...@gmail.com https://ci.ignite.apache.org/viewModification.html?modId=887407 - 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 06:03:38 09-07-2019
Who is owning this account
Who owns this community account? Please repond _ Sent from http://apache-ignite-developers.2346864.n4.nabble.com
Re: [discussion] using custom build of H2 for Ignite
Denis, thank you for the reply, making this vendor-neutral separate project and repository where Apache committers are in sync with GitHub collaborators could work for me. I still suggest le...@apache.org approve this once we agree on this. And I'm sorry for hijacking this topic, but as Apache-fanatic I prefer Apache projects, and I pretty sure most of us know about https://calcite.apache.org/ can we consider it as it keeps out the project in the Apache ecosystem? Sincerely, пн, 8 июл. 2019 г. в 23:51, Denis Magda : > Dmitry, > > To make this fully-vendor neutral even at the originating repository level, > we can create and work with the H2 fork as a separate Github repo (separate > project governed and maintained by Ignite community). That repo can't be > part of Ignite due to license mismatch. Thus, during release times, we need > to assemble a binary (maven artifact) from that fork. > > However, it's not clear to me how to use those sources during the dev time? > It sounds like Ignite can use only the binary (Maven) artifact that has to > be updated/regenerated if there are any changes. *SQL experts*, could you > please step in? > > Nickolay, as for that fork which is in GG codebase - GridGain is a major > contributor and maintainer but the others are welcomed to send > pull-requests. > > - > Denis > > > On Thu, Jul 4, 2019 at 9:26 AM Dmitriy Pavlov wrote: > > > Hi Denis, > > > > As you know, some time ago I've started a discussion about removing > > dependence from gridgain:shmem. Ignite community seems to be not so much > > interested in this removal, for now. So once added it could stay here > > forever. Reverse dependency direction seems to be more natural. It is > like > > the open-core model. > > > > I feel more comfortable if all Ignite dependencies are released as part > of > > the Ignite code base, or some open governed project with a license from > > Category A https://www.apache.org/legal/resolved.html. > > > > It is true that H2 has Category B license, so derivative can't be > committed > > into ASF repository. > > > > What if we consult with le...@apache.org to find additional ways to > donate > > forked version into ASF codebase? We anyway need their approval because > > gridgain/h2 has a non-standard license, so we should approve including > > non-standard licensed component it the product. > > > > Sincerely, > > Dmitriy Pavlov > > > > чт, 4 июл. 2019 г. в 18:57, Denis Magda : > > > > > Hi Igniters, > > > > > > As you know, Ignite SQL engine is tightly coupled with the H2 database > > that > > > provides basic parsing and query execution capabilities. This synergy > > has > > > worked well for a while until Ignite SQL engine got a much broader > > adoption > > > for all sort of use cases. > > > > > > Presently, there is a list of impactful issues and limitations related > to > > > memory management, distributed engine optimization, and queries > planning > > > that require changes in H2. We've tried to contribute to H2 directly > with > > > no significant luck - what's needed for our distributed engine is of no > > > interest to H2 community. At the same time, we can't leave the things > as > > > is, as long as these limitations keep Ignite SQL engine from gradual > > > evolution. > > > > > > As a solution, we created an H2 fork [1] and did all of the required > > > changes there. We would be happy to include the fork into Ignite source > > > base, but H2's license (available under dual MPL 2.0 and EPL 1.0) is > not > > > compliant with Apache 2.0. However, if Ignite starts using our maven > > > artifacts instead of the standard H2's ones, then the licensing issue > is > > > solved. > > > > > > Is the community ready to accept this solution and swap the standard H2 > > > artifact with the one prepared by GridGain? Presently, all of those > > > improvements are available to GridGain customers, but GridGain wants to > > > make all of them be available for Ignite community. And that's the only > > > legal way we've come up with... > > > > > > > > > [1] https://github.com/gridgain/gridgain/tree/master/modules/h2 > > > > > > > > > > > > -- > > > - > > > Denis > > > > > >
Re: [discussion] using custom build of H2 for Ignite
Dmitry, To make this fully-vendor neutral even at the originating repository level, we can create and work with the H2 fork as a separate Github repo (separate project governed and maintained by Ignite community). That repo can't be part of Ignite due to license mismatch. Thus, during release times, we need to assemble a binary (maven artifact) from that fork. However, it's not clear to me how to use those sources during the dev time? It sounds like Ignite can use only the binary (Maven) artifact that has to be updated/regenerated if there are any changes. *SQL experts*, could you please step in? Nickolay, as for that fork which is in GG codebase - GridGain is a major contributor and maintainer but the others are welcomed to send pull-requests. - Denis On Thu, Jul 4, 2019 at 9:26 AM Dmitriy Pavlov wrote: > Hi Denis, > > As you know, some time ago I've started a discussion about removing > dependence from gridgain:shmem. Ignite community seems to be not so much > interested in this removal, for now. So once added it could stay here > forever. Reverse dependency direction seems to be more natural. It is like > the open-core model. > > I feel more comfortable if all Ignite dependencies are released as part of > the Ignite code base, or some open governed project with a license from > Category A https://www.apache.org/legal/resolved.html. > > It is true that H2 has Category B license, so derivative can't be committed > into ASF repository. > > What if we consult with le...@apache.org to find additional ways to donate > forked version into ASF codebase? We anyway need their approval because > gridgain/h2 has a non-standard license, so we should approve including > non-standard licensed component it the product. > > Sincerely, > Dmitriy Pavlov > > чт, 4 июл. 2019 г. в 18:57, Denis Magda : > > > Hi Igniters, > > > > As you know, Ignite SQL engine is tightly coupled with the H2 database > that > > provides basic parsing and query execution capabilities. This synergy > has > > worked well for a while until Ignite SQL engine got a much broader > adoption > > for all sort of use cases. > > > > Presently, there is a list of impactful issues and limitations related to > > memory management, distributed engine optimization, and queries planning > > that require changes in H2. We've tried to contribute to H2 directly with > > no significant luck - what's needed for our distributed engine is of no > > interest to H2 community. At the same time, we can't leave the things as > > is, as long as these limitations keep Ignite SQL engine from gradual > > evolution. > > > > As a solution, we created an H2 fork [1] and did all of the required > > changes there. We would be happy to include the fork into Ignite source > > base, but H2's license (available under dual MPL 2.0 and EPL 1.0) is not > > compliant with Apache 2.0. However, if Ignite starts using our maven > > artifacts instead of the standard H2's ones, then the licensing issue is > > solved. > > > > Is the community ready to accept this solution and swap the standard H2 > > artifact with the one prepared by GridGain? Presently, all of those > > improvements are available to GridGain customers, but GridGain wants to > > make all of them be available for Ignite community. And that's the only > > legal way we've come up with... > > > > > > [1] https://github.com/gridgain/gridgain/tree/master/modules/h2 > > > > > > > > -- > > - > > Denis > > >
Re: apache ignite contribution
Hi Vladimir, I've added your account to the list. Welcome onboard. Best Regards, Dmitriy Pavlov P.S couple of links that should boost your onboarding: - short contributors guide https://github.com/apache/ignite/blob/master/CONTRIBUTING.md#contributing-to-apache-ignite - and its full version https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute пн, 8 июл. 2019 г. в 15:59, Владимир Белов-Федоров < belovfedorov.vladi...@gmail.com>: > Hi Dmitriy, > My jira username is vladimir.bf > > Thanks, > Vladimir > > Sent from my iPhone > > > On 5 Jul 2019, at 21:10, Dmitriy Pavlov wrote: > > > > Hi Vladimir, > > > > Welcome to the Apache Ignite community. Is it your JIRA username? > > > > Sincerely, > > Dmitriy Pavlov > > > > пт, 5 июл. 2019 г. в 16:10, Владимир Белов-Федоров < > > belovfedorov.vladi...@gmail.com>: > > > >> Hi devs, > >> > >> My name is Vladimir Belov-Fedorov. > >> Please register me as Apache Ignite contributor. > >> > >> Thank you! > >> >
Re: I would like to contribute to apache ignite -- jira username: akorensh
Hi Alexander, Welcome to Apache Ignite Community. See also short contributors guide https://github.com/apache/ignite/blob/master/CONTRIBUTING.md#contributing-to-apache-ignite and its full version https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute I've added your account to the list of contributors. Now you should be able to assign issues. Please note, that mentioned issue https://issues.apache.org/jira/browse/IGNITE-6796 is already assigned to a contributor and status is In Progress. Please ask him if he is willing to continue development or not. In there will be no response in 3days, we can consider it as approval via silence. Best Regards, Dmitriy Pavlov пн, 8 июл. 2019 г. в 18:48, Alex Korenshteyn : > Hello Ignite Community! > > My name is Alexander. I want to contribute to Apache Ignite and want to > start with this issue - IGNITE-6796, my JIRA username is akorensh. Any help > on this will be appreciated. > > Thanks! >
Re: Revisit added java modules in ignite.sh
Igniters, I present a ticket [1] removing java.transaction and java.corba modules from sh/bat scripts for your review. I remind that it fixes nodejs, python and php suites when running on Java 9 and 10. In case there is no activity on this I would like to merge it this week. [1] https://issues.apache.org/jira/browse/IGNITE-11946 ср, 3 июл. 2019 г. в 21:40, Павлухин Иван : > > I removed command line arguments enabling java.transaction and > java.corba module from TC configuration. All activity in a ticket [1]. > > [1] https://issues.apache.org/jira/browse/IGNITE-11946 > > вс, 30 июн. 2019 г. в 07:31, Павлухин Иван : > > > > I made 2 experiments: > > 1. Removed --add-modules=java.transaction from TC configurations. I > > have not observed any new test failures after that change. > > 2. Removed that option from ignite.sh in PR. In PR problematic thin > > client suites are green. > > > > See the ticket [1] for additional details. If there is no objections I > > will cleanup that option from TC configurations and Ignite scripts. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9687 > > > > пт, 28 июн. 2019 г. в 10:09, Павлухин Иван : > > > > > > Folks, > > > > > > During investigation of thin client test suite failures [1] I found > > > that it is not clear whether --add-modules=java.transaction in > > > ignite.sh/bat is needed (we add this module for Java 9 and 10). In > > > thread [1] I already mentioned that launching ignite.sh with Java 9 > > > and ignite-jta libraries on a classpath leads to an error. You can see > > > how it can look in a log [2]. > > > > > > My proposal here is to get rid off --add-modules=java.transaction from > > > stratup scripts and parameters used by TC. And I will try to explain > > > why. > > > > > > The story started in a ticket [3]. Where a recipe > > > --add-modules=java.transaction > > > --patch-module=java.transaction=$HOME/.m2/repository/javax/transaction/javax.transaction-api/1.3/javax.transaction-api-1.3.jar > > > allowed to execute JTA tests successfully. After that > > > --add-modules=java.transaction was added to launch scripts. But that > > > setup allowed to launch tests. And they failed actually due to > > > problems with resolving needed classes for test depndencies > > > (org.ow2.jotm:jotm-core). Needed classes were not found because the > > > dependency required classes from java standard library which were > > > moved to optional modules. And the thing is even trickier with a > > > --patch-module option because javax.transaction-api-1.3.jar contains a > > > superset of classes comparing to java.transaction module. So, I do not > > > see a need of adding this module. Moreover that module was removed > > > completely starting from Java 11. And even if missed something and it > > > has some meaning for Java 9/10, I still think that having uniform > > > setup for all Java versions simplifies matters. > > > > > > Have I missed something? Do we have an example how to check JTA > > > integration? How it can be used with a standalone Ignite setup? > > > > > > P.S. Also I will try to do a similar reseach about java.xml.bind > > > module if noone knows why do we need it. > > > > > > [1] > > > http://apache-ignite-developers.2346864.n4.nabble.com/Thin-client-test-suites-failure-td42388.html > > > [2] > > > https://ci.ignite.apache.org/viewLog.html?buildId=4217786=IgniteTests24Java8_ThinClientNodeJs=buildLog_IgniteTests24Java8=pull%2F6644%2Fhead&_focus=423#_state=423 > > > [3] https://issues.apache.org/jira/browse/IGNITE-9687 > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > > > -- > Best regards, > Ivan Pavlukhin -- Best regards, Ivan Pavlukhin
I would like to contribute to apache ignite -- jira username: akorensh
Hello Ignite Community! My name is Alexander. I want to contribute to Apache Ignite and want to start with this issue - IGNITE-6796, my JIRA username is akorensh. Any help on this will be appreciated. Thanks!
I would like to contribute to Apache Ignite. -- Jira username: akorensh
Hello Ignite Community! My name is Alexander. I want to contribute to Apache Ignite and want to start with this issue - IGNITE-6796, my JIRA username akorensh. Any help on this will be appreciated. Thanks!
Re: [DISCUSSION][IEP-35] Metrics configuration
Nikolay, To me a separate metrics configuration file seems to be not very user-friendly. First of all, it does not allow to configure the system only from Java code. Second, having multiple configuration files seem to be quite confusing for end users (judging by the logging configuration questions). Perhaps, we will still end up with the configuration file - but for now I would put this aside for a more thorough brainstorm and added the JMX and internal API for changing metrics configuration. пт, 5 июл. 2019 г. в 14:17, Seliverstov Igor : > Igniters, > > One more question on topic. > > Should we preserve metrics configuration on restart? (I think we should) > > If so, which configuration use after restart? Defined in config file or > saved in config storage? (I guess, saved configuration should have a > priority) > > So, how to tell users that any changes in configuration file have no > effect on Ignite configuration after first start? > > I think there are too many open questions and (at least at now) we should > provide only JMX API until all of the questions are clarified. > > Regards, > Igor > > > 4 июля 2019 г., в 19:55, Nikolay Izhikov > написал(а): > > > > Hello, Andrey. > > > >> 3. I can't imagine that adequate values will be chosen on project > >> setup stage. > > > > Configuration file required in the case we adds new node or replace > existing to the cluster. > > Use can have parameters similar to Ignite configuration, log > configuration files. > > > >> My proposal is adding API for boundaries configuration to the metrics > >> framework and expose it via JMX > > > > Agree. I think we should have both: > > > > 1. Configuration file. > > 2. JMX API to change bounaries of histogram *and HitRateMetric params*. > > > > But, if you and other community member are against config file, let's > have only JMX. > > Seems, JMX will provide required level of configurability for metrics. > > > > > > В Чт, 04/07/2019 в 17:53 +0300, Andrey Gura пишет: > >> Igniters, > >> > >> I rethought the issue and I see some problems: > >> > >> 1. It seems that in most cases bucket boundaries configuration will be > >> problem for user. Absolute values for latency boundaries it is very > >> odd choice. > >> 2. Also seems that latency for most caches (if we configure cache > >> metrics fro example) will be similar. > >> 3. I can't imagine that adequate values will be chosen on project > >> setup stage. So chosen values should be changed in the future. > >> > >> Solution with configuration file looks unnatural and creates more > >> problems than could solve. > >> > >> My proposal is adding API for boundaries configuration to the metrics > >> framework and expose it via JMX (at this step). It still provides > >> configuration possibility but don't force user to do it. > >> > >> Also we should chose default values for bucket boundaries. And it is > >> most complex problem at the moment :) Let's discuss it. > >> > >> > >> > >> > >> > >> On Wed, Jul 3, 2019 at 4:49 PM Andrey Gura wrote: > >>> > >>> Nikolai, > >>> > >>> Metric is disabled if it doesn't allocate any memory and doesn't > >>> update any variable because doesn't have any value. Ideally disabling > >>> metrics for some cache should be equal to cache stopping. > >>> > >>> On Fri, Jun 28, 2019 at 1:02 PM Nikolay Izhikov > wrote: > > Hello, Alexey. > > Thanks for the feedback! > > > My only concert is that we should have the metrics framework > configuration > > as the first-citizen of the framework itself > > Yes. I planned to add `void configure(String param)` method to the > metric API. > > > but change the metrics parameters in > > runtime from JMX or command-line, etc. > > I've add requirement of JMX method to the ticket: > > https://issues.apache.org/jira/browse/IGNITE-11927 > > > Another concern is to have an > > ability to disable/enable metrics per metrics group/prefix. > > Yes, we discusss it. > But, let's make it clear: > > *What is disabling metric?* > > Looks like exporter filter solve this task. > > В Чт, 27/06/2019 в 16:24 +0300, Alexey Goncharuk пишет: > > Nikolay, > > > > My only concert is that we should have the metrics framework > configuration > > as the first-citizen of the framework itself. This way, we can > configure > > the metrics not only from file, but change the metrics parameters in > > runtime from JMX or command-line, etc. Another concern is to have an > > ability to disable/enable metrics per metrics group/prefix. > > > > The logger-like configuration meets these suggestions given that the > > configuration is generalized into the metrics framework. > > > > What do you think? > > > > чт, 27 июн. 2019 г. в 12:30, Nikolay Izhikov : > > > >> Hello, Igniters. > >> > >> As you may know, I've contributed Phase1 [1] for IEP-35 [2]. >
[jira] [Created] (IGNITE-11967) control.sh validate_indexes SQL Index issue must contain information about cache group
Kirill Tkalenko created IGNITE-11967: Summary: control.sh validate_indexes SQL Index issue must contain information about cache group Key: IGNITE-11967 URL: https://issues.apache.org/jira/browse/IGNITE-11967 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: apache ignite contribution
Hi Dmitriy, My jira username is vladimir.bf Thanks, Vladimir Sent from my iPhone > On 5 Jul 2019, at 21:10, Dmitriy Pavlov wrote: > > Hi Vladimir, > > Welcome to the Apache Ignite community. Is it your JIRA username? > > Sincerely, > Dmitriy Pavlov > > пт, 5 июл. 2019 г. в 16:10, Владимир Белов-Федоров < > belovfedorov.vladi...@gmail.com>: > >> Hi devs, >> >> My name is Vladimir Belov-Fedorov. >> Please register me as Apache Ignite contributor. >> >> Thank you! >>
