Project Load Failed : Cannot access ....atp5

(Thomas de Nooij) #1

We have an Automise 5 project that calls an action list in another Automise project in parallel async groups. This has worked perfectly on multiple servers, but suddenly we are getting errors: Project Load Failed : Cannot access library.atp5. Any reason why this is happening?

(Vincent Parrett) #2

Does the file exist?
Is the path to the file correct?
Can you load library.atp5 in the Automise IDE?

That would be the first things to check.

How are you calling, using the Include Project action or directly executing atcmd?

(Thomas de Nooij) #3

Yes, I can open the file directly and the path exists. Also, the same action is called from other threads successfully. Here are some parts from the logging:


and this is the action that fails:

I am calling the project using the Include Project action. We run the 5.0.1015 build.

(Vincent Parrett) #4

Is the library.atp file a large project, wondering if it takes more than a second to load?

You could try to increase the thread start delay to 2s and see if that helps.

In the mean time I’ll try to reproduce this here, it’s a common scenario that many customers (both Automise and FinalBuilder) use so I’m surprised we haven’t seen this before.

(Thomas de Nooij) #5

I will try with a 2 second delay. I need to wait until tonight because this is a production server and I cannot start the script at this moment.

So it should be possible to call the same project from two asynch threads at the same time? That one thread is still processing the action list from that project (and blocks it) while the other is trying to call the same project and fails?

(Vincent Parrett) #6

Yes, it should be possible, there is is a mutex in place for the filename to avoid overwrites. We will try to reproduce this here and also see if we can improve the error message so we can tell exactly where it’s failing.

(Thomas de Nooij) #7

We executed the script with the 2 second delay, and now it is functioning correctly. The script itself is executing backup processes and zip-actions, so this will slow down the server it is executing on. Could this be the cause? The thing is that we run the same script on 20 other servers without problems and also ran on this server for a while without problems.

(Vincent Parrett) #8

I haven’t been able to reproduce this here so far. My guess is there is some sort of timing aspect to the cause. Are you able to send your project files (the main one and the library) to support - that way we can try to setup the exact same scenario under the debugger and see what’s going on.

(Thomas de Nooij) #9

Can we send this private?

(Vincent Parrett) #10

yes, send it to support @

(Thomas de Nooij) #11

Tonight the problem occurred again. We are happy to replace the automise with a version that gives you more debugging info.