If you are going to use CustomExpiry and use fields of your value to compute the expiration time then I think you would want to use ttl expiration. TimeToLive expiration only gets reevaluated when the entry is written, and you would only care about rescheduling it when the value changes. Idle expiration gets reevaluated on every entry read which would be overkill in your use case.
Expiration has one scheduler thread that will wake up when a scheduled item's time has come. It keeps a sorted queue using the JDK java.util.Timer class. When an item in that queue expires a check is done to see if it actually did expire or if its last modified/accessed time has extended its life. If it was extended it just reschedules it out into the future. You are free to tell it when you want entries to expire. So you could bucket them into a time that is an off time for you. If you are using the CustomExpiry then it seems like this should make it easy for you to decide at what time of day the expirations happen. By default the single scheduler thread is also the thread that performs the expiration action. Since expiration are usually a distributed invalidate/destroy they can take some time on a larger cluster. So if a bunch of entries all want to expire at the same time it can take a while for this single thread to do them one at a time. A system property exists that allows you to use a thread pool that the schedule hands the expiration operation off too. Set the system property "gemfire.EXPIRY_THREADS" to a value greater than zero if you need additional threads. On Tue, Aug 7, 2018 at 12:27 PM Upasana Rangwani <[email protected]> wrote: > Thanks Udo for your quick guidance. > > I have referred the reference provided by you, and it seems I can create > my own implementation of *CustomExpiry *and in the implementation of* > getExpiry(Entry entry) *can set the desired ExpirationAttributes for > targetted entries in my partition region. I will certainly give a try to > this. > > From the doc, it seems there is async expiration thread who is responsible > of this, It would be great help if some one gives me brief details on > following, > 1. How can I make sure that for a particular day (or 24 hours span) > expiration thread only do it job once (or in a off time), > would like to avoid frequent expiration checks, as it may be overkill, > and not required for my case as date changes in 24 hrs. > > 2. Brief workflow of row's expiration when one provides customExpiry > configuration - to understand this better. > > Thanks in advance. > > -U. > > > On Tue, Aug 7, 2018 at 11:43 PM, Udo Kohlmeyer <[email protected]> wrote: > >> Hi there Upasana, >> >> I think if you were to use CustomExpiration >> <http://?ui=2&ik=33876c1b82&view=fimg&th=165159813ce123d4&attid=0.1.1&disp=emb&attbid=ANGjdJ8BI70PT-rC7pqsj1AKV_eYpdDCeqRcsVv7hpycAk690F2woyI44YH25DvtHHiy9OwUi3tWmFJR0HP3WxFzPcvqmJFVxcSR_OchvRN7SwRhgmES_KmJ5Dum6jA&sz=s0-l75-ft&ats=1533668619696&rm=165159813ce123d4&zw&atsh=0> >> you should be able to achieve what you want. In the custom expiry >> implementation you define what the expiration criteria are. >> >> Have you tried this? >> >> --Udo >> [1] >> https://geode.apache.org/docs/guide/16/developing/expiration/configuring_data_expiration.html >> >> On 8/7/18 10:45, Upasana Rangwani wrote: >> >> Hello, >> >> In my expriment, I am loading (onetime - initial load) *last six month >> passenger data* (boarded flight information) into geode region, where >> value object contains field/attribute named *departure_date*. >> >> As day progress (day+1, day+2 and so on), I want to delete/expire all >> records from region that does not satisfy the last six month criteria >> (departure_date is not within six month). >> >> Expectation is for any given day after initial load, region should >> contain last six month (departure_date - current_date is not more than six >> month ) data. >> >> I tried to explore geode's expiration mechanism and seems can not be used >> for my requirements. >> >> Kindly guide me how to achieve the above. >> >> Thanks in advance. >> >> -U. >> >> >> >> >> >
