Twice in the past week I've see an issue where a programmer tries to check in a code update and they get a Vault error. Here's the stack dump from the server log:
Code: Select all
----5/3/2007 6:11:04 PM Kharmon--192.168.104.159(192.168.104.159)--SSL Disabled BeginTx: Critical Error! Error in the application.
at VaultServiceBase.VaultFolder.DeleteFolderEntryByName(HybridDictionary htParentObjects, String strSearchName, Int32 nObjType, Int32 nFSOHashCode)
at VaultServiceBase.VaultRepository.CreateFolderReferenceCopy(Int64 nRevID, HybridDictionary hdNewRefParents, VaultFolders vfOwners, VaultFolder vfOld)
at VaultServiceBase.VaultRepository.GetReferenceCopiesByPath(Int64 nRevID, HybridDictionary hdNewRefParents, String strAbsolutePath, Boolean bRefCopyLastObjectWithAllFolders, VaultFSObjects& fsoList, Int32& nPinCount)
at VaultServiceAPILib.VaultTransactionContainer.GetReferenceCopiesByPath(String strAbsolutePath, VaultFSObjects& fsoList, Int32& nPinCount)
at VaultServiceAPILib.VaultTransaction.PreCheckCheckIn(Int32 nCurrStatCode, VaultRequestCheckIn vrci, String strFileToken, VaultResponseCheckIn vRespCheckIn, VaultTransactionContainer txContainer)
at VaultServiceAPILib.VaultServiceAPI.BeginTx(HttpApplicationState theApp, VaultLoginInfo vliLoggedInUser, Int32 nTxUserID, Int32 nRepID, VaultDateTime dtBeginTx, String strComment, VaultRequestItem[]& requests, String& strTxID, VaultIntTx& vit)
at VaultService.VaultService.DoBeginTx(HttpApplicationState has, HttpSessionState hss, VaultLoginInfo vli, String strCallerLogEvt, Int32 nTxUserID, Int32 nRepID, VaultDateTime dtBeginTx, String strComment, VaultRequestItem[]& requests, String& strTxID)
Is anybody looking into what the root cause of such problems could be? A real fix here would be nice.
In one of my posts a few months ago (http://support.sourcegear.com/viewtopic.php?p=30371) there really was no answer for either 1) why the cache gets corrupt or 2) why clearing the caches fixes it. In yet another post of mine (http://support.sourcegear.com/viewtopic.php?=&p=30128) this same problematic method DeleteFolderEntryByName is listed as the top function in the stack.
I sincerely hope that someone is taking a good hard look at the code in DeleteFolderEntryByName as it is clearly not as robust as it needs to be.