Hi @scott-wright_8356 , Once connector caching is enabled, the error pattern is not used, so we only have this warning. I added a small change via PG-2726 which will add the connector name. This will appear in the next maintenance release (2024.9), scheduled for this week. Removing connector caching should reveal the connector name, so maybe that helps you identify it until then Thanks, Steve

I set our metadata caching to 10000 queries over 24 hours. I will reduce to the default first and monitor. Thanks Dean

@rhessinger Wonderful, thank you very much and credit to Pawel Ostrowski who also did a lot of investigation on this

Thank you very much for this, Alana. Very much appreciated.

Hi @scott-wright_8356 , This is unfortunately the consequence/downside with frequently-updated packages (like 2-3x daily updates of electron-to-chromium) and metadata caching. The underlying issue is that different metadata queries have different cache expirations, so the search queries (e.g. "electron-" or "electron-to" or "chromium", etc) will not line up with index queries (e.g. "list electron-to-chromium versions"). There is no solution to this, aside from changing durations or disabling caching. In general, we very strongly advise against developers "always using the latest version of packages they see", since that's a major attack vector for software supply chains. It also makes build reproducibility basically impossible and gives testing a headache. Instead, we encourage a package approval process where only approved packages are consumable by build servers, as opposed to whatever's the latest version on the net Best, Alana

Hi @scott-wright_8356 , You can ignore that message; not sure how/why it occurred, but the consequence is that the message that the license key was updated wasn't immediately dispatched to the other nodes due to some timint issue. So that means it could take a few minutes for the other nodes to reflect the new license key. We should probably just ignore that error. let us know if you keep seeing "No primary service node has been registered." and we can investigate further. Best, Alana

Hi @scott-wright_8356, I looked into this further; for Maven feeds, the Connector Health Check simply queries the downloaded index. If there is no downloaded index, then it reports back as healthy. If there's an error with the index, it reports an error. However, most maven repositories don't have a downloadable index. Anyway the health check is not very useful, and we plan to revisit the functionality in the future, since there's really no way to determine if ProGet can download an artifact unless you know the exact name. Thanks, Alana

Hi @scott-wright_8356 , Thanks; it sounds like the underlying issue is indeed Google Android connector you added. I don't have an information or idea on why that might be the case... some third-party repos (Maven, PyPi, NuGet, etc.) are just really slow and buggy. ProGet is basically acting like a proxy server here, so "garbage in, garbage out" applies - if the connector is slow and error-prone, then you will experience slowness and errors. Sometimes third-party repos will create packages that don't follow the specifications but just happen to work in certain versions of clients. That could be what's happening here. In cases like that, we can really only address those on a case-by-case basis, and we'd need to know exactly how to reproduce the error and investigate it later. Best, Alana

Hi @scott-wright_8356 , You can change if you'd like, I'm not sure if it makes any difference with .NET6+ applications. Cheers, Alana

@atripp We applied the script, can confirm that we are not getting the error anymore. Thanks!

Hi @scott-wright_8356, This is usually due to a networking error; it may also be resolved by restarting. It's also just something you can ignore. The service messanger isn't very important in ProGet. Best, Alana

Thank you for the information. I will investigate the virus scanner

Excellent, we have just moved to using integrated security with the SQL server. The account was configured as DB owner. Will test the next upgrade when available.

Hi Atripp, We have received some scripts from Alex Papadimoulis. We started running these yesterday and the SQL blocking has so far disappeared and the Dashboards_GetLargestPackages now has no issues. Looks like Brett Shearer and Alex have a solution for both problems. Our load is still an issue at peak times but features are now working fast. Will keep monitoring and get back to Alex confirming the outcomes of the new stored procedures next week. Thank you

Hi @scott-wright_8356, We haven't seen any other issues with this procedure in particular, but it's something we can consider to update. Have you considered that doing the commit with UPDLOCK and SERIALIZABLE could be causing issues with AlwaysOn and sycnchronsist commits going to the secondary? One thing we faced with ProGet 2023's new database model was handling different bugs in different version of SQL Server's analysis engine. Without this pessimistic lock, some versions of SQL Server 2019 will deadlock while updating totally unrelated indexed view. That said, you shouldn't need to use synchronous commits with ProGet in AlwaysOn. That's going to slow things down a lot to begin with, and that level of data-integrity is so important in ProGet. Thanks, Alana

Thank you atripp, confirmation of everything we thought was the problem and working on it now.

@atripp said in ProGet Diagnostic Center: Delete All Messagses: TRUNCATE LogMessages Thank you worked perfectly yes there were a lot of logs.