[ https://issues.apache.org/jira/browse/DRILL-5090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15713647#comment-15713647 ]
Paul Rogers edited comment on DRILL-5090 at 12/2/16 3:46 AM: ------------------------------------------------------------- Further tests show that the {{StoragePluginRegistryImpl.createPlugins()}} method does not load the test bootstrap plugins because the local plugin directory already exists: {{/tmp/drill/sys.storage_plugins}}. Not sure how this could have ever worked if this directory exists and has contents: {code} cp.sys.drill dfs.sys.drill s3.sys.drill {code} These may have been created when running other unit tests. How are they being cleaned up for folks for whom the JDBC unit tests succeed? Interesting fact: the storage plugin thinks the local storage path is {{/tmp/drill/sys.storage_plugins}} while {{TestUtilities.createTempDir();}} in the JDBC driver test code sets the temp dir to {{/var/folders/xyz/abc}} where xyz and abc are random strings. was (Author: paul-rogers): Further tests show that the {{StoragePluginRegistryImpl.createPlugins()}} method does not load the test bootstrap plugins because the local plugin directory already exists: {{/tmp/drill/sys.storage_plugins}}. Not sure how this could have ever worked if this directory exists and has contents: {code} cp.sys.drill dfs.sys.drill s3.sys.drill {code} These may have been created when running other unit tests. How are they being cleaned up for folks for whom the JDBC unit tests succeed? > JDBC tests silently ignore failure to set up test storage plugin > ---------------------------------------------------------------- > > Key: DRILL-5090 > URL: https://issues.apache.org/jira/browse/DRILL-5090 > Project: Apache Drill > Issue Type: Bug > Affects Versions: 1.8.0 > Reporter: Paul Rogers > > Run the {{TestJDBCQuery}} test cases using Java 8. The tests will fail with > error such as: > {code} > VALIDATION ERROR ... > Current default schema: No default schema selected > {code} > The problem is that the tests try to set up a test schema, but fail. The code > that does this setup just silently ignores the error: > {code} > try { > TestUtilities.updateDfsTestTmpSchemaLocation(pluginRegistry, > tmpDirPath); > TestUtilities.makeDfsTmpSchemaImmutable(pluginRegistry); > } > } catch(Throwable e) { > // ... This is unlikely to > // happen, but just a safeguard to avoid failing user applications. > logger.warn("Failed to update tmp schema locations. This step is purely > for testing purpose. " + > "Shouldn't be seen in production code."); > // Ignore the error and go with defaults > } > {code} > The reason that the error is ignored is that the JDBC driver _itself_ > contains test code in the form of the following check: > {code} > if (props != null && > "true".equalsIgnoreCase(props.getProperty("drillJDBCUnitTests"))) { > {code} > That is, the JDBC driver itself contains the code needed to set up the test > schemas. This means that test code is shipped in production. And, we must > handle the failure gracefully in case the user set the property in production. > Requested changes: > * Find a way to do test setup without including test code in JDBC. > * If test setup fails, issue a fatal error to direct the developer to the > actual problem. > And, of course, fix the Java 8 error so that the tests pass. Fixing that > error is a separate issue. If things were to fail again, we need the above > fixes to avoid wasting developer's time finding the problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)