TIL that PowerShell can use internal CLR generic reference type names like that! But really, please don't do that...
-
[System.Nullable``1[[System.Int32]]]
-
[Nullable[int]]
... much easier to read
TIL that PowerShell can use internal CLR generic reference type names like that! But really, please don't do that...
[System.Nullable``1[[System.Int32]]]
[Nullable[int]]
... much easier to read
You can ignore this error; for whatever reason, the NuGet client unexpectedly terminated the connection, and the result was that ProGEt stopped writing bytes. Not really anything to worry about.
The diagnostic center isn't for proactive-monitoring, more for diagnostic purposes. So ulnless users are reporting a problem, you don't need to check it.
Hi @andreas-unverdorben_1551 ,
npmjs.org primarily serves static content and runs on massive server farms running in Microsoft's datacenters.
Your ProGet server is much less powerful and does not serve static content. Not only is every request is dynamic (authentication, authorization, vulnerability checking, license checking, etc), but most requests (such as "what is the latest version of package X") need to be forwarded to npmjs.org and aggregated with local data.
So, a much less powerful server doing a lot more processing is going to be a little slower ;)
Running ProGet in a server cluster will certainly help.
Cheers,
Dean
Hi @scott-wright_8356 ,
Thanks for sharing a lot of the details; it's not really clear what objects the locks are on, can you look at the XML view of the deadlock report to find out?
Since you're "already there", you're welcome to try doing what we would do --- just add WITH (READUNCOMMITTED)
to the problematic queries (i.e. the ones where object locks are occurring on).
For example, like this: SELECT * INTO #PgvdPackageNames FROM [PgvdPackageNames_Extended] WITH (READUNCOMMITTED) WHERE [PackageName_Id] = @PackageName_Id
As an FYI, this should not be an issue in ProGet 2024, since package analysis is cached for a short while. Also, our internal development practices (going forward) are to READUNCOMMITTED
in "hot" queries this anyway.
-- Dean
hi @andreas-unverdorben_1551 ,
The timeout message you shared is for a NuGet feed - so the issue isn't the 727 packages that you're installing (which often results in 1400-2100 requests being fired off simultaneously) , but the NuGet build(s) that are also going on at the same time and hammering the server.
The server cluster will definitely help with this peak load.
FYI --- that error message you shared is is from NuGet v2 API, so something is still calling it.
Cheers,
Dean
Hi @andreas-unverdorben_1551 ,
What's happening here is your server is being overloaded due to lots and lots of traffic -- effectively you are doing a Denial of Service attack on you server. As I mentioned in npm install slow on proxy feed, ProGet is not a static file server and there is a lot of processing required for each request.
The best way to handle this is to run a load-balanced ProGet server cluster.
Alternatively, you will need to reduce or throttle traffic.
Best,
Steve
Hi @andreas-unverdorben_1551 ,
npmjs.org primarily serves static content and runs on massive server farms running in Microsoft's datacenters.
Your ProGet server is much less powerful and does not serve static content. Not only is every request is dynamic (authentication, authorization, vulnerability checking, license checking, etc), but most requests (such as "what is the latest version of package X") need to be forwarded to npmjs.org and aggregated with local data.
So, a much less powerful server doing a lot more processing is going to be a little slower ;)
Running ProGet in a server cluster will certainly help.
Cheers,
Dean
In this case, can you open a ticket and send us that tar.gz file (attach on the ticket)?
From there we will load it in a debug version of ProGet and identify where the problem is occurring. Not something that will be easy to spot by inspecting a file :)
Thanks,
Dean
This means that the file you uploaded contained unexpected data; like maybe something in the package.json file was wrong, or it was in the wrong format, etc.
How did you create this npm package? Or did you download it from somewhere? We could probably look at the file and say what's wrong with it.
Best,
Dean
Hi @henh-lieu_7061 ,
This error indicates that you don't have access to the c:\ProgramData\Romp directory, or there is otherwise a file error when writing to that folder.
You can try deleting that folder, then reinstalling again.
Best,
Dean
Hi @Ricardo_C_RST ,
For EC2 (a virtual server), you can just follow the ordinary Inedo Hub installation process. As for HTTPS and Domain, that's a setting probably easiest to do in AWS. I'm not familiar with AWS, but something like CloudFront might help?
Dean
Hi @Justinvolved,
I don't know if I'm totally tracking the structure, and what you mean by "referencing the latest builds" in the deployment scripts.
Are you looking to have three applications? One app per repo, and then a "controller" application?
Or, do you want to have one application that builds from two repos? And it will always build/deploy content from those at the same time?
Dean
Hi @MaxCascone ,
Thanks for pointing these out; we will get the RPM icon fixed (probably a minor CSS thing), and then then hide the option on the Manage Asset Directory page (via PG-2540).
This view is intended mostly for ProGet ISV Edition use cases, and we likely won't expand on this in ProGet 2024, since you're probably first person who commented on it
Cheers,
Dean