There is an error in XML document error during login
Moderator: SourceGear
There is an error in XML document error during login
We are experiencing this ("There is an error in XML document (1,xxxxxxx)") error for several users during Vault login. As a result, these users cannot even login to Vault. It only seems to be an issue for users that are not in the same location as the server (i.e. in different states/countries). The problem seems to be getting worse.
Vault version: 4.0.5.15922
- Jeff
Vault version: 4.0.5.15922
- Jeff
What is the OS being used?
Was it working previously?
Have you checked your Vault Server Log for errors?
In this thread here, There is an error in XML Document, it turned out to be a routing issue for that user. You will want to check out the suggestions there as well.
Was it working previously?
Have you checked your Vault Server Log for errors?
In this thread here, There is an error in XML Document, it turned out to be a routing issue for that user. You will want to check out the suggestions there as well.
The Vault server is 2003 and the clients are all XP.What is the OS being used?
It used to work fine.Was it working previously?
The server log doesn't have an entry since the clients are not able to complete the login process.Have you checked your Vault Server Log for errors?
I had seen that thread, but it seemed to be Vista-related.In this thread here, There is an error in XML Document, it turned out to be a routing issue for that user. You will want to check out the suggestions there as well.
- Jeff
In the start it focused on that, but it turned to the router towards the end.
Is it a case of where no computers in your location can connect?
I think if there's an attempt at a login and it fails, there should be something written to the server log, but if nothing at all is written, I would suspect that the communication never reaches it at all.
Do you know of a date when it started failing and giving you this error?
Did any updates or network changes happen over the weekend?
Is it a case of where no computers in your location can connect?
I think if there's an attempt at a login and it fails, there should be something written to the server log, but if nothing at all is written, I would suspect that the communication never reaches it at all.
Do you know of a date when it started failing and giving you this error?
Did any updates or network changes happen over the weekend?
Actually all users at my location are fine since the server is here as well. In the other locations it is not all users failing. It started with one or two but now there are reports of at least four failing.Is it a case of where no computers in your location can connect?
I will check the server log again tomorrow (once the server log is re-enabled - it turns off "all by itself" sometimes).I think if there's an attempt at a login and it fails, there should be something written to the server log, but if nothing at all is written, I would suspect that the communication never reaches it at all.
I don't know an exact date, but I know some users have had this issue for a couple of weeks. I'll check with I/T about network updates.Do you know of a date when it started failing and giving you this error?
Did any updates or network changes happen over the weekend?
I had one user try turning off the proxy which worked for a few days, but now that user is failing again.
Would the client log provide any useful information?
- Jeff
Starting client logging can't hurt if you wish. It still seems like it could be caused by a networking problem though. Something is interfering with the network data sent between Vault client and server.
Are the remote users that are having a problem all in the same location?
Do some remote users still work fine? If all locations have a problem, then the problem could be server side of the network, and that's where you'd want to check the routers and firewalls. If all the client problems are in one location, then you may wish to check their side as well.
Try using an IP address instead of the computer's name to connect and see if that makes a difference?
You may want to check the MTU on the Vault server/clients. There are a few tools that help with this, but we haven't checked them out:
"Dr. TCP" (http://www.dslreports.com/faq/578)
Also, http://help.expedient.com/broadband/mtu.shtml
Are the remote users that are having a problem all in the same location?
Do some remote users still work fine? If all locations have a problem, then the problem could be server side of the network, and that's where you'd want to check the routers and firewalls. If all the client problems are in one location, then you may wish to check their side as well.
Try using an IP address instead of the computer's name to connect and see if that makes a difference?
You may want to check the MTU on the Vault server/clients. There are a few tools that help with this, but we haven't checked them out:
"Dr. TCP" (http://www.dslreports.com/faq/578)
Also, http://help.expedient.com/broadband/mtu.shtml
We have had problems at at least two locations. I don't know if the second location is having the problem at login or when choosing a repository, but I'll find out.Are the remote users that are having a problem all in the same location?
Yes, the majority of the remote users work fine.....so far.Do some remote users still work fine?
I will have them try that.Try using an IP address instead of the computer's name to connect and see if that makes a difference?
Update:
One of our locations (the one with the most Vault troubles) is working much better after frequent cache deletions.
At a different location - that has also had problems - a user turned on client logging and got the following results when trying to open different repositories:
"Good repository":
3/4/2008 1:33:21 PM <refresh>: [GUIClientWorkerThread:1648] Calling client service GetRepositoryStructure(26, 112155, -1, 1/22/2008 11:02:45 AM, ref, ref, ref)
3/4/2008 1:33:21 PM <refresh>: [GUIClientWorkerThread:1648] Client service GetRepositoryStructure returned: dtLatestCheck 1/22/2008 11:02:45 AM, nReturnDestRevision 112155, rd not null True
"Bad repository":
3/4/2008 1:34:22 PM <refresh>: [GUIClientWorkerThread:3380] Calling client service GetRepositoryStructure(7, 0, -1, 7/1/1850 12:00:00 AM, ref, ref, ref)
3/4/2008 1:34:49 PM <refresh>: [GUIClientWorkerThread:3380] GetRepositoryStructure caught exception: There is an error in XML document (1, 1944338).
In the "bad repository", the date passed is 7/1/1850, which looks a bit suspicious.
- Jeff
One of our locations (the one with the most Vault troubles) is working much better after frequent cache deletions.
At a different location - that has also had problems - a user turned on client logging and got the following results when trying to open different repositories:
"Good repository":
3/4/2008 1:33:21 PM <refresh>: [GUIClientWorkerThread:1648] Calling client service GetRepositoryStructure(26, 112155, -1, 1/22/2008 11:02:45 AM, ref, ref, ref)
3/4/2008 1:33:21 PM <refresh>: [GUIClientWorkerThread:1648] Client service GetRepositoryStructure returned: dtLatestCheck 1/22/2008 11:02:45 AM, nReturnDestRevision 112155, rd not null True
"Bad repository":
3/4/2008 1:34:22 PM <refresh>: [GUIClientWorkerThread:3380] Calling client service GetRepositoryStructure(7, 0, -1, 7/1/1850 12:00:00 AM, ref, ref, ref)
3/4/2008 1:34:49 PM <refresh>: [GUIClientWorkerThread:3380] GetRepositoryStructure caught exception: There is an error in XML document (1, 1944338).
In the "bad repository", the date passed is 7/1/1850, which looks a bit suspicious.
- Jeff
Sorry I missed seeing that last reply. That is definitely strange.
If the information is coming from the client, then I could see clearing the cache cleaning that up. I wouldn't expect a user to need to do it more than once though.
Could the user that turned on their client logging clear their Clear Client Side Cache entirely except for cachemember_workingfolderassisgnments? Close Vault and Visual Studio first. Then open Vault and access the repository again and let me know the results?
If the information is coming from the client, then I could see clearing the cache cleaning that up. I wouldn't expect a user to need to do it more than once though.
Could the user that turned on their client logging clear their Clear Client Side Cache entirely except for cachemember_workingfolderassisgnments? Close Vault and Visual Studio first. Then open Vault and access the repository again and let me know the results?
I'll have them try the selective cache clearing.
Another manifestation of this same XML error produces the following in the client log:
System.InvalidOperationException: There is an error in XML document (1, 4420093). ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
It looks like the client was trying to get the repository structure.
The XML error only happens when users are working with two of our largest repositories; one with 184,000+ files, 12,000+ folders and 45,000+ revisions and the other with 136,000+ files, 18,000+ folders and 7,000+ revisions.
Any ideas with this one?
Another manifestation of this same XML error produces the following in the client log:
System.InvalidOperationException: There is an error in XML document (1, 4420093). ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
It looks like the client was trying to get the repository structure.
The XML error only happens when users are working with two of our largest repositories; one with 184,000+ files, 12,000+ folders and 45,000+ revisions and the other with 136,000+ files, 18,000+ folders and 7,000+ revisions.
Any ideas with this one?
What error in the server log corresponds to that?
The times I've seen that error, it was a firewall blocking or IIS periodically recycling. I could tell more on that one from the server log. Could you either post your server log here or email it to me at support at sourcegear.com with a link to this forum thread?
The times I've seen that error, it was a firewall blocking or IIS periodically recycling. I could tell more on that one from the server log. Could you either post your server log here or email it to me at support at sourcegear.com with a link to this forum thread?