Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
"504 Gateway Time-out" error when debug of web application which is running in Eclipse Che workspace on OCP
See original GitHub issueDescription
There is 30 sec timeout of waiting response from Web application when we stop application at the breakpoint in debug mode in Eclipse Che which is run on OCP infrastructure:
Server response:
<html><body><h1>504 Gateway Time-out</h1>
The server didn't respond in time.
</body></html>
java.lang.RuntimeException: java.lang.Exception: Cannot do request for application: 504<html><body><h1>504 Gateway Time-out</h1>
The server didn't respond in time.
</body></html>
Reproduction Steps
Steps to reproduce: look at the selenium test StepIntoStepOverStepReturnWithChangeVariableTest#changeVariableTest().
This issue is reproducing both in browser and with java client library HttpURLConnection.
OS and version:
Eclipse Che Multiuser 6.3.0-SNAPSHOT which is run on OCP
It works correctly on Docker.
Diagnostics:
Issue Analytics
- State:
- Created 5 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@eivantsov @dmytro-ndp Personally I, as a full-time engineer don’t see this as a big problem for a developer. Usually, debugging is not about changing something in debug and watching how it appears on the client side. But this is an important thing for some cases and definitely for demos of Che on OS. But only for certain people in certain cases, so I believe that we should not set it to something like 1h for all the workspaces of all the users. We can do something for particular workspaces or servers. For example, add an ability to configure this behavior in an infrastructure agnostic way in workspace attributes or server attributes. In this case, we can even provide UI to enable this.
Issues go stale after
180days of inactivity.lifecycle/staleissues rot after an additional7days of inactivity and eventually close.Mark the issue as fresh with
/remove-lifecycle stalein a new comment.If this issue is safe to close now please do so.
Moderators: Add
lifecycle/frozenlabel to avoid stale mode.