How to make heartbeats for Autocad from a plugin (C#) - autodesk-forge

Im developping a plugin for AutoCAD on Forge. Via a custom command (Provided by the plugin), it will publish a big png (25000x20000 for example) and sometimes it causes a timeout and the workitem failed.
<report.txt>
...
[03/02/2022 22:10:41] Save changes to page setup [Yes/No]? <N> N
[03/02/2022 22:10:41] Proceed with plot [Yes/No] <Y>: Y
[03/02/2022 22:10:41] Effective plotting area: 21212.94 wide by 20000.00 high
[03/02/2022 22:10:41] Plotting viewport 2.
[03/02/2022 22:11:42] Error: AutoCAD Core Console is shut down due to timeout.
[03/02/2022 22:11:42] End script phase.
[03/02/2022 22:11:42] Error: An unexpected error happened during phase CoreEngineExecution of job.
...
Im guessing the timeout will be done by design (Work Item Heartbeat) but havent succeed to find the way to make the long plotting survive.
Is there anyone who can help me?
The suggested solution, HeartBeat.cs has been tried but it seems not working for my case (because the engine Im using is AutoCAD?) though the document said that it will be ok if my plugin will print something (to stdout(=report.txt?) or trace(the suggested one) before one minute silence.
Additionally the actual PLOT command is issued on a scr file which is loaded and is executed inside my plugin.
PS1.
The only way to print something on report.txt I find is
Document doc = Application.DocumentManager.MdiActiveDocument;
doc.Editor.WriteMessage("somthing");
and seems the doc doesnt work with threading.
PS2.
The limitProcessingTimeSec for the workitem has been changed to 300, but it seems not related.

Related

Opening a downloaded mht file from Selenium (Help needed)

Long story short, I'm not a coder.
My team used to have this coder who created this Python/Selenium code to extract some information from chrome browser (Echocardiography reports) and/or downloaded mht file (also Echocardiography reports).
This code was working fine until recently, it stopped working.
The program still successfully downloads the mht file via chrome.
However, it fails to open the file and hence, code continues without extracting any information - resulting in empty extractions.
This is the part I need help figuring out
driver.get('chrome://downloads')
# driver.get('file:///C:/Users/name/Downloads/')
root1 = driver.find_element_by_tag_name('downloads-manager')
shadow_root1 = expand_shadow_element(root1)
time.sleep(2)
root2 = shadow_root1.find_element_by_css_selector('downloads-item')
shadow_root2 = expand_shadow_element(root2)
time.sleep(1.5)
openEchoFileButton = shadow_root2.find_element_by_id('file-link')
mhtFileName = openEchoFileButton.text
driver.get('file:///C:/Users/name/Downloads/' + mhtFileName) # go to web page
try:
echoDateElement = WebDriverWait(driver, delay).until(
EC.presence_of_element_located((By.XPATH, '/html/body/div[3]/p[1]/span[3]')))
except TimeoutException:
print("Loading page took too much time!")
I'm trying to figure out why it suddenly fails to open the downloaded mht files.
Last time our team tried using this code is back in 2020 and was successful.
Were there any updates to Chrome perhaps?
Help would be immensely appreciated.
Thank you so much in advance.
There are three obvious weaknesses in this code. The first two are the use of time.sleep() to wait for the element to appear and be manipulable. What if the machine is busy doing something else, and 1.5 seconds isn't enough? The right way to do that is to repeatedly check for the element to be ready. You've got a great example of how to do that using WebDriverWait() in this code already. The third weakness is the locator used in that presence_of_element_located() call. XPath locators rooted at "/html" are notoriously fragile, subject to breakage by small changes to the web page. Try to find something in the page that you can check via a more stable locator - ideally, an element with an ID= attribute.

FailedLimitProcessingTime; access to Forge Journal file possible?

We have a Revit model that doesn't seem to be running in Forge. It runs just fine in our local Revit Plugin, but it seems to 'hang' when trying it in Forge. After 3 hours, Forge just times-out...
The model isn't that big (less than 150MB), and we've handled many different (and larger) models before with success.
The logs from Forge doesn't tell us that much. It seems that the code from out plugin did not even run (we log the start of our code). Is there a way to get access to the journal file from Forge? Or is there an other way to see what might be the cause?
...
[05/03/2021 14:32:10] Initialize and get RCE: (VersionBuild) 21.1.20.44 (VersionNumber) 2021 (SubVersionNumber) 2021.2
[05/03/2021 17:31:52] Error: Revit Core Engine Core Console is shut down due to process time limit.
[05/03/2021 17:31:52] End script phase.
[05/03/2021 17:31:52] Error: An unexpected error happened during phase CoreEngineExecution of job.
[05/03/2021 17:31:52] Job finished with result FailedLimitProcessingTime
the workitemid:b27223519e824cdc90df80a1af6e718b
The issue is reproducible. So if you like we can send the model again and it will do exactly the same.

Error while executing Work Item "Cannot find the addin file"

I am new to the Design Automation API, so please excuse and correct me if I am using the wrong terms. I am setting up the wiring for my very first Design Automation AppBundle, and I have almost all of it working. I followed the patterns in the "Delete Walls" tutorial.
I have a working add-in DLL that I can test locally and it runs under the "design.automation-csharp-revit.local.debug.tool".
I also have all of the Rest API connections setup, and I can successfully submit a WorkItem that will download a Revit file from a BIM 360, and start processing it in the sandbox of Design Automation. But I am getting an error during the execution on the sandbox where it seems it can't find my add-in file. Here is an excerpt from the WorkItem log:
[07/21/2020 18:02:26] Resolving location of Revit/RevitCoreEngine installation...
[07/21/2020 18:02:26] Running user application....
[07/21/2020 18:02:31] Cannot find the addin file:
[07/21/2020 18:02:31] Fail to deploy Addon DLL(s) in AppPackages.
[07/21/2020 18:02:31] RESULT: Failure
I have looked through "bundle" ZIP file many times looking for typos that could cause this, but I can't find anything, it looks identical to the "delete walls" example. So I'm wondering if there is somewhere else that I need to look. Or any other way I could debug this to find out were the connection is missing. I can only assume that the AppBundle and Activity items are setup correctly since I am getting this far and the error is not mentioning either of those items.
Any tips on where to look?
This turned out to be a misspelling of the [dot]bundle folder extension that triggered the issue.

Cloudconnect CSV buffer size

When I try to load a big CSV from a zip file, the execution log give me the following error:
----------------------------------------- Error details ------------------------------------------
Component [Clientes:CLIENTES1] finished with status ERROR.
The size of data buffer is only 100663296. Set appropriate parameter in defaultProperties file.
--------------------------------------------------------------------------------------------------
How can I set the appropriate parameter in defaultProperties file?
I tried this link, but my cloudconnect run configurations page is different from the link:
I've created the parameters file and filled the additional parameters with the right values like said the tutorial (code bellow) and the same error appear in the screen.
Name: -config; Value: new_buffer_size.txt
The new_buffer_size.txt content have just this line:DEFAULT_INTERNAL_IO_BUFFER_SIZE = 200000000
How can I solve this problem? I need to solve this before the world explodes.
CloudConnect is designed to develop ETL(s), which can be run on GoodData cloud workers and therefore some lower level settings are surpassed as in this case. The only legitimate way is to modify the ETL the way it can process the data with current settings. Regarding to docs, the referenced article is outdated. GoodData docs team is aware if it and they are preparing docs refactoring.
Note: As you have probably noticed, CloudConnect is being powered by Javlin's Clover ETL, therefore feel free to check their forums, as you would find there how to overcome the issue on lower level (no UI), but it would work only for data processing on the local machine.

chrome "aw, snap" crash, but can't see crash log in chrome://crashes but see DMP generated, so what is the quickest way to interpret this DMP file

I can see my page get crash(see aw, snap page) with 20% proprobility after 10 mins(otherwise it runs well like forever)
so I tried:
1) CPU and memory check with task manager, and see no increasing(so no leakage).
2) enable crush log in the chrome://settings/
result:
2.1) see still nothing in the chrome://crashes page, not even a crush ID (0 crashes).
2.2) see nothing in the folder under path
C:/%User%/AppData/Local/Google/CrashReports (nothing in) nor
C:/%User%/AppData/Local/Google/Chrome/User Data/Crash Reports (folder not exist)
2.3) but indeed see DMP in the:
C:/%User%/AppData/Local/Google/Chrome/User Data/CrashPads/reports
but seems they are not readable, and it also seems not the correct address for crash logs
3) can get chrome log either by command line arguments, or using sawbuck, but found nothing but only 2 errors, one for sawbuck itself, and another saying can't send the report to google.
So the questions are:
1) are those DMP the crash logs(the default Dir for dump file has been changed for chrome v50)
2) how can I abstract information out of the DMP file, if chrome://crashes page shows nothing (for chrome on windows)
p.s. 2 usage pages are found at https://www.chromium.org/developers/decoding-crash-dumps
https://www.chromium.org/developers/crash-reports
but seems it's not for windows without a recompile of chrome's component, is there any 3rd party tools to interpret the DMP file?
env informations:
chrome version: 50.0.2661.02 m
; Host OS: windows 10
The crash dumps (.dmp files) in C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Crashpad\reports can be read by standard Windows debuggers. WinDbg is one tool (provided by Microsoft) for analysing these dumps; it's not going to win any beauty contents, but it's powerful and gets the job done. The recommended way to obtain it is, somewhat bizarrely, the Windows Driver Kit.
You'll need debugging symbols to make sense of the results, and these aren't included in standard builds of Chrome. To get symbols for both Chrome and the Windows runtime, set the following as your Symbols path:
SRV*c:\symbols*https://msdl.microsoft.com/download/symbols;SRV*c:\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com
There are numerous resources on using WinDbg on the web; this cheat sheet contains some useful commands to get you started.