Owen and Marie:
You brought this problem up a few days ago. At our client we're pretty sure we've found out how to stop the problem and have a theory on why it happens.
The <userid>.log error message appears to be a VSS quirk, not a CCNet problem. We have 5 builds running on one machine. If we open up the VSS GUI on the build machine, log in as the same user that the builds are using, and leave the GUI open, the problem doesn't happen. If we close the GUI, we get the same error sporadically.
Our theory is that when a CCNet instance logs out of VSS, the <userid>.log file is deleted. If a second build is using the repository concurrently with the same user, when that second build logs out it looks for <userid>.log, but it's gone. Hence the error. Having the GUI open prevents the .log file from being deleted, so the problem doesn't occur. It's just a theory.
We've a guess that logging in with a different user for each build would solve the problem. There's a lot of red tape to get additional VSS users here, though, so we haven't tried it.
Best,
Garrett
Original message:
Subject: Re: [Ccnet-user] Network error
To: "Owen Rogers <ORogers" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
From: Marie Montero <[EMAIL PROTECTED]>
Date: Thu, 15 Apr 2004 10:55:00 -0500
I have also noticed a similar behaviour with my automated builds. I
currently have 4 projects setup and each of them will randomly put out an
Exception Message like this::
<cruisecontrol><modifications /><build date="4/15/2004 6:24:02 AM"
buildtime="00:00:00"
/><exception><![CDATA[ThoughtWorks.CruiseControl.Core.CruiseControlException:
Source control operation caused an error: Unable to open user login file
\\RemoteServer\SourceSafe\Vss60\data\loggedin\userid.log.
at
ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute(ProcessInfo
processInfo) in
d:\sourceforge\ccnet\project\core\sourcecontrol\ProcessSourceControl.cs:line
54
at
ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.GetModifications(ProcessInfo
info, DateTime from, DateTime to) in
d:\sourceforge\ccnet\project\core\sourcecontrol\ProcessSourceControl.cs:line
44
at
ThoughtWorks.CruiseControl.Core.Sourcecontrol.Vss.GetModifications(DateTime
from, DateTime to) in
d:\sourceforge\ccnet\project\core\sourcecontrol\Vss.cs:line 71
at
ThoughtWorks.CruiseControl.Core.Project.GetSourceModifications(IntegrationResult
results) in d:\sourceforge\ccnet\project\core\Project.cs:line 189
at ThoughtWorks.CruiseControl.Core.Project.RunIntegration(BuildCondition
buildCondition) in d:\sourceforge\ccnet\project\core\Project.cs:line
146]]></exception></cruisecontrol>
If you look at the time, it's at 6:24 am when nobody on my team is even in
the office. But just in case they are in, I also manually checked the
project directory in SourceSafe and it didn't have any checkins that
matched that time frame. All of my projects have gotten this weird error
(some of them at midnight or 2AM) at least once or twice and once the build
reports this errort, it seems to get stuck because then it will try another
'unexplainable' build sometime later and get the same error. Unlike
Kostya, when I check on the builds in the morning, I dont restart the
service but I force a build instead and that has so far yielded successful
builds.
Because they seem random, I am unable to recreate this problem. This is a
peculiar problem that is definitely misleading (as it makes you think the
builds failed) but I was planning on working with our admin guys for
SourceSafe to see if they could help me diagnose this problem. I thought
I'd send out a post about it since it seems that other people are running
into the same issue.
Marie
P.S. I am setting the SSDIR directory before I do any gets and I use the
service.
