Hello,
I just wanted to ask if anyone has the same problem when checking the host profile compliance for a host system.
The vRO executes the task in the vCenter successfully but then an unhandled exception is thrown in the orchestrator in the background and the appliance is a short time afterwards not responding anymore and only a reboot helps...
My code to create the VcTask which is executed in the vCenter:
var hosts = new Array();
hosts.push(in_host); // VcHostSystemvar profiles = new Array();
profiles.push(profile); // VcHostProfilevar cm = VcPlugin.allSdkConnections[0].complianceManager;
checkComplianceTask = cm.checkCompliance_Task(profiles, hosts);
This code is also possible to create the task:
var hosts = new Array();
hosts.push(in_host); // VcHostSystemvar profiles = new Array();
var cm = VcPlugin.allSdkConnections[0].complianceManager;
checkComplianceTask = cm.checkCompliance_Task(profiles, hosts);
Logs:
[2018-07-10 16:28:00.214] [I] checkCompliance/task-24544 running 0 %
[2018-07-10 16:28:01.223] [I] checkCompliance/task-24544 running 0 %
[2018-07-10 16:28:02.235] [I] checkCompliance/task-24544 running 0 %
[2018-07-10 16:28:03.243] [I] checkCompliance/task-24544 running 0 %
[2018-07-10 16:28:04.254] [I] checkCompliance/task-24544 running 0 %
[2018-07-10 16:28:05.275] [I] checkCompliance/task-24544 ends with success
[2018-07-10 16:28:06.566] [E] Workflow execution stack:
***
', state: 'failed', business state: 'null', exception: 'null'*** End of execution stack.
I tested it with vRO 7.3 and 7.4. and both versions show the same behavior.
The main problem is that you even cannot handle the error path because it seems like that the workflow execution just aborts.
OK, I managed to reproduce the same 'Can not set long field ...' error using your workflow. Comparing your workflow with mine, it seems the only significant difference is that yours is using a separate action element for vim3WaitTaskEnd, while mine is calling this action inline.
This clearly looks like a bug that needs to be fixed. If you need an urgent fix, please open a SR, so we can prioritize it higher.
Hi,
Tried the second code snippet on my 7.3 and 7.5 environments; no error occured.
Could you export and attach the workflow that fails in your environment?
Attached you'll find the workflow.
Here is the live log from the vCO Control Center for this workflow:
2018-07-11 13:51:41.793+0200 [WorkflowExecutorPool-Thread-73] INFO {user@domain.com:check profile compliance:860b2358-22fa-4a11-86c5-4c7f7f389fce:token=2c9792e6647f2c390164892e8c2502a7} [DynamicFunction] End of action "com.vmware.library.vc.basic/vim3WaitTaskEnd", completed for: 14162ms
2018-07-11 13:51:44.035+0200 [WorkflowExecutorPool-Thread-73] WARN {user@domain.com:check profile compliance:860b2358-22fa-4a11-86c5-4c7f7f389fce:token=2c9792e6647f2c390164892e8c2502a7} [WorkflowHandler] Error in execution of workflow "check profile compliance for wfExecution[2c9792e6647f2c390164892e8c2502a7]
java.lang.StackOverflowError
at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:57)
at sun.reflect.UnsafeQualifiedLongFieldAccessorImpl.getLong(UnsafeQualifiedLongFieldAccessorImpl.java:62)
at sun.reflect.UnsafeQualifiedLongFieldAccessorImpl.get(UnsafeQualifiedLongFieldAccessorImpl.java:38)
at java.lang.reflect.Field.get(Field.java:393)
at com.rits.cloning.Cloner.cloneObject(Cloner.java:451)
at com.rits.cloning.Cloner.cloneInternal(Cloner.java:431)
at com.rits.cloning.Cloner.cloneObject(Cloner.java:453)
at com.rits.cloning.Cloner.cloneInternal(Cloner.java:431)
at com.rits.cloning.Cloner.cloneObject(Cloner.java:453)
at com.rits.cloning.Cloner.cloneInternal(Cloner.java:431)
at com.rits.cloning.Cloner.cloneObject(Cloner.java:453)
at com.rits.cloning.Cloner.cloneInternal(Cloner.java:431)
[... and so on ...]
And if you execute the workflow immediately again after the first failed run the vim3WaitTaskEnd action throws this error which can then be handled. But if I investigated it correctly I think this is related to the StackOverflowError before.
[2018-07-11 14:02:55.649] [I] Error Code: Can not set long field com.codahale.metrics.ThreadLocalRandom.rnd to com.codahale.metrics.ThreadLocalRandom
OK, I managed to reproduce the same 'Can not set long field ...' error using your workflow. Comparing your workflow with mine, it seems the only significant difference is that yours is using a separate action element for vim3WaitTaskEnd, while mine is calling this action inline.
This clearly looks like a bug that needs to be fixed. If you need an urgent fix, please open a SR, so we can prioritize it higher.
Wow! Thanks for the hint that it works inline
Can you take care to report this bug? For me it is fine to use the action inline for the time being.
Regards,
Lukas
I opened a bug.