Re: Call for presentations for ApacheCon North America 2020 now open
Congrats, Saikat! I received a similar message that my talk (In-memory computing essentials for software engineers) was accepted as well. So, at least two talks by the Ignite folks. Once you share the time your presentation is scheduled for, I'll go ahead and update on the events' page on the website. https://ignite.apache.org/events.html - Denis On Tue, Aug 4, 2020 at 6:40 PM Saikat Maitra wrote: > Hi, > > I learned that my proposal for talk about Data Streaming using Apache > Ignite > and Apache Flink has been accepted. > > I have not yet received the schedule yet. I will share as soon as I have > it. > > Regards, > Saikat > > On Wed, Jan 22, 2020 at 8:09 PM Saikat Maitra > wrote: > > > Hi Denis, > > > > Thank you for your email. I have submitted a talk about Data Streaming > > using Apache Ignite and Apache Flink. > > > > I would also like to co-present on Ignite internals and usecases deep > dive. > > > > Regards, > > Saikat > > > > On Wed, Jan 22, 2020 at 6:22 PM Denis Magda wrote: > > > >> Igniters, > >> > >> I was submitting an Ignite talk to the conference and found out that > this > >> time ASF created a separate category for Ignite-specific proposals. You > can > >> see an abstract submitted by me: > >> > https://drive.google.com/file/d/1woaEOWaIFxN8UIJ7nvFbYoc53mYsUsSN/view?usp=sharing > >> > >> Who else is ready to submit? It can be a deep-dive about Ignite > internals > >> or Ignite use case overview. We can co-present. Also, GridGain is ready > to > >> sponsor your trip if the talk is accepted. > >> > >> > >> > >> - > >> Denis > >> > >> > >> On Tue, Jan 21, 2020 at 5:22 PM Denis Magda wrote: > >> > >>> 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 > >>> > >> >
Re: Call for presentations for ApacheCon North America 2020 now open
Hello Prasad, Yes sure, I will share the slides. Regards, Saikat On Tue, Aug 4, 2020 at 9:35 PM Prasad Bhalerao wrote: > Hi Saikat, > Can you please share the slides for both presentations, streaming as well > as ignite internals? > Thanks, > Prasad > > On Wed 5 Aug, 2020, 7:10 AM Saikat Maitra >> Hi, >> >> I learned that my proposal for talk about Data Streaming using Apache Ignite >> and Apache Flink has been accepted. >> >> I have not yet received the schedule yet. I will share as soon as I have >> it. >> >> Regards, >> Saikat >> >> On Wed, Jan 22, 2020 at 8:09 PM Saikat Maitra >> wrote: >> >>> Hi Denis, >>> >>> Thank you for your email. I have submitted a talk about Data Streaming >>> using Apache Ignite and Apache Flink. >>> >>> I would also like to co-present on Ignite internals and usecases deep >>> dive. >>> >>> Regards, >>> Saikat >>> >>> On Wed, Jan 22, 2020 at 6:22 PM Denis Magda wrote: >>> Igniters, I was submitting an Ignite talk to the conference and found out that this time ASF created a separate category for Ignite-specific proposals. You can see an abstract submitted by me: https://drive.google.com/file/d/1woaEOWaIFxN8UIJ7nvFbYoc53mYsUsSN/view?usp=sharing Who else is ready to submit? It can be a deep-dive about Ignite internals or Ignite use case overview. We can co-present. Also, GridGain is ready to sponsor your trip if the talk is accepted. - Denis On Tue, Jan 21, 2020 at 5:22 PM Denis Magda wrote: > 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 >
Re: Call for presentations for ApacheCon North America 2020 now open
Hi Saikat, Can you please share the slides for both presentations, streaming as well as ignite internals? Thanks, Prasad On Wed 5 Aug, 2020, 7:10 AM Saikat Maitra Hi, > > I learned that my proposal for talk about Data Streaming using Apache Ignite > and Apache Flink has been accepted. > > I have not yet received the schedule yet. I will share as soon as I have > it. > > Regards, > Saikat > > On Wed, Jan 22, 2020 at 8:09 PM Saikat Maitra > wrote: > >> Hi Denis, >> >> Thank you for your email. I have submitted a talk about Data Streaming >> using Apache Ignite and Apache Flink. >> >> I would also like to co-present on Ignite internals and usecases deep >> dive. >> >> Regards, >> Saikat >> >> On Wed, Jan 22, 2020 at 6:22 PM Denis Magda wrote: >> >>> Igniters, >>> >>> I was submitting an Ignite talk to the conference and found out that >>> this time ASF created a separate category for Ignite-specific proposals. >>> You can see an abstract submitted by me: >>> https://drive.google.com/file/d/1woaEOWaIFxN8UIJ7nvFbYoc53mYsUsSN/view?usp=sharing >>> >>> Who else is ready to submit? It can be a deep-dive about Ignite >>> internals or Ignite use case overview. We can co-present. Also, GridGain is >>> ready to sponsor your trip if the talk is accepted. >>> >>> >>> >>> - >>> Denis >>> >>> >>> On Tue, Jan 21, 2020 at 5:22 PM Denis Magda wrote: >>> 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 >>>
Re: Call for presentations for ApacheCon North America 2020 now open
Hi, I learned that my proposal for talk about Data Streaming using Apache Ignite and Apache Flink has been accepted. I have not yet received the schedule yet. I will share as soon as I have it. Regards, Saikat On Wed, Jan 22, 2020 at 8:09 PM Saikat Maitra wrote: > Hi Denis, > > Thank you for your email. I have submitted a talk about Data Streaming > using Apache Ignite and Apache Flink. > > I would also like to co-present on Ignite internals and usecases deep dive. > > Regards, > Saikat > > On Wed, Jan 22, 2020 at 6:22 PM Denis Magda wrote: > >> Igniters, >> >> I was submitting an Ignite talk to the conference and found out that this >> time ASF created a separate category for Ignite-specific proposals. You can >> see an abstract submitted by me: >> https://drive.google.com/file/d/1woaEOWaIFxN8UIJ7nvFbYoc53mYsUsSN/view?usp=sharing >> >> Who else is ready to submit? It can be a deep-dive about Ignite internals >> or Ignite use case overview. We can co-present. Also, GridGain is ready to >> sponsor your trip if the talk is accepted. >> >> >> >> - >> Denis >> >> >> On Tue, Jan 21, 2020 at 5:22 PM Denis Magda wrote: >> >>> 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 >>> >>
Re: [DISCUSSION] Cache warmup
Kirill,
Thanks for driving this. This is awaited by many users.
A few comments and questions.
I would keep CacheWarmup interface purely internal and never view it as an
interface which a user would be implementing.
There are multiple reasons for that:
- The logic of the cache warmup is very low-level; how a user is supposed to
know which pages they want?
- A sophisticated strategy will require accessing private APIs for sure; say, I
need a strategy which loads the last known memory state before the restart; how
can I even implement that without breaking into various internals?
- In fact there aren't many implementations which make sense ("load
everything", "load indexes", "load last memory state", "load N GB at random");
every use case I've seen would be solved by a "load everything" strategy (if
disk is < RAM) or "load last memory state" strategy
- Warmup will be a critical phase, and a custom user implementation is all too
likely to cause issues. We should avoid executing user code in critical stages
if we can help it
To summarize, if we give warmup strategies in users' hands they will be hard to
write, will require breaking into internals or a lot of additional public
interfaces for these internals, will likely cause issues with the cluster, and
everyone will be implementing the same few general strategies.
Basically, I expect only fellow Ignite developers to be implementing their own
strategies.
Because of that I propose to keep the interfaces private, and only give a
single public parameter. The parameter can take an enum of the supported
strategies. New useful strategies should be added to Ignite codebase.
Will there be a way to interrupt warmup phase and continue startup (e.g. via
JMX, REST and/or control.sh)? Can we have it please?
I think that ideally warmup should be configured per-cache - I believe this is
what a user would expect to do.
However, cache configs are immutable. We need a way for existing users to enjoy
the cache warmup feature, as well as for early adopters to switch to more
sophisticated strategies as they will be released (or as their dataset grows).
Because of that I propose to add the cache warmup configuration to the
DataRegionConfiguration. Data regions can be changed between restarts,
independently on each node allowing for a rolling change.
Will preloadPartition() method be deprecated together with this change? I
assume yes?
How hard would it be to implement a "load all indexes, metapages and freelists"
strategy in addition to the "load everything"?
I think it would be an MVP for environments with a datasets larger than RAM. A
"load everything" strategy will not work in this environments pretty much at
all, and "load indexes" will be a significant improvement to no warmup at all.
Thanks,
Stan
> On 4 Aug 2020, at 16:04, ткаленко кирилл wrote:
>
> Hi, Denis!
>
> For now, I suggest a simple warm-up implementation, if the persistent storage
> is less than RAM. If others want to make additional implementations, they can
> do it themselves by implementing interfaces. For the first point, we need to
> figure out how and where we will remember pages, etc. Perhaps for such tasks
> it will be necessary to make improvements in kernel.
>
> In "WarmUpStrategy#warmUp" method, we get "GridKernalContext#cache" from
> which we can get with caches and groups through
> "GridCacheProcessor#cacheGroups", "GridCacheProcessor#caches" and so on, we
> can access to pages.
>> The second one requires direct work with data pages, but not with a cache
>> context, so it's also impossible to implement.
>
> This requires writing additional custom code, which may run longer due to its
> SQL features, and so on.
> It would be more convenient to just set a warm-up strategy for both developer
> and grid administrator.
>> When loading of all cache data is required, it can be done by running a
>> local scan query. It will iterate through all data pages and result in
>> their allocation in memory.
>
> 04.08.2020, 15:25, "Denis Mekhanikov" :
>> Kirill,
>>
>> When I discussed this functionality with Ignite users, I heard the
>> following thoughts about warming up:
>>
>>- Node restarts affect performance of queries. The main reason for that
>>is that the pages that were loaded into memory before the restart are on
>>disk after the restart. It takes time to reach the same distribution of
>>data between memory and disk. Until that point the performance is usually
>>degraded. No simple rule like "load everything" helps here if only a part
>>of data fits in memory.
>>- It would be nice to have a way to give preferences to indices when
>>doing a warmup. Usually indices are used more often than data nodes, so
>>loading indices first would bring more benefits.
>>
>> The first point can be addressed by implementing the policy that would
>> restore the memory state that was observed before the restart. I don't see
>> how it can be
Re: Moving Ignite documentation to github
Hi Alex, Certainly, the new documentation should not be treated as a showstopper, and if the code is ready much earlier, then we can release the docs on readme.io. But, it's not clear what's the documentation readiness status. As per our updated release process, the docs need to be ready before the voting is started [1]. That change was discussed and introduced after our lessons-learned conversations related to the 2.8 release. Could you please help to figure out the status by preparing a list of documentation tasks that must be completed before the voting time (all significant features and changes)? The "most important tasks" section [2] already lists most of them, but the list might be incomplete. For example, the tracing feature should be added in 2.9, but it's not in the important tasks list. There might be something else profound that we should put on paper. Once we get the list, we can start working with the contributors in charge to get things done. If some documentation pages won't be finished in 2 weeks from now, then it's reasonable to contribute the 2.9 docs to the new docs repository that will be ready for the release in 3-4 weeks. Just my thinking. [1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-4.1EnsureDocumentationReadinessandAccouncementBlogPostActivity [2] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.9#ApacheIgnite2.9-Themostimportantreleasetasks - Denis On Tue, Aug 4, 2020 at 5:54 AM Alex Plehanov wrote: > Denis, > > We have some performance drop on benchmarks, so we need some time to find > problematic commit and analyze it. I hope this will be completed during the > current week and we move to the "Vote preparation" phase to the start of > next week. > I think waiting for another month due to documentation it's too much. > Do we have an option to release with documentation on readme.io and then > move documentation in the new format during next month? > > > > пн, 3 авг. 2020 г. в 17:55, Denis Magda : > > > I would wait for 3-4 weeks and release the new docs in 2.9. It means that > > the release should be announced the first week of September which is not > a > > huge slip. Moreover, it feels like the testing phase and release > procedures > > will not be completed sooner. > > > > So, I would suggest contributing 2.9 related page to the new > documentation > > repository. > > > > > > Denis > > > > On Monday, August 3, 2020, Artem Budnikov > > wrote: > > > > > Hi Maxim, > > > > > > The new docs project is not finished yet. There are still a lot of > pages > > > to port to the new format, and we are still working on the integration > > with > > > the web-site. Nevertheless, we can try to publish the Ignite 2.9 > > > documentation on the web-site in the new format. The documentation will > > not > > > be 100% complete, but it will be updated significantly and will contain > > > most of the information our users need. Actually, I would like to do > > that, > > > but it all depends on how much time I have before Ignite 2.9 is > released. > > > I'd say 2-3 weeks would be enough for me to finish all tasks that are > > > critical for the publication. > > > > > > If we can wait with release 2.9 that much time, then I'll prepare the > > > instruction on how to contribute to the docs. > > > > > > What do you think? > > > > > > -Artem > > > > > > On 03.08.2020 12:24, Maxim Muzafarov wrote: > > > > > >> Artem, > > >> > > >> I'd like to submit some documentation changes for 2.9 release. Should > > >> I update docs on readme.io or publish it on ignite.apache.org? > > >> > > >> On Wed, 29 Jul 2020 at 19:06, Artem Budnikov > > >> wrote: > > >> > > >>> Hi Alex, > > >>> > > >>> Sorry, I missed this message. There is still a lot of work on the > docs. > > >>> When is version 2.9 going to be released? > > >>> > > >>> -Artem > > >>> > > >>> On 22.07.2020 10:35, Alex Plehanov wrote: > > >>> > > Guys, > > > > What about documentation for 2.9 release? Are we going to publish it > > on > > readme.io or publish it on ignite.apache.org? > > What about new edits? Should we still edit pages on readme.io or > > already > > make changes in git repository? > > Artem, could you please clarify the current documentation workflow? > > > > > > пн, 20 июл. 2020 г. в 16:42, Artem Budnikov < > > a.budnikov.ign...@gmail.com>: > > > > Denis, > > > > > > How about the next step of taking the HTML and committing it to the > > >> > > > website > > > > > >> repository? Did you have a chance to think through this step? > > >> > > > Yes, I'll look into this this week. This shouldn't be very > difficult. > > > > > > -Artem > > > > > > On 18.07.2020 00:43, Denis Magda wrote: > > > > > >> Worked out well on my end. Thanks for sending the update! > > >> > > >> How about the next step of taking the HTML and committing it to > the > >
[jira] [Created] (IGNITE-13326) .NET: GetJvmDllPathsWindows does not work on .NET Core
Pavel Tupitsyn created IGNITE-13326: --- Summary: .NET: GetJvmDllPathsWindows does not work on .NET Core Key: IGNITE-13326 URL: https://issues.apache.org/jira/browse/IGNITE-13326 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 2.4 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.10 GetJvmDllPathsWindows implementation is hidden with preprocessor directives on .NET Core, because it uses Windows Registry, which is not available by default. We should use Microsoft.Win32.Registry NuGet package to make it work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] Cache warmup
Hi, Denis! For now, I suggest a simple warm-up implementation, if the persistent storage is less than RAM. If others want to make additional implementations, they can do it themselves by implementing interfaces. For the first point, we need to figure out how and where we will remember pages, etc. Perhaps for such tasks it will be necessary to make improvements in kernel. In "WarmUpStrategy#warmUp" method, we get "GridKernalContext#cache" from which we can get with caches and groups through "GridCacheProcessor#cacheGroups", "GridCacheProcessor#caches" and so on, we can access to pages. > The second one requires direct work with data pages, but not with a cache > context, so it's also impossible to implement. This requires writing additional custom code, which may run longer due to its SQL features, and so on. It would be more convenient to just set a warm-up strategy for both developer and grid administrator. > When loading of all cache data is required, it can be done by running a > local scan query. It will iterate through all data pages and result in > their allocation in memory. 04.08.2020, 15:25, "Denis Mekhanikov" : > Kirill, > > When I discussed this functionality with Ignite users, I heard the > following thoughts about warming up: > > - Node restarts affect performance of queries. The main reason for that > is that the pages that were loaded into memory before the restart are on > disk after the restart. It takes time to reach the same distribution of > data between memory and disk. Until that point the performance is usually > degraded. No simple rule like "load everything" helps here if only a part > of data fits in memory. > - It would be nice to have a way to give preferences to indices when > doing a warmup. Usually indices are used more often than data nodes, so > loading indices first would bring more benefits. > > The first point can be addressed by implementing the policy that would > restore the memory state that was observed before the restart. I don't see > how it can be implemented using the suggested interface. > The second one requires direct work with data pages, but not with a cache > context, so it's also impossible to implement. > > When loading of all cache data is required, it can be done by running a > local scan query. It will iterate through all data pages and result in > their allocation in memory. > > So, I don't really see a scenario when the suggested API will help. Do you > have a suitable use-case that will be covered? > > Denis > > вт, 4 авг. 2020 г. в 13:42, ткаленко кирилл : > >> Hi, Denis! >> >> Previously, I answered Slava about implementation that I keep in mind, now >> it will be possible to add own warm-up strategy implementations. Which will >> be possible to implement in different ways. >> >> At the moment, I suggest implementing one "Load all" strategy, which will >> be effective if persistent storage is less than RAM. >> >> 28.07.2020, 19:46, "Denis Mekhanikov" : >> > Kirill, >> > >> > That will be a great feature! Other popular databases already have it >> (e.g. >> > Postgres: https://www.postgresql.org/docs/11/pgprewarm.html), so it's >> good >> > that we're also going to have it in Ignite. >> > >> > What implementation of CacheWarmup interface do you have in mind? Will >> > there be some preconfigured implementation, and will users be able to >> > implement it themselves? >> > >> > Do you think it should be cache-based? I would say that a >> DataRegion-based >> > warm-up would come more naturally. Page IDs that are loaded into the data >> > region can be dumped periodically to disk and recovered on restarts. This >> > is more or less how it works in Postgres. >> > I'm afraid that if we make it cache-based, the implementation won't be >> that >> > obvious. We already have an API for warmup that appeared to be pretty >> much >> > impossible to apply in a useful way: >> > >> >> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#preloadPartition-int- >> > Let's make sure that our new tool for warming up is actually useful. >> > >> > Denis >> > >> > вт, 28 июл. 2020 г. в 09:17, Zhenya Stanilovsky >> > >> : >> > >> >> Looks like we need additional func for static caches, for >> >> example: warmup(List cconf) it would be helpful for >> >> spring too. >> >> >> >> > >> >> >--- Forwarded message --- >> >> >From: "Вячеслав Коптилин" < slava.kopti...@gmail.com > >> >> >To: dev@ignite.apache.org >> >> >Cc: >> >> >Subject: Re: [DISCUSSION] Cache warmup >> >> >Date: Mon, 27 Jul 2020 16:47:48 +0300 >> >> > >> >> >Hello Kirill, >> >> > >> >> >Thanks a lot for driving this activity. If I am not mistaken, this >> >> >discussion relates to IEP-40. >> >> > >> >> >> I suggest adding a warmup phase after recovery here [1] after [2], >> >> before >> >> >discovery. >> >> >This means that the user's thread, which starts Ignite via >> >>
Re: Moving Ignite documentation to github
Denis, We have some performance drop on benchmarks, so we need some time to find problematic commit and analyze it. I hope this will be completed during the current week and we move to the "Vote preparation" phase to the start of next week. I think waiting for another month due to documentation it's too much. Do we have an option to release with documentation on readme.io and then move documentation in the new format during next month? пн, 3 авг. 2020 г. в 17:55, Denis Magda : > I would wait for 3-4 weeks and release the new docs in 2.9. It means that > the release should be announced the first week of September which is not a > huge slip. Moreover, it feels like the testing phase and release procedures > will not be completed sooner. > > So, I would suggest contributing 2.9 related page to the new documentation > repository. > > > Denis > > On Monday, August 3, 2020, Artem Budnikov > wrote: > > > Hi Maxim, > > > > The new docs project is not finished yet. There are still a lot of pages > > to port to the new format, and we are still working on the integration > with > > the web-site. Nevertheless, we can try to publish the Ignite 2.9 > > documentation on the web-site in the new format. The documentation will > not > > be 100% complete, but it will be updated significantly and will contain > > most of the information our users need. Actually, I would like to do > that, > > but it all depends on how much time I have before Ignite 2.9 is released. > > I'd say 2-3 weeks would be enough for me to finish all tasks that are > > critical for the publication. > > > > If we can wait with release 2.9 that much time, then I'll prepare the > > instruction on how to contribute to the docs. > > > > What do you think? > > > > -Artem > > > > On 03.08.2020 12:24, Maxim Muzafarov wrote: > > > >> Artem, > >> > >> I'd like to submit some documentation changes for 2.9 release. Should > >> I update docs on readme.io or publish it on ignite.apache.org? > >> > >> On Wed, 29 Jul 2020 at 19:06, Artem Budnikov > >> wrote: > >> > >>> Hi Alex, > >>> > >>> Sorry, I missed this message. There is still a lot of work on the docs. > >>> When is version 2.9 going to be released? > >>> > >>> -Artem > >>> > >>> On 22.07.2020 10:35, Alex Plehanov wrote: > >>> > Guys, > > What about documentation for 2.9 release? Are we going to publish it > on > readme.io or publish it on ignite.apache.org? > What about new edits? Should we still edit pages on readme.io or > already > make changes in git repository? > Artem, could you please clarify the current documentation workflow? > > > пн, 20 июл. 2020 г. в 16:42, Artem Budnikov < > a.budnikov.ign...@gmail.com>: > > Denis, > > > > How about the next step of taking the HTML and committing it to the > >> > > website > > > >> repository? Did you have a chance to think through this step? > >> > > Yes, I'll look into this this week. This shouldn't be very difficult. > > > > -Artem > > > > On 18.07.2020 00:43, Denis Magda wrote: > > > >> Worked out well on my end. Thanks for sending the update! > >> > >> How about the next step of taking the HTML and committing it to the > >> > > website > > > >> repository? Did you have a chance to think through this step? > >> > >> - > >> Denis > >> > >> > >> On Fri, Jul 17, 2020 at 5:27 AM Artem Budnikov < > >> > > a.budnikov.ign...@gmail.com> > > > >> wrote: > >> > >> Hi everyone, > >>> > >>> I've prepared the initial set of source files for the Ignite > >>> documentation. If you are interested, you can take a look at > >>> https://github.com/apache/ignite/tree/IGNITE-7595/docs > >>> > >>> You can run a local web-server (jekyll) if you want to view the > docs > >>> in > >>> your browser. Refer to the README.adoc for instructions. Some > people > >>> had > >>> troubles installing Jekyll locally, so I added an instruction on > how > >>> to > >>> use jekyll docker image. > >>> > >>> If you have any comments on the overall approach, please let me > know. > >>> The styles and content are still a work in progress, so please > don't > >>> report issues related to that. > >>> > >>> -Artem > >>> > >>> On 26.06.2020 01:54, Guru Stron wrote: > >>> > +1 for migrating docs to github. It will allow an easier > contribution > > >>> for > > > >> docs, I think. As a nice feature - adding an edit link (submit PR > for > > >>> docs) > >>> > to the document page on site. > > As for keeping them separate - Microsoft keeps docs for it's > products > > >>> in > > > >> separate repos, for example. > > On Thu, 25 Jun 2020 at 15:48, Artem Budnikov < > > >>>
Re: [DISCUSSION] Cache warmup
Kirill,
When I discussed this functionality with Ignite users, I heard the
following thoughts about warming up:
- Node restarts affect performance of queries. The main reason for that
is that the pages that were loaded into memory before the restart are on
disk after the restart. It takes time to reach the same distribution of
data between memory and disk. Until that point the performance is usually
degraded. No simple rule like "load everything" helps here if only a part
of data fits in memory.
- It would be nice to have a way to give preferences to indices when
doing a warmup. Usually indices are used more often than data nodes, so
loading indices first would bring more benefits.
The first point can be addressed by implementing the policy that would
restore the memory state that was observed before the restart. I don't see
how it can be implemented using the suggested interface.
The second one requires direct work with data pages, but not with a cache
context, so it's also impossible to implement.
When loading of all cache data is required, it can be done by running a
local scan query. It will iterate through all data pages and result in
their allocation in memory.
So, I don't really see a scenario when the suggested API will help. Do you
have a suitable use-case that will be covered?
Denis
вт, 4 авг. 2020 г. в 13:42, ткаленко кирилл :
> Hi, Denis!
>
> Previously, I answered Slava about implementation that I keep in mind, now
> it will be possible to add own warm-up strategy implementations. Which will
> be possible to implement in different ways.
>
> At the moment, I suggest implementing one "Load all" strategy, which will
> be effective if persistent storage is less than RAM.
>
>
> 28.07.2020, 19:46, "Denis Mekhanikov" :
> > Kirill,
> >
> > That will be a great feature! Other popular databases already have it
> (e.g.
> > Postgres: https://www.postgresql.org/docs/11/pgprewarm.html), so it's
> good
> > that we're also going to have it in Ignite.
> >
> > What implementation of CacheWarmup interface do you have in mind? Will
> > there be some preconfigured implementation, and will users be able to
> > implement it themselves?
> >
> > Do you think it should be cache-based? I would say that a
> DataRegion-based
> > warm-up would come more naturally. Page IDs that are loaded into the data
> > region can be dumped periodically to disk and recovered on restarts. This
> > is more or less how it works in Postgres.
> > I'm afraid that if we make it cache-based, the implementation won't be
> that
> > obvious. We already have an API for warmup that appeared to be pretty
> much
> > impossible to apply in a useful way:
> >
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#preloadPartition-int-
> > Let's make sure that our new tool for warming up is actually useful.
> >
> > Denis
> >
> > вт, 28 июл. 2020 г. в 09:17, Zhenya Stanilovsky
> >> :
> >
> >> Looks like we need additional func for static caches, for
> >> example: warmup(List cconf) it would be helpful for
> >> spring too.
> >>
> >> >
> >> >--- Forwarded message ---
> >> >From: "Вячеслав Коптилин" < slava.kopti...@gmail.com >
> >> >To: dev@ignite.apache.org
> >> >Cc:
> >> >Subject: Re: [DISCUSSION] Cache warmup
> >> >Date: Mon, 27 Jul 2020 16:47:48 +0300
> >> >
> >> >Hello Kirill,
> >> >
> >> >Thanks a lot for driving this activity. If I am not mistaken, this
> >> >discussion relates to IEP-40.
> >> >
> >> >> I suggest adding a warmup phase after recovery here [1] after [2],
> >> before
> >> >discovery.
> >> >This means that the user's thread, which starts Ignite via
> >> >Ignition.start(), will wait for ana additional step - cache warm-up.
> >> >I think this fact has to be clearly mentioned in our documentation (at
> >> >Javadocat least) because this step can be time-consuming.
> >> >
> >> >> I suggest adding a new interface:
> >> >I would change it a bit. First of all, it would be nice to place this
> >> >interface to a public package and get rid of using GridCacheContext,
> >> >which is an internal class and it should not leak to the public API
> in any
> >> >case.
> >> >Perhaps, this parameter is not needed at all or we should add some
> public
> >> >abstraction instead of internal class.
> >> >
> >> >package org.apache.ignite.configuration;
> >> >
> >> >import org.apache.ignite.IgniteCheckedException;
> >> >import org.apache.ignite.lang.IgniteFuture;
> >> >
> >> >public interface CacheWarmupper {
> >> > /**
> >> > * Warmup cache.
> >> > *
> >> > * @param cachename Cache name.
> >> > * @return Future cache warmup.
> >> > * @throws IgniteCheckedException If failed.
> >> > */
> >> > IgniteFuture warmup(String cachename) throws
> >> >IgniteCheckedException;
> >> >}
> >> >
> >> >Thanks,
> >> >S.
> >> >
> >> >пн, 27 июл. 2020 г. в 15:03, ткаленко кирилл < tkalkir...@yandex.ru
> >:
> >> >
> >> >> Now, after restarting node, we
[jira] [Created] (IGNITE-13325) java.util.concurrent.ExecutionException: java.lang.IllegalStateException: class org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to perform cac
Keshava Munegowda created IGNITE-13325:
--
Summary: java.util.concurrent.ExecutionException:
java.lang.IllegalStateException: class
org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to
perform cache operation (cache is stopped):
Key: IGNITE-13325
URL: https://issues.apache.org/jira/browse/IGNITE-13325
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.8.1
Reporter: Keshava Munegowda
when the ignite was used in the cluster node mode (not the thin client), the
cache closed exceptions are observed.
here is full log:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.apache.ignite.internal.util.GridUnsafe$2
(file:/data/kmg/SBK/build/install/sbk/lib/ignite-core-2.8.1.jar) to field
java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of
org.apache.ignite.internal.util.GridUnsafe$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
0 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding
PropertySource 'systemProperties' with lowest search precedence
2 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding
PropertySource 'systemEnvironment' with lowest search precedence
2 [main] DEBUG org.springframework.core.env.StandardEnvironment - Initialized
StandardEnvironment with PropertySources [MapPropertySource@1220806149
{name='systemProperties', properties={awt.toolkit=sun.awt.X11.XToolkit,
java.specification.version=11, sun.cpu.isalist=, sun.jnu.encoding=UTF-8,
Re: [DISCUSSION] Cache warmup
Hi, Denis!
Previously, I answered Slava about implementation that I keep in mind, now it
will be possible to add own warm-up strategy implementations. Which will be
possible to implement in different ways.
At the moment, I suggest implementing one "Load all" strategy, which will be
effective if persistent storage is less than RAM.
28.07.2020, 19:46, "Denis Mekhanikov" :
> Kirill,
>
> That will be a great feature! Other popular databases already have it (e.g.
> Postgres: https://www.postgresql.org/docs/11/pgprewarm.html), so it's good
> that we're also going to have it in Ignite.
>
> What implementation of CacheWarmup interface do you have in mind? Will
> there be some preconfigured implementation, and will users be able to
> implement it themselves?
>
> Do you think it should be cache-based? I would say that a DataRegion-based
> warm-up would come more naturally. Page IDs that are loaded into the data
> region can be dumped periodically to disk and recovered on restarts. This
> is more or less how it works in Postgres.
> I'm afraid that if we make it cache-based, the implementation won't be that
> obvious. We already have an API for warmup that appeared to be pretty much
> impossible to apply in a useful way:
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#preloadPartition-int-
> Let's make sure that our new tool for warming up is actually useful.
>
> Denis
>
> вт, 28 июл. 2020 г. в 09:17, Zhenya Stanilovsky > :
>
>> Looks like we need additional func for static caches, for
>> example: warmup(List cconf) it would be helpful for
>> spring too.
>>
>> >
>> >--- Forwarded message ---
>> >From: "Вячеслав Коптилин" < slava.kopti...@gmail.com >
>> >To: dev@ignite.apache.org
>> >Cc:
>> >Subject: Re: [DISCUSSION] Cache warmup
>> >Date: Mon, 27 Jul 2020 16:47:48 +0300
>> >
>> >Hello Kirill,
>> >
>> >Thanks a lot for driving this activity. If I am not mistaken, this
>> >discussion relates to IEP-40.
>> >
>> >> I suggest adding a warmup phase after recovery here [1] after [2],
>> before
>> >discovery.
>> >This means that the user's thread, which starts Ignite via
>> >Ignition.start(), will wait for ana additional step - cache warm-up.
>> >I think this fact has to be clearly mentioned in our documentation (at
>> >Javadocat least) because this step can be time-consuming.
>> >
>> >> I suggest adding a new interface:
>> >I would change it a bit. First of all, it would be nice to place this
>> >interface to a public package and get rid of using GridCacheContext,
>> >which is an internal class and it should not leak to the public API in any
>> >case.
>> >Perhaps, this parameter is not needed at all or we should add some public
>> >abstraction instead of internal class.
>> >
>> >package org.apache.ignite.configuration;
>> >
>> >import org.apache.ignite.IgniteCheckedException;
>> >import org.apache.ignite.lang.IgniteFuture;
>> >
>> >public interface CacheWarmupper {
>> > /**
>> > * Warmup cache.
>> > *
>> > * @param cachename Cache name.
>> > * @return Future cache warmup.
>> > * @throws IgniteCheckedException If failed.
>> > */
>> > IgniteFuture warmup(String cachename) throws
>> >IgniteCheckedException;
>> >}
>> >
>> >Thanks,
>> >S.
>> >
>> >пн, 27 июл. 2020 г. в 15:03, ткаленко кирилл < tkalkir...@yandex.ru >:
>> >
>> >> Now, after restarting node, we have only cold caches, which at first
>> >> requests to them will gradually load data from disks, which can slow
>> down
>> >> first calls to them.
>> >> If node has more RAM than data on disk, then they can be loaded at start
>> >> "warmup", thereby solving the issue of slowdowns during first calls to
>> >> caches.
>> >>
>> >> I suggest adding a warmup phase after recovery here [1] after [2],
>> before
>> >> descovery.
>> >>
>> >> I suggest adding a new interface:
>> >>
>> >> package org.apache.ignite.internal.processors.cache;
>> >>
>> >> import org.apache.ignite.IgniteCheckedException;
>> >> import org.apache.ignite.internal.IgniteInternalFuture;
>> >> import org.jetbrains.annotations.Nullable;
>> >>
>> >> /**
>> >> * Interface for warming up cache.
>> >> */
>> >> public interface CacheWarmup {
>> >> /**
>> >> * Warmup cache.
>> >> *
>> >> * @param cacheCtx Cache context.
>> >> * @return Future cache warmup.
>> >> * @throws IgniteCheckedException if failed.
>> >> */
>> >> @Nullable IgniteInternalFuture process(GridCacheContext cacheCtx)
>> >> throws IgniteCheckedException;
>> >> }
>> >>
>> >> Which will allow to warm up caches in parallel and asynchronously.
>> Warmup
>> >> phase will end after all IgniteInternalFuture for all caches isDone.
>> >>
>> >> Also adding the ability to customize via methods:
>> >>
>> org.apache.ignite.configuration.IgniteConfiguration#setDefaultCacheWarmup
>> >> org.apache.ignite.configuration.CacheConfiguration#setCacheWarmup
>> >>
>> >> Which will allow for each cache to set implementation
Re: [DISCUSSION] Cache warmup
Hi Eugene!
This will be considered in specific strategies.
28.07.2020, 09:17, "Zhenya Stanilovsky" :
> Looks like we need additional func for static caches, for example:
> warmup(List cconf) it would be helpful for spring too.
>
>> --- Forwarded message ---
>> From: "Вячеслав Коптилин" < slava.kopti...@gmail.com >
>> To: dev@ignite.apache.org
>> Cc:
>> Subject: Re: [DISCUSSION] Cache warmup
>> Date: Mon, 27 Jul 2020 16:47:48 +0300
>>
>> Hello Kirill,
>>
>> Thanks a lot for driving this activity. If I am not mistaken, this
>> discussion relates to IEP-40.
>>
>>> I suggest adding a warmup phase after recovery here [1] after [2], before
>> discovery.
>> This means that the user's thread, which starts Ignite via
>> Ignition.start(), will wait for ana additional step - cache warm-up.
>> I think this fact has to be clearly mentioned in our documentation (at
>> Javadocat least) because this step can be time-consuming.
>>
>>> I suggest adding a new interface:
>> I would change it a bit. First of all, it would be nice to place this
>> interface to a public package and get rid of using GridCacheContext,
>> which is an internal class and it should not leak to the public API in any
>> case.
>> Perhaps, this parameter is not needed at all or we should add some public
>> abstraction instead of internal class.
>>
>> package org.apache.ignite.configuration;
>>
>> import org.apache.ignite.IgniteCheckedException;
>> import org.apache.ignite.lang.IgniteFuture;
>>
>> public interface CacheWarmupper {
>> /**
>> * Warmup cache.
>> *
>> * @param cachename Cache name.
>> * @return Future cache warmup.
>> * @throws IgniteCheckedException If failed.
>> */
>> IgniteFuture warmup(String cachename) throws
>> IgniteCheckedException;
>> }
>>
>> Thanks,
>> S.
>>
>> пн, 27 июл. 2020 г. в 15:03, ткаленко кирилл < tkalkir...@yandex.ru >:
>>
>>> Now, after restarting node, we have only cold caches, which at first
>>> requests to them will gradually load data from disks, which can slow down
>>> first calls to them.
>>> If node has more RAM than data on disk, then they can be loaded at start
>>> "warmup", thereby solving the issue of slowdowns during first calls to
>>> caches.
>>>
>>> I suggest adding a warmup phase after recovery here [1] after [2], before
>>> descovery.
>>>
>>> I suggest adding a new interface:
>>>
>>> package org.apache.ignite.internal.processors.cache;
>>>
>>> import org.apache.ignite.IgniteCheckedException;
>>> import org.apache.ignite.internal.IgniteInternalFuture;
>>> import org.jetbrains.annotations.Nullable;
>>>
>>> /**
>>> * Interface for warming up cache.
>>> */
>>> public interface CacheWarmup {
>>> /**
>>> * Warmup cache.
>>> *
>>> * @param cacheCtx Cache context.
>>> * @return Future cache warmup.
>>> * @throws IgniteCheckedException if failed.
>>> */
>>> @Nullable IgniteInternalFuture process(GridCacheContext cacheCtx)
>>> throws IgniteCheckedException;
>>> }
>>>
>>> Which will allow to warm up caches in parallel and asynchronously. Warmup
>>> phase will end after all IgniteInternalFuture for all caches isDone.
>>>
>>> Also adding the ability to customize via methods:
>>> org.apache.ignite.configuration.IgniteConfiguration#setDefaultCacheWarmup
>>> org.apache.ignite.configuration.CacheConfiguration#setCacheWarmup
>>>
>>> Which will allow for each cache to set implementation of cache warming
>>> up,
>>> both for a specific cache, and for all if necessary.
>>>
>>> I suggest adding an implementation of SequentialWarmup that will use [3].
>>>
>>> Questions, suggestions, comments?
>>>
>>> [1] -
>>>
>>> org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#afterLogicalUpdatesApplied
>>> [2] -
>>>
>>> org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#restorePartitionStates
>>> [3] -
>>>
>>> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManager.CacheDataStore#preload
Re: [DISCUSSION] Cache warmup
Hi, Slava!
Thank you for looking at the offer and making fair comments.
I personally discussed with Anton and Alexey because they are author and
sponsor of "IEP-40" and we found out that point 2 in it is no longer relevant
and it can be removed.
I suggest implementing point 3, since it may be independent of point 1. Also,
the warm-up will always start after restore phase, without subscribing to
events.
You are right this should be mentioned in the documentation and javadoc.
> This means that the user's thread, which starts Ignite via
> Ignition.start(), will wait for ana additional step - cache warm-up.
> I think this fact has to be clearly mentioned in our documentation (at
> Javadocat least) because this step can be time-consuming.
My suggestion for implementation:
1)Adding a marker interface
"org.apache.ignite.configuration.WarmUpConfiguration" for configuring cache
warming;
2)Set only one configuration via
"org.apache.ignite.configuration.IgniteConfiguration#setWarmUpConfiguration";
3)Add an internal warm-up interface that will start in [1] after [2];
package org.apache.ignite.internal.processors.cache.warmup;
import org.apache.ignite.IgniteCheckedException;
import org.apache.ignite.configuration.WarmUpConfiguration;
import org.apache.ignite.internal.GridKernalContext;
/**
* Interface for warming up.
*/
public interface WarmUpStrategy {
/**
* Returns configuration class for mapping to strategy.
*
* @return Configuration class.
*/
Class configClass();
/**
* Warm up.
*
* @param kernalCtx Kernal context.
* @param cfg Warm-up configuration.
* @throws IgniteCheckedException if faild.
*/
void warmUp(GridKernalContext kernalCtx, T cfg) throws
IgniteCheckedException;
}
4)Adding an internal plugin extension for add own strategies;
package org.apache.ignite.internal.processors.cache.warmup;
import java.util.Collection;
import org.apache.ignite.plugin.Extension;
/**
* Interface for getting warm-up strategies from plugins.
*/
public interface WarmUpStrategySupplier extends Extension {
/**
* Getting warm-up strategies.
*
* @return Warm-up strategies.
*/
Collection strategies();
}
5)Add a "Load all" strategy that will load everything to memory as long as
there is space in it. This strategy is suitable if the persistent storage is
less than RAM.
Any objections or comments?
[1] -
org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#afterLogicalUpdatesApplied
[2] -
org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#restorePartitionStates
27.07.2020, 16:48, "Вячеслав Коптилин" :
> Hello Kirill,
>
> Thanks a lot for driving this activity. If I am not mistaken, this
> discussion relates to IEP-40.
>
>> I suggest adding a warmup phase after recovery here [1] after [2], before
>
> discovery.
> This means that the user's thread, which starts Ignite via
> Ignition.start(), will wait for ana additional step - cache warm-up.
> I think this fact has to be clearly mentioned in our documentation (at
> Javadocat least) because this step can be time-consuming.
>
>> I suggest adding a new interface:
>
> I would change it a bit. First of all, it would be nice to place this
> interface to a public package and get rid of using GridCacheContext,
> which is an internal class and it should not leak to the public API in any
> case.
> Perhaps, this parameter is not needed at all or we should add some public
> abstraction instead of internal class.
>
> package org.apache.ignite.configuration;
>
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.lang.IgniteFuture;
>
> public interface CacheWarmupper {
> /**
> * Warmup cache.
> *
> * @param cachename Cache name.
> * @return Future cache warmup.
> * @throws IgniteCheckedException If failed.
> */
> IgniteFuture warmup(String cachename) throws IgniteCheckedException;
> }
>
> Thanks,
> S.
>
> пн, 27 июл. 2020 г. в 15:03, ткаленко кирилл :
>
>> Now, after restarting node, we have only cold caches, which at first
>> requests to them will gradually load data from disks, which can slow down
>> first calls to them.
>> If node has more RAM than data on disk, then they can be loaded at start
>> "warmup", thereby solving the issue of slowdowns during first calls to
>> caches.
>>
>> I suggest adding a warmup phase after recovery here [1] after [2], before
>> descovery.
>>
>> I suggest adding a new interface:
>>
>> package org.apache.ignite.internal.processors.cache;
>>
>> import org.apache.ignite.IgniteCheckedException;
>> import org.apache.ignite.internal.IgniteInternalFuture;
>> import org.jetbrains.annotations.Nullable;
>>
>> /**
>> * Interface for warming up cache.
>> */
>> public interface CacheWarmup {
>> /**
>> * Warmup cache.
>> *
>> * @param cacheCtx Cache context.
>> *
[jira] [Created] (IGNITE-13324) Create NoOp version of GridEncryptionManager for in-memory grid.
Pavel Pereslegin created IGNITE-13324: - Summary: Create NoOp version of GridEncryptionManager for in-memory grid. Key: IGNITE-13324 URL: https://issues.apache.org/jira/browse/IGNITE-13324 Project: Ignite Issue Type: Improvement Reporter: Pavel Pereslegin Assignee: Pavel Pereslegin GridEncryptionManager starts even on an in-memory grid, this introduces a minor overhead and it seems better to create a simplified (no-op) version for the in-memory grid. -- This message was sent by Atlassian Jira (v8.3.4#803005)
