Native Subversion Client stack trace

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

2 answers

1 accepted

Accepted Answer
0 votes
Lukasz Pater Atlassian Team Feb 13, 2013

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

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.

0 votes

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.

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

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Monday in Jira Ops

Jira Ops Early Access Program Update #1: Announcing our next feature and a new integration

Thanks for signing up for Jira Ops! I’m Matt Ryall, leader for the Jira Ops product team at Atlassian. Since this is a brand new product, we’ll be delivering improvements quickly and sharing updates...

344 views 0 8
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you