Hi @patchlings,

We believe this error is due to a regression/bug in the Mono, which is related to change to their HttpWebRequest stack. In the future, after Microsoft releases it, we plan to move to .NET 5 for a more stable platform.

The best resolution, for now, is to move to Windows/IIS; it's the most stable. Is this possible?

If not... we don't know when Mono will fix the bug, or if it's possible for us to work-around, but we think it will get resolved in the future. Would you be able to make ProGet restart once per day? I think this would help with the memory leak.

Thanks,
Rich

Hi @patchlings,

Thanks for all the data. I really appreciate your help with this! I'm currently reviewing our code to see if I can find a correlation with this.

Thanks,
Rich

Hi @patchlings,

Thanks! I'm not surprised that debug exaccerbates the issue, but it's definitely good to know.

Thanks,
Rich

Hi @patchlings,

Thank you for checking this for me. So the good thing is that this is definitely not a threading issue. Can you give me a stub status when it's working during normal use and one after it starts behaving poorly?

Thanks,
Rich

Hi @patchlings ,

Thanks for all this information. Would you be able to get me an open thread count for when everything is running fine and when things are not? You should be able to find it by running sudo ps huH p <PID_OF_MONO_PROCESS> | wc -l. Also, are you running these commands inside the docker image? Or on the host?

Thanks,
Rich

Hi @patchlings,

Thank you very much for the information. I'm researching the issue more on our side. I may send over some more questions your way while I'm working on this.

Thanks,
Rich

Hi @patchlings,

Do these connector errors happen on all your feeds? Or just NuGet?

Thanks,
Rich

Hi @philippe-camelio_3885,

Technically you can use VSCode, but you will still have to at least install the MS Build Tools for Visual Studio 2019. Then you will have to run the msbuild.exe to compile your code. Here is Microsoft's guide for how to work with C# in VSCode. Hope this helps!

Thanks,
Rich

Hi @patchlings ,

I was doing some Docker research around this issue. Something I found Docker users complaining about was an issue with the total number of available connections on the host. It seems that the more containers running on a host (especially with database containers on it), the connection count can get spread a bit thin under load. Have you tried increasing the max number of connections? Here is a StackOverflow about increasing them Increasing the maximum number of TCP/IP connections in Linux.

Also, how many connectors do you have on your NuGet feed?

Thanks,
Rich

Hi @philippe-camelio_3885,

Do you know how to create your own extension? If not, check out creating an extension using the SDK.

To create an $InedoProduct and $InedoProductVersion variables, you can create a couple of new classes extending Inedo.Extensibility.ScalarVariableFunction. Then simply implement the ExecuteScalar method and have it return Inedo.SDK.ProductName or Inedo.SDK.ProductVersion. You can see an example of this with the ServerNameVariableFunction in the Inedox-InedoCore extension on GitHub. If you can submit a pull request, I'll be happy to test it and get it published right away!

Thanks,
Rich

Hi @patchlings,

Have you enabled the nginx HTTP Stub Status module on your nginx proxy? I would be interested to see the number of open and waiting connections. Although this article is old, nginx: See Active connections / Connections Per Seconds seems to show a pretty easy configuration to see this status. I would be curious to see these counts when the problem exists. Would you be able to enable this and post the counts when everything is working and when it is not?

Thanks,
Rich

Hi @scroak_6473,

That's great to hear that the impersonation has fixed the issue. We have fixed this issue to not require impersonation in ProGet 5.3.2. I will let you know if anything changes!

Thanks,
Rich

Hi @scroak_6473 ,

Yes, I have included this fix in 5.3 as well. It will be released as part of ProGet 5.3.1.

Thanks,
Rich

Hi @scroak_6473 ,

Thanks for bringing this up to us! I have fixed this issue and it will be released in ProGet 5.2.31.

Thanks,
Rich

Hi @aleksandarsh_4585 ,

I wanted to put the final solution in this thread for what solved the error. It looks like the issue was around which extensions were installed. After upgrading to 6.1, you needed to enable the legacy features in Administration > Advanced Settings and install the Legacy extensions in Administration > Extensions. We also had to uninstall and extensions that had errors loading including Amazon, Jira, and Jenkins and only leave the legacy versions installed.

Thanks,
Rich

Hi @aleksandarsh_4585 ,

I'm currently looking into if you can back up from a version older than 6.1.

I did want to verify that you have the latest extensions installed in your 6.1 instance. I would also recommend restarting IIS (or the independent web server if you are using that) and the BuildMaster service. Would you be able to take screenshot of your extensions page? The error you sent out is typically an error caused by a missing extension. In these cases, it will also cause your build pipeline page to error on load. That could explain why you can't load your application when you click on it.

You might be able to see what extension is failing by going to /pipelines/edit-json?pipelineId=464. Could you also try that?

Thanks,
Rich

Hi @aleksandarsh_4585 ,

Would you be able to send over a screenshot of your extensions page?

I think the best way to migrate this application is to install a fresh install of BuidMaster 6.2 and use option 3 from the release notes which is to export your application and reimport it into 6.2.

Export a single application from BuildMaster at a time into a universal package, and import that package into your new BuildMaster 6.2 instance. This will give you a good opportunity to discover any issues and to gradually migrate your applications to the new instance as you are able.

Generally, this approach will work best if you have a large number of applications, and some of them rely on legacy features that have been removed in BuildMaster 6.2. This way, you can bring over applications as the legacy dependencies are removed to take advantage of new features and capabilities, while still retaining the original instance for risk mitigation.

You can view the documentation for backing up and restoring applications here.

Thanks,
Rich

Hi @aleksandarsh_4585,

What version of BuildMaster did you upgrade to (i.e., 6.2.10)? It looks like it did not run the scripts for 6.2 on your database. I just wanted to confirm that the Manual Install zip you downloaded matches the version of BuildMaster that you installed.

Also, could you run the following query? I would like to see if any script errors happened during the SQL upgrade.

select top 10 * from __BuildMaster__DbSchemaChanges2 where Success_Indicator = 'N' order by Executed_Date DESC

Thanks,
Rich

Hi @aleksandarsh_4585,

It sounds like either the database or the application didn't actually update. Would you be able to make a direct SQL query against the ProGet database that is in the config? I would like you to run two different queries:

select * from Applications_Extended

and

select top 10 executed_date, Script_Guid, Script_Name from __InedoDb_DbSchemaChanges order by Executed_Date DESC

Thanks,
Rich

Hi @jonnpear_8217 ,

I have just updated the documentation for switching to IIS. Please take a look and let me know if you have any questions.

Thanks,
Rich