Async actions with dynamic content

The Async action group enables the execution of all child nodes concurrently.

One disadvantage for me is the fact that all the child nodes must be placed in DESIGN TIME (when creating the project).

This does not allow for more dynamic scenarios, where the tasks needed to run asynchronously are not known ahead of time.

For example - i'd like to perform some task on a given set of remote servers, the list of servers will be read from file at runtime, and is not known at design time.

With today's design, this scenario is not possible.

This is trivial to achieve with the current design, using Action Lists, action list parameters, the run actionlist action and the async group action.

I'm sorry but i don't understand how is this possible.

How can i create it with today's design?

Let see the task i'd like to perform asynchronously is Copy File to some location unknown at design time.

Copy File (src: C:\Test.txt, dest: %Dest_Iterator%)

In theory, i'd like to have something like:

Async Iterator (save %Dest_Iterator%)

Copy File from src -> %Dest_Iterator%

End

This would finish only after all copy actions finished (but all of them will execute concurrently).

Please let me know how to achieve something of this type.

Thanks

Lior

 I have attached and example of how to process a list of items using async groups and run actionlist.

 

AsyncOnAListOfItems.zip (4.452 KB)

I ran this example.

According to what i understand, it runs 2 WHILE loops concurrently, this is not what i've described.

How will this allow me to execute an arbitrary number of tasks concurrently?

 

Lior

It won’t and that can’t be done. According to your original post :

i’d like to perform some task on a given set of remote servers, the list of servers will be read from file at runtime, and is not known at design time.


That can be done in serial quite simply, or in parallel using the example I posted. Obviously it doesn’t parallelize the entire list of servers, that would result in it being slower than the serial version, you should use as many threads (each immediate child of an async group uses a thread) as you have cores or processors.

Think of FinalBuilder as a programming language, it doesn’t and can’t generate code on the fly, it can however do logic, branching, looping etc.

I understand.

My wish was for it to be able to parallelize the entire list.

I haven't asked anything related to code generation, the logic is quite simple.

I have a long lasting task -- MSI installation which consumes around 15-20 minutes.

I'd like to parallelize this task and be able to install on any number of remote servers concurrently.

 

This task is not CPU intensive (for the local server), only for the remote servers used for installing, thus making it a perfect fit for an async action.

I believe this action is not bound by the number of cores or processors on the local machine, since it involved little actual processing on the machine running finalbuilder, and more on remote machines doing the work.

 

Do you think this can't be done?

 

Thanks alot!

Lior

I don’t believe it can be done without us dreaming up some new constructs… and quite frankly I don’t think that will happen. We see users tying themselves in knots all the time with async groups inside async groups… one project I looked at had close to 500 threads running in a single core virtual machine and the user was wondering if I had any tips to improve performance.

I have to say that what you are wanting to achieve sounds more like a job for automated deployment systems.

Fair enough.
Last question – do u think this can be coded by me using the API supplied?

I don’t remember if StandardAction exposed any information regarding child nodes or parent nodes.
If this is the case it would be able to build some sort of mechanism by myself.

Lior

No, that is not exposed to the external api’s.

 Hi.

has there been any progress in this issue? (running a dynamic number of action lists)

 

Thanks,

 

Or Rubin

 

 

No progress, we do not have any plans to implement this feature at this time.