Re: [MTCGA]: new failures in builds [4944565] needs to be handled
It was caused by my fix. I will try to fix it shortly. ср, 22 янв. 2020 г. в 00:56, : > Hi Igniters, > > I've detected some new issue on TeamCity to be handled. You are more than > welcomed to help. > > If your changes can lead to this failure(s): We're grateful that you were > a volunteer to make the contribution to this project, but things change and > you may no longer be able to finalize your contribution. > Could you respond to this email and indicate if you wish to continue and > fix test failures or step down and some committer may revert you commit. > > *Recently contributed test failed in master-nightly > FreeListCachingTest.testPageListCacheLimit > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4892367253112139895=%3Cdefault%3E=testDetails > Changes may lead to failure were done by > - aleksei scherbakov > https://ci.ignite.apache.org/viewModification.html?modId=895725 > - aleksei scherbakov > https://ci.ignite.apache.org/viewModification.html?modId=895727 > - ilya kasnacheev > https://ci.ignite.apache.org/viewModification.html?modId=895710 > - aleksey plekhanov > https://ci.ignite.apache.org/viewModification.html?modId=895739 > - anton kalashnikov > https://ci.ignite.apache.org/viewModification.html?modId=895723 > - alexey goncharuk > https://ci.ignite.apache.org/viewModification.html?modId=895735 > - anton kalashnikov > https://ci.ignite.apache.org/viewModification.html?modId=895719 > - alexey goncharuk > https://ci.ignite.apache.org/viewModification.html?modId=895729 > > - 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 00:56:41 22-01-2020 >
Re: Ignite-spring-boot-autoconfigurer
Hi Nikolay,
I have reviewed the PR and shared comments.
Please let me know if you have any feedback.
Regards,
Saikat
On Mon, Jan 20, 2020 at 2:42 PM Николай Ижиков wrote:
> Hello, Saikat.
>
> Thanks, for feedback.
>
> I raised a PR [1] to `ignite-extensions`.
>
> You can find description of the new module below(examples can be found at
> [2]):
>
> Module provides the ability to integrate `Ignite` into you spring-boot
> application with zero(or minimal) configuration.
>
> After you add this module as a dependency to your spring-boot application
> `Ignite` node will be configured and injected into `BeanFactory`.
>
> Algorithm to configure `Ignite` is the following:
> 1. If `IgniteConfiguration` bean exists in the `BeanFactory` it will be
> used.
> 2. If `IgniteConfiguration` bean doesn't exist following rules are
> applied:
> 2.1. Default `Ignite` configuration created.
> 2.2. If `IgniteConfigurer` bean exists in `BeanFactory` it will be
> used to customize `IgniteConfiguration`.
> If a user wants to set custom SPI instances or similar hardcoded
> values
> one should do it with `IgniteConfigurer` implementation.
> 2.3 Application properties applied to `IgniteConfiguration`. Prefix
> for the properties is `ignite`.
>
>
> [1] https://github.com/apache/ignite-extensions/pull/6
> [2] https://github.com/nizhikov/ignite-spring-boot-autoconfigure-example
>
>
> > 18 янв. 2020 г., в 06:44, Saikat Maitra
> написал(а):
> >
> > Hi Nikolay,
> >
> > Thank you for your email. As part of Ignite Extensions migration we are
> migrating Ignite Extensions to following repo.
> >
> > https://github.com/apache/ignite-extensions
> >
> > We have added flink and pub-sub modules and few additional modules are
> open in PR.
> >
> > You can refer to this PR to see how we are migrating the modules
> https://github.com/apache/ignite-extensions/pull/5
> >
> > I wanted to connect and discuss the changes to understand the spring
> boot auto configure feature. We currently have an ignite spring module that
> allows resource injection capabilities and provides a parser for Spring
> based xml configuration files. Can you please review and share if the
> changes you are proposing can be added as part of Ignite spring module or
> it make sense to make it a separate spring boot auto configure module.
> >
> > https://github.com/apache/ignite/tree/master/modules/spring
> >
> > Regards,
> > Saikat
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Jan 17, 2020 at 3:12 AM Николай Ижиков
> wrote:
> > Tests added.
> > Please, review.
> >
> > Saikat, can you help with this PR [1]?
> >
> > I think it should be added as a separate module as we do with the flink
> integration.
> > Can you help me with it?
> > Do we have some how-to for it?
> >
> > [1] https://github.com/apache/ignite/pull/7237
> >
> > > 16 янв. 2020 г., в 16:51, Николай Ижиков
> написал(а):
> > >
> > > Hello, Denis.
> > >
> > > Thanks, for the feedback.
> > >
> > > Alexey, it seems, PR is ready to be reviewed, but I need some time(a
> day or two) to write tests.
> > > You can start with the core code review if you wish.
> > >
> > > Here are autoconfigurer requirements:
> > >
> > > 1. Start usage of Ignite with minimal(or zero) configuration.
> > > 2. Configure Ignite configuration properties with the standard spring
> boot application properties.
> > > 3. Configure Ignite SPI implementation and so on that can’t be
> configured via #2.
> > >
> > > After some consultation with the Spring experts from the
> community(Maxim Stepachev thanks for the idea)
> > > I updated the PR with the logic described below:
> > >
> > > 1. To enable Ignite auto-configuration user should add
> `org.apache.ignite:spring-boot-ignite-autoconfigure:2.9.0` to dependencies.
> > >After it Ignite node will be started during spring-boot application
> startup.
> > >
> > > 2. IgniteConfiguration initialization logic:
> > >
> > > 2.1 If {@link IgniteConfiguration} bean exists in {@link BeanFactory}
> it will be used for the node start.
> > > 2.2 If {@link IgniteConfiguration} bean doesn't exist following rules
> are applied:
> > > * Newly introducer IgniteConfigurer bean will be used to customize an
> empty IgniteConfiguration instance.
> > >If a user wants to set custom SPI instances or similar hardcoded
> values one should do it IgniteConfigurer implementation.
> > >
> > > * Application properties will override config values. Prefix for
> properties names is "ignite».
> > >
> > > PS. Similar logic applied for the second module -
> `org.apache.ignite:spring-boot-ignite-client-autoconfigure:2.9.0`.
> > > It provides the same features but for the autoconfiguration of the
> IgniteClient
> > >
> > >
> > >> 15 янв. 2020 г., в 03:03, Denis Magda написал(а):
> > >>
> > >> Nikolay,
> > >>
> > >> Thanks for contributing in this direction! That's one of the gaps on
> our
> > >> end and the user community will be certainly thankful once we fill it
> in.
> > >>
> > >> *Alexey Kuznetsov*, as
[jira] [Created] (IGNITE-12561) Add a check for conflict of field names in key and value
Evgeniy Rudenko created IGNITE-12561:
Summary: Add a check for conflict of field names in key and value
Key: IGNITE-12561
URL: https://issues.apache.org/jira/browse/IGNITE-12561
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Evgeniy Rudenko
Assignee: Evgeniy Rudenko
If key and value types of an SQL-enabled cache have the same fields annotated
with `@QuerySqlEntity` the cache will start without errors but the key's field
will not be queryable:
{color:#172b4d}{{{color:#505f79}// here, you can't query Key.a via
SQL{color}{color:#0052cc}class{color} {color:#6554c0}Key{color} {
@QuerySqlField {color:#0052cc}int{color} a; @QuerySqlField
{color:#0052cc}int{color} b; }{color:#0052cc}class{color}
{color:#6554c0}Value{color} { @QuerySqlField {color:#0052cc}int{color} a;
@QuerySqlField {color:#0052cc}int{color} c; }}}{color}
To workaround that, one needs to specify a different name for one of the `a`
fields:
{color:#172b4d}{{{color:#0052cc}class{color} {color:#6554c0}Key{color} {
@QuerySqlField(name = {color:#36b37e}"key_a"{color}) {color:#0052cc}int{color}
a; @QuerySqlField {color:#0052cc}int{color} b; }{color:#0052cc}class{color}
{color:#6554c0}Value{color} { @QuerySqlField {color:#0052cc}int{color} a;
@QuerySqlField {color:#0052cc}int{color} c; }}}{color}
The first configuration is obviously incorrect - one can't use the `Key.a` in
SQL but annotates it as queryable. We need to issue an error or at least a
warning for starting a configuration like this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Please a reviewer for the case IGNITE-12518
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 composition of the > controller layer, and OSB for the integration the TPS of the client are > biggest. > > *AS-IS* > > [image: imagen.png] > > *To Be roadmap* > > [image: imagen.png] > > With the ignite modification published in Jira is possible run JSF for run > my reports and forms, JaxWS for the service SOAP and Jersey for Rest (i > start modification in this task). > The code published in Jira have capabilites for work with Primefaces > (tested ok), JaxWS (tested ok), but jersey is not included yet. > > 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 jue., 16 ene. 2020 a las 0:25, Saikat Maitra () > escribió: > >> 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 (< >> saikat.mai...@gmail.com>) >> > 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,
Fwd: Call for presentations for ApacheCon North America 2020 now open
Ignite folks, just bringing to your attention and encourage anybody interested to submit an Ignite-related session. Both Alex Zinoviev and I presented at ApacheCons the previous year -- the events are worth attending and speaking at. - Denis -- Forwarded message - From: Rich Bowen Date: Tue, Jan 21, 2020 at 7:06 AM Subject: Call for presentations for ApacheCon North America 2020 now open To: plann...@apachecon.com Dear Apache enthusiast, (You’re receiving this message because you are subscribed to one or more project mailing lists at the Apache Software Foundation.) The call for presentations for ApacheCon North America 2020 is now open at https://apachecon.com/acna2020/cfp ApacheCon will be held at the Sheraton, New Orleans, September 28th through October 2nd, 2020. As in past years, ApacheCon will feature tracks focusing on the various technologies within the Apache ecosystem, and so the call for presentations will ask you to select one of those tracks, or “General” if the content falls outside of one of our already-organized tracks. These tracks are: Karaf Internet of Things Fineract Community Content Delivery Solr/Lucene (Search) Gobblin/Big Data Integration Ignite Observability Cloudstack Geospatial Graph Camel/Integration Flagon Tomcat Cassandra Groovy Web/httpd General/Other The CFP will close Friday, May 1, 2020 8:00 AM (America/New_York time). Submit early, submit often, at https://apachecon.com/acna2020/cfp Rich, for the ApacheCon Planners
[MTCGA]: new failures in builds [4944565] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *Recently contributed test failed in master-nightly FreeListCachingTest.testPageListCacheLimit https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4892367253112139895=%3Cdefault%3E=testDetails Changes may lead to failure were done by - aleksei scherbakov https://ci.ignite.apache.org/viewModification.html?modId=895725 - aleksei scherbakov https://ci.ignite.apache.org/viewModification.html?modId=895727 - ilya kasnacheev https://ci.ignite.apache.org/viewModification.html?modId=895710 - aleksey plekhanov https://ci.ignite.apache.org/viewModification.html?modId=895739 - anton kalashnikov https://ci.ignite.apache.org/viewModification.html?modId=895723 - alexey goncharuk https://ci.ignite.apache.org/viewModification.html?modId=895735 - anton kalashnikov https://ci.ignite.apache.org/viewModification.html?modId=895719 - alexey goncharuk https://ci.ignite.apache.org/viewModification.html?modId=895729 - 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 00:56:41 22-01-2020
Re: [MTCGA]: new failures in builds [4944525] needs to be handled
I've pushed the fix [1] [1] https://issues.apache.org/jira/browse/IGNITE-12560 вт, 21 янв. 2020 г. в 23:11, : > 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 > MetaStorageCompatibilityTest.testMigrationWithoutFullBaselineIntoPartition > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-369187610128267810=%3Cdefault%3E=testDetails > Changes may lead to failure were done by > - aleksei scherbakov > https://ci.ignite.apache.org/viewModification.html?modId=895725 > - aleksei scherbakov > https://ci.ignite.apache.org/viewModification.html?modId=895727 > - ilya kasnacheev > https://ci.ignite.apache.org/viewModification.html?modId=895710 > - aleksey plekhanov > https://ci.ignite.apache.org/viewModification.html?modId=895739 > - anton kalashnikov > https://ci.ignite.apache.org/viewModification.html?modId=895723 > - alexey goncharuk > https://ci.ignite.apache.org/viewModification.html?modId=895735 > - anton kalashnikov > https://ci.ignite.apache.org/viewModification.html?modId=895719 > - alexey goncharuk > https://ci.ignite.apache.org/viewModification.html?modId=895729 > > - 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 23:11:38 21-01-2020 > -- Best regards, Alexei Scherbakov
[jira] [Created] (IGNITE-12560) MetaStorageCompatibilityTest starts failing after compilation fix
Alexey Scherbakov created IGNITE-12560: -- Summary: MetaStorageCompatibilityTest starts failing after compilation fix Key: IGNITE-12560 URL: https://issues.apache.org/jira/browse/IGNITE-12560 Project: Ignite Issue Type: Bug Reporter: Alexey Scherbakov Assignee: Alexey Scherbakov Seems the problem is related to incompatible internal checkpoint API usage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[MTCGA]: new failures in builds [4944525] 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 MetaStorageCompatibilityTest.testMigrationWithoutFullBaselineIntoPartition https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-369187610128267810=%3Cdefault%3E=testDetails Changes may lead to failure were done by - aleksei scherbakov https://ci.ignite.apache.org/viewModification.html?modId=895725 - aleksei scherbakov https://ci.ignite.apache.org/viewModification.html?modId=895727 - ilya kasnacheev https://ci.ignite.apache.org/viewModification.html?modId=895710 - aleksey plekhanov https://ci.ignite.apache.org/viewModification.html?modId=895739 - anton kalashnikov https://ci.ignite.apache.org/viewModification.html?modId=895723 - alexey goncharuk https://ci.ignite.apache.org/viewModification.html?modId=895735 - anton kalashnikov https://ci.ignite.apache.org/viewModification.html?modId=895719 - alexey goncharuk https://ci.ignite.apache.org/viewModification.html?modId=895729 - 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 23:11:38 21-01-2020
Re: Thin client: compute support
Igor, thanks for the reply. > Approach with taskId will require a lot of changes in protocol and thus more "heavy" for implementation Do you mean approach with server notifications mechanism? Yes, it will require a lot of changes. But in most recent messages we've discussed with Pavel approach without server notifications mechanism. This approach have the same complexity and performance as an approach with requestId. > But such clients as Python, Node.js, PHP, Go most probably won't have support for this API, at least for now. Without a server notifications mechanism, there will be no breaking changes in the protocol, so client implementation can just skip this feature and protocol version and implement the next one. > Or never. I think it still useful to execute java compute tasks from non-java thin clients. Also, we can provide some out-of-the-box java tasks, for example ExecutePythonScriptTask with python compute implementation, which can run python script on server node. > So, maybe it's a good time for us to change our backward compatibility mechanism from protocol versioning to feature masks? I like the idea with feature masks, but it will force us to support both backward compatibility mechanisms, protocol versioning and feature masks. пн, 20 янв. 2020 г. в 20:34, Pavel Tupitsyn : > Huge +1 from me for Feature Masks. > I think this should be our top priority for thin client protocol, since it > simplifies change management a lot. > > On Mon, Jan 20, 2020 at 8:21 PM Igor Sapego wrote: > > > Sorry for the late reply. > > > > Approach with taskId will require a lot of changes in protocol and thus > > more "heavy" for implementation, but it definitely looks to me less hacky > > than reqId-approach. Moreover, as was mentioned, server notifications > > mechanism will be required in a future anyway with high probability. So > > from this point of view I like taskId-approach. > > > > On the other hand, what we should also consider here is performance. > > Speaking of latency, it looks like reqId will have better results in case > > of > > small and fast tasks. The only question here, if we want to optimize thin > > clients for this case. > > > > Also, what are you talking about mostly involves clients on platforms > > that already have Compute API for thick clients. Let me mention one > > more point of view here and another concern here. > > > > The changes you propose are going to change protocol version for sure. > > In case with taskId approach and server notifications - even more so. > > > > But such clients as Python, Node.js, PHP, Go most probably won't have > > support for this API, at least for now. Or never. But current > > backward-compatibility mechanism implies protocol versions where we > > imply that client that supports version 1.5 also supports all the > features > > introduced in all the previous versions of the protocol. > > > > Thus implementing Compute API in any of the proposed ways *may* > > force mentioned clients to support changes in protocol which they not > > necessarily need in order to introduce new features in the future. > > > > So, maybe it's a good time for us to change our backward compatibility > > mechanism from protocol versioning to feature masks? > > > > WDYT? > > > > Best Regards, > > Igor > > > > > > On Fri, Jan 17, 2020 at 9:37 AM Alex Plehanov > > wrote: > > > > > Looks like we didn't rich consensus here. > > > > > > Igor, as thin client maintainer, can you please share your opinion? > > > > > > Everyone else also welcome, please share your thoughts about options to > > > implement operations for compute. > > > > > > > > > чт, 28 нояб. 2019 г. в 10:02, Alex Plehanov : > > > > > > > > Since all thin client operations are inherently async, we should be > > > able > > > > to cancel any of them > > > > It's illogical to have such ability. What should do cancel operation > of > > > > cancel operation? Moreover, sometimes it's dangerous, for example, > > create > > > > cache operation should never be canceled. There should be an explicit > > set > > > > of processes that we can cancel: queries, transactions, tasks, > > services. > > > > The lifecycle of services is more complex than the lifecycle of > tasks. > > > With > > > > services, I suppose, we can't use request cancelation, so tasks will > be > > > the > > > > only process with an exceptional pattern. > > > > > > > > > The request would be "execute task with specified node filter" - > > simple > > > > and efficient. > > > > It's not simple: every compute or service request should contain > > complex > > > > node filtering logic, which duplicates the same logic for cluster > API. > > > > It's not efficient: for example, we can't implement forPredicate() > > > > filtering in this case. > > > > > > > > > > > > ср, 27 нояб. 2019 г. в 19:25, Pavel Tupitsyn : > > > > > > > >> > The request is already processed (task is started), we can't > cancel > > > the > > > >> request > > > >> The request is not "start a
Call for presentations for ApacheCon North America 2020 now open
Dear Apache enthusiast, (You’re receiving this message because you are subscribed to one or more project mailing lists at the Apache Software Foundation.) The call for presentations for ApacheCon North America 2020 is now open at https://apachecon.com/acna2020/cfp ApacheCon will be held at the Sheraton, New Orleans, September 28th through October 2nd, 2020. As in past years, ApacheCon will feature tracks focusing on the various technologies within the Apache ecosystem, and so the call for presentations will ask you to select one of those tracks, or “General” if the content falls outside of one of our already-organized tracks. These tracks are: Karaf Internet of Things Fineract Community Content Delivery Solr/Lucene (Search) Gobblin/Big Data Integration Ignite Observability Cloudstack Geospatial Graph Camel/Integration Flagon Tomcat Cassandra Groovy Web/httpd General/Other The CFP will close Friday, May 1, 2020 8:00 AM (America/New_York time). Submit early, submit often, at https://apachecon.com/acna2020/cfp Rich, for the ApacheCon Planners
Re: Internal classes are exposed in public API
Hello, Igniters. Alexey approved my PR [1] regarding fixing public API for metric exporters. I’m waiting for a bot visa and merge this PR. As we discussed, the metrics API will be marked with IgniteExperimental annotation. If anyone has any objection to this plan, please provide your feedback. [1] https://github.com/apache/ignite/pull/7269 > 21 янв. 2020 г., в 13:45, Николай Ижиков написал(а): > > Thanks, for the review Alexey. > > I will fix your comment and try to implement Monitoring facade, shortly. > >> 21 янв. 2020 г., в 13:32, Alexey Goncharuk >> написал(а): >> >> Nikolay, >> >> I left a single comment in the PR about the histogram metric. I think the >> API looks much cleaner now. >> >> I will take care of the @IgniteExperimental annotation. >> >> пн, 20 янв. 2020 г. в 20:55, Николай Ижиков : >> >>> Alexey. >>> >>> PR [1] is waiting for your review. >>> Please, take a look. >>> >>> I think we should do the following before 2.8 release >>> >>> * Introduce new @IgniteExperimental annotation as discussed. >>> * Mark Monitoring API with it. >>> * merge «[IEP-35] Expose MetricRegistry to the public API» to 2.8 >>> * merge «[IEP-35] public Java metric API» to 2.8 >>> >>> [1] https://github.com/apache/ignite/pull/7269 >>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk >>> написал(а): Nikolay, Should we wait for both of the tickets given that we agreed that we are putting an experimental marker on the new APIs? I'm ok to fix only the first one and add the experimental marker so that we do not delay 2.8 release. пн, 20 янв. 2020 г. в 13:32, Николай Ижиков : > Andrey. > > Let’s move from the long letters to the code. > If you want to change API - please, propose this changes. > I think everybody wins if we make our API better. > > Please, describe proposed changes. > It would be great if you have some examples or PR for it. > > As for this release, I have plans to contribute tickets > «[IEP-35] Expose MetricRegistry to the public API» [1] and > «[IEP-35] public Java metric API» [2] for it. > > Any objections on it? > > [1] https://github.com/apache/ignite/pull/7269 > [2] https://issues.apache.org/jira/browse/IGNITE-12553 > > >> 20 янв. 2020 г., в 13:08, Andrey Gura написал(а): >> >> It solves problem. >> >> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk >> wrote: >>> >>> After giving it some thought, I agree with Denis - there is nothing > wrong >>> with exposing the new APIs, we just need to make it clear that we are > still >>> going to change it. >>> >>> Should we Introduce something like @IgniteExperimental annotation (I >>> believe it has been discussed a dozen of times on the dev-list)? >>> >>> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov : >>> +1 to mark feature or whole release as EA. пт, 17 янв. 2020 г., 23:00 Denis Magda : > Folks, if you don't mind I'll share some thoughts/suggestions as an > observer who was not involved in the feature development. > > It's absolutely 'ok' to deprecate an API that is replaced with a >>> much > better version. However, we should do this only when the new APIs >>> are > production-ready. If there are still many limitations or open items > then > don't deprecate anything that exists and release the new APIs > labeling as > early access. What if release the improvements labeling as EA >>> instead > of > hiding them completely? > > I would also encourage us to put aside emotions, don't blame or >>> point > fingers. This IEP is a great initiative and you both have already > done a > tremendous job by developing, architecting and reviewing changes. > Just be > respectful. Nobody is trying to block the feature from being >>> released. > Everyone would be glad to tap into improvements and start using them > in > prod. But if more time is needed for the GA let's reiterate a bit. > > - > Denis > > > On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков < >>> nizhi...@apache.org> > wrote: > >>> Also I agree with Alexey about introducing public IgniteMonitoring > facade >> >> This is not an issue with the API. >> Just the new feature that doesn’t affects API. >> Moreover, I create a ticket to fix it, already. >> >>> It's right. But if you add checking of statisticsEnabling property then >> test will fail. It's just not good tests. >> >> My changes doesn’t affect any `staticticsEnabled` property. >> I don’ understand your point here. >> >>> Redundant
Re: [DISCUSS] ThreadGroup for IgniteThread
Ivan, I cannot recall why exactly a separate thread group was needed. I guess the intention was to collect all threads related to Ignite to one group, but I see no practical use of that particular implementation. We can either remove it (not sure if this is a breaking public API change?) or create a separate thread group per Ignite instance and pass it to the constructor of IgniteThread (quite a lot of refactoring). вт, 21 янв. 2020 г. в 13:17, Ivan Pavlukhin : > Hi, > > As you might know, IgniteThread class captures calling ThreadGroup on > initialization (as IgniteThread.DFLT_GRP) and includes all new ignite > threads into this group. A user reported an issue [1] related to it. > And the root cause here is that captured DFLT_GRP is out of control of > IgniteThread class. Looks like a design fault. Consequently several > unclear points: > 1. What is the real need for IgniteThread.DFLT_GRP? > 2. Can we simply stop using this trick? > 3. Could there be any better options to do the same? > > Please share your thoughts. > > [1] https://issues.apache.org/jira/browse/IGNITE-12554 > > -- > Best regards, > Ivan Pavlukhin >
Re: Master compilation error
That's what I was using, it did not compile ignite-compatibility for me. Thanks for Petr, the following command worked: mvn clean package -U -Pall-java,all-scala,scala,licenses,lgpl,examples,tensorflow,checkstyle -DskipTests -Dmaven.javadoc.skip=true пн, 20 янв. 2020 г. в 18:59, Ilya Kasnacheev : > Hello! > > I do the following: > > mvn clean install -DskipTests -Dmaven.javadoc.skip=true > -Dmaven.scaladoc.skip=true -Plgpl > > Maybe -Pall-java is needed actually, though, it will not check C++ and .Net > anyway :-/ > > Regards, > -- > Ilya Kasnacheev > > > пн, 20 янв. 2020 г. в 16:35, Alexey Goncharuk >: > > > Ok, now I'm confused: what is a kosher command to check the build > locally? > > > > пн, 20 янв. 2020 г. в 15:38, Alexey Goncharuk < > alexey.goncha...@gmail.com > > >: > > > > > Master is fixed. > > > > > > пн, 20 янв. 2020 г. в 15:08, Alexey Goncharuk < > > alexey.goncha...@gmail.com > > > >: > > > > > >> Will fix the compilation shortly, apologies for not checking locally. > > >> > > >> An additional compilation attempt is a good idea, but: first, I > believe, > > >> there is still an option to merge a PR directly to apache git, second > - > > >> when running a check, we need to make sure that master gets > > fast-forwarded > > >> exactly to the revision that was checked (though, it will help to > avoid > > a > > >> lot of concurrent merge failures). I have no enough experience with > > Github, > > >> so I am not sure if this is possible. > > >> > > >> пн, 20 янв. 2020 г. в 14:40, Anton Vinogradov : > > >> > > >>> Also, is it possible to perform the same check on the merge attempt? > > >>> > > >>> Each PR can be merged from GitHub page, can we append check to the > > "megre > > >>> button" flow? > > >>> Can we restrict merges bypassing this button? > > >>> > > >>> On Mon, Jan 20, 2020 at 2:17 PM Anton Vinogradov > > wrote: > > >>> > > >>> > Should we perform an additional compilation attempt on > pull/xxx/merge > > >>> at > > >>> > each visa request? > > >>> > > > >>> > On Mon, Jan 20, 2020 at 1:56 PM Pavel Tupitsyn < > ptupit...@apache.org > > > > > >>> > wrote: > > >>> > > > >>> >> > Main question is "how this may happen in case fix got the Visa > [2] > > >>> ?". > > >>> >> This can happen because of other changes in master. > > >>> >> "Visa" truly works only when master is in the same state during > the > > >>> merge > > >>> >> as it was during TC run. > > >>> >> > > >>> >> On Mon, Jan 20, 2020 at 1:50 PM Anton Vinogradov > > >>> wrote: > > >>> >> > > >>> >> > It seems, this because of IGNITE-12227 fix [1]. > > >>> >> > Main question is "how this may happen in case fix got the Visa > [2] > > >>> ?". > > >>> >> > > > >>> >> > [1] > > >>> >> > > > >>> >> > > > >>> >> > > >>> > > > https://ci.ignite.apache.org/viewModification.html?modId=895719=false=IgniteTests24Java8_BuildApacheIgnite=vcsModificationFiles > > >>> >> > [2] > > >>> >> > > > >>> >> > > > >>> >> > > >>> > > > https://issues.apache.org/jira/browse/IGNITE-12227?focusedCommentId=17018135=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17018135 > > >>> >> > > > >>> >> > On Mon, Jan 20, 2020 at 1:43 PM Николай Ижиков < > > nizhi...@apache.org > > >>> > > > >>> >> > wrote: > > >>> >> > > > >>> >> > > Hello. Igniters. > > >>> >> > > > > >>> >> > > Master build fails: > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > >>> >> > > >>> > > > https://ci.ignite.apache.org/viewLog.html?buildId=4944107=IgniteTests24Java8_BuildApacheIgnite=buildLog_IgniteTests24Java8=pull%2F7269%2Fhead > > >>> >> > > > > >>> >> > > [13:37:02][Step 3/4] [ERROR] Failed to execute goal > > >>> >> > > org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile > > >>> >> > > (default-testCompile) on project ignite-core: Compilation > > failure: > > >>> >> > > Compilation failure: > > >>> >> > > [13:37:02][Step 3/4] [ERROR] > > >>> >> > > > > >>> >> > > > >>> >> > > >>> > > > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[25,1] > > >>> >> > > cannot find symbol > > >>> >> > > [13:37:02][Step 3/4] [ERROR] symbol: static > > >>> >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > > >>> >> > > [13:37:02][Step 3/4] [ERROR] location: class > > >>> >> > > [13:37:02][Step 3/4] [ERROR] > > >>> >> > > > > >>> >> > > > >>> >> > > >>> > > > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateAbstractTest.java:[162,28] > > >>> >> > > cannot find symbol > > >>> >> > > [13:37:02][Step 3/4] [ERROR] symbol: variable > > >>> >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > > >>> >> > > [13:37:02][Step 3/4] [ERROR] location: class > > >>> >> > > > > >>> >> > > > >>> >> > > >>> > > > org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateAbstractTest > > >>> >> > > [13:37:02][Step 3/4] [ERROR]
Re: Request for review: @IgniteExperimental
Pavel, Igor, Can you add similar annotations/attributes to platforms? вт, 21 янв. 2020 г. в 16:01, Alexey Goncharuk : > Igniters, > > As discussed in the thread [1], we want to add an annotation marking an > API or feature experimental. The corresponding ticket and PR are [2],[3]. > > Please take a look at the description and suggest any edits to the javadoc > if necessary. > > A side question - Anton Vinogradov asked me to mark the read-repair > feature as experimental in this PR. Should I also mark the IEP-35 > interfaces there as well or should we move that change to a separate ticket? > > [1] > http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-td45146.html > [2] https://issues.apache.org/jira/browse/IGNITE-12559 > [3] https://github.com/apache/ignite/pull/7279 >
Request for review: @IgniteExperimental
Igniters, As discussed in the thread [1], we want to add an annotation marking an API or feature experimental. The corresponding ticket and PR are [2],[3]. Please take a look at the description and suggest any edits to the javadoc if necessary. A side question - Anton Vinogradov asked me to mark the read-repair feature as experimental in this PR. Should I also mark the IEP-35 interfaces there as well or should we move that change to a separate ticket? [1] http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-td45146.html [2] https://issues.apache.org/jira/browse/IGNITE-12559 [3] https://github.com/apache/ignite/pull/7279
[jira] [Created] (IGNITE-12559) Introduce @IgniteExperimental API annotation
Alexey Goncharuk created IGNITE-12559: - Summary: Introduce @IgniteExperimental API annotation Key: IGNITE-12559 URL: https://issues.apache.org/jira/browse/IGNITE-12559 Project: Ignite Issue Type: Improvement Affects Versions: 2.8 Reporter: Alexey Goncharuk Assignee: Alexey Goncharuk Fix For: 2.8 This is a follow-up for the discussion on the dev-list: http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-td45146.html The annotation will mark new APIs which are not yet finalized, but the underlying functionality is ready to be tried by users. The annotation will provide a good way to collect user feedback and correct wrong design choices without a need to preserve binary and source compatibility. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Folks, I think both of these issues [1] [2] are critical to 2.8 release and we must include them. [1] https://issues.apache.org/jira/browse/IGNITE-12547 Excessive AtomicLong instantiations lead to GC pressure. [2] https://issues.apache.org/jira/browse/IGNITE-12530 Pages list caching can cause IgniteOOME when the checkpoint is triggered by "too many dirty pages" reason. On Mon, 20 Jan 2020 at 19:00, Alex Plehanov wrote: > > Guys, > > There is an issue [1] caused by page list caching [2], which also affects > 2.8 release. IgniteOutOfMemoryException can be thrown in some cases (data > region is small, a checkpoint is triggered by "too many dirty pages" reason > and pages list cache is rather big). > The fix is ready and merged to master, I suggest to include this fix to 2.8 > release. What do you think? > > [1]: https://issues.apache.org/jira/browse/IGNITE-12530 > [2]: https://issues.apache.org/jira/browse/IGNITE-6930 > > пн, 20 янв. 2020 г. в 12:57, Alexey Goncharuk : > > > Maxim, > > > > I took a quick look at IGNITE-12456 and I am not sure it's about data > > corruption. In the attached logs blocked system threads are reported, > > however, there is no enough information to investigate the issue (the full > > thread dump was not attached). I asked the ticket creator to attach missing > > pieces. > > > > Should we consider moving this ticket to a next release? > > > > пн, 20 янв. 2020 г. в 08:54, Zhenya Stanilovsky > >: > > > > > > > > Maxim, performance fix issue [1] already in master, if no objections, can > > > u merge it into 2.8 ? Thanks ! > > > [1] https://issues.apache.org/jira/browse/IGNITE-12547 > > > > > > >Igniters, > > > > > > > > > > > >Here is the actual list of BLOCKER release issues: > > > > > > > >IGNITE-12456 Cluster Data Store grid gets Corrupted for Load test > > > >*[Unassigned]* OPEN > > > >IGNITE-12489 Error during purges by expiration: Unknown page type* > > > >[Unassigned]* OPEN > > > >IGNITE-8641 SpringDataExample should use example-ignite.xml config > > > >*[Unassigned]* OPEN > > > > > > > >IGNITE-12398 Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes > > > getting > > > >down [Emmanouil Gkatziouras] OPEN > > > >IGNITE-9184 Cluster hangs during concurrent node client and server nodes > > > >restart [Dmitriy Sorokin] IN PROGRESS > > > >IGNITE-12553 [IEP-35] public Java metric API Improvement [Nikolay > > Izhikov] > > > >Blocker IN PROGRESS > > > > > > > >IGNITE-12227 Default auto-adjust baseline enabled flag calculated > > > >incorrectly [Anton Kalashnikov] PATCH AVAILABLE > > > >IGNITE-12470 Pme-free switch feature should be deactivatable [Sergei > > > >Ryzhov] PATCH AVAILABLE > > > >IGNITE-12552 [IEP-35] Expose MetricRegistry to the public API > > Improvement > > > >[Nikolay Izhikov] PATCH AVAILABLE > > > > > > > > > > > >[1] https://issues.apache.org/jira/browse/IGNITE-12456 > > > >[2] https://issues.apache.org/jira/browse/IGNITE-12489 > > > >[3] https://issues.apache.org/jira/browse/IGNITE-8641 > > > >[8] https://issues.apache.org/jira/browse/IGNITE-12398 > > > >[3] https://issues.apache.org/jira/browse/IGNITE-9184 > > > >[6] https://issues.apache.org/jira/browse/IGNITE-12553 > > > >[7] https://issues.apache.org/jira/browse/IGNITE-12227 > > > >[9] https://issues.apache.org/jira/browse/IGNITE-12470 > > > >[5] https://issues.apache.org/jira/browse/IGNITE-12552 > > > > > > > > > > > >On Sat, 18 Jan 2020 at 19:11, Sergey Antonov < > > antonovserge...@gmail.com > > > > > > > >wrote: > > > > > > > >> Maxim, > > > >> > > > >> Conflicts in pr [1] are resolved. TC Run all is started. > > > >> > > > >> [1] https://github.com/apache/ignite/pull/7238 > > > >> > > > >> пт, 17 янв. 2020 г. в 16:04, Sergey Antonov < > > antonovserge...@gmail.com > > > >: > > > >> > > > >>> Maxim, > > > >>> > > > >>> I will do that on monday (20/01). > > > >>> > > > >>> пт, 17 янв. 2020 г. в 13:08, Maxim Muzafarov < mmu...@apache.org >: > > > >>> > > > Sergey, > > > > > > > > > Can you, please, resolve the PR conflicts [1] [2]? > > > > > > [1] https://github.com/apache/ignite/pull/7238 > > > [2] https://issues.apache.org/jira/browse/IGNITE-11256 > > > > > > On Thu, 16 Jan 2020 at 16:59, Ilya Kasnacheev < > > > ilya.kasnach...@gmail.com > > > > wrote: > > > > > > > > Hello! > > > > > > > > I have bumped beanutils and re-ran Cassandra Store tests. Can you > > > please > > > > comment on the ticket? > > > > > > > > I think that fixing ZooKeeper is too much effort (there's chaos > > with > > > > jackson vs. jackson-asl), maybe it should be split up as a > > separate > > > ticket > > > > to be done later. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > ср, 15 янв. 2020 г. в 18:31, Vladimir Pligin < > > vova199...@yandex.ru > > > >: > > > > > > > > > Thanks, Ilya. It would be really great to have your patch
Re: Internal classes are exposed in public API
Thanks, for the review Alexey. I will fix your comment and try to implement Monitoring facade, shortly. > 21 янв. 2020 г., в 13:32, Alexey Goncharuk > написал(а): > > Nikolay, > > I left a single comment in the PR about the histogram metric. I think the > API looks much cleaner now. > > I will take care of the @IgniteExperimental annotation. > > пн, 20 янв. 2020 г. в 20:55, Николай Ижиков : > >> Alexey. >> >> PR [1] is waiting for your review. >> Please, take a look. >> >> I think we should do the following before 2.8 release >> >> * Introduce new @IgniteExperimental annotation as discussed. >> * Mark Monitoring API with it. >> * merge «[IEP-35] Expose MetricRegistry to the public API» to 2.8 >> * merge «[IEP-35] public Java metric API» to 2.8 >> >> [1] https://github.com/apache/ignite/pull/7269 >> >>> 20 янв. 2020 г., в 17:09, Alexey Goncharuk >> написал(а): >>> >>> Nikolay, >>> >>> Should we wait for both of the tickets given that we agreed that we are >>> putting an experimental marker on the new APIs? I'm ok to fix only the >>> first one and add the experimental marker so that we do not delay 2.8 >>> release. >>> >>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков : >>> Andrey. Let’s move from the long letters to the code. If you want to change API - please, propose this changes. I think everybody wins if we make our API better. Please, describe proposed changes. It would be great if you have some examples or PR for it. As for this release, I have plans to contribute tickets «[IEP-35] Expose MetricRegistry to the public API» [1] and «[IEP-35] public Java metric API» [2] for it. Any objections on it? [1] https://github.com/apache/ignite/pull/7269 [2] https://issues.apache.org/jira/browse/IGNITE-12553 > 20 янв. 2020 г., в 13:08, Andrey Gura написал(а): > > It solves problem. > > On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk > wrote: >> >> After giving it some thought, I agree with Denis - there is nothing wrong >> with exposing the new APIs, we just need to make it clear that we are still >> going to change it. >> >> Should we Introduce something like @IgniteExperimental annotation (I >> believe it has been discussed a dozen of times on the dev-list)? >> >> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov : >> >>> +1 to mark feature or whole release as EA. >>> >>> пт, 17 янв. 2020 г., 23:00 Denis Magda : >>> Folks, if you don't mind I'll share some thoughts/suggestions as an observer who was not involved in the feature development. It's absolutely 'ok' to deprecate an API that is replaced with a >> much better version. However, we should do this only when the new APIs >> are production-ready. If there are still many limitations or open items then don't deprecate anything that exists and release the new APIs labeling as early access. What if release the improvements labeling as EA >> instead of hiding them completely? I would also encourage us to put aside emotions, don't blame or >> point fingers. This IEP is a great initiative and you both have already done a tremendous job by developing, architecting and reviewing changes. Just be respectful. Nobody is trying to block the feature from being >> released. Everyone would be glad to tap into improvements and start using them in prod. But if more time is needed for the GA let's reiterate a bit. - Denis On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков < >> nizhi...@apache.org> wrote: >> Also I agree with Alexey about introducing public IgniteMonitoring facade > > This is not an issue with the API. > Just the new feature that doesn’t affects API. > Moreover, I create a ticket to fix it, already. > >> It's right. But if you add checking of statisticsEnabling property >>> then > test will fail. It's just not good tests. > > My changes doesn’t affect any `staticticsEnabled` property. > I don’ understand your point here. > >> Redundant ReadOnlyMetricRegistry. > > It’s not redundant. > It required for exporters and provide read only access to >>> MetricRegistry > existing in the node. > > >> MetricExporterSpi that requires ReadOnlyMetricRegistry. > >> Absence of newly created metrics in old MBeans that forces user >> use >> exporter SPI while his code base uses old MBeans. > > Why this is issue? > >> Inconsistent MetricRegistry API. > > It’s
Re: Internal classes are exposed in public API
Nikolay, I left a single comment in the PR about the histogram metric. I think the API looks much cleaner now. I will take care of the @IgniteExperimental annotation. пн, 20 янв. 2020 г. в 20:55, Николай Ижиков : > Alexey. > > PR [1] is waiting for your review. > Please, take a look. > > I think we should do the following before 2.8 release > > * Introduce new @IgniteExperimental annotation as discussed. > * Mark Monitoring API with it. > * merge «[IEP-35] Expose MetricRegistry to the public API» to 2.8 > * merge «[IEP-35] public Java metric API» to 2.8 > > [1] https://github.com/apache/ignite/pull/7269 > > > 20 янв. 2020 г., в 17:09, Alexey Goncharuk > написал(а): > > > > Nikolay, > > > > Should we wait for both of the tickets given that we agreed that we are > > putting an experimental marker on the new APIs? I'm ok to fix only the > > first one and add the experimental marker so that we do not delay 2.8 > > release. > > > > пн, 20 янв. 2020 г. в 13:32, Николай Ижиков : > > > >> Andrey. > >> > >> Let’s move from the long letters to the code. > >> If you want to change API - please, propose this changes. > >> I think everybody wins if we make our API better. > >> > >> Please, describe proposed changes. > >> It would be great if you have some examples or PR for it. > >> > >> As for this release, I have plans to contribute tickets > >> «[IEP-35] Expose MetricRegistry to the public API» [1] and > >> «[IEP-35] public Java metric API» [2] for it. > >> > >> Any objections on it? > >> > >> [1] https://github.com/apache/ignite/pull/7269 > >> [2] https://issues.apache.org/jira/browse/IGNITE-12553 > >> > >> > >>> 20 янв. 2020 г., в 13:08, Andrey Gura написал(а): > >>> > >>> It solves problem. > >>> > >>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk > >>> wrote: > > After giving it some thought, I agree with Denis - there is nothing > >> wrong > with exposing the new APIs, we just need to make it clear that we are > >> still > going to change it. > > Should we Introduce something like @IgniteExperimental annotation (I > believe it has been discussed a dozen of times on the dev-list)? > > пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov : > > > +1 to mark feature or whole release as EA. > > > > пт, 17 янв. 2020 г., 23:00 Denis Magda : > > > >> Folks, if you don't mind I'll share some thoughts/suggestions as an > >> observer who was not involved in the feature development. > >> > >> It's absolutely 'ok' to deprecate an API that is replaced with a > much > >> better version. However, we should do this only when the new APIs > are > >> production-ready. If there are still many limitations or open items > >> then > >> don't deprecate anything that exists and release the new APIs > >> labeling as > >> early access. What if release the improvements labeling as EA > instead > >> of > >> hiding them completely? > >> > >> I would also encourage us to put aside emotions, don't blame or > point > >> fingers. This IEP is a great initiative and you both have already > >> done a > >> tremendous job by developing, architecting and reviewing changes. > >> Just be > >> respectful. Nobody is trying to block the feature from being > released. > >> Everyone would be glad to tap into improvements and start using them > >> in > >> prod. But if more time is needed for the GA let's reiterate a bit. > >> > >> - > >> Denis > >> > >> > >> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков < > nizhi...@apache.org> > >> wrote: > >> > Also I agree with Alexey about introducing public IgniteMonitoring > >> facade > >>> > >>> This is not an issue with the API. > >>> Just the new feature that doesn’t affects API. > >>> Moreover, I create a ticket to fix it, already. > >>> > It's right. But if you add checking of statisticsEnabling property > > then > >>> test will fail. It's just not good tests. > >>> > >>> My changes doesn’t affect any `staticticsEnabled` property. > >>> I don’ understand your point here. > >>> > Redundant ReadOnlyMetricRegistry. > >>> > >>> It’s not redundant. > >>> It required for exporters and provide read only access to > > MetricRegistry > >>> existing in the node. > >>> > >>> > MetricExporterSpi that requires ReadOnlyMetricRegistry. > >>> > Absence of newly created metrics in old MBeans that forces user > use > exporter SPI while his code base uses old MBeans. > >>> > >>> Why this is issue? > >>> > Inconsistent MetricRegistry API. > >>> > >>> It’s consistent. > >>> > Metrics lookups from map instead of using direct reference > (performance problem). > >>> > >>> 1. We(You and I) did this choice together to simplify creation of > the > > new > >>> metrics. > >>>
[DISCUSS] ThreadGroup for IgniteThread
Hi, As you might know, IgniteThread class captures calling ThreadGroup on initialization (as IgniteThread.DFLT_GRP) and includes all new ignite threads into this group. A user reported an issue [1] related to it. And the root cause here is that captured DFLT_GRP is out of control of IgniteThread class. Looks like a design fault. Consequently several unclear points: 1. What is the real need for IgniteThread.DFLT_GRP? 2. Can we simply stop using this trick? 3. Could there be any better options to do the same? Please share your thoughts. [1] https://issues.apache.org/jira/browse/IGNITE-12554 -- Best regards, Ivan Pavlukhin
[jira] [Created] (IGNITE-12558) Add UTC timestamp to local node metrics
Ilya Kasnacheev created IGNITE-12558: Summary: Add UTC timestamp to local node metrics Key: IGNITE-12558 URL: https://issues.apache.org/jira/browse/IGNITE-12558 Project: Ignite Issue Type: Improvement Components: general Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev Let's also add current UTC timestamp to "Metrics for local node" message. We often see logs posted where there is no date or the time zone is unknown, making it hard to correlate logs from different nodes. Time to fix that. We should also consider any other minor improvements to this block. Maybe tone down "to disable" message a bit to make up free space? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12557) Destroy of big cache which is not only cache in cache group couses IgniteOOME
Aleksey Plekhanov created IGNITE-12557:
--
Summary: Destroy of big cache which is not only cache in cache
group couses IgniteOOME
Key: IGNITE-12557
URL: https://issues.apache.org/jira/browse/IGNITE-12557
Project: Ignite
Issue Type: Bug
Components: persistence
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
When {{destroyCache()}} is invoked {{checkpointReadLock}} is held by exchange
thread during all time cache entries is cleaning. Meanwhile,
{{db-checkpoint-thread}} can't acquire checkpoint write lock and can't start
checkpoint. After some time all page-memory has filled with dirty pages and
attempt to acquire a new page causes IgniteOOM exception:
{noformat}
class org.apache.ignite.internal.mem.IgniteOutOfMemoryException: Failed to find
a page for eviction [segmentCapacity=40485, loaded=15881, maxDirtyPages=11910,
dirtyPages=15881, cpPages=0, pinnedInSegment=0, failedToPrepare=15881]
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$Segment.tryToFindSequentially(PageMemoryImpl.java:2420)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$Segment.removePageForReplacement(PageMemoryImpl.java:2314)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:743)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:679)
at
org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:158)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.acquirePage(BPlusTree.java:5872)
at
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compareKeys(CacheDataTree.java:435)
at
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compare(CacheDataTree.java:384)
at
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compare(CacheDataTree.java:63)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.compare(BPlusTree.java:5214)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findInsertionPoint(BPlusTree.java:5134)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(BPlusTree.java:298)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5723)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run(BPlusTree.java:278)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5709)
at
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(PageHandler.java:169)
at
org.apache.ignite.internal.processors.cache.persistence.DataStructure.read(DataStructure.java:364)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.read(BPlusTree.java:5910)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removeDown(BPlusTree.java:2077)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:2007)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1838)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.clear(IgniteCacheOffheapManagerImpl.java:2963)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.clear(GridCacheOffheapManager.java:2611)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.removeCacheData(IgniteCacheOffheapManagerImpl.java:296)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.stopCache(IgniteCacheOffheapManagerImpl.java:258)
at
org.apache.ignite.internal.processors.cache.CacheGroupContext.stopCache(CacheGroupContext.java:825)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1070)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2617)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2596)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$processCacheStopRequestOnExchangeDone$629e8679$1(GridCacheProcessor.java:2796)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11173)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11075)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCacheStopRequestOnExchangeDone(GridCacheProcessor.java:2761)
at
