Native Subversion Client stack trace
Asked by Randy Bumgardner:

To start, I'm using java 1.6.0_31, svn 1.6.11 on a RHEL5 machine with FishEye 2.8.0 (we're upgrading to 2.10.1 this weekend).

I'm trying to use the native svnclient as using svnkit creates too many svnserve processes on the remote machine. However, I'm seeing the following stack traces in the logs and the Subversion repos aren't starting properly:

2013-02-13 21:46:43,367 WARN - Problem starting repository  
com.cenqua.fisheye.config.ConfigException: Could not load svn-javahl: java.lang.NoClassDefFoundError-Could not initialize class org.tigris.subversion.javahl.SVNClient  
at com.cenqua.fisheye.svn.util.SvnLoader.onLoaded(SvnLoader.java:56)  
at com.cenqua.fisheye.svn.util.SvnLoader.checkLoaded(SvnLoader.java:27)  
at com.cenqua.fisheye.svn.SvnScmConfig.\<init\>(SvnScmConfig.java:133)  
at com.cenqua.fisheye.config.ConfigUtil.initScmConfig(ConfigUtil.java:77)  
at com.cenqua.fisheye.config.ConfigUtil.createRepositoryConfig(ConfigUtil.java:62)  
at com.cenqua.fisheye.config.DefaultRepositoryManager.createRepositoryConfig(DefaultRepositoryManager.java:252)  
at com.cenqua.fisheye.config.DefaultRepositoryManager.parseRepositoryConfig(DefaultRepositoryManager.java:246)  
at com.cenqua.fisheye.config.DefaultRepositoryManager.runRepository(DefaultRepositoryManager.java:294)  
at com.cenqua.fisheye.config.DefaultRepositoryManager.runRepositories(DefaultRepositoryManager.java:330)  
at com.cenqua.fisheye.config.RootConfig.startRepositories(RootConfig.java:454)  
at com.cenqua.fisheye.ctl.Run.mainImpl(Run.java:251)  
at com.cenqua.fisheye.ctl.Run.main(Run.java:76)  
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)  
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)  
at java.lang.reflect.Method.invoke(Method.java:597)  
at com.cenqua.fisheye.FishEyeCtl.mainImpl(FishEyeCtl.java:98)  
at com.cenqua.fisheye.FishEyeCtl.main(FishEyeCtl.java:41)  
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.tigris.subversion.javahl.SVNClient  
at com.cenqua.fisheye.svn.util.SvnLoader.onLoaded(SvnLoader.java:48)  
... 17 more  
2013-02-13 21:46:43,368 WARN - Could not load svn-javahl  
java.lang.NoClassDefFoundError: Could not initialize class org.tigris.subversion.javahl.SVNClient  
at com.cenqua.fisheye.svn.util.SvnLoader.onLoaded(SvnLoader.java:48)  
at com.cenqua.fisheye.svn.util.SvnLoader.checkLoaded(SvnLoader.java:27)  
at com.cenqua.fisheye.svn.SvnScmConfig.\<init\>(SvnScmConfig.java:133)  
at com.cenqua.fisheye.config.ConfigUtil.initScmConfig(ConfigUtil.java:77)  
at com.cenqua.fisheye.config.ConfigUtil.createRepositoryConfig(ConfigUtil.java:62)  
at com.cenqua.fisheye.config.DefaultRepositoryManager.createRepositoryConfig(DefaultRepositoryManager.java:252)  
at com.cenqua.fisheye.config.DefaultRepositoryManager.parseRepositoryConfig(DefaultRepositoryManager.java:246)  
at com.cenqua.fisheye.config.DefaultRepositoryManager.runRepository(DefaultRepositoryManager.java:294)  
at com.cenqua.fisheye.config.DefaultRepositoryManager.runRepositories(DefaultRepositoryManager.java:330)  
at com.cenqua.fisheye.config.RootConfig.startRepositories(RootConfig.java:454)  
at com.cenqua.fisheye.ctl.Run.mainImpl(Run.java:251)  
at com.cenqua.fisheye.ctl.Run.main(Run.java:76)  
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)  
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)  
at java.lang.reflect.Method.invoke(Method.java:597)  
at com.cenqua.fisheye.FishEyeCtl.mainImpl(FishEyeCtl.java:98)  
at com.cenqua.fisheye.FishEyeCtl.main(FishEyeCtl.java:41)

Thanks for any help on this!

-randy


Answers:
author: lpater
body: Regarding the issue of spawning too many svnserve processes, if you're using an svn+ssh connection it might be related to this SVNKit bug [http://issues.tmatesoft.com/issue/SVNKIT-319](http://issues.tmatesoft.com/issue/SVNKIT-319.).

It was fixed in svnkit 1.7.6, which is included starting from FishEye/Crucible 2.9.0, as per [https://jira.atlassian.com/browse/FE-4340](https://jira.atlassian.com/browse/FE-4340.).

If it's feasible it might be worth considering letting FishEye access the svn repository directly through the filesystem, using the file:// protocol. This should both improve the speed of indexing, and workaround the svnserve issue. For more details see <https://confluence.atlassian.com/display/FISHEYE/Improve+FishEye+scan+performance>

comments: author: Randy Bumgardner
body: I appreciate the answer Lukasz. I'll be upgrading to 2.10.1 later today, and I'll also be using svnsync to mirror the repos locally.


author: Conor
body: It does not look like you have fully configured the JavaHL native library.

In any case I don't think changing from svnkit to native javahl will make much difference to the number of svnserve processes being spawned on the server.

You could configure a throttle setting in the FishEye repository to prevent it from overloading the SVN server or bump the number of allowed svnserver processes. That requires changing the xinetd config if I remember correctly.

comments: author: Randy Bumgardner
body: Thanks for the answer Conor, I appreciate the response. I think Lukasz hit the nail on the head, though...