This commit is contained in:
@@ -243,66 +243,10 @@ TODO: 1 BETA DOCS:
|
||||
██ ██ ███████ ██ ██████ ██ ██ ██ ██ ██ ████ ██████
|
||||
|
||||
|
||||
|
||||
- 1 todo: error handling improvement: DO THIS NEXT
|
||||
if the chromium process is killed while rendering by the sweeper, the browser gets back a temporary error message that it pops up:
|
||||
{"error":{"code":"2030","message":"Protocol error(Page.printToPDF): Target closed. (The remote party closed the WebSocket connection without completing the close handshake.)"}}
|
||||
This is not good as it vanishes by and is basically meaningless to users
|
||||
So, server should not return this error but instead return a timeout error if it sees this was the error
|
||||
To test this out use the large data set and run 1800 wo dispatch report with the timeout set to 6 minutes which is enough time for the browser to kick in but not enopugh to complete the job
|
||||
may need to re-run a few times as the timing is wonky when the sweeper job kicks in
|
||||
|
||||
TODO: throw the same exception when this error is detected as if timed out normally in reportbiz which in turn should trigger proper error handling at both ends (log in server, clear message in webapp)
|
||||
|
||||
|
||||
|
||||
- 1 todo: add the caching technique to *all* the other getreportdata methods as was done with workorder
|
||||
|
||||
|
||||
|
||||
- xx DONE?: kill chromium better NOT TESTED YET ON LINUX
|
||||
|
||||
ok, seeing that the process id that we get from teh browser does not include the process actually doing the work, if it needs to kill it, it seems to kill some other chromium process that isn't the one in question
|
||||
|
||||
if chromium process issue arises again, could add code to look for chromium process that are not in the bag but are started from our private instance folder and shut those down
|
||||
during sweeper cleanup job
|
||||
|
||||
foreach (Process PPath in Process.GetProcessesByName("notepad"))
|
||||
{
|
||||
string fullpath = PPath.MainModule.FileName;
|
||||
Console.WriteLine(fullpath);
|
||||
}
|
||||
|
||||
IDEAS:
|
||||
|
||||
-1 - Process.Kill has a bool to kill child processes which I was not setting, fuck, this might fix it all completely..testing...
|
||||
YES YES YES, worked in windows in one test.
|
||||
|
||||
0- does .net give age of process, if so then easy peasy because can step through all chromium processes that are in our path and kill any over the expiry time
|
||||
YES!!
|
||||
https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.process.starttime?view=net-6.0#System_Diagnostics_Process_StartTime
|
||||
https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.process?view=net-6.0#properties
|
||||
|
||||
1- check if no unexpired print jobs active in bag and if so then kill any chromium processes found (takes care of hangers on but only works when there is a lull in printing)
|
||||
2- step through report render, look for processes being created, see if there is a moment when they can be read back from windows and added to bag
|
||||
i.e. what processes did it *just* start and toss them in the bag with same expiry date then proceed
|
||||
|
||||
|
||||
- xx DONE SEEMS OK: Is there a reason to open a new page or can I re-use the initial browser page because it seems like the extra page is causing extra hassles as it's process is different from the browser pid
|
||||
did it, seems ok, no issues noted
|
||||
|
||||
|
||||
- 3 COULD NOT REPRODUCE / DOWNGRADED TO BOLO todo: chromium seems to be launched 6 times for one report, when the report is done and sent 3 instances close but three remain with one being super busy and eating up ram still
|
||||
wtf are there so many processes?
|
||||
2gb of ram in the zombie unasked for chromium process wtf?
|
||||
Is it doubling the work somehow, seems like the second chromium is re-doing the work of the first or at least it's busy for no real reason?
|
||||
Does a Page have it's own process id like it's a whole browser running?
|
||||
Go headful and watch what is happening, figure it out
|
||||
COULD NOT REPRODUCE, did make some changes and it could have been leftovers from earlier shit maybe
|
||||
will downgrade and keep an eye on this
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## CLIENT MISC ITEMS
|
||||
@@ -497,6 +441,10 @@ todo: 1 When there is a rendering issue with chromium browser startup the server
|
||||
this is because it was written expecting any error was a template error not a starting chromium error so need to look there in the exception handler
|
||||
would rather not log report template issues to the server log but anything else structural should be
|
||||
|
||||
todo: 2 Log levels are all over the place at the server, follow proper guideance and adjust them as per:
|
||||
https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.logging.loglevel?view=dotnet-plat-ext-6.0
|
||||
specifically there are a lot of log debugs that should be traces and maybe missing log criticals level for server stopping shit
|
||||
|
||||
todo: 2 wrap this error in a debug build block before release:
|
||||
2021-12-22 16:19:07.0290|ERROR|AyaNova.Biz.TranslationBiz|********* GetSubsetAsync problem: Duplicate keys: WorkOrderItemPartQuantity)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user