Troubleshooting Subversion and TortoiseSVN

Simultaneously I got the complaint from our outsourced teams in India about Subversion. Suddenly they started getting this uninformative error while trying to commit or checkout the code with TortoiseSVN client from SVN.

Error: PROPFIND request failed on '/application/name'
Error: PROPFIND of '/application/name': Could not resolve hostname 'svn. companyserver.com': The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. (https:// svn.companyserver.com)

We didn't perform any changes to SVN repository lately so I'm trying to get more information from network administrators of offshore teams and have feeling that something is wrong with Cisco VPN Client in offshore. On the one hand SVN problems appeared at the same time in two different locations, on the other hand when I started to ask them to connect to others restricted application they were not able to connect too. IPCONFIG /ALL on their machines returns IP addresses in accepted VPN range, but PING or TRACEROUTE are not able to come through network.

Update 1:
I got the response from one of the networking folks onsite. The public VPN server was upgraded last week. Today the network admin audited the new VPN server and compared it with the old VPN configuration and identified only one delta - 'IPSEC over UDP' was no enabled. Now I need the confirmation from offshore partners that Subversion and TortoiseSVN issue is resolved and they have an access to other restricted resources

Update 2: SVN and TortoiseSVN works behind VPN from offshore side

Borland SilkTest 2006 drops out

Borland SilkTest 2006 drops out of the race by obvious reason. We are using SilkMeter installed on utility server to manage SilkTest licenses, so in case of unexpected outage the utility server may be down and as result we would not able to run our nice automated functional tests.

Automated post outage testing

Which tool is best suited for automated post outage testing? Right now I'm checking a few tools: SilkTest 2006, Selenium and Canoo WebTest to help with post outage verification. The goal is to automate post outage functional testing executed after a significant outage to ensure our web applications have returned to their normal state and are ready to use by client.

Borland SilkTest is powerful, functional and regression test automation tool. SilkTest has nice GUI record-and-play capabilities, own testing language, and quite costly, but we already have SilkTest license and a few experienced QA Engineers, so why don't we use Silk Test on full throttle.

Selenium and Canoo WebTest are both open source tools that existed for a few years. The former uses injected JavaScript to work within browser; the latter is based on HtmlUnit the underlying browser implementation.

Confluence and Jra OutOfMemory errors

Last year we installed Confluence into Jira Standalone. Everything was perfect during trial period on QA server, but as soon as real user started to use JIRA and Confluence both applications started to fail with this error: java.lang.OutOfMemoryError: PermGen space. The issue was fixed by setting the -XX:MaxPermSize=128m memory property in JAVA_OPTS as it properly described in 'Add Confluence EAR-WAR to JIRA Standalone' manual on Atlassian site:

Step 4 - Modify your setenv.sh/bat (ONLY IF YOU ARE RUNNING A SUN MICROSYSTEMS JVM)

1. Open JIRA's bin/setenv.sh/bat (.sh on unix, .bat on windows) in a text editor.
2. Find the line that says: "... JAVA_OPTS=... " and add -XX:MaxPermSize=128m to its end.

The Java Virtual Machine sets aside a portion of memory as the "permanent space", for objects that it never expects to have to garbage-collect. Because JIRA and Confluence are both quite large applications, it is possible that this permanent space will be filled up. Increasing the application heap size will not help, because the permanent generation size is a separate setting.

Anyway I need to consider switching to running Confluence Standalone separately during next Confluence or Jira upgrade.