Robots going unresponsive ORCHESTRATOR 2018.4.3

Help
,
1

Hi all,

We have recently updated our orchestrator from 2018.2.6 to 2018.4.6.

After the update we can see that the robots in Orchestrator keeps going unresponsive at an interval of time(4mins to 6 mins). During this time the scheduled jobs are not getting triggered.

Are there anyone facing similar issues? Any solution to fix this

Thanks in advance!

Robot%20Alerts
Robot%20Alerts1579Ă—799 46.9 KB

2

We received same issue. I would share what we did, but installation responsibility was shifted to IT and they are not normally very transparent on resolutions.

Our IT had an UiPath representative help resolve the issue. If I was to guess, I would say the license or Robot.exe was not installed right.
I suggest have UiPath support on this: Contact Technical Support

Regards.

1 Like
3

Thanks for the reply @ClaytonM . I have already raised a ticket with UiPath. They looked into the issue they weren’t able to find whats causing the issue. We are still waiting for the response them.

I tried reinstalling the robots but that didn’t fixed the issue.

Thanks,
Ashok

4

Hello @ashoks93,

Is the Orchestrator instance hosted in Azure? If so, please check whether this is s single-node or a multiple-node instance. If it is a multiple-node, you need to make sure that redis is added to the instance, and the correct updates are made to the web.config file.

Also, how many schedules do you have enabled? In the db, are there any blocked triggers in the Quartz Triggers table?

Thank you!

1 Like
5

@Bogdan_Toma how can you check for blocked triggers? Do you just clear them with a SQL update?

6

It would be great if you could figure out what happened. We are experiencing the exact issue i.e. they go unresponsive after a few minutes then come back.

Here is what I observe:

  • Robots oscillate between unresponsive and available about every 8-10 minutes.
    image

  • This occurred after an update of the orchestrator from version 2018.3.2 to 2018.4.3.

  • If I reattach the affected robot to the “old” orchestrator (we updated in parallel). The robot remains available.

Things I’ve tried:

  • Confirmed the UiPath Robot Service is running on the robot.|
  • Restarted the robot ( to reset the service and WPF tray application).|
  • Deleted the machine record from orchestrator.|
  • Deleted the robot record from orchestrator.|
  • Created a new machine record in UiPath.|
  • Created a new robot record in UiPath.|
  • Reattached the robot after a restart.|
  • Replaced the tenant license with an allocation of robots from the host license.|
7

I believe this is the answer. We resized our Azure app service plan from two nodes to one and the problem seems to be resolved. No, we didn’t perform the multiple node configurations in the initial deployment.

After resizing back down to one instance this morning.
image

8

If I understand correctly, your robots still become unresponsive, after you have sized down your Azure app to a single node. Are the app and the SQL DB on the same timezone? De-synchronization between the app and DB, would lead to robots becoming unresponsive.

9

That’s correct. There were several changes we did before getting this issue fixed. Not sure if a single change fixed or a series of changes fixed. One was we saw all the time stamp in the db was different than the actual timezone also, we disconnected all the robot machines and reconnected one by one observing the behaviour, Orchestrator must be updated first i.e. only after that robot machines should be updated.

Thanks,
Ashok

10

I found out what solutions we used to resolve our issue…
We use a Load Balancer between 2 servers, so we needed to verify that the Redis settings in the web.config file (which are in two sections: <!--Load Balancer--> and under it <!--Uncomment this to enable redis state-->) on both Orchestrator servers matched.

This is kind of what Bogdan is saying.

Regards.

4 Likes