[JAVA-834] Set a sane default socketTimeout Created: 23/May/13  Updated: 25/Jun/13  Resolved: 25/Jun/13

Status: Closed
Project: Java Driver
Component/s: None
Affects Version/s: 2.11.1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Jo Voordeckers Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The current default is to have no socket timeout at all, in case of a replicaset when a primary is not reachable this blocks server threads that try to write.
I would consider this a bad default, it makes a lot more sense to have a sane default of say 120s to allow the software to gracefully handle this situation, now due to the current setup, it caused thread starvation on our Glassfish server so it went completely down, while read operations should have still been possible IMHO.

Trace logs:

Thread Synchronization Statistics:
-----------------------
Number of times this thread was blocked (to enter/reenter a Monitor): 2
Number of times this thread waited for a notification (i.e. it was in WAITING or TIMED_WAITING state): 11,596
Total CPU time for this thread: 32 seconds 617,224,466 nanoseconds.
User-level CPU time for this thread: 32 seconds 617,224,466 nanoseconds.
Object Monitors currently held or requested by this thread: []
Ownable Synchronizers (e.g. ReentrantLock and ReentrantReadWriteLock) held by this thread: []
--------------------------------------------------------------------------------
Thread Execution Information:
-----------------------
Thread "http-thread-pool-8080(5)" thread-id: 56 thread-state: RUNNABLE Running in native
at: java.net.SocketInputStream.socketRead0(Native Method)
at: java.net.SocketInputStream.read(SocketInputStream.java:150)
at: java.net.SocketInputStream.read(SocketInputStream.java:121)
at: java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at: java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
at: java.io.BufferedInputStream.read(BufferedInputStream.java:334)
at: org.bson.io.Bits.readFully(Bits.java:46)
at: org.bson.io.Bits.readFully(Bits.java:33)
at: org.bson.io.Bits.readFully(Bits.java:28)
at: com.mongodb.Response.<init>(Response.java:40)
at: com.mongodb.DBPort.go(DBPort.java:124)
at: com.mongodb.DBPort.go(DBPort.java:88)
at: com.mongodb.DBPort.findOne(DBPort.java:143)
at: com.mongodb.DBPort.runCommand(DBPort.java:148)
at: com.mongodb.DBTCPConnector._checkWriteError(DBTCPConnector.java:140)
at: com.mongodb.DBTCPConnector.say(DBTCPConnector.java:183)
at: com.mongodb.DBTCPConnector.say(DBTCPConnector.java:155)
at: com.mongodb.DBApiLayer$MyCollection.update(DBApiLayer.java:349)
at: com.mongodb.DBCollection.update(DBCollection.java:177)
at: com.mongodb.DBCollection.update(DBCollection.java:208)
at: com.mongodb.DBCollection.update(DBCollection.java:220)



 Comments   
Comment by Jeffrey Yemin [ 23/May/13 ]

So set the socketTimeout=2000.

The reason we don't set a socket timeout by default is that queries can be slow if they are un-indexed and there is a lot of documents, so anything we choose would be arbitrary.

Comment by Jo Voordeckers [ 23/May/13 ]

We're not handling that many reqs, but at least with a short timeout the application has more chances of keeping up before it collapses.
120s is probably too conservative, I've set it at 10s now, but I'm no socket nor mongo expert.
Ideally I would like my reqs to fail within 2-3s, what would be the optimal MongoClientOptions for this?

Comment by Jeffrey Yemin [ 23/May/13 ]

I don't consider this a blocker since there is a simple workaround.

Won't a 120 second timeout cause thread starvation as well? How many requests/second are you handling?

Generated at Thu Feb 08 08:53:11 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.