Disabling server network interface causes client login hang.

[jfreidin]

We're in the process of upgrading from SOS/VSS to Vault. One of the main reasons for the upgrade is better connection reliability of the Vault client. One of the first tests I ran was to disable the network interface on the Vault server and then try to connect from the client. If I try to close the client before the 90 sec. connection timeout, it never times out after that. Also, the GUI doesn't repaint properly when I switch windows. If the server eventually responds, then a dialog does appear and the client closes normally.

But if the server doesn't respond, the client waits indefinitely and I have to kill it with the task manager. I haven't successfully reproduced the problem using a profile during login.

I have a 25 MB zipped dump file of the client version 3.5.1 (4786). It is too big to attach (I get "No Post Mode Specified"). Could you take a look at it and get back to me with the cause of the hang?

[lbauer]

The cause of the hang is that there is no network connection.

The Vault client sends a web request, which can take 2 hours to timeout. So if the client can't contact the server, the client appears to be hung. Because of the way .NET works, you can't really kill a request.

Nearly all Vault client hangs are due to network issues specific to the user's environment, rather than a defect in Vault. These need to be dealt with on a case-by-case basis.

For users experiencing Vault client hangs, please make sure your network connection is intact. If the problem persists, contact support@sourcegear.com.

[jfreidin]

Web browsers don't hang when the connection to the server fails. I don't know what else I can say to convince you that this is a real problem and deserves the attention of a developer.

My hope is that someone will take a look at my dump file, realize there is a programming error of some sort and fix it. Let me know how I can get the dump file to you.

At the very least if the connection thread is hung, other threads should be able to repaint the GUI and respond to the exit window command. Ideally, it should time out within a reasonable period of time and give an appropriate message.

[jclausius]

One of the main reasons for the upgrade is supposedly better connection reliability in the Vault client.

A better description is to say Vault communicates differently than SourceOffSite.

SourceOffSite requires a persistent network connection. If the connection to the SOS Server is not reliable, you will have problems because the connection keeps going down.

Vault communicates through HTTP Web Requests. In order to gain a bit of performance, the Vault client always requests HTTP Keep-Alives. What this does is create try to create a persistent connection (much like SOS) because that is the optimal way to communicate. However, if your network connection to the server is spotty, then you should look at using IIS 6.0 and the settings their to disable HTTP Keep-Alives.

One of the first tests I ran was to disable the network interface on the Vault server and then try to connect from the client. I've found that after a few tries, the client may hang. Then I have to kill it with the task manager.

I ran that test here. The client tries to connect for about three minutes and then gives up with the following error:

Code: Select all

Unable to connect to http://192.168.94.102/VaultService.  No server was found at the specified URL.  Please verify your network settings using the Options dialog under the Tools menu in the Vault GUI Client.  Web Exception: The underlying connection was closed: Unable to connect to the remote server.

After six attempts, my Vault client is still responsive. It could be a difference in .Net Frameworks. I'm using .Net Framework 1.1 (SP1).

I have a 25 MB zipped dump file of my hung client, version 3.5.1 (4786). It is too big to attach (I get "No Post Mode Specified). Could you take a look at it and get back to me with the cause of the hang?

If you want, you can FTP it anonymously to our FTP Server (ftp.sourcegear.com). Place it in the incoming/ folder, and send me a private message with the file name.

[jfreidin]

My initial report needs some clarification:

1) The hang only occurs if you attempt close Vault client while it's trying to connect to a server that isn't responding. The client never works after that and you have to kill it with task manager.

2) The Tools -> Abort Current Operation doesn't help in this circumstance.

3) If you wait for the 90 second timeout, the error dialog appears and you can retry or close the client without a problem.

[jclausius]

I've verified that after trying to close the Vault client while it is trying to find a Vault server which does not exist does cause a problem within the Vault client.

There is probably a deadlock condition going on while the main UI thread waits for the communication thread to terminate, but the communication thread is sending events to the main UI thread that an error occurred.

I've logged a bug regarding the scenario.

[jfreidin]

My clarification needs further clarification:

1) The problem only occurs if you attempt to close Vault client while it's trying to connect to a server that isn't responding. The client waits indefinitely for the server to respond after that. If the server eventually responds, a timeout dialog appears, and upon closing that, the client closes normally. It never times out if the server doesn't respond. If you want to close Vault client before the server responds, you then have to kill it with the task manager.

2) The Tools -> Abort Current Operation doesn't help in this circumstance.

3) If you wait for the 90 second timeout, the error dialog appears and you can retry or close the client without a problem.