[
https://issues.apache.org/jira/browse/HIVE-13523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15246337#comment-15246337
]
Thomas Poepping commented on HIVE-13523:
----------------------------------------
[~prasanth_j]
tl;dr on my local environment, every test that was reported to fail here
succeeded ; both with and without my change. And I agree that none of these
tests seem related. What's our next step?
Of the 42 tests that failed, around half (20) were because of "connection
refused", which is a failure that we've been seeing consistently in the
automatic test runs. However, to be sure, I'll run each failed test with and
without my change
TestDbTxnManager succeeds for me both with and without my change
TestClientSideAuthorizationProvider succeeds
TestCommands succeeds
TestDbNotificationListener succeeds
TestExtendedAcls succeeds
TestFolderPermissions succeeds
TestHBaseImport succeeds
TestHiveMetaStorePartitionSpecs succeeds
TestJdbcWithDBTokenStore succeeds
TestMetastoreAuthorizationProvider succeeds
TestStorageBasedClientSideAuthorizationProvider succeeds
TestStorageBasedMetastoreAuthorizationDrops succeeds
TestStorageBasedMetastoreAuthorizationProvider succeeds
TestStorageBasedMetastoreAuthorizationReads succeeds
TestHadoopAuthBridge23 succeeds
TestHS2ImpersonationWithRemoteMS succeeds
TestMultiAuthorizationPreEventListener succeeds
TestStorageBasedMetastoreAuthorizationProviderWithACL succeeds
TestCliDriver with partition_coltype_literals.q succeeds
TestCliDriver with index_bitmap3.q succeeds
> Fix connection leak in ORC RecordReader and refactor for unit testing
> ---------------------------------------------------------------------
>
> Key: HIVE-13523
> URL: https://issues.apache.org/jira/browse/HIVE-13523
> Project: Hive
> Issue Type: Bug
> Components: ORC
> Affects Versions: 2.0.0
> Reporter: Thomas Poepping
> Assignee: Thomas Poepping
> Attachments: HIVE-13523.patch
>
>
> In RecordReaderImpl, a MetadataReaderImpl object was being created (opening a
> file), but never closed, causing a leak. This change closes the Metadata
> object in RecordReaderImpl, and does substantial refactoring to make
> RecordReaderImpl testable:
> * Created DataReaderFactory and MetadataReaderFactory (plus default
> implementations) so that the create() methods can be mocked to verify that
> the objects are actually closed in RecordReaderImpl.close()
> * Created MetadataReaderProperties and DataReaderProperties to clean up
> argument lists, making code more readable
> * Created a builder() for RecordReaderImpl to make the code more readable
> * DataReader and MetadataReader now extend closeable (there was no reason
> for them not to in the first place) so I can use the guava Closer interface:
> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/io/Closer.html
> * Use the Closer interface to guarantee that regardless of if either close()
> call fails, both will be attempted (preventing further potential leaks)
> * Create builders for MetadataReaderProperties, DataReaderProperties, and
> RecordReaderImpl to help with code readability
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
