Hello,
I have an issue with NCrunch regarding Distributed Processing.
Running it on my machine alone works perfectly fine.
Running distributed processing however will lead to NCrunch getting stuck.
It will Init and load snapshot without any problems but after that it will simply say "The connection has been closed" with a red alert next to the server.
It works fine on a pc right next to me so it's unlikely to be the network.
Build/Test Issues
"The connection has been closed" on Distributed Processing
Started by Farami on 9,382 views
Remco NCrunch Developer
#10256
13 Apr 2017 10:00 UTC
Hi, thanks for sharing this issue.
Does this seem to happen only for a specific solution? For example, does it also fail if you try to use it with a very simple dummy test solution?
Does this seem to happen only for a specific solution? For example, does it also fail if you try to use it with a very simple dummy test solution?
Hi, thanks for the quick answer.
I have tried with as simple a project as possible and the problem still persists.
I have tried with as simple a project as possible and the problem still persists.
Remco NCrunch Developer
#10258
13 Apr 2017 11:12 UTC
Can you check whether the version of the grid node is consistent with the client? A simple way to be certain of this is to just re-download the installer for the latest version of both and install them.
I have already tried updating the grid nodes. Everything is the same version and my colleague can use the grid node servers perfectly fine.
Remco NCrunch Developer
#10260
13 Apr 2017 11:19 UTC
Are you running any kind of anti-virus or firewall software on your machine that might interfere with outgoing connections?
Something worth trying is also to install the grid node on your local machine, then try to connect to it via loopback connection (127.0.0.1). This would help to rule out whether there is anything on the network that might cause this.
If you can submit a bug report after you've had the disconnection happen, I'll examine the logs to see if there is any clue about why this is happening on your machine.
Something worth trying is also to install the grid node on your local machine, then try to connect to it via loopback connection (127.0.0.1). This would help to rule out whether there is anything on the network that might cause this.
If you can submit a bug report after you've had the disconnection happen, I'll examine the logs to see if there is any clue about why this is happening on your machine.
Remco wrote:Are you running any kind of anti-virus or firewall software on your machine that might interfere with outgoing connections?
No I am not. Windows firewall is disabled.
Remco wrote:
Something worth trying is also to install the grid node on your local machine, then try to connect to it via loopback connection (127.0.0.1). This would help to rule out whether there is anything on the network that might cause this.
Running the grid node on my own computer appears to work fine.
Remco wrote:
If you can submit a bug report after you've had the disconnection happen, I'll examine the logs to see if there is any clue about why this is happening on your machine.
I have submitted a bug report right after the connection has been closed on the remote grid node.
Edited 13 Apr 2017 11:28 UTC
Remco NCrunch Developer
#10262
13 Apr 2017 11:58 UTC
Thanks. I've taken a look at the log file in the bug report. It contains some interesting exceptions, but these are all downstream from the disconnection itself and don't appear to be the actual cause of it. The grid node seems to be synchronising successfully and starting to build the projects when the connection suddenly gets cut.
I'll need to take a look at the logs on the grid node itself. Unfortunately, the bug reporter doesn't have any option to easily upload these, so it'll take a little digging from your side:
1. Open up the grid configuration tool on the grid node
2. Turn on the log to file option and choose a directory to hold the logs. Set the log verbosity to Detailed.
3. Press OK, let the grid node restart.
4. Connect to the grid node using the smallest solution/project you can that will surface the problem.
5. Let the connection run until it fails, then disable NCrunch on the client so it doesn't try to reconnect.
6. Go to the grid node, zip up the logs (hopefully it's just one file), then submit it through the contact form on this site: https://www.ncrunch.net/support/contact.
I'm also hoping you can double-check that you aren't running any kind of software on your machine or network that might interfere with TCP connections in any possible way. The pattern of failure here (works with loopback and other machines on the network) does make the network connections on your machine quite suspect, especially as I haven't had anyone report a problem exactly like this before. If you're absolutely certain that there is nothing to your knowledge that could do this, then I'll take your word for it.
Something else that comes to mind ... Are all the machines on your network using the same locale (i.e. Germany)? Hopefully this isn't a cross-locale issue.
I'll need to take a look at the logs on the grid node itself. Unfortunately, the bug reporter doesn't have any option to easily upload these, so it'll take a little digging from your side:
1. Open up the grid configuration tool on the grid node
2. Turn on the log to file option and choose a directory to hold the logs. Set the log verbosity to Detailed.
3. Press OK, let the grid node restart.
4. Connect to the grid node using the smallest solution/project you can that will surface the problem.
5. Let the connection run until it fails, then disable NCrunch on the client so it doesn't try to reconnect.
6. Go to the grid node, zip up the logs (hopefully it's just one file), then submit it through the contact form on this site: https://www.ncrunch.net/support/contact.
I'm also hoping you can double-check that you aren't running any kind of software on your machine or network that might interfere with TCP connections in any possible way. The pattern of failure here (works with loopback and other machines on the network) does make the network connections on your machine quite suspect, especially as I haven't had anyone report a problem exactly like this before. If you're absolutely certain that there is nothing to your knowledge that could do this, then I'll take your word for it.
Something else that comes to mind ... Are all the machines on your network using the same locale (i.e. Germany)? Hopefully this isn't a cross-locale issue.
Thanks for the quick responses.
I have done as you asked and attached the zipped logfile to the contact form.
I have double checked and there is nothing running or even installed that should prevent the connection from being stable. At least to my knowledge.
The locale is the same on all machines.
I have done as you asked and attached the zipped logfile to the contact form.
I have double checked and there is nothing running or even installed that should prevent the connection from being stable. At least to my knowledge.
The locale is the same on all machines.
Edited 13 Apr 2017 12:14 UTC
Remco NCrunch Developer
#10266
14 Apr 2017 00:05 UTC
Thanks for sending through the log. This error message is a bit misleading. The connection problem isn't between your client machine and the grid node, it's between the grid node and its build runner host.
When the grid node attempts to run nCrunch.BuildHost462.x86.exe and hook up an IPC connection, the process suddenly terminates.
Can you check whether you have .NET 4.6.2 installed on the grid node server? NCrunch v3.6 has a bug that prevents it from accurately detecting this version of .NET, so it's possible the grid node is trying to use a version of .NET that isn't installed on the system.
When the grid node attempts to run nCrunch.BuildHost462.x86.exe and hook up an IPC connection, the process suddenly terminates.
Can you check whether you have .NET 4.6.2 installed on the grid node server? NCrunch v3.6 has a bug that prevents it from accurately detecting this version of .NET, so it's possible the grid node is trying to use a version of .NET that isn't installed on the system.
Awesome! 4.6.2 was indeed missing and installing it fixed the issue. Thank you very much for the quick help.
Remco NCrunch Developer
#10288
18 Apr 2017 07:54 UTC
Farami wrote:Awesome! 4.6.2 was indeed missing and installing it fixed the issue. Thank you very much for the quick help.
Great to hear! A fix for the detection issue will be in the v3.7 release, so next time we won't get a weird error like this.
Post a reply
Log in to reply.