Hello Ben,

Thank you for sharing your concern. However, with HTTP the [ssl]socket is
reused for each subsequent HTTP request, so I do not think SSLContext is
recreated for each request. Whether connection is persistent or not depends
on HTTP Keep-Alive header value (and that depends on the server settings),
so I think that SSLContext might be created a few times during SVN
operation like update or getDir, but it should not happen for each HTTP
request.

Do you experience different behavior?

Thanks!

Alexander Kitaev,
TMate Software,
http://subgit.com/ - Svn to Git Migration!
http://svnkit.com/ - Java [Sub]Versioning Library!
http://hg4j.com/ - Java Mercurial Library!
http://sqljet.com/ - Java SQLite Library!

On Thu, Oct 8, 2015 at 1:31 AM, Ben Castellucci <ben...@gmail.com> wrote:

> Bump...
>
> Any thoughts about making a change like this?
> On Sep 30, 2015 10:46 AM, "Ben Castellucci" <ben...@gmail.com> wrote:
>
>> Greetings.
>>
>> This may indeed be the wrong place to bring this up. If so, could someone
>> kindly direct me to the right place (be that a feature request or issue or
>> whatever)?
>>
>> Also, I will disclose I am not an expert in any way regarding how Java
>> handles SSL communication so I may be completely off base here.
>>
>> However, I was perusing the source and noticed in SVNSocketFactory.java,
>> method createSSLContext(), it looks like a brand new SSLContext object is
>> created every time. This ends up that the entire SSL handshake must be
>> repeated for each and every SVN operation because the built in support for
>> session resume is not able to function.
>>
>> If the SSLContext object were stored in some way, possibly a static
>> variable or something, that should allow SSL session resume which would
>> avoid this issue.
>>
>> I realize this would have no benefit for command line as it's a new JVM
>> each time, however it would benefit GUI clients immensely. It would greatly
>> speed up operations and make using SVN over SSL orders of magnitude more
>> pleasant.
>>
>> Let me know any thoughts.
>>
>> Thanks!
>> Ben
>>
>

Reply via email to