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: | |
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
[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.