VMware Cloud Community
LukasWe
Enthusiast
Enthusiast
Jump to solution

Check Host Compliance Not Working - Unhandled vRO Exception

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); // VcHostSystem

var profiles = new Array();
profiles.push(profile); // VcHostProfile

var 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); // VcHostSystem

var 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.

0 Kudos
1 Solution

Accepted Solutions
iiliev
VMware Employee
VMware Employee
Jump to solution

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.

View solution in original post

0 Kudos
5 Replies
iiliev
VMware Employee
VMware Employee
Jump to solution

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?

0 Kudos
LukasWe
Enthusiast
Enthusiast
Jump to solution

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

0 Kudos
iiliev
VMware Employee
VMware Employee
Jump to solution

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.

0 Kudos
LukasWe
Enthusiast
Enthusiast
Jump to solution

Wow! Thanks for the hint that it works inline Smiley Happy

Can you take care to report this bug? For me it is fine to use the action inline for the time being.

Regards,

Lukas

0 Kudos
iiliev
VMware Employee
VMware Employee
Jump to solution

I opened a bug.

0 Kudos