Skip to main content

Hi everyone,

 

I have bots in production environment. They connect to a simple webpage.

They used to work correctly. All of a sudden they stopped working with the message “The web page took too long to load. Increase wait time and try again.”. 

I have added delay, I have re-developed the bot, I resetted Google Chrome to its default version, double checked that it is the same version that on my local machine, that it is the latest package (recorder package 4.1.0) , I still get the same error. On the other hand, on my local machine it works perfectly. 

Is there a way to solve that ?

 

Hi ​@Augustin ,

 

Instead of adding static delays, do like this

 

Find a stable Object in the webpage that you can reference. Then use the Loop → While and set the condition as Object doesn't exists where you can use the web object. By doing this, the bot will continuously loop until it finds the object within the page.

 

Hope it is clear and will help.

I can consistently replicate the issue on a slow computer. This may be the new reality with the MVC 3 plugins. 

The computer I can replicate this on has a 1.1GHz Celeron processor with 16GB RAM and 512GB M2 PCI-E SSD. In my case, it is not a lack of memory or storage, it is definitely the slow CPU. 

In your case, ​@Augustin , if you're using VMs for the bot runners, you may have to allocate more CPU power to those VMs. 

I can consistently replicate the issue on a slow computer. This may be the new reality with the MVC 3 plugins. 

The computer I can replicate this on has a 1.1GHz Celeron processor with 16GB RAM and 512GB M2 PCI-E SSD. In my case, it is not a lack of memory or storage, it is definitely the slow CPU. 

In your case, ​@Augustin , if you're using VMs for the bot runners, you may have to allocate more CPU power to those VMs. 

Hi Aaron,

 

Thanks a lot for your answer.

I am running a VM with 4 vCPU and 16 GB of RAM (labelled “Power” on AWS)

It should be more than enough to connect to a basic web portal, don’t you think ?

Hi everyone,

 

To keep you updated, the Automation Anywhere support was fast and efficient to answer.

When switching from Manifest v2 to Manifest v3, there was still a “zombie” process from the MV2. It was that one that considered that Chrome was unavailable.

By disabling the Automation Anywhere service and killing the process, then re-enabling the service, the problem was solved.

Great job troubleshooting that. Maybe that’s why Chrome is moving from MV2 to MV3.

I’ll have to check the super slow laptop and see if it is suffering from the same problem.

Terms & ConditionsCookie settingsAccessibility statement