How to prevent HTTP 302 when running long tests from RQM Adapter?
My team is maintaining custom instance of RQM Adapter to run our tests. We are also running long tests (longer then 8h, up to 3 days) and we are facing the following issue.
When the test execution is finished, adapter is executing some PUT/POST requests to RQM and gets HTTP 302 and RedirectException. When running shorter tests and sending same data in PUT/POST we do not get that issue. Afterwards we are executing some GETs to existing items (testscript, adaptertask, executionworkitem) by their IDs (URLs) and getting empty responses. And again - in long running tests we have the issue, but in shorter tests not - in the same resources.
We suppose it is matter of keeping communication with RQM alive. Do you know how we can deal with it in our code to keep the RQM communication alive? Which class/method we should use or there is any other thing we can do?
We are using RQM 4.0.4
When the test execution is finished, adapter is executing some PUT/POST requests to RQM and gets HTTP 302 and RedirectException. When running shorter tests and sending same data in PUT/POST we do not get that issue. Afterwards we are executing some GETs to existing items (testscript, adaptertask, executionworkitem) by their IDs (URLs) and getting empty responses. And again - in long running tests we have the issue, but in shorter tests not - in the same resources.
We suppose it is matter of keeping communication with RQM alive. Do you know how we can deal with it in our code to keep the RQM communication alive? Which class/method we should use or there is any other thing we can do?
We are using RQM 4.0.4
Accepted answer
Hi Mateusz,
It sounds like the adapter's HTTP client logs out of the RQM server, possibly due to inactivity (e.g. HTTP requests). For example, the 302 is probably a redirect to the RQM login page. The adapter's HTTP client would need to a) make HTTP 'ping' requests to the RQM server before the HTTP client logs out of the RQM server or b) relogin into the RQM server to resolve the symptom.
It sounds like the adapter's HTTP client logs out of the RQM server, possibly due to inactivity (e.g. HTTP requests). For example, the 302 is probably a redirect to the RQM login page. The adapter's HTTP client would need to a) make HTTP 'ping' requests to the RQM server before the HTTP client logs out of the RQM server or b) relogin into the RQM server to resolve the symptom.