Предотвратить умирание mongodb с помощью: "состояние должно быть: открыто"

Question

Я использую mongodb в многопоточном приложении clojure, использую библиотеку monger, и один из моих продюсеров умирает с

java.lang.IllegalStateException: state should be: open
 at com.mongodb.assertions.Assertions.isTrue (Assertions.java:70)
    com.mongodb.connection.DefaultServer.getConnection (DefaultServer.java:84)
    com.mongodb.binding.ClusterBinding$ClusterBindingConnectionSource.getConnection (ClusterBinding.java:86)
    com.mongodb.operation.QueryBatchCursor.getMore (QueryBatchCursor.java:205)
    com.mongodb.operation.QueryBatchCursor.hasNext (QueryBatchCursor.java:103)
    com.mongodb.MongoBatchCursorAdapter.hasNext (MongoBatchCursorAdapter.java:46)
    com.mongodb.DBCursor.hasNext (DBCursor.java:155)
    clojure.lang.RT$4.invoke (RT.java:512)
    clojure.lang.LazySeq.sval (LazySeq.java:40)
    clojure.lang.LazySeq.seq (LazySeq.java:49)
    clojure.lang.RT.seq (RT.java:525)
    clojure.core$seq__6416.invokeStatic (core.clj:137)
    clojure.core$map$fn__6875.invoke (core.clj:2719)
    clojure.lang.LazySeq.sval (LazySeq.java:40)
    clojure.lang.LazySeq.seq (LazySeq.java:49)
    clojure.lang.RT.seq (RT.java:525)
    clojure.core$seq__6416.invokeStatic (core.clj:137)
    clojure.core$map$fn__6875.invoke (core.clj:2719)
    clojure.lang.LazySeq.sval (LazySeq.java:40)
    clojure.lang.LazySeq.seq (LazySeq.java:49)
    clojure.lang.RT.seq (RT.java:525)
    clojure.core$seq__6416.invokeStatic (core.clj:137)
    clojure.core$filter$fn__6902.invoke (core.clj:2782)
    clojure.lang.LazySeq.sval (LazySeq.java:40)
    clojure.lang.LazySeq.seq (LazySeq.java:49)
    clojure.lang.ChunkedCons.chunkedNext (ChunkedCons.java:59)
    clojure.lang.ChunkedCons.next (ChunkedCons.java:43)
    clojure.lang.RT.next (RT.java:703)
    clojure.core$next__6400.invokeStatic (core.clj:64)
    clojure.core$dorun.invokeStatic (core.clj:3115)
    clojure.core$doall.invokeStatic (core.clj:3121)
    clojure.core$doall.invoke (core.clj:3121)
    myapp.ns1.$somefn.invokeStatic (ns1.clj:93)
    myapp.ns1.$somefn.invoke (ns1.clj:90)
    myapp.ns1$anotherfn.invokeStatic (ns1.clj:124)
    myapp.ns1$anotherfn.invoke (ns1.clj:116)
    myapp.ns2$doit.invokeStatic (ns2:21)
    myapp.ns2$doit.invoke (ns2:17)
    myapp.ns2$producer$fn__11200.invoke (ns2:45)
    myapp.ns2$producer.invokeStatic (ns2:31)
    myapp.ns2$producer.invoke (ns2:25)
    myapp.ns2$_start$fn__11230.invoke (ns2:70)
    clojure.core$binding_conveyor_fn$fn__6766.invoke (core.clj:2020)
    clojure.lang.AFn.call (AFn.java:18)
    java.util.concurrent.FutureTask.run (FutureTask.java:266)
    java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1142)
    java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:617)
    java.lang.Thread.run (Thread.java:745)

Я нашел кучу других хитов для этой проблемы, и все они были решены путем удаления некоторых conn.close() позвоните куда-нибудь.

У меня есть одно соединение, которое я создаю при запуске, и единственное место, где я звоню close во время выключения. Драйвер Java управляет пулом потоков, поэтому я не совсем уверен, о каком подключении мы говорим. Имеет ли DbObject, возвращаемый из запросов, свое собственное выделенное соединение, и это соединение умирает?

Я попытался исправить это, указав :socket-keep-alive trueи явно установить :socket-timeout до 0 (это значение по умолчанию и означает неограниченное) безрезультатно.

В monger есть некоторое использование with-open, которое, как я полагал, может вызвать проблему, с которой я столкнулся. На случай, если какое-то соединение, связанное с объектом db, передается сюда, которое закрывается, я попытался удалить все повторное использование объектов db, но это не имело никакого эффекта.

Другая мысль заключалась в том, чтоwith-open может плохо взаимодействовать с ленивыми вещами внутри, но оборачивая все в doall чтобы сделать это нетерпеливым, не имело никакого эффекта также.

Я бегу против набора реплик, и я бегу локально на подчиненном Mongodb с ReadPreference/secondary,

Любые другие идеи относительно того, что может быть не так?

Answer 1

После удаления слоев лени в моем приложении исключение изменилось на что-то вроде "курсор БД не найден". В тот момент было очевидно, что было не так, и с помощью моего собственного курсора notimeout, Вместо того, чтобы использовать monger, случайные ошибки исчезли.