Bug #37981 Cannot set socketTimeout (read timeout defaults to 0/infinite)
Submitted: 9 Jul 2008 5:59 Modified: 11 Jul 2008 9:24
Reporter: Ken Johanson Email Updates:
Status: Not a Bug Impact on me:
None 
Category:Connector / J Severity:S3 (Non-critical)
Version:mysql-connector-java-5.1.6 OS:Any
Assigned to: CPU Architecture:Any

[9 Jul 2008 5:59] Ken Johanson
Description:
The value sent to:

this.mysqlConnection.setSoTimeout(socketTimeout);

(com.mysql.jdbc.MysqlIO line 283)

is always 0; setting the socketTimeout=30000 argument on the connection URL does not change this:

jdbc:mysql://127.0.0.1/test?dontTrackOpenResources=true&useTimezone=true&serverTimezone=PST&zeroDateTimeBehavior=convertToNull&characterEncoding=utf-8&user=myuser&password=mypass&socketTimeout=30000

I am marking this 'serious' because on a production system, the inability to detect a timeout (such as when the server has a small timeout config and the socket-close is not received) will cause a connection to deadlock it's thread; in a web environment with connection pools this can cause server-thread pools to be exhausted; i.e the site is un-usable. I can can provide concrete test/example case/server and client-code to show how damaging this problem is...

How to repeat:
Set the value to a small (5000 ms) value, then run a query with delayed response, or against a connection that the server has expired. Thread will block indefinitely.

Suggested fix:
Additionally, should not Statement.setQueryTimeout(int secs) also set this value for the duration of the Statement's execution? It does not currently.
[9 Jul 2008 10:56] Sveta Smirnova
Thank you for the report.

I can not repeat described behavior with following test case:

import testsuite.BaseTestCase;

public class bug37981 extends BaseTestCase {
	
	public bug37981(String name) {
		super(name);
	}

	public static void main(String[] args) {
		junit.textui.TestRunner.run(bug37981.class);
	}

	public void testBug37570() throws Exception {
		try {
			this.stmt.setQueryTimeout(3);
			this.stmt.execute("select sleep(10)");
		} finally {
	    	closeMemberJDBCResources();
		}
	}
	
}

Also specifying timeout in connection options works fine for me too.

Please provide example of code bug is repeatable with.
[11 Jul 2008 5:10] Ken Johanson
My assessment that the URL params for socketTimeout was incorrect, due to middleware improperly decoding the '&' encoded in XML-=stored URL configs. I suppose this could be a request for enhancements; that the driver may help if it throws/logs a warning when URL-strings contain foo=bar&aye=bee. Hmm, maybe better left for middleware (con pools etc).

Anyway I do feel that the other point, about setQueryTimeout, should set the value of SO_TIMEOUT because when a connection is invalid but not detected, and no socketTimeout was set, some people might consider this a logical means to otherwise un-lock that thread.

Mark this closed / NAB if you like, and I'll re-write setQueryTimeout as an RFE.

Thank you and apologies,

Ken
[11 Jul 2008 9:24] Sveta Smirnova
Thank you for the feedback.

Closed as "Not a Bug" because last comment.