3

I'm using an sharded-cluster(Mongo version 2.4.1) with a java application. After a specific time (10 minutes or more) I got the following exception:

com.mongodb.MongoException$Network: Read operation to server cs-mongo-mongo-west-t:3306 failed on database mdb
    at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:253)
    at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:216)
    at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:288)
    at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:273)
    at com.mongodb.DBCursor._check(DBCursor.java:368)
    at com.mongodb.DBCursor._hasNext(DBCursor.java:459)
    at com.mongodb.DBCursor._fill(DBCursor.java:518)
    at com.mongodb.DBCursor.toArray(DBCursor.java:553)
    at com.mongodb.DBCursor.toArray(DBCursor.java:542)
    at com.pribas.messagesdb.impl.GetMessagesDBHandlerImpl.handleRequest(GetMessagesDBHandlerImpl.java:86)
    at com.pribas.messagesdb.impl.MessagesDBHandlerImpl.handleRequest(MessagesDBHandlerImpl.java:37)
    at com.pribas.messagesdb.service.MessageServlet.processRequest(MessageServlet.java:161)
    at com.pribas.messagesdb.service.MessageServlet.doPost(MessageServlet.java:86)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1008)
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

Is there a way to disable this timeout of the cursor within the sharded-cluster or within the config-file? At the moment this issue can only be solved by restarting the application so it establishes a new connection.

Thank you very much, Daniel

1

There is a 10 minute time out for inactive cursors, and it can be overridden, but be careful: "immortal" cursors can become a problem if enough of them accumulate on the server over time. So, it would be a good idea to close your cursor correctly from time to time and avoid that if possible. You should also make sure that it is in fact the cursor timeout that is hurting you here (and not a TCP timeout for example).

The option to turn off the timeout involves basically setting the noTimeout flag. In Java that means using addOption on the cursor and setting QUERYOPTION_NOTIMEOUT.

  • 1
    Hi Adam, it was indeed a TCP timeout caused by our firewalls. This problem is solved now but thank you for your help :) – DanielH Jul 4 '14 at 14:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.