MongoError['This MongoConnection is closed]

[Daniel Menchaca Luna]

Hello.

I am using "play framework (2.6)" with "(play2-reactivemongo, 0.12.6-play26)", and sometimes when the play server is working reactivemongo faces the following error:

 ERROR] from reactivemongo.api.Cursor in application-akka.actor.default-dispatcher-202 - fails to send request
reactivemongo.core.actors.Exceptions$ClosedException: MongoError['This MongoConnection is closed (Supervisor-1/Connection-2)']
Caused by: reactivemongo.core.actors.Exceptions$InternalState: null
    at reactivemongo.Close(<time:1509058236955>)

My code looks like:

def coleccion: Future[JSONCollection] = reactiveMongoApi.database.map(_.collection("sellers"));


def sellers(limite:Int):Future[Seq[Seller]] = {
        val query = BSONDocument()

        val selector = BSONDocument(
            "seller" -> 0
        )

        coleccion.flatMap(
            _.find(query, selector).cursor[Seller](ReadPreference.primary)
            .collect[Seq](limite,Cursor.FailOnError[Seq[Seller]]())
        )
    }

I Check the mailing list and found an error similar to mine, in a version earlier than the one I'm using:

https://groups.google.com/forum/#!searchin/reactivemongo/reactivemongo.api.Cursor%7Csort:date/reactivemongo/eoCSJZ27Nzc/wtl46A5GAQAJ




To solve this, it is necessary to restart the play server, making it possible to return to normal queries

When this error occurs I can make other queries but in the query where the error occurs it is "blocked" under this error.

Note: The mongo server is a remote, with a latency of 90 - 100

Some one now what am i doing wrong?

[Cédric Chantepie]

A Close event happens if (and only if) the connection has been closed explicitly (or crashed - see logs).

A MongoConnection is a pool and should only be closed at app shutdown.

[Daniel Menchaca Luna]

Hello Cédric, thanks for reply.

I have a curious problem with the query "get seller quey", because when it happens I can work normally in another query like "get seller by id query", and this last query work fine, thsi last query use the same collection in the same block of code, Do you know if it is normal for the latter does not fail while the other fails?

Can i reload the connection with the reactivemongoapi in play? 

[Cédric Chantepie]

As said the MongoConnection should not be closed or reloaded.

[Daniel Menchaca Luna]

Cébric you are right, when this error occurs I shoutdown the server and that's when the cursors detect that mongo is already closed and throw the errors. (I didn't notice that I was causing the message)

I think the problem comes from the cursor that tries to get an answer but it doesn't and doesn't return an answer. When I call this same query again, the system still waits for the previous cursor to finish, and this causes this query to be blocked, until I restart the system. 

I thought that by saying "failover=strict in the URI" this wouldn't happen. How can I kill the cursor that didn't get an answer after a while? I don't know why the cursor doesn't get an answer, but if I can at least unlock it I think it will be enough. 

[Cédric Chantepie]

On Friday, 27 October 2017 20:40:06 UTC+2, Daniel Menchaca Luna wrote:

Cébric you are right, when this error occurs I shoutdown the server and that's when the cursors detect that mongo is already closed and throw the errors. (I didn't notice that I was causing the message)

I think the problem comes from the cursor that tries to get an answer but it doesn't and doesn't return an answer. When I call this same query again, the system still waits for the previous cursor to finish, and this causes this query to be blocked, until I restart the system. 

Instead of trying to fix an issue that happens in the second time after restarting the server, better to investigate the initial issue: see troubleshooting the documentation.

Then to get more help you will have to prepare a shareable reproducer to the issue can be checked.

[Daniel Menchaca Luna]

I think I found a way to solve the problem.

I changed the value of maxIdleTimeMS, rm.monitorRefreshMS and the server looks fantastic, in the past days after some 10 - 15 minutes the query didn't respond, but with the change it's been a while without fail.

I really appreciate your help, Cédric.

[Cédric Chantepie]

Such network/pool options could be used to handle specific env constraints. It should only be applied when the cause of such requirements is identified: if these are added as workaround for some env latency, better to understand why there is such latency at first (there seems the server or tcp state are not up to date).