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

Terry Tam commented on THRIFT-2293:
-----------------------------------

Hi,

    Thanks community for finding the fix for this.  While testing and reviewing 
the patch, we noticed the createSSLContext() allows for the condition where 
both the keystore and truststore is set:

     if (params.isKeyStoreSet && params.isTrustStoreSet) {
        ctx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
      }

For the case above where both the keystore and truststore parameters are set,  
the truststore file input stream should still leak (depend on GC) since it was 
not implicitly closed before the reference "fin" is reused for the keystore.  
We got around this by allocating a different file input stream reference for 
the keystore and truststore and closed both in the finally block.

Best Regards, T.

> TSSLTransportFactory.createSSLContext() leaves files open
> ---------------------------------------------------------
>
>                 Key: THRIFT-2293
>                 URL: https://issues.apache.org/jira/browse/THRIFT-2293
>             Project: Thrift
>          Issue Type: Bug
>          Components: Java - Library
>    Affects Versions: 0.9.1
>         Environment: Windows 7, Java 7
>            Reporter: Andreas Sjöholm
>            Assignee: Roger Meier
>            Priority: Minor
>              Labels: file, leak
>             Fix For: 0.9.2
>
>         Attachments: TSSLTransportFactory.diff
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Even though my thrift server is shutdown and (perhaps?) GC'ed, 
> the keystore file used is still locked by the VM.
> In TSSLTransportFactory.createSSLContext() i see  
> ks.load(new FileInputStream(params.keyStore), params.keyPass.toCharArray());
> The FileInputStreams are never closed, which they should.
> Or is this done deliberately?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to