[ https://issues.apache.org/jira/browse/GEODE-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16490008#comment-16490008 ]
John Blum commented on GEODE-5236: ---------------------------------- As it turns out, there is also another, related problem that occurs when cycling the cache instance used in _Integration Tests_, which can happen rather quickly. This is particularly problematic when different tests in the _Integration Test Suite_ cycle between {{ClientCache}} instances and peer {{Cache}} instances as well, which is not at all uncommon. It seems Apache Geode is not very timely or mutually exclusive about cleaning up the "cache reference" (and associated resources), as obtained from [{{CacheFactory.getAnyInstance()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/CacheFactory.html#getAnyInstance--] or [{{ClientCacheFactory.getAnyInstance()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/client/ClientCacheFactory.html#getAnyInstance--], and creating a "*new*" instance (in subsequent tests in the suite). As such, what happens is, a test can acquire an "existing" cache instance, created previously from some other test class (which is especially problematic when the cache types are different, i.e. "client" vs. "peer", or vice versa) even despite the fact the the previous test may have properly called {{GemFireCache.close()}}. As such, undesirable logic like [this|https://github.com/spring-projects/spring-boot-data-geode/blob/master/geode-spring-boot-starter/src/test/java/org/springframework/boot/data/geode/cache/client/SpringBootApacheGeodeClientCacheApplicationIntegrationTests.java#L65-L68] (which is supported by [this|https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-test-data-geode/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L45-L67]) is required. Again, this is something I already support and handle on the user's behalf in the [*_Spring Test for Apache Geode & Pivotal GemFire (using Spring Data)_*|https://github.com/spring-projects/spring-test-data-geode] project. > Intermittent NoSubscriptionServersAvailableException > ----------------------------------------------------- > > Key: GEODE-5236 > URL: https://issues.apache.org/jira/browse/GEODE-5236 > Project: Geode > Issue Type: Bug > Components: client queues, cq > Reporter: Swapnil Bawaskar > Priority: Major > > When the client connects to the server, the server creates a queue for the > events to send the client, whether the client is *durable* or not. If that > server-side queue is not ready, then a interest registration or CQ will cause > the \{{NoSubscriptionServersAvailableException}}. > When the request for RI or CQ reaches the server, I think, the server should > be able to check if queue initialization is in progress, and the call should > block until the queue is ready. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)