race condition using transient RESTHost

[yellowmito]

Hello,

we are using transient RESTOperations as shown in this example:

https://code.vmware.com/samples/2032/execute-a-transient-restoperation-for-a-transient-resthost

If we run two worflows creating different RESTHosts and RESTOperations using different credentials in parallel we encounter an issue that the RestHost object seems to get mixed up across both workflow runs and the wrong one is used.

Steps to reproduce:

- Create a action from this sample code in https://code.vmware.com/samples/2032/execute-a-transient-restoperation-for-a-transient-resthost

- Create a workflow calling this action in an infinite loop using url-A, user-A, password-A e.g. performing a GET against API-A

- Create a second workflow calling the same action in an infinite loop using url-B, user-B, password-B e.g. performing a GET against API-B

- start both workflows at the same time in the same orchestrator and check both workflow logfiles for authentication failed errors that indicate that sometimes the wrong RESTHost-object of the other workflow is used

It looks like there is a race condition mixing up the transient RESTHost object between parallel workflow runs?

Cany anyone confirm this issue?

Is there any solution for this?

Many thanks,

Dennis

[eoinbyrne]

I've seen some funnies here before with this type of interleaving when accessing the same RESTHost object.

If you want a quick fix, try using workflow locking to make sure callers are well behaved? It will slow down your execution as calls will be serial but at least you will not have the interleaving problem

[stevedrummond]

Does the same issue occur if you don't use REST Operations? Considering they're using a transient host I have no idea why they're also using rest operations.

I use transient hosts but don't bother with rest operations and so far I haven't run into any issues.

What version of vRO and rest plug-in?

[yellowmito]

We've already thought about using workflow locks. But as we have about 10 workflows using RestHosts within our OS deployment process which are triggered within different event broker phases we would need to set a global lock. For single VM deployments this would be fine, but deploying larger numbers it would slow down the provisioning a lot.

[yellowmito]

Not sue if I got your point? You are creating a transient REST Host and executing your REST calls without creating an transient REST Operation from this REST Host before?

the vRO is on 7.5.0.14913938

However are you able to reproduce the issue using the example code? We are still not 100% sure if it is a BUG withing the orchestrator or if we have an issue somewhere else?

[stevedrummond]

I just ran two workflows concurrently doing 1000 iterations each and I was not able to reproduce the issue. They were talking to different URL's with different credentials. This was on vRO 7.4 HF9.

Although it doesn't appear to be an issue with REST Ops, to answer your question you can just do RESTHost.createRequest(<params>) without using RESTOperation objects.