We have some tests which use a central DB. When I use the [Serial] attribute and just run the tests on my local machine then the tests run fine. However if I enable the grid then I get intermittent failures because of conflicts in the DB (which running serially is designed to solve - not ideal I know, but we are where we are)
What I would like is to solve this. There are a couple of potential solutions I can think of. 1 is a new attribute which ensures exclusivity across the grid (difficult to implement I expect). The other is some way to force those particular tests to always run locally. I expect this can be done using the RequiredCapabilities attribute, but I have a question. We have machines which run the NCrunch command line in teamcity and also host a grid node (again not ideal, but until we can persuade someone to buy us more hardware...). Can the RequiredCapabilities of the grid node be different from the RequiredCapabilities of the NCrunch command line tool?
If so then we can have all the devs set their local machines to have the 'LocalRun' capability and then have the NCrunch command line runner also have the 'LocalRun' capability, then the tests will run serially on a single machine and all will be well in the world. Other suggestions to solve this would be appreciated. Always running on a single grid node is not going to be an option I don't think.
Cheers
Sam
Remco NCrunch Developer
#8721
10 May 2016 23:47 UTC
Hi Sam,
At the moment, there is no facility in NCrunch that can coordinate concurrent access to a resource across the grid (i.e. distributed mutex). The infrastructure to allow this just isn't there yet - we'd need a controller node that can centrally coordinate the individual nodes. Early designs of the NCrunch grid did leave room for this, so it may well happen in future... but I can't make promises at this stage.
The first thing I would suggest is to see what options you may have for avoiding the concurrency constraint entirely. Even with a centralised database server, there is usually the ability to create multiple databases or schemas on the server that represent individual clients. I was once involved in a project where all developers would work using a central Oracle server (which was problematic to set up on each workstation). We each had our own schema on the central server, and although it was heavily overloaded, we were able to work around the central constraint.
Where this just isn't feasible, the RequiredCapabilities attribute is your best hope. SerialAttribute and ExclusivelyUsesAttribute won't stop concurrency across the grid itself, and even if they did, there is still the risk of a collision with other DB users on your team.
It's definitely possible to have a different set of capabilities between the NCrunch console tool and the NCrunch grid node. The NCrunch console tool reads its configuration from an XML file that can be provided on the command line. The grid node will store its configuration inside the registry. This means that changing the configuration for one of these won't affect the other.
At the moment, there is no facility in NCrunch that can coordinate concurrent access to a resource across the grid (i.e. distributed mutex). The infrastructure to allow this just isn't there yet - we'd need a controller node that can centrally coordinate the individual nodes. Early designs of the NCrunch grid did leave room for this, so it may well happen in future... but I can't make promises at this stage.
The first thing I would suggest is to see what options you may have for avoiding the concurrency constraint entirely. Even with a centralised database server, there is usually the ability to create multiple databases or schemas on the server that represent individual clients. I was once involved in a project where all developers would work using a central Oracle server (which was problematic to set up on each workstation). We each had our own schema on the central server, and although it was heavily overloaded, we were able to work around the central constraint.
Where this just isn't feasible, the RequiredCapabilities attribute is your best hope. SerialAttribute and ExclusivelyUsesAttribute won't stop concurrency across the grid itself, and even if they did, there is still the risk of a collision with other DB users on your team.
It's definitely possible to have a different set of capabilities between the NCrunch console tool and the NCrunch grid node. The NCrunch console tool reads its configuration from an XML file that can be provided on the command line. The grid node will store its configuration inside the registry. This means that changing the configuration for one of these won't affect the other.
Post a reply
Log in to reply.