Native Subversion Client stack trace

[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

[lpater · Accepted solution]

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.

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.

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

[Randy Bumgardner]

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.

[Conor]

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.

[Randy Bumgardner]

Thanks for the answer Conor, I appreciate the response. I think Lukasz hit the nail on the head, though...