I found a test that closes the cache and then recreates the cache multiple
times with 2 second sleep between each. I tried to remove the Thread.sleep
and found that recreating the cache
throws DistributedSystemDisconnectedException (see below).
This seems like a usability nightmare. Anyone have an
+1 ^ 64!
I found this out the hard way some time ago and is why STDG exists in the
first place (i.e. usability issues, particularly with testing).
On Mon, Nov 25, 2019 at 1:41 PM Kirk Lund wrote:
> I found a test that closes the cache and then recreates the cache multiple
> times with 2 second
+1 to fix.
> On Nov 25, 2019, at 2:02 PM, John Blum wrote:
>
> +1 ^ 64!
>
> I found this out the hard way some time ago and is why STDG exists in the
> first place (i.e. usability issues, particularly with testing).
>
> On Mon, Nov 25, 2019 at 1:41 PM Kirk Lund wrote:
>
>> I found a test tha
Looking at the code, the cache.close() and InternalCacheBuilder.create()
are synchronized on "GemFireCacheImpl.class"'; it's the
internalCachebuilder create that seems to be using reference to the old
distributed-system.
The GemFireCacheImpl.getInstance() and getExisting() both perform
"isClosing"
+1 for fixing it.
De: Anilkumar Gingade
Enviado: martes, 26 de noviembre de 2019 0:24
Para: geode
Asunto: Re: Cache.close is not synchronous?
Looking at the code, the cache.close() and InternalCacheBuilder.create()
are synchronized on "GemFireCacheImpl.
+1 for fixing.
On Tue, Nov 26, 2019 at 6:53 AM Alberto Bustamante Reyes
wrote:
> +1 for fixing it.
>
> De: Anilkumar Gingade
> Enviado: martes, 26 de noviembre de 2019 0:24
> Para: geode
> Asunto: Re: Cache.close is not synchronous?
>
Seems like this must be a bug, so I filed
https://issues.apache.org/jira/browse/GEODE-7503. I'll look into it...
On Mon, Nov 25, 2019 at 3:24 PM Anilkumar Gingade
wrote:
> Looking at the code, the cache.close() and InternalCacheBuilder.create()
> are synchronized on "GemFireCacheImpl.class"'; it
I added a stack trace to the closing of both GemFireCacheImpl and
InternalDistributedSystem and found a difference.
The test passes when it's the test thread doing the close:
java.lang.Throwable: KIRK GemFireCacheImpl closed 1046056441
at
org.apache.geode.internal.cache.GemFireCacheImpl.c
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 possi
