Bug: AcCoreConsole IMPORT hangs

Bug: AcCoreConsole IMPORT hangs

DynamicObjects
Advocate Advocate
1,248 Views
4 Replies
Message 1 of 5

Bug: AcCoreConsole IMPORT hangs

DynamicObjects
Advocate
Advocate

Hi Autodesk community,

 

Description:

In this post i am describing a situation where the IMPORT command simply hangs.

The IMPORT command hangs when it is issued (within a short period of time) from multiple instances of acCoreConsole. 

(This is a separate behaviour from the bug I described here and for which Autodesk reported that they have provided a fix for in AutoCAD 2020). 

I would like to stress that IMPORT does NOT fail at all for the exact same files if acCoreConsole is run sequentially, looping through and IMPORTing each file one by one. -- it fails when two or more instances of acCoreConsole are run in parallel and each calls IMPORT on their respective files (different files!!).

 

How to reproduce:

1) Write a script to launch 2 or more parallel processes (c# Diagnostics.Process.Start) of accoreconsole where each instance issues IMPORT with a <unique_filename.iam> then issues a SAVEAS with a <unique_filename.dwg>

2) Have the script iterate over a statistically significant number of files - say 20 to 50 .iam files - so that chances of a collision increase.

3) Note that accoreconsole.exe will hang when 2 or more instances issue their IMPORT commands at similar times. (within a few seconds on my machine).  You will see that it hangs during the IMPORT command (if you run with the console window visible you will see the IMPORT command writes progress dots  "..." for ever until you kill the process). 

 

Workaround:

I suspect that the IMPORT command might be failing due to some internal race or deadlock condition on some resource that it uses. 

My workaround is therefore to prevent multiple instances of Core Console from issuing the IMPORT command at a similar time.  In my project the way I have achieved this is to ensure each instance calls Process.Start() inside a lock that includes a delay as follows:

 

 

	lock (MyPadlock)
	{
		// launch this instance of acCoreConsole
		p.Start();

		// wait a little while before releasing the lock to ensure other acCoreConsole instances are 
// suitably staggered to prevent internal deadlocking on the same resource
// say, acTranslators.exe perhaps. int milliseconds = 5000; // 5 seconds Thread.Sleep(milliseconds); }

 

 

The question is how long a delay is sufficient - and i guess the answer to that depends on how fast a computer you are running it on.

 

I have experimented with the time period and find that on my machine if i lock other instances from starting for 5 seconds then i get no failures at all.

However, if I reduce the time period to 3 seconds i begin to get some failures now and then.

If i reduce the time period to ZERO then I find that every thread fails except for the first thread to start.

 

I'd appreciate feedback on this - especially if you cannot reproduce the behaviour

regards

Dan

------------------------------------------------------------------------------------------------------------
Atkins Consultants Ltd UK
+19,000 staff (M&E, Civils, Structural, Geotechnical, Environmental and more)
0 Likes
Accepted solutions (1)
1,249 Views
4 Replies
Replies (4)
Message 2 of 5

natasha.l
Alumni
Alumni

Hello @DynamicObjects

 

Message 3 of 5

m_latz
Advisor
Advisor
Accepted solution

A customer of us use the accoreconsole many years, with sometimes thousands of jobs a day. And it is very robust, more than the previous "Batch AutoCAD" were they use an AutoCAD and send commands to the command editor.

 

They use 5 or more accoreconsole parallel (you can configure), but they/we "isolated" the accorsonsole.

Yes we use the isolate command switch, but this only does not work,  we had also "deadlocks".

So we clone the environment for every accoreconsole "on the fly". And after doing that we never had any problems.

They/we do not use the import scenario you describe, but I'm sure if you separate your accorconsole it could work.

 

The idea for this came from an ADN devblog I read, when we developed that, but I could not find that article at the moment.

 

regards

 

Markus

Message 4 of 5

DynamicObjects
Advocate
Advocate

Hey thanks for this informatio @natasha.l  @m_latz 

 

What constitutes the ‘environment’ for acCoreConsole.exe – i.e. how do we determine what are its dependencies/resources ..and.. since we are calling the IMPORT command which launches acTranslators.exe – then what are the dependencies/resources used by acTranslators.exe also?
How did you go about figuring this out?
regards
dan

------------------------------------------------------------------------------------------------------------
Atkins Consultants Ltd UK
+19,000 staff (M&E, Civils, Structural, Geotechnical, Environmental and more)
Message 5 of 5

m_latz
Advisor
Advisor

Excuse the delay, but I had to finish some urgent work.

 

When we developed the "Batch AcCoreConsole" for our customer, we assumed, that the collisions could only in areas where write access exists (registry and file system). So we monitored with procmon the core console and then isolated the parts of the core console.

 

regards

 

Markus