Crucible connection VisualSVN error SSL

[David Schmidt]

Hey There,

we have a weird issue with our Crucible installation (4.2.1) and VisualSVN server.

Everytime a revision gets added on VisualSVN we get the following on Crucible:

Tue Mar 07 10:21:55 GMT+100 2017: Repository paused due to error com.cenqua.fisheye.rep.RepositoryClientException: java.lang.IllegalStateException: Can't overwrite cause with org.tmatesoft.svn.core.SVNException: svn: E175002: SSL peer shut down incorrectly svn: E175002: REPORT request failed on '/svn/Product/!svn/vcc/default' java.lang.IllegalStateException: Can't overwrite cause with org.tmatesoft.svn.core.SVNException: svn: E175002: SSL peer shut down incorrectly svn: E175002: REPORT request failed on '/svn/Product/!svn/vcc/default' org.apache.subversion.javahl.ClientException: svn: E175002: SSL peer shut down incorrectly svn: E175002: REPORT request failed on '/svn/Product/!svn/vcc/default'

Any idea what this could be? There are no other issues on our Nginx reverse proxy, also timeouts are set to hours of time.

Thanks
David

[David Schmidt]

Hi Ola,

I am sorry I can't help here anymore. I have been off due to sickness almost 1 year.

It might have been solved or worked around somehow, not sure!

Best regards

David

[Ola Presterud]

Hi David,

Did you find a solution to this?

I have just ran across this issue, but might have had it for a while. Seems OK when Fisheye (we do not have the "full" Crucible suite) only adds changes to a repo, but when I do a full "re-index" this error will appear exactly as you describe.

Upgraded to latest versions of both Fisheye and VisualSVN Server, but no improvment. We do not have any proxies, both servies run on separate servers.

Thanks,

Ola

[Mikolaj Zyromski]

Hi David,

It's really hard to say what's the problem here. Such errors are usually caused by proxy server closing connections prematurely (https://confluence.atlassian.com/fishkb/fisheye-crucible-svn-e175002-ssl-peer-shut-down-incorrectly-838560862.html), but you said you've increased timeouts, so that might not be the case here.

My advise would be for you to enable DEBUG logging (Administration > Global Settings > Server > Debug logging), wait for the problem to reappear, generate a support ZIP (Administration > System Settings > Support Tools) and contact Atlassian via support.atlassian.com with a problem description and the support ZIP attached. 

Regards,

Mikołaj Żyromski