CCNET not retrieving latest version

[grandavenuesoftware]

CCNET communicates with the Vault Plugin and the plugin uses a history command to check the latest version in the repository. If the version has been updated, CCNET triggers a build. Then the plugin does a GET.

Currently, if the GET fails, we have no way to stop CCNET from continuing with the build.

I've logged work item 16696 to see if there's a way we can change this behavior. We'll also take a look at changing the behavior for a failed login.

The worst part is once CruiseControl gets into this state, no source is ever gotten until the service is restarted. So for scheduled builds they perform it with the same source, and check-in triggered builds never fire.

[lbauer]

It might be helpful to determine why the Get is failing.

Could there be hardware or network problems?

Are there any errors in the Vault server log or in the event viewer that explain the failed Get?

[grandavenuesoftware]

It might be helpful to determine why the Get is failing.
Could there be hardware or network problems?
Are there any errors in the Vault server log or in the event viewer that explain the failed Get?

We haven't found any evidence of hardware or network problems. The two machines (client and vault server) are virtual machines on the same host operating system.

We also haven't found any errors or events that give us an indication of why the Get failed.

And again, our concern is that in the real world there will be failures, and we'd like CCNET to not get stuck indefinitely when one occurs.

Thanks.

[grandavenuesoftware]

It might be helpful to determine why the Get is failing.

Could there be hardware or network problems?

Are there any errors in the Vault server log or in the event viewer that explain the failed Get?

We did activate verbose debugging. At some point a particular cruise control project will start giving the following error: SSL Disabled AuthTokenHash matched, but couldn't get the userid. From that point on that project will not get source until the CruiseControl.Net service is restarted. It seems most likely that the problem is in the cruise control plug-in. This problem started happening after we upgraded to CruiseControl.NET 1.8.2 and Source Gear 6.0.1. (We upgraded both at the same time so we don't know if one or the other was the culprit.)

We have been able to reproduce the problem. When we reboot the server that Vault runs on, all of the cruise control clients start getting the "but couldn't get the userid" error.

We can send you the full logs if that would help.

[humphry]

CCNET communicates with the Vault Plugin and the plugin uses a history command to check the latest version in the repository. If the version has been updated, CCNET triggers a build. Then the plugin does a GET.

Currently, if the GET fails, we have no way to stop CCNET from continuing with the build.

Isn't it as easy as just rethrowing the exception?
In the vault plugin all exceptions are caught and handled.

The following is a snippet from ccnet's library that contains an implementation for getting source for SVN:

File : C:\Program Files (x86)\CruiseControl.NET\server\ThoughtWorks.CruiseControl.Core.dll
Assembly : ThoughtWorks.CruiseControl.Core, Version=1.8.2.0, Culture=neutral, PublicKeyToken=null

Code: Select all

namespace ThoughtWorks.CruiseControl.Core.Sourcecontrol
{
	[ReflectorType("svn")]
	public class Svn : ProcessSourceControl
	{
....
public override void GetSource(IIntegrationResult result)
{
...
	this.CheckoutSource(result);
}
...
}

Inside GetSource, the method CheckoutSource is called. The method CheckoutSource starts with:

Code: Select all

private void CheckoutSource(IIntegrationResult result)
{
	if (string.IsNullOrEmpty(this.TrunkUrl))
	{
		throw new ConfigurationException("<trunkurl> configuration element must be specified in order to automatically checkout source from SVN.");
	}
....
}

So, when something is wrong an exception is thrown to the calling code.

[lbauer]

Isn't it as easy as just rethrowing the exception?
In the vault plugin all exceptions are caught and handled.

Our code does catch the exception, so we need a way of sending it back to the server.

We have work item 16696 logged to address this problem.

[lbauer]

To Grandavenuesoftware:

When we reboot the server that Vault runs on, all of the cruise control clients start getting the "but couldn't get the userid" error.

It looks like some of the problems with slow logins and errors like this have to do with the client-side cache (or possibly lack of a cache.)

When the Vault server restarts, the server has to reload its in-memory cache and send a new version of the tree the the clients. If there are a lot of connections this might create a performance issue.

We've been communicating off-line about slow logins -- I'll contact you with more details.

[humphry]

Our code does catch the exception, so we need a way of sending it back to the server.

What do you mean by "sending it back to the server"?
Just rethrowing the exception will do I think (or not catching it at all).

[lbauer]

I meant reflecting the error in the Vault Server log.

I'll pass your comments on to our developers.

[danf]

What's the status of this error (and work item 16696) ? We're getting it with vault standard 7.1.0.2028 and CCNET 1.5.6804.1

[lbauer]

It hasn't been addressed yet. I've added your comments to the work item and bumped it up in priority.