Java SDK - Is there a problem if I only close buckets

Java SDK
,
1

Hello,

I am using Java SDK to develop an application and I created a DAO layer in my application to store my entities.
And I am facing an issue that my tests are taking too long to run because of the time the SDK takes to disconnect from Couchbase.

If just call the Bucket.close() methods the tests run and finish just fine (under 2 seconds).
But if I issue Cluster.disconnect() the tests take up to 6 seconds to finish.

I am putting both Bucket.close() and Cluster.disconnect() on @AfterClass of JUnit to just close the connection after all tests have been run.

So here are my questions:

  • Is there any problem if I just issue the Bucket.close() part and not the Cluster.disconnect() part?
  • How Couchbase handle those dangling connections?
  • Does it purge after a timeout of inactivity?

Thanks in advance.

2

Cluster.disconnect() will also close all open buckets, so maybe if you only leave that it’ll finish quickly enough?

Otherwise, I don’t think it’s a huge issue to only use bucket.close, as the connections will be killed when the JVM running the tests exits.

If you are writing integration tests (and arguably, if you’re connecting to the database, you’re writing integration tests :stuck_out_tongue: ), having longer execution time is probably “normal”… That said I agree that 6s is a bit long for a disconnect. Any particular messages or logs that would indicate what takes up most time?

3

I already tried no to close the buckets and only trying to disconnect from the clusters, but it takes some time anyway (3s).
But, since there is no problem, I will continue only closing buckets.
When the number of requests to my WEB API begin to increase I will re-check this aspect to see if there is any kind of performance impact.

Thanks for the rapid response! You guys are doing an awesome work with Couchbase (and the SDK).

4

careful, it should not be a problem, but only in the context of automated tests, don’t do that in application code (just to be sure)