Feat request: add sender on I'm Bussy message

Hello,

I have a constant message, in the docker logs, for the api container,
"Error: Sorry, I’m bussy
at WebSocketServerClient.Queue (/data/WebSocketServerClient.js:724:19)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
"

I have 14 HD Robots, which get informations from the Workitems Queue.
Is this normal?

Regards

Eric

yes and no.

Why you get the message

It depends on when and how you get it.
The error is from a OpenRPA client that was asked to invoke a workflow, and refused to due so. This will put the message back in the message queue for another (or the same robot) to pick up.
The timeout on each queue is really low, (default 1 minute) so if a message stays in the queue for more than one minute it will get moved to the dead letter queue, and then the api will pick it up and send a “timeout” error message back to the sender. ( the “request timed out, no robot picked up the message in a timely fashion” you might have seen in Node-RED )

safe examples

Say you have one robot. You send 2-3 request this robot to run a workflow, at the same time, but it can only do one at the time, but each workflow completes within a few seconds. Then you will see this message a few times until the robot has completed all 3 workflows. No issue.

Say you have 3 robots consuming the same queue ( a role with rpa enabled ). Whenever you send a message to the queue, rabbitmq will round robin between the robots, so if each workflow takes a while to complete and you have a steady stream of workflow run requests, there is a high chance a robot that is busy will get asked to run the workflow. The robot will reject it, and rabbitmq will just move on to the next robot.

In both cases you are fine, as long as no message stays in the queue for a long period of time. But you if keep seeing the messages it could be a symptom of you need more robots to pickup messages.

important exception

EXCEPT if you are using workitem’s. If these messages are from workitem queues notifying robots about new work, then you will see plenty of “bussy” messages and those can safely be ignored. The way workitem queues work right now, is they will, pretty aggressively, keep notifying the amqp queue they where assigned about new work ( default once every 10 seconds ) so if workflows take more than 10 seconds, or you have a main workflow that keeps popping items until the queue is empty, you will see these message pretty regularly while there are new items in the queue. Either way, you can safely ignore them in this case, since the workitem queue system will ensure all work is getting handles as long as your robots are working.

Thanks for the answer.

I’m in the “important exception case”, I’m using workitem’s queues, with a lot of messages (around 1K). And each HD robots have a workflow which takes around 5-10 minutes…

in that case, you can safely ignore the message.
( I have often been conflicted about weather to log the message or not. in 99% of the cases it’s not an error and should be ignored, but in those rare cases where you are troubleshooting why a workflow is not being run, it can save you so much troubleshooting time )

I understand, logging can be a tricky thing. In the log, we could have the robot which sends the “bussy” message, this could help to understand that this log is not coming from the Openflow but from a Robot instead.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.