[ 
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)

Reply via email to