Executions queued, never run; enclosed exceptions shown
Project has ~20 lab resources with "Sample: Command Line Adapter" adapter.
When test suite is executed sometimes certain machines get put in queue and never progress. The jazz log has
javax.xml.bind.MarshalException
- with linked exception:
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:304)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:230)
at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:96)
at com.ibm.rqm.xml.service.internal.JAXBContextService.marshalWriter(JAXBContextService.java:67)
at sun.reflect.GeneratedMethodAccessor146.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
In proximity to:
ERROR - Remote Host: X.42.53.105
08/30/2011 09:32 AM
Remote Host: X.42.53.105
Location
com.ibm.rqm.executionframework.service.integration.jaxb.AdapterTaskGetHandler.handle(AdapterTaskGetHandler.java:113)
RQM 2.0.1.1 ifix3
Any recognition out there ?
When test suite is executed sometimes certain machines get put in queue and never progress. The jazz log has
javax.xml.bind.MarshalException
- with linked exception:
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:304)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:230)
at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:96)
at com.ibm.rqm.xml.service.internal.JAXBContextService.marshalWriter(JAXBContextService.java:67)
at sun.reflect.GeneratedMethodAccessor146.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
In proximity to:
ERROR - Remote Host: X.42.53.105
08/30/2011 09:32 AM
Remote Host: X.42.53.105
Location
com.ibm.rqm.executionframework.service.integration.jaxb.AdapterTaskGetHandler.handle(AdapterTaskGetHandler.java:113)
RQM 2.0.1.1 ifix3
Any recognition out there ?
4 answers
Try to identify if the issue is specific to a certain adapter. Essentially see which adapter isn't running the script it's suppose to run. And try to run a script on that adapter outside of the test suite.
If the problem persist for that adapter, then it appears something is hosed with it. To "fix", stop the adapter and go to the Execution->Adapter Console page and delete the adapter from this adapter console. Then restart the adapter and try to use it again.
If the problem persist for that adapter, then it appears something is hosed with it. To "fix", stop the adapter and go to the Execution->Adapter Console page and delete the adapter from this adapter console. Then restart the adapter and try to use it again.
Try to identify if the issue is specific to a certain adapter. Essentially see which adapter isn't running the script it's suppose to run. And try to run a script on that adapter outside of the test suite.
If the problem persist for that adapter, then it appears something is hosed with it. To "fix", stop the adapter and go to the Execution->Adapter Console page and delete the adapter from this adapter console. Then restart the adapter and try to use it again.
The adapters were 'rebooted' by the customer with no effect on the pending runs.
Only restarting RQM has any effect.
Try to identify if the issue is specific to a certain adapter. Essentially see which adapter isn't running the script it's suppose to run. And try to run a script on that adapter outside of the test suite.
If the problem persist for that adapter, then it appears something is hosed with it. To "fix", stop the adapter and go to the Execution->Adapter Console page and delete the adapter from this adapter console. Then restart the adapter and try to use it again.
The adapters were 'rebooted' by the customer with no effect on the pending runs.
Only restarting RQM has any effect.
I get the sense that the pending runs aren't going to start. But to help get the adapters in a better state, then it would be good to first identify the adapters facing the issue and delete them from Adapter Console. Essentially no current queued task will run for that adapter, however hopefully that adapter wouldn't have this issue any more.