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 >
