-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Server Deployment/Start Appears to Timeout After 2 Minutes #587
Comments
Looking at the codebase for the rsp, it seems we do have a 2 minute timeout for recognizing the server is started. And at this time we don't have a setting to override that. So your issue is a real one, and a bit unfortunate that I didn't consider adding a setting to override that. I'm going on time-off for the next 5 weeks, so I won't be able to fix this until I get back unfortunately. But I just wanted to give you the peace of mind in at least knowing that this is a real issue, someone has looked into it, and it's a feature that should be expanded for our users. |
Moving this issue to rsp-server where the timeout is enforced. |
Without prying, can you explain why your WF takes more than 2 minutes to start up? Is it that you're debugging the startup process? Or do you have some large deployments that delay the complete startup of the app server? |
Thanks @robstryker! I was actually doing some more investigating into why we were hitting this timeout all of a sudden, and it looks like there may have been some policy changes to the enterprise AV my company uses. I am currently working with them to whitelist the relevant directories, so that should hopefully bring or deployment time down. The app I support is quite large, so deployment usually takes some and that can affect the startup process. Couple quick questions:
|
The two-minute timeout is in the RSP server, which is a standalone process that the vscode extension uses to start / stop / deploy to wildfly. I don't think it'd be easy to fork since you'd need to be able to build the rsp and the extension. I'd give you some steps (or actually fix the bug) but I'm on PTO right now. Sorry. |
No worries!! Hopefully you are enjoying your PTO :). I was thinking if it was a relatively easy fork/fix it could be done as a temporary workaround, but that is not a problem |
Back from PTO. Will add timeout overrides for users once I get settled. :D |
https://github.com/robstryker/rsp-server/tree/serverTimeoutOverrides Will merge once I regain access to my damn github. Ugh. |
Hah, no worries! Thanks for the quick fix Rob! Greatly appreciated :) As an aside, we were able to confirm that some changes to the company AV software was causing it to be overly aggressive on scanning the deploy folder as it was creating the temporary files. So it seems to be a combination of a large project and the AV software caused us to just barely bump up against the 2 minute timeout |
Hi Rob! Just wondering if you had any luck recovering your account? |
This was fixed here: #596 Still no extension release. Working on it. Closing this issue since it's committed |
Thanks Rob! |
18:29:20,199 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.2.0.GA (WildFly Core 6.0.11.Final-redhat-00001) iniciado em 46698ms - Iniciado 838 de serviços 1036 (os serviços 357 são lazy, passivos ou em demanda) @robstryker jboss starts but red hat server connector stays in "starting". after 2 minutes it stops server. EDIT: |
Once the server process is launched, we use a web-port polling mechanism, ie, we go to localhost:8080 or whatever other port is expected, and wait for a response. If your server is stuck in 'starting...' mode, you will want to check that its reachable by browser at the expected url. If you have changed the binding host or port, then you need to update various properties in the server adapter so that the tool knows where to look for a running server. |
Happens on my end with Wildfly 25 |
UPDATE: seems like I was probably mistaken, but "server.timeout.startup": "120000" as recommended by redhat-developer/vscode-server-connector#468 (comment) worked ...... I'm not sure if my issue was the same, but I'll post it here for posterity... With my tomcat instance, I had an issue with the server dropping when I entered a debugger (before the server finished starting). I believe it was due to the way tomcat works. I fixed it by placing this in the base.xml of my CATALINA_BASE (conf/localhost/base.xml): <?xml version="1.0" encoding="UTF-8"?>
<Context>
<Connector port="8080" connectionTimeout="-1" />
</Context> Btw, examples like above are part of why I think publishing some basic configuration could be helpful redhat-developer/rsp-server-community#160 |
A long starting server being stopped without any warning brought me here... It looks like both Also, probably for another feature request, I can't see why there is currently no notification about forcefully stopping the server because of the timeout. Or is it there, just not functioning? |
redhat-developer/vscode-rsp-ui#297 documents the falgs. |
Opened #723 to track the request of a notification upon timeout |
@robstryker, thank you, the changes look promising. 👍 |
Good Day,
I've recently run into a problem with my VSCode Server Extension when trying to deploy to a Wildfly 11.0 instance under JDK 8. (I have also tried using WildFly 19.1 with JDK 11 to no avail).
It seems no matter what I do, when attempting to launch the server via the VSCode extension, the server will startup as normal, but at around 2 minutes each time, the process abruptly stops and the server changes from "Starting" to "Stopped'.
The odd thing about this is I do not run into the issue when launching Wildfly from the various standalone.bat/.sh scripts.
Is there a configuration for timeout I am missing somewhere? I have searched the standalone.xml and cranked any potential waits/timeout values, but am still experiencing the same results. While not essential, it is nice being able to quickly attach a debugger directly through VSCode :)
Please let me know if you require logs or any other information.
The text was updated successfully, but these errors were encountered: