"Request Timeout" during validation. What does this mean?

[Will Herrmann]

We run Gauge every night on our VM. Every so often, the Gauge validation runs for exactly two hours, then fails with the following error:

[Step 1/2] 22:01:20.438 [WARN] Validation failed. The following steps have errors

[22:01:20][Step 1/2] D:\BuildAgent\work\2d6565245b2c3b0a\DriverTest\specs\Preconditions-SectOnRespValTimeout.spec:31: Request Timeout. Click button "EndExamButton"

[22:01:20][Step 1/2] D:\BuildAgent\work\2d6565245b2c3b0a\DriverTest\specs\Preconditions-SectOnRespValTimeout.spec:63: Request Timeout. Verify error uRL is displayed

The console output continues with many more steps in other specs that have the same "Request Timeout" error. The full console output can be found here.

This issue does not happen all the time, and our usual response to this error is simply to run Gauge again, and then it works.

What does it mean that Validation failed and that there was a "Request Timeout"? How can we fix this error?

[Will Herrmann]

Also, I did see this discussion, where it talks about increasing the timeout value of property  runner_request_timeout in gauge.properties. We have it set to 10000, which seemed long enough for me, and doesn't explain why validation takes exactly 2 hours before failing.

[Mahendra Kariya]

Hi Will,

For any operation / action, Gauge core requests the language runners and waits for a response. If it doesn't receive any response within a particular time limit, it times out. How long the Gauge core should wait is something that users can configure by setting the runner_request_timeout property in gauge.properties.

Looking at the logs that you have shared, it looks like these errors have occurred in the validation phase. What Gauge core does is, for each spec file, it sends a validation request to language runner. Gauge aggregates all the validation errors (including time outs) and prints it when validation is done. And you are seeing these errors after 2 hours because that's the time Gauge takes to finish the validation. 

I see 3 issues separate here:

1. It could be a connection failure between Gauge core and language runner. This looks very likely. We are investigating this.
2. The fact that this occurs intermittently could be an environment issue. The most likely cause could be the way OS schedules various processes. Maybe you can check this happens consistently on the same VM?
3. If each validation action takes 10 secs then that is concerning and we NEED to improve the performance. However, I doubt this is what is happening. I think the validation take way less than 10 secs, but at some points the runner loses contact with the core which is why these time out. 

Can you help us with some more information - How many spec files you have and what is the combined size of those files on disk? Also, do you always see the same set of specs timing out?

Thanks

Mahendra

--
You received this message because you are subscribed to the Google Groups "getgauge" group.
To unsubscribe from this group and stop receiving emails from it, send an email to getgauge+u...@googlegroups.com.
To post to this group, send email to getg...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/getgauge/f8081323-f583-4d3e-84c0-b162847f6984%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Will Herrmann]

Hi Mahendra,

Thank you very much for your prompt reply.

We have 722 total specs taking up 4.97 MB on the disk. They are divide into eight groups, each group having its own tag. The following groups/specs fail to start (timeout): 

• Group 7 (77 Specs)  
  
• Group 8 (109 Specs)
  

It is about 50/50 whether or not these specs pass or fail, with them being run on the same VM. 

Hope this helps. Please let us know what we should do next.

[Mahendra Kariya]

Thanks for the details Will!

We will try and replicate this issue on our side to figure out what's going wrong. In the meanwhile, could you please try running these groups on a different VM. That will help us ensure that it's not an environment issue.

To view this discussion on the web visit https://groups.google.com/d/msgid/getgauge/9f5cdb40-0a8f-4c35-9099-f1b48779af3f%40googlegroups.com.

[Will Herrmann]

We have run the groups on different VMs and still had the same errors with those specific groups. Thus we have determined that the VMs are not the issue.

Please let us know what we should try next.