ProGet 2022.30 upgrade to 2023.28

[scott.wright_8356]

Hi Inedo,

Had an issue with the feed upgrade failing due to old packages with version issues. Was able to resolve all of these and complete the upgrade process. The server is up and running and responding to package requests across feeds are working. The issue is the event viewer we are getting .Net Runtime errors for 2 feeds npm and nuget cache feeds.

Category: Microsoft.AspNetCore.Server.IIS.Core.IISHttpServer
EventId: 2
SpanId: f132db9462672ba5
TraceId: 72864a074b90e5fac4c87f08e7c5ce94
ParentId: 0000000000000000
RequestId: 80000a9e-000e-c900-b63f-84710c7967bb
RequestPath: /npm/Registry/npm

Connection ID "14483576463363672733", Request ID "80000a9e-000e-c900-b63f-84710c7967bb": An unhandled exception was thrown by the application.

Exception: 
System.Threading.Tasks.TaskCanceledException: A task was canceled.
   at Inedo.Web.AhHttpResponse.CompleteAsync()
   at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)
   at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)
   at Inedo.Web.AhWebHost.<>c.<<Configure>b__18_0>d.MoveNext()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContextOfT`1.ProcessRequestAsync()

Category: Microsoft.AspNetCore.Server.IIS.Core.IISHttpServer
EventId: 2
SpanId: ecc2892673882cd1
TraceId: d46b306d137da872e9d90b192c3cdc99
ParentId: 0000000000000000
RequestId: 800007d4-000a-e900-b63f-84710c7967bb
RequestPath: /nuget/Gallery/v3/flatcontainer/microsoft.net.workload.mono.toolchain.net6.manifest-8.0.100.msi.x64/index.json

Connection ID "16789419455397496785", Request ID "800007d4-000a-e900-b63f-84710c7967bb": An unhandled exception was thrown by the application.

Exception: 
System.OperationCanceledException: The operation was canceled.
   at System.Threading.CancellationToken.ThrowOperationCanceledException()

The Web.ConcurrentRequestLimit is set to 0. We only started to see these errors after the upgrade. Any idea what it could be?

Regards Scott

[scott.wright_8356]

We are noticing the following query having a duration of anywhere from 12-20 seconds. Our Server is incredibly slow.

SELECT @PackageName_Id = [PackageName_Id]
FROM [PackageNameIds] WITH (UPDLOCK, SERIALIZABLE) 
WHERE [PackageType_Name] = @PackageType_Name
		       AND (([PackageGroup_Name_Lower] IS NULL AND @PackageGroup_Name IS NULL) OR ([PackageGroup_Name_Lower] = LOWER(@PackageGroup_Name)))
		       AND [Package_Name_Lower] = LOWER(@Package_Name)

Is there a reason why the Create_Indicator is always defaulting to 'Y' PackageNameIds_GetOrCreatePackageNameId. Have you considered that doing the commit with UPDLOCK and SERIALIZABLE could be causing issues with AlwaysOn and sycnchronsist commits going to the secondary? It appears everything is being blocked waiting for the secondary to update and we may not need to update at all.

Instead of doing pessimistic locking in the stored procedure it could be changed to do optimistic locking.

GET Id from table
if ID is null
	insert row
	if error
		Get ID from table
	else
		Get ID from whatever you inserted
	end
end
return ID

[atripp]

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