Unable to get behavior described in documentation when using durable native client

Hi all, Could you please help me understand behavior of the native client when configured as durable? I have been working on a bug GEODE-7944 which results with exception "Unable to deserialize membership id java.io.EOFException" on

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

When I previously submitted a PR to change concurrent calls to Cache.close() to not return until everything is completely stopped (including the DistributedSystem), the change was down-voted by Anil. His reasoning was that the current behavior is expected by users and is de facto correct. Changing

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

 > On Apr 14, 2020, at 3:09 PM, Mark Hanson wrote: > > Any other thoughts? Don’t encourage me! Option 7: remove all singletons! > Any preferences? It think any of the current options seem better than the > current situation as long as we fix isClosed. Option 7, 2 or 4 in that order.

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

Among other problems I encountered, 1 problem that seemed to affect *Integration Tests* as I described was that the *Singleton* cache reference was not cleaned up in a timely manner. Therefore, starting a fresh cache instance (without coordination) in another *Integration Tests* would occasionally

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

I believe it is because of disk persistence among other things. Kirk would know for sure. He fixed the issue and his PR got shutdown. I totally support just fixing the bug. Let’s give Kirk a chance to chime in. Thanks, Mark > On Apr 14, 2020, at 3:39 PM, Dan Smith wrote: > > IMO if it's not

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

IMO if it's not currently synchronous, that's just a bug that needs to be fixed. If folks can provide details on what actually was asynchronous or the particular test failures they saw, that would be helpful. Previously, when this came up it looks like Kirk found that close would not wait for a

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

My first thought is cache close (i.e. RegionService.close() should be synchronous (by default), perhaps, with non-blocking options or options to wait for a set timeout as Jake suggested. This is a problem for *Integration Tests* (that start a peer cache instance, in-process or standalone) in

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

The isClosed flag and method might be used currently more as an isClosing. The GemFireCacheImpl.isClosed() method is actually returning isClosing. Whatever change to isClosed that will be made, will have to properly handle cases where it's meant to be treated as isClosing(). On Tue, Apr 14, 2020

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

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 wrote: > Hi Jake, > > For Option 6: We could fix isClosed as well. That is a great suggestion. > Currently, it

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

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

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

Re: [Discuss] Cache.close is not synchronous, but code still expects it to be....

Corrected subject line... > On Apr 14, 2020, at 2:11 PM, Mark Hanson 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

[Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

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

Reviewers for GEODE-7971 Gateway sender to deliver transaction events atomically to gateway receivers

Hi, Could I ask for a review on https://github.com/apache/geode/pull/4928? This PR is about "Gateway sender to deliver transaction events atomically to gateway receivers" (https://issues.apache.org/jira/browse/GEODE-7971). Thanks, /Alberto G.