These sort of problems are the exact types of things that *Spring Test for Apache Geode* (STDG) [1] was designed to handle. I experienced similar problems while testing features in the SDG, SSDG and SBDG projects, which is how STDG came to be.
However, since you are not using *Spring* in this case, there are a few things you should be aware of. 1. ClientCache.close() does NOT guarantee that the [client] cache instance has been fully stopped and that all resources are properly released in a timely manner. 2. Depending on your version of Geode, the SSL state is maintained in static references that can linger without proper cleanup, especially in and between automated tests, and particularly if you are not forking new JVMs per test. 3. You should be careful how you set Geode properties (e.g. as Java System properties). Your approach (i.e. using the API) should be generally fine, however, keep in mind #1 above! 4. etc... There are other things to be aware of as well, but I simply wanted to list a few here for your reference. You can use this setup/tear down logic [2] from STDG as a guide in your own test scaffolding. You can safely ignore the *Spring*-specific tear down logic. As 1 example of testing SSL, you can review the SBDG test suite, beginning here [3]. SBDG offers support [4] to auto-configure SSL for Apache Geode, depending on your configuration. As you can imagine, SBDG's test suite is very comprehensive (given the auto-configuration for many Geode features), and because I don't like forking JVMs, it is imperative that each test properly cleanup after itself in a reliable manner especially if 1 tests uses SSL and the rest don't. Anyway... Hope this helps (give you ideas/pointers/etc)! Regards, -j [1] https://github.com/spring-projects/spring-test-data-geode [2] https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L106-L250 [3] https://github.com/spring-projects/spring-boot-data-geode/blob/master/spring-geode-autoconfigure/src/test/java/org/springframework/geode/boot/autoconfigure/security/ssl/AutoConfiguredSslIntegrationTests.java [4] https://docs.spring.io/spring-boot-data-geode-build/1.3.x/reference/html5/#geode-security-ssl On Fri, Feb 7, 2020 at 5:17 AM Mario Kevo <[email protected]> wrote: > Hi all, > > We are using java client to test some functionality and it seems that we > have a problem with the client cache. > We started locator and server with SSL enabled. > On the client side also add SSL parameters, create proxy region, put some > entries and it works. > > Properties props = new Properties(); > > props.setProperty("ssl-enabled-components", "all"); > > props.setProperty("ssl-keystore", keystorePath); > > ... > > ClientCache clientCache = new > ClientCacheFactory(props).addPoolLocator("localhost", 10334) > .set("log-level", "info").create(); > > ... > clientCache.close(); > > After that we start another test with some other properties. > > As we are connecting from non-SSL-enabled client to SSL-enabled locator we > should get an exception, but didn't. > > > Properties props = new Properties(); > > props.setProperty("log-file", "test.log"); // no ssll parameters > > ... > > ClientCache clientCache = new > ClientCacheFactory(props).addPoolLocator("localhost", 10334) > > .set("log-level", "info").create(); > > ... > clientCache.close(); > > Despite of that we have in logs that *GemFire Properties defined with api > * has only this property changed but it somehow take also the cache from > the test before. > > The same thing happened if we change order of tests execution. > > > > Does anyone know is there a possibility that cache is saved somewhere and > if yes how to delete it? > > How to avoid this issue? > > > BR, > > Mario > > -- -John Spring Data Team
