We’re replacing an old SVN server with SCM-Manager. We’ve created a set of batchfiles doing a backup. They work fine up to the version 2.35, maybe also to 2.37.
Since the latest version(s) we’ve experienced an error during the backup, the connection is closed and the backup of this repository is aborted. As workarround we do a restart of the service before starting the backup process (shutdown, wait for 30 seconds, startup, wait for 90 seconds, start the backup). But even then sometimes this error occur. Before adding the restart of the service, all repositories have been affected. After adding the restart, it’s random which repository export fails.
The environment is:
The host is a “Windows 2019 Server Datacenter”
The used Java version is “Java™ SE Runtime Environment (build 1.8.0_341-b10)”
The SVN command line tools are “svn, version 1.14.2 (r1899510) compiled Apr 9 2022, 14:18:14 on x86-microsoft-windows”
We’re using the LDAP plugin to connect to our active directory.
The major admin account is a local account.
We’re using port 80 for UI and SVN.
We don’t use https.
The batchfiles are running locally on the host.
The process in the batch file is:
Loop over all server repository directories (SCM_HOME/repositories).
Fiddle out namespace, name and type of the metadata.xml.
Do an export of the repository using svnrdump.
The recieved error is:
svnrdump: E730053: Error running context: An established connection was aborted by the software in your host machine.
The messages in scm-server.wrapper.log and the scm-server.0.err.log of the startup looking fine, nothing suspisios there. Also the messages during the export - except one in scm-server.0.err.log:
2022-09-02 20:30:01.756:WARN:oejs.HttpChannel:qtp1869997857-49: handleException /scm/repo/svn/XXXXjava.io.IOException: Cannot flush a closed output stream
Searching the internet for the SVN error points out that this is:
Your workflow sounds pretty complacated and could be easier for sure. Why do you use svnrdump instead the repository export from scm-manager?
For example you could use the scm-manager script plugin to get all repositories (or only all the svn repos) and then trigger the export for all of them. After this is done copy the files to your backup destination. Would you try this solution?
For further investigation in your mentioned error we need more information like the whole stacktrace and your actual batchfiles so we can figured out why the connection is gone.
I have seen the scripting plugin. However, I have not found any documentation on the scripting language used. Trying to generate a list of repositories ended in a stack trace. This was despite copying the code exactly from the examples. Additionally, I didn’t find a way to run scripts on a timed basis. Maybe you can handle it if you know and understand Java - unfortunately that’s not the case for me. If there is documentation somewhere that even a Java noob can understand, then I could possibly set it up with that. Until then, I’ll use what’s old but proven. The export itself is not complicated, it’s one command. Getting the data from the XML file is a bit more complicated.
Can you please tell me how I can upload the files you requested? I was not able to attach a zip file here.
Download and unzip the attachment. The scripts are designed to run locally on the server. You have to adjust the variable SCM_REPOSITORIES in dump_all_repos.bat to SCM_HOME/repositories. Then you can call the scripts by the following statement (keep in mind you need to have admin privileges because of the service restart):
Take care that the xml.exe is in the same path as the batch files. Otherwise the script will not be able to extract information from the metadata.xml. The result will be dump files for each repository in the same path as the batch files are. There are still more options like zipping or parallel export but they are not relevant for this problem.
Uhm, I forgot an important hint: The problem occurs only if the service is NOT restarted. To disable the service restart, you have to comment line 255 in dump_all_repos.bat. Otherwise the service will be restarted each time the backup is executed. I’m sorry for that and apologize for any inconvenience.
thank you for providing your scripts. And we had a look at them and to speak frankly we cannot support you in debugging your script. It’s simply a lot of work for us to go through each line… and this is something we unfortunately cannot cover with the free Community Support.
I am sorry but I hope this is understandable. We are a small open source project and are relying on customers who are paying for new feature development and support.
If you want to backup your repositories we can recommend to use the Cloudogu EcoSystem which is providing a backup & restore mechanism. Backup & Restore with Cloudogu Ecosystem
Thank you very much for your suggestion. The Cloudogu cloud was a point we were thinking about. But for various reasons there was a decision not to use it.
Thanks also for the quick look at the scripts - I understand that they are not easy to debug. At least it is very old fashioned batch
I have now updated to the latest version 2.39.0 and will check if the problem still occurs without restarting the service. If not, everything is fine. If it does, we have the solution with restarting the service, which is also acceptable to us.
Thank you for this great software and your support.
after longer observation it seems that the error no longer occurs. At least in version 2.39 and 2.39.1 the problem did not occur anymore. We are now using our backup scripts without restarting the SCM manager.
