[ https://issues.apache.org/jira/browse/PHOENIX-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908918#comment-14908918 ]
James Taylor commented on PHOENIX-2285: --------------------------------------- +1. Looks great, [~jfernando_sfdc]. One minor nit, remove the throw SQLException here: {code} + public int getQueryTimeoutInMillis() throws SQLException { + return queryTimeoutMillis; + } {code} > phoenix.query.timeoutMs doesn't allow callers to set the timeout to less than > 1 second > -------------------------------------------------------------------------------------- > > Key: PHOENIX-2285 > URL: https://issues.apache.org/jira/browse/PHOENIX-2285 > Project: Phoenix > Issue Type: Bug > Affects Versions: 4.5.2 > Reporter: Jan Fernando > Assignee: Jan Fernando > Attachments: PHOENIX-2285-v1.txt > > > When creating a Phoenix JDBC connection I have a use case where I want to > override the default value of phoenix.query.timeoutMs to a value of 200 ms. > Currently if you set phoenix.query.timeoutMs to less than 1000 ms, the > timeout gets rounded up to 1000ms. This is because in > PhoenixStatement.getDefaultQueryTimeout() we convert the value of > phoenix.query.timeoutMs to seconds in order to be compliant with JDBC. In > BaseResultIterators we then convert it back to millis. As a result of the > conversion we loose the millisecond fidelity. > A possible solution is to store the timeout value stored on the > PhoenixStatement in both seconds and milliseconds. Then, in > BaseResultIterators when we read the value from the statement we can check if > the value exists in millisecond fidelity and if so use that value. Otherwise > we would use the value in second granularity and convert. > This would allow Phoenix to remain JDBC compatible with second level > granularity for setting query timeouts on statements, but allow millisecond > granularity of timeouts by explicitly setting phoenix.query.timeoutMs on > connection properties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)