Fortress and Visual Studio Stops Responding

[markreyn]

Dear Support

My Fortress client and Visual Studio 2008 freeze multiple times a day.

I am using the following setup
- Fortress server (version 1.1.3.18336.) hosted on Windows XP
- Fortress client (version 1.1.3.18336) hosted on Vista Ultimate 64 bit
- Connecting to server via Cisco ssl vpn client.

Visual Studio intermittently stops responding when connecting to projects on start-up, checking files in and checking files out and undoing file checkouts.
Crashing and restarting visual studio get everything working again most of the time.
The Fortress client can also stop responding when connecting, and will usually crash after deleting a few folders from the repository

Please help!!

Mark

[jeremy_sg]

This is very weird. It would be helpful is you sent us your Vault client log, which will give more information about this issue. Do you get this issue if you close the Fortress Item Tracking view and restart Visual Studio?

[Darren Thompson]

I get a very similar situation to Mark.

I also have the latest versions of Fortress and connect to the server via a VPN connection.

However, for me all this started to go nuts after installing VS2008 SP1, at first I just assumed it was to do with it but having noticed Mark's post I thought I would chime in as well.

Also I find that VS2008 crashes out randomly after making a batch of checkins, when this happens some or all of the files that were checked in are left with the "Needs merge" state.

I also don't usually use the Item Tracking view.

I'll also enabled client logging and get back to you if something comes up.

Darren

[jeremy_sg]

Thanks for the additional information. I'd like to gather as much info about this as we can, so we can fix the issue immediately. It's probable that if there was a crash we logged information in the log file even with debug logging turned off, so it's worth it to check the log file immediately after a crash.

[markreyn]

Hi Jeremy

Thanks for your help with this.

The Work Item Tracking view wasn't activated for a few weeks and the crashing still occurred.

I enabled work item tracking this morning, everything worked fine for a few hours, then when I attempted to undo a checkout a little later on all vault type commands were disabled, but work item tracking worked without any problems. I tried to close visual studio, it stopped responding. All worked ok on restart

I have two log files to send you VaultGUIClient.txt and VaultVsipClient2008.txt and a list of some times and dates of when the client crashed.
How do I upload/email these?
I have enabled verbose logging so I may have some more extensive data for you by the end of the day.

Regards
Mark

[jeremy_sg]

Please email them to support at sourcegear.com ATTN: jeremy with a link to this thread.

hs: 214015

[markreyn]

Hi Jeremy

I've been persisting with this problem and noticed the error more in the afternoon.
I've done some checks on the broadband line and discovered the speed sometimes drops to near ISDN/Dialup.
My client is in discussion with their ISP and is planning to migrate to another supplier.

I'm assuming the slow connection speed will affect vault. My Question is, will the sudden connection performance drop cause the 15 minutes of no response from vault/vs? it seems to always be aproximately 15 minutes before it comes back to life. Is there a setting that affects this?

Regards
Mark

[jeremy_sg]

Mark,

When we were discussing this offline, you said that your server was on Vista, and I suspected that the Vista connection limit was being reached, causing the client's requests to hang or be lost. Is that still the case?

As for your question of network drops, it appeared from your logs that the following would happen

Client: start server request (ListCloaks, for example)
Server: start ListCloaks
Server: return from ListCloaks

And then the client would never get the results from the ListCloaks method, and you would have to kill it. It's possible that the results are being lost completely due to some network issue.

Also, I never heard back from you. Did setting HTTP keep-alives help you?