Couchbase BucketClosedException, когда ведро активно используется - PullRequest
1 голос
/ 26 марта 2020

CB сервер - Enterprise Edition 6.0.0 build 1693 CB Java sdk- 2.7.10 Я выполняю стресс-тестирование на своем кластере CB, где я генерирую нагрузку до 1 Кбит / с c. Загрузка представляет собой сочетание операций set / get. 2 операции довольно равны по количеству. Кластер имеет 2 сегмента, из которых я использую только один. Я подключаюсь к кластеру следующим образом

Cluster cluster = CouchbaseCluster.create(config.getString(CB_GE_HOSTS));
        cluster.authenticate(new PasswordAuthenticator(config.getString(CB_GE_USERNAME), config.getString(CB_GE_PASSWORD)));
        bucket = cluster.openBucket(config.getString(CB_GE_BUCKET));

В моем коде я делаю bucket.disconnect() только тогда, когда модуль получает сигнал выключения. так что я явно не закрываю ведро или соединение кластера. Хотя изначально операции выполняются успешно, я начинаю получать BucketClosedException во время выполнения операций. Ниже приведена трассировка стека в логах:

com.couchbase.client.core.BucketClosedException: gameengine has been closed
        at com.couchbase.client.core.RequestHandler.dispatchRequest(RequestHandler.java:240) ~[com.couchbase.client.core-io-1.7.10.jar:na]
        at com.couchbase.client.core.RequestHandler.onEvent(RequestHandler.java:207) ~[com.couchbase.client.core-io-1.7.10.jar:na]
        at com.couchbase.client.core.RequestHandler.onEvent(RequestHandler.java:78) ~[com.couchbase.client.core-io-1.7.10.jar:na]
        at com.couchbase.client.deps.com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:168) ~[com.couchbase.client.core-io-1.7.10.jar:na]
        at com.couchbase.client.deps.com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) ~[com.couchbase.client.core-io-1.7.10.jar:na]
        at com.couchbase.client.deps.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[com.couchbase.client.core-io-1.7.10.jar:na]
        at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_242]

Разве это не происходит обычно только с простаивающими соединениями? У меня запущен один экземпляр модуля, и я создаю соединение с кластером только один раз (в сегменте кода stati c). Чаще всего это происходит, когда я увеличиваю трафик c для кластера CB. Для некоторых начальных запросов CB работает нормально, но затем все вызовы CB начинают терпеть неудачу. Кластер в настоящее время имеет один экземпляр EC2 с 90 ГБ службы данных и 512 МБ службы индекса. Когда я смотрю на ресурсы сервера, в нем перечисляется ~ 45 соединений, с одним подключенным модулем.

1 Ответ

0 голосов
/ 27 марта 2020

Вызов bucket.close () выполнялся явно со стороны клиента. Это было определено из журналов memcache на сервере CB. В одном из потоков в приложении происходил NPE, который не регистрировался. Когда я следил за журналами pod (kubectl logs --follow), я видел, что произойдет NPE, посылая сигнал перезагрузки pod, и это вызовет обработчик завершения работы в приложении, что приведет к закрытию соединения. Это согласуется с выводом о том, что все вызовы CB в модуле не будут выполняться после первой ошибки при подключении к CB. И он будет успешным при следующем запуске для того же модуля, поскольку между тестовыми прогонами был промежуток времени, давая возможность модулю перезапуститься.

...