Can you spell out what parts of Cache.close are asynchronous? As far as I can tell it shuts down threadpools, etc. synchronously.
-Dan On Tue, Apr 14, 2020 at 3:09 PM Mark Hanson <hans...@vmware.com> wrote: > Hi Jake, > > For Option 6: We could fix isClosed as well. That is a great suggestion. > Currently, it returns almost immediately. > I like your options though.... > > Any other thoughts? > > Any preferences? It think any of the current options seem better than the > current situation as long as we fix isClosed. > > Thanks, > Mark > ________________________________ > From: Jacob Barrett <jbarr...@pivotal.io> > Sent: Tuesday, April 14, 2020 2:30 PM > To: dev@geode.apache.org <dev@geode.apache.org> > Subject: Re: [Discuss] Cache.close synchronous is not synchronous, but > code still expects it to be.... > > Option 4: Cache.closeAndWait(long timeout, TimeUnit unit) - Closes and > waits until it is really closed. > Option 5: Cache.close(Runnable closedCalleback) - Runs callback after > cache is really close. > Option 6: cache.close(); while (!cache.isClosed()); > > > > On Apr 14, 2020, at 2:11 PM, Mark Hanson <mhan...@pivotal.io> wrote: > > > > Hi All, > > > > I know that we have discussed this once before, but I think it bears > repeating. We have test code that assumes cache.close is synchronous. It is > not. Not even close. I would like discuss some possible changes. > > > > Option 1. Call it what it is. Deprecate Cache.close and create a new > method called asyncClose to replace it. Simple and descriptive. > > Option 2. Fix cache close so it is synchronous. Some might say that we > are going to break behavior, but I doubt any user relies on the fact that > it is asynchronous. That would be dangerous in and of itself. Obviously, we > don’t want to change behavior, but there have been a number of distributed > tests that have failed for this. If internal to the code devs don’t get it > right, where does that leave users. > > Option 3. Status quo. > > > > What do you think? Are there other options I am missing? > > > > Thanks, > > Mark > > > >
