Re: Please a reviewer for the case IGNITE-12518
Hi, Luis, Denis We can take up the changes in either Ignite-extensions repo as new independent module or as part of ignite repo inside rest-http module but since the changes are not in git pull request it is hard for us to review and share feedback. 1. There are jar dependencies shared in the jira ticket[1] but we do not accept jar instead we will require the changes in maven pom.xml file. 2. There are also changes in GridJettyRestHandler and GridJettyRestProtocol but there are no corresponding tests for validation. It will be better if required tests are added as part of PR. 3. It is also unclear how do we incorporate the changes mentioned in the jira related to web.xml file, Do they need to be part of README.md? Please let me know if I can help in any way with PR process. Our docs for contribution are available here [2] [1] https://issues.apache.org/jira/browse/IGNITE-12518 [2] https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute Regards, Saikat On Fri, Jan 24, 2020 at 11:09 AM Denis Magda wrote: > Hi Luis, > > Presently, the community is on the route of Ignite simplification. We're > trying to define Ignite core that has minimal dependencies with 3rd party > libraries. That also led to the modularization initiative [1] with the > first results in the form of Ignite Extensions repository where we're > moving all 3rd party integrations. > > Saikat, do you think Luis's contribution needs to reside in the extensions > repository? > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization > > - > Denis > > > On Thu, Jan 23, 2020 at 8:48 PM Luis Arce wrote: > > > Hi Saikat, > > Thanks for you response: > > > > My system need a web server for work. i work correctly with Wildfly and i > > use Ignite as Backend for database. > > My problem is the combination of both is around 6 GB RAM for work in the > > VPS. > > For this reason i modified the unique plugin with webserver inside > > (rest-http module). > > The change enabled the possibility for use only 3GB RAM in a VPS ( > > vpsserver.com) saving money and enabling horizontal scalling. > > I shared this change in the Jira ticket touching the two classes of > > rest-http plugin. > > The change has less impact (programaticly), the point is the library > > dependencies (quantity of jars). > > > > It change has sense for you?, i think is a util because that technologies > > dont has present inside of ignite currently and is friendly with the code > > of rest-ignite. > > > > > > > > > > Best regards, > > > > > > *Luis Arce Martínez*Licenciado e Ingeniero en Informática y Gestión > > 09-57861903 > > Linkedin: > > https://cl.linkedin.com/in/luisalejandroarcemartinez > > > > > > > > > > > > El mié., 22 ene. 2020 a las 0:38, Saikat Maitra (< > saikat.mai...@gmail.com > > >) > > escribió: > > > > > Hello Luis, > > > > > > Thank you for your email. You can plan to create a separate application > > for > > > jaxws service and use any build tools like gradle or maven to define > your > > > dependencies. > > > > > > Please find below some of the performance tips related to Ignite > > > > > > https://apacheignite.readme.io/docs/durable-memory-tuning > > > > > > You can use IgniteClient in your service and can connect to remote > > cluster > > > of Apache Ignite for data persistence. > > > > > > Can you please correct my understanding on the usage of > ignite-rest-http > > > in IGNITE-12518, I see the dependencies you have mentioned are related > to > > > your project and my understanding is you are trying to use > > ignite-rest-http > > > jetty server for running your application. My understanding is this > > change > > > will make ignite-rest-http very large jar file with dependencies > > > like tomcat-servlet-api-9.0.10.jar may not needed outside of your > project > > > scope. > > > > > > Please let me know your thoughts. > > > > > > Regards, > > > Saikat > > > > > > > > > On Sun, Jan 19, 2020 at 9:47 PM Luis Arce wrote: > > > > > > > Hi Saikat, > > > > I agree, the impact of changes is bigger on the module. > > > > I have a question: If i need create a jaxws service what is your > > > > recomendation? > > > > My motivation for the changes is the next: > > > > *Introduction.* > > > > A few time ago i design a ABB for traceability for Oracle Service Bus > > > with > > > > the objective of detecting failures points in many processes of a > > > customer. > > > > In first instance my team worked with rest-http module in ignite 2.4 > > with > > > > poor results, the quantity of TPS was 4.Then we make a implementation > > of > > > > Rest service inside Apache Tomcat and call to Apache Ignite directly > to > > > > Database with persistence activated. This change, enabled the > > possibility > > > > for work with 4 environment of the customer (Development, Testing, > QA, > > > > Production) with 8GB of RAM in the machine, the configuration of the > > > client > > > > had a Oracle Portal for the View layer, EJB for
[jira] [Created] (IGNITE-12581) [REFACTORING] Test parametrization
Nikolay Izhikov created IGNITE-12581: Summary: [REFACTORING] Test parametrization Key: IGNITE-12581 URL: https://issues.apache.org/jira/browse/IGNITE-12581 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov Right now many Ignite tests parametrization implemented via inheritance. For example: parent - JdbcThinBulkLoadAbstractSelfTest extensions - JdbcThinBulkLoadAtomicPartitionedNearSelfTest, JdbcThinBulkLoadAtomicPartitionedSelfTest, JdbcThinBulkLoadAtomicReplicatedSelfTest, JdbcThinBulkLoadTransactionalPartitionedNearSelfTest, JdbcThinBulkLoadTransactionalPartitionedSelfTest, JdbcThinBulkLoadTransactionalReplicatedSelfTest. Look like we can significantly reduce tests code base, therefore, improve readability and maintainability without losing any test-cases if we use the JUnit parameterized approach. A contributor can use this ticket as an umbrella one and create a sub-ticket for each refactored test-classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: New contributor
Could you tell us what team did you join? I'll work, for example, with Anton Vinogradov, Maxim Muzafarov, Nikolay Izhikov, Maxim Muzafarov and several others. The main focus is core functionality. 24.01.2020 16:15, Ivan Pavlukhin пишет: Vladimir, Welcome to Apache Ignite Community! I added a contributor role to your Jira account. Now you can assign tickets to yourself. Please get familiar with the contribution process [1]. By the way, I've just joined a team with the commiters. Could you tell us what team did you join? [1] https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute пт, 24 янв. 2020 г. в 16:01, Vladimir Steshin : Hello everyone! My name is Vladimir. I'd like to become new contributor of Apache Ignite as a developer. I've just joined a team with the commiters. I've been working as Java developer more than 10 years with a bunch of various frameworks and solutions. Now I'm interrested in modern open source pojects, distributed data bases and computations. I have an expirience of working with Apache Ignite in real project on production. I'd be happy to participate in evolving of this project. A couple of fix-tickets have been already issued some time ago by my questions on the user forum :) You can find me in Jira as 'vladsz83'. Thanks!
Re: Internal classes are exposed in public API
Andrey. With this API we are trying to fill the GAP Alexey pointed out at the start of this discussion. I think it worth to be reviewed and merged. Can we, please, come back to the discussion of the changes itself? I think API changes should be discussed in the other thread. > Why do you think this is a wrong usage pattern? From the top of my head, here > is a few cases of direct metric API usage that I know are currently being > used in production: > * A custom task execution scheduling service with load balancing based on > utilization metrics readings from Java code > * Cleanup task trigger based on metrics readings > * A custom health-check endpoint for an application with an embedded Ignite > node for Kubernetes/Spring Application/etc [1] https://github.com/apache/ignite/pull/7283 > 24 янв. 2020 г., в 18:08, Andrey Gura написал(а): > >> My point - that your contribution that took a long time, already, can’t be >> an argument to postpone creation of the API in the current release. > > Argument is not about time. But about API which is known will be changed. > Second argument: why we should add this experimental API to the > already existing experimental API? Just to making API more > experimental? As I told already it is commit for commit and doesn't > bring any value but brings some inconvenience to me (e.g. merge > problems). > > BTW, does it exist issue about marking IEP-35 API's as experimental? > > On Thu, Jan 23, 2020 at 8:33 PM Николай Ижиков wrote: >> >>> You want say didn't discuss? >> >> Yes. >> >>> Secondly, yes it took a lot of time due to a lot of changes. Is it problem? >> >> No, of course. >> My point - that your contribution that took a long time, already, can’t be >> an argument to postpone creation of the API in the current release. >> >> >>> 23 янв. 2020 г., в 18:11, Andrey Gura написал(а): >>> We don’t discuss your changes and your proposals for the Metric API. >>> >>> You want say didn't discuss? Actually we did it [1] but you told ok >>> let's see code :) >>> So I don’t think we can make the existence of some PR is an argument to introduce(or not introduce) this facade. >>> >>> You definitely right in case of competition development. But I think >>> that collaborative development is more effective. Isn't it? >>> Moreover, As far as I know, you developing changes for the Metric API for 5 months without public discussion, for now. Let's start it. >>> >>> Firsty, with discussion. See above. >>> Secondly, yes it took a lot of time due to a lot of changes. Is it problem? >>> Let’s do the following: 1. Review `IgniteMetric` facade and introduce it to the users as an experimental API. >>> >>> It just doesn't make sense. Just commit for commit. >>> 2. Discuss your proposal to the Metric API in the separate thread you are referencing. >>> >>> You a re welcome to thread [1] again. But please, take into account. >>> because discussion is postponed by you it's late enough to discuss >>> proposed solution. But of course I'll answer on your questions and >>> will be glade to your comments and suggestions. >>> I think we should start a discussion from the simplified explanation of: 1. API intentions - What we want to gain with it? What is our focus? 2. Simple, minimal example of API main interfaces and desired usages. >>> >>> All this already described at [1]. You also can take a look on PR (see >>> MetricSource implementations, there are complex and simple ones). >>> >>> [1] >>> http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Metrics-management-in-Ignite-tp43243.html >>> >>> On Thu, Jan 23, 2020 at 5:42 PM Николай Ижиков wrote: Andrey. > IGNITE-11927 implementation so your changes are incompatible with my > changes We don’t discuss your changes and your proposals for the Metric API. So I don’t think we can make the existence of some PR is an argument to introduce(or not introduce) this facade. Moreover, As far as I know, you developing changes for the Metric API for 5 months without public discussion, for now. Let's start it. Let’s do the following: 1. Review `IgniteMetric` facade and introduce it to the users as an experimental API. 2. Discuss your proposal to the Metric API in the separate thread you are referencing. I think we should start a discussion from the simplified explanation of: 1. API intentions - What we want to gain with it? What is our focus? 2. Simple, minimal example of API main interfaces and desired usages. This will help to the community and me personally better understand your idea and share feedback. Thanks. > 23 янв. 2020 г., в 17:15, Andrey Gura написал(а): > > Nikolay, > > as I wrote early in this thread API significantly changed during > IGNITE-11927
