[ 
https://issues.apache.org/jira/browse/HIVE-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504814#comment-13504814
 ] 

Kevin Wilfong commented on HIVE-3709:
-------------------------------------

It looks like that fixes the issue on a single thread where it ends up reading 
from the same InputStream repeatedly, which is why I overrode the close method 
to reset the InputStream.

It does not look like it will fix the multi-threaded issue.  If two threads get 
Configuration objects constructed using the copy constructor, and hence get the 
same InputStream since the resources are not cloned themselves, and 
loadResources has not been called before the copy constructor, it looks like it 
could be possible that both threads call loadResources at about the same time 
causing the issues Carl was seeing in TestHiveServerSessions.
                
> Stop storing default ConfVars in temp file
> ------------------------------------------
>
>                 Key: HIVE-3709
>                 URL: https://issues.apache.org/jira/browse/HIVE-3709
>             Project: Hive
>          Issue Type: Improvement
>          Components: Configuration
>    Affects Versions: 0.10.0
>            Reporter: Kevin Wilfong
>            Assignee: Kevin Wilfong
>         Attachments: HIVE-3709.1.patch.txt, HIVE-3709.2.patch.txt, 
> HIVE-3709.3.patch.txt
>
>
> To work around issues with Hadoop's Configuration object, specifically it's 
> addResource(InputStream), default configurations are written to a temp file 
> (I think HIVE-2362 introduced this).
> This, however, introduces the problem that once that file is deleted from 
> /tmp the client crashes.  This is particularly problematic for long running 
> services like the metastore server.
> Writing a custom InputStream to deal with the problems in the Configuration 
> object should provide a work around, which does not introduce a time bomb 
> into Hive.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to